idnits 2.17.1 draft-ietf-spring-segment-routing-policy-13.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 (May 28, 2021) is 1064 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 (-08) exists of draft-ali-spring-sr-traffic-accounting-05 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-07 == Outdated reference: A later version (-02) exists of draft-filsfils-spring-sr-traffic-counters-01 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-12 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-15 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-16 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-08 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-05 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-06 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-policy-yang-01 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). 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: November 29, 2021 D. Voyer 6 Bell Canada 7 A. Bogdanov 8 Google, Inc. 9 P. Mattes 10 Microsoft 11 May 28, 2021 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-13 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 November 29, 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . 7 68 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8 69 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 8 70 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 23 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. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 29 102 9.3. Using a Candidate Path for Path Protection . . . . . . . 30 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 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. Intermediate per-path states are 118 eliminated thanks to source routing. 120 The headend node is said to steer a flow into a Segment Routing 121 Policy (SR Policy). [RFC8402] introduces the SR Policy construct and 122 provides an overview of how it is leveraged for Segment Routing use- 123 cases. 125 The packets steered into an SR Policy carry an ordered list of 126 segments associated with that SR Policy. [RFC8660] describes the 127 representation and processing of these ordered list of segments as an 128 MPLS label stack for SR-MPLS. While [RFC8754] and [RFC8986] describe 129 the same for Segment Routing over IPv6 (SRv6) with the use of the 130 Segment Routing Header (SRH). 132 This document details the concepts of SR Policy and steering packets 133 into an SR Policy. These apply equally to the SR-MPLS and SRv6 134 instantiations of segment routing. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2. SR Policy 146 An SR Policy is a framework that enables the instantiation of an 147 ordered list of segments on a node for implementing a source routing 148 policy for the steering of traffic for a specific purpose (e.g. for a 149 specific SLA) from that node. 151 The Segment Routing architecture [RFC8402] specifies that any 152 instruction can be bound to a segment. Thus, an SR Policy can be 153 built using any type of Segment Identifier (SID) including those 154 associated with topological or service instructions. 156 This section defines the key aspects and constituents of an SR 157 Policy. 159 2.1. Identification of an SR Policy 161 An SR Policy is identified through the tuple . In the context of a specific headend, one may identify an 163 SR policy by the tuple. 165 The headend is the node where the policy is instantiated/implemented. 166 The headend is specified as an IPv4 or IPv6 address and is expected 167 to be unique in the domain. 169 The endpoint indicates the destination of the policy. The endpoint 170 is specified as an IPv4 or IPv6 address and is expected to be unique 171 in the domain. In a specific case (refer to Section 8.8.1), the 172 endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6). 174 The color is a 32-bit numerical value that associates the SR Policy 175 with an intent or objective (e.g. low-latency). 177 The endpoint and the color are used to automate the steering of 178 service or transport routes on SR Policies (refer to Section 8). 180 An implementation MAY allow assignment of a symbolic name comprising 181 of printable ASCII characters to an SR Policy to serve as a user- 182 friendly attribute for debugging and troubleshooting purposes. Such 183 symbolic names may identify an SR Policy when the naming scheme 184 ensures uniqueness. The SR Policy name may also be signaled along 185 with a candidate path of the SR Policy (refer to Section 2.2). An SR 186 Policy may have multiple names associated with it in the scenario 187 where the headend receives different SR Policy names along with 188 candidate paths for the same SR Policy. 190 2.2. Candidate Path and Segment List 192 An SR Policy is associated with one or more candidate paths. A 193 candidate path is the unit for signaling of an SR Policy to a headend 194 via protocol extensions like Path Computation Element (PCE) 195 Communication Protocol (PCEP) [RFC8664] 196 [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy 197 [I-D.ietf-idr-segment-routing-te-policy]. 199 A Segment-List represents a specific source-routed path to send 200 traffic from the headend to the endpoint of the corresponding SR 201 policy. 203 A candidate path is either dynamic, explicit, or composite. 205 An explicit candidate path is expressed as a Segment-List or a set of 206 Segment-Lists. 208 A dynamic candidate path expresses an optimization objective and a 209 set of constraints. The headend (potentially with the help of a PCE) 210 computes the solution Segment-List (or set of Segment-Lists) that 211 solves the optimization problem. 213 If a candidate path is associated with a set of Segment-Lists, each 214 Segment-List is associated with weight for weighted load balancing 215 (refer to Section 2.11 for details). The default weight is 1. 217 A composite candidate path acts as a container for grouping SR 218 Policies. The composite candidate path construct enables the 219 combination of SR Policies, each with explicit candidate paths and/or 220 dynamic candidate paths with potentially different optimization 221 objectives and constraints, for load-balanced steering of packet 222 flows over its constituent SR Policies. The following criteria apply 223 for inclusion of constituent SR Policies using a composite candidate 224 path under a parent SR Policy: 226 o the endpoints of the constituent SR Policies and the parent SR 227 Policy MUST be identical 229 o The colors of each of the constituent SR Policies and the parent 230 SR Policy MUST be different 232 o the constituent SR Policies MUST NOT use composite candidate paths 234 Each constituent SR Policy of a composite candidate path is 235 associated with weight for load-balancing purposes (refer to 236 Section 2.11 for details). The default weight is 1. 238 2.3. Protocol-Origin of a Candidate Path 240 A headend may be informed about a candidate path for an SR Policy 241 by various means including: via configuration, PCEP 242 [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP 243 [I-D.ietf-idr-segment-routing-te-policy]. 245 Protocol-Origin of a candidate path is an 8-bit value associated with 246 the mechanism or protocol used for signaling/provisioning the SR 247 Policy. It helps identify the protocol/mechanism that provides or 248 signals the candidate path and indicates its preference relative to 249 other protocols/mechanisms. 251 The head-end assigns different Protocol-Origin values to each source 252 of SR Policy information. The Protocol-Origin value is used as a 253 tie-breaker between candidate-paths of equal preference, as described 254 in Section 2.9. The table below specifies the RECOMMENDED default 255 values of Protocol-Origin: 257 +-----------------+-------------------+ 258 | Protocol-Origin | Description | 259 +-----------------+-------------------+ 260 | 10 | PCEP | 261 | 20 | BGP SR Policy | 262 | 30 | Via Configuration | 263 +-----------------+-------------------+ 265 Table 1: Protocol-Origin default values 267 Implementations MAY allow modifications of these default values 268 assigned to protocols on the headend along similar lines as a routing 269 administrative distance. Its application in the candidate path 270 selection is described in Section 2.9. 272 2.4. Originator of a Candidate Path 274 Originator identifies the node which provisioned or signaled the 275 candidate path on the headend. The originator is expressed in the 276 form of a 160-bit numerical value formed by the concatenation of the 277 fields of the tuple as 278 below: 280 o Autonomous System Number (ASN) : represented as a 4-byte number. 281 If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and 282 the high-order bits MUST be set to zero. 284 o Node Address : represented as a 128-bit value. IPv4 addresses 285 MUST be encoded in the lowest 32 bits, and the high-order bits 286 MUST be set to zero. 288 Its application in the candidate path selection is described in 289 Section 2.9. 291 When provisioning is via configuration, the ASN and node address MAY 292 be set to either the headend or the provisioning controller/node ASN 293 and address. The default value is 0 for both AS and node address. 295 When signaling is via PCEP, it is the IPv4 or IPv6 address of the PCE 296 and the AS number SHOULD be set to 0 by default when not available or 297 known. 299 When signaling is via BGP SR Policy, the ASN and Node Address are 300 provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) 301 on the headend. 303 2.5. Discriminator of a Candidate Path 305 The Discriminator is a 32-bit value associated with a candidate path 306 that uniquely identifies it within the context of an SR Policy from a 307 specific Protocol-Origin as specified below: 309 When provisioning is via configuration, this is an implementation's 310 configuration model-specific unique identifier for a candidate path. 311 The default value is 0. 313 When signaling is via PCEP, the method to uniquely signal an 314 individual candidate path along with its discriminator is described 315 in [I-D.ietf-pce-segment-routing-policy-cp]. The default value is 0. 317 When signaling is via BGP SR Policy, the BGP process receiving the 318 route provides the distinguisher (refer to Section 2.1 of 319 [I-D.ietf-idr-segment-routing-te-policy]) as the discriminator. 321 Its application in the candidate path selection is described in 322 Section 2.9. 324 2.6. Identification of a Candidate Path 326 A candidate path is identified in the context of a single SR Policy. 328 A candidate path is not shared across SR Policies. 330 A candidate path is not identified by its Segment-List(s). 332 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 333 candidate path of SR Policy Pol2, then these two candidate paths 334 are independent, even if they happen to have the same Segment- 335 List. The Segment-List does not identify a candidate path. The 336 Segment-List is an attribute of a candidate path. 338 The identity of a candidate path MUST be uniquely established in the 339 context of an SR Policy to handle add, 340 delete or modify operations on them in an unambiguous manner 341 regardless of their source(s). 343 The tuple uniquely 344 identifies a candidate path. 346 Candidate paths MAY also be assigned or signaled with a symbolic name 347 comprising printable ASCII characters to serve as a user-friendly 348 attribute for debugging and troubleshooting purposes. Such symbolic 349 names MUST NOT be considered as identifiers for a candidate path. 351 2.7. Preference of a Candidate Path 353 The preference of the candidate path is used to select the best 354 candidate path for an SR Policy. It is a 32-bit value and the 355 default preference is 100. 357 It is RECOMMENDED that each candidate path of a given SR policy has a 358 different preference. 360 2.8. Validity of a Candidate Path 362 A candidate path is usable when it is valid. A common path validity 363 criterion is the validity of its constituent Segment-Lists. The 364 validation rules are specified in Section 5. 366 2.9. Active Candidate Path 368 A candidate path is selected when it is valid and it is determined to 369 be the best path of the SR Policy. The selected path is referred to 370 as the "active path" of the SR policy in this document. 372 Whenever a new path is learned or an active path is deleted, the 373 validity of an existing path changes or an existing path is changed, 374 the selection process MUST be re-executed. 376 The candidate path selection process operates on the candidate path 377 Preference. A candidate path is selected when it is valid and it has 378 the highest preference value among all the candidate paths of the SR 379 Policy. 381 In the case of multiple valid candidate paths of the same preference, 382 the tie-breaking rules are evaluated on the identification tuple in 383 the following order until only one valid best path is selected: 385 1. Higher value of Protocol-Origin is selected. 387 2. If specified by configuration, prefer the existing installed 388 path. 390 3. Lower value of originator is selected. 392 4. Finally, the higher value of discriminator is selected. 394 The rules are framed with multiple protocols and sources in mind and 395 hence may not follow the logic of a single protocol (e.g. BGP best 396 path selection). The motivation behind these rules are as follows: 398 o The Protocol-Origin allows an operator to set up a default 399 selection mechanism across protocol sources, e.g., to prefer 400 configured over paths signaled via BGP SR Policy or PCEP. 402 o The preference, being the first tiebreaker, allows an operator to 403 influence selection across paths thus allowing provisioning of 404 multiple path options, e.g., CP1 is preferred and if it becomes 405 invalid then fallback to CP2 and so on. Since preference works 406 across protocol sources, it also enables (where necessary) 407 selective override of the default Protocol-Origin preference, 408 e.g., to prefer a path signaled via BGP SR Policy over what is 409 configured. 411 o The originator allows an operator to have multiple redundant 412 controllers and still maintain a deterministic behavior over which 413 of them are preferred even if they are providing the same 414 candidate paths for the same SR policies to the headend. 416 o The discriminator performs the final tiebreaking step to ensure a 417 deterministic outcome of selection regardless of the order in 418 which candidate paths are signaled across multiple transport 419 channels or sessions. 421 Section 4 of [I-D.filsfils-spring-sr-policy-considerations] provides 422 a set of examples to illustrate the active candidate path selection 423 rules. 425 2.10. Validity of an SR Policy 427 An SR Policy is valid when it has at least one valid candidate path. 429 2.11. Instantiation of an SR Policy in the Forwarding Plane 431 A valid SR Policy is instantiated in the forwarding plane. 433 Only the active candidate path SHOULD be used for forwarding traffic 434 that is being steered onto that policy. 436 If a set of Segment-Lists is associated with the active path of the 437 policy, then the steering is per-flow and weighted-ECMP (W-ECMP) 438 based according to the relative weight of each Segment-List. 440 The fraction of the flows associated with a given Segment-List is w/ 441 Sw, where w is the weight of the Segment-List and Sw is the sum of 442 the weights of the Segment-Lists of the selected path of the SR 443 Policy. 445 When a composite candidate path is active, the fraction of flows 446 steered into each constituent SR Policy is equal to the relative 447 weight of each constituent SR Policy. Further load balancing of 448 flows steered into a constituent SR Policy is performed based on the 449 weights of the Segment-List of the active candidate path of that 450 constituent SR Policy. 452 The accuracy of the weighted load-balancing depends on the platform 453 implementation. 455 2.12. Priority of an SR Policy 457 Upon topological change, many policies could be recomputed or 458 revalidated. An implementation MAY provide a per-policy priority 459 configuration. The operator MAY set this field to indicate the order 460 in which the policies should be re-computed. Such a priority is 461 represented by an integer in the range (0, 255) where the lowest 462 value is the highest priority. The default value of priority is 128. 464 An SR Policy may comprise multiple Candidate Paths received from the 465 same or different sources. A candidate path MAY be signaled with a 466 priority value. When an SR Policy has multiple candidate paths with 467 distinct signaled non-default priority values, the SR Policy as a 468 whole takes the lowest value (i.e. the highest priority) amongst 469 these signaled priority values. 471 2.13. Summary 473 In summary, the information model is the following: 475 SR policy POL1 476 Candidate-path CP1 478 Preference 200 479 Weight W1, SID-List1 480 Weight W2, SID-List2 481 Candidate-path CP2 483 Preference 100 484 Weight W3, SID-List3 485 Weight W4, SID-List4 487 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 489 identified by a tuple . 490 CP1 is the active candidate path (it is valid and has the highest 491 preference). The two Segment-Lists of CP1 are installed as the 492 forwarding instantiation of SR policy POL1. Traffic steered on POL1 493 is flow-based hashed on Segment-List with a ratio 494 W1/(W1+W2). 496 The information model of SR Policy POL100 having a composite 497 candidate path is the following: 499 SR policy POL100 500 Candidate-path CP1 502 Preference 200 503 Weight W1, SR policy 504 Weight W2, SR policy 506 The constituent SR Policies POL1 and POL2 have an information model 507 as described at the start of this section. They are referenced only 508 by color in the composite candidate path since their headend and 509 endpoint are identical to the POL100. The valid Segment-Lists of the 510 active candidate path of POL1 and POL2 are installed in the 511 forwarding. Traffic steered on POL100 is flow-based hashed on POL1 512 with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing 513 over its Segment-Lists are performed as described earlier in this 514 section. 516 3. Segment Routing Database 518 An SR Policy computation node (e.g. headend or controller) maintains 519 the Segment Routing Database (SR-DB). The SR-DB is a conceptual 520 database to illustrate the various pieces of information and their 521 sources that may help in SR Policy computation and validation. There 522 is no specific requirement for an implementation to create a new 523 database as such. 525 An SR headend leverages the SR-DB to validate explicit candidate 526 paths and compute dynamic candidate paths. 528 The information in the SR-DB MAY include: 530 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 531 OSPF [RFC2328] [RFC5340]) 532 o Segment Routing information (such as Segment Routing Global Block, 533 Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Peering 534 SID, SRv6 SIDs) [RFC8402] [RFC8986] 535 o TE Link Attributes (such as TE metric, Shared Risk Link Groups, 536 attribute-flag, extended admin group) [RFC5305] [RFC3630]. 537 o Extended TE Link attributes (such as latency, loss) [RFC8570] 538 [RFC7471] 539 o Inter-AS Topology information 540 [I-D.ietf-idr-bgpls-segment-routing-epe]. 542 The attached domain topology MAY be learned via IGP, BGP-LS or 543 NETCONF. 545 A non-attached (remote) domain topology MAY be learned via BGP-LS or 546 NETCONF. 548 In some use-cases, the SR-DB may only contain the attached domain 549 topology while in others, the SR-DB may contain the topology of 550 multiple domains and in this case, it is multi-domain capable. 552 The SR-DB MAY also contain the SR Policies instantiated in the 553 network. This can be collected via BGP-LS 554 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231], 555 [I-D.ietf-pce-segment-routing-policy-cp], and 556 [I-D.ietf-pce-binding-label-sid]. This information allows to build 557 an end-to-end policy on the basis of intermediate SR policies (see 558 Section 6 for further details). 560 The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of 561 nodes in the topology. This can be collected via ISIS [RFC8491], 562 OSPF [RFC8476], BGP-LS [RFC8814] or PCEP [RFC8664]. 564 The use of the SR-DB for computation and validation of SR Policies is 565 outside the scope of this document. Some implementation aspects 566 related to this are covered in 567 [I-D.filsfils-spring-sr-policy-considerations]. 569 4. Segment Types 571 A Segment-List is an ordered set of segments represented as where S1 is the first segment. 574 Based on the desired dataplane, either the MPLS label stack or the 575 SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. 576 However, the Segment-List itself can be specified using different 577 segment-descriptor types and the following are currently defined: 579 Type A: SR-MPLS Label: 580 An MPLS label corresponding to any of the segment types defined 581 for SR-MPLS (as defined in [RFC8402] or other SR-MPLS 582 specifications) can be used. Additionally, reserved labels 583 like explicit-null or in general any MPLS label may also be 584 used. E.g. this type can be used to specify a label 585 representation that maps to an optical transport path on a 586 packet transport node. This type does not require the headend 587 to perform SID resolution. 589 Type B: SRv6 SID: 590 An IPv6 address corresponding to any of the SID behaviors for 591 SRv6 (as defined in [RFC8986] or other SRv6 specifications) can 592 be used. This type does not require the headend to perform SID 593 resolution. Optionally, the SRv6 SID behavior (as defined in 594 [RFC8986] or other SRv6 specifications) and structure (as 595 defined in [RFC8986]) MAY also be provided for the headend to 596 perform validation of the SID when using it for building the 597 Segment List. 599 Type C: IPv4 Prefix with optional SR Algorithm: 600 The headend is required to resolve the specified IPv4 Prefix 601 Address to the SR-MPLS label corresponding to a Prefix SID 602 segment (as defined in [RFC8402]). The SR algorithm (refer to 603 Section 3.1.1 of [RFC8402]) to be used MAY also be provided. 605 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 606 In this case, the headend is required to resolve the specified 607 IPv6 Global Prefix Address to the SR-MPLS label corresponding 608 to its Prefix SID segment (as defined in [RFC8402]). The SR 609 Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY 610 also be provided. 612 Type E: IPv4 Prefix with Local Interface ID: 613 This type allows identification of Adjacency SID or BGP Peer 614 Adjacency SID (as defined in [RFC8402]) label for point-to- 615 point links including IP unnumbered links. The headend is 616 required to resolve the specified IPv4 Prefix Address to the 617 Node originating it and then use the Local Interface ID to 618 identify the point-to-point link whose adjacency is being 619 referred to. The Local Interface ID link descriptor follows 620 semantics as specified in [RFC7752]. This type can also be 621 used to indicate indirection into a layer 2 interface (i.e. 622 without IP address) like a representation of an optical 623 transport path or a layer 2 Ethernet port or circuit at the 624 specified node. 626 Type F: IPv4 Addresses for link endpoints as Local, Remote pair: 627 This type allows identification of Adjacency SID or BGP Peer 628 Adjacency SID (as defined in [RFC8402]) label for links. The 629 headend is required to resolve the specified IPv4 Local Address 630 to the Node originating it and then use the IPv4 Remote Address 631 to identify the link adjacency being referred to. The Local 632 and Remote Address pair link descriptors follow semantics as 633 specified in [RFC7752]. 635 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 636 Remote pair for SR-MPLS: 637 This type allows identification of Adjacency SID or BGP Peer 638 Adjacency SID (as defined in [RFC8402]) label for links 639 including those with only Link-Local IPv6 addresses. The 640 headend is required to resolve the specified IPv6 Prefix 641 Address to the Node originating it and then use the Local 642 Interface ID to identify the point-to-point link whose 643 adjacency is being referred to. For other than point-to-point 644 links, additionally the specific adjacency over the link needs 645 to be resolved using the Remote Prefix and Interface ID. The 646 Local and Remote pair of Prefix and Interface ID link 647 descriptor follows semantics as specified in [RFC7752]. This 648 type can also be used to indicate indirection into a layer 2 649 interface (i.e. without IP address) like a representation of an 650 optical transport path or a layer 2 Ethernet port or circuit at 651 the specified node. 653 Type H: IPv6 Addresses for link endpoints as Local, Remote pair for 654 SR-MPLS: 655 This type allows identification of Adjacency SID or BGP Peer 656 Adjacency SID (as defined in [RFC8402]) label for links with 657 Global IPv6 addresses. The headend is required to resolve the 658 specified Local IPv6 Address to the Node originating it and 659 then use the Remote IPv6 Address to identify the link adjacency 660 being referred to. The Local and Remote Address pair link 661 descriptors follow semantics as specified in [RFC7752]. 663 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: 664 The headend is required to resolve the specified IPv6 Global 665 Prefix Address to an SRv6 SID corresponding to a Prefix SID 666 segment (as defined in [RFC8402]), such as a SID associated 667 with the End behavior (as defined in [RFC8986]), of the node 668 which is originating the prefix. The SR Algorithm (refer to 669 Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as defined 670 in [RFC8986] or other SRv6 specifications) and structure (as 671 defined in [RFC8986]) MAY also be provided. 673 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 674 Remote pair for SRv6: 675 This type allows identification of an SRv6 SID corresponding to 676 an Adjacency SID or BGP Peer Adjacency SID (as defined in 677 [RFC8402]), such as a SID associated with the End.X behavior 678 (as defined in [RFC8986]), associated with link or adjacency 679 with only Link-Local IPv6 addresses. The headend is required 680 to resolve the specified IPv6 Prefix Address to the Node 681 originating it and then use the Local Interface ID to identify 682 the point-to-point link whose adjacency is being referred to. 683 For other than point-to-point links, additionally the specific 684 adjacency needs to be resolved using the Remote Prefix and 685 Interface ID. The Local and Remote pair of Prefix and 686 Interface ID link descriptor follows semantics as specified in 687 [RFC7752]. The SR Algorithm (refer to Section 3.1.1 of 688 [RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or 689 other SRv6 specifications) and structure (as defined in 690 [RFC8986]) MAY also be provided. 692 Type K: IPv6 Addresses for link endpoints as Local, Remote pair for 693 SRv6: 694 This type allows identification of an SRv6 SID corresponding to 695 an Adjacency SID or BGP Peer Adjacency SID (as defined in 696 [RFC8402]), such as a SID associated with the End.X behavior 697 (as defined in [RFC8986]), associated with link or adjacency 698 with Global IPv6 addresses. The headend is required to resolve 699 the specified Local IPv6 Address to the Node originating it and 700 then use the Remote IPv6 Address to identify the link adjacency 701 being referred to. The Local and Remote Address pair link 702 descriptors follow semantics as specified in [RFC7752]. The SR 703 Algorithm (refer to Section 3.1.1 of [RFC8402]), the SRv6 SID 704 behavior (as defined in [RFC8986] or other SRv6 specifications) 705 and structure (as defined in [RFC8986]) MAY also be provided. 707 When the algorithm is not specified for the SID types above which 708 optionally allow for it, the headend SHOULD use the Strict Shortest 709 Path algorithm if available; otherwise, it SHOULD use the default 710 Shortest Path algorithm. The specification of the algorithm enables 711 the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific 712 SIDs in SR Policy. 714 For SID types C-through-K, a SID value may also be optionally 715 provided to the headend for verification purposes. Section 5.1. 716 describes the resolution and verification of the SIDs and Segment 717 Lists on the headend. 719 When building the MPLS label stack or the IPv6 Segment list from the 720 Segment List, the node instantiating the policy MUST interpret the 721 set of Segments as follows: 723 o The first Segment represents the topmost label or the first IPv6 724 segment. It identifies the active segment the traffic will be 725 directed toward along the explicit SR path. 726 o The last Segment represents the bottommost label or the last IPv6 727 segment the traffic will be directed toward along the explicit SR 728 path. 730 4.1. Explicit Null 732 A Type A SID may be any MPLS label, including reserved labels. 734 For example, assuming that the desired traffic-engineered path from a 735 headend 1 to an endpoint 4 can be expressed by the Segment-List 736 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 737 to the IPv4 Prefix SIDs bound to node 2, 3, and 4, then IPv6 traffic 738 can be traffic-engineered from nodes 1 to 4 via the previously 739 described path using an SR Policy with Segment-List <16002, 16003, 740 16004, 2> where the MPLS label value of 2 represents the "IPv6 741 Explicit NULL Label". 743 The penultimate node before node 4 will pop 16004 and will forward 744 the frame on its directly connected interface to node 4. 746 The endpoint receives the traffic with the top label "2" which 747 indicates that the payload is an IPv6 packet. 749 When steering unlabeled IPv6 BGP destination traffic using an SR 750 policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit 751 Null Label Policy is processed as specified in 752 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 753 "IPv6 Explicit NULL label" is not present as the bottom label, the 754 headend SHOULD automatically impose one. Refer to Section 8 for more 755 details. 757 5. Validity of a Candidate Path 759 5.1. Explicit Candidate Path 761 An explicit candidate path is associated with a Segment-List or a set 762 of Segment-Lists. 764 An explicit candidate path is provisioned by the operator directly or 765 via a controller. 767 The computation/logic that leads to the choice of the Segment-List is 768 external to the SR Policy headend. The SR Policy headend does not 769 compute the Segment-List. The SR Policy headend only confirms its 770 validity. 772 An explicit candidate path MAY consist of a single explicit Segment- 773 List containing only an implicit-null label to indicate pop-and- 774 forward behavior. The Binding SID (BSID) is popped and the traffic 775 is forwarded based on the inner label or an IP lookup in the case of 776 unlabeled IP packets. Such an explicit path can serve as a fallback 777 or path of last resort for traffic being steered into an SR Policy 778 using its BSID (refer to Section 8.3). 780 A Segment-List of an explicit candidate path MUST be declared invalid 781 when: 783 o It is empty. 784 o Its weight is 0. 785 o It comprises of a mix of SR-MPLS and SRv6 segment types. 786 o The headend is unable to perform path resolution for the first SID 787 into one or more outgoing interface(s) and next-hop(s). 788 o The headend is unable to perform SID resolution for any non-first 789 SID of type C-through-K into an MPLS label or an SRv6 SID. 790 o The headend verification fails for any SID for which verification 791 has been explicitly requested. 793 "Unable to perform path resolution" means that the headend has no 794 path to the SID in its SR database. 796 SID verification is performed when the headend is explicitly 797 requested to verify SID(s) by the controller via the signaling 798 protocol used. Implementations MAY provide a local configuration 799 option to enable verification on a global or per policy or per 800 candidate path basis. 802 "Verification fails" for a SID means any of the following: 804 o The headend is unable to find the SID in its SR-DB 805 o The headend detects a mis-match between the SID value and its 806 context provided for SIDs of type C-through-L in its SR-DB. 807 o The headend is unable to perform SID resolution for any non-first 808 SID of type C-through-K into an MPLS label or an SRv6 SID. 810 In multi-domain deployments, it is expected that the headend be 811 unable to verify the reachability of the SIDs in remote domains. 812 Types A or B MUST be used for the SIDs for which the reachability 813 cannot be verified. Note that the first SID MUST always be reachable 814 regardless of its type. 816 Additionally, a Segment-List MAY be declared invalid when: 818 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 819 advertised by the node specified as the endpoint of the 820 corresponding SR policy. 821 o Its last segment is not an Adjacency SID (including BGP Peer 822 Adjacency SID) of any of the links present on neighbor nodes and 823 that terminate on the node specified as the endpoint of the 824 corresponding SR policy. 826 An explicit candidate path is invalid as soon as it has no valid 827 Segment-List. 829 Additionally, an explicit candidate path MAY be declared invalid when 830 its constituent segment lists (valid or invalid) are using segment 831 types of different SR dataplanes. 833 5.2. Dynamic Candidate Path 835 A dynamic candidate path is specified as an optimization objective 836 and constraints. 838 The headend of the policy leverages its SR database to compute a 839 Segment-List ("solution Segment-List") that solves this optimization 840 problem for either the SR-MPLS or the SRv6 data-plane as specfied. 842 The headend re-computes the solution Segment-List any time the inputs 843 to the problem change (e.g., topology changes). 845 When the local computation is not possible (e.g., a policy's tail-end 846 is outside the topology known to the headend) or not desired, the 847 headend MAY send path computation request to a PCE supporting PCEP 848 extension specified in [RFC8664]. 850 If no solution is found to the optimization objective and 851 constraints, then the dynamic candidate path MUST be declared 852 invalid. 854 Section 3 of [I-D.filsfils-spring-sr-policy-considerations] discusses 855 some of the optimization objectives and constraints that may be 856 considered by a dynamic candidate path. It illustrates some of the 857 desirable properties of the computation of the solution Segment-List. 859 5.3. Composite Candidate Path 861 A composite candidate path is specified as a group of its constituent 862 SR Policies. 864 A composite candidate path is valid when it has at least one valid 865 constituent SR Policy. 867 6. Binding SID 869 The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 870 It provides scaling, network opacity, and service independence. 871 Section 6 of [I-D.filsfils-spring-sr-policy-considerations] 872 illustrates some of these benefits. This section describes the 873 association of BSID with an SR Policy. 875 6.1. BSID of a candidate path 877 Each candidate path MAY be defined with a BSID. 879 Candidate Paths of the same SR policy SHOULD have the same BSID. 881 Candidate Paths of different SR policies MUST NOT have the same BSID. 883 6.2. BSID of an SR Policy 885 The BSID of an SR Policy is the BSID of its active candidate path. 887 When the active candidate path has a specified BSID, the SR Policy 888 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 889 available (i.e., not associated with any other usage: e.g. to another 890 MPLS client, to another SRv6 client, to another SID, to another SR 891 Policy, outside the range of SRv6 Locators). 893 In the case of SR-MPLS, SRv6 BSIDs (e.g. with the behavior End.BM 894 [RFC8986]) MAY be associated with the SR Policy in addition to the 895 MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g. with 896 different behaviors like End.B6.Encap and End.B6.Encap.Red [RFC8986]) 897 MAY be associated with the SR Policy. 899 Optionally, instead of only checking that the BSID of the active path 900 is available, a headend MAY check that it is available within a given 901 SID range i.e., Segment Routing Local Block (SRLB) as specified in 902 [RFC8402]. 904 When the specified BSID is not available (optionally is not in the 905 SRLB), an alert message MUST be generated. 907 In the cases (as described above) where SR Policy does not have a 908 BSID available, then the SR Policy MAY dynamically bind a BSID to 909 itself. Dynamically bound BSID SHOULD use an available SID outside 910 the SRLB. 912 Assuming that at time t the BSID of the SR Policy is B1, if at time 913 t+dt a different candidate path becomes active and this new active 914 path does not have a specified BSID or its BSID is specified but is 915 not available (e.g. it is in use by something else), then the SR 916 Policy keeps the previous BSID B1. 918 The association of an SR Policy with a BSID thus MAY change over the 919 life of the SR Policy (e.g., upon active path change). Hence, the 920 BSID SHOULD NOT be used as an identification of an SR Policy. 922 6.2.1. Frequent use-case : unspecified BSID 924 All the candidate paths of the same SR Policy can have an unspecified 925 BSID. 927 In such a case, a BSID MAY be dynamically bound to the SR Policy as 928 soon as the first valid candidate path is received. That BSID is 929 kept through the life of the SR Policy and across changes of active 930 candidate path. 932 6.2.2. Frequent use-case: all specified to the same BSID 934 All the paths of the SR Policy can have the same specified BSID. 936 6.2.3. Specified-BSID-only 938 An implementation MAY support the configuration of the Specified- 939 BSID-only restrictive behavior on the headend for all SR Policies or 940 individual SR Policies. Further, this restrictive behavior MAY also 941 be signaled on a per SR Policy basis to the headend. 943 When this restrictive behavior is enabled, if the candidate path has 944 an unspecified BSID or if the specified BSID is not available when 945 the candidate path becomes active then no BSID is bound to it and it 946 is considered invalid. An alert MUST be triggered for this error. 948 Other candidate paths MUST then be evaluated for becoming the active 949 candidate path. 951 6.3. Forwarding Plane 953 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 954 with the action of steering the packets matching this entry to the 955 selected path of the SR Policy. 957 If the Specified-BSID-only restrictive behavior is enabled and the 958 BSID of the active path is not available (optionally not in the 959 SRLB), then the SR Policy does not install any entry indexed by a 960 BSID in the forwarding plane. 962 6.4. Non-SR usage of Binding SID 964 An implementation MAY choose to associate a Binding SID with any type 965 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 966 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 967 tunnel, etc). This enables the use of other non-SR enabled 968 interfaces and tunnels as segments in an SR Policy Segment-List 969 without the need of forming routing protocol adjacencies over them. 971 The details of this kind of usage are beyond the scope of this 972 document. A specific packet-optical integration use case is 973 described in [I-D.anand-spring-poi-sr]. 975 7. SR Policy State 977 The SR Policy State is maintained on the headend to represent the 978 state of the policy and its candidate paths. This is to provide an 979 accurate representation of whether the SR Policy is being 980 instantiated in the forwarding plane and which of its candidate paths 981 and segment-list(s) are active. The SR Policy state MUST also 982 reflect the reason when a policy and/or its candidate path is not 983 active due to validation errors or not being preferred. 985 The SR Policy state can be reported by the headend node via BGP-LS 986 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 987 [I-D.ietf-pce-binding-label-sid]. 989 SR Policy state on the headend also includes traffic accounting 990 information for the flows being steered via the policies. The 991 details of the SR Policy accounting are beyond the scope of this 992 document. The aspects related to the SR traffic counters and their 993 usage in the broader context of traffic accounting in an SR network 994 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 995 [I-D.ali-spring-sr-traffic-accounting] respectively. 997 Implementations MAY support an administrative state to control 998 locally provisioned policies via mechanisms like CLI or NETCONF. 1000 8. Steering into an SR Policy 1002 A headend can steer a packet flow into a valid SR Policy in various 1003 ways: 1005 o Incoming packets have an active SID matching a local BSID at the 1006 headend. 1007 o Per-destination Steering: incoming packets match a BGP/Service 1008 route which recurses on an SR policy. 1009 o Per-flow Steering: incoming packets match or recurse on a 1010 forwarding array of where some of the entries are SR Policies. 1011 o Policy-based Steering: incoming packets match a routing policy 1012 that directs them on an SR policy. 1014 8.1. Validity of an SR Policy 1016 An SR Policy is invalid when all its candidate paths are invalid as 1017 described in Section 5 and Section 2.10. 1019 By default, upon transitioning to the invalid state, 1021 o an SR Policy and its BSID are removed from the forwarding plane. 1022 o any steering of a service (Pseudowire (PW)), destination (BGP- 1023 VPN), flow or packet on the related SR policy is disabled and the 1024 related service, destination, flow, or packet is routed per the 1025 classic forwarding table (e.g. longest-match to the destination or 1026 the recursing next-hop). 1028 8.2. Drop upon invalid SR Policy 1030 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 1032 o an invalid SR Policy and its BSID is kept in the forwarding plane 1033 with an action to drop. 1034 o any steering of a service (PW), destination (BGP-VPN), flow or 1035 packet on the related SR policy is maintained with the action to 1036 drop all of this traffic. 1038 The drop-upon-invalid behavior has been deployed in use-cases where 1039 the operator wants some PW to only be transported on a path with 1040 specific constraints. When these constraints are no longer met, the 1041 operator wants the PW traffic to be dropped. Specifically, the 1042 operator does not want the PW to be routed according to the IGP 1043 shortest path to the PW endpoint. 1045 8.3. Incoming Active SID is a BSID 1047 Let us assume that headend H has a valid SR Policy P of Segment-List 1048 and BSID B. 1050 In the case of SR-MPLS, when H receives a packet K with label stack 1051 , H pops B and pushes and forwards the 1052 resulting packet according to SID S1. 1054 "Forwarding the resulting packet according to S1" means: If S1 is 1055 an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H 1056 sends the resulting packet with label stack on 1057 the outgoing interface associated with S1; Else H sends the 1058 resulting packet with label stack along the 1059 path of S1. 1061 In the case of SRv6, the processing is similar and follows the SR 1062 Policy headend behaviors as specified in section 5 of [RFC8986]. 1064 H has steered the packet into the SR policy P. 1066 H did not have to classify the packet. The classification was done 1067 by a node upstream of H (e.g., the source of the packet or an 1068 intermediate ingress edge node of the SR domain) and the result of 1069 this classification was efficiently encoded in the packet header as a 1070 BSID. 1072 This is another key benefit of the segment routing in general and the 1073 binding SID in particular: the ability to encode a classification and 1074 the resulting steering in the packet header to better scale and 1075 simplify intermediate aggregation nodes. 1077 If the SR Policy P is invalid, the BSID B is not in the forwarding 1078 plane and hence the packet K is dropped by H. 1080 8.4. Per-Destination Steering 1082 In the case of SR-MPLS, let us assume that headend H: 1084 o learns a BGP route R/r via next-hop N, extended-color community C 1085 and VPN label V. 1086 o has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1087 List and BSID B. 1088 o has a BGP policy that matches on the extended-color community C 1089 and allows its usage as SLA steering information. 1091 If all these conditions are met, H installs R/r in RIB/FIB with next- 1092 hop = SR Policy P of BSID B instead of via N. 1094 Indeed, H's local BGP policy and the received BGP route indicate that 1095 the headend should associate R/r with an SR Policy path to endpoint N 1096 with the SLA associated with color C. The headend, therefore, 1097 installs the BGP route on that policy. 1099 This can be implemented by using the BSID as a generalized next-hop 1100 and installing the BGP route on that generalized next-hop. 1102 When H receives a packet K with a destination matching R/r, H pushes 1103 the label stack and sends the resulting packet along 1104 the path to S1. 1106 Note that any SID associated with the BGP route is inserted after the 1107 Segment-List of the SR Policy (i.e., ). 1109 In the case of SRv6, the processing is similar and follows the SR 1110 Policy headend behaviors as specified in section 5 of [RFC8986]. 1112 The same behavior applies to any type of service route: any AFI/SAFI 1113 of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1115 In a BGP multi-path scenario, the BGP route may be resolved over a 1116 mix of paths that include those that are steered over SR Policies and 1117 others resolved via the normal BGP nexthop resolution. 1118 Implementations MAY provide options to prefer one type over the other 1119 or other forms of local policy to determine the paths that are 1120 selected. 1122 8.4.1. Multiple Colors 1124 When a BGP route has multiple extended-color communities each with a 1125 valid SR Policy, the BGP process installs the route on the SR Policy 1126 giving preference to the color with the highest numerical value. 1128 Let us assume that headend H: 1130 o learns a BGP route R/r via next-hop N, extended-color communities 1131 C1 and C2. 1132 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1133 List and BSID B1. 1134 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1135 List and BSID B2. 1136 o has a BGP policy that matches the extended-color communities C1 1137 and C2 and allows their usage as SLA steering information 1139 If all these conditions are met, H installs R/r in RIB/FIB with next- 1140 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1142 When the SR Policy with a specific color is not instantiated or in 1143 the down/inactive state, the SR Policy with the next highest 1144 numerical value of color is considered. 1146 8.5. Recursion on an on-demand dynamic BSID 1148 In the previous section, it was assumed that H had a pre-established 1149 "explicit" SR Policy (color C, endpoint N). 1151 In this section, independent of the a-priori existence of any 1152 explicit candidate path of the SR policy (C, N), it is to be noted 1153 that the BGP process at headend node H triggers the instantiation of 1154 a dynamic candidate path for the SR policy (C, N) as soon as: 1156 o the BGP process learns of a route R/r via N and with color C. 1157 o a local policy at node H authorizes the on-demand SR Policy path 1158 instantiation and maps the color to a dynamic SR Policy path 1159 optimization template. 1161 8.5.1. Multiple Colors 1163 When a BGP route R/r via N has multiple extended-color communities Ci 1164 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1165 request (color Ci, endpoint N) is triggered for each color Ci. The 1166 SR Policy that is used for steering is then determined as described 1167 in Section 8.4.1. 1169 8.6. Per-Flow Steering 1171 Let us assume that headend H: 1173 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1174 List and BSID B1. 1175 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1176 List and BSID B2. 1177 o is configured to instantiate an array of paths to N where the 1178 entry 0 is the IGP path to N, color C1 is the first entry and 1179 Color C2 is the second entry. The index into the array is called 1180 a Forwarding Class (FC). The index can have values 0 to 7. 1181 o is configured to match flows in its ingress interfaces (upon any 1182 field such as Ethernet destination/source/VLAN/TOS or IP 1183 destination/source/DSCP or transport ports etc.) and color them 1184 with an internal per-packet forwarding-class variable (0, 1 or 2 1185 in this example). 1187 If all these conditions are met, H installs in RIB/FIB: 1189 o N via recursion on an array A (instead of the immediate outgoing 1190 link associated with the IGP shortest-path to N). 1191 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1192 path to N. 1193 o Entry A(1) set to SR Policy P1 of BSID=B1. 1194 o Entry A(2) set to SR Policy P2 of BSID=B2. 1196 H receives three packets K, K1, and K2 on its incoming interface. 1197 These three packets either longest-match on N or more likely on a 1198 BGP/service route which recurses on N. H colors these 3 packets 1199 respectively with forwarding-class 0, 1, and 2. 1201 As a result, for SR-MPLS: 1203 o H forwards K along the shortest path to N (i.e., pushes the 1204 prefix-SID of N). 1205 o H pushes on packet K1 and forwards the resulting 1206 frame along the shortest path to S1. 1207 o H pushes on packet K2 and forwards the resulting 1208 frame along the shortest path to S4. 1210 For SRv6, the processing is similar and the segment lists of the 1211 individual SR Policies P1 and P2 are enforced for packet K1 and K2 1212 using the SR Policy headend behaviors as specified in section 5 of 1213 [RFC8986]. 1215 If the local configuration does not specify any explicit forwarding 1216 information for an entry of the array, then this entry is filled with 1217 the same information as entry 0 (i.e. the IGP shortest path). 1219 If the SR Policy mapped to an entry of the array becomes invalid, 1220 then this entry is filled with the same information as entry 0. When 1221 all the array entries have the same information as entry0, the 1222 forwarding entry for N is updated to bypass the array and point 1223 directly to its outgoing interface and next-hop. 1225 The array index values (e.g. 0, 1, and 2) and the notion of 1226 forwarding-class are implementation-specific and only meant to 1227 describe the desired behavior. The same can be realized by other 1228 mechanisms. 1230 This realizes per-flow steering: different flows bound to the same 1231 BGP endpoint are steered on different IGP or SR Policy paths. 1233 A headend MAY support options to apply per-flow steering only for 1234 traffic matching specific prefixes (e.g. specific IGP or BGP 1235 prefixes). 1237 8.7. Policy-based Routing 1239 Finally, headend H may be configured with a local routing policy 1240 which overrides any BGP/IGP path and steer a specified packet on an 1241 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1242 automatic routing of IGP prefixes over SR Policies intended for such 1243 purpose. 1245 8.8. Optional Steering Modes for BGP Destinations 1247 8.8.1. Color-Only BGP Destination Steering 1249 In the previous section, it is seen that the steering on an SR Policy 1250 is governed by the matching of the BGP route's next-hop N and the 1251 authorized color C with an SR Policy defined by the tuple (N, C). 1253 This is the most likely form of BGP destination steering and the one 1254 recommended for most use-cases. 1256 This section defines an alternative steering mechanism based only on 1257 the color. 1259 This color-only steering variation is governed by two new "CO" bits 1260 defined in the color extended community in section 3 of 1261 [I-D.ietf-idr-segment-routing-te-policy]. 1263 The Color-Only flags "CO" are set to 00 by default. 1265 When 00, the BGP destination is steered as follows: 1267 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1269 endpoint address and C is a color; 1270 Steer into SR Policy (N, C); 1271 ELSE; 1272 Steer on the IGP path to the next-hop N. 1274 This is the classic case described in this document previously and 1275 what is recommended in most scenarios. 1277 When 01, the BGP destination is steered as follows: 1279 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1281 endpoint address and C is a color; 1282 Steer into SR Policy (N, C); 1283 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1284 same address-family of N; 1286 Steer into SR Policy (null endpoint, C); 1287 ELSE IF there is any valid SR Policy 1288 (any address-family null endpoint, C); 1289 Steer into SR Policy (any null endpoint, C); 1290 ELSE; 1291 Steer on the IGP path to the next-hop N. 1293 When 10, the BGP destination is steered as follows: 1295 IF there is a valid SR Policy (N, C) where N is an 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) 1299 of the 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 IF there is any valid SR Policy (any endpoint, C) 1305 of the same address-family of N; 1306 Steer into SR Policy (any endpoint, C); 1307 ELSE IF there is any valid SR Policy 1308 (any address-family endpoint, C); 1309 Steer into SR Policy (any address-family endpoint, C); 1310 ELSE; 1311 Steer on the IGP path to the next-hop N. 1313 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1314 to the 0 value). 1316 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1317 reception, an implementation MUST treat it like 00. 1319 8.8.2. Multiple Colors and CO flags 1321 The steering preference is first based on the highest color value and 1322 then CO-dependent for the color. Assuming a Prefix via (NH, 1323 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1325 o SR policy (NH, C1). 1326 o SR policy (null, C1). 1327 o SR policy (NH, C2). 1328 o SR policy (null, C2). 1329 o IGP to NH. 1331 8.8.3. Drop upon Invalid 1333 This document defined earlier that when all the following conditions 1334 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1335 BSID B instead of via N. 1337 o H learns a BGP route R/r via next-hop N, extended-color community 1338 C. 1339 o H has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1340 List and BSID B. 1341 o H has a BGP policy that matches the extended-color community C and 1342 allows its usage as SLA steering information. 1344 This behavior is extended by noting that the BGP policy may require 1345 the BGP steering to always stay on the SR policy whatever its 1346 validity. 1348 This is the "drop upon invalid" option described in Section 8.2 1349 applied to BGP-based steering. 1351 9. Protection 1353 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1355 In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) 1356 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1357 protection technique for IGP SIDs. The backup path is computed on a 1358 per IGP SID basis along the post-convergence path. 1360 In a network that has deployed TI-LFA, an SR Policy built on the 1361 basis of TI-LFA protected IGP segments leverages the local protection 1362 of the constituent segments. Since TI-LFA protection is based on IGP 1363 computation, there are cases where the path used during the fast- 1364 reroute time window may not meet the exact constraints of the SR 1365 Policy. 1367 In a network that has deployed TI-LFA, an SR Policy instantiated only 1368 with non-protected Adj SIDs does not benefit from any local 1369 protection. 1371 9.2. Using an SR Policy to locally protect a link 1372 1----2-----6----7 1373 | | | | 1374 4----3-----9----8 1376 Figure 1: Local protection using SR Policy 1378 An SR Policy can be instantiated at node 2 to protect the link 2to6. 1379 A typical explicit Segment-List would be <3, 9, 6>. 1381 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1382 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are 1383 part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 1384 cannot benefit from TI-LFA automated local protection. The SR Policy 1385 with Segment-List <3, 9, 6> on node 2 can be locally configured to be 1386 a fast-reroute backup path for the link 2to6. 1388 9.3. Using a Candidate Path for Path Protection 1390 An SR Policy allows for multiple candidate paths, of which at any 1391 point in time there is a single active candidate path that is 1392 provisioned in the forwarding plane and used for traffic steering. 1393 However, another (lower preference) candidate path MAY be designated 1394 as the backup for a specific or all (active) candidate path(s). The 1395 following options are possible: 1397 o A pair of disjoint candidate paths are provisioned with one of 1398 them as primary and the other is identified as its backup. 1399 o A specific candidate path is provisioned as the backup for any 1400 (active) candidate path. 1401 o The headend picks the next (lower) preference valid candidate path 1402 as the backup for the active candidate path. 1404 The headend MAY compute a-priori and validate such backup candidate 1405 paths as well as provision them into the forwarding plane as a backup 1406 for the active path. The backup candidate path may be dynamically 1407 computed or explicitly provisioned in such a way that they provide 1408 the most appropriate alternative for the active candidate path. A 1409 fast re-route mechanism MAY then be used to trigger sub 50msec 1410 switchover from the active to the backup candidate path in the 1411 forwarding plane. Mechanisms like Bidirectional Forwarding Detection 1412 (BFD) MAY be used for fast detection of such failures. 1414 10. Security Considerations 1416 This document specifies in detail the SR Policy construct introduced 1417 in [RFC8402] and its instantiation on a router supporting SR along 1418 with descriptions of mechanisms for steering of traffic flows over 1419 it. Therefore, the security considerations of [RFC8402] apply. This 1420 document does not define any new protocol extensions and does not 1421 introduce any further security considerations. 1423 11. Manageability Considerations 1425 This document specifies in detail the SR Policy construct introduced 1426 in [RFC8402] and its instantiation on a router supporting SR along 1427 with descriptions of mechanisms for steering of traffic flows over 1428 it. Therefore, the manageability considerations of [RFC8402] apply. 1430 A YANG model for the configuration and operation of SR Policy has 1431 been defined in [I-D.ietf-spring-sr-policy-yang]. 1433 12. IANA Considerations 1435 The document requests IANA to create a new sub-registry called 1436 "Segment Types" under the top-level "Segment Routing" registry that 1437 was created by [RFC8986]. This sub-registry maintains the alphabetic 1438 identifiers for the segment types (as specified in section 4) that 1439 may be used within a Segment List of an SR Policy. The alphabetical 1440 identifiers run from A to Z and may be extended on exhaustion with 1441 the identifiers AA to AZ, BA to BZ and so on through till ZZ. This 1442 sub-registry would follow the Specification Required allocation 1443 policy as specified in [RFC8126]. 1445 The initial registrations for this sub-registry are as follows: 1447 +-------+-----------------------------------------------+-----------+ 1448 | Value | Description | Reference | 1449 +-------+-----------------------------------------------+-----------+ 1450 | A | SR-MPLS Label | [This.ID] | 1451 | B | SRv6 SID | [This.ID] | 1452 | C | IPv4 Prefix with optional SR Algorithm | [This.ID] | 1453 | D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1454 | | for SR-MPLS | | 1455 | E | IPv4 Prefix with Local Interface ID | [This.ID] | 1456 | F | IPv4 Addresses for link endpoints as Local, | [This.ID] | 1457 | | Remote pair | | 1458 | G | IPv6 Prefix and Interface ID for link | [This.ID] | 1459 | | endpoints as Local, Remote pair for SR-MPLS | | 1460 | H | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1461 | | Remote pair for SR-MPLS | | 1462 | I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1463 | | for SRv6 | | 1464 | J | IPv6 Prefix and Interface ID for link | [This.ID] | 1465 | | endpoints as Local, Remote pair for SRv6 | | 1466 | K | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1467 | | Remote pair for SRv6 | | 1468 +-------+-----------------------------------------------+-----------+ 1470 Table 2: Initial IANA Registration 1472 12.1. Guidance for Designated Experts 1474 The Designated Expert (DE) is expected to ascertain the existence of 1475 suitable documentation (a specification) as described in [RFC8126] 1476 and to verify that the document is permanently and publicly 1477 available. The DE is also expected to check the clarity of purpose 1478 and use of the requested assignment. Additionally, the DE must 1479 verify that any request for one of these assignments has been made 1480 available for review and comment within the IETF: the DE will post 1481 the request to the SPRING Working Group mailing list (or a successor 1482 mailing list designated by the IESG). If the request comes from 1483 within the IETF, it should be documented in an Internet-Draft. 1484 Lastly, the DE must ensure that any other request for a code point 1485 does not conflict with work that is active or already published 1486 within the IETF. 1488 13. Acknowledgement 1490 The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger 1491 Geib, Rob Shakir, Cheng Li, Dhruv Dhody and Gyan Mishra for their 1492 review comments and suggestions. 1494 14. Contributors 1496 The following people have contributed to this document: 1498 Siva Sivabalan 1499 Cisco Systems 1500 Email: msiva@cisco.com 1502 Zafar Ali 1503 Cisco Systems 1504 Email: zali@cisco.com 1506 Jose Liste 1507 Cisco Systems 1508 Email: jliste@cisco.com 1510 Francois Clad 1511 Cisco Systems 1512 Email: fclad@cisco.com 1514 Kamran Raza 1515 Cisco Systems 1516 Email: skraza@cisco.com 1518 Mike Koldychev 1519 Cisco Systems 1520 Email: mkoldych@cisco.com 1522 Shraddha Hegde 1523 Juniper Networks 1524 Email: shraddha@juniper.net 1526 Steven Lin 1527 Google, Inc. 1528 Email: stevenlin@google.com 1530 Przemyslaw Krol 1531 Google, Inc. 1532 Email: pkrol@google.com 1534 Martin Horneffer 1535 Deutsche Telekom 1536 Email: martin.horneffer@telekom.de 1538 Dirk Steinberg 1539 Steinberg Consulting 1540 Email: dws@steinbergnet.net 1541 Bruno Decraene 1542 Orange Business Services 1543 Email: bruno.decraene@orange.com 1545 Stephane Litkowski 1546 Orange Business Services 1547 Email: stephane.litkowski@orange.com 1549 Luay Jalil 1550 Verizon 1551 Email: luay.jalil@verizon.com 1553 15. References 1555 15.1. Normative References 1557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1558 Requirement Levels", BCP 14, RFC 2119, 1559 DOI 10.17487/RFC2119, March 1997, 1560 . 1562 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1563 Writing an IANA Considerations Section in RFCs", BCP 26, 1564 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1565 . 1567 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1568 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1569 May 2017, . 1571 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1572 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1573 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1574 July 2018, . 1576 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1577 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1578 Routing with the MPLS Data Plane", RFC 8660, 1579 DOI 10.17487/RFC8660, December 2019, 1580 . 1582 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1583 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1584 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1585 . 1587 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1588 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1589 (SRv6) Network Programming", RFC 8986, 1590 DOI 10.17487/RFC8986, February 2021, 1591 . 1593 15.2. Informative References 1595 [I-D.ali-spring-sr-traffic-accounting] 1596 Filsfils, C., Talaulikar, K., Sivabalan, S., Horneffer, 1597 M., Raszuk, R., Litkowski, S., Voyer, D., and R. Morton, 1598 "Traffic Accounting in Segment Routing Networks", draft- 1599 ali-spring-sr-traffic-accounting-05 (work in progress), 1600 April 2021. 1602 [I-D.anand-spring-poi-sr] 1603 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1604 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1605 Integration in Segment Routing", draft-anand-spring-poi- 1606 sr-08 (work in progress), July 2019. 1608 [I-D.filsfils-spring-sr-policy-considerations] 1609 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1610 P. Mattes, "SR Policy Implementation and Deployment 1611 Considerations", draft-filsfils-spring-sr-policy- 1612 considerations-07 (work in progress), April 2021. 1614 [I-D.filsfils-spring-sr-traffic-counters] 1615 Filsfils, C., Ali, Z., Horneffer, M., Voyer, D., Durrani, 1616 M., and R. Raszuk, "Segment Routing Traffic Accounting 1617 Counters", draft-filsfils-spring-sr-traffic-counters-01 1618 (work in progress), April 2021. 1620 [I-D.ietf-idr-bgpls-segment-routing-epe] 1621 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1622 S., and J. Dong, "BGP-LS extensions for Segment Routing 1623 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1624 segment-routing-epe-19 (work in progress), May 2019. 1626 [I-D.ietf-idr-segment-routing-te-policy] 1627 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1628 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 1629 Routing Policies in BGP", draft-ietf-idr-segment-routing- 1630 te-policy-12 (work in progress), November 2020. 1632 [I-D.ietf-idr-te-lsp-distribution] 1633 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1634 H., and J. Tantsura, "Distribution of Traffic Engineering 1635 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1636 lsp-distribution-15 (work in progress), October 2020. 1638 [I-D.ietf-lsr-flex-algo] 1639 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1640 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1641 algo-16 (work in progress), April 2021. 1643 [I-D.ietf-pce-binding-label-sid] 1644 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 1645 and C. Li, "Carrying Binding Label/Segment Identifier in 1646 PCE-based Networks.", draft-ietf-pce-binding-label-sid-08 1647 (work in progress), April 2021. 1649 [I-D.ietf-pce-segment-routing-policy-cp] 1650 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 1651 Bidgoli, "PCEP extension to support Segment Routing Policy 1652 Candidate Paths", draft-ietf-pce-segment-routing-policy- 1653 cp-05 (work in progress), March 2021. 1655 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1656 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 1657 Decraene, B., and D. Voyer, "Topology Independent Fast 1658 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 1659 routing-ti-lfa-06 (work in progress), February 2021. 1661 [I-D.ietf-spring-sr-policy-yang] 1662 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 1663 Matsushima, S., and V. P. Beeram, "YANG Data Model for 1664 Segment Routing Policy", draft-ietf-spring-sr-policy- 1665 yang-01 (work in progress), April 2021. 1667 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1668 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1669 December 1990, . 1671 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1672 DOI 10.17487/RFC2328, April 1998, 1673 . 1675 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1676 (TE) Extensions to OSPF Version 2", RFC 3630, 1677 DOI 10.17487/RFC3630, September 2003, 1678 . 1680 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1681 "Multiprotocol Extensions for BGP-4", RFC 4760, 1682 DOI 10.17487/RFC4760, January 2007, 1683 . 1685 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1686 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1687 2008, . 1689 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1690 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1691 . 1693 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1694 Locator/ID Separation Protocol (LISP)", RFC 6830, 1695 DOI 10.17487/RFC6830, January 2013, 1696 . 1698 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1699 Previdi, "OSPF Traffic Engineering (TE) Metric 1700 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1701 . 1703 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1704 S. Ray, "North-Bound Distribution of Link-State and 1705 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1706 DOI 10.17487/RFC7752, March 2016, 1707 . 1709 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1710 Computation Element Communication Protocol (PCEP) 1711 Extensions for Stateful PCE", RFC 8231, 1712 DOI 10.17487/RFC8231, September 2017, 1713 . 1715 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1716 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1717 DOI 10.17487/RFC8476, December 2018, 1718 . 1720 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1721 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1722 DOI 10.17487/RFC8491, November 2018, 1723 . 1725 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1726 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1727 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1728 2019, . 1730 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1731 and J. Hardwick, "Path Computation Element Communication 1732 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1733 DOI 10.17487/RFC8664, December 2019, 1734 . 1736 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 1737 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 1738 Using the Border Gateway Protocol - Link State", RFC 8814, 1739 DOI 10.17487/RFC8814, August 2020, 1740 . 1742 Authors' Addresses 1744 Clarence Filsfils 1745 Cisco Systems, Inc. 1746 Pegasus Parc 1747 De kleetlaan 6a, DIEGEM BRABANT 1831 1748 BELGIUM 1750 Email: cfilsfil@cisco.com 1752 Ketan Talaulikar (editor) 1753 Cisco Systems, Inc. 1754 India 1756 Email: ketant@cisco.com 1758 Daniel Voyer 1759 Bell Canada 1760 671 de la gauchetiere W 1761 Montreal, Quebec H3B 2M8 1762 Canada 1764 Email: daniel.voyer@bell.ca 1766 Alex Bogdanov 1767 Google, Inc. 1769 Email: bogdanov@google.com 1770 Paul Mattes 1771 Microsoft 1772 One Microsoft Way 1773 Redmond, WA 98052-6399 1774 USA 1776 Email: pamattes@microsoft.com