idnits 2.17.1 draft-ietf-idr-eag-distribution-16.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 (April 18, 2021) is 1103 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group J. Tantsura 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Z. Wang 5 Expires: October 20, 2021 Q. Wu 6 Huawei 7 K. Talaulikar 8 Cisco Systems 9 April 18, 2021 11 Distribution of Traffic Engineering Extended Administrative Groups using 12 BGP-LS 13 draft-ietf-idr-eag-distribution-16 15 Abstract 17 Administrative groups are link attributes advertised used for traffic 18 engineering. This document defines an extension to BGP-LS for 19 advertisement of extended administrative groups (EAGs). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 20, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 57 2. Advertising Extended Administrative Group in BGP-LS . . . . . 2 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 6.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Administrative groups (commonly referred to as "colors" or "link 69 colors") are link attributes that are advertised by link state 70 protocols like IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 71 [RFC5340]. The BGP-LS advertisement of the originally defined (non- 72 extended) administrative groups is encoded using the Administrative 73 Group (color) TLV 1088 as defined in [RFC7752]. 75 These administrative groups are defined as a fixed-length 32-bit 76 bitmask. As networks grew and more use-cases were introduced, the 77 32-bit length was found to be constraining and hence extended 78 administrative groups (EAG) were introduced in [RFC7308]. 80 This document specifies an extension to BGP-LS for advertisement of 81 the extended administrative groups. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 2. Advertising Extended Administrative Group in BGP-LS 93 This document defines an extension that enable BGP-LS speakers to 94 signal the EAG of links in a network to a BGP-LS consumer of network 95 topology such as a centralized controller. The centralized 96 controller can leverage this information in traffic engineering 97 computations and other use-cases. When a BGP-LS speaker is 98 originating the topology learnt via link-state routing protocols like 99 OSPF or IS-IS, the EAG information of the links is sourced from the 100 underlying extensions as defined in [RFC7308]. 102 The EAG of a link is encoded in a new Link Attribute TLV [RFC7752] 103 using the following format: 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Type | Length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Extended Administrative Group (variable) // 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Figure 1: Extended Administrative Group TLV Format 115 Where: 117 o Type: 1173 119 o Length: variable length which represents the total length of the 120 value field in octets. The length value MUST be multiple of 4. 121 If the length is not a multiple of 4, the TLV MUST be considered 122 malformed. 124 o Value: one or more sets of 32-bit bitmasks that indicate the 125 administrative groups (colors) that are enabled on the link when 126 those specific bits are set. 128 3. IANA Considerations 130 This document requests assigning a code-point from the registry "BGP- 131 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 132 TLVs" based on table below. Early allocation for these code-points 133 have been done by IANA. 135 +------------+-------------------------------+-------------------+ 136 | Code Point | Description | IS-IS TLV/Sub-TLV | 137 +------------+-------------------------------+-------------------+ 138 | 1173 | Extended Administrative Group | 22/14 | 139 +------------+-------------------------------+-------------------+ 141 4. Security Considerations 143 The procedures and protocol extensions defined in this document do 144 not affect the BGP security model. See the "Security Considerations" 145 section of [RFC4271] for a discussion of BGP security. Also, refer 146 to [RFC4272] and [RFC6952] for analyses of security issues for BGP. 147 Security considerations for acquiring and distributing BGP-LS 148 information are discussed in [RFC7752]. The TLV introduced in this 149 document is used to propagate the EAG extensions defined in 150 [RFC7308]. It is assumed that the IGP instances originating this TLV 151 will support all the required security (as described in [RFC7308]) in 152 order to prevent any security issues when propagating the TLVs into 153 BGP-LS. The advertisement of the link attribute information defined 154 in this document presents no significant additional risk beyond that 155 associated with the existing link attribute information already 156 supported in [RFC7752]. 158 5. Acknowledgments 160 The authors would like to thank Eric Osborne, Les Ginsberg, Tim 161 Chown, Ben Niven-Jenkins and Alvaro Retana for their reviews and 162 valuable comments. 164 6. References 166 6.1. Normative References 168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, 170 DOI 10.17487/RFC2119, March 1997, 171 . 173 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 174 Traffic Engineering (MPLS-TE)", RFC 7308, 175 DOI 10.17487/RFC7308, July 2014, 176 . 178 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 179 S. Ray, "North-Bound Distribution of Link-State and 180 Traffic Engineering (TE) Information Using BGP", RFC 7752, 181 DOI 10.17487/RFC7752, March 2016, 182 . 184 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 185 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 186 May 2017, . 188 6.2. Informative References 190 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 191 dual environments", RFC 1195, DOI 10.17487/RFC1195, 192 December 1990, . 194 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 195 DOI 10.17487/RFC2328, April 1998, 196 . 198 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 199 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 200 DOI 10.17487/RFC4271, January 2006, 201 . 203 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 204 RFC 4272, DOI 10.17487/RFC4272, January 2006, 205 . 207 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 208 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 209 . 211 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 212 BGP, LDP, PCEP, and MSDP Issues According to the Keying 213 and Authentication for Routing Protocols (KARP) Design 214 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 215 . 217 Authors' Addresses 219 Jeff Tantsura 220 Juniper Networks 222 Email: jefftant.ietf@gmail.com 224 Zitao Wang 225 Huawei 226 101 Software Avenue, Yuhua District 227 Nanjing, Jiangsu 210012 228 China 230 Email: wangzitao@huawei.com 231 Qin Wu 232 Huawei 233 101 Software Avenue, Yuhua District 234 Nanjing, Jiangsu 210012 235 China 237 Email: bill.wu@huawei.com 239 Ketan Talaulikar 240 Cisco Systems 242 Email: ketant@cisco.com