idnits 2.17.1 draft-ietf-idr-bgp-ls-flex-algo-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 : ---------------------------------------------------------------------------- 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 (January 6, 2020) is 1544 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) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-05 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-07 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing K. Talaulikar 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: July 9, 2020 S. Zandi 6 G. Dawra 7 LinkedIn 8 January 6, 2020 10 Flexible Algorithm Definition Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-flex-algo-02 13 Abstract 15 Flexible Algorithm is a solution that allows routing protocols (viz. 16 OSPF and IS-IS) to compute paths over a network based on user-defined 17 (and hence, flexible) constraints and metrics. The computation is 18 performed by routers participating in the specific network in a 19 distribute manner using a Flex Algorithm definition. This definition 20 provisioned on one or more routers and propagated (viz. OSPF and IS- 21 IS flooding) through the network. 23 BGP Link-State (BGP-LS) enables the collection of various topology 24 information from the network. This draft defines extensions to BGP- 25 LS address-family to advertise the Flexible Algorithm Definition as a 26 part of the topology information from the network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 9, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. BGP-LS Extensions for Flex Algo . . . . . . . . . . . . . . . 4 65 3. Flexible Algorithm Definition . . . . . . . . . . . . . . . . 4 66 3.1. Flex Algo Exclude Any Affinity . . . . . . . . . . . . . 6 67 3.2. Flex Algo Include Any Affinity . . . . . . . . . . . . . 6 68 3.3. Flex Algo Include All Affinity . . . . . . . . . . . . . 7 69 3.4. Flex Algo Definition Flags . . . . . . . . . . . . . . . 8 70 4. Flex Algorithm Prefix Metric . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Manageability Considerations . . . . . . . . . . . . . . . . 10 73 6.1. Operational Considerations . . . . . . . . . . . . . . . 10 74 6.2. Management Considerations . . . . . . . . . . . . . . . . 11 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 IGP protocols (OSPF and IS-IS) traditionally compute best paths over 85 the network based on the IGP metric assigned to the links. Many 86 network deployments use RSVP-TE [RFC3209] based or Segment Routing 87 (SR) Policy [I-D.ietf-spring-segment-routing-policy] based solutions 88 to enforce traffic over a path that is computed using different 89 metrics or constraints than the shortest IGP path. 90 [I-D.ietf-lsr-flex-algo] defines the Flexible Algorithm solution that 91 allows IGPs themselves to compute constraint based paths over the 92 network. 94 Flexible Algorithm is called so as it allows a user the flexibility 95 to define 97 o the type of calculation to be used (e.g. shortest path) 99 o the metric type to be used (e.g. IGP metric or TE metric) 101 o the set of constraints to be used (e.g. inclusion or exclusion of 102 certain links using affinities) 104 The operations of the flexible algorithm solution is described in 105 detail in [I-D.ietf-lsr-flex-algo] and a high level summary of the 106 same is described here for clarity. The network operator enables the 107 participation of specific nodes in the network for a specific 108 algorithm and then provisions the definition of that flexible 109 algorithm on one or more of these nodes. The nodes where the 110 flexible algorithm definition (FAD) is advertised then flood these 111 definitions via respective IGP (IS-IS and OSPFv2/v3) mechanisms to 112 all other nodes in the network. The nodes select the definition for 113 each algorithm based on the flooded information in a deterministic 114 manner and thus all nodes participating in a flexible algorithm 115 computation arrive at a common understanding of the type of 116 calculation that they need to use. 118 When using Segment Routing (SR) [RFC8402] MPLS forwarding plane 119 [RFC8660], the result of a flex algorithm computation is the 120 provisioning of the Prefix SIDs associated with that algorithm with 121 paths based on the topology computed based on that algorithm. When 122 using SR forwarding plane on IPv6 (SRv6) 123 [I-D.ietf-spring-srv6-network-programming], the result of a flex 124 algorithm computation is the provisioning of the SRv6 Locators 125 associated with that algorithm with paths based on the topology 126 computed based on that algorithm. This flex algorithm computation is 127 within an IGP area or level similar to the default shortest path tree 128 (SPT) algorithm. 130 A flex algorithm specific metric MAY be advertised along with the 131 prefix as described in [I-D.ietf-lsr-flex-algo] to enable end-to-end 132 optimal path computation for prefixes across multiple areas/domains 133 in the flex algorithm computation for the SR-MPLS forwarding plane. 135 The BGP-LS extensions for SR are defined in 136 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and 137 [I-D.ietf-idr-bgpls-srv6-ext]. They include the 139 o SR Algorithm TLV to indicate the participation of a node in a flex 140 algorithm computation 142 o Prefix SID TLV to indicate the association of the Prefix-SIDs to a 143 specific flex algorithm for SR-MPLS forwarding 145 o SRv6 Locator TLV to indicate the Locator for specific flex 146 algorithm for SRv6 forwarding 148 Thus a controller or a Path Computation Engine (PCE) is aware of the 149 IGP topology across multiple domains which includes the above 150 information related to the flexible algorithm. This draft defines 151 extensions to BGP-LS for carrying the Flexible Algorithm Definition 152 information so that it enables the controller/PCE to learn the 153 mapping of the flex algorithm number to its definition in each area/ 154 domain of the underlying IGP. The controller/PCE also learns the 155 type of computation used and the constraints for the same. This 156 information can then be leveraged by it for setting up SR Policy 157 paths end to end across domains by leveraging the appropriate Flex 158 Algorithm specific SIDs in the in its Segment List 159 [I-D.ietf-spring-segment-routing-policy]. e.g. picking the Flex 160 Algorithm Prefix SID (in case of SR-MPLS) or End SID (in case of 161 SRv6) of ABRs/ASBRs corresponding to a definition that optimizes on 162 the delay metric enables the PCE/controller to build an end to end 163 low latency path across IGP domains with minimal SIDs in the SID 164 list. 166 1.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 2. BGP-LS Extensions for Flex Algo 176 The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of 177 nodes along with their attributes using the BGP-LS Attribute and the 178 Prefix NLRI for advertisement of prefixes along with their attributes 179 using the BGP-LS Attribute. The Flexible Algorithm Definition (FAD) 180 advertised by a node are considered as its node level attributes and 181 advertised as such. The Flexible Algorithm Prefix Metric (FAPM) are 182 considered as prefix attributes and advertised as such. 184 3. Flexible Algorithm Definition 186 This document defines a new optional BGP-LS Attribute TLV associated 187 with the Node NLRI called the Flexible Algorithm Definition (FAD) TLV 188 and its format is as follows: 190 0 1 2 3 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 |Flex-Algorithm | Metric-Type | Calc-Type | Priority | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | sub-TLVs ... // 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 1: Flex Algorithm Definition TLV 202 where: 204 o Type: 1039 206 o Length: variable. Minimum of 4 octets. 208 o Flex-Algorithm : 1 octet value in the range between 128 and 255 209 inclusive which is the range defined for Flexible Algorithms in 210 the IANA "IGP Parameters" registries under the "IGP Algorithm 211 Types" registry [I-D.ietf-lsr-flex-algo]. 213 o Metric-Type : 1 octet value indicating the type of the metric used 214 in the computation. Values allowed come from the IANA "IGP 215 Parameters" registries under the "Flexible Algorithm Definition 216 Metric-Type" registry [I-D.ietf-lsr-flex-algo]. 218 o Calculation-Type : 1 octet value in the range between 0 and 127 219 inclusive which is the range defined for the standard algorithms 220 in the IANA "IGP Parameters" registries under the "IGP Algorithm 221 Types" registry [I-D.ietf-lsr-flex-algo]. 223 o Priority : 1 octet value between 0 and 255 inclusive that 224 specifies the priority of the FAD. 226 o sub-TLVs : zero or more sub-TLVs may be included as described 227 further in this section. 229 The FAD TLV can only be added to the BGP-LS Attribute of the Node 230 NLRI if the corresponding node originates the underlying IGP TLV/sub- 231 TLV as described below. This information is derived from the 232 protocol specific advertisements as below.. 234 o IS-IS, as defined by the ISIS Flexible Algorithm Definition sub- 235 TLV in [I-D.ietf-lsr-flex-algo]. 237 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm 238 Definition TLV in [I-D.ietf-lsr-flex-algo]. 240 The BGP-LS Attribute associated with a Node NLRI MAY include one or 241 more FAD TLVs corresponding to the Flexibile Algorithm Definition for 242 each algorithm that the particular node is advertising. 244 The following sub-sections define the sub-TLVs for the FAD TLV. 246 3.1. Flex Algo Exclude Any Affinity 248 The Flex Algo Exclude Any Affinity sub-TLV is an optional sub-TLV 249 that is used to carry the affinity constraints [RFC2702] associated 250 with the flex algo definition and enable the exclusion of links 251 carrying any of the specified affinities from the computation of the 252 specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The 253 affinity is expressed in terms of Extended Admin Group (EAG) as 254 defined in [RFC7308]. 256 The TLV has the following format: 258 0 1 2 3 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Exclude-Any EAG (variable) // 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 where: 268 o Type: 1040 270 o Length: variable, dependent on the size of the Extended Admin 271 Group. MUST be a multiple of 4 octets. 273 o Exclude-Any EAG : the bitmask used to represent the affinities to 274 be excluded. 276 The information in the Flex Algo Exclude Any Affinity sub-TLV is 277 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 278 Exclude Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 280 3.2. Flex Algo Include Any Affinity 282 The Flex Algo Incude Any Affinity sub-TLV is an optional sub-TLV that 283 is used to carry the affinity constraints [RFC2702] associated with 284 the flex algo definition and enable the inclusion of links carrying 285 any of the specified affinities in the computation of the specific 286 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 287 expressed in terms of Extended Admin Group (EAG) as defined in 288 [RFC7308]. 290 The TLV has the following format: 292 0 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Include-Any EAG (variable) // 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 where: 302 o Type: 1041 304 o Length: variable, dependent on the size of the Extended Admin 305 Group. MUST be a multiple of 4 octets. 307 o Include-Any EAG : the bitmask used to represent the affinities to 308 be included. 310 The information in the Flex Algo Include Any Affinity sub-TLV is 311 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 312 Include-Any Admin Group sub-TLV as defined in 313 [I-D.ietf-lsr-flex-algo]. 315 3.3. Flex Algo Include All Affinity 317 The Flex Algo Incude All Affinity sub-TLV is an optional sub-TLV that 318 is used to carry the affinity constraints [RFC2702] associated with 319 the flex algo definition and enable the inclusion of links carrying 320 all of the specified affinities in the computation of the specific 321 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 322 expressed in terms of Extended Admin Group (EAG) as defined in 323 [RFC7308]. 325 The TLV has the following format: 327 0 1 2 3 328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Include-All EAG (variable) // 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 where: 337 o Type: 1042 339 o Length: variable, dependent on the size of the Extended Admin 340 Group. MUST be a multiple of 4 octets. 342 o Include-All EAG : the bitmask used to represent the affinities to 343 be included. 345 The information in the Flex Algo Include All Affinity sub-TLV is 346 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 347 Include-All Admin Group sub-TLV as defined in 348 [I-D.ietf-lsr-flex-algo]. 350 3.4. Flex Algo Definition Flags 352 The Flex Algo Definition Flags sub-TLV is an optional sub-TLV that is 353 used to carry the flags associated with the flex algo definition that 354 are used in the computation of the specific algorithm as described in 355 [I-D.ietf-lsr-flex-algo]. 357 The TLV has the following format: 359 0 1 2 3 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Flags (variable) // 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 where: 369 o Type: 1043 371 o Length: variable. MUST be a multiple of 4 octets. 373 o Flags : the bitmask used to represent the flags for the flex 374 algorithm definition as introduced by [I-D.ietf-lsr-flex-algo] and 375 listed in the "Flex-Algorithm Definition Flags" registry under the 376 "Interior Gateway Protocol (IGP) Parameters" IANA registry. 378 The information in the Flex Algo Definition Flags sub-TLV is derived 379 from the IS-IS and OSPF protocol specific Flexible Algorithm 380 Definition Flags sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 382 4. Flex Algorithm Prefix Metric 384 This document defines a new optional BGP-LS Attribute TLV associated 385 with the Prefix NLRI called the Flexible Algorithm Prefix Metric 386 (FAPM) TLV and its format is as follows: 388 0 1 2 3 389 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |Flex-Algorithm | Reserved | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Metric | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 where: 400 o Type: 1044 402 o Length: 8 octets. 404 o Flex-Algorithm : 1 octet value in the range between 128 and 255 405 inclusive which is the range defined for Flexible Algorithms in 406 the IANA "IGP Parameters" registries under the "IGP Algorithm 407 Types" registry [I-D.ietf-lsr-flex-algo]. 409 o Reserved : 3 octet value that SHOULD be set to 0 by the originator 410 and MUST be ignored by the receiver. 412 o Metric : 4 octets field to carry the metric information. 414 The FAPM TLV can be added to the BGP-LS Attribute of the Prefix NLRI 415 orginated by a node, only if the corresponding node originates the 416 Prefix in along with the underlying IGP TLV/sub-TLV as described 417 below. This information is derived from the protocol specific 418 advertisements as below. 420 o IS-IS, as defined by the ISIS Flexible Algorithm Prefix Metric 421 sub-TLV in [I-D.ietf-lsr-flex-algo]. 423 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm Prefix 424 Metric sub-TLV in [I-D.ietf-lsr-flex-algo]. 426 The BGP-LS Attribute associated with a Prefix NLRI MAY include one or 427 more FAPM TLVs corresponding to the Flexibile Algorithm Prefix Metric 428 for each algorithm associated with that the particular prefix. 430 5. IANA Considerations 432 This document requests assigning code-points from the registry "BGP- 433 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 434 TLVs" based on table below which reflects the values assigned via the 435 early allocation process. The column "IS-IS TLV/Sub-TLV" defined in 436 the registry does not require any value and should be left empty. 438 +------------+----------------------------------------+----------+ 439 | Code Point | Description | Length | 440 +------------+----------------------------------------+----------+ 441 | 1039 | Flex Algorithm Definition TLV | variable | 442 | 1040 | Flex Algo Exclude Any Affinity sub-TLV | variable | 443 | 1041 | Flex Algo Include Any Affinity sub-TLV | variable | 444 | 1042 | Flex Algo Include All Affinity sub-TLV | variable | 445 | 1043 | Flex Algo Definition Flags sub-TLV | variable | 446 | 1044 | Flex Algorithm Prefix Metric TLV | variable | 447 +------------+----------------------------------------+----------+ 449 6. Manageability Considerations 451 This section is structured as recommended in [RFC5706]. 453 The new protocol extensions introduced in this document augment the 454 existing IGP topology information that was distributed via [RFC7752]. 455 Procedures and protocol extensions defined in this document do not 456 affect the BGP protocol operations and management other than as 457 discussed in the Manageability Considerations section of [RFC7752]. 458 Specifically, the malformed NLRIs attribute tests in the Fault 459 Management section of [RFC7752] now encompass the new TLVs for the 460 BGP-LS NLRI in this document. 462 6.1. Operational Considerations 464 No additional operation considerations are defined in this document. 466 6.2. Management Considerations 468 No additional management considerations are defined in this document. 470 7. Security Considerations 472 The new protocol extensions introduced in this document augment the 473 existing IGP topology information that was distributed via [RFC7752]. 474 Procedures and protocol extensions defined in this document do not 475 affect the BGP security model other than as discussed in the Security 476 Considerations section of [RFC7752]. 478 8. Acknowledgements 480 The authors would like to thank Les Ginsberg for his reviews and 481 contributions to this work. 483 9. References 485 9.1. Normative References 487 [I-D.ietf-lsr-flex-algo] 488 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 489 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 490 algo-05 (work in progress), November 2019. 492 [I-D.ietf-spring-srv6-network-programming] 493 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 494 Matsushima, S., and Z. Li, "SRv6 Network Programming", 495 draft-ietf-spring-srv6-network-programming-07 (work in 496 progress), December 2019. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 504 S. Ray, "North-Bound Distribution of Link-State and 505 Traffic Engineering (TE) Information Using BGP", RFC 7752, 506 DOI 10.17487/RFC7752, March 2016, 507 . 509 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 510 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 511 May 2017, . 513 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 514 Decraene, B., Litkowski, S., and R. Shakir, "Segment 515 Routing with the MPLS Data Plane", RFC 8660, 516 DOI 10.17487/RFC8660, December 2019, 517 . 519 9.2. Informative References 521 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 522 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 523 and M. Chen, "BGP Link-State extensions for Segment 524 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 525 (work in progress), June 2019. 527 [I-D.ietf-idr-bgpls-srv6-ext] 528 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 529 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 530 State Extensions for SRv6", draft-ietf-idr-bgpls- 531 srv6-ext-01 (work in progress), July 2019. 533 [I-D.ietf-spring-segment-routing-policy] 534 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 535 P. Mattes, "Segment Routing Policy Architecture", draft- 536 ietf-spring-segment-routing-policy-06 (work in progress), 537 December 2019. 539 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 540 McManus, "Requirements for Traffic Engineering Over MPLS", 541 RFC 2702, DOI 10.17487/RFC2702, September 1999, 542 . 544 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 545 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 546 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 547 . 549 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 550 Management of New Protocols and Protocol Extensions", 551 RFC 5706, DOI 10.17487/RFC5706, November 2009, 552 . 554 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 555 Traffic Engineering (MPLS-TE)", RFC 7308, 556 DOI 10.17487/RFC7308, July 2014, 557 . 559 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 560 Decraene, B., Litkowski, S., and R. Shakir, "Segment 561 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 562 July 2018, . 564 Authors' Addresses 566 Ketan Talaulikar 567 Cisco Systems 568 India 570 Email: ketant@cisco.com 572 Peter Psenak 573 Cisco Systems 574 Slovakia 576 Email: ppsenak@cisco.com 578 Shawn Zandi 579 LinkedIn 580 USA 582 Email: szandi@linkedin.com 584 Gaurav Dawra 585 LinkedIn 586 USA 588 Email: gdawra.ietf@gmail.com