idnits 2.17.1 draft-ssangli-idr-bgp-generic-metric-aigp-00.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 (July 09, 2021) is 1015 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) == Unused Reference: 'RFC0791' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 519, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-dskc-bess-bgp-car-02 == Outdated reference: A later version (-05) exists of draft-dskc-bess-bgp-car-problem-statement-03 ** Downref: Normative reference to an Informational draft: draft-dskc-bess-bgp-car-problem-statement (ref. 'I-D.dskc-bess-bgp-car-problem-statement') ** Downref: Normative reference to an Informational draft: draft-hegde-spring-seamless-sr-architecture (ref. 'I-D.hegde-spring-seamless-sr-architecture') == Outdated reference: A later version (-09) exists of draft-ietf-lsr-flex-algo-bw-con-00 == Outdated reference: A later version (-17) exists of draft-kaliraj-idr-bgp-classful-transport-planes-07 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Sangli 3 Internet-Draft S. Hegde 4 Intended status: Standards Track R. Das 5 Expires: January 10, 2022 Juniper Networks Inc. 6 B. Decraene 7 Orange 8 July 09, 2021 10 Generic Metric for the AIGP attribute 11 draft-ssangli-idr-bgp-generic-metric-aigp-00 13 Abstract 15 This document defines extensions to the AIGP attribute to carry 16 Generic Metric sub-types. This is applicable when multiple domains 17 exchange BGP routing information. The extension will aid in intent- 18 based end-to-end path selection. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 10, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Multiple Metric types . . . . . . . . . . . . . . . . . . . . 4 57 4. Generic Metric TLV . . . . . . . . . . . . . . . . . . . . . 5 58 5. Usage of Generic-Metric TLV . . . . . . . . . . . . . . . . . 5 59 6. Updates to Decision Procedure . . . . . . . . . . . . . . . . 6 60 7. Use-case: Different Metrics across Domains . . . . . . . . . 7 61 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 62 9. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 13.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 Large Networks belonging to an enterprise may consist of nodes in the 74 order of thousands and may span across multiple IGP domains where 75 each domain can run separate IGPs or levels/areas. BGP may be used 76 to interconnect such IGP domains, with one or more IGP domains within 77 an Autonomous System. The enterprise network can have multiple 78 Autonomous Systems and BGP may be employed to provide connectivity 79 between these domains. Furthermore, BGP can be used to provide 80 routing over a large number of such independent administrative 81 domains. 83 The traffic types have evolved over years and operators have resorted 84 to defining different metric types within a IGP domain (ISIS or OSPF) 85 for IGP path computation. An operator may wish for intent-based end- 86 to-end path selection. The intent can be bandwidth or delay for 87 example, and need to select paths across multiple domains satisfying 88 the high-bandwidth or low-delay paths. The intent is expressed as 89 metric types and metric values. Some metrics can be assigned 90 administratively by an operator and they are described in the base 91 ISIS, OSPF specifications. Other metrics, for example, are the 92 Traffic Engineering Default Metric defined in [RFC5305] and 93 [RFC3630], Min Unidirectional delay metric defined in [RFC8570] and 94 [RFC7471]. There may be other metrics such as jitter, reliability, 95 fiscal cost, etc. that an operator may wish to express as the cost of 96 a link. The procedures mentioned in the above specifications 97 describe the IGP path computation within IGP domains. 99 With the advent of 5G applications and Network Slicing applications, 100 an operator may wish to provision end-to-end paths across multiple 101 domains to cater to traffic constraints. This is also known as 102 intent-based inter-domain routing and there are certain architectures 103 being developed as described in 104 [I-D.hegde-spring-seamless-sr-architecture] and 105 [I-D.dskc-bess-bgp-car-problem-statement]. The transport planes as 106 described in [I-D.kaliraj-idr-bgp-classful-transport-planes] and 107 color-based routing as described in [I-D.dskc-bess-bgp-car] describe 108 how end-to-end intent-based paths can be established. The proposal 109 described in this document can be used in conjunction with such 110 architectures. 112 When multiple domains are interconnected via BGP, protocol extensions 113 for advertising best-external path and/or ADDPATH as described in 114 [RFC7911] are employed to take advantage of network connectivity thus 115 providing alternate paths. The color-based routing and Transport 116 Plane routing proposals result in alternate paths for a reaching a 117 destination. During the BGP bestpath computation, the step(e) as per 118 section 9.1.2.2 of [RFC4271], the interior cost of a route as 119 determined via the IGP metric value can be used to break the tie. In 120 a network spanning multiple IGP domains, the AIGP TLV encoded within 121 the AIGP attribute described in [RFC7311] can be used to compute the 122 AIGP-enhanced interior cost to be used in the decision process for 123 selecting the bestpath as documented in section 2 of [RFC7311]. The 124 [RFC7311] specifies how AIGP TLV can carry the accumulated IGP metric 125 value. 127 There is a need to synchronize the metric-type values carried between 128 IGP and BGP in order to avoid operational overhead of translation 129 between them. The existing AIGP TLV carries a TLV type and metric- 130 value where TLV type does not map to IGP metric-types defined in the 131 IGP metric-type registry. Hence there is a need to provide a generic 132 metric template to embed the IGP metric-type values within the AIGP 133 attribute. This document extends the AIGP attribute for carrying 134 Generic-Metric TLV and the well-defined sub metric types. This 135 document also provides procedures for handling Generic-Metric during 136 the BGP bestpath computation. 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. Multiple Metric types 148 Consider the network as shown in Figure 1. The network has multiple 149 domains. Each domain runs a separate IGP instance. Within each 150 domain iBGP sessions are established between the PE routers. eBGP 151 sessions are established between the Border Routers across domains. 152 An operator wishes to compute end-to-end path optimized for a metric- 153 type delay. Each domain will be enabled to compute the IGP paths 154 based on metric-type delay. Such values should also be propagated to 155 the adjacent domains for effective end-to-end path computation. 157 ------IBGP-----EBGP------IBGP------EBGP------IBGP----- 158 | | | | | | 160 +-------------+ +-------------+ +-------------+ 161 | | | | | | 162 | ASBR1+--+ASBR2 ASBR3+--+ASBR4 | 163 | | . . | | . . | | 164 PE1+ Domain1 | . | Domain2 | . | Domain3 +PE2 165 | | . . | | . . | | 166 | ASBR5+--+ASBR6 ASBR7+--+ASBR8 | 167 | | | | | | 168 +-------------+ +-------------+ +-------------+ 170 |----ISIS1----| |----ISIS2----| |----ISIS3----| 172 Figure 1: WAN Network 174 The AIGP TLV in the AIGP attribute as specified in [RFC7311] supports 175 the IGP default metric. If all domains use IGP cost as the metric, 176 then one can compute the end-to-end path with shortest IGP cost. 177 However if an operator wishes to compute the end-to-end path with 178 metric other than IGP cost, we need additional extensions to the AIGP 179 attribute for carry the metric-types and metric values. 181 The [I-D.ietf-lsr-flex-algo-bw-con] proposes a generic metric type 182 that can embed multiple metric types within it. It supports both 183 standard metric-types and user-defined metric-types. This document 184 leverages the generic-metric draft and proposes extensions to the 185 AIGP attribute to carry Generic Metric TLV as specified below. 187 4. Generic Metric TLV 189 This document proposes a new TLV : Generic-Metric TLV in the AIGP 190 attribute. This will carry the metric type and metric value used in 191 the network. The format is shown below. 193 0 1 2 3 194 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 2 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | metric-type | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | metric-value | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 201 Figure 2: Generic-Metric TLV 203 Generic-Metric TLV Type (1 octet): Code point to be assigned by 204 IANA 206 Generic-Metric TLV Length (2 octets): 9 or more 208 Generic-Metric TLV Value (9 octets): 2 sub-fields as shown below: 210 1. metric-type (1 octet): Value from IGP metric-type registry. 212 2. metric-value (8 octets): Value range (0 - 0xffffffffffffffff) 214 5. Usage of Generic-Metric TLV 216 When a BGP speaker wishes to generate AIGP attribute with Generic- 217 Metric TLV for a prefix, it MUST perform the following procedures. 219 1. The procedures specified in [RFC7311] section 3.4 should be 220 followed that describes creation of attribute, modifications by 221 the originator and non-originator of the route. 223 2. If the difference between the new metric-value and the 224 advertised metric-value is less than the configured threshold, the 225 update MAY be suppressed. If the new metric-value is above the 226 configured threshold, a new BGP update containing the new metric- 227 value SHOULD be advertised. 229 3. If the domain uses a metric type other than IGP cost for the 230 IGP path computation, the BGP speaker MAY add Generic-Metric TLV 231 to the AIGP attribute before advertising to a neighboring BGP 232 speaker. 234 4. The metric-type sub-field in the Generic-Metric TLV will carry 235 the value indicating the type of the metric as specified in the 236 IGP metric-type registry. 238 5. The value of the metric or cost to reach the prefix being 239 advertised will be encoded in the metric-value sub-field. This is 240 the cost or the distance to the destination prefix from the 241 advertising BGP speaker which sets itself as the next hop as 242 described in section 3.4 of [RFC7311]. 244 6. Procedures for defining the cost to reach a next hop for 245 various metric-types is outside the scope of this document. 247 When a BGP speaker wishes to send a BGP update attaching the AIGP 248 attribute, it must validate if that session has been enabled for 249 sending the AIGP attribute as per procedures mentioned in [RFC7311]. 251 When a BGP speaker receives a BGP update that has the AIGP attribute 252 with Generic-Metric TLV it MUST perform the following procedures. 254 1. It must validate if that session has been enabled to receive 255 the AIGP attribute as per rules mentioned in [RFC7311]. 257 2. If the BGP speaker does not recognize the Generic-Metric TLV 258 or type of metric encoded in metric-type subfield of the TLV, then 259 the BGP speaker will ignore the Generic-Metric TLV and follow the 260 BGP decision procedure as specified in [RFC7311]. 262 3. If the metric-type matches with the type of the metric 263 configured on the router, then the metric-value sub-field MUST be 264 used in the AIGP-enhanced interior cost computation as specified 265 in the next section. 267 4. If the metric-type does not match with the type of the metric 268 configured on the router, then the BGP speaker may translate cost 269 encoded in the metric-value field for computing the AIGP-enhanced 270 interior cost specified in [RFC7311]. A policy may be used to 271 provide the metric translation. 273 6. Updates to Decision Procedure 275 When a route has the AIGP attribute with Generic-Metric TLV and the 276 metric-type sub-field matches with the type of the metric used in the 277 current domain, the AIGP-enhanced interior cost should be computed as 278 below. 280 Let A be the value of the value of the metric-value sub-field of 281 the Generic-Metric TLV. 283 Let m be the cost to reach the next hop that IGP uses for its path 284 computation as described in [RFC7311]. 286 The AIGP-enhanced interior cost will be A+m as described in 287 [RFC7311]. 289 If the type of the metric used in the domain does not match the 290 metric-type sub-field of the Generic-Metric TLV, the metric-value may 291 be translated to the type of the metric used in the domain. The 292 translated metric value can be zero. 294 The translated metric value MUST be used in the AIGP-enhanced 295 interior cost computation which will be used in the decision process 296 as described in [RFC7311]. 298 7. Use-case: Different Metrics across Domains 300 +--------------+ 301 | Domain2 | 302 | | 303 ......+ASBR21 ASBR22+.... 304 . | | . 305 +------------+ . | igp-metric | . +--------------+ 306 | Domain1 | . +--------------+ . | Domain4 | 307 | | . . | | 308 | ASBR11+.. ..+ASBR41 | 309 +PE1 | | PE2+ 310 | ASBR12+.. ..+ASBR42 | 311 | | . . | | 312 | IGP-metric | . . | delay-metric | 313 +------------+ . +--------------+ . +--------------+ 314 . | Domain3 | . 315 . | | . 316 ......+ASBR31 ASBR32+.... 317 | | 318 | delay-metric | 319 +--------------+ 321 Figure 3: Different metric across network 323 Each domain is a separate Autonomous System. Within each domain, 324 ASBR and PE form iBGP peering. The IGP within each domain uses 325 domain specific metric. Domain3 and Domain4 use delay as the metric 326 while Domain1 and Domain2 use IGP cost as the metric. ASBRs across 327 domains form eBGP peering. The use-case is to find delay-based end- 328 to-end path from Domain1 to Domain4. 330 This can be achieved by the advertising router to add the AIGP 331 attribute with metric type 1 that represents delay metric. In the 332 above network diagram, ASBR41 (and ASBR42) will advertise prefix 333 PE2-loopback with Generic-Metric TLV with metric-type 1. The metric- 334 value sub-field of the Generic-Metric TLV will represent the cost to 335 reach PE2's loopback end-point from the advertising router as they 336 will do next hop self. 338 In Domain3, when ASRB32 advertises the prefix PE2-loopback within the 339 local domain, it may add cost to the metric-value, the value 340 representing the delay introduced by the DMZ link between ASRB32 to 341 ASBR42. When ASRBR31 advertises the prefix PE2-lookback, it will 342 perform the following procedures. 344 1. Compute the delay d of the path to reach ASBR32 from which it 345 has chosen the bestpath. 347 2. Add the above d value to the metric-value sub-field of the 348 Generic-Metric TLV. 350 In Domain2 however, the local metric type IGP cost. The ASBR22 may 351 follow the procedure similar to ASBR32 and add the delay value 352 corresponding to the DMZ link between ASBR22 and ASBR41 before 353 advertising the path internally in Domain2. When ASBR21 computes the 354 AIGP-enhanced interior cost, as mentioned before, it may translate 355 the igp cost to reach ASBR22 and may add the translated value to the 356 delay-metric. In the above network example, the delay cost from 357 ASBR21 to ASBR22 is negligible and hence delay-metric value will be 358 unchanged. 360 The procedures for AIGP-enhanced interior cost computation at ASBR11 361 (and ASBR12) will follow DMZ delay computation procedure described 362 above. PE1 will have two paths to reach PE2-loopback: P1 via ASBR11 363 (and domain2) and P2 via ASBR12 (and domain3), each having respective 364 AIGP-enhanced interior cost representing end-to-end delay. The BGP 365 decision process described in [RFC7311] will result in delay 366 optimized end-to-end path for PE2-loopback on PE1 that can be used to 367 resolve the service prefixes. 369 8. Deployment Considerations 371 It can be noted that a domain may translate the metric-value of the 372 metric-type used in the local domain to the metric-type present in 373 the Generic-Metric TLV. The idea is to propagate the cost of 374 reaching the prefix through the domain while maintaining the metric- 375 type chosen by the originating router and domain. The translation of 376 metric types to the one carried in the AIGP attribute can be done via 377 policy. Definition of such policies and how they can be enforced is 378 outside the scope of this document. In topologies where there is a 379 common router between adjacent domains that do iBGP peering, the 380 Border router can provide the translation. 382 All routers of a domain MUST compute the AIGP-enhanced interior cost 383 as described above to be used during decision process. Within a 384 domain, if one router R1 applies AIGP-enhanced interior cost while R2 385 does not, it may lead to routing loop unless some sort of tunnelling 386 technology viz MPLS, SRv6, IP, etc. is adopted to reach the next hop. 387 In a network where any tunnelling technology is used, one can 388 incrementally deploy the Generic-Metric functionality. In a network 389 without any tunnelling technology, it is recommended that all routers 390 should support Generic-Metric based AIGP-enhanced interior cost 391 computation. 393 9. Backward Compatibility 395 When a BGP speaker receives an update with the AIGP attribute it may 396 have Generic-Metric TLV. If the BGP speaker understands the AIGP 397 attribute but does not understand the Generic-Metric TLV, it will 398 process the AIGP attribute as per [RFC7311]. However when it needs 399 to advertise the prefix to its peers it will pass on the AIGP 400 attribute with all the TLVs including the unknown Generic-Metric TLV 401 as per [RFC7311]. If a BGP speaker does not understand the Generic- 402 Metric TLV, it may chose sub-optimal BGP path. 404 10. Security Considerations 406 This document does not introduce any new security considerations 407 beyond those already specified in [RFC4271], [RFC7311]. 409 11. IANA Considerations 411 IANA is requested to assign a code point for Generic Metric TLV. The 412 metric-type field refers to the IGP metric-type registry defined in 413 [I-D.ietf-lsr-flex-algo-bw-con] 415 12. Acknowledgements 417 The authors would like to thank John Scudder and Jeff Haas for 418 careful review and suggestions. 420 13. References 421 13.1. Normative References 423 [I-D.dskc-bess-bgp-car] 424 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 425 Steinberg, D., Jalil, L., Su, Y., Guichard, J., Patel, K., 426 and H. Wang, "BGP Color-Aware Routing (CAR)", draft-dskc- 427 bess-bgp-car-02 (work in progress), May 2021. 429 [I-D.dskc-bess-bgp-car-problem-statement] 430 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 431 Decraene, B., Steinberg, D., Jalil, L., Guichard, J., 432 Patel, K., and W. Henderickx, "BGP Color-Aware Routing 433 Problem Statement", draft-dskc-bess-bgp-car-problem- 434 statement-03 (work in progress), May 2021. 436 [I-D.hegde-spring-seamless-sr-architecture] 437 Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A., 438 Uttaro, J., Jalil, L., Khaddam, M., and A. Alston, 439 "Seamless Segment Routing Architecture", draft-hegde- 440 spring-seamless-sr-architecture-00 (work in progress), 441 February 2021. 443 [I-D.ietf-lsr-flex-algo-bw-con] 444 Hegde, S., J, W. B. A., Shetty, R., Decraene, B., Psenak, 445 P., and T. Li, "Flexible Algorithms: Bandwidth, Delay, 446 Metrics and Constraints", draft-ietf-lsr-flex-algo-bw- 447 con-00 (work in progress), May 2021. 449 [I-D.kaliraj-idr-bgp-classful-transport-planes] 450 Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., 451 Mishra, G., Khaddam, M., Xu, X., and R. J. Szarecki, "BGP 452 Classful Transport Planes", draft-kaliraj-idr-bgp- 453 classful-transport-planes-07 (work in progress), February 454 2021. 456 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 457 DOI 10.17487/RFC0791, September 1981, 458 . 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 466 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 467 May 2017, . 469 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 470 (IPv6) Specification", STD 86, RFC 8200, 471 DOI 10.17487/RFC8200, July 2017, 472 . 474 13.2. Informative References 476 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 477 (TE) Extensions to OSPF Version 2", RFC 3630, 478 DOI 10.17487/RFC3630, September 2003, 479 . 481 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 482 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 483 DOI 10.17487/RFC4271, January 2006, 484 . 486 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 487 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 488 2006, . 490 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 491 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 492 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 493 . 495 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 496 "Multiprotocol Extensions for BGP-4", RFC 4760, 497 DOI 10.17487/RFC4760, January 2007, 498 . 500 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 501 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 502 2008, . 504 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 505 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 506 DOI 10.17487/RFC7311, August 2014, 507 . 509 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 510 Previdi, "OSPF Traffic Engineering (TE) Metric 511 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 512 . 514 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 515 "Advertisement of Multiple Paths in BGP", RFC 7911, 516 DOI 10.17487/RFC7911, July 2016, 517 . 519 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 520 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 521 . 523 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 524 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 525 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 526 2019, . 528 Authors' Addresses 530 Srihari Sangli 531 Juniper Networks Inc. 532 Exora Business Park 533 Bangalore, KA 560103 534 India 536 Email: ssangli@juniper.net 538 Shraddha Hegde 539 Juniper Networks Inc. 540 Exora Business Park 541 Bangalore, KA 560103 542 India 544 Email: shraddha@juniper.net 546 Reshma Das 547 Juniper Networks Inc. 548 1133 Innovation Way 549 Sunnyvale, CA 94089 550 USA 552 Email: dreshma@juniper.net 554 Bruno Decraene 555 Orange 556 France 558 Email: bruno.decraene@orange.com