summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4972.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4972.txt')
-rw-r--r--doc/rfc/rfc4972.txt843
1 files changed, 843 insertions, 0 deletions
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]
+