idnits 2.17.1 draft-peng-idr-bgp-metric-credit-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 28, 2021) is 844 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) -- Looks like a reference, but probably isn't: '2' on line 517 -- Looks like a reference, but probably isn't: '0' on line 517 -- Looks like a reference, but probably isn't: '1' on line 517 == Outdated reference: A later version (-05) exists of draft-dskc-bess-bgp-car-03 == 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-12 == Outdated reference: A later version (-07) exists of draft-ssangli-idr-bgp-generic-metric-aigp-01 == Outdated reference: A later version (-04) exists of draft-zhou-idr-inter-domain-lcu-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Shaofu. Peng 3 Internet-Draft Bin. Tan 4 Intended status: Standards Track ZTE Corporation 5 Expires: July 1, 2022 December 28, 2021 7 BGP Metric Credit Based Routing 8 draft-peng-idr-bgp-metric-credit-00 10 Abstract 12 This document defines an optional metric related BGP path attribute 13 that can be advertised with BGP intent routes, to provide more clear 14 intent information used for the next-hop resolution. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 1, 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Extensions for BGP Route Metric . . . . . . . . . . . . . . . 4 53 2.1. Extensions for Metric Type and Metric . . . . . . . . . . 4 54 2.2. Extensions for Metric Credit . . . . . . . . . . . . . . 4 55 3. Process of Received Metric Credit . . . . . . . . . . . . . . 6 56 3.1. Only Total Metric Credit Provided . . . . . . . . . . . . 6 57 3.2. Metric Credit Piece Provided . . . . . . . . . . . . . . 7 58 3.3. Select Underlay Path According to Suggested Metric Credit 7 59 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Example of Intent with Average Metric Credit . . . . . . 8 61 4.2. Example of Intent with Metric Credit Piece . . . . . . . 10 62 4.3. Example of Intent Shared by Multiple Path . . . . . . . . 12 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 15 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 69 1. Introduction 71 In large-scale networks across multiple domains, BGP can be used to 72 advertise intent route and provide end-to-end intent aware path. 73 According to corresponding intent information, a BGP intent route 74 selects the expected underlay path for the next hop resolution. The 75 underlay path may be an MPLS-TE tunnel, an SR policy, an IGP Flex- 76 algo route, or a direct link, established segment by segment based on 77 the same intent. 79 There are many methods to make BGP carry intent information during 80 route advertisement. 82 [I-D.zhou-idr-inter-domain-lcu] describe a simple method, termed 83 as BGP-LU color, combined with [RFC7911], to create multiple BGP- 84 LU color path to the same destination, using color as intent 85 identifier. 87 [I-D.kaliraj-idr-bgp-classful-transport-planes] defines new 88 "Classful Transport" SAFI NLRI and "Transport Class" Route Target 89 extended community, to advertise intent based routes with related 90 Transport Class identifier as intent identifier. 92 [I-D.dskc-bess-bgp-car] defines new "BGP CAR" SAFI NLRI that 93 contains a Color field as intent identifier to advertise intent 94 based routes. 96 [I-D.lp-lsr-bgp-algorithm] introduces Algorithm Extended Community 97 to advertise BGP algorithm routes, using algorithm as intent 98 identifier. 100 Once a BGP speaker received an intent route advertised from neighbor, 101 it will check the related intent template in local. The intent 102 template could be a Color template, a Flex-algorithm Definition, or 103 some other modules. The intent template contains a set of 104 constraints, such as the reserved bandwidth to be provided in the 105 path, the boundary minimum and maximum delay, the boundary delay 106 jitter, the boundary packet loss rates, including or excluding 107 specific nodes or links, limiting the calculation of the path in a 108 specific virtual network, and so on. The detailed intent information 109 itself are not recommended to be directly carried in the advertised 110 route. 112 On the ingress PE node in the network, a BGP intent route to the 113 egress PE will be selected according to the service SLA. The intent 114 template configured on the ingress PE node is generally consistent 115 with the service SLA. However this does not mean that the intent 116 template configured on the intermediate nodes should also be 117 consistent with the service SLA. For example, the SLA of the service 118 is to "provide a path with an upper delay boundary of 100ms from 119 ingress PE to egress PE". In this case, the upper delay of 100ms 120 refers to end-to-end delay constraint, not for each segment. A 121 possible method is to include different delay constraints in the 122 intent template configured on different BGP speakers along the path. 123 However, this static configuration method has shortcomings, because 124 an intent template is not necessarily bound to a specific end-to-end 125 path and may be used for multiple paths. 127 It can be seen that the information contained in the intent template 128 is not enough to represent the complete intent. This often occurs on 129 cumulable metric attributes. 131 This document describes extensions to carry the metric credit 132 information in the BGP route advertisement, as a supplement to the 133 intent template, so that the BGP speaker receiving the BGP intent 134 route can establish (or select) the underlay path to the downstream 135 BGP speaker with more accurate intent indication. 137 1.1. 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 2. Extensions for BGP Route Metric 147 This section describes some extensions related to metric, so that 148 when BGP speaker advertise intent route to upstream neighbors, it 149 carries optional metric type, metric, and metric credit information. 151 2.1. Extensions for Metric Type and Metric 153 [RFC7311] defines AIGP Attribute to represent basic IGP default 154 metric type and its cumulative value. 155 [I-D.ssangli-idr-bgp-generic-metric-aigp] defines extensions to the 156 AIGP attribute to carry Generic Metric sub-types, to meet more metric 157 types, such as Min Unidirectional delay metric defined in [RFC8570], 158 TE Default Metric defined in [RFC5305], Bandwidth Metric defined in 159 [I-D.ietf-lsr-flex-algo-bw-con], etc. 161 This document reuse the above definitions. 163 2.2. Extensions for Metric Credit 165 A new path attribute type (TBD): METRIC-CREDIT attribute, is 166 introduced in this document. It is an optional non-transitive 167 attribute, which is used to specify end-to-end total metric credit, 168 estimated BGP hop counts, and metric credit piece information. 170 The format of attribute value is shown below. 172 +----------------------------------------------------+ 173 | Count of Sources (1 octet) | 174 +----------------------------------------------------+ 175 | Flags (1 octet) | <--- 1st Source 176 +----------------------------------------------------+ 177 // Network Address of Source (variable) // 178 +----------------------------------------------------+ 179 | Total Metric Credit for Source (4 octets) | 180 +----------------------------------------------------+ 181 | Estimated BGP Hops Count for Source (1 octet) | 182 +----------------------------------------------------+ 183 // Current Hop Number (1 octet) // 184 +----------------------------------------------------+ 185 // Metric Credit Piece [Hops Count] (variable) // 186 +----------------------------------------------------+ 187 // ... For other Sources ... // <--- 2nd Source 188 +----------------------------------------------------+ 190 Figure 1: Metric Credit Path Attribute Format 192 Count of Sources (1 octet): Indicates how many sources (i.e. ingress 193 PE) have corresponding metric credit information. 195 Flags (1 octet): Currently three flags are defined. 197 0 1 2 3 4 5 6 7 198 +-+-+-+-+-+-+-+-+ 199 |S|F|P| | 200 +-+-+-+-+-+-+-+-+ 202 Figure 2 204 S-Flag: Source Address Flag. The Network Address of Source field 205 is included when S-Flag is set, and not included when unset. 207 F-Flag: Address Family Flag. Indicate the address family of the 208 Network Address of Source field. 0 for 32 bits IPv4 address, 1 for 209 128 bits IPv6 address. 211 P-Flag: Piece Flag. Indicates whether specific metric credit 212 piece information (Current Hop Number field and Metric Credit 213 Piece [] field) is included. 215 Network Address of Source (variable octets): Represents the IP 216 address of the source. When S-flag is 0, this field does not exist; 217 When S-flag is 1 and F-flag is 0, this field is a 32-bits IPv4 218 address; When S-flag is 1 and F-flag is 1, this field is a 128-bits 219 IPv6 address. If this field does not exist, it means that the metric 220 credit information is independent of the specific source. This 221 generally occurs in the scenario that want to control the 222 establishment of intent paths according to the metric credit in 223 coarse granularity. For example, in a small administrative domain, 224 when the egress PE advertise BGP intent routes to multiple ingress 225 PEs, only a single unified metric credit information for all source 226 is carried. 228 Total Metric Credit for Source (4 octets): Represents the total 229 metric credit from a specific ingress PE (or any source, when the 230 Network Address of Source field does not exist) to egress PE. 232 Estimated BGP Hops Count for Source (1 octet): Represents the 233 estimated number of BGP hops from a specific ingress PE (or any 234 source, when the Network Address of Source field does not exist) to 235 egress PE. Only those BGP speakers who modified BGP next hop to self 236 when receiving BGP intent route are counted. 238 Current Hop Number (1 octet): Represents the current index of the 239 array Metric Credit Piece[]. Note that when P-flag is 0, the 240 "Current Hop Number" and "Metric Credit Piece[]" fields do not exist. 241 In the BGP intent route advertisement originated from egress PE, the 242 initial value of Current Hop Number is 0; When the BGP intent route 243 advertisement received by an upstream BGP speaker and the BGP speaker 244 modifies the BGP next hop to self, it read the item from the array 245 Metric Credit Piece[] using Current Hop Number as index, to obtain 246 the metric credit piece that is available from the current BGP 247 speaker to the neighbor of the downstream BGP speaker. When the BGP 248 speaker continue to advertise the route to the upstream BGP speaker 249 neighbor and modify BGP next hop to self, it increase the Current Hop 250 Number by 1. Note that when using Current Hop Number as index to 251 read items from the array Metric Credit Piece[], it must avoid array 252 out of bounds. 254 Metric Credit Piece[] (variable octets): Is an array. The number of 255 items is specified by Estimated BGP Hops Count for Source. Each item 256 occupies 3 bytes (in microseconds) for each BGP speaker along the 257 intent path. There are strict restrictions on the use of Metric 258 Credit Piece[], i.e., BGP intent route must be advertised to a 259 specific ingress PE hop by hop in strict accordance with the 260 propagated path expected by egress PE. When an exception occurs, 261 e.g., a BGP speaker finds that the Current Hop Number value in the 262 received BGP intent route is greater than or equal to the Estimated 263 BGP Hops Count for Source value, then it must stop using Metric 264 Credit Piece[] for BGP next hop resolution. 266 3. Process of Received Metric Credit 268 When a BGP speaker receives BGP intent route with metric credit 269 information from neighbors, it obtains the intent identififer from 270 the route advertisement, looks up the intent template locally to 271 obtain the detailed intent information, and selects underlay path 272 according to the intent information. 274 The metric credit attribute information contained in the route 275 advertisement can provide a suggested metric credit value for this 276 BGP speaker to select underlay path destinated to the downstream 277 neighbor BGP speaker. 279 3.1. Only Total Metric Credit Provided 281 If the metric credit attribute only contains the total metric credit 282 related to the source, but does not contain the explicit metric 283 credit piece information, then for each source: 285 Let metric_residual_value = "Total Metric Credit for Source" - 286 "metric of AIGP Attribute" 287 Let average_metric_credit_value = "Total Metric Credit for Source" 288 / "Estimated BGP Hops Count for Source" 290 The suggested metric credit for the current segment is the minimum 291 value of metric_residual_value (note: negative values need to be 292 excluded) and average_metric_credit_value for all sources. 294 3.2. Metric Credit Piece Provided 296 If the BGP intent route advertisement also contains explicit metric 297 credit piece information, then: 299 Let explicit_metric_credit_piece_value = Metric Credit 300 Piece[Current Hop Number] 302 The suggested metric credit for the current segment is the minimum 303 value of metric_residual_value (note: negative values need to be 304 excluded) and explicit_metric_credit_piece_value for all sources. 306 It is recommonded that this option is mainly used in the case that 307 only a single source related metric credit piece information is 308 included in the intent route that is advertised to a single ingress 309 PE. Multiple source related metric credit piece information may 310 bring conflicts and cause inaccurate suggested metric credit. 312 To include explicit BGP speaker list in the route advertisement and 313 specify metric credit piece for each segment, will be described in 314 the next version. 316 3.3. Select Underlay Path According to Suggested Metric Credit 318 The purpose of suggested metric credit is to restrict that the 319 cumulative metric of the resolved underlay path cannot exceed the 320 expected value. However, in some cases, if the BGP speaker finds 321 that there is no underlay path that can meet the suggested value, 322 this constraint can be relaxed appropriately by local policy. 324 For the BGP intent route installed on the received BGP speaker, the 325 metric value is updated to the metric of AIGP attribute plus the 326 cumulative metric of the underlay path for the corresponding metric 327 type. 329 4. Examples 330 4.1. Example of Intent with Average Metric Credit 332 As shown in Figure 3, it contains two IGP domains. BGP neighbors are 333 established between PE1 and ABR, ABR and PE2, to advertise BGP intent 334 routes. Egress PE2 advertise its loopback route, loopback-PE2, to 335 ABR through BGP, and carries intent identifier and metric credit 336 attribute. 338 +---------P1---------+ +---------P4---------+ 339 / | \ / | \ 340 PE1---------P2----------ABR-----------P5----------PE2 341 \ | / \ | / 342 +---------P3---------+ +---------P6---------+ 344 |<---- IGP domain 1 ---->||<---- IGP domain 2 ---->| 346 TE-path-11: PE1-P1-ABR TE-path-12: ABR-P4-PE2 347 TE-path-21: PE1-P3-ABR TE-path-22: ABR-P6-PE2 349 Figure 3: Inter-area Intent Routing 351 There are two services to communicate between ingress PE1 and egress 352 PE2. The intent of the first service is that the end-to-end total 353 delay of the transport path used shall not exceed 10ms, for the 354 intent of the second service, it is 100ms. Since two intent aware 355 paths need to be instantiated between the same source/destination for 356 two services, in general, two intent identifiers, intent-1000 and 357 intent-2000, need to be configured on the egress PE2. 359 The intent-1000 template may have the following configuration: 361 metric-type: Unidirectional Link Delay (ms) 363 total-metric-credit: 10 (ms) 365 metric-credit enabled 367 The intent-2000 template may have the following configuration: 369 metric-type: Unidirectional Link Delay (ms) 371 total-metric-credit: 100 (ms) 373 metric-credit enabled 375 The above intent template are also configured in other BGP speakers 376 (i.e., ABR and PE1). However, it should be noted that since the 377 intent template contains the metric credit enabled command, these BGP 378 speakers, for the matched intent routes that are not originated from 379 themselvs, will not select the underlay path to the downstream BGP 380 speaker neighbor only according to the total metric contained in the 381 intent template. Instead, they should obtain the suggested metric 382 credit from the received BGP intent route, and then select the 383 appropriate underlay path that meets the suggested metric credit. 385 The total metric credit included in the intent template is mainly 386 used for egress PE2 to generate metric credit information that is 387 encoded in the originated intent route. Other BGP speakers (non 388 initiator) cannot directly use it to select underlay paths. 390 PE2 advertises two BGP intent routes, and , which are 392 advertised to ABR respectively. The BGP next hop in the advertised 393 route is set to PE2. 395 The metric related information encoded in is: 398 metric-type: Unidirectional Link Delay 400 metric: assume an initial value of 0 402 metric-credit information: 404 Count of Sources: 1 406 S-Flag = 1, F-Flag = 0, P-Flag = 0 408 Network Address of Source: loopback-PE1 410 Total Metric Credit for Source: 10 412 Estimated BGP Hops Count for Source: 2 414 Similarly, the metric related information encoded in is: 417 metric-type: Unidirectional Link Delay 419 metric: assume an initial value of 0 421 metric-credit information: 423 Count of Sources: 1 424 S-Flag = 1, F-Flag = 0, P-Flag = 0 426 Network Address of Source: loopback-PE1 428 Total Metric Credit for Source: 100 430 Estimated BGP Hops Count for Source: 2 432 After receiving the first route advetisement, ABR knows that the 433 suggested metric credit from itself to the downstream BGP speaker 434 neighbor PE2 is 5ms, i.e., the average metric credit 5, the residual 435 metric credit 10, taking the minimum one, then select an ultra-low 436 delay path not exceeding 5ms to progress PE2, assuming TE path-12 in 437 Figure 3. 439 After receiving the second route advetisement, ABR knows that the 440 suggested metric credit from itself to the downstream BGP speaker 441 neighbor PE2 is 50ms, i.e., the average metric credit 50, the 442 residual metric credit 100, taking the minimum one, then select a low 443 delay path not exceeding 50ms to progress PE2, assuming TE path-22 in 444 Figure 3. 446 ABR continues to advertise the above two BGP intent routes to the 447 upstream BGP speaker neighbor PE1, where the metric is accumulated by 448 the selected underlay path, the BGP next hop is modified to ABR, and 449 the metric credit information is unchanged. 451 After receiving the first route advetisement, PE1 knows that the 452 suggested metric credit from itself to the downstream BGP speaker 453 neighbor ABR is 5ms, i.e., the average metric credit 5, the residual 454 metric credit 6, taking the minimum one, then select an ultra-low 455 delay path to ABR, assuming TE path-11 in Figure 3. 457 After receiving the second route advetisement, PE1 knows that the 458 suggested metric credit from itself to the downstream BGP speaker 459 neighbor ABR is 50ms, i.e., the average metric credit 50, the 460 residual metric credit 60, taking the minimum one, then select a low 461 delay path to ABR, assuming TE path-12 in Figure 3. 463 4.2. Example of Intent with Metric Credit Piece 465 Based on the first example, assume that two IGP domains are managed 466 by a single provider, which is familiar with the performance of the 467 network, and the propagated path of BGP intent route is clear, then, 468 intent template may include explicit metric credit piece information. 470 Thus the intent routes originated from PE2 will contain more 471 information related with metric credit piece. 473 The metric related information encoded in is: 476 metric-type: Unidirectional Link Delay 478 metric: assume an initial value of 0 480 metric-credit information: 482 Count of Sources: 1 484 S-Flag = 1, F-Flag = 0, P-Flag = 1 486 Network Address of Source: loopback-PE1 488 Total Metric Credit for Source: 10 490 Estimated BGP Hops Count for Source: 2 492 Current Hop Number: 0 494 Metric Credit Piece [2]: [0] = 4, [1] = 6 496 Similarly, the metric related information encoded in is: 499 metric-type: Unidirectional Link Delay 501 metric: assume an initial value of 0 503 metric-credit information: 505 Count of Sources: 1 507 S-Flag = 1, F-Flag = 0, P-Flag = 1 509 Network Address of Source: loopback-PE1 511 Total Metric Credit for Source: 100 513 Estimated BGP Hops Count for Source: 2 515 Current Hop Number: 0 517 Metric Credit Piece [2]: [0] = 40, [1] = 60 519 After receiving the first route advetisement, ABR knows that the 520 suggested metric credit from itself to the downstream BGP speaker 521 neighbor ABR is 4ms, i.e., the explicit metric credit piece 4, the 522 residual metric credit 10, taking the minimum one, then select an 523 ultra-low delay path to PE2, assuming TE path-12 in Figure 3. 525 After receiving the second route advetisement, ABR knows that the 526 suggested metric credit from itself to the downstream BGP speaker 527 neighbor ABR is 40ms, i.e., the explicit metric credit piece 40, the 528 residual metric credit 100, taking the minimum one, then select a low 529 delay path to PE2, assuming TE path-22 in Figure 3. 531 ABR continues to advertise the above two BGP intent routes to the 532 upstream BGP speaker neighbor PE1, where the metric is accumulated by 533 the selected underlay path, the BGP next hop is modified to ABR, and 534 the Current Hop Number is incremented by 1. 536 After receiving the first route advetisement, PE1 knows that the 537 suggested metric credit from itself to the downstream BGP speaker 538 neighbor ABR is 6ms, i.e., the explicit metric credit piece 6, the 539 residual metric credit 6, taking the minimum one, then select an 540 ultra-low delay path to ABR, assuming TE path-11 in Figure 3. 542 After receiving the second route advetisement, PE1 knows that the 543 suggested metric credit from itself to the downstream BGP speaker 544 neighbor ABR is 60ms, i.e., the explicit metric credit piece 60, the 545 residual metric credit 60, taking the minimum one, then select a low 546 delay path to ABR, assuming TE path-12 in Figure 3. 548 4.3. Example of Intent Shared by Multiple Path 550 As shown in Figure 4, it contains three AS. BGP neighbors are 551 established between PE1 and ASBR1, ASBR1 and ASBR2, ASBR1 and ASBR3, 552 ASBR2 and PE2, ASBR3 and PE3, to advertise BGP intent routes carrying 553 intent identifier and metric credit attribute. 555 +---------P1---------+ +--------P4---------+ 556 / | \ / | \ 557 PE1---------P2----------ASBR1---ASBR2---------P5----------PE2 558 \ | / \ \ | / 559 +---------P3---------+ \ +--------P6---------+ 560 \ 561 \ 562 \ +---------P7---------+ 563 \ / | \ 564 +--ASBR3-------P8----------PE3 565 \ | / 566 +---------P9---------+ 567 TE-path-11:PE1-P1-ASBR1 TE-path-12:ASBR1-ASBR2 TE-path-13: ASBR2-P4-PE2 568 TE-path-21:PE1-P3-ASBR1 TE-path-22:ASBR1-ASBR3 TE-path-23: ASBR3-P7-PE3 570 Figure 4: Inter-AS Intent Routing 572 In this example, the same type of service needs to communicate 573 between PE1 and PE2, PE1 and pE3. The intent of this type of service 574 is the specific value related to the end-to-end total delay and 575 distance of the transport path used. 577 PE2 and pE3 will respectively config the intent templates with the 578 same intent identifier, e.g., intent-1000. 580 The intent-1000 template configured on PE2 have the following 581 configuration: 583 metric-type: Unidirectional Link Delay (ms) 585 total-metric-credit: 200 (ms) 587 metric-credit enabled 589 The intent-1000 template also configured on PE3 have the following 590 configuration: 592 metric-type: Unidirectional Link Delay (ms) 594 total-metric-credit: 300 (ms) 596 metric-credit enabled 598 PE2 advertises BGP intent route, , which is advertised to ASBR2. The metric related information 600 encoded is: 602 metric-type: Unidirectional Link Delay 603 metric: assume an initial value of 0 605 metric-credit information: 607 Count of Sources: 1 609 S-Flag = 1, F-Flag = 0, P-Flag = 0 611 Network Address of Source: loopback-PE1 613 Total Metric Credit for Source: 200 615 Estimated BGP Hops Count for Source: 3 617 Similarly, PE3 advertises BGP intent route, , which is advertised to ASBR3. The metric related 619 information encoded is: 621 metric-type: Unidirectional Link Delay 623 metric: assume an initial value of 0 625 metric-credit information: 627 Count of Sources: 1 629 S-Flag = 1, F-Flag = 0, P-Flag = 0 631 Network Address of Source: loopback-PE1 633 Total Metric Credit for Source: 300 635 Estimated BGP Hops Count for Source: 3 637 Then, ASBR2 and ASBR3 will use the suggested metric credit 66 and 638 100, taking minimum value from residual metric credit and average 639 metric credit, to select the transport path for and 641 respectively, assuming TE path-13 with cumulated metric 60 and TE 642 path-23 with cumulated metric 100 in Figure 4. 644 Similarly, ASBR1 will also use suggested metric credit 66 and 100, to 645 select the transport path for and respectively, 647 assuming TE path-12 with cumulated metric 10 and TE path-22 with 648 cumulated metric 10 in Figure 4. 650 Similarly, PE1 will also use suggested metric credit 66 and 100, to 651 select the transport path for and respectively, 653 assuming TE path-11 with cumulated metric 60 and TE path-21 with 654 cumulated metric 100 in Figure 4. 656 5. IANA Considerations 658 This document request the METRIC_CREDIT entry to the "BGP Path 659 Attributes" registry: 661 +=======+=========================+================+ 662 | Value | Code | Reference | 663 +=======+=========================+================+ 664 | TBD | METRIC_CREDIT | This Document | 665 +-------+-------------------------+----------------+ 667 6. Security Considerations 669 TBD 671 7. Acknowledgements 673 TBD 675 8. Normative References 677 [I-D.dskc-bess-bgp-car] 678 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 679 Steinberg, D., Jalil, L., Su, Y., Decraene, B., Guichard, 680 J., Patel, K., and H. Wang, "BGP Color-Aware Routing 681 (CAR)", draft-dskc-bess-bgp-car-03 (work in progress), 682 October 2021. 684 [I-D.ietf-lsr-flex-algo-bw-con] 685 Hegde, S., J, W. B. A., Shetty, R., Decraene, B., Psenak, 686 P., and T. Li, "Flexible Algorithms: Bandwidth, Delay, 687 Metrics and Constraints", draft-ietf-lsr-flex-algo-bw- 688 con-01 (work in progress), July 2021. 690 [I-D.kaliraj-idr-bgp-classful-transport-planes] 691 Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., 692 Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., and D. 693 J. Gowda, "BGP Classful Transport Planes", draft-kaliraj- 694 idr-bgp-classful-transport-planes-12 (work in progress), 695 August 2021. 697 [I-D.lp-lsr-bgp-algorithm] 698 Yao, L. and P. Shaofu, "Advertisement of Algorithm in 699 BGP", draft-lp-lsr-bgp-algorithm-00 (work in progress), 700 March 2021. 702 [I-D.ssangli-idr-bgp-generic-metric-aigp] 703 Sangli, S., Hegde, S., Das, R., and B. Decraene, "Generic 704 Metric for the AIGP attribute", draft-ssangli-idr-bgp- 705 generic-metric-aigp-01 (work in progress), July 2021. 707 [I-D.zhou-idr-inter-domain-lcu] 708 Chen, R., Dai, C., and S. Peng, "Inter-domain Network 709 Slicing via BGP-LU", draft-zhou-idr-inter-domain-lcu-02 710 (work in progress), January 2021. 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, 714 DOI 10.17487/RFC2119, March 1997, 715 . 717 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 718 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 719 2008, . 721 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 722 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 723 DOI 10.17487/RFC7311, August 2014, 724 . 726 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 727 "Advertisement of Multiple Paths in BGP", RFC 7911, 728 DOI 10.17487/RFC7911, July 2016, 729 . 731 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 732 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 733 May 2017, . 735 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 736 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 737 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 738 2019, . 740 Authors' Addresses 741 Shaofu Peng 742 ZTE Corporation 743 China 745 Email: peng.shaofu@zte.com.cn 747 Bin Tan 748 ZTE Corporation 749 China 751 Email: tan.bin@zte.com.cn