RFC 4972
Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership 🦋
Network Working Group · Request for Comments: 4972 · Category: Standards Track · July 2007 🎀
Authors: JP. Vasseur, Ed. (Cisco Systems, Inc), JL. Leroux, Ed. (France Telecom), S. Yasukawa (NTT), S. Previdi (Cisco Systems, Inc), P. Psenak (Cisco Systems, Inc), and P. Mabbey (Comcast) 💅
Okay so the title block says this is a Standards Track doc, dated July 2007, and it doesn't list anything it obsoletes or updates. So it's a fresh, official spec, no drama 🌸
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 💌
Copyright Notice 🔒
Copyright (C) The IETF Trust (2007).
Abstract 🧚
Okay, the big picture: setting up a full mesh of MPLS Traffic Engineering (TE) Label Switched Paths (LSP) between a bunch of Label Switch Routers (LSR) is super common. People do it for bandwidth optimization, bandwidth guarantees, or fast rerouting with MPLS Fast Reroute. The catch is that it can take a ton of TE LSPs to configure (on the order of the square of the number of LSRs) 😭
So this document specifies IGP routing extensions for IS-IS and OSPF that automatically discover which LSRs belong to a mesh, so the creation of that mesh of TE LSPs can be automated. It's giving automation, bestie 🤖💖
Table of Contents 📚
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Conventions Used in This Document ..........................4
3. Description of a TE Mesh-Group ..................................4
4. TE-MESH-GROUP TLV Formats .......................................4
4.1. OSPF TE-MESH-GROUP TLV Format ..............................4
4.2. IS-IS TE-MESH-GROUP Sub-TLV Format .........................7
5. Elements of Procedure ...........................................9
5.1. OSPF .......................................................9
5.2. IS-IS .....................................................10
6. Backward Compatibility .........................................11
7. IANA Considerations ............................................11
7.1. OSPF ......................................................11
7.2. IS-IS .....................................................11
8. Security Considerations ........................................12
9. Acknowledgements ...............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................131. Introduction 🌈
Okay, so there are two well-known ways to deploy MPLS Traffic Engineering, and they are giving two very different personalities 💅
(1) The so-called "strategic" approach, which is setting up a full mesh of TE LSPs between a set of LSRs. Very planned, very intentional, very main character 👑
(2) The so-called "tactical" approach, where a set of TE LSPs gets provisioned on well-identified "hot spots" to fix congestion caused by, for instance, unexpected traffic growth in some parts of the network. Reactive, but make it fashion 🔥
A full mesh of TE LSPs among a set of LSRs is a common deployment scenario for MPLS Traffic Engineering, whether it's for bandwidth optimization, bandwidth guarantees, or fast rerouting with MPLS Fast Reroute. But here's the tea ☕: a full mesh between N LSRs needs a potentially huge number of TE LSPs (O(N^2)). It gets worse, because adding one new LSR to the mesh means configuring N new TE LSPs on the new LSR, plus one new TE LSP on every LSR already in the mesh that points at this new one. That's a total of 2*N TE LSPs to configure, just for one router 😭💀
That whole process is time consuming and risky, since it's prone to misconfiguration, and Service Providers really feel that pain. So an automatic way to set up TE LSP meshes is very desirable, and it needs the ability to automatically discover the set of LSRs that belong to the mesh. This document specifies routing extensions to do exactly that discovery for a mesh, which it calls a "TE mesh-group". Just a heads up that the mechanism for dynamically creating the TE LSPs is implementation specific and outside the scope of this document 🧚
Routing extensions were already defined in [RFC4970] and [RFC4971] for advertising router capabilities. This document specifies IGP (OSPF and IS-IS) TE Mesh Group (Type Length Value) TLVs for automatic discovery of TE mesh-group members. These get carried in the OSPF Router Information (Link State Advertisement) LSA [RFC4970] and the IS-IS Router Capability TLV [RFC4971]. The routing extensions here also let you signal multiple TE mesh groups, and an LSR can belong to more than one TE mesh-group 🦋
Now the real-time part, which matters. IGPs such as OSPF and IS-IS have pretty tight real-time constraints, so you have to be careful about proposing to carry extra information in an IGP. The info in this document is relatively small in total volume (compared with what IGPs already carry), and it's also relatively stable. Changes come from configuration changes, not from dynamic events in the network or dynamic triggers, like leaking information from other routing protocols or routing protocol instances. Stable and small, the ideal houseguest 🫶
2. Definitions 🍓
These are the terms used in this document, so keep them handy:
- IGP: Interior Gateway Protocol
- IGP Area: OSPF area or IS-IS level
- IS-IS: Intermediate System-to-Intermediate System (IS-IS)
- LSR: Label Switch Router
- OSPF: Open Shortest Path First
- OSPF LSA: OSPF Link State Advertisement
- TE LSP: Traffic Engineering Label Switched Path
- TE LSP head-end: head/source of the TE LSP
- TE LSP tail-end: tail/destination of the TE LSP.
- TLV: Type Length Value
2.1. Conventions Used in This Document 🎀
Okay, the super-important caps words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Read those caps like they're serious, because they are 👑
3. Description of a TE Mesh-Group 💜
A TE mesh-group is defined as a group of LSRs that are connected by a full mesh of TE LSPs. The routing extensions in this document let members get discovered dynamically, and there are also procedures for a member to join and leave a TE mesh-group. For each TE mesh-group membership an LSR announces, the following information gets advertised:
- A mesh-group number identifying the TE mesh-group that the LSR belongs to,
- A tail-end address (used as the TE LSP Tail-end address by other LSRs belonging to the same mesh-group),
- A tail-end name: a display string that is allocated to the tail-end used to ease the TE-LSP naming.
4. TE-MESH-GROUP TLV Formats ✨
(More formats are coming in part 2, bestie 🧚💖)
4.1. OSPF TE-MESH-GROUP TLV Format ✨
okay so the TE-MESH-GROUP TLV is how an LSR says "hey, I wanna join this TE mesh-group" or "bye, I'm out" 🦋 it's giving networking drama. No sub-TLV is defined for it yet, so there's nothing nested inside (yet 👀).
This TLV rides inside an OSPF router information LSA, which is defined in [RFC4970]. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - OSPF TE-MESH-GROUP TLV formatWhere:
- Type: identifies the TLV type
- Length: the length of the value field in octets
The format matches the TLV format used by the Traffic Engineering Extensions to OSPF (see[RFC3630]). The TLV gets padded to a four-octet alignment, but padding doesn't count toward the length field. So a three-octet value has a length of three, yet the whole TLV takes up eight octets 🙈 Nested TLVs are 32-bit aligned too. Unrecognized types get ignored (no drama, just vibes). Everything from 32768 to 65535 is reserved for vendor-specific extensions, and all the other undefined type codes are saved for future IANA assignment 💅
Here's how it looks for IPv4 (Figure 2) and IPv6 (Figure 3):
TYPE: 3 with LENGTH: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)TYPE: 4 with LENGTH: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address 1 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address n |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address)The OSPF TE-MESH-GROUP TLV can hold one or more mesh-group entries, and each entry is one TE mesh-group made of these fields:
- A mesh-group-number that identifies the mesh-group number.
- A Tail-end address: an IPv4 or IPv6 IP address that other LSRs in the same mesh-group use as a tail-end TE LSP address.
- Name length field: an integer, in octets, saying how long the Tail-end name is before padding.
- A Tail-end name: a display string given to the Tail-end. It's variable length and helps with TE LSP identification 🎀
4.2. IS-IS TE-MESH-GROUP Sub-TLV Format ✨
the TE-MESH-GROUP sub-TLV is basically the same move, just for IS-IS 🌸 It says whether an LSR wants to join or leave a TE mesh-group. Again, no sub-TLV is defined for this sub-TLV right now.
This one shows up inside the IS-IS CAPABILITY TLV, which comes from [RFC4971]. It has 1 octet for the type, 1 octet for the TLV length, and then the value. Its format is identical to the TLV format used by the Traffic Engineering Extensions for IS-IS [RFC3784]. Iconic consistency 👑
Here's IPv4 (Figure 4) and IPv6 (Figure 5):
TYPE: 3 with LENGTH: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address)TYPE: 4 with LENGTH: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address 1 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address n |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - IS-IS TE-MESH-GROUP sub-TLV format (IPv6 Address)The IS-IS TE-MESH-GROUP sub-TLV can hold one or more mesh-group entries, and each entry matches a TE mesh-group and has these fields:
- A mesh-group-number that identifies the mesh-group number.
- A Tail-end address: an IPv4 or IPv6 IP address that other LSRs in the same mesh-group use as a tail-end TE LSP address.
- Name length field: an integer, in octets, saying how long the Tail-end name is before padding.
- A Tail-end name: a display string given to the Tail-end. It's variable length and helps with TE LSP identification 🦋
5. Elements of Procedure 💖
the OSPF TE-MESH-GROUP TLV lives inside the OSPF Routing Information LSA, and the IS-IS TE-MESH-GROUP sub-TLV lives inside the IS-IS Router capability TLV 🧚 That means the elements of procedure are inherited from [RFC4970] for OSPF and [RFC4971] for IS-IS. The big rule: a router MUST originate a new LSA/LSP whenever this info changes, or whenever regular routing procedure requires it (for example, updates) 🔥
The TE-MESH-GROUP TLV is OPTIONAL, and it MUST NOT include more than one of each of the IPv4 instances or the IPv6 instance. If an IPv4 or IPv6 OSPF TE-MESH-GROUP TLV shows up more than once in the OSPF Router Information LSA, only the first one gets processed, and the later ones SHOULD be silently ignored 🙈 The same deal goes for the IS-IS TE-MESH-GROUP sub-TLV: if either the IPv4 or IPv6 one appears more than once in the IS-IS Router capability TLV, only the first instance is processed, and the subsequent TLV(s) SHOULD be silently ignored 💅
5.1. OSPF 🦋
Okay so for OSPF, the TE-MESH-GROUP TLV lives inside an OSPF Router Information opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 [RFC2328], and inside a brand new LSA (Router Information LSA) for OSPFv3 [RFC2740]. The Router Information LSAs for OSPFv2 and OSPFv3 are defined in [RFC4970]. 💅
A router MUST originate a new OSPF router information LSA whenever the content of any of the advertised TLV changes, or whenever the regular OSPF procedure requires it (LSA update (every LSRefreshTime)). 🔥 If an LSR wants to join or leave a particular TE mesh group, it MUST originate a new OSPF Router Information LSA containing the updated TE-MESH-GROUP TLV. For a join, a new entry gets added to the TE-MESH-GROUP TLV. For a leave, the corresponding entry gets removed from the TE-MESH-GROUP TLV, so the LSR leaves a mesh-group the corresponding entry will be removed from the TE-MESH-GROUP TLV. Both operations can happen in the context of a single LSA update, which is so efficient 🧚. An implementation SHOULD be able to detect any change to a previously received TE-MESH-GROUP TLV from a specific LSR. Main character energy for sure ✨
As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the flooding scope of the Router Information LSA is determined by the LSA Opaque type for OSPFv2, and by the values of the S1/S2 bits for OSPFv3. 🌈
For OSPFv2 Router Information opaque LSA:
- Link-local scope: type 9;
- Area-local scope: type 10;
- Routing-domain scope: type 11. In this case, the flooding scope is equivalent to the Type 5 LSA flooding scope.
For OSPFv3 Router Information LSA:
- Link-local scope: OSPFv3 Router Information LSA with the S1 and S2 bits cleared;
- Area-local scope: OSPFv3 Router Information LSA with the S1 bit set and the S2 bit cleared;
- Routing-domain scope: OSPFv3 Router Information LSA with S1 bit cleared and the S2 bit set.
A router may generate multiple OSPF Router Information LSAs with different flooding scopes. Multitasking queen 👑
The TE-MESH-GROUP TLV may be advertised within an Area-local or Routing-domain scope Router Information LSA, depending on the MPLS TE mesh group profile:
- If the MPLS TE mesh-group is contained within a single area (all the LSRs of the mesh-group are contained within a single area), the TE-MESH-GROUP TLV MUST be generated within an Area-local Router Information LSA.
- If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh-group TLV MUST be generated within a Routing-domain scope router information LSA.
5.2. IS-IS 🌸
The TE-MESH-GROUP sub-TLV gets advertised within the IS-IS Router CAPABILITY TLV defined in [RFC4971]. An IS-IS router MUST originate a new IS-IS LSP whenever the content of any of the advertised sub-TLV changes, or whenever the regular IS-IS procedure requires it (LSP updates). 💖 If an LSR wants to join or leave a particular TE mesh group, it MUST originate a new LSP containing the refreshed IS-IS Router capability TLV, which holds the updated TE-MESH-GROUP sub-TLV. For a join, a new entry gets added to the TE-MESH-GROUP sub-TLV. For a leave, the corresponding entry gets deleted from the TE-MESH-GROUP sub-TLV. Both operations can happen in the context of a single update, iconic behavior honestly 🎀. An implementation SHOULD be able to detect any change to a previously received TE-MESH-GROUP sub-TLV from a specific LSR. 🫶
If the flooding scope of a TE-MESH-GROUP sub-TLV is limited to an IS-IS level/area, the sub-TLV MUST not be leaked across level/area, and the S flag of the Router CAPABILITY TLV MUST be cleared. 🙈 Conversely, if the flooding scope of a TE-MESH-GROUP sub-TLV is the entire routing domain, the TLV MUST be leaked across IS-IS levels/areas, and the S flag of the Router CAPABILITY TLV MUST be set. In both cases, the flooding rules specified in [RFC4971] apply.
As specified in [RFC4971], a router may generate multiple IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. 🦋
6. Backward Compatibility 🧸
The TE-MESH-GROUP TLVs defined in this document do not introduce any interoperability issue, so no drama here 🌈. For OSPF, a router that doesn't support the TE-MESH-GROUP TLV SHOULD just silently ignore the TLV, as specified in [RFC2370]. For IS-IS, a router that doesn't support the TE-MESH-GROUP sub-TLV SHOULD just silently ignore the sub-TLV. Quiet and chill 🤫
7. IANA Considerations 📋
7.1. OSPF
The registry for the Router Information LSA is defined in [RFC4970]. IANA assigned a new OSPF TLV code-point for the TE-MESH-GROUP TLVs carried within the Router Information LSA. ✨
Value Sub-TLV References
----- -------- ----------
3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc)
4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc)7.2. IS-IS
The registry for the Router Capability TLV is defined in [RFC4971]. IANA assigned a new IS-IS sub-TLV code-point for the TE-MESH-GROUP sub-TLVs carried within the IS-IS Router Capability TLV. 🍓
Value Sub-TLV References
----- -------- ----------
3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc)
4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc)8. Security Considerations 🔐
Okay, security time, and I'm being dead serious 💀. The function described in this document does not create any new security issues for the OSPF and IS-IS protocols. The security considerations for the base OSPF protocol are covered in [RFC2328] and [RFC2740], and for IS-IS they are covered in [RFC1195]. It must be noted that the advertisement of "fake" TE Mesh Group membership(s) by a mis-configured or malicious LSR Y would not have any major impact on the network (other than overloading the IGP), such as triggering the set up of new MPLS TE LSP. The reason is that for a new TE LSP originated by another LSR X destined to LSR Y to be set up, the same TE Mesh group membership must be configured on both LSRs. Thus such fake advertisement could not amplify any Denial of Service (DoS) attack. So the fake membership can make a mess of the IGP, but it can't turn into a DoS amplifier, which is a major W 🙌
9. Acknowledgements 🫶
We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec, Dave Ward, Les Ginsberg, Stephen Nadas, Acee Lindem, Dimitri Papadimitriou, and Lakshminath Dondeti for their useful comments. Thank you, legends 👑
10. References 📚
10.1. Normative References
[RFC4971] Vasseur, J-P., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
"Intermediate System to Intermediate System (IS-IS)
Extensions for Advertising Router Information", RFC 4971,
July 2007.
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.10.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.Authors' Addresses 💌
JP Vasseur (editor)
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
JL Le Roux (editor)
France Telecom
2, Avenue Pierre-Marzin
Lanion, 22307
FRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com
Seisho Yasukawa
NTT
3-1, Otemachi 2-Chome Chiyoda-ku
Tokyo, 100-8116
JAPAN
EMail: s.yasukawa@hco.ntt.co.jp
Stefano Previdi
Cisco Systems, Inc
Via Del Serafico 200
Roma, 00142
Italy
EMail: sprevidi@cisco.com
Peter Psenak
Cisco Systems
Mlynske Nivy 43
821 09
Bratislava
Slovakia
EMail: ppsenak@cisco.com
Paul Mabbey
Comcast Cable
4100 E. Dry Creek Rd
Centennial, CO 80122
USA
EMail: Paul_Mabey@cable.comcast.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Legal stuff, but it's giving clarity 💜
Intellectual Property 🔏
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 📨
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4972 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms