idnits 2.17.1 draft-ssangli-idr-bgp-generic-metric-aigp-01.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 (26 July 2021) is 1003 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 567, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 630, 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 (-10) exists of draft-ietf-lsr-flex-algo-bw-con-01 == Outdated reference: A later version (-17) exists of draft-kaliraj-idr-bgp-classful-transport-planes-10 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: 27 January 2022 Juniper Networks Inc. 6 B. Decraene 7 Orange 8 26 July 2021 10 Generic Metric for the AIGP attribute 11 draft-ssangli-idr-bgp-generic-metric-aigp-01 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 27 January 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. Multiple Metric types . . . . . . . . . . . . . . . . . . . . 4 56 4. Issues with RFC7311 . . . . . . . . . . . . . . . . . . . . . 5 57 5. Generic Metric TLV . . . . . . . . . . . . . . . . . . . . . 6 58 6. Usage of Generic-Metric TLV . . . . . . . . . . . . . . . . . 6 59 7. Updates to Decision Procedure . . . . . . . . . . . . . . . . 8 60 8. Use-case: Different Metrics across Domains . . . . . . . . . 9 61 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 62 10. Contiguity Compliance . . . . . . . . . . . . . . . . . . . . 11 63 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 15.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 Large Networks belonging to an enterprise may consist of nodes in the 75 order of thousands and may span across multiple IGP domains where 76 each domain can run separate IGPs or levels/areas. BGP may be used 77 to interconnect such IGP domains, with one or more IGP domains within 78 an Autonomous System. The enterprise network can have multiple 79 Autonomous Systems and BGP may be employed to provide connectivity 80 between these domains. Furthermore, BGP can be used to provide 81 routing over a large number of such independent administrative 82 domains. 84 The traffic types have evolved over years and operators have resorted 85 to defining different metric types within a IGP domain (ISIS or OSPF) 86 for IGP path computation. An operator may want to create an end-to- 87 end path that satisfy certain intent. The intent could be to create 88 end-to-end path that minimizes one of the metric-types. Some metrics 89 can be assigned administratively by an operator and they are 90 described in the base ISIS, OSPF specifications. Other metrics, for 91 example, are the Traffic Engineering Default Metric defined in 92 [RFC5305] and [RFC3630], Min Unidirectional delay metric defined in 93 [RFC8570] and [RFC7471]. There may be other metrics such as jitter, 94 reliability, fiscal cost, etc. that an operator may wish to express 95 as the cost of a link. The procedures mentioned in the above 96 specifications describe the IGP path computation within IGP domains. 98 With the advent of 5G applications and Network Slicing applications, 99 an operator may wish to provision end-to-end paths across multiple 100 domains to cater to traffic constraints. This is also known as 101 intent-based inter-domain routing and there are certain architectures 102 being developed as described in 103 [I-D.hegde-spring-seamless-sr-architecture] and 104 [I-D.dskc-bess-bgp-car-problem-statement]. The Clasful Transport 105 Planes as described in 106 [I-D.kaliraj-idr-bgp-classful-transport-planes] and Color-Based 107 Routing as described in [I-D.dskc-bess-bgp-car] describe how end-to- 108 end intent-based paths can be established. The proposal described in 109 this document can be used in conjunction with such architectures. 111 When multiple domains are interconnected via BGP, protocol extensions 112 for advertising best-external path and/or ADDPATH as described in 113 [RFC7911] are employed to take advantage of network connectivity thus 114 providing alternate paths. The Color-Based Routing and Classful 115 Transport Planes routing proposals describe approaches that result in 116 alternate paths for a reaching one destination. During the BGP best 117 path computation, the step(e) as per section 9.1.2.2 of [RFC4271], 118 the interior cost of a route as determined via the IGP metric value 119 can be used to break the tie. In a network spanning multiple IGP 120 domains, the AIGP TLV encoded within the AIGP attribute described in 121 [RFC7311] can be used to compute the AIGP-enhanced interior cost to 122 be used in the decision process for selecting the best path as 123 documented in section 2 of [RFC7311]. The [RFC7311] specifies how 124 AIGP TLV can carry the accumulated IGP metric value. 126 There is a need to synchronize the metric-type values carried between 127 IGP and BGP in order to avoid operational overhead of translation 128 between them. The existing AIGP TLV carries a TLV type and metric- 129 value where TLV type does not map to IGP metric-types defined in the 130 IGP metric-type registry. Hence there is a need to provide a generic 131 metric template to embed the IGP metric-type values within the AIGP 132 attribute. This document extends the AIGP attribute for carrying 133 Generic-Metric TLV and the well-defined sub metric types. This 134 document also provides procedures for handling Generic-Metric during 135 the BGP best path computation. 137 2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. Multiple Metric types 147 Consider the network as shown in Figure 1. The network has multiple 148 domains. Each domain runs a separate IGP instance. Within each 149 domain iBGP sessions are established between the PE routers. eBGP 150 sessions are established between the Border Routers across domains. 151 An operator wishes to compute end-to-end path optimized for a metric- 152 type delay. Each domain will be enabled to compute the IGP paths 153 based on metric-type delay. Such values should also be propagated to 154 the adjacent domains for effective end-to-end path computation. 156 ------IBGP-----EBGP------IBGP------EBGP------IBGP----- 157 | | | | | | 159 +-------------+ +-------------+ +-------------+ 160 | | | | | | 161 | ASBR1+--+ASBR2 ASBR3+--+ASBR4 | 162 | | . . | | . . | | 163 PE1+ Domain1 | . | Domain2 | . | Domain3 +PE2 164 | | . . | | . . | | 165 | ASBR5+--+ASBR6 ASBR7+--+ASBR8 | 166 | | | | | | 167 +-------------+ +-------------+ +-------------+ 169 |----ISIS1----| |----ISIS2----| |----ISIS3----| 171 Figure 1: WAN Network 173 The AIGP TLV in the AIGP attribute as specified in [RFC7311] supports 174 the IGP default metric. If all domains use IGP cost as the metric, 175 then one can compute the end-to-end path with shortest IGP cost. 176 However if an operator wishes to compute the end-to-end path with 177 metric other than IGP cost, we need additional extensions to the AIGP 178 attribute for carry the metric-types and metric values. 180 The [I-D.ietf-lsr-flex-algo-bw-con] proposes a generic metric type 181 that can embed multiple metric types within it. It supports both 182 standard metric-types and user-defined metric-types. This document 183 leverages the generic-metric draft and proposes extensions to the 184 AIGP attribute to carry Generic Metric TLV as specified below. 186 4. Issues with RFC7311 188 The following procedures are not clearly described in [RFC7311]. 190 * The section 3 describes "When an AIGP attribute is created, it 191 SHOULD contain no more than one AIGP TLV. However, if it contains 192 more than one AIGP TLV, only the first one is used as described in 193 Sections 3.4 and 4. In the remainder of this document, we will 194 use the term value of the AIGP TLV to mean the value of the first 195 AIGP TLV in the AIGP attribute. Any other AIGP TLVs in the AIGP 196 attribute MUST be passed along unchanged if the AIGP attribute is 197 passed along." 199 * ....One MUST interpret that more than one TLV of a particular type 200 (i.e. AIGP TLV metric-type 1) can be present in the update and 201 only the first occurance MUST be analysed. All other TLVs (type 2 202 or type 3 etc.) MUST be passed along unchanged if AIGP attribute 203 is passed along. 205 * The section 3.2 describes "Note that an AIGP attribute MUST NOT be 206 considered to be malformed because it contains more than one TLV 207 of a given type or because it contains TLVs of unknown types." 209 * ....One MUST interpret that opaque TLVs (TLVs with type 2 or type 210 3 for example) MUST be passed along if ADVERTISE_AIGP_ATTRIBUTE 211 has been enabled to a neighbor. 213 * Section 3.3 describes "The AIGP attribute MUST NOT be sent on any 214 BGP session for which AIGP_SESSION is disabled." 216 * ....While maintaining the non-transitivity is important, it is 217 also important to provide accumulated cost end-to-end across 218 domains. If there are more than one TLVs in the AIGP attribute, 219 it becomes important to define the behavior of which TLV gets 220 updated and sent across domains. 222 * The rules for route redistribution is not clearly described. 224 * ....When a BGP route is redistributed, should AIGP metric-value be 225 used directly as the cost in IGP or should there be a policy to 226 modify AIGP metric-value before redistributing the route into IGP. 227 It is important to define the behavior of route redistribution 228 metric conversion when redistribution occurs on multiple domains 229 along the path. 231 5. Generic Metric TLV 233 This document proposes a new TLV : Generic-Metric TLV in the AIGP 234 attribute. This will carry the metric type and metric value used in 235 the network. The format is shown below. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type | Length | metric-type | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | metric-value | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 245 Figure 2: Generic-Metric TLV 247 Generic-Metric TLV Type (1 octet): Code point to be assigned by 248 IANA 250 Generic-Metric TLV Length (2 octets): 12 252 Generic-Metric TLV Value (9 octets): 2 sub-fields as shown below: 254 1. metric-type (1 octet): Value from IGP metric-type registry. 256 2. metric-value (8 octets): Value range (0 - 0xffffffffffffffff) 258 6. Usage of Generic-Metric TLV 260 1. When a BGP speaker wishes to generate AIGP attribute with 261 Generic-Metric TLV for a prefix, it MUST perform the following 262 procedures. 264 - The procedures specified in [RFC7311] section 3.4 should be 265 followed that describes creation of attribute, modifications by 266 the originator and non-originator of the route. 268 - Repeated metric changes may cause large number of BGP updates 269 to get generated and be propagated throughout the network. In 270 order to avoid that, a configurable threshold is defined. If 271 the difference between the new metric-value and the advertised 272 metric-value is less than the configured threshold, the update 273 MAY be suppressed. If the new metric-value is above the 274 configured threshold, a new BGP update containing the new 275 metric-value SHOULD be advertised. 277 - If the domain uses a metric type other than IGP cost for the 278 IGP path computation, the BGP speaker MAY add Generic-Metric 279 TLV to the AIGP attribute before advertising to a neighboring 280 BGP speaker. 282 - The metric-type sub-field in the Generic-Metric TLV will carry 283 the value indicating the type of the metric as specified in the 284 IGP metric-type registry. 286 - The value of the metric or cost to reach the prefix being 287 advertised will be encoded in the metric-value sub-field. This 288 is the cost or the distance to the destination prefix from the 289 advertising BGP speaker which sets itself as the next hop as 290 described in section 3.4 of [RFC7311]. 292 - Procedures for defining the cost to reach a next hop for 293 various metric-types is outside the scope of this document. 295 2. When a BGP speaker wishes to send a BGP update attaching the 296 AIGP attribute, it must validate if that session has been enabled 297 for sending the AIGP attribute as per procedures mentioned in 298 [RFC7311]. 300 3. When a BGP speaker receives a BGP update that has a route to T 301 with next hop N and has the AIGP attribute with Generic-Metric TLV 302 it MUST perform the following procedures. 304 - It must validate if that session has been enabled to receive 305 the AIGP attribute as per rules mentioned in [RFC7311]. 307 - If the BGP speaker does not recognize the Generic-Metric TLV or 308 type of metric encoded in metric-type subfield of the TLV, then 309 the BGP speaker will ignore the Generic-Metric TLV and follow 310 the BGP decision procedure as specified in [RFC7311]. 312 - If the metric-type of the path used for resolving the next hop 313 N matches with the metric-type of Generic-Metric TLV of the 314 AIGP attribute, then the metric-value sub-field MUST be used in 315 the AIGP-enhanced interior cost computation as specified in the 316 next section. 318 - If the metric-type of the path used for resolving the next hop 319 N does not match with the metric-type of Generic-Metric TLV of 320 the AIGP attribute, then the BGP speaker may normalize cost of 321 the path used for resolving the next hop. A policy may be used 322 to provide the metric normalization. 324 7. Updates to Decision Procedure 326 This section follows the approach as laid out in [RFC7311] to select 327 the best path when the route has AIGP attribute with Generic-Metric 328 TLV. The domain that the router R belongs to, has enabled metric- 329 types different from IGP cost. The following describes procedures in 330 addition to general procedure described in section 4 of [RFC7311]. 332 When R receives a route T with next hop N and the AIGP attribute with 333 Generic-Metric TLV, and the metric-type sub-field matches with the 334 type of the metric of the path used for resolving the next hop N, the 335 AIGP-enhanced interior cost should be computed as below. 337 Let m be the cost to reach the next hop N that IGP uses for its 338 path computation as described in [RFC7311]. 340 If the type of the metric of the path used for resolving the next hop 341 N does not match the metric-type sub-field of the Generic-Metric TLV, 342 the cost of the path to reach next hop N may be normalized. The 343 normalized metric value can be zero, maximum metric value or scaled 344 up (multiple of a positive number). 346 Let m be the normalized value of the cost to reach the next hop N 347 that IGP uses for its path computation as described in [RFC7311]. 349 The AIGP-enhanced interior cost computation as described below will 350 be used in the decision process as described in [RFC7311]. 352 Let A be the value of the value of the metric-value sub-field of 353 the Generic-Metric TLV. 355 The AIGP-enhanced interior cost will be A+m as described in 356 [RFC7311]. 358 A path with Generic-Metric TLV and a path with AIGP TLV cannot be 359 compared. To enable end-to-end path selection based on intent, the 360 with Generic-Metric TLV MUST be chosen over path with AIGP TLV. The 361 implementation should allow a local policy to specify the preference. 363 A path with Generic-Metric TLV of metric-type 'a' cannot be compared 364 with a path with Generic-Metric TLV of metric-type 'b'. The path 365 with lower metric-type MUST be chosen as best between two paths with 366 Generic-Metric TLV. 368 8. Use-case: Different Metrics across Domains 370 +--------------+ 371 | Domain2 | 372 | | 373 ......+ASBR21 ASBR22+.... 374 . | | . 375 +------------+ . | igp-metric | . +--------------+ 376 | Domain1 | . +--------------+ . | Domain4 | 377 | | . . | | 378 | ASBR11+.. ..+ASBR41 | 379 +PE1 | | PE2+ 380 | ASBR12+.. ..+ASBR42 | 381 | | . . | | 382 | IGP-metric | . . | delay-metric | 383 +------------+ . +--------------+ . +--------------+ 384 . | Domain3 | . 385 . | | . 386 ......+ASBR31 ASBR32+.... 387 | | 388 | delay-metric | 389 +--------------+ 391 Figure 3: Different metric across network 393 Each domain is a separate Autonomous System. Within each domain, 394 ASBR and PE form iBGP peering. The IGP within each domain uses 395 domain specific metric. Domain3 and Domain4 use delay as the metric 396 while Domain1 and Domain2 use IGP cost as the metric. ASBRs across 397 domains form eBGP peering. The use-case is to find delay-based end- 398 to-end path from Domain1 to Domain4. 400 This can be achieved by the advertising router to add the AIGP 401 attribute with metric type 1 that represents delay metric. In the 402 above network diagram, ASBR41 (and ASBR42) will advertise prefix 403 PE2-loopback with Generic-Metric TLV with delay as metric-type. The 404 metric-value sub-field of the Generic-Metric TLV will represent the 405 cost to reach PE2's loopback end-point from the advertising router as 406 they will do next hop self. 408 In Domain3, when ASRB32 advertises the prefix PE2-loopback within the 409 local domain, it may add cost to the metric-value, the value 410 representing the delay introduced by the DMZ link between ASRB32 to 411 ASBR42. When ASRBR31 advertises the prefix PE2-lookback, it will 412 perform the following procedures. 414 1. Compute the delay d of the path to reach ASBR32 from which it 415 has chosen the best path. 417 2. Add the above d value to the metric-value sub-field of the 418 Generic-Metric TLV. 420 In Domain2 however, the local metric type IGP cost. The ASBR22 may 421 follow the procedure similar to ASBR32 and add the delay value 422 corresponding to the DMZ link between ASBR22 and ASBR41 before 423 advertising the path internally in Domain2. When ASBR21 computes the 424 AIGP-enhanced interior cost, as mentioned before, it may normalize 425 the igp cost to reach ASBR22 and may add the normalized value to the 426 delay-metric. In the above network example, the delay cost from 427 ASBR21 to ASBR22 is negligible and hence delay-metric value will be 428 unchanged. 430 The procedures for AIGP-enhanced interior cost computation at ASBR11 431 (and ASBR12) will follow DMZ delay computation procedure described 432 above. PE1 will have two paths to reach PE2-loopback: P1 via ASBR11 433 (and domain2) and P2 via ASBR12 (and domain3), each having respective 434 AIGP-enhanced interior cost representing end-to-end delay. The BGP 435 decision process described in Section 7 will result in delay 436 optimized end-to-end path for PE2-loopback on PE1 that can be used to 437 resolve the service prefixes. 439 9. Deployment Considerations 441 It can be noted that a domain may normalize the metric-value of the 442 metric-type of the path used to resolve next hop to the metric-type 443 present in the Generic-Metric TLV. The idea is to propagate the cost 444 of reaching the prefix through the domain while maintaining the 445 metric-type chosen by the originating router and domain. The 446 normalization of metric types to the one carried in the AIGP 447 attribute can be done via policy. Definition of such policies and 448 how they can be enforced is outside the scope of this document. In 449 topologies where there is a common router between adjacent domains 450 that do iBGP peering, the Border router can provide the 451 normalization. 453 It is important to maintain the property of IGP cost to a destination 454 decrease as one gets closer to the destination. The AIGP-enhanced 455 interior cost should not be allowed to decrease through the metric 456 normalization. When adjacent domains use different metric types, the 457 ASBR that connects two domains is better suited to pass on the metric 458 values by setting itself as next hop. 460 All routers of a domain MUST compute the AIGP-enhanced interior cost 461 as described above to be used during decision process. Within a 462 domain, if one router R1 applies AIGP-enhanced interior cost while R2 463 does not, it may lead to routing loop unless some sort of tunnelling 464 technology viz MPLS, SRv6, IP, etc. is adopted to reach the next hop. 465 In a network where any tunnelling technology is used, one can 466 incrementally deploy the Generic-Metric functionality. In a network 467 without any tunnelling technology, it is recommended that all routers 468 MUST support Generic-Metric based AIGP-enhanced interior cost 469 computation. 471 The contiguity of the AIGP domain across multiple IGP or AS domains 472 is important to maintain end-to-end path of a certain intent. A 473 router that does not recognize Generic-Metric TLV, may add AIGP TLV 474 and pass on the BGP route with just AIGP TLV. This results in AIGP 475 attribute having both TLVs. The router making decision only on 476 Generic-Metric TLV may chose sub-optimal paths. 478 In certain networks, routes may be redistributed between BGP and IGP, 479 usually controlled via a policy. When a route is propagated across 480 domains, a router should use AIGP metric-value of Generic-Metric TLV, 481 optionally modified via the local policy as the IGP cost during route 482 redistribution in to IGP. The local policy should apply metric 483 normalization or translation based on metric-type of Generic-Metric 484 TLV and the metric-type adopted in the IGP. 486 10. Contiguity Compliance 488 AIGP attribute is optional and non-transitive, however new TLV might 489 not be interpreted and/or updated by routers along the path. For 490 computing the end-to-end path based on an intent, it is essential to 491 maintain contiguity of AIGP domain for the metric-type. The 492 mechanism will be addressed in the future version of this document. 494 11. Backward Compatibility 496 When a BGP speaker receives an update with the AIGP attribute it may 497 have Generic-Metric TLV. If the BGP speaker understands the AIGP 498 attribute but does not understand the Generic-Metric TLV, it will 499 process the AIGP attribute as per [RFC7311]. However when it needs 500 to advertise the prefix to its peers it will pass on the AIGP 501 attribute with all the TLVs including the unknown Generic-Metric TLV 502 as per [RFC7311]. If a BGP speaker does not understand the Generic- 503 Metric TLV, it may chose sub-optimal BGP path. 505 12. Security Considerations 507 This document does not introduce any new security considerations 508 beyond those already specified in [RFC4271], [RFC7311]. 510 13. IANA Considerations 512 IANA is requested to assign a code point for Generic Metric TLV. The 513 metric-type field refers to the IGP metric-type registry defined in 514 [I-D.ietf-lsr-flex-algo-bw-con] 516 14. Acknowledgements 518 The authors would like to thank John Scudder, Jeff Haas, Robert 519 Raszuk, and Kaliraj Vairavakkalai for careful review and suggestions. 521 15. References 523 15.1. Normative References 525 [I-D.dskc-bess-bgp-car] 526 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 527 Steinberg, D., Jalil, L., Su, Y., Guichard, J., Patel, K., 528 and H. Wang, "BGP Color-Aware Routing (CAR)", Work in 529 Progress, Internet-Draft, draft-dskc-bess-bgp-car-02, 11 530 May 2021, . 533 [I-D.dskc-bess-bgp-car-problem-statement] 534 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 535 Decraene, B., Steinberg, D., Jalil, L., Guichard, J., 536 Patel, K., and W. Henderickx, "BGP Color-Aware Routing 537 Problem Statement", Work in Progress, Internet-Draft, 538 draft-dskc-bess-bgp-car-problem-statement-03, 23 May 2021, 539 . 542 [I-D.hegde-spring-seamless-sr-architecture] 543 Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A., 544 Uttaro, J., Jalil, L., Khaddam, M., and A. Alston, 545 "Seamless Segment Routing Architecture", Work in Progress, 546 Internet-Draft, draft-hegde-spring-seamless-sr- 547 architecture-00, 22 February 2021, 548 . 551 [I-D.ietf-lsr-flex-algo-bw-con] 552 Hegde, S., J, W. B. A., Shetty, R., Decraene, B., Psenak, 553 P., and T. Li, "Flexible Algorithms: Bandwidth, Delay, 554 Metrics and Constraints", Work in Progress, Internet- 555 Draft, draft-ietf-lsr-flex-algo-bw-con-01, 12 July 2021, 556 . 559 [I-D.kaliraj-idr-bgp-classful-transport-planes] 560 Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., 561 Mishra, G., Khaddam, M., Xu, X., and R. J. Szarecki, "BGP 562 Classful Transport Planes", Work in Progress, Internet- 563 Draft, draft-kaliraj-idr-bgp-classful-transport-planes-10, 564 12 July 2021, . 567 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 568 DOI 10.17487/RFC0791, September 1981, 569 . 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 577 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 578 May 2017, . 580 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 581 (IPv6) Specification", STD 86, RFC 8200, 582 DOI 10.17487/RFC8200, July 2017, 583 . 585 15.2. Informative References 587 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 588 (TE) Extensions to OSPF Version 2", RFC 3630, 589 DOI 10.17487/RFC3630, September 2003, 590 . 592 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 593 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 594 DOI 10.17487/RFC4271, January 2006, 595 . 597 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 598 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 599 2006, . 601 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 602 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 603 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 604 . 606 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 607 "Multiprotocol Extensions for BGP-4", RFC 4760, 608 DOI 10.17487/RFC4760, January 2007, 609 . 611 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 612 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 613 2008, . 615 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 616 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 617 DOI 10.17487/RFC7311, August 2014, 618 . 620 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 621 Previdi, "OSPF Traffic Engineering (TE) Metric 622 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 623 . 625 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 626 "Advertisement of Multiple Paths in BGP", RFC 7911, 627 DOI 10.17487/RFC7911, July 2016, 628 . 630 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 631 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 632 . 634 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 635 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 636 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 637 2019, . 639 Authors' Addresses 641 Srihari Sangli 642 Juniper Networks Inc. 643 Exora Business Park 644 Bangalore 560103 645 KA 646 India 648 Email: ssangli@juniper.net 650 Shraddha Hegde 651 Juniper Networks Inc. 652 Exora Business Park 653 Bangalore 560103 654 KA 655 India 657 Email: shraddha@juniper.net 659 Reshma Das 660 Juniper Networks Inc. 661 1133 Innovation Way 662 Sunnyvale, CA 94089 663 United States of America 665 Email: dreshma@juniper.net 667 Bruno Decraene 668 Orange 669 France 671 Email: bruno.decraene@orange.com