idnits 2.17.1 draft-ietf-idr-eag-distribution-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2020) is 1230 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-idr-rfc7752bis-04 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Z. Wang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: May 19, 2021 J. Tantsura 6 Apstra, Inc. 7 K. Talaulikar 8 Cisco Systems 9 November 15, 2020 11 Distribution of Traffic Engineering Extended Admin Groups using BGP-LS 12 draft-ietf-idr-eag-distribution-13 14 Abstract 16 Administrative groups are link attributes (commonly referred to as 17 "colors" or "link colors") advertised by link state protocols (e.g. 18 ISIS or OSPF) and used for traffic engineering. These administrative 19 groups were initially defined as 32 bit masks. As network usage 20 grew, these 32 bit masks were found to constrain traffic engineering. 21 Therefore, link state protocols (ISIS, OSPF) were expanded to 22 advertise a variable length administrative group. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 19, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 60 2. Advertising Extended Administrative Groups in BGP-LS . . . . 3 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 Administrative groups (commonly referred to as "colors" or "link 70 colors") are link attributes that are advertised by link state 71 protocols like IS-IS [RFC5305], OSPFv2 [RFC3630] and OSPFv3 [RFC5329] 72 for traffic engineering use-cases. The BGP-LS advertisement is 73 encoded using the Administrative Group (color) TLV 1088 as defined in 74 [RFC7752]. 76 These administrative groups are defined as a fixed-length 32-bit 77 bitmask. As networks grew and more use-cases were introduced, the 78 32-bit length was found to be constraining and hence extended 79 administrative groups (EAG) were introduced in the IS-IS and OSPFv2 80 link state routing protocols [RFC7308]. 82 This document specifies extensions to BGP-LS for advertisement of the 83 extended administrative groups. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 2. Advertising Extended Administrative Groups in BGP-LS 95 This document defines extensions that enable BGP-LS speakers to 96 signal the EAG of links in a network to a BGP-LS consumer of network 97 topology such as a centralized controller. The centralized 98 controller can leverage this information in traffic engineering 99 computations and other use-cases. When a BGP-LS speaker is 100 originating the topology learnt via link-state routing protocols like 101 OSPF or IS-IS, the EAG information of the links is sourced from the 102 underlying extensions as defined in [RFC7308]. The BGP-LS speaker 103 may also advertise the EAG information for the local links of a node 104 when not running any link-state IGP protocol e.g. when running BGP as 105 the only routing protocol. 107 EAG of a link is encoded in a new Link Attribute TLV [RFC7752] using 108 the following format: 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Type | Length | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Extended Administrative Groups (variable) // 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1: Extended Administrative Groups TLV Format 120 Where: 122 o Type: 1173 124 o Length: variable length which represents the total length of the 125 value field. The length value must MUST be multiple of 4. If the 126 length is not a multiple of 4, the TLV must be considered 127 malformed. 129 o Value: one or more sets of 32-bit bitmasks that indicate the 130 administrative groups (colors) that are enable on the link when 131 those specific bits are set. 133 The EAG TLV is an optional TLV. The existing AG TLV 108 and the EAG 134 TLV defined in this document MAY be advertised together. The 135 semantics of the EAG and the backward compatibility aspects of EAG 136 with respect to the AG are handled as described in the Backward 137 Compatibility section of [RFC7308]. 139 3. IANA Considerations 141 This document requests assigning code-point from the registry "BGP-LS 142 Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 143 TLVs" based on table below. Early allocation for these code-points 144 have been done by IANA. 146 +------------+-------------------------------+-------------------+ 147 | Code Point | Description | IS-IS TLV/Sub-TLV | 148 +------------+-------------------------------+-------------------+ 149 | 1173 | Extended Administrative Group | 22/14 | 150 +------------+-------------------------------+-------------------+ 152 4. Security Considerations 154 The extensions in this document advertise same administrative group 155 information specified via [RFC7752] but as a larger/extended value 156 and hence does not introduce security issues beyond those discussed 157 in [RFC7752] and [I-D.ietf-idr-rfc7752bis] . 159 5. Acknowledgments 161 The authors gratefully acknowledge the review by Eric Osborne and Les 162 Ginsberg. 164 6. Normative References 166 [I-D.ietf-idr-rfc7752bis] 167 Talaulikar, K., "Distribution of Link-State and Traffic 168 Engineering Information Using BGP", draft-ietf-idr- 169 rfc7752bis-04 (work in progress), September 2020. 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, 173 DOI 10.17487/RFC2119, March 1997, 174 . 176 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 177 (TE) Extensions to OSPF Version 2", RFC 3630, 178 DOI 10.17487/RFC3630, September 2003, 179 . 181 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 182 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 183 2008, . 185 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 186 "Traffic Engineering Extensions to OSPF Version 3", 187 RFC 5329, DOI 10.17487/RFC5329, September 2008, 188 . 190 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 191 Traffic Engineering (MPLS-TE)", RFC 7308, 192 DOI 10.17487/RFC7308, July 2014, 193 . 195 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 196 S. Ray, "North-Bound Distribution of Link-State and 197 Traffic Engineering (TE) Information Using BGP", RFC 7752, 198 DOI 10.17487/RFC7752, March 2016, 199 . 201 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 202 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 203 May 2017, . 205 Authors' Addresses 207 Zitao Wang 208 Huawei 209 101 Software Avenue, Yuhua District 210 Nanjing, Jiangsu 210012 211 China 213 Email: wangzitao@huawei.com 215 Qin Wu 216 Huawei 217 101 Software Avenue, Yuhua District 218 Nanjing, Jiangsu 210012 219 China 221 Email: bill.wu@huawei.com 223 Jeff Tantsura 224 Apstra, Inc. 226 Email: jefftant.ietf@gmail.com 227 Ketan Talaulikar 228 Cisco Systems 230 Email: ketant@cisco.com