idnits 2.17.00 (12 Aug 2021) /tmp/idnits4659/draft-ssangli-idr-bgp-generic-metric-aigp-02.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 354 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (January 23, 2022) is 111 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 521, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC8277' is defined on line 584, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-dskc-bess-bgp-car-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 (-02) exists of draft-ietf-lsr-flex-algo-bw-con-01 == Outdated reference: A later version (-14) exists of draft-kaliraj-idr-bgp-classful-transport-planes-13 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDR S. Sangli 2 Internet-Draft S. Hegde 3 Intended status: Standards Track R. Das 4 Expires: July 27, 2022 Juniper Networks Inc. 5 B. Decraene 6 Orange 7 January 23, 2022 9 Generic Metric for the AIGP attribute 10 draft-ssangli-idr-bgp-generic-metric-aigp-02 12 Abstract 14 This document defines extensions to the AIGP attribute to carry 15 Generic Metric sub-types. This is applicable when multiple domains 16 exchange BGP routing information. The extension will aid in intent- 17 based end-to-end path selection. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 27, 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Multiple Metric types . . . . . . . . . . . . . . . . . . . . 4 56 4. Issues with RFC7311 . . . . . . . . . . . . . . . . . . . . . 4 57 5. Generic Metric TLV . . . . . . . . . . . . . . . . . . . . . 5 58 6. Usage of Generic-Metric TLV . . . . . . . . . . . . . . . . . 6 59 7. Updates to Decision Procedure . . . . . . . . . . . . . . . . 7 60 8. Use-case: Different Metrics across Domains . . . . . . . . . 8 61 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 62 10. Contiguity Compliance . . . . . . . . . . . . . . . . . . . . 10 63 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 15.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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----- | | | | | | +-------------+ +-------------+ +-------------+ | | | | | | | ASBR1+--+ASBR2 ASBR3+--+ASBR4 | | | . . | | . . | | PE1+ Domain1 | . | Domain2 | . | Domain3 +PE2 | | . . | | . . | | | ASBR5+--+ASBR6 ASBR7+--+ASBR8 | | | | | | | +-------------+ +-------------+ +-------------+ |----ISIS1----| |----ISIS2----| |----ISIS3----| 158 Figure 1: WAN Network 160 The AIGP TLV in the AIGP attribute as specified in [RFC7311] supports 161 the IGP default metric. If all domains use IGP cost as the metric, 162 then one can compute the end-to-end path with shortest IGP cost. 163 However if an operator wishes to compute the end-to-end path with 164 metric other than IGP cost, we need additional extensions to the AIGP 165 attribute for carry the metric-types and metric values. 167 The [I-D.ietf-lsr-flex-algo-bw-con] proposes a generic metric type 168 that can embed multiple metric types within it. It supports both 169 standard metric-types and user-defined metric-types. This document 170 leverages the generic-metric draft and proposes extensions to the 171 AIGP attribute to carry Generic Metric TLV as specified below. 173 4. Issues with RFC7311 175 The following procedures are not clearly described in [RFC7311] . 177 o The section 3 describes "When an AIGP attribute is created, it 178 SHOULD contain no more than one AIGP TLV. However, if it contains 179 more than one AIGP TLV, only the first one is used as described in 180 Sections 3.4 and 4. In the remainder of this document, we will 181 use the term value of the AIGP TLV to mean the value of the first 182 AIGP TLV in the AIGP attribute. Any other AIGP TLVs in the AIGP 183 attribute MUST be passed along unchanged if the AIGP attribute is 184 passed along." 186 o ....One MUST interpret that more than one TLV of a particular type 187 (i.e. AIGP TLV metric-type 1) can be present in the update and 188 only the first occurance MUST be analysed. All other TLVs (type 2 189 or type 3 etc.) MUST be passed along unchanged if AIGP attribute 190 is passed along. 192 o The section 3.2 describes "Note that an AIGP attribute MUST NOT be 193 considered to be malformed because it contains more than one TLV 194 of a given type or because it contains TLVs of unknown types." 196 o ....One MUST interpret that opaque TLVs (TLVs with type 2 or type 197 3 for example) MUST be passed along if ADVERTISE_AIGP_ATTRIBUTE 198 has been enabled to a neighbor. 200 o Section 3.3 describes "The AIGP attribute MUST NOT be sent on any 201 BGP session for which AIGP_SESSION is disabled." 203 o ....While maintaining the non-transitivity is important, it is 204 also important to provide accumulated cost end-to-end across 205 domains. If there are more than one TLVs in the AIGP attribute, 206 it becomes important to define the behavior of which TLV gets 207 updated and sent across domains. 209 o The rules for route redistribution is not clearly described. 211 o ....When a BGP route is redistributed, should AIGP metric-value be 212 used directly as the cost in IGP or should there be a policy to 213 modify AIGP metric-value before redistributing the route into IGP. 214 It is important to define the behavior of route redistribution 215 metric conversion when redistribution occurs on multiple domains 216 along the path. 218 5. Generic Metric TLV 220 This document proposes a new TLV : Generic-Metric TLV in the AIGP 221 attribute. This will carry the metric type and metric value used in 222 the network. The format is shown below. 224 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | metric-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metric-value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 226 Figure 2: Generic-Metric TLV 228 Generic-Metric TLV Type (1 octet): Code point to be assigned by 229 IANA 231 Generic-Metric TLV Length (2 octets): 12 233 Generic-Metric TLV Value (9 octets): 2 sub-fields as shown below: 235 1. metric-type (1 octet): Value from IGP metric-type registry. 237 2. metric-value (8 octets): Value range (0 - 0xffffffffffffffff) 239 6. Usage of Generic-Metric TLV 241 1. When a BGP speaker wishes to generate AIGP attribute with 242 Generic-Metric TLV for a prefix, it MUST perform the following 243 procedures. 245 * The procedures specified in [RFC7311] section 3.4 should be 246 followed that describes creation of attribute, modifications by 247 the originator and non-originator of the route. 249 * Repeated metric changes may cause large number of BGP updates 250 to get generated and be propagated throughout the network. In 251 order to avoid that, a configurable threshold is defined. If 252 the difference between the new metric-value and the advertised 253 metric-value is less than the configured threshold, the update 254 MAY be suppressed. If the new metric-value is above the 255 configured threshold, a new BGP update containing the new 256 metric-value SHOULD be advertised. 258 * If the domain uses a metric type other than IGP cost for the 259 IGP path computation, the BGP speaker MAY add Generic-Metric 260 TLV to the AIGP attribute before advertising to a neighboring 261 BGP speaker. 263 * The metric-type sub-field in the Generic-Metric TLV will carry 264 the value indicating the type of the metric as specified in the 265 IGP metric-type registry. 267 * The value of the metric or cost to reach the prefix being 268 advertised will be encoded in the metric-value sub-field. This 269 is the cost or the distance to the destination prefix from the 270 advertising BGP speaker which sets itself as the next hop as 271 described in section 3.4 of [RFC7311] . 273 * Procedures for defining the cost to reach a next hop for 274 various metric-types is outside the scope of this document. 276 2. When a BGP speaker wishes to send a BGP update attaching the 277 AIGP attribute, it must validate if that session has been enabled 278 for sending the AIGP attribute as per procedures mentioned in 279 [RFC7311] . 281 3. When a BGP speaker receives a BGP update that has a route to T 282 with next hop N and has the AIGP attribute with Generic-Metric TLV 283 it MUST perform the following procedures. 285 * It must validate if that session has been enabled to receive 286 the AIGP attribute as per rules mentioned in [RFC7311] . 288 * If the BGP speaker does not recognize the Generic-Metric TLV or 289 type of metric encoded in metric-type subfield of the TLV, then 290 the BGP speaker will ignore the Generic-Metric TLV and follow 291 the BGP decision procedure as specified in [RFC7311] . 293 * If the metric-type of the path used for resolving the next hop 294 N matches with the metric-type of Generic-Metric TLV of the 295 AIGP attribute, then the metric-value sub-field MUST be used in 296 the AIGP-enhanced interior cost computation as specified in the 297 next section. 299 * If the metric-type of the path used for resolving the next hop 300 N does not match with the metric-type of Generic-Metric TLV of 301 the AIGP attribute, then the BGP speaker may normalize cost of 302 the path used for resolving the next hop. A policy may be used 303 to provide the metric normalization. 305 7. Updates to Decision Procedure 307 This section follows the approach as laid out in [RFC7311] to select 308 the best path when the route has AIGP attribute with Generic-Metric 309 TLV. The domain that the router R belongs to, has enabled metric- 310 types different from IGP cost. The following describes procedures in 311 addition to general procedure described in section 4 of [RFC7311] . 313 When R receives a route T with next hop N and the AIGP attribute with 314 Generic-Metric TLV, and the metric-type sub-field matches with the 315 type of the metric of the path used for resolving the next hop N, the 316 AIGP-enhanced interior cost should be computed as below. 318 Let m be the cost to reach the next hop N that IGP uses for its 319 path computation as described in [RFC7311] . 321 If the type of the metric of the path used for resolving the next hop 322 N does not match the metric-type sub-field of the Generic-Metric TLV, 323 the cost of the path to reach next hop N may be normalized. The 324 normalized metric value can be zero, maximum metric value or scaled 325 up (multiple of a positive number). 327 Let m be the normalized value of the cost to reach the next hop N 328 that IGP uses for its path computation as described in [RFC7311] . 330 The AIGP-enhanced interior cost computation as described below will 331 be used in the decision process as described in [RFC7311] . 333 Let A be the value of the value of the metric-value sub-field of 334 the Generic-Metric TLV. 336 The AIGP-enhanced interior cost will be A+m as described in 337 [RFC7311] . 339 A path with Generic-Metric TLV and a path with AIGP TLV cannot be 340 compared. To enable end-to-end path selection based on intent, the 341 with Generic-Metric TLV MUST be chosen over path with AIGP TLV. The 342 implementation should allow a local policy to specify the preference. 344 A path with Generic-Metric TLV of metric-type 'a' cannot be compared 345 with a path with Generic-Metric TLV of metric-type 'b'. The path 346 with lower metric-type MUST be chosen as best between two paths with 347 Generic-Metric TLV. 349 8. Use-case: Different Metrics across Domains 351 +--------------+ | Domain2 | | | ......+ASBR21 ASBR22+.... . | | . +------------+ . | igp-metric | . +--------------+ | Domain1 | . +--------------+ . | Domain4 | | | . . | | | ASBR11+.. ..+ASBR41 | +PE1 | | PE2+ | ASBR12+.. ..+ASBR42 | | | . . | | | IGP-metric | . . | delay-metric | +------------+ . +--------------+ . +--------------+ . | Domain3 | . . | | . ......+ASBR31 ASBR32+.... | | | delay-metric | +--------------+ 353 Figure 3: Different metric across network 355 Each domain is a separate Autonomous System. Within each domain, 356 ASBR and PE form iBGP peering. The IGP within each domain uses 357 domain specific metric. Domain3 and Domain4 use delay as the metric 358 while Domain1 and Domain2 use IGP cost as the metric. ASBRs across 359 domains form eBGP peering. The use-case is to find delay-based end- 360 to-end path from Domain1 to Domain4. 362 This can be achieved by the advertising router to add the AIGP 363 attribute with metric type 1 that represents delay metric. In the 364 above network diagram, ASBR41 (and ASBR42) will advertise prefix 365 PE2-loopback with Generic-Metric TLV with delay as metric-type. The 366 metric-value sub-field of the Generic-Metric TLV will represent the 367 cost to reach PE2's loopback end-point from the advertising router as 368 they will do next hop self. 370 In Domain3, when ASRB32 advertises the prefix PE2-loopback within the 371 local domain, it may add cost to the metric-value, the value 372 representing the delay introduced by the DMZ link between ASRB32 to 373 ASBR42. When ASRBR31 advertises the prefix PE2-lookback, it will 374 perform the following procedures. 376 1. Compute the delay d of the path to reach ASBR32 from which it 377 has chosen the best path. 379 2. Add the above d value to the metric-value sub-field of the 380 Generic-Metric TLV. 382 In Domain2 however, the local metric type IGP cost. The ASBR22 may 383 follow the procedure similar to ASBR32 and add the delay value 384 corresponding to the DMZ link between ASBR22 and ASBR41 before 385 advertising the path internally in Domain2. When ASBR21 computes the 386 AIGP-enhanced interior cost, as mentioned before, it may normalize 387 the igp cost to reach ASBR22 and may add the normalized value to the 388 delay-metric. In the above network example, the delay cost from 389 ASBR21 to ASBR22 is negligible and hence delay-metric value will be 390 unchanged. 392 The procedures for AIGP-enhanced interior cost computation at ASBR11 393 (and ASBR12) will follow DMZ delay computation procedure described 394 above. PE1 will have two paths to reach PE2-loopback: P1 via ASBR11 395 (and domain2) and P2 via ASBR12 (and domain3), each having respective 396 AIGP-enhanced interior cost representing end-to-end delay. The BGP 397 decision process described in Section 7 will result in delay 398 optimized end-to-end path for PE2-loopback on PE1 that can be used to 399 resolve the service prefixes. 401 9. Deployment Considerations 403 It can be noted that a domain may normalize the metric-value of the 404 metric-type of the path used to resolve next hop to the metric-type 405 present in the Generic-Metric TLV. The idea is to propagate the cost 406 of reaching the prefix through the domain while maintaining the 407 metric-type chosen by the originating router and domain. The 408 normalization of metric types to the one carried in the AIGP 409 attribute can be done via policy. Definition of such policies and 410 how they can be enforced is outside the scope of this document. In 411 topologies where there is a common router between adjacent domains 412 that do iBGP peering, the Border router can provide the 413 normalization. 415 It is important to maintain the property of IGP cost to a destination 416 decrease as one gets closer to the destination. The AIGP-enhanced 417 interior cost should not be allowed to decrease through the metric 418 normalization. When adjacent domains use different metric types, the 419 ASBR that connects two domains is better suited to pass on the metric 420 values by setting itself as next hop. 422 All routers of a domain MUST compute the AIGP-enhanced interior cost 423 as described above to be used during decision process. Within a 424 domain, if one router R1 applies AIGP-enhanced interior cost while R2 425 does not, it may lead to routing loop unless some sort of tunnelling 426 technology viz MPLS, SRv6, IP, etc. is adopted to reach the next hop. 427 In a network where any tunnelling technology is used, one can 428 incrementally deploy the Generic-Metric functionality. In a network 429 without any tunnelling technology, it is recommended that all routers 430 MUST support Generic-Metric based AIGP-enhanced interior cost 431 computation. 433 The contiguity of the AIGP domain across multiple IGP or AS domains 434 is important to maintain end-to-end path of a certain intent. A 435 router that does not recognize Generic-Metric TLV, may add AIGP TLV 436 and pass on the BGP route with just AIGP TLV. This results in AIGP 437 attribute having both TLVs. The router making decision only on 438 Generic-Metric TLV may chose sub-optimal paths. 440 In certain networks, routes may be redistributed between BGP and IGP, 441 usually controlled via a policy. When a route is propagated across 442 domains, a router should use AIGP metric-value of Generic-Metric TLV, 443 optionally modified via the local policy as the IGP cost during route 444 redistribution in to IGP. The local policy should apply metric 445 normalization or translation based on metric-type of Generic-Metric 446 TLV and the metric-type adopted in the IGP. 448 10. Contiguity Compliance 450 AIGP attribute is optional and non-transitive, however new TLV might 451 not be interpreted and/or updated by routers along the path. For 452 computing the end-to-end path based on an intent, it is essential to 453 maintain contiguity of AIGP domain for the metric-type. The 454 mechanism will be addressed in the future version of this document. 456 11. Backward Compatibility 458 When a BGP speaker receives an update with the AIGP attribute it may 459 have Generic-Metric TLV. If the BGP speaker understands the AIGP 460 attribute but does not understand the Generic-Metric TLV, it will 461 process the AIGP attribute as per [RFC7311] . However when it needs 462 to advertise the prefix to its peers it will pass on the AIGP 463 attribute with all the TLVs including the unknown Generic-Metric TLV 464 as per [RFC7311] . If a BGP speaker does not understand the Generic- 465 Metric TLV, it may chose sub-optimal BGP path. 467 12. Security Considerations 469 This document does not introduce any new security considerations 470 beyond those already specified in [RFC4271] , [RFC7311] . 472 13. IANA Considerations 474 IANA is requested to assign a code point for Generic Metric TLV. The 475 metric-type field refers to the IGP metric-type registry defined in 476 [I-D.ietf-lsr-flex-algo-bw-con] 478 14. Acknowledgements 480 The authors would like to thank John Scudder, Jeff Haas, Robert 481 Raszuk, and Kaliraj Vairavakkalai for careful review and suggestions. 483 15. References 485 15.1. Normative References 487 [I-D.dskc-bess-bgp-car] 488 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 489 Steinberg, D., Jalil, L., Su, Y., Decraene, B., Guichard, 490 J., Patel, K., and H. Wang, "BGP Color-Aware Routing 491 (CAR)", draft-dskc-bess-bgp-car-03 (work in progress), 492 October 2021. 494 [I-D.dskc-bess-bgp-car-problem-statement] 495 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 496 Decraene, B., Steinberg, D., Jalil, L., Guichard, J., 497 Patel, K., and W. Henderickx, "BGP Color-Aware Routing 498 Problem Statement", draft-dskc-bess-bgp-car-problem- 499 statement-04 (work in progress), November 2021. 501 [I-D.hegde-spring-seamless-sr-architecture] 502 Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A., 503 Uttaro, J., Jalil, L., Khaddam, M., and A. Alston, 504 "Seamless Segment Routing Architecture", draft-hegde- 505 spring-seamless-sr-architecture-00 (work in progress), 506 February 2021. 508 [I-D.ietf-lsr-flex-algo-bw-con] 509 Hegde, S., J, W. B. A., Shetty, R., Decraene, B., Psenak, 510 P., and T. Li, "Flexible Algorithms: Bandwidth, Delay, 511 Metrics and Constraints", draft-ietf-lsr-flex-algo-bw- 512 con-01 (work in progress), July 2021. 514 [I-D.kaliraj-idr-bgp-classful-transport-planes] 515 Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., 516 Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., and D. 517 J. Gowda, "BGP Classful Transport Planes", draft-kaliraj- 518 idr-bgp-classful-transport-planes-13 (work in progress), 519 January 2022. 521 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 522 DOI 10.17487/RFC0791, September 1981, 523 . 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, 527 DOI 10.17487/RFC2119, March 1997, 528 . 530 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 531 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 532 May 2017, . 534 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 535 (IPv6) Specification", STD 86, RFC 8200, 536 DOI 10.17487/RFC8200, July 2017, 537 . 539 15.2. Informative References 541 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 542 (TE) Extensions to OSPF Version 2", RFC 3630, 543 DOI 10.17487/RFC3630, September 2003, 544 . 546 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 547 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 548 DOI 10.17487/RFC4271, January 2006, 549 . 551 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 552 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 553 2006, . 555 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 556 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 557 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 558 . 560 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 561 "Multiprotocol Extensions for BGP-4", RFC 4760, 562 DOI 10.17487/RFC4760, January 2007, 563 . 565 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 566 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 567 2008, . 569 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 570 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 571 DOI 10.17487/RFC7311, August 2014, 572 . 574 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 575 Previdi, "OSPF Traffic Engineering (TE) Metric 576 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 577 . 579 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 580 "Advertisement of Multiple Paths in BGP", RFC 7911, 581 DOI 10.17487/RFC7911, July 2016, 582 . 584 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 585 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 586 . 588 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 589 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 590 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 591 2019, . 593 Authors' Addresses 595 Srihari Sangli 596 Juniper Networks Inc. 597 Exora Business Park 598 Bangalore, KA 560103 599 India 601 Email: ssangli@juniper.net 603 Shraddha Hegde 604 Juniper Networks Inc. 605 Exora Business Park 606 Bangalore, KA 560103 607 India 609 Email: shraddha@juniper.net 610 Reshma Das 611 Juniper Networks Inc. 612 1133 Innovation Way 613 Sunnyvale, CA 94089 614 USA 616 Email: dreshma@juniper.net 618 Bruno Decraene 619 Orange 620 France 622 Email: bruno.decraene@orange.com