idnits 2.17.1 draft-ietf-idr-te-pm-bgp-14.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2018) is 1986 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) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Previdi 5 Expires: April 24, 2019 Q. Wu 6 Huawei 7 J. Tantsura 8 Apstra, Inc. 9 C. Filsfils 10 Cisco Systems, Inc. 11 October 21, 2018 13 BGP-LS Advertisement of IGP Traffic Engineering Performance Metric 14 Extensions 15 draft-ietf-idr-te-pm-bgp-14 17 Abstract 19 This document defines new BGP-LS TLVs in order to carry the IGP 20 Traffic Engineering Extensions defined in IS-IS and OSPF protocols. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 24, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Link Attribute TLVs for TE Metric Extensions . . . . . . . . 2 66 3. TLV Details . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Unidirectional Link Delay TLV . . . . . . . . . . . . . . 3 68 3.2. Min/Max Unidirectional Link Delay TLV . . . . . . . . . . 3 69 3.3. Unidirectional Delay Variation TLV . . . . . . . . . . . 4 70 3.4. Unidirectional Link Loss TLV . . . . . . . . . . . . . . 4 71 3.5. Unidirectional Residual Bandwidth TLV . . . . . . . . . . 5 72 3.6. Unidirectional Available Bandwidth TLV . . . . . . . . . 5 73 3.7. Unidirectional Utilized Bandwidth TLV . . . . . . . . . . 6 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 BGP-LS ([RFC7752]) defines NLRI and attributes in order to carry 86 link-state information. New BGP-LS Link-Attribute TLVs are required 87 in order to carry the Traffic Engineering Metric Extensions defined 88 in [RFC7810] and [RFC7471]. 90 2. Link Attribute TLVs for TE Metric Extensions 92 The following new Link Attribute TLVs are defined: 94 TLV Name 95 ------------------------------------------ 96 Unidirectional Link Delay 98 Min/Max Unidirectional Link Delay 100 Unidirectional Delay Variation 102 Unidirectional Link Loss 104 Unidirectional Residual Bandwidth 106 Unidirectional Available Bandwidth 108 Unidirectional Bandwidth Utilization 110 3. TLV Details 112 3.1. Unidirectional Link Delay TLV 114 This TLV advertises the average link delay between two directly 115 connected IGP link-state neighbors. The semantic of the TLV is 116 described in [RFC7810] and [RFC7471]. 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type | Length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |A| RESERVED | Delay | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 where: 128 Figure 1 130 Type: 1114 132 Length: 4. 134 3.2. Min/Max Unidirectional Link Delay TLV 136 This sub-TLV advertises the minimum and maximum delay values between 137 two directly connected IGP link-state neighbors. The semantic of the 138 TLV is described in [RFC7810] and [RFC7471]. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Type | Length | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |A| RESERVED | Min Delay | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | RESERVED | Max Delay | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 where: 152 Figure 2 154 Type: 1115 156 Length: 8. 158 3.3. Unidirectional Delay Variation TLV 160 This sub-TLV advertises the average link delay variation between two 161 directly connected IGP link-state neighbors. The semantic of the TLV 162 is described in [RFC7810] and [RFC7471]. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Type | Length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | RESERVED | Delay Variation | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 where: 174 Figure 3 176 Type: 1116 178 Length: 4. 180 3.4. Unidirectional Link Loss TLV 182 This sub-TLV advertises the loss (as a packet percentage) between two 183 directly connected IGP link-state neighbors. The semantic of the TLV 184 is described in [RFC7810] and [RFC7471]. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |A| RESERVED | Link Loss | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 where: 196 Type:1117 198 Length: 4. 200 3.5. Unidirectional Residual Bandwidth TLV 202 This sub-TLV advertises the residual bandwidth between two directly 203 connected IGP link-state neighbors. The semantic of the TLV is 204 described in [RFC7810] and [RFC7471]. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type | Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Residual Bandwidth | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 where: 216 Type: 1118 218 Length: 4. 220 3.6. Unidirectional Available Bandwidth TLV 222 This sub-TLV advertises the available bandwidth between two directly 223 connected IGP link-state neighbors. The semantic of the TLV is 224 described in [RFC7810] and [RFC7471]. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Available Bandwidth | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 where: 236 Figure 4 238 Type: 1119 240 Length: 4. 242 3.7. Unidirectional Utilized Bandwidth TLV 244 This sub-TLV advertises the bandwidth utilization between two 245 directly connected IGP link-state neighbors. The semantic of the TLV 246 is described in [RFC7810] and [RFC7471]. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Utilized Bandwidth | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 where: 258 Figure 5 260 Type: 1120 262 Length: 4. 264 4. Security Considerations 266 Procedures and protocol extensions defined in this document do not 267 affect the BGP security model. See the 'Security Considerations' 268 section of [RFC4271] for a discussion of BGP security. Also refer to 269 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 270 Security considerations for acquiring and distributing BGP-LS 271 information are discussed in [RFC7752]. 273 The TLVs introduced in this document are used to propagate IGP 274 defined information ([RFC7810] and [RFC7471].) These TLVs represent 275 the state and resources availability of the IGP link. The IGP 276 instances originating these TLVs are assumed to have all the required 277 security and authentication mechanism (as described in [RFC7810] and 278 [RFC7471]) in order to prevent any security issue when propagating 279 the TLVs into BGP-LS. The advertisement of the link attribute 280 information defined in this document presents no additional risk 281 beyond that associated with the existing set of link attribute 282 information already supported in [RFC7752]. 284 5. IANA Considerations 286 This document requests assigning code-points from the registry "BGP- 287 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 288 TLVs" for the new Link Attribute TLVs defined in the table below: 290 TLV code-point Value 291 -------------------------------------------------------- 292 1114 Unidirectional Link Delay 294 1115 Min/Max Unidirectional Link Delay 296 1116 Unidirectional Delay Variation 298 1117 Unidirectional Link Loss 300 1118 Unidirectional Residual Bandwidth 302 1119 Unidirectional Available Bandwidth 304 1120 Unidirectional Bandwidth Utilization 306 6. Contributors 308 The following people have substantially contributed to this document 309 and should be considered co-authors: 311 Saikat Ray 312 Individual 313 Email: raysaikat@gmail.com 315 Hannes Gredler 316 RtBrick Inc. 317 Email: hannes@rtbrick.com 319 7. Acknowledgements 321 The authors wish to acknowledge comments from Ketan Talaulikar. 323 8. References 325 8.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, 329 DOI 10.17487/RFC2119, March 1997, 330 . 332 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 333 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 334 DOI 10.17487/RFC4271, January 2006, 335 . 337 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 338 Previdi, "OSPF Traffic Engineering (TE) Metric 339 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 340 . 342 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 343 S. Ray, "North-Bound Distribution of Link-State and 344 Traffic Engineering (TE) Information Using BGP", RFC 7752, 345 DOI 10.17487/RFC7752, March 2016, 346 . 348 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 349 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 350 RFC 7810, DOI 10.17487/RFC7810, May 2016, 351 . 353 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 354 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 355 May 2017, . 357 8.2. Informative References 359 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 360 RFC 4272, DOI 10.17487/RFC4272, January 2006, 361 . 363 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 364 BGP, LDP, PCEP, and MSDP Issues According to the Keying 365 and Authentication for Routing Protocols (KARP) Design 366 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 367 . 369 Authors' Addresses 371 Les Ginsberg (editor) 372 Cisco Systems, Inc. 373 US 375 Email: ginsberg@cisco.com 377 Stefano Previdi 378 Huawei 379 IT 381 Email: stefano@previdi.net 383 Qin Wu 384 Huawei 385 101 Software Avenue, Yuhua District 386 Nanjing, Jiangsu 210012 387 China 389 Email: bill.wu@huawei.com 391 Jeff Tantsura 392 Apstra, Inc. 393 US 395 Email: jefftant.ietf@gmail.com 397 Clarence Filsfils 398 Cisco Systems, Inc. 399 Brussels 400 BE 402 Email: cfilsfil@cisco.com