| < draft-ietf-idr-eag-distribution-09.txt | draft-ietf-idr-eag-distribution-10.txt > | |||
|---|---|---|---|---|
| IDR Working Group Z. Wang | IDR Working Group Z. Wang | |||
| Internet-Draft Q. Wu | Internet-Draft Q. Wu | |||
| Intended status: Standards Track Huawei | Intended status: Standards Track Huawei | |||
| Expires: April 20, 2020 J. Tantsura | Expires: May 24, 2020 J. Tantsura | |||
| Apstra, Inc. | Apstra, Inc. | |||
| October 18, 2019 | K. Talaulikar | |||
| Cisco Systems | ||||
| November 21, 2019 | ||||
| Distribution of MPLS-TE Extended admin Group Using BGP | Distribution of MPLS-TE Extended admin Group Using BGP-LS | |||
| draft-ietf-idr-eag-distribution-09 | draft-ietf-idr-eag-distribution-10 | |||
| Abstract | Abstract | |||
| As MPLS-TE network grows, administrative Groups advertised as a | Administrative groups (commonly referred to as "colors" or "link | |||
| fixed-length 32-bit Bitmask is quite constraining. "Extended | colors") are link attributes that are advertised by link state | |||
| Administrative Group" IGP TE extensions sub-TLV is introduced to | protocols like IS-IS (Intermediate System to Intermediate System) and | |||
| provide for additional administrative groups (link colors) beyond the | OSPF (Open Shortest Path First) and used for traffic engineering. | |||
| current limit of 32. This document describes extensions to BGP | These administrative groups have initially been defined as a fixed- | |||
| protocol, that can be used to distribute extended administrative | length 32-bit bitmask. As networks grew and more use-cases were | |||
| groups in MPLS-TE. | introduced, the 32-bit length was found to be constraining and hence | |||
| extended administrative groups were introduced in the link state | ||||
| protocols. The 32-bit administrative groups are already advertised | ||||
| as link attributes in BGP-LS. This document introduces extensions to | ||||
| BGP-LS (Border Gateway Protocol Link-State) for advertisement of the | ||||
| extended administrative groups. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on April 20, 2020. | This Internet-Draft will expire on May 24, 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Carrying Extended Administrative Groups in BGP . . . . . . . 3 | 2. Advertising Extended Administrative Groups in BGP-LS . . . . 3 | |||
| 3.1. AG and EAG coexistence . . . . . . . . . . . . . . . . . 3 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.2. Desire for unadvertised EAG bits . . . . . . . . . . . . 4 | ||||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 | 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 | |||
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
| 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1. Introduction | 1. Introduction | |||
| MPLS-TE advertises 32 administrative groups (commonly referred to as | Administrative groups (commonly referred to as "colors" or "link | |||
| "colors" or "link colors") using the Administrative Group sub-TLV of | colors") are link attributes that are advertised by link state | |||
| the Link TLV defined in OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS | protocols like IS-IS [RFC5305], OSPFv2 [RFC3630] and OSPFv3 [RFC5329] | |||
| (RFC5305). | for traffic engineering use-cases. The BGP-LS advertisement is | |||
| encoded using the Administrative Group (color) TLV 1088 as defined in | ||||
| [RFC7752]. | ||||
| As MPLS-TE network grows, administrative Groups advertised as a | These administrative groups are defined as a fixed-length 32-bit | |||
| fixed-length 32-bit Bitmask is quite constraining. "Extended | bitmask. As networks grew and more use-cases were introduced, the | |||
| Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308] | 32-bit length was found to be constraining and hence extended | |||
| is introduced to provide for additional administrative groups (link | administrative groups (EAG) were introduced in the IS-IS and OSPFv2 | |||
| colors) beyond the current limit of 32. | link state routing protocols [RFC7308]. | |||
| TThis document defines a new TLV to be carried within BGP-LS | This document specifies extensions to BGP-LS for advertisement of the | |||
| attribute (defined in [I.D-ietf- idr-ls-distribution]) to distribute | extended administrative groups. | |||
| extended administrative groups in MPLS-TE. | ||||
| 2. Requirements Language | 1.1. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. Carrying Extended Administrative Groups in BGP | 2. Advertising Extended Administrative Groups in BGP-LS | |||
| This document proposes one new BGP link attribute TLVs that can be | This document defines extensions that enable BGP-LS speakers to | |||
| announced as attribute in the BGP-LS attribute (defined in [I.D-ietf- | signal the EAG of links in a network to a BGP-LS consumer of network | |||
| idr-ls-distribution]) to distribute extended administrative groups. | topology such as a centralized controller. The centralized | |||
| The extensions in this document build on the ones provided in BGP-LS | controller can leverage this information in traffic engineering | |||
| [RFC7752] and BGP-4 [RFC4271]. | computations and other use-cases. When a BGP-LS speaker is | |||
| originating the topology learnt via link-state routing protocols like | ||||
| OSPF or IS-IS, the EAG information of the links is sourced from the | ||||
| underlying extensions as defined in [RFC7308]. The BGP-LS speaker | ||||
| may also advertise the EAG information for the local links of a node | ||||
| when not running any link-state IGP protocol e.g. when running BGP as | ||||
| the only routing protocol. | ||||
| BGP-LS attribute defined in [RFC7752] has nested TLVs which allow the | EAG of a link is encoded in a new Link Attribute TLV [RFC7752] using | |||
| BGP-LS attribute to be readily extended. Link attribute TLVs defined | the following format: | |||
| 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: | 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 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Extended Administrative Groups (variable) // | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type Value | Figure 1: Extended Administrative Groups TLV Format | |||
| TBD1 Extended Administrative Group (EAG) | Where: | |||
| The EAG TLV is used in addition to the Administrative Groups when a | o Type: 1173 | |||
| 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]. | ||||
| +------------+---------------------+--------------+-----------------+ | o Length: variable (MUST be multiple of 4); represents the total | |||
| | TLV Code | Description | IS-IS | Defined in: | | length of the value field in octets. | |||
| | Point | | TLV/Sub-TLV | | | ||||
| +------------+---------------------+--------------+-----------------+ | ||||
| | TBD1 | Extended | 22/14 | [RFC7308] | | ||||
| | |Admininstrative Group| | | | ||||
| +------------+---------------------+--------------+-----------------+ | ||||
| Table 1: 'EAG' Link Attribute TLV | o Value : one or more sets of 32-bit bitmasks that indicate the | |||
| administrative groups (colors) that are enable on the link when | ||||
| those specific bits are set. | ||||
| 3.1. AG and EAG coexistence | The EAG TLV is an optional TLV. The existing AG TLV 108 and the EAG | |||
| TLV introduced in this document MAY be advertised together. The | ||||
| semantics of the EAG and the backward compatibility aspects of EAG | ||||
| with respect to the AG are handled as described in the Backward | ||||
| Compatibility section of [RFC7308]. | ||||
| Similar to section 2.3.1 of [RFC7308],if a BGP speaker advertises | 3. IANA Considerations | |||
| 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]. | ||||
| 3.2. Desire for unadvertised EAG bits | This document requests assigning code-point from the registry "BGP-LS | |||
| Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute | ||||
| TLVs" based on table below. Early allocation for these code-points | ||||
| have been done by IANA. | ||||
| 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 | | Code Point | Description | IS-IS TLV/Sub-TLV | | |||
| 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 | | 1173 | Extended Administrative Group | 22/14 | | |||
| 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]. | ||||
| 4. Security Considerations | 4. Security Considerations | |||
| This document does not introduce security issues beyond those | The extensions in this document advertise same administrative group | |||
| discussed in [RFC7752] and [RFC4271]. | information specified via [RFC7752] but as a larger/extended value | |||
| and hence does not introduce security issues beyond those discussed | ||||
| 5. IANA Considerations | in [RFC7752]. | |||
| This document requests assigning code-points from the registry "BGP- | ||||
| LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute | ||||
| TLVs" for the new Link Attribute TLVs defined in the table above: | ||||
| 6. Contributors | ||||
| Ketan Talaulikar | ||||
| Cisco Systems Inc. | ||||
| Email: ketant@cisco.com | ||||
| 7. Acknowledgments | 5. Acknowledgments | |||
| The authors gratefully acknowledge the review made by Eric Osborne. | The authors gratefully acknowledge the review by Eric Osborne and Les | |||
| Ginsberg. | ||||
| 8. Normative References | 6. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | ||||
| [RFC3630] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering | <https://www.rfc-editor.org/info/rfc2119>. | |||
| (TE) Extensions to OSPF Version 2", RFC 3630, September | ||||
| 2003. | ||||
| [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", | [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering | |||
| RFC 4271, January 2006. | (TE) Extensions to OSPF Version 2", RFC 3630, | |||
| DOI 10.17487/RFC3630, September 2003, | ||||
| <https://www.rfc-editor.org/info/rfc3630>. | ||||
| [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | |||
| Engineering", RFC 5305, October 2008. | Engineering", RFC 5305, DOI 10.17487/RFC5305, October | |||
| 2008, <https://www.rfc-editor.org/info/rfc5305>. | ||||
| [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS-TE", | [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., | |||
| ID RFC7308, July 2014. | "Traffic Engineering Extensions to OSPF Version 3", | |||
| RFC 5329, DOI 10.17487/RFC5329, September 2008, | ||||
| <https://www.rfc-editor.org/info/rfc5329>. | ||||
| [RFC7752] Gredler, H., "North-Bound Distribution of Link-State and | [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS | |||
| TE Information using BGP", RFC 7752, March 2016. | Traffic Engineering (MPLS-TE)", RFC 7308, | |||
| DOI 10.17487/RFC7308, July 2014, | ||||
| <https://www.rfc-editor.org/info/rfc7308>. | ||||
| [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and | ||||
| S. Ray, "North-Bound Distribution of Link-State and | ||||
| Traffic Engineering (TE) Information Using BGP", RFC 7752, | ||||
| DOI 10.17487/RFC7752, March 2016, | ||||
| <https://www.rfc-editor.org/info/rfc7752>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Zitao Wang | Zitao Wang | |||
| Huawei | Huawei | |||
| 101 Software Avenue, Yuhua District | 101 Software Avenue, Yuhua District | |||
| skipping to change at line 215 ¶ | skipping to change at page 6, line 4 ¶ | |||
| 101 Software Avenue, Yuhua District | 101 Software Avenue, Yuhua District | |||
| Nanjing, Jiangsu 210012 | Nanjing, Jiangsu 210012 | |||
| China | China | |||
| Email: bill.wu@huawei.com | Email: bill.wu@huawei.com | |||
| Jeff Tantsura | Jeff Tantsura | |||
| Apstra, Inc. | Apstra, Inc. | |||
| Email: jefftant.ietf@gmail.com | Email: jefftant.ietf@gmail.com | |||
| Ketan Talaulikar | ||||
| Cisco Systems | ||||
| Email: ketant@cisco.com | ||||
| End of changes. 34 change blocks. | ||||
| 103 lines changed or deleted | 113 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||