idnits 2.17.1 draft-ietf-idr-bgp-ls-flex-algo-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 (July 8, 2019) is 1748 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-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 ** 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-03 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: January 9, 2020 S. Zandi 6 G. Dawra 7 LinkedIn 8 July 8, 2019 10 Flexible Algorithm Definition Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-flex-algo-01 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 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 9, 2020. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. BGP-LS Extensions for Flex Algo . . . . . . . . . . . . . . . 4 72 3. Flexible Algorithm Definition . . . . . . . . . . . . . . . . 4 73 3.1. Flex Algo Exclude Any Affinity . . . . . . . . . . . . . 6 74 3.2. Flex Algo Include Any Affinity . . . . . . . . . . . . . 6 75 3.3. Flex Algo Include All Affinity . . . . . . . . . . . . . 7 76 3.4. Flex Algo Definition Flags . . . . . . . . . . . . . . . 8 77 4. Flex Algorithm Prefix Metric . . . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 6. Manageability Considerations . . . . . . . . . . . . . . . . 10 80 6.1. Operational Considerations . . . . . . . . . . . . . . . 10 81 6.2. Management Considerations . . . . . . . . . . . . . . . . 10 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 9.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 IGP protocols (OSPF and IS-IS) traditionally compute best paths over 92 the network based on the IGP metric assigned to the links. Many 93 network deployments use RSVP-TE [RFC3209] based or Segment Routing 94 (SR) Policy [I-D.ietf-spring-segment-routing-policy] based solutions 95 to enforce traffic over a path that is computed using different 96 metrics or constraints than the shortest IGP path. 97 [I-D.ietf-lsr-flex-algo] defines the Flexible Algorithm solution that 98 allows IGPs themselves to compute constraint based paths over the 99 network. 101 Flexible Algorithm is called so as it allows a user the flexibility 102 to define 104 o the type of calculation to be used (e.g. shortest path) 106 o the metric type to be used (e.g. IGP metric or TE metric) 108 o the set of constraints to be used (e.g. inclusion or exclusion of 109 certain links using affinities) 111 The operations of the flexible algorithm solution is described in 112 detail in [I-D.ietf-lsr-flex-algo] and a high level summary of the 113 same is described here for clarity. The network operator enables the 114 participation of specific nodes in the network for a specific 115 algorithm and then provisions the definition of that flexible 116 algorithm on one or more of these nodes. The nodes where the 117 flexible algorithm definition (FAD) is advertised then flood these 118 definitions via respective IGP (IS-IS and OSPFv2/v3) mechanisms to 119 all other nodes in the network. The nodes select the definition for 120 each algorithm based on the flooded information in a deterministic 121 manner and thus all nodes participating in a flexible algorithm 122 computation arrive at a common understanding of the type of 123 calculation that they need to use. 125 When using Segment Routing (SR) [RFC8402] MPLS forwarding plane 126 [I-D.ietf-spring-segment-routing-mpls], the result of a flex 127 algorithm computation is the provisioning of the Prefix SIDs 128 associated with that algorithm with paths based on the topology 129 computed based on that algorithm. When using SR forwarding plane on 130 IPv6 (SRv6) [I-D.ietf-spring-srv6-network-programming], the result of 131 a flex algorithm computation is the provisioning of the SRv6 Locators 132 associated with that algorithm with paths based on the topology 133 computed based on that algorithm. This flex algorithm computation is 134 within an IGP area or level similar to the default shortest path tree 135 (SPT) algorithm. 137 A flex algorithm specific metric MAY be advertised along with the 138 prefix as described in [I-D.ietf-lsr-flex-algo] to enable end-to-end 139 optimal path computation for prefixes across multiple areas/domains 140 in the flex algorithm computation for the SR-MPLS forwarding plane. 142 The BGP-LS extensions for SR are defined in 143 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and 144 [I-D.ietf-idr-bgpls-srv6-ext]. They include the 146 o SR Algorithm TLV to indicate the participation of a node in a flex 147 algorithm computation 149 o Prefix SID TLV to indicate the association of the Prefix-SIDs to a 150 specific flex algorithm for SR-MPLS forwarding 152 o SRv6 Locator TLV to indicate the Locator for specific flex 153 algorithm for SRv6 forwarding 155 Thus a controller or a Path Computation Engine (PCE) is aware of the 156 IGP topology across multiple domains which includes the above 157 information related to the flexible algorithm. This draft defines 158 extensions to BGP-LS for carrying the Flexible Algorithm Definition 159 information so that it enables the controller/PCE to learn the 160 mapping of the flex algorithm number to its definition in each area/ 161 domain of the underlying IGP. The controller/PCE also learns the 162 type of computation used and the constraints for the same. This 163 information can then be leveraged by it for setting up SR Policy 164 paths end to end across domains by leveraging the appropriate Flex 165 Algorithm specific SIDs in the in its Segment List 166 [I-D.ietf-spring-segment-routing-policy]. e.g. picking the Flex 167 Algorithm Prefix SID (in case of SR-MPLS) or End SID (in case of 168 SRv6) of ABRs/ASBRs corresponding to a definition that optimizes on 169 the delay metric enables the PCE/controller to build an end to end 170 low latency path across IGP domains with minimal SIDs in the SID 171 list. 173 2. BGP-LS Extensions for Flex Algo 175 The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of 176 nodes along with their attributes using the BGP-LS Attribute and the 177 Prefix NLRI for advertisement of prefixes along with their attributes 178 using the BGP-LS Attribute. The Flexible Algorithm Definition (FAD) 179 advertised by a node are considered as its node level attributes and 180 advertised as such. The Flexible Algorithm Prefix Metric (FAPM) are 181 considered as prefix attributes and advertised as such. 183 3. Flexible Algorithm Definition 185 This document defines a new optional BGP-LS Attribute TLV associated 186 with the Node NLRI called the Flexible Algorithm Definition (FAD) TLV 187 and its format is as follows: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |Flex-Algorithm | Metric-Type | Calc-Type | Priority | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | sub-TLVs ... // 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: Flex Algorithm Definition TLV 201 where: 203 o Type: TBD (see IANA Considerations Section 5) 205 o Length: variable. Minimum of 4 octets. 207 o Flex-Algorithm : 1 octet value in the range between 128 and 255 208 inclusive which is the range defined for Flexible Algorithms in 209 the IANA "IGP Parameters" registries under the "IGP Algorithm 210 Types" registry [I-D.ietf-lsr-flex-algo]. 212 o Metric-Type : 1 octet value indicating the type of the metric used 213 in the computation. Values allowed come from the IANA "IGP 214 Parameters" registries under the "Flexible Algorithm Definition 215 Metric-Type" registry [I-D.ietf-lsr-flex-algo]. 217 o Calculation-Type : 1 octet value in the range between 0 and 127 218 inclusive which is the range defined for the standard algorithms 219 in the IANA "IGP Parameters" registries under the "IGP Algorithm 220 Types" registry [I-D.ietf-lsr-flex-algo]. 222 o Priority : 1 octet value between 0 and 255 inclusive that 223 specifies the priority of the FAD. 225 o sub-TLVs : zero or more sub-TLVs may be included as described 226 further in this section. 228 The FAD TLV can only be added to the BGP-LS Attribute of the Node 229 NLRI if the corresponding node originates the underlying IGP TLV/sub- 230 TLV as described below. This information is derived from the 231 protocol specific advertisements as below.. 233 o IS-IS, as defined by the ISIS Flexible Algorithm Definition sub- 234 TLV in [I-D.ietf-lsr-flex-algo]. 236 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm 237 Definition TLV in [I-D.ietf-lsr-flex-algo]. 239 The BGP-LS Attribute associated with a Node NLRI MAY include one or 240 more FAD TLVs corresponding to the Flexibile Algorithm Definition for 241 each algorithm that the particular node is advertising. 243 The following sub-sections define the sub-TLVs for the FAD TLV. 245 3.1. Flex Algo Exclude Any Affinity 247 The Flex Algo Exclude Any Affinity sub-TLV is an optional sub-TLV 248 that is used to carry the affinity constraints [RFC2702] associated 249 with the flex algo definition and enable the exclusion of links 250 carrying any of the specified affinities from the computation of the 251 specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The 252 affinity is expressed in terms of Extended Admin Group (EAG) as 253 defined in [RFC7308]. 255 The TLV has the following format: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Exclude-Any EAG (variable) // 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 where: 267 o Type: TBD (see IANA Considerations Section 5) 269 o Length: variable, dependent on the size of the Extended Admin 270 Group. MUST be a multiple of 4 octets. 272 o Exclude-Any EAG : the bitmask used to represent the affinities to 273 be excluded. 275 The information in the Flex Algo Exclude Any Affinity sub-TLV is 276 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 277 Exclude Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 279 3.2. Flex Algo Include Any Affinity 281 The Flex Algo Incude Any Affinity sub-TLV is an optional sub-TLV that 282 is used to carry the affinity constraints [RFC2702] associated with 283 the flex algo definition and enable the inclusion of links carrying 284 any of the specified affinities in the computation of the specific 285 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 286 expressed in terms of Extended Admin Group (EAG) as defined in 287 [RFC7308]. 289 The TLV has the following format: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Include-Any EAG (variable) // 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 where: 301 o Type: TBD (see IANA Considerations Section 5) 303 o Length: variable, dependent on the size of the Extended Admin 304 Group. MUST be a multiple of 4 octets. 306 o Include-Any EAG : the bitmask used to represent the affinities to 307 be included. 309 The information in the Flex Algo Include Any Affinity sub-TLV is 310 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 311 Include-Any Admin Group sub-TLV as defined in 312 [I-D.ietf-lsr-flex-algo]. 314 3.3. Flex Algo Include All Affinity 316 The Flex Algo Incude All Affinity sub-TLV is an optional sub-TLV that 317 is used to carry the affinity constraints [RFC2702] associated with 318 the flex algo definition and enable the inclusion of links carrying 319 all of the specified affinities in the computation of the specific 320 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 321 expressed in terms of Extended Admin Group (EAG) as defined in 322 [RFC7308]. 324 The TLV has the following format: 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type | Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Include-All EAG (variable) // 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 where: 336 o Type: TBD (see IANA Considerations Section 5) 338 o Length: variable, dependent on the size of the Extended Admin 339 Group. MUST be a multiple of 4 octets. 341 o Include-All EAG : the bitmask used to represent the affinities to 342 be included. 344 The information in the Flex Algo Include All Affinity sub-TLV is 345 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 346 Include-All Admin Group sub-TLV as defined in 347 [I-D.ietf-lsr-flex-algo]. 349 3.4. Flex Algo Definition Flags 351 The Flex Algo Definition Flags sub-TLV is an optional sub-TLV that is 352 used to carry the flags associated with the flex algo definition that 353 are used in the computation of the specific algorithm as described in 354 [I-D.ietf-lsr-flex-algo]. 356 The TLV has the following format: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Flags (variable) // 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 where: 368 o Type: TBD (see IANA Considerations Section 5) 370 o Length: variable. MUST be a multiple of 4 octets. 372 o Flags : the bitmask used to represent the flags for the flex 373 algorithm definition as introduced by [I-D.ietf-lsr-flex-algo] and 374 listed in the "Flex-Algorithm Definition Flags" registry under the 375 "Interior Gateway Protocol (IGP) Parameters" IANA registry. 377 The information in the Flex Algo Definition Flags sub-TLV is derived 378 from the IS-IS and OSPF protocol specific Flexible Algorithm 379 Definition Flags sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 381 4. Flex Algorithm Prefix Metric 383 This document defines a new optional BGP-LS Attribute TLV associated 384 with the Prefix NLRI called the Flexible Algorithm Prefix Metric 385 (FAPM) TLV and its format is as follows: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Type | Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |Flex-Algorithm | Reserved | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Metric | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 where: 399 o Type: TBD (see IANA Considerations Section 5) 401 o Length: 8 octets. 403 o Flex-Algorithm : 1 octet value in the range between 128 and 255 404 inclusive which is the range defined for Flexible Algorithms in 405 the IANA "IGP Parameters" registries under the "IGP Algorithm 406 Types" registry [I-D.ietf-lsr-flex-algo]. 408 o Reserved : 3 octet value that SHOULD be set to 0 by the originator 409 and MUST be ignored by the receiver. 411 o Metric : 4 octets field to carry the metric information. 413 The FAPM TLV can be added to the BGP-LS Attribute of the Prefix NLRI 414 orginated by a node, only if the corresponding node originates the 415 Prefix in along with the underlying IGP TLV/sub-TLV as described 416 below. This information is derived from the protocol specific 417 advertisements as below. 419 o IS-IS, as defined by the ISIS Flexible Algorithm Prefix Metric 420 sub-TLV in [I-D.ietf-lsr-flex-algo]. 422 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm Prefix 423 Metric sub-TLV in [I-D.ietf-lsr-flex-algo]. 425 The BGP-LS Attribute associated with a Prefix NLRI MAY include one or 426 more FAPM TLVs corresponding to the Flexibile Algorithm Prefix Metric 427 for each algorithm associated with that the particular prefix. 429 5. IANA Considerations 431 This document requests assigning code-points from the registry "BGP- 432 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 433 TLVs" based on table below. The column "IS-IS TLV/Sub-TLV" defined 434 in the registry does not require any value and should be left empty. 436 +------------+----------------------------------------+----------+ 437 | Code Point | Description | Length | 438 +------------+----------------------------------------+----------+ 439 | TBD | Flex Algorithm Definition TLV | variable | 440 | TBD | Flex Algo Exclude Any Affinity sub-TLV | variable | 441 | TBD | Flex Algo Include Any Affinity sub-TLV | variable | 442 | TBD | Flex Algo Include All Affinity sub-TLV | variable | 443 | TBD | Flex Algo Definition Flags sub-TLV | variable | 444 | TBD | Flex Algorithm Prefix Metric TLV | variable | 445 +------------+----------------------------------------+----------+ 447 6. Manageability Considerations 449 This section is structured as recommended in [RFC5706]. 451 The new protocol extensions introduced in this document augment the 452 existing IGP topology information that was distributed via [RFC7752]. 453 Procedures and protocol extensions defined in this document do not 454 affect the BGP protocol operations and management other than as 455 discussed in the Manageability Considerations section of [RFC7752]. 456 Specifically, the malformed NLRIs attribute tests in the Fault 457 Management section of [RFC7752] now encompass the new TLVs for the 458 BGP-LS NLRI in this document. 460 6.1. Operational Considerations 462 No additional operation considerations are defined in this document. 464 6.2. Management Considerations 466 No additional management considerations are defined in this document. 468 7. Security Considerations 470 The new protocol extensions introduced in this document augment the 471 existing IGP topology information that was distributed via [RFC7752]. 472 Procedures and protocol extensions defined in this document do not 473 affect the BGP security model other than as discussed in the Security 474 Considerations section of [RFC7752]. 476 8. Acknowledgements 478 The authors would like to thank Les Ginsberg for his reviews and 479 contributions to this work. 481 9. References 483 9.1. Normative References 485 [I-D.ietf-lsr-flex-algo] 486 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 487 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 488 algo-03 (work in progress), July 2019. 490 [I-D.ietf-spring-segment-routing-mpls] 491 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 492 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 493 data plane", draft-ietf-spring-segment-routing-mpls-22 494 (work in progress), May 2019. 496 [I-D.ietf-spring-srv6-network-programming] 497 Filsfils, C., Camarillo, P., Leddy, J., 498 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 499 Network Programming", draft-ietf-spring-srv6-network- 500 programming-01 (work in progress), July 2019. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 508 S. Ray, "North-Bound Distribution of Link-State and 509 Traffic Engineering (TE) Information Using BGP", RFC 7752, 510 DOI 10.17487/RFC7752, March 2016, 511 . 513 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 514 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 515 May 2017, . 517 9.2. Informative References 519 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 520 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 521 and M. Chen, "BGP Link-State extensions for Segment 522 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 523 (work in progress), June 2019. 525 [I-D.ietf-idr-bgpls-srv6-ext] 526 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 527 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 528 State Extensions for SRv6", draft-ietf-idr-bgpls- 529 srv6-ext-01 (work in progress), July 2019. 531 [I-D.ietf-spring-segment-routing-policy] 532 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 533 bogdanov@google.com, b., and P. Mattes, "Segment Routing 534 Policy Architecture", draft-ietf-spring-segment-routing- 535 policy-03 (work in progress), May 2019. 537 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 538 McManus, "Requirements for Traffic Engineering Over MPLS", 539 RFC 2702, DOI 10.17487/RFC2702, September 1999, 540 . 542 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 543 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 544 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 545 . 547 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 548 Management of New Protocols and Protocol Extensions", 549 RFC 5706, DOI 10.17487/RFC5706, November 2009, 550 . 552 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 553 Traffic Engineering (MPLS-TE)", RFC 7308, 554 DOI 10.17487/RFC7308, July 2014, 555 . 557 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 558 Decraene, B., Litkowski, S., and R. Shakir, "Segment 559 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 560 July 2018, . 562 Authors' Addresses 564 Ketan Talaulikar 565 Cisco Systems 566 India 568 Email: ketant@cisco.com 570 Peter Psenak 571 Cisco Systems 572 Slovakia 574 Email: ppsenak@cisco.com 576 Shawn Zandi 577 LinkedIn 578 USA 580 Email: szandi@linkedin.com 582 Gaurav Dawra 583 LinkedIn 584 USA 586 Email: gdawra.ietf@gmail.com