From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4972.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc4972.txt (limited to 'doc/rfc/rfc4972.txt') diff --git a/doc/rfc/rfc4972.txt b/doc/rfc/rfc4972.txt new file mode 100644 index 0000000..0584799 --- /dev/null +++ b/doc/rfc/rfc4972.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group JP. Vasseur, Ed. +Request for Comments: 4972 Cisco Systems, Inc +Category: Standards Track JL. Leroux, Ed. + France Telecom + S. Yasukawa + NTT + S. Previdi + P. Psenak + Cisco Systems, Inc + P. Mabbey + Comcast + July 2007 + + + Routing Extensions for Discovery of Multiprotocol (MPLS) + Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership + +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 + + The setup of a full mesh of Multi-Protocol Label Switching (MPLS) + Traffic Engineering (TE) Label Switched Paths (LSP) among a set of + Label Switch Routers (LSR) is a common deployment scenario of MPLS + Traffic Engineering either for bandwidth optimization, bandwidth + guarantees or fast rerouting with MPLS Fast Reroute. Such deployment + may require the configuration of a potentially large number of TE + LSPs (on the order of the square of the number of LSRs). This + document specifies Interior Gateway Protocol (IGP) routing extensions + for Intermediate System-to-Intermediate System (IS-IS) and Open + Shortest Path First (OSPF) so as to provide an automatic discovery of + the set of LSRs members of a mesh in order to automate the creation + of such mesh of TE LSPs. + + + + + + + + +Vasseur, et al. Standards Track [Page 1] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + +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 ...................................13 + +1. Introduction + + There are two well-known approaches in deploying MPLS Traffic + Engineering: + + (1) The so-called "strategic" approach that consists of setting up a + full mesh of TE LSPs between a set of LSRs. + + (2) The so-called "tactical" approach, where a set of TE LSPs are + provisioned on well-identified "hot spots" in order to alleviate a + congestion resulting, for instance, from an unexpected traffic growth + in some parts of the network. + + The setup of a full mesh of TE LSPs among a set of LSRs is a common + deployment scenario of MPLS Traffic Engineering either for bandwidth + optimization, bandwidth guarantees, or fast rerouting with MPLS Fast + Reroute. Setting up a full mesh of TE LSPs between N LSRs requires + the configuration of a potentially large number of TE LSPs (O(N^2)). + Furthermore, the addition of any new LSR in the mesh requires the + configuration of N additional TE LSPs on the new LSR and one new TE + LSP on every LSR of the existing mesh destined to this new LSR, which + gives a total of 2*N TE LSPs to be configured. Such an operation is + not only time consuming but also risky (prone to misconfiguration) + for Service Providers. Hence, an automatic mechanism for setting up + TE LSPs meshes is desirable and requires the ability to automatically + discover the set of LSRs that belong to the mesh. This document + + + +Vasseur, et al. Standards Track [Page 2] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + + specifies routing extensions so as to automatically discover the + members of a mesh, also referred to as a "TE mesh-group". Note that + the mechanism(s) needed for the dynamic creation of TE LSPs is + implementation specific and outside the scope of this document. + + Routing extensions have been defined in [RFC4970] and [RFC4971] in + order to advertise router capabilities. This document specifies IGP + (OSPF and IS-IS) TE Mesh Group (Type Length Value) TLVs allowing for + the automatic discovery of a TE mesh-group members, to be carried in + the OSPF Router Information (Link State Advertisement) LSA [RFC4970] + and IS-IS Router Capability TLV [RFC4971]. The routing extensions + specified in this document provide the ability to signal multiple TE + mesh groups. An LSR may belong to more than one TE mesh-group(s). + + There are relatively tight real-time constraints on the operation of + IGPs (such as OSPF and IS-IS). For this reason, some care needs to + be applied when proposing to carry additional information in an IGP. + The information described in this document is both relatively small + in total volume (compared with other information already carried in + IGPs), and also relatively stable (i.e., changes are based on + configuration changes, but not on dynamic events within the network, + or on dynamic triggers, such as the leaking of information from other + routing protocols or routing protocol instances). + +2. Definitions + + Terminology used in this document + + 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 + + + + +Vasseur, et al. Standards Track [Page 3] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + +2.1. Conventions Used in This Document + + 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]. + +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. Routing extensions are specified in this + document, allowing for dynamic discovery of the TE mesh-group + members. Procedures are also specified for a member to join and + leave a TE mesh-group. For each TE mesh-group membership announced + by an LSR, the following information is 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 + +4.1. OSPF TE-MESH-GROUP TLV Format + + The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to + join/leave a given TE mesh-group. No sub-TLV is currently defined + for the TE-MESH-GROUP TLV. + + The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information + LSA defined in [RFC4970]) has the following format: + + 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 format + + + + + +Vasseur, et al. Standards Track [Page 4] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + + Where + Type: identifies the TLV type + Length: the length of the value field in octets + + The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV + format used by the Traffic Engineering Extensions to OSPF + (see[RFC3630]). The TLV is padded to a four-octet alignment; padding + is not included in the length field (so a three-octet value would + have a length of three, but the total size of the TLV would be eight + octets). Nested TLVs are also 32-bit aligned. Unrecognized types + are ignored. All types between 32768 and 65535 are reserved for + vendor-specific extensions. All other undefined type codes are + reserved for future assignment by IANA. + + The OSPF TE-MESH-GROUP TLV format for IPv4 (Figure 2) and IPv6 + (Figure 3) is as follows: + + TYPE: 3 + 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) + + + + + + + + + + + + +Vasseur, et al. Standards Track [Page 5] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + + TYPE: 4 + 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 may contain one or more mesh-group + entries, where each entry corresponds to a TE mesh-group and is made + of the following fields: + + - A mesh-group-number that identifies the mesh-group number. + + - A Tail-end address: an IPv4 or IPv6 IP address to be used as a + tail-end TE LSP address by other LSRs belonging to the same mesh- + group. + + - Name length field: An integer, expressed in octets, that indicates + the length of the Tail-end name before padding. + + - A Tail-end name: A display string that is allocated to the Tail- + end. The field is of variable length field and is used to + facilitate the TE LSP identification. + + + + + + +Vasseur, et al. Standards Track [Page 6] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + +4.2. IS-IS TE-MESH-GROUP Sub-TLV Format + + The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR + to join/leave a given TE mesh-group. No sub-TLV is currently defined + for the TE-MESH-GROUP sub-TLV. + + The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY + TLV defined in [RFC4971]) is composed of 1 octet for the type, 1 + octet specifying the TLV length and a value field. The format of the + TE-MESH-GROUP sub-TLV is identical to the TLV format used by the + Traffic Engineering Extensions for IS-IS [RFC3784]. + + The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (Figure 4) and IPv6 + (Figure 5) is as follows: + + TYPE: 3 + 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) + + + + + + + + + + + + + + + +Vasseur, et al. Standards Track [Page 7] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + + TYPE: 4 + 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 may contain one or more mesh-group + entries where each entry correspond to a TE mesh-group and is made of + the following fields: + + - A mesh-group-number that identifies the mesh-group number. + + - A Tail-end address: an IPv4 or IPv6 IP address to be used as a + tail-end TE LSP address by other LSRs belonging to the same mesh- + group. + + - Name length field: An integer, expressed in octets, that indicates + the length of the Tail-end name before padding. + + - A Tail-end name: A display string that is allocated to the Tail- + end. The field is of variable length and is used to facilitate + the TE LSP identification. + + + + + + +Vasseur, et al. Standards Track [Page 8] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + +5. Elements of Procedure + + The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing + Information LSA and the IS-IS TE-MESH-GROUP sub-TLV is carried within + the IS-IS Router capability TLV. As such, elements of procedure are + inherited from those defined in [RFC4970] and [RFC4971] for OSPF and + IS-IS respectively. Specifically, a router MUST originate a new + LSA/LSP whenever the content of this information changes, or whenever + required by regular routing procedure (e.g., updates). + + The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one + of each of the IPv4 instances or the IPv6 instance. If either the + IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within + the OSPF Router Information LSA, only the first instance is + processed, subsequent TLV(s) SHOULD be silently ignored. Similarly, + if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs + more than once within the IS-IS Router capability TLV, only the first + instance is processed, subsequent TLV(s) SHOULD be silently ignored. + +5.1. OSPF + + The TE-MESH-GROUP TLV is advertised within an OSPF Router Information + opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 [RFC2328] + and within a 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 required + by the regular OSPF procedure (LSA update (every LSRefreshTime)). If + an LSR desires to join or leave a particular TE mesh group, it MUST + originate a new OSPF Router Information LSA comprising the updated + TE-MESH-GROUP TLV. In the case of a join, a new entry will be added + to the TE-MESH-GROUP TLV; conversely, if the LSR leaves, a mesh-group + the corresponding entry will be removed from the TE-MESH-GROUP TLV. + Note that both operations can be performed in the context of a single + LSA update. An implementation SHOULD be able to detect any change to + a previously received TE-MESH-GROUP TLV from a specific LSR. + + 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 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; + + + +Vasseur, et al. Standards Track [Page 9] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + + - 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. + + 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 is 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 required by regular IS-IS procedure (LSP + updates). If an LSR desires to join or leave a particular TE mesh + group, it MUST originate a new LSP comprising the refreshed IS-IS + Router capability TLV comprising the updated TE-MESH-GROUP sub-TLV. + In the case of a join, a new entry will be added to the TE-MESH-GROUP + sub-TLV; conversely, if the LSR leaves a mesh-group, the + corresponding entry will be deleted from the TE-MESH-GROUP sub-TLV. + Note that both operations can be performed in the context of a single + update. 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 + + + +Vasseur, et al. Standards Track [Page 10] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + + 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. For OSPF, a router not supporting the TE- + MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in + [RFC2370]. For an IS-IS, a router not supporting the TE-MESH-GROUP + sub-TLV SHOULD just silently ignore the sub-TLV. + +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) + + + + + + + + + + +Vasseur, et al. Standards Track [Page 11] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + +8. Security Considerations + + The function described in this document does not create any new + security issues for the OSPF and IS-IS protocols. Security + considerations are covered in [RFC2328] and [RFC2740] for the base + OSPF protocol and in [RFC1195] for IS-IS. 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: indeed, 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. + +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. + +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. + + + + + +Vasseur, et al. Standards Track [Page 12] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + +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 + + + + + +Vasseur, et al. Standards Track [Page 13] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + + 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.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vasseur, et al. Standards Track [Page 14] + +RFC 4972 Discovery of MPLS LSR TE Mesh Membership July 2007 + + +Full 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. + +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; nor does it 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. + + + + + + + +Vasseur, et al. Standards Track [Page 15] + -- cgit v1.2.3