idnits 2.17.00 (12 Aug 2021) /tmp/idnits18303/draft-ietf-spring-segment-routing-policy-16.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 document date (January 28, 2022) is 113 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 (-07) exists of draft-ali-spring-sr-traffic-accounting-06 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-08 == Outdated reference: A later version (-17) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-17) exists of draft-ietf-idr-te-lsp-distribution-16 == Outdated reference: A later version (-20) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-15) exists of draft-ietf-pce-binding-label-sid-12 == Outdated reference: A later version (-07) exists of draft-ietf-pce-segment-routing-policy-cp-06 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Filsfils 3 Internet-Draft K. Talaulikar, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 1, 2022 D. Voyer 6 Bell Canada 7 A. Bogdanov 8 British Telecom 9 P. Mattes 10 Microsoft 11 January 28, 2022 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-16 16 Abstract 18 Segment Routing (SR) allows a headend node to steer a packet flow 19 along any path. Intermediate per-path states are eliminated thanks 20 to source routing. The headend node steers a flow into an SR Policy. 21 The packets steered into an SR Policy carry an ordered list of 22 segments associated with that SR Policy. This document details the 23 concepts of SR Policy and steering into an SR Policy. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 1, 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 63 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 5 64 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 6 65 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 6 66 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 7 67 2.6. Identification of a Candidate Path . . . . . . . . . . . 8 68 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8 69 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 8 70 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 9 71 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 10 72 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 10 73 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 10 74 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 12 76 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 16 78 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 17 79 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 17 80 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 18 81 5.3. Composite Candidate Path . . . . . . . . . . . . . . . . 19 82 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 19 84 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 19 85 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 21 86 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 21 87 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 21 88 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 22 89 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 22 90 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 22 91 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 23 92 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 24 93 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 25 94 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 25 95 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 27 96 8.8. Optional Steering Modes for BGP Destinations . . . . . . 27 98 9. Recovering from Network Failures . . . . . . . . . . . . . . 29 99 9.1. Leveraging TI-LFA local protection of the constituent IGP 100 segments . . . . . . . . . . . . . . . . . . . . . . . . 29 101 9.2. Using an SR Policy to locally protect a link . . . . . . 30 102 9.3. Using a Candidate Path for Path Protection . . . . . . . 30 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 11. Manageability Considerations . . . . . . . . . . . . . . . . 31 105 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 106 12.1. Guidance for Designated Experts . . . . . . . . . . . . 32 107 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32 108 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 109 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 111 15.2. Informative References . . . . . . . . . . . . . . . . . 35 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 114 1. Introduction 116 Segment Routing (SR) [RFC8402] allows a headend node to steer a 117 packet flow along any path. The headend is a node where the 118 instructions for source routing (i.e. segments) are instantiated into 119 the packet and hence becomes the starting node for a specific segment 120 routing path. Intermediate per-path states are eliminated thanks to 121 source routing. 123 The headend node is said to steer a flow into a Segment Routing 124 Policy (SR Policy). [RFC8402] introduces the SR Policy construct and 125 provides an overview of how it is leveraged for Segment Routing use- 126 cases. 128 The packets steered into an SR Policy carry an ordered list of 129 segments associated with that SR Policy. [RFC8660] describes the 130 representation and processing of this ordered list of segments as an 131 MPLS label stack for SR-MPLS. While [RFC8754] and [RFC8986] describe 132 the same for Segment Routing over IPv6 (SRv6) with the use of the 133 Segment Routing Header (SRH). 135 This document details the concepts of SR Policy and steering packets 136 into an SR Policy. These apply equally to the SR-MPLS and SRv6 137 instantiations of segment routing. 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2. SR Policy 149 An SR Policy is a framework that enables the instantiation of an 150 ordered list of segments on a node for implementing a source routing 151 policy for the steering of traffic for a specific purpose (e.g. for a 152 specific SLA) from that node. 154 The Segment Routing architecture [RFC8402] specifies that any 155 instruction can be bound to a segment. Thus, an SR Policy can be 156 built using any type of Segment Identifier (SID) including those 157 associated with topological or service instructions. 159 This section defines the key aspects and constituents of an SR 160 Policy. 162 2.1. Identification of an SR Policy 164 An SR Policy MUST be identified through the tuple . In the context of a specific headend, an SR policy MUST 166 be identified by the tuple. 168 The headend is the node where the policy is instantiated/implemented. 169 The headend is specified as an IPv4 or IPv6 address and is expected 170 to be unique in the domain. 172 The endpoint indicates the destination of the policy. The endpoint 173 is specified as an IPv4 or IPv6 address and is expected to be unique 174 in the domain. In a specific case (refer to Section 8.8.1), the 175 endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6). 177 The color is an unsigned non-zero 32-bit numerical value that 178 associates the SR Policy with an intent or objective (e.g. low- 179 latency). 181 The endpoint and the color are used to automate the steering of 182 service or transport routes on SR Policies (refer to Section 8). 184 An implementation MAY allow the assignment of a symbolic name 185 comprising of printable ASCII [RFC0020] [RFC5234] characters to an SR 186 Policy to serve as a user-friendly attribute for debugging and 187 troubleshooting purposes. Such symbolic names MAY identify an SR 188 Policy when the naming scheme ensures uniqueness. The SR Policy name 189 MAY also be signaled along with a candidate path of the SR Policy 190 (refer to Section 2.2). An SR Policy MAY have multiple names 191 associated with it in the scenario where the headend receives 192 different SR Policy names along with candidate paths for the same SR 193 Policy. 195 2.2. Candidate Path and Segment List 197 An SR Policy is associated with one or more candidate paths. A 198 candidate path is the unit for signaling of an SR Policy to a headend 199 via protocol extensions like Path Computation Element (PCE) 200 Communication Protocol (PCEP) [RFC8664] 201 [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy 202 [I-D.ietf-idr-segment-routing-te-policy]. 204 A Segment-List represents a specific source-routed path to send 205 traffic from the headend to the endpoint of the corresponding SR 206 policy. 208 A candidate path is either dynamic, explicit, or composite. 210 An explicit candidate path is expressed as a Segment-List or a set of 211 Segment-Lists. 213 A dynamic candidate path expresses an optimization objective and a 214 set of constraints. The headend (potentially with the help of a PCE) 215 computes the solution Segment-List (or set of Segment-Lists) that 216 solves the optimization problem. 218 If a candidate path is associated with a set of Segment-Lists, each 219 Segment-List is associated with weight for weighted load balancing 220 (refer to Section 2.11 for details). The default weight is 1. 222 A composite candidate path acts as a container for grouping SR 223 Policies. The composite candidate path construct enables the 224 combination of SR Policies, each with explicit candidate paths and/or 225 dynamic candidate paths with potentially different optimization 226 objectives and constraints, for load-balanced steering of packet 227 flows over its constituent SR Policies. The following criteria apply 228 for inclusion of constituent SR Policies using a composite candidate 229 path under a parent SR Policy: 231 o the endpoints of the constituent SR Policies and the parent SR 232 Policy MUST be identical 234 o The colors of each of the constituent SR Policies and the parent 235 SR Policy MUST be different 237 o the constituent SR Policies MUST NOT use composite candidate paths 239 Each constituent SR Policy of a composite candidate path is 240 associated with weight for load-balancing purposes (refer to 241 Section 2.11 for details). The default weight is 1. 243 The Section 2.13 illustrates an information model for heirarchical 244 relationships between the SR Policy constructs described in this 245 section. 247 2.3. Protocol-Origin of a Candidate Path 249 A headend MAY be informed about a candidate path for an SR Policy 250 by various means including: via configuration, PCEP 251 [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP 252 [I-D.ietf-idr-segment-routing-te-policy]. 254 Protocol-Origin of a candidate path is an 8-bit value associated with 255 the mechanism or protocol used for signaling/provisioning the SR 256 Policy. It helps identify the protocol/mechanism that provides or 257 signals the candidate path and indicates its preference relative to 258 other protocols/mechanisms. 260 The head-end assigns different Protocol-Origin values to each source 261 of SR Policy information. The Protocol-Origin value is used as a 262 tie-breaker between candidate paths of equal preference, as described 263 in Section 2.9. The table below specifies the RECOMMENDED default 264 values of Protocol-Origin: 266 +-----------------+-------------------+ 267 | Protocol-Origin | Description | 268 +-----------------+-------------------+ 269 | 10 | PCEP | 270 | 20 | BGP SR Policy | 271 | 30 | Via Configuration | 272 +-----------------+-------------------+ 274 Table 1: Protocol-Origin default values 276 Implementations MAY allow modifications of these default values 277 assigned to protocols on the headend along similar lines as a routing 278 administrative distance. Its application in the candidate path 279 selection is described in Section 2.9. 281 2.4. Originator of a Candidate Path 283 Originator identifies the node which provisioned or signaled the 284 candidate path on the headend. The originator is expressed in the 285 form of a 160-bit numerical value formed by the concatenation of the 286 fields of the tuple as 287 below: 289 o Autonomous System Number (ASN) : represented as a 4-byte number. 290 If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and 291 the high-order bits MUST be set to zero. 293 o Node Address : represented as a 128-bit value. IPv4 addresses 294 MUST be encoded in the lowest 32 bits, and the high-order bits 295 MUST be set to zero. 297 Its application in the candidate path selection is described in 298 Section 2.9. 300 When provisioning is via configuration, the ASN and node address MAY 301 be set to either the headend or the provisioning controller/node ASN 302 and address. The default value is 0 for both AS and node address. 304 When signaling is via PCEP, it is the IPv4 or IPv6 address of the PCE 305 and the AS number SHOULD be set to 0 by default when not available or 306 known. 308 When signaling is via BGP SR Policy, the ASN and Node Address are 309 provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) 310 on the headend. 312 2.5. Discriminator of a Candidate Path 314 The Discriminator is a 32-bit value associated with a candidate path 315 that uniquely identifies it within the context of an SR Policy from a 316 specific Protocol-Origin as specified below: 318 When provisioning is via configuration, this is an implementation's 319 configuration model-specific unique identifier for a candidate path. 320 The default value is 0. 322 When signaling is via PCEP, the method to uniquely signal an 323 individual candidate path along with its discriminator is described 324 in [I-D.ietf-pce-segment-routing-policy-cp]. The default value is 0. 326 When signaling is via BGP SR Policy, the BGP process receiving the 327 route provides the distinguisher (refer to Section 2.1 of 328 [I-D.ietf-idr-segment-routing-te-policy]) as the discriminator. 330 Its application in the candidate path selection is described in 331 Section 2.9. 333 2.6. Identification of a Candidate Path 335 A candidate path is identified in the context of a single SR Policy. 337 A candidate path is not shared across SR Policies. 339 A candidate path is not identified by its Segment-List(s). 341 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 342 candidate path of SR Policy Pol2, then these two candidate paths 343 are independent, even if they happen to have the same Segment- 344 List. The Segment-List does not identify a candidate path. The 345 Segment-List is an attribute of a candidate path. 347 The identity of a candidate path MUST be uniquely established in the 348 context of an SR Policy to handle add, 349 delete or modify operations on them in an unambiguous manner 350 regardless of their source(s). 352 The tuple uniquely 353 identifies a candidate path. 355 Candidate paths MAY also be assigned or signaled with a symbolic name 356 comprising printable ASCII [RFC0020] [RFC5234] characters to serve as 357 a user-friendly attribute for debugging and troubleshooting purposes. 358 Such symbolic names MUST NOT be considered as identifiers for a 359 candidate path. 361 2.7. Preference of a Candidate Path 363 The preference of the candidate path is used to select the best 364 candidate path for an SR Policy. It is a 32-bit value where a higher 365 value indicates higher preference and the default preference value is 366 100. 368 It is RECOMMENDED that each candidate path of a given SR policy has a 369 different preference. 371 2.8. Validity of a Candidate Path 373 A candidate path is usable when it is valid. A common path validity 374 criterion is the validity of any of its constituent Segment-Lists. 375 The validation rules are specified in Section 5. 377 2.9. Active Candidate Path 379 A candidate path is selected when it is valid and it is determined to 380 be the best path of the SR Policy. The selected path is referred to 381 as the "active path" of the SR policy in this document. 383 Whenever a new path is learned or an active path is deleted, the 384 validity of an existing path changes or an existing path is changed, 385 the selection process MUST be re-executed. 387 The candidate path selection process operates on the candidate path 388 Preference. A candidate path is selected when it is valid and it has 389 the highest preference value among all the candidate paths of the SR 390 Policy. 392 In the case of multiple valid candidate paths of the same preference, 393 the tie-breaking rules are evaluated on the identification tuple in 394 the following order until only one valid best path is selected: 396 1. Higher value of Protocol-Origin is selected. 398 2. If specified by configuration, prefer the existing installed 399 path. 401 3. Lower value of originator is selected. 403 4. Finally, the higher value of discriminator is selected. 405 The rules are framed with multiple protocols and sources in mind and 406 hence may not follow the logic of a single protocol (e.g. BGP best 407 path selection). The motivation behind these rules are as follows: 409 o The Protocol-Origin allows an operator to set up a default 410 selection mechanism across protocol sources, e.g., to prefer 411 configured over paths signaled via BGP SR Policy or PCEP. 413 o The preference, being the first tiebreaker, allows an operator to 414 influence selection across paths thus allowing provisioning of 415 multiple path options, e.g., CP1 is preferred and if it becomes 416 invalid then fallback to CP2 and so on. Since preference works 417 across protocol sources, it also enables (where necessary) 418 selective override of the default Protocol-Origin preference, 419 e.g., to prefer a path signaled via BGP SR Policy over what is 420 configured. 422 o The originator allows an operator to have multiple redundant 423 controllers and still maintain a deterministic behavior over which 424 of them are preferred even if they are providing the same 425 candidate paths for the same SR policies to the headend. 427 o The discriminator performs the final tiebreaking step to ensure a 428 deterministic outcome of selection regardless of the order in 429 which candidate paths are signaled across multiple transport 430 channels or sessions. 432 Section 4 of [I-D.filsfils-spring-sr-policy-considerations] provides 433 a set of examples to illustrate the active candidate path selection 434 rules. 436 2.10. Validity of an SR Policy 438 An SR Policy is valid when it has at least one valid candidate path. 440 2.11. Instantiation of an SR Policy in the Forwarding Plane 442 A valid SR Policy is instantiated in the forwarding plane. 444 Only the active candidate path SHOULD be used for forwarding traffic 445 that is being steered onto that policy. 447 If a set of Segment-Lists is associated with the active path of the 448 policy, then the steering is per-flow and weighted-ECMP (W-ECMP) 449 based according to the relative weight of each Segment-List. 451 The fraction of the flows associated with a given Segment-List is w/ 452 Sw, where w is the weight of the Segment-List and Sw is the sum of 453 the weights of the Segment-Lists of the selected path of the SR 454 Policy. 456 When a composite candidate path is active, the fraction of flows 457 steered into each constituent SR Policy is equal to the relative 458 weight of each constituent SR Policy. Further load balancing of 459 flows steered into a constituent SR Policy is performed based on the 460 weights of the Segment-List of the active candidate path of that 461 constituent SR Policy. 463 The accuracy of the weighted load-balancing depends on the platform 464 implementation. 466 2.12. Priority of an SR Policy 468 Upon topological change, many policies could be recomputed or 469 revalidated. An implementation MAY provide a per-policy priority 470 configuration. The operator MAY set this field to indicate the order 471 in which the policies should be re-computed. Such a priority is 472 represented by an integer in the range (0, 255) where the lowest 473 value is the highest priority. The default value of priority is 128. 475 An SR Policy MAY comprise multiple Candidate Paths received from the 476 same or different sources. A candidate path MAY be signaled with a 477 priority value. When an SR Policy has multiple candidate paths with 478 distinct signaled non-default priority values and the SR Policy 479 itself does not have a priority value configured, the SR Policy as a 480 whole takes the lowest value (i.e. the highest priority) amongst 481 these signaled priority values. 483 2.13. Summary 485 In summary, the information model is the following: 487 SR policy POL1 488 Candidate-path CP1 490 Preference 200 491 Priority 10 492 Segment List 1 , Weight W1 493 Segment List 2 , Weight W2 494 Candidate-path CP2 496 Preference 100 497 Priority 10 498 Segment List 3 , Weight W3 499 Segment List 4 , Weight W4 501 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 503 identified by a tuple . 504 CP1 is the active candidate path (it is valid and has the highest 505 preference). The two Segment-Lists of CP1 are installed as the 506 forwarding instantiation of SR policy POL1. Traffic steered on POL1 507 is flow-based hashed on Segment-List with a ratio 508 W1/(W1+W2). 510 The information model of SR Policy POL100 having a composite 511 candidate path is the following: 513 SR policy POL100 514 Candidate-path CP1 516 Preference 200 517 SR policy , Weight W1 518 SR policy , Weight W2 520 The constituent SR Policies POL1 and POL2 have an information model 521 as described at the start of this section. They are referenced only 522 by color in the composite candidate path since their headend and 523 endpoint are identical to the POL100. The valid Segment-Lists of the 524 active candidate path of POL1 and POL2 are installed in the 525 forwarding. Traffic steered on POL100 is flow-based hashed on POL1 526 with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing 527 over its Segment-Lists are performed as described earlier in this 528 section. 530 3. Segment Routing Database 532 An SR Policy computation node (e.g. headend or controller) maintains 533 the Segment Routing Database (SR-DB). The SR-DB is a conceptual 534 database to illustrate the various pieces of information and their 535 sources that may help in SR Policy computation and validation. There 536 is no specific requirement for an implementation to create a new 537 database as such. 539 An SR headend leverages the SR-DB to validate explicit candidate 540 paths and compute dynamic candidate paths. 542 The information in the SR-DB may include: 544 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 545 OSPF [RFC2328] [RFC5340]) 546 o Segment Routing information (such as Segment Routing Global Block, 547 Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Peering 548 SID, SRv6 SIDs) [RFC8402] [RFC8986] 549 o TE Link Attributes (such as TE metric, Shared Risk Link Groups, 550 attribute-flag, extended admin group) [RFC5305] [RFC3630]. 551 o Extended TE Link attributes (such as latency, loss) [RFC8570] 552 [RFC7471] 553 o Inter-AS Topology information [RFC9086]. 555 The attached domain topology may be learned via IGP, BGP-LS or 556 NETCONF. 558 A non-attached (remote) domain topology may be learned via BGP-LS or 559 NETCONF. 561 In some use-cases, the SR-DB may only contain the attached domain 562 topology while in others, the SR-DB may contain the topology of 563 multiple domains and in this case, it is multi-domain capable. 565 The SR-DB may also contain the SR Policies instantiated in the 566 network. This can be collected via BGP-LS 567 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231], 569 [I-D.ietf-pce-segment-routing-policy-cp], and 570 [I-D.ietf-pce-binding-label-sid]. This information allows to build 571 an end-to-end policy on the basis of intermediate SR policies (see 572 Section 6 for further details). 574 The SR-DB may also contain the Maximum SID Depth (MSD) capability of 575 nodes in the topology. This can be collected via ISIS [RFC8491], 576 OSPF [RFC8476], BGP-LS [RFC8814] or PCEP [RFC8664]. 578 The use of the SR-DB for computation and validation of SR Policies is 579 outside the scope of this document. Some implementation aspects 580 related to this are covered in 581 [I-D.filsfils-spring-sr-policy-considerations]. 583 4. Segment Types 585 A Segment-List is an ordered set of segments represented as where S1 is the first segment. 588 Based on the desired dataplane, either the MPLS label stack or the 589 SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. 590 However, the Segment-List itself can be specified using different 591 segment-descriptor types and the following are currently defined: 593 Type A: SR-MPLS Label: 594 An MPLS label corresponding to any of the segment types defined 595 for SR-MPLS (as defined in [RFC8402] or other SR-MPLS 596 specifications) can be used. Additionally, special purpose 597 labels like explicit-null or in general any MPLS label MAY also 598 be used. E.g. this type can be used to specify a label 599 representation that maps to an optical transport path on a 600 packet transport node. This type does not require the headend 601 to perform SID resolution. 603 Type B: SRv6 SID: 604 An IPv6 address corresponding to any of the SID behaviors for 605 SRv6 (as defined in [RFC8986] or other SRv6 specifications) can 606 be used. This type does not require the headend to perform SID 607 resolution. Optionally, the SRv6 SID behavior (as defined in 608 [RFC8986] or other SRv6 specifications) and structure (as 609 defined in [RFC8986]) MAY also be provided for the headend to 610 perform validation of the SID when using it for building the 611 Segment List. 613 Type C: IPv4 Prefix with optional SR Algorithm: 614 The headend is required to resolve the specified IPv4 Prefix 615 Address to the SR-MPLS label corresponding to a Prefix SID 616 segment (as defined in [RFC8402]). The SR algorithm (refer to 617 Section 3.1.1 of [RFC8402]) to be used MAY also be provided. 619 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 620 In this case, the headend is required to resolve the specified 621 IPv6 Global Prefix Address to the SR-MPLS label corresponding 622 to its Prefix SID segment (as defined in [RFC8402]). The SR 623 Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY 624 also be provided. 626 Type E: IPv4 Prefix with Local Interface ID: 627 This type allows identification of Adjacency SID or BGP Peer 628 Adjacency SID (as defined in [RFC8402]) label for point-to- 629 point links including IP unnumbered links. The headend is 630 required to resolve the specified IPv4 Prefix Address to the 631 Node originating it and then use the Local Interface ID to 632 identify the point-to-point link whose adjacency is being 633 referred to. The Local Interface ID link descriptor follows 634 semantics as specified in [RFC7752]. This type can also be 635 used to indicate indirection into a layer 2 interface (i.e. 636 without IP address) like a representation of an optical 637 transport path or a layer 2 Ethernet port or circuit at the 638 specified node. 640 Type F: IPv4 Addresses for link endpoints as Local, Remote pair: 641 This type allows identification of Adjacency SID or BGP Peer 642 Adjacency SID (as defined in [RFC8402]) label for links. The 643 headend is required to resolve the specified IPv4 Local Address 644 to the Node originating it and then use the IPv4 Remote Address 645 to identify the link adjacency being referred to. The Local 646 and Remote Address pair link descriptors follow semantics as 647 specified in [RFC7752]. 649 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 650 Remote pair for SR-MPLS: 651 This type allows identification of Adjacency SID or BGP Peer 652 Adjacency SID (as defined in [RFC8402]) label for links 653 including those with only Link-Local IPv6 addresses. The 654 headend is required to resolve the specified IPv6 Prefix 655 Address to the Node originating it and then use the Local 656 Interface ID to identify the point-to-point link whose 657 adjacency is being referred to. For other than point-to-point 658 links, additionally the specific adjacency over the link needs 659 to be resolved using the Remote Prefix and Interface ID. The 660 Local and Remote pair of Prefix and Interface ID link 661 descriptor follows semantics as specified in [RFC7752]. This 662 type can also be used to indicate indirection into a layer 2 663 interface (i.e. without IP address) like a representation of an 664 optical transport path or a layer 2 Ethernet port or circuit at 665 the specified node. 667 Type H: IPv6 Addresses for link endpoints as Local, Remote pair for 668 SR-MPLS: 669 This type allows identification of Adjacency SID or BGP Peer 670 Adjacency SID (as defined in [RFC8402]) label for links with 671 Global IPv6 addresses. The headend is required to resolve the 672 specified Local IPv6 Address to the Node originating it and 673 then use the Remote IPv6 Address to identify the link adjacency 674 being referred to. The Local and Remote Address pair link 675 descriptors follow semantics as specified in [RFC7752]. 677 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: 678 The headend is required to resolve the specified IPv6 Global 679 Prefix Address to an SRv6 SID corresponding to a Prefix SID 680 segment (as defined in [RFC8402]), such as a SID associated 681 with the End behavior (as defined in [RFC8986]), of the node 682 which is originating the prefix. The SR Algorithm (refer to 683 Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as defined 684 in [RFC8986] or other SRv6 specifications) and structure (as 685 defined in [RFC8986]) MAY also be provided. 687 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 688 Remote pair for SRv6: 689 This type allows identification of an SRv6 SID corresponding to 690 an Adjacency SID or BGP Peer Adjacency SID (as defined in 691 [RFC8402]), such as a SID associated with the End.X behavior 692 (as defined in [RFC8986]), associated with link or adjacency 693 with only Link-Local IPv6 addresses. The headend is required 694 to resolve the specified IPv6 Prefix Address to the Node 695 originating it and then use the Local Interface ID to identify 696 the point-to-point link whose adjacency is being referred to. 697 For other than point-to-point links, additionally the specific 698 adjacency needs to be resolved using the Remote Prefix and 699 Interface ID. The Local and Remote pair of Prefix and 700 Interface ID link descriptor follows semantics as specified in 701 [RFC7752]. The SR Algorithm (refer to Section 3.1.1 of 702 [RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or 703 other SRv6 specifications) and structure (as defined in 704 [RFC8986]) MAY also be provided. 706 Type K: IPv6 Addresses for link endpoints as Local, Remote pair for 707 SRv6: 708 This type allows identification of an SRv6 SID corresponding to 709 an Adjacency SID or BGP Peer Adjacency SID (as defined in 710 [RFC8402]), such as a SID associated with the End.X behavior 711 (as defined in [RFC8986]), associated with link or adjacency 712 with Global IPv6 addresses. The headend is required to resolve 713 the specified Local IPv6 Address to the Node originating it and 714 then use the Remote IPv6 Address to identify the link adjacency 715 being referred to. The Local and Remote Address pair link 716 descriptors follow semantics as specified in [RFC7752]. The SR 717 Algorithm (refer to Section 3.1.1 of [RFC8402]), the SRv6 SID 718 behavior (as defined in [RFC8986] or other SRv6 specifications) 719 and structure (as defined in [RFC8986]) MAY also be provided. 721 When the algorithm is not specified for the SID types above which 722 optionally allow for it, the headend SHOULD use the Strict Shortest 723 Path algorithm if available; otherwise, it SHOULD use the default 724 Shortest Path algorithm. The specification of the algorithm enables 725 the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific 726 SIDs in SR Policy. 728 For SID types C-through-K, a SID value MAY also be optionally 729 provided to the headend for verification purposes. Section 5.1. 730 describes the resolution and verification of the SIDs and Segment 731 Lists on the headend. 733 When building the MPLS label stack or the IPv6 Segment list from the 734 Segment List, the node instantiating the policy MUST interpret the 735 set of Segments as follows: 737 o The first Segment represents the topmost label or the first IPv6 738 segment. It identifies the active segment the traffic will be 739 directed toward along the explicit SR path. 740 o The last Segment represents the bottommost label or the last IPv6 741 segment the traffic will be directed toward along the explicit SR 742 path. 744 4.1. Explicit Null 746 A Type A SID MAY be any MPLS label, including special purpose labels. 748 For example, assuming that the desired traffic-engineered path from a 749 headend 1 to an endpoint 4 can be expressed by the Segment-List 750 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 751 to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6 traffic 752 can be traffic-engineered from nodes 1 to 4 via the previously 753 described path using an SR Policy with Segment-List <16002, 16003, 754 16004, 2> where the MPLS label value of 2 represents the "IPv6 755 Explicit NULL Label". 757 The penultimate node before node 4 will pop 16004 and will forward 758 the frame on its directly connected interface to node 4. 760 The endpoint receives the traffic with the top label "2" which 761 indicates that the payload is an IPv6 packet. 763 When steering unlabeled IPv6 BGP destination traffic using an SR 764 policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit 765 Null Label Policy is processed as specified in 766 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 767 "IPv6 Explicit NULL label" is not present as the bottom label, the 768 headend SHOULD automatically impose one. Refer to Section 8 for more 769 details. 771 5. Validity of a Candidate Path 773 5.1. Explicit Candidate Path 775 An explicit candidate path is associated with a Segment-List or a set 776 of Segment-Lists. 778 An explicit candidate path is provisioned by the operator directly or 779 via a controller. 781 The computation/logic that leads to the choice of the Segment-List is 782 external to the SR Policy headend. The SR Policy headend does not 783 compute the Segment-List. The SR Policy headend only confirms its 784 validity. 786 An explicit candidate path MAY consist of a single explicit Segment- 787 List containing only an implicit-null label to indicate pop-and- 788 forward behavior. The Binding SID (BSID) is popped and the traffic 789 is forwarded based on the inner label or an IP lookup in the case of 790 unlabeled IP packets. Such an explicit path can serve as a fallback 791 or path of last resort for traffic being steered into an SR Policy 792 using its BSID (refer to Section 8.3). 794 A Segment-List of an explicit candidate path MUST be declared invalid 795 when any of the following is true: 797 o It is empty. 798 o Its weight is 0. 799 o It comprises a mix of SR-MPLS and SRv6 segment types. 800 o The headend is unable to perform path resolution for the first SID 801 into one or more outgoing interface(s) and next-hop(s). 802 o The headend is unable to perform SID resolution for any non-first 803 SID of type C-through-K into an MPLS label or an SRv6 SID. 804 o The headend verification fails for any SID for which verification 805 has been explicitly requested. 807 "Unable to perform path resolution" means that the headend has no 808 path to the SID in its SR database. 810 SID verification is performed when the headend is explicitly 811 requested to verify SID(s) by the controller via the signaling 812 protocol used. Implementations MAY provide a local configuration 813 option to enable verification on a global or per policy or per 814 candidate path basis. 816 "Verification fails" for a SID means any of the following: 818 o The headend is unable to find the SID in its SR-DB 819 o The headend detects a mismatch between the SID value and its 820 context provided for SIDs of type C-through-K in its SR-DB. 821 o The headend is unable to perform SID resolution for any non-first 822 SID of type C-through-K into an MPLS label or an SRv6 SID. 824 In multi-domain deployments, it is expected that the headend may be 825 unable to verify the reachability of the SIDs in remote domains. 826 Types A or B MUST be used for the SIDs for which the reachability 827 cannot be verified. Note that the first SID MUST always be reachable 828 regardless of its type. 830 Additionally, a Segment-List MAY be declared invalid when: 832 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 833 advertised by the node specified as the endpoint of the 834 corresponding SR policy. 835 o Its last segment is not an Adjacency SID (including BGP Peer 836 Adjacency SID) of any of the links present on neighbor nodes and 837 that terminate on the node specified as the endpoint of the 838 corresponding SR policy. 840 An explicit candidate path is invalid as soon as it has no valid 841 Segment-List. 843 Additionally, an explicit candidate path MAY be declared invalid when 844 its constituent segment lists (valid or invalid) are using segment 845 types of different SR data planes. 847 5.2. Dynamic Candidate Path 849 A dynamic candidate path is specified as an optimization objective 850 and constraints. 852 The headend of the policy leverages its SR database to compute a 853 Segment-List ("solution Segment-List") that solves this optimization 854 problem for either the SR-MPLS or the SRv6 data-plane as specified. 856 The headend re-computes the solution Segment-List any time the inputs 857 to the problem change (e.g., topology changes). 859 When the local computation is not possible (e.g., a policy's tail-end 860 is outside the topology known to the headend) or not desired, the 861 headend MAY send path computation request to a PCE supporting PCEP 862 extension specified in [RFC8664]. 864 If no solution is found to the optimization objective and 865 constraints, then the dynamic candidate path MUST be declared 866 invalid. 868 Section 3 of [I-D.filsfils-spring-sr-policy-considerations] discusses 869 some of the optimization objectives and constraints that may be 870 considered by a dynamic candidate path. It illustrates some of the 871 desirable properties of the computation of the solution Segment-List. 873 5.3. Composite Candidate Path 875 A composite candidate path is specified as a group of its constituent 876 SR Policies. 878 A composite candidate path is valid when it has at least one valid 879 constituent SR Policy. 881 6. Binding SID 883 The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 884 It provides scaling, network opacity, and service independence. 885 Section 6 of [I-D.filsfils-spring-sr-policy-considerations] 886 illustrates some of these benefits. This section describes the 887 association of BSID with an SR Policy. 889 6.1. BSID of a candidate path 891 Each candidate path MAY be defined with a BSID. 893 Candidate Paths of the same SR policy SHOULD have the same BSID. 895 Candidate Paths of different SR policies MUST NOT have the same BSID. 897 6.2. BSID of an SR Policy 899 The BSID of an SR Policy is the BSID of its active candidate path. 901 When the active candidate path has a specified BSID, the SR Policy 902 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 903 available (i.e., not associated with any other usage: e.g. to another 904 MPLS client, to another SRv6 client, to another SID, to another SR 905 Policy, outside the range of SRv6 Locators). 907 In the case of SR-MPLS, SRv6 BSIDs (e.g. with the behavior End.BM 908 [RFC8986]) MAY be associated with the SR Policy in addition to the 909 MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g. with 910 different behaviors like End.B6.Encap and End.B6.Encap.Red [RFC8986]) 911 MAY be associated with the SR Policy. 913 Optionally, instead of only checking that the BSID of the active path 914 is available, a headend MAY check that it is available within a given 915 SID range i.e., Segment Routing Local Block (SRLB) as specified in 916 [RFC8402]. 918 When the specified BSID is not available (optionally is not in the 919 SRLB), an alert message MUST be generated. 921 In the cases (as described above) where SR Policy does not have a 922 BSID available, then the SR Policy MAY dynamically bind a BSID to 923 itself. Dynamically bound BSID SHOULD use an available SID outside 924 the SRLB. 926 Assuming that at time t the BSID of the SR Policy is B1, if at time 927 t+dt a different candidate path becomes active and this new active 928 path does not have a specified BSID or its BSID is specified but is 929 not available (e.g. it is in use by something else), then the SR 930 Policy MAY keep the previous BSID B1. 932 The association of an SR Policy with a BSID thus MAY change over the 933 life of the SR Policy (e.g., upon active path change). Hence, the 934 BSID SHOULD NOT be used as an identification of an SR Policy. 936 6.2.1. Frequent use-case : unspecified BSID 938 All the candidate paths of the same SR Policy can have an unspecified 939 BSID. 941 In such a case, a BSID MAY be dynamically bound to the SR Policy as 942 soon as the first valid candidate path is received. That BSID is 943 kept through the life of the SR Policy and across changes of active 944 candidate path. 946 6.2.2. Frequent use-case: all specified to the same BSID 948 All the paths of the SR Policy can have the same specified BSID. 950 6.2.3. Specified-BSID-only 952 An implementation MAY support the configuration of the Specified- 953 BSID-only restrictive behavior on the headend for all SR Policies or 954 individual SR Policies. Further, this restrictive behavior MAY also 955 be signaled on a per SR Policy basis to the headend. 957 When this restrictive behavior is enabled, if the candidate path has 958 an unspecified BSID or if the specified BSID is not available when 959 the candidate path becomes active then no BSID is bound to it and the 960 candidate path is considered invalid. An alert MUST be triggered for 961 this error. Other candidate paths MUST then be evaluated for 962 becoming the active candidate path. 964 6.3. Forwarding Plane 966 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 967 with the action of steering the packets matching this entry to the 968 selected path of the SR Policy. 970 If the Specified-BSID-only restrictive behavior is enabled and the 971 BSID of the active path is not available (optionally not in the 972 SRLB), then the SR Policy does not install any entry indexed by a 973 BSID in the forwarding plane. 975 6.4. Non-SR usage of Binding SID 977 An implementation MAY choose to associate a Binding SID with any type 978 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 979 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 980 tunnel, etc). This enables the use of other non-SR enabled 981 interfaces and tunnels as segments in an SR Policy Segment-List 982 without the need of forming routing protocol adjacencies over them. 984 The details of this kind of usage are beyond the scope of this 985 document. A specific packet-optical integration use case is 986 described in [I-D.anand-spring-poi-sr]. 988 7. SR Policy State 990 The SR Policy State is maintained on the headend to represent the 991 state of the policy and its candidate paths. This is to provide an 992 accurate representation of whether the SR Policy is being 993 instantiated in the forwarding plane and which of its candidate paths 994 and segment-list(s) are active. The SR Policy state MUST also 995 reflect the reason when a policy and/or its candidate path is not 996 active due to validation errors or not being preferred. 998 The SR Policy state can be reported by the headend node via BGP-LS 999 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 1000 [I-D.ietf-pce-binding-label-sid]. 1002 SR Policy state on the headend also includes traffic accounting 1003 information for the flows being steered via the policies. The 1004 details of the SR Policy accounting are beyond the scope of this 1005 document. The aspects related to the SR traffic counters and their 1006 usage in the broader context of traffic accounting in an SR network 1007 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 1008 [I-D.ali-spring-sr-traffic-accounting] respectively. 1010 Implementations MAY support an administrative state to control 1011 locally provisioned policies via mechanisms like CLI or NETCONF. 1013 8. Steering into an SR Policy 1015 A headend can steer a packet flow into a valid SR Policy in various 1016 ways: 1018 o Incoming packets have an active SID matching a local BSID at the 1019 headend. 1020 o Per-destination Steering: incoming packets match a BGP/Service 1021 route which recurses on an SR policy. 1022 o Per-flow Steering: incoming packets match or recurse on a 1023 forwarding array of where some of the entries are SR Policies. 1024 o Policy-based Steering: incoming packets match a routing policy 1025 that directs them on an SR policy. 1027 8.1. Validity of an SR Policy 1029 An SR Policy is invalid when all its candidate paths are invalid as 1030 described in Section 5 and Section 2.10. 1032 By default, upon transitioning to the invalid state, 1034 o an SR Policy and its BSID are removed from the forwarding plane. 1035 o any steering of a service (Pseudowire (PW)), destination (BGP- 1036 VPN), flow or packet on the related SR policy is disabled and the 1037 related service, destination, flow, or packet is routed per the 1038 classic forwarding table (e.g. longest-match to the destination or 1039 the recursing next-hop). 1041 8.2. Drop upon invalid SR Policy 1043 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 1045 o an invalid SR Policy and its BSID is kept in the forwarding plane 1046 with an action to drop. 1047 o any steering of a service (PW), destination (BGP-VPN), flow or 1048 packet on the related SR policy is maintained with the action to 1049 drop all of this traffic. 1051 The drop-upon-invalid behavior has been deployed in use-cases where 1052 the operator wants some PW to only be transported on a path with 1053 specific constraints. When these constraints are no longer met, the 1054 operator wants the PW traffic to be dropped. Specifically, the 1055 operator does not want the PW to be routed according to the IGP 1056 shortest path to the PW endpoint. 1058 8.3. Incoming Active SID is a BSID 1060 Let us assume that headend H has a valid SR Policy P of Segment-List 1061 and BSID B. 1063 In the case of SR-MPLS, when H receives a packet K with label stack 1064 , H pops B and pushes and forwards the 1065 resulting packet according to SID S1. 1067 "Forwarding the resulting packet according to S1" means: If S1 is 1068 an Adj-SID or a PHP-enabled prefix SID advertised by a neighbor, H 1069 sends the resulting packet with label stack on 1070 the outgoing interface associated with S1; Else H sends the 1071 resulting packet with label stack along the 1072 path of S1. 1074 In the case of SRv6, the processing is similar and follows the SR 1075 Policy headend behaviors as specified in section 5 of [RFC8986]. 1077 H has steered the packet into the SR policy P. 1079 H did not have to classify the packet. The classification was done 1080 by a node upstream of H (e.g., the source of the packet or an 1081 intermediate ingress edge node of the SR domain) and the result of 1082 this classification was efficiently encoded in the packet header as a 1083 BSID. 1085 This is another key benefit of the segment routing in general and the 1086 binding SID in particular: the ability to encode a classification and 1087 the resulting steering in the packet header to better scale and 1088 simplify intermediate aggregation nodes. 1090 If the SR Policy P is invalid, the BSID B is not in the forwarding 1091 plane and hence the packet K is dropped by H. 1093 8.4. Per-Destination Steering 1095 In the case of SR-MPLS, let us assume that headend H: 1097 o learns a BGP route R/r via next-hop N, Color Extended community C 1098 and VPN label V. 1099 o has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1100 List and BSID B. 1101 o has a BGP policy that matches on the Color Extended community C 1102 and allows its usage as SLA steering information. 1104 If all these conditions are met, H installs R/r in RIB/FIB with next- 1105 hop = SR Policy P of BSID B instead of via N. 1107 Indeed, H's local BGP policy and the received BGP route indicate that 1108 the headend should associate R/r with an SR Policy path to endpoint N 1109 with the SLA associated with color C. The headend, therefore, 1110 installs the BGP route on that policy. 1112 This can be implemented by using the BSID as a generalized next-hop 1113 and installing the BGP route on that generalized next-hop. 1115 When H receives a packet K with a destination matching R/r, H pushes 1116 the label stack and sends the resulting packet along 1117 the path to S1. 1119 Note that any SID associated with the BGP route is inserted after the 1120 Segment-List of the SR Policy (i.e., ). 1122 In the case of SRv6, the processing is similar and follows the SR 1123 Policy headend behaviors as specified in section 5 of [RFC8986]. 1125 The same behavior applies to any type of service route: any AFI/SAFI 1126 of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1128 In a BGP multi-path scenario, the BGP route MAY be resolved over a 1129 mix of paths that include those that are steered over SR Policies and 1130 others resolved via the normal BGP nexthop resolution. 1131 Implementations MAY provide options to prefer one type over the other 1132 or other forms of local policy to determine the paths that are 1133 selected. 1135 8.4.1. Multiple Colors 1137 When a BGP route has multiple Color Extended communities each with a 1138 valid SR Policy, the BGP process installs the route on the SR Policy 1139 giving preference to the color with the highest numerical value. 1141 Let us assume that headend H: 1143 o learns a BGP route R/r via next-hop N, Color Extended communities 1144 C1 and C2. 1145 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1146 List and BSID B1. 1147 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1148 List and BSID B2. 1149 o has a BGP policy that matches the Color Extended communities C1 1150 and C2 and allows their usage as SLA steering information 1152 If all these conditions are met, H installs R/r in RIB/FIB with next- 1153 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1155 When the SR Policy with a specific color is not instantiated or in 1156 the down/inactive state, the SR Policy with the next highest 1157 numerical value of color is considered. 1159 8.5. Recursion on an on-demand dynamic BSID 1161 In the previous section, it was assumed that H had a pre-established 1162 "explicit" SR Policy (color C, endpoint N). 1164 In this section, independent of the a-priori existence of any 1165 explicit candidate path of the SR policy (C, N), it is to be noted 1166 that the BGP process at headend node H triggers the instantiation of 1167 a dynamic candidate path for the SR policy (C, N) as soon as: 1169 o the BGP process learns of a route R/r via N and with color C. 1170 o a local policy at node H authorizes the on-demand SR Policy path 1171 instantiation and maps the color to a dynamic SR Policy path 1172 optimization template. 1174 8.5.1. Multiple Colors 1176 When a BGP route R/r via N has multiple Color Extended communities Ci 1177 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1178 request (color Ci, endpoint N) is triggered for each color Ci. The 1179 SR Policy that is used for steering is then determined as described 1180 in Section 8.4.1. 1182 8.6. Per-Flow Steering 1184 Let us assume that headend H: 1186 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1187 List and BSID B1. 1189 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1190 List and BSID B2. 1191 o is configured to instantiate an array of paths to N where the 1192 entry 0 is the IGP path to N, color C1 is the first entry and 1193 Color C2 is the second entry. The index into the array is called 1194 a Forwarding Class (FC). The index can have values 0 to 7. 1195 o is configured to match flows in its ingress interfaces (upon any 1196 field such as Ethernet destination/source/VLAN/TOS or IP 1197 destination/source/DSCP or transport ports etc.) and color them 1198 with an internal per-packet forwarding-class variable (0, 1 or 2 1199 in this example). 1201 If all these conditions are met, H installs in RIB/FIB: 1203 o N via recursion on an array A (instead of the immediate outgoing 1204 link associated with the IGP shortest-path to N). 1205 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1206 path to N. 1207 o Entry A(1) set to SR Policy P1 of BSID=B1. 1208 o Entry A(2) set to SR Policy P2 of BSID=B2. 1210 H receives three packets K, K1, and K2 on its incoming interface. 1211 These three packets either longest-match on N or more likely on a 1212 BGP/service route which recurses on N. H colors these 3 packets 1213 respectively with forwarding-class 0, 1, and 2. 1215 As a result, for SR-MPLS: 1217 o H forwards K along the shortest path to N (i.e., pushes the 1218 Prefix-SID of N). 1219 o H pushes on packet K1 and forwards the resulting 1220 frame along the shortest path to S1. 1221 o H pushes on packet K2 and forwards the resulting 1222 frame along the shortest path to S4. 1224 For SRv6, the processing is similar and the segment lists of the 1225 individual SR Policies P1 and P2 are enforced for packets K1 and K2 1226 using the SR Policy headend behaviors as specified in section 5 of 1227 [RFC8986]. 1229 If the local configuration does not specify any explicit forwarding 1230 information for an entry of the array, then this entry is filled with 1231 the same information as entry 0 (i.e. the IGP shortest path). 1233 If the SR Policy mapped to an entry of the array becomes invalid, 1234 then this entry is filled with the same information as entry 0. When 1235 all the array entries have the same information as entry0, the 1236 forwarding entry for N is updated to bypass the array and point 1237 directly to its outgoing interface and next-hop. 1239 The array index values (e.g. 0, 1, and 2) and the notion of 1240 forwarding-class are implementation-specific and only meant to 1241 describe the desired behavior. The same can be realized by other 1242 mechanisms. 1244 This realizes per-flow steering: different flows bound to the same 1245 BGP endpoint are steered on different IGP or SR Policy paths. 1247 A headend MAY support options to apply per-flow steering only for 1248 traffic matching specific prefixes (e.g. specific IGP or BGP 1249 prefixes). 1251 8.7. Policy-based Routing 1253 Finally, headend H MAY be configured with a local routing policy 1254 which overrides any BGP/IGP path and steer a specified packet on an 1255 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1256 automatic routing of IGP prefixes over SR Policies intended for such 1257 purpose. 1259 8.8. Optional Steering Modes for BGP Destinations 1261 8.8.1. Color-Only BGP Destination Steering 1263 In the previous section, it is seen that the steering on an SR Policy 1264 is governed by the matching of the BGP route's next-hop N and the 1265 authorized color C with an SR Policy defined by the tuple (N, C). 1267 This is the most likely form of BGP destination steering and the one 1268 recommended for most use-cases. 1270 This section defines an alternative steering mechanism based only on 1271 the color. 1273 This color-only steering variation is governed by two new "CO" bits 1274 defined in the Color Extended community in section 3 of 1275 [I-D.ietf-idr-segment-routing-te-policy]. 1277 The Color-Only flags "CO" are set to 00 by default. 1279 When 00, the BGP destination is steered as follows: 1281 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1283 endpoint address and C is a color; 1285 Steer into SR Policy (N, C); 1286 ELSE; 1287 Steer on the IGP path to the next-hop N. 1289 This is the classic case described in this document previously and 1290 what is recommended in most scenarios. 1292 When 01, the BGP destination is steered as follows: 1294 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1296 endpoint address and C is a color; 1297 Steer into SR Policy (N, C); 1298 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1299 same address-family of N; 1300 Steer into SR Policy (null endpoint, C); 1301 ELSE IF there is any valid SR Policy 1302 (any address-family null endpoint, C); 1303 Steer into SR Policy (any null endpoint, C); 1304 ELSE; 1305 Steer on the IGP path to the next-hop N. 1307 When 10, the BGP destination is steered as follows: 1309 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1310 endpoint address and C is a color; 1311 Steer into SR Policy (N, C); 1312 ELSE IF there is a valid SR Policy (null endpoint, C) 1313 of the same address-family of N; 1314 Steer into SR Policy (null endpoint, C); 1315 ELSE IF there is any valid SR Policy 1316 (any address-family null endpoint, C); 1317 Steer into SR Policy (any null endpoint, C); 1318 ELSE IF there is any valid SR Policy (any endpoint, C) 1319 of the same address-family of N; 1320 Steer into SR Policy (any endpoint, C); 1321 ELSE IF there is any valid SR Policy 1322 (any address-family endpoint, C); 1323 Steer into SR Policy (any address-family endpoint, C); 1324 ELSE; 1325 Steer on the IGP path to the next-hop N. 1327 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1328 to the 0 value). 1330 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1331 reception, an implementation MUST treat it like 00. 1333 8.8.2. Multiple Colors and CO flags 1335 The steering preference is first based on the highest color value and 1336 then CO-dependent for the color. Assuming a Prefix via (NH, 1337 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1339 o SR policy (NH, C1). 1340 o SR policy (null, C1). 1341 o SR policy (NH, C2). 1342 o SR policy (null, C2). 1343 o IGP to NH. 1345 8.8.3. Drop upon Invalid 1347 This document defined earlier that when all the following conditions 1348 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1349 BSID B instead of via N. 1351 o H learns a BGP route R/r via next-hop N, Color Extended community 1352 C. 1353 o H has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1354 List and BSID B. 1355 o H has a BGP policy that matches the Color Extended community C and 1356 allows its usage as SLA steering information. 1358 This behavior is extended by noting that the BGP policy may require 1359 the BGP steering to always stay on the SR policy whatever its 1360 validity. 1362 This is the "drop upon invalid" option described in Section 8.2 1363 applied to BGP-based steering. 1365 9. Recovering from Network Failures 1367 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1369 In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) 1370 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1371 protection technique for IGP SIDs. The backup path is computed on a 1372 per IGP SID basis along the post-convergence path. 1374 In a network that has deployed TI-LFA, an SR Policy built on the 1375 basis of TI-LFA protected IGP segments leverages the local protection 1376 of the constituent segments. Since TI-LFA protection is based on IGP 1377 computation, there are cases where the path used during the fast- 1378 reroute time window may not meet the exact constraints of the SR 1379 Policy. 1381 In a network that has deployed TI-LFA, an SR Policy instantiated only 1382 with non-protected Adj SIDs does not benefit from any local 1383 protection. 1385 9.2. Using an SR Policy to locally protect a link 1387 1----2-----6----7 1388 | | | | 1389 4----3-----9----8 1391 Figure 1: Local protection using SR Policy 1393 An SR Policy can be instantiated at node 2 to protect link 2to6. A 1394 typical explicit Segment-List would be <3, 9, 6>. 1396 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1397 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are 1398 part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 1399 cannot benefit from TI-LFA automated local protection. The SR Policy 1400 with Segment-List <3, 9, 6> on node 2 can be locally configured to be 1401 a fast-reroute backup path for the link 2to6. 1403 9.3. Using a Candidate Path for Path Protection 1405 An SR Policy allows for multiple candidate paths, of which at any 1406 point in time there is a single active candidate path that is 1407 provisioned in the forwarding plane and used for traffic steering. 1408 However, another (lower preference) candidate path MAY be designated 1409 as the backup for a specific or all (active) candidate path(s). The 1410 following options are possible: 1412 o A pair of disjoint candidate paths are provisioned with one of 1413 them as primary and the other is identified as its backup. 1414 o A specific candidate path is provisioned as the backup for any 1415 (active) candidate path. 1416 o The headend picks the next (lower) preference valid candidate path 1417 as the backup for the active candidate path. 1419 The headend MAY compute a-priori and validate such backup candidate 1420 paths as well as provision them into the forwarding plane as a backup 1421 for the active path. The backup candidate path may be dynamically 1422 computed or explicitly provisioned in such a way that they provide 1423 the most appropriate alternative for the active candidate path. A 1424 fast re-route mechanism MAY then be used to trigger sub 50msec 1425 switchover from the active to the backup candidate path in the 1426 forwarding plane. Mechanisms like Bidirectional Forwarding Detection 1427 (BFD) MAY be used for fast detection of such failures. 1429 10. Security Considerations 1431 This document specifies in detail the SR Policy construct introduced 1432 in [RFC8402] and its instantiation on a router supporting SR along 1433 with descriptions of mechanisms for steering of traffic flows over 1434 it. Therefore, the security considerations of [RFC8402] apply. This 1435 document does not define any new protocol extensions and does not 1436 introduce any further security considerations. 1438 11. Manageability Considerations 1440 This document specifies in detail the SR Policy construct introduced 1441 in [RFC8402] and its instantiation on a router supporting SR along 1442 with descriptions of mechanisms for steering of traffic flows over 1443 it. Therefore, the manageability considerations of [RFC8402] apply. 1445 A YANG model for the configuration and operation of SR Policy has 1446 been defined in [I-D.ietf-spring-sr-policy-yang]. 1448 12. IANA Considerations 1450 The document requests IANA to create a new sub-registry called 1451 "Segment Types" under the top-level "Segment Routing" registry that 1452 was created by [RFC8986]. This sub-registry maintains the alphabetic 1453 identifiers for the segment types (as specified in section 4) that 1454 may be used within a Segment List of an SR Policy. The alphabetical 1455 identifiers run from A to Z and may be extended on exhaustion with 1456 the identifiers AA to AZ, BA to BZ, and so on through till ZZ. This 1457 sub-registry would follow the Specification Required allocation 1458 policy as specified in [RFC8126]. 1460 The initial registrations for this sub-registry are as follows: 1462 +-------+-----------------------------------------------+-----------+ 1463 | Value | Description | Reference | 1464 +-------+-----------------------------------------------+-----------+ 1465 | A | SR-MPLS Label | [This.ID] | 1466 | B | SRv6 SID | [This.ID] | 1467 | C | IPv4 Prefix with optional SR Algorithm | [This.ID] | 1468 | D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1469 | | for SR-MPLS | | 1470 | E | IPv4 Prefix with Local Interface ID | [This.ID] | 1471 | F | IPv4 Addresses for link endpoints as Local, | [This.ID] | 1472 | | Remote pair | | 1473 | G | IPv6 Prefix and Interface ID for link | [This.ID] | 1474 | | endpoints as Local, Remote pair for SR-MPLS | | 1475 | H | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1476 | | Remote pair for SR-MPLS | | 1477 | I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1478 | | for SRv6 | | 1479 | J | IPv6 Prefix and Interface ID for link | [This.ID] | 1480 | | endpoints as Local, Remote pair for SRv6 | | 1481 | K | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1482 | | Remote pair for SRv6 | | 1483 +-------+-----------------------------------------------+-----------+ 1485 Table 2: Initial IANA Registration 1487 12.1. Guidance for Designated Experts 1489 The Designated Expert (DE) is expected to ascertain the existence of 1490 suitable documentation (a specification) as described in [RFC8126] 1491 and to verify that the document is permanently and publicly 1492 available. The DE is also expected to check the clarity of purpose 1493 and use of the requested assignment. Additionally, the DE must 1494 verify that any request for one of these assignments has been made 1495 available for review and comment within the IETF: the DE will post 1496 the request to the SPRING Working Group mailing list (or a successor 1497 mailing list designated by the IESG). If the request comes from 1498 within the IETF, it should be documented in an Internet-Draft. 1499 Lastly, the DE must ensure that any other request for a code point 1500 does not conflict with work that is active or already published 1501 within the IETF. 1503 13. Acknowledgement 1505 The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger 1506 Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha, 1507 Jim Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi, 1508 and Matthew Bocci for their review comments and suggestions. 1510 14. Contributors 1512 The following people have contributed to this document: 1514 Siva Sivabalan 1515 Cisco Systems 1516 Email: msiva@cisco.com 1518 Zafar Ali 1519 Cisco Systems 1520 Email: zali@cisco.com 1522 Jose Liste 1523 Cisco Systems 1524 Email: jliste@cisco.com 1526 Francois Clad 1527 Cisco Systems 1528 Email: fclad@cisco.com 1530 Kamran Raza 1531 Cisco Systems 1532 Email: skraza@cisco.com 1534 Mike Koldychev 1535 Cisco Systems 1536 Email: mkoldych@cisco.com 1538 Shraddha Hegde 1539 Juniper Networks 1540 Email: shraddha@juniper.net 1542 Steven Lin 1543 Google, Inc. 1544 Email: stevenlin@google.com 1546 Przemyslaw Krol 1547 Google, Inc. 1548 Email: pkrol@google.com 1550 Martin Horneffer 1551 Deutsche Telekom 1552 Email: martin.horneffer@telekom.de 1554 Dirk Steinberg 1555 Steinberg Consulting 1556 Email: dws@steinbergnet.net 1557 Bruno Decraene 1558 Orange Business Services 1559 Email: bruno.decraene@orange.com 1561 Stephane Litkowski 1562 Orange Business Services 1563 Email: stephane.litkowski@orange.com 1565 Luay Jalil 1566 Verizon 1567 Email: luay.jalil@verizon.com 1569 15. References 1571 15.1. Normative References 1573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1574 Requirement Levels", BCP 14, RFC 2119, 1575 DOI 10.17487/RFC2119, March 1997, 1576 . 1578 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1579 Writing an IANA Considerations Section in RFCs", BCP 26, 1580 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1581 . 1583 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1584 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1585 May 2017, . 1587 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1588 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1589 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1590 July 2018, . 1592 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1593 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1594 Routing with the MPLS Data Plane", RFC 8660, 1595 DOI 10.17487/RFC8660, December 2019, 1596 . 1598 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1599 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1600 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1601 . 1603 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1604 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1605 (SRv6) Network Programming", RFC 8986, 1606 DOI 10.17487/RFC8986, February 2021, 1607 . 1609 15.2. Informative References 1611 [I-D.ali-spring-sr-traffic-accounting] 1612 Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., 1613 Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D., and 1614 R. Morton, "Traffic Accounting in Segment Routing 1615 Networks", draft-ali-spring-sr-traffic-accounting-06 (work 1616 in progress), November 2021. 1618 [I-D.anand-spring-poi-sr] 1619 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1620 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1621 Integration in Segment Routing", draft-anand-spring-poi- 1622 sr-08 (work in progress), July 2019. 1624 [I-D.filsfils-spring-sr-policy-considerations] 1625 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1626 P. Mattes, "SR Policy Implementation and Deployment 1627 Considerations", draft-filsfils-spring-sr-policy- 1628 considerations-08 (work in progress), October 2021. 1630 [I-D.filsfils-spring-sr-traffic-counters] 1631 Filsfils, C., Ali, Z., Horneffer, M., Voyer, D., Durrani, 1632 M., and R. Raszuk, "Segment Routing Traffic Accounting 1633 Counters", draft-filsfils-spring-sr-traffic-counters-02 1634 (work in progress), October 2021. 1636 [I-D.ietf-idr-segment-routing-te-policy] 1637 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1638 Jain, D., and S. Lin, "Advertising Segment Routing 1639 Policies in BGP", draft-ietf-idr-segment-routing-te- 1640 policy-14 (work in progress), November 2021. 1642 [I-D.ietf-idr-te-lsp-distribution] 1643 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1644 H., and J. Tantsura, "Distribution of Traffic Engineering 1645 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1646 lsp-distribution-16 (work in progress), October 2021. 1648 [I-D.ietf-lsr-flex-algo] 1649 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1650 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1651 algo-18 (work in progress), October 2021. 1653 [I-D.ietf-pce-binding-label-sid] 1654 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 1655 and C. L. (editor), "Carrying Binding Label/Segment 1656 Identifier in PCE-based Networks.", draft-ietf-pce- 1657 binding-label-sid-12 (work in progress), January 2022. 1659 [I-D.ietf-pce-segment-routing-policy-cp] 1660 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 1661 Bidgoli, "PCEP extension to support Segment Routing Policy 1662 Candidate Paths", draft-ietf-pce-segment-routing-policy- 1663 cp-06 (work in progress), October 2021. 1665 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1666 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 1667 Decraene, B., and D. Voyer, "Topology Independent Fast 1668 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 1669 routing-ti-lfa-08 (work in progress), January 2022. 1671 [I-D.ietf-spring-sr-policy-yang] 1672 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 1673 Matsushima, S., and V. P. Beeram, "YANG Data Model for 1674 Segment Routing Policy", draft-ietf-spring-sr-policy- 1675 yang-01 (work in progress), April 2021. 1677 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 1678 RFC 20, DOI 10.17487/RFC0020, October 1969, 1679 . 1681 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1682 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1683 December 1990, . 1685 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1686 DOI 10.17487/RFC2328, April 1998, 1687 . 1689 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1690 (TE) Extensions to OSPF Version 2", RFC 3630, 1691 DOI 10.17487/RFC3630, September 2003, 1692 . 1694 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1695 "Multiprotocol Extensions for BGP-4", RFC 4760, 1696 DOI 10.17487/RFC4760, January 2007, 1697 . 1699 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1700 Specifications: ABNF", STD 68, RFC 5234, 1701 DOI 10.17487/RFC5234, January 2008, 1702 . 1704 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1705 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1706 2008, . 1708 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1709 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1710 . 1712 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1713 Locator/ID Separation Protocol (LISP)", RFC 6830, 1714 DOI 10.17487/RFC6830, January 2013, 1715 . 1717 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1718 Previdi, "OSPF Traffic Engineering (TE) Metric 1719 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1720 . 1722 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1723 S. Ray, "North-Bound Distribution of Link-State and 1724 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1725 DOI 10.17487/RFC7752, March 2016, 1726 . 1728 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1729 Computation Element Communication Protocol (PCEP) 1730 Extensions for Stateful PCE", RFC 8231, 1731 DOI 10.17487/RFC8231, September 2017, 1732 . 1734 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1735 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1736 DOI 10.17487/RFC8476, December 2018, 1737 . 1739 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1740 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1741 DOI 10.17487/RFC8491, November 2018, 1742 . 1744 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1745 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1746 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1747 2019, . 1749 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1750 and J. Hardwick, "Path Computation Element Communication 1751 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1752 DOI 10.17487/RFC8664, December 2019, 1753 . 1755 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 1756 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 1757 Using the Border Gateway Protocol - Link State", RFC 8814, 1758 DOI 10.17487/RFC8814, August 2020, 1759 . 1761 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 1762 Ray, S., and J. Dong, "Border Gateway Protocol - Link 1763 State (BGP-LS) Extensions for Segment Routing BGP Egress 1764 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 1765 2021, . 1767 Authors' Addresses 1769 Clarence Filsfils 1770 Cisco Systems, Inc. 1771 Pegasus Parc 1772 De kleetlaan 6a, DIEGEM BRABANT 1831 1773 BELGIUM 1775 Email: cfilsfil@cisco.com 1777 Ketan Talaulikar (editor) 1778 Cisco Systems, Inc. 1779 India 1781 Email: ketant.ietf@gmail.com 1782 Daniel Voyer 1783 Bell Canada 1784 671 de la gauchetiere W 1785 Montreal, Quebec H3B 2M8 1786 Canada 1788 Email: daniel.voyer@bell.ca 1790 Alex Bogdanov 1791 British Telecom 1793 Email: alex.bogdanov@bt.com 1795 Paul Mattes 1796 Microsoft 1797 One Microsoft Way 1798 Redmond, WA 98052-6399 1799 USA 1801 Email: pamattes@microsoft.com