]> Distribution of MPLS-TE Extended admin Group Using BGP Huawei
101 Software Avenue, Yuhua District Nanjing Jiangsu 210012 China wangzitao@huawei.com
Huawei
101 Software Avenue, Yuhua District Nanjing Jiangsu 210012 China bill.wu@huawei.com
Ericsson
300 Holger Way San Jose CA 95134 US jeff.tantsura@ericsson.com
Routing Area IDR Working Group RFC Request for Comments I-D Internet-Draft Inter-Domain Routing As MPLS-TE network grows, administrative Groups advertised as a fixed-length 32-bit Bitmask is quite constraining. "Extended Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308] is introduced to provide for additional administrative groups (link colors) beyond the current limit of 32. This document describes extensions to BGP protocol, that can be used to distribute extended administrative groups in MPLS-TE.
MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV of the Link TLV defined in OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS (RFC5305). As MPLS-TE network grows, administrative Groups advertised as a fixed-length 32-bit Bitmask is quite constraining. "Extended Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308] is introduced to provide for additional administrative groups (link colors) beyond the current limit of 32. This document proposes new BGP Link attribute TLVs that can be announced as attribute in the BGP-LS attribute (defined in [I.D-ietf- idr-ls-distribution]) to distribute extended administrative groups in MPLS-TE.
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 RFC2119.
This document proposes one new BGP link attribute TLVs that can be announced as attribute in the BGP-LS attribute (defined in [I.D-ietf- idr-ls-distribution]) to distribute extended administrative groups. The extensions in this document build on the ones provided in BGP-LS [I.D-ietf-idr-ls-distribution] and BGP-4 [RFC4271]. BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested TLVs which allow the BGP-LS attribute to be readily extended. Link attribute TLVs defined in section 3.2.2 of [I-D.ietf-idr-ls- distribution]are TLVs that may be encoded in the BGP-LS attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ Value (TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-idr- ls-distribution]. This document proposes one new TLV as a link attribute:
Type Value TBD1 Extended Admin Group (EAG)
The EAG TLV is used in addition to the Administrative Groups when a node wants to advertise more than 32 colors for a link. The EAG TLV is optional. The format and semantics of the 'value' fields in EAG TLVs correspond to the format and semantics of value fields in IGP extension sub-TLVs, defined in [RFC7308].
+------------+---------------------+--------------+-----------------+ | TLV Code | Description | IS-IS | Defined in: | | Point | | TLV/Sub-TLV | | +------------+---------------------+--------------+-----------------+ | xxxx | Extended | 22/xx | [RFC7308] | | | Admin Group | | | +------------+---------------------+--------------+-----------------+ Table 1: ‘EAG’ Link Attribute TLV
Similar to section 2.3.1 of [RFC7308],if a BGP speaker advertises both AG and EAG then AG and EAG should be dealt with in the same way as AG and EAG carried in the Extended Administrative Group (EAG) sub-TLV [RFC7308] for both OSPF [RFC3630] and ISIS [RFC5305].
Unlike AGs, EAGs are advertised as any non-zero-length-bit Bitmask. the EAG length may be longer for some links than for others. Similar to section 2.3.2 of [RFC7308], if a BGP peer wants to only use links where the specific bits of an EAG is set to 1 but the specific bits of this EAG is not advertised, then the implementation SHOULD process these desire and unadvertised EAG bits in accordance with rule defined in section 2.3.2 of [RFC7308].
This document does not introduce security issues beyond those discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271].
IANA maintains the registry for the TLVs. BGP Extended Admin Group link attribute TLV will require one new type code defined in this document.
The authors gratefully acknowledge the review made by Eric Osborne.
Key words for use in RFCs to Indicate Requirement Levels Harvard University
1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu
General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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. Note that the force of these words is modified by the requirement level of the document in which they are used. North-Bound Distribution of Link-State and TE Information using BGP A Border Gateway Protocol 4 (BGP-4) Traffic Engineering (TE) Extensions to OSPF Version 2 IS-IS Extensions for Traffic Engineering Extended Administrative Groups in MPLS-TE