idnits 2.17.1 draft-ietf-spring-segment-routing-policy-22.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 (March 22, 2022) is 759 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-08) 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 (-26) exists of draft-ietf-idr-segment-routing-te-policy-16 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-16 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-15 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-08 == 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) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 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 Updates: 8402 (if approved) Cisco Systems, Inc. 5 Intended status: Standards Track D. Voyer 6 Expires: September 23, 2022 Bell Canada 7 A. Bogdanov 8 British Telecom 9 P. Mattes 10 Microsoft 11 March 22, 2022 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-22 16 Abstract 18 Segment Routing (SR) allows a node to steer a packet flow along any 19 path. Intermediate per-path states are eliminated thanks to source 20 routing. SR Policy is an ordered list of segments (i.e., 21 instructions) that represent a source-routed policy. Packet flows 22 are steered into a SR Policy on a node where it is instantiated 23 called a headend node. The packets steered into an SR Policy carry 24 an ordered list of segments associated with that SR Policy. 26 This document updates RFC8402 as it details the concepts of SR Policy 27 and steering into an SR Policy. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 23, 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 67 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 5 68 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 6 69 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 7 70 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 7 71 2.6. Identification of a Candidate Path . . . . . . . . . . . 8 72 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8 73 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 9 74 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 9 75 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 10 76 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 10 77 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 11 78 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 12 80 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 17 82 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 17 83 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 17 84 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 19 85 5.3. Composite Candidate Path . . . . . . . . . . . . . . . . 19 86 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 20 88 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 20 89 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 21 90 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 22 91 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 22 92 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 22 93 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 23 94 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 23 95 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 23 96 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 24 97 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 26 98 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 26 99 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 28 100 8.8. Optional Steering Modes for BGP Destinations . . . . . . 28 101 9. Recovering from Network Failures . . . . . . . . . . . . . . 30 102 9.1. Leveraging TI-LFA local protection of the constituent IGP 103 segments . . . . . . . . . . . . . . . . . . . . . . . . 30 104 9.2. Using an SR Policy to locally protect a link . . . . . . 30 105 9.3. Using a Candidate Path for Path Protection . . . . . . . 31 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 107 11. Manageability Considerations . . . . . . . . . . . . . . . . 32 108 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 109 12.1. Guidance for Designated Experts . . . . . . . . . . . . 33 110 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34 111 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 112 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 113 15.1. Normative References . . . . . . . . . . . . . . . . . . 35 114 15.2. Informative References . . . . . . . . . . . . . . . . . 36 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 117 1. Introduction 119 Segment Routing (SR) [RFC8402] allows a node to steer a packet flow 120 along any path. The headend is a node where the instructions for 121 source routing (i.e., segments) are written into the packet and hence 122 becomes the starting node for a specific segment routing path. 123 Intermediate per-path states are eliminated thanks to source routing. 125 A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of 126 segments (i.e., instructions) that represent a source-routed policy. 127 The headend node is said to steer a flow into a SR Policy. The 128 packets steered into an SR Policy have an ordered list of segments 129 associated with that SR Policy written into them. [RFC8660] 130 describes the representation and processing of this ordered list of 131 segments as an MPLS label stack for SR-MPLS, while [RFC8754] and 132 [RFC8986] describe the same for Segment Routing over IPv6 (SRv6) with 133 the use of the Segment Routing Header (SRH). 135 [RFC8402] introduces the SR Policy construct and provides an overview 136 of how it is leveraged for Segment Routing use-cases. This document 137 updates [RFC8402] to specify detailed concepts of SR Policy and 138 steering packets into an SR Policy. It applies equally to the SR- 139 MPLS and SRv6 instantiations of segment routing. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. SR Policy 151 The general concept of SR Policy provides a framework that enables 152 the instantiation of an ordered list of segments on a node for 153 implementing a source routing policy for the steering of traffic for 154 a specific purpose (e.g. for a specific SLA) from that node. 156 The Segment Routing architecture [RFC8402] specifies that any 157 instruction can be bound to a segment. Thus, an SR Policy can be 158 built using any type of Segment Identifier (SID) including those 159 associated with topological or service instructions. 161 This section defines the key aspects and constituents of an SR 162 Policy. 164 2.1. Identification of an SR Policy 166 An SR Policy MUST be identified through the tuple . In the context of a specific headend, an SR policy MUST 168 be identified by the tuple. 170 The headend is the node where the policy is instantiated/implemented. 171 The headend is specified as an IPv4 or IPv6 address and MUST resolve 172 to a unique node in the SR domain [RFC8402]. 174 The endpoint indicates the destination of the policy. The endpoint 175 is specified as an IPv4 or IPv6 address and SHOULD resolve to a 176 unique node in the domain. In a specific case (refer to 177 Section 8.8.1), the endpoint can be the unspecified address (0.0.0.0 178 for IPv4, :: for IPv6) and in this case, the destination of the 179 policy is indicated by the last segment in the segment list(s). 181 The color is an unsigned non-zero 32-bit integer value that 182 associates the SR Policy with an intent or objective (e.g. low- 183 latency). 185 The endpoint and the color are used to automate the steering of 186 service or transport routes on SR Policies (refer to Section 8). 188 An implementation MAY allow the assignment of a symbolic name 189 comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) 190 to an SR Policy to serve as a user-friendly attribute for debugging 191 and troubleshooting purposes. Such symbolic names may identify an SR 192 Policy when the naming scheme ensures uniqueness. The SR Policy name 193 MAY also be signaled along with a candidate path of the SR Policy 194 (refer to Section 2.2). An SR Policy MAY have multiple names 195 associated with it in the scenario where the headend receives 196 different SR Policy names along with different candidate paths for 197 the same SR Policy via the same or different sources. 199 2.2. Candidate Path and Segment List 201 An SR Policy is associated with one or more candidate paths. A 202 candidate path is the unit for signaling of an SR Policy to a headend 203 via protocol extensions like Path Computation Element (PCE) 204 Communication Protocol (PCEP) [RFC8664] 205 [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy 206 [I-D.ietf-idr-segment-routing-te-policy]. 208 A Segment-List represents a specific source-routed path to send 209 traffic from the headend to the endpoint of the corresponding SR 210 policy. 212 A candidate path is either dynamic, explicit, or composite. 214 An explicit candidate path is expressed as a Segment-List or a set of 215 Segment-Lists. 217 A dynamic candidate path expresses an optimization objective and a 218 set of constraints for a specific data plane (i.e., SR-MPLS or SRv6). 219 The headend (potentially with the help of a PCE) computes a solution 220 Segment-List (or set of Segment-Lists) that solves the optimization 221 problem. 223 If a candidate path is associated with a set of Segment-Lists, each 224 Segment-List is associated with weight for weighted load balancing 225 (refer to Section 2.11 for details). The default weight is 1. 227 A composite candidate path acts as a container for grouping SR 228 Policies. The composite candidate path construct enables the 229 combination of SR Policies, each with explicit candidate paths and/or 230 dynamic candidate paths with potentially different optimization 231 objectives and constraints, for load-balanced steering of packet 232 flows over its constituent SR Policies. The following criteria apply 233 for inclusion of constituent SR Policies using a composite candidate 234 path under a parent SR Policy: 236 o the endpoints of the constituent SR Policies and the parent SR 237 Policy MUST be identical 239 o The colors of each of the constituent SR Policies and the parent 240 SR Policy MUST be different 242 o the constituent SR Policies MUST NOT use composite candidate paths 244 Each constituent SR Policy of a composite candidate path is 245 associated with weight for load-balancing purposes (refer to 246 Section 2.11 for details). The default weight is 1. 248 The Section 2.13 illustrates an information model for hierarchical 249 relationships between the SR Policy constructs described in this 250 section. 252 2.3. Protocol-Origin of a Candidate Path 254 A headend may be informed about a candidate path for an SR Policy 255 by various means including: via configuration, PCEP 256 [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP 257 [I-D.ietf-idr-segment-routing-te-policy]. 259 Protocol-Origin of a candidate path is an 8-bit value associated with 260 the mechanism or protocol used for signaling/provisioning the SR 261 Policy. It helps identify the protocol/mechanism that provides or 262 signals the candidate path and indicates its preference relative to 263 other protocols/mechanisms. 265 The head-end assigns different Protocol-Origin values to each source 266 of SR Policy information. The Protocol-Origin value is used as a 267 tie-breaker between candidate paths of equal preference, as described 268 in Section 2.9. The table below specifies the RECOMMENDED default 269 values of Protocol-Origin: 271 +-----------------+-------------------+ 272 | Protocol-Origin | Description | 273 +-----------------+-------------------+ 274 | 10 | PCEP | 275 | 20 | BGP SR Policy | 276 | 30 | Via Configuration | 277 +-----------------+-------------------+ 279 Table 1: Protocol-Origin default values 281 Note that the above order is to satisfy the need for having a clear 282 ordering and implementations MAY allow modifications of these default 283 values assigned to protocols on the headend along similar lines as a 284 routing administrative distance. Its application in the candidate 285 path selection is described in Section 2.9. 287 2.4. Originator of a Candidate Path 289 Originator identifies the node which provisioned or signaled the 290 candidate path on the headend. The originator is expressed in the 291 form of a 160-bit numerical value formed by the concatenation of the 292 fields of the tuple as 293 below: 295 o Autonomous System Number (ASN) : represented as a 4-byte number. 296 If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and 297 the high-order bits MUST be set to zero. 299 o Node Address : represented as a 128-bit value. IPv4 addresses 300 MUST be encoded in the lowest 32 bits, and the high-order bits 301 MUST be set to zero. 303 Its application in the candidate path selection is described in 304 Section 2.9. 306 When provisioning is via configuration, the ASN and node address MAY 307 be set to either the headend or the provisioning controller/node ASN 308 and address. The default value is 0 for both AS and node address. 310 When signaling is via PCEP, it is the IPv4 or IPv6 address of the PCE 311 and the AS number is expected to be set to 0 by default when not 312 available or known. 314 When signaling is via BGP SR Policy, the ASN and Node Address are 315 provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) 316 on the headend. 318 2.5. Discriminator of a Candidate Path 320 The Discriminator is a 32-bit value associated with a candidate path 321 that uniquely identifies it within the context of an SR Policy from a 322 specific Protocol-Origin as specified below: 324 o When provisioning is via configuration, this is an 325 implementation's configuration-model-specific unique identifier 326 for a candidate path. The default value is 0. 328 o When signaling is via PCEP, the method to uniquely signal an 329 individual candidate path along with its discriminator is 330 described in [I-D.ietf-pce-segment-routing-policy-cp]. The 331 default value is 0. 333 o When signaling is via BGP SR Policy, the BGP process receiving the 334 route provides the distinguisher (refer to Section 2.1 of 335 [I-D.ietf-idr-segment-routing-te-policy]) as the discriminator. 336 Note that the BGP best path selection is applied before the route 337 is supplied as a candidate path, so only a single candidate path 338 for a given SR Policy will be seen for a given discriminator. 340 Its application in the candidate path selection is described in 341 Section 2.9. 343 2.6. Identification of a Candidate Path 345 A candidate path is identified in the context of a single SR Policy. 347 A candidate path is not shared across SR Policies. 349 A candidate path is not identified by its Segment-List(s). 351 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 352 candidate path of SR Policy Pol2, then these two candidate paths 353 are independent, even if they happen to have the same Segment- 354 List. The Segment-List does not identify a candidate path. The 355 Segment-List is an attribute of a candidate path. 357 The identity of a candidate path MUST be uniquely established in the 358 context of an SR Policy to handle add, 359 delete or modify operations on them in an unambiguous manner 360 regardless of their source(s). 362 The tuple uniquely 363 identifies a candidate path. 365 Candidate paths MAY also be assigned or signaled with a symbolic name 366 comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) 367 to serve as a user-friendly attribute for debugging and 368 troubleshooting purposes. Such symbolic names MUST NOT be considered 369 as identifiers for a candidate path. The signaling of the candidate 370 path name via BGP and PCEP is described in 371 [I-D.ietf-pce-segment-routing-policy-cp] and 372 [I-D.ietf-idr-segment-routing-te-policy] respectively. 374 2.7. Preference of a Candidate Path 376 The preference of the candidate path is used to select the best 377 candidate path for an SR Policy. It is a 32-bit value where a higher 378 value indicates higher preference and the default preference value is 379 100. 381 It is RECOMMENDED that each candidate path of a given SR policy has a 382 different preference. 384 The signaling of the candidate path preference via BGP and PCEP is 385 described in [I-D.ietf-pce-segment-routing-policy-cp] and 386 [I-D.ietf-idr-segment-routing-te-policy] respectively. 388 2.8. Validity of a Candidate Path 390 A candidate path is usable when it is valid. The RECOMMEDED 391 candidate path validity criterion is the validity of at least one of 392 its constituent Segment-Lists. The validation rules are specified in 393 Section 5. 395 2.9. Active Candidate Path 397 A candidate path is selected when it is valid and it is determined to 398 be the best path of the SR Policy. The selected path is referred to 399 as the "active path" of the SR policy in this document. 401 Whenever a new path is learned or an active path is deleted, the 402 validity of an existing path changes or an existing path is changed, 403 the selection process MUST be re-executed. 405 The candidate path selection process operates primarily on the 406 candidate path Preference. A candidate path is selected when it is 407 valid and it has the highest preference value among all the valid 408 candidate paths of the SR Policy. 410 In the case of multiple valid candidate paths of the same preference, 411 the tie-breaking rules are evaluated on the identification tuple in 412 the following order until only one valid best path is selected: 414 1. Higher value of Protocol-Origin is selected. 416 2. If specified by configuration, prefer the existing installed 417 path. 419 3. Lower value of originator is selected. 421 4. Finally, the higher value of discriminator is selected. 423 The rules are framed with multiple protocols and sources in mind and 424 hence may not follow the logic of a single protocol (e.g. BGP best 425 path selection). The motivation behind these rules are as follows: 427 o The preference, being the primary criterion, allows an operator to 428 influence selection across paths thus allowing provisioning of 429 multiple path options, e.g., CP1 is preferred and if it becomes 430 invalid then fallback to CP2 and so on. Since preference works 431 across protocol sources, it also enables (where necessary) 432 selective override of the default Protocol-Origin preference, 433 e.g., to prefer a path signaled via BGP SR Policy over what is 434 configured. 436 o The Protocol-Origin allows an operator to set up a default 437 selection mechanism across protocol sources, e.g., to prefer 438 configured over paths signaled via BGP SR Policy or PCEP. 440 o The originator allows an operator to have multiple redundant 441 controllers and still maintain a deterministic behavior over which 442 of them are preferred even if they are providing the same 443 candidate paths for the same SR policies to the headend. 445 o The discriminator performs the final tiebreaking step to ensure a 446 deterministic outcome of selection regardless of the order in 447 which candidate paths are signaled across multiple transport 448 channels or sessions. 450 Section 4 of [I-D.filsfils-spring-sr-policy-considerations] provides 451 a set of examples to illustrate the active candidate path selection 452 rules. 454 2.10. Validity of an SR Policy 456 An SR Policy is valid when it has at least one valid candidate path. 458 2.11. Instantiation of an SR Policy in the Forwarding Plane 460 Generally, only valid SR policies are instantiated in the forwarding 461 plane. 463 Only the active candidate path MUST be used for forwarding traffic 464 that is being steered onto that policy except for certain scenarios 465 such as fast-reroute where a backup candidate path may be used as 466 described in Section 9.3. 468 If a set of Segment-Lists is associated with the active path of the 469 policy, then the steering is per-flow and weighted-ECMP (W-ECMP) 470 based according to the relative weight of each Segment-List. 472 The fraction of the flows associated with a given Segment-List is w/ 473 Sw, where w is the weight of the Segment-List and Sw is the sum of 474 the weights of the Segment-Lists of the selected path of the SR 475 Policy. 477 When a composite candidate path is active, the fraction of flows 478 steered into each constituent SR Policy is equal to the relative 479 weight of each constituent SR Policy. Further load balancing of 480 flows steered into a constituent SR Policy is performed based on the 481 weights of the Segment-List of the active candidate path of that 482 constituent SR Policy. 484 The accuracy of the weighted load-balancing depends on the platform 485 implementation. 487 2.12. Priority of an SR Policy 489 Upon topological change, many policies could be recomputed or 490 revalidated. An implementation MAY provide a per-policy priority 491 configuration. The operator may set this field to indicate the order 492 in which the policies should be re-computed. Such a priority is 493 represented by an integer in the range (0, 255) where the lowest 494 value is the highest priority. The default value of priority is 128. 496 An SR Policy may comprise multiple Candidate Paths received from the 497 same or different sources. A candidate path MAY be signaled with a 498 priority value. When an SR Policy has multiple candidate paths with 499 distinct signaled non-default priority values and the SR Policy 500 itself does not have a priority value configured, the SR Policy as a 501 whole takes the lowest value (i.e., the highest priority) amongst 502 these signaled priority values. 504 2.13. Summary 506 In summary, the information model is the following: 508 SR policy POL1 509 Candidate-path CP1 511 Preference 200 512 Priority 10 513 Segment List 1 , Weight W1 514 Segment List 2 , Weight W2 515 Candidate-path CP2 517 Preference 100 518 Priority 10 519 Segment List 3 , Weight W3 520 Segment List 4 , Weight W4 522 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 524 identified by a tuple 525 within the scope of POL1. CP1 is the active candidate path (it is 526 valid and has the highest preference). The two Segment-Lists of CP1 527 are installed as the forwarding instantiation of SR policy POL1. 528 Traffic steered on POL1 is flow-based hashed on Segment-List 529 with a ratio W1/(W1+W2). 531 The information model of SR Policy POL100 having a composite 532 candidate path is the following: 534 SR policy POL100 535 Candidate-path CP1 537 Preference 200 538 SR policy , Weight W1 539 SR policy , Weight W2 541 The constituent SR Policies POL1 and POL2 have an information model 542 as described at the start of this section. They are referenced only 543 by color in the composite candidate path since their headend and 544 endpoint are identical to the POL100. The valid Segment-Lists of the 545 active candidate path of POL1 and POL2 are installed in the 546 forwarding. Traffic steered on POL100 is flow-based hashed on POL1 547 with a proportion W1/(W1+W2). Within the POL1, the flow-based 548 hashing over its Segment-Lists are performed as described earlier in 549 this section. 551 3. Segment Routing Database 553 An SR Policy computation node (e.g. headend or controller) maintains 554 the Segment Routing Database (SR-DB). The SR-DB is a conceptual 555 database to illustrate the various pieces of information and their 556 sources that may help in SR Policy computation and validation. There 557 is no specific requirement for an implementation to create a new 558 database as such. 560 An SR headend leverages the SR-DB to validate explicit candidate 561 paths and compute dynamic candidate paths. 563 The information in the SR-DB may include: 565 o IGP information (topology, IGP metrics based on IS-IS [RFC1195] 566 and OSPF [RFC2328] [RFC5340]) 567 o Segment Routing information (such as Segment Routing Global Block, 568 Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Peering 569 SID, SRv6 SIDs) [RFC8402] [RFC8986] 570 o TE Link Attributes (such as TE metric, Shared Risk Link Groups, 571 attribute-flag, extended admin group) [RFC5305] [RFC3630] 572 [RFC5329]. 574 o Extended TE Link attributes (such as latency, loss) [RFC8570] 575 [RFC7471] 576 o Inter-AS Topology information [RFC9086]. 578 The attached domain topology may be learned via protocol/mechanisms 579 such as IGP, BGP-LS or NETCONF. 581 A non-attached (remote) domain topology may be learned via protocol/ 582 mechanisms such as BGP-LS or NETCONF. 584 In some use-cases, the SR-DB may only contain the attached domain 585 topology while in others, the SR-DB may contain the topology of 586 multiple domains and in this case, it is multi-domain capable. 588 The SR-DB may also contain the SR Policies instantiated in the 589 network. This can be collected via BGP-LS 590 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231], 591 [I-D.ietf-pce-segment-routing-policy-cp], and 592 [I-D.ietf-pce-binding-label-sid]. This information allows to build 593 an end-to-end policy on the basis of intermediate SR policies (see 594 Section 6 for further details). 596 The SR-DB may also contain the Maximum SID Depth (MSD) capability of 597 nodes in the topology. This can be collected via IS-IS [RFC8491], 598 OSPF [RFC8476], BGP-LS [RFC8814] or PCEP [RFC8664]. 600 The use of the SR-DB for path computation and for the validation of 601 optimization objective and constraints of paths is outside the scope 602 of this document. Some implementation aspects related to path 603 computation are covered in 604 [I-D.filsfils-spring-sr-policy-considerations]. 606 4. Segment Types 608 A Segment-List is an ordered set of segments represented as where S1 is the first segment. 611 Based on the desired dataplane, either the MPLS label stack or the 612 SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. 613 However, the Segment-List itself can be specified using different 614 segment-descriptor types and the following are currently defined: 616 Type A: SR-MPLS Label: 617 An MPLS label corresponding to any of the segment types defined 618 for SR-MPLS (as defined in [RFC8402] or other SR-MPLS 619 specifications) can be used. Additionally, special purpose 620 labels like explicit-null or in general any MPLS label MAY also 621 be used. E.g. this type can be used to specify a label 622 representation that maps to an optical transport path on a 623 packet transport node. 625 Type B: SRv6 SID: 626 An IPv6 address corresponding to any of the SID behaviors for 627 SRv6 (as defined in [RFC8986] or other SRv6 specifications) can 628 be used. Optionally, the SRv6 SID behavior (as defined in 629 [RFC8986] or other SRv6 specifications) and structure (as 630 defined in [RFC8986]) MAY also be provided for the headend to 631 perform validation of the SID when using it for building the 632 Segment List. 634 Type C: IPv4 Prefix with optional SR Algorithm: 635 In this case, the headend is required to resolve the specified 636 IPv4 Prefix Address to the SR-MPLS label corresponding to its 637 Prefix SID segment (as defined in [RFC8402]). The SR algorithm 638 (refer to Section 3.1.1 of [RFC8402]) to be used MAY also be 639 provided. 641 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 642 In this case, the headend is required to resolve the specified 643 IPv6 Global Prefix Address to the SR-MPLS label corresponding 644 to its Prefix SID segment (as defined in [RFC8402]). The SR 645 Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY 646 also be provided. 648 Type E: IPv4 Prefix with Local Interface ID: 649 This type allows identification of Adjacency SID or BGP Peer 650 Adjacency SID (as defined in [RFC8402]) SR-MPLS label for 651 point-to-point links including IP unnumbered links. The 652 headend is required to resolve the specified IPv4 Prefix 653 Address to the Node originating it and then use the Local 654 Interface ID to identify the point-to-point link whose 655 adjacency is being referred to. The Local Interface ID link 656 descriptor follows semantics as specified in [RFC5307]. This 657 type can also be used to indicate indirection into a layer 2 658 interface (i.e., without IP address) like a representation of 659 an optical transport path or a layer 2 Ethernet port or circuit 660 at the specified node. 662 Type F: IPv4 Addresses for link endpoints as Local, Remote pair: 663 This type allows identification of Adjacency SID or BGP Peer 664 Adjacency SID (as defined in [RFC8402]) SR-MPLS label for 665 links. The headend is required to resolve the specified IPv4 666 Local Address to the Node originating it and then use the IPv4 667 Remote Address to identify the link adjacency being referred 668 to. The Local and Remote Address pair link descriptors follow 669 semantics as specified in [RFC7752]. 671 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 672 Remote pair for SR-MPLS: 673 This type allows identification of Adjacency SID or BGP Peer 674 Adjacency SID (as defined in [RFC8402]) label for links 675 including those with only Link-Local IPv6 addresses. The 676 headend is required to resolve the specified IPv6 Prefix 677 Address to the Node originating it and then use the Local 678 Interface ID to identify the point-to-point link whose 679 adjacency is being referred to. For other than point-to-point 680 links, additionally the specific adjacency over the link needs 681 to be resolved using the Remote Prefix and Interface ID. The 682 Local and Remote pair of Prefix and Interface ID link 683 descriptor follows semantics as specified in [RFC7752]. This 684 type can also be used to indicate indirection into a layer 2 685 interface (i.e., without IP address) like a representation of 686 an optical transport path or a layer 2 Ethernet port or circuit 687 at the specified node. 689 Type H: IPv6 Addresses for link endpoints as Local, Remote pair for 690 SR-MPLS: 691 This type allows identification of Adjacency SID or BGP Peer 692 Adjacency SID (as defined in [RFC8402]) label for links with 693 Global IPv6 addresses. The headend is required to resolve the 694 specified Local IPv6 Address to the Node originating it and 695 then use the Remote IPv6 Address to identify the link adjacency 696 being referred to. The Local and Remote Address pair link 697 descriptors follow semantics as specified in [RFC7752]. 699 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: 700 The headend is required to resolve the specified IPv6 Global 701 Prefix Address to an SRv6 SID corresponding to a Prefix SID 702 segment (as defined in [RFC8402]), such as a SID associated 703 with the End behavior (as defined in [RFC8986]) of the node 704 which is originating the prefix. The SR Algorithm (refer to 705 Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as defined 706 in [RFC8986] or other SRv6 specifications) and structure (as 707 defined in [RFC8986]) MAY also be provided. 709 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 710 Remote pair for SRv6: 711 This type allows identification of an SRv6 SID corresponding to 712 an Adjacency SID or BGP Peer Adjacency SID (as defined in 713 [RFC8402]), such as a SID associated with the End.X behavior 714 (as defined in [RFC8986]) associated with link or adjacency 715 with only Link-Local IPv6 addresses. The headend is required 716 to resolve the specified IPv6 Prefix Address to the Node 717 originating it and then use the Local Interface ID to identify 718 the point-to-point link whose adjacency is being referred to. 720 For other than point-to-point links, additionally the specific 721 adjacency needs to be resolved using the Remote Prefix and 722 Interface ID. The Local and Remote pair of Prefix and 723 Interface ID link descriptor follows semantics as specified in 724 [RFC7752]. The SR Algorithm (refer to Section 3.1.1 of 725 [RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or 726 other SRv6 specifications) and structure (as defined in 727 [RFC8986]) MAY also be provided. 729 Type K: IPv6 Addresses for link endpoints as Local, Remote pair for 730 SRv6: 731 This type allows identification of an SRv6 SID corresponding to 732 an Adjacency SID or BGP Peer Adjacency SID (as defined in 733 [RFC8402]), such as a SID associated with the End.X behavior 734 (as defined in [RFC8986]) associated with link or adjacency 735 with Global IPv6 addresses. The headend is required to resolve 736 the specified Local IPv6 Address to the Node originating it and 737 then use the Remote IPv6 Address to identify the link adjacency 738 being referred to. The Local and Remote Address pair link 739 descriptors follow semantics as specified in [RFC7752]. The SR 740 Algorithm (refer to Section 3.1.1 of [RFC8402]), the SRv6 SID 741 behavior (as defined in [RFC8986] or other SRv6 specifications) 742 and structure (as defined in [RFC8986]) MAY also be provided. 744 When the algorithm is not specified for the SID types above which 745 optionally allow for it, the headend SHOULD use the Strict Shortest 746 Path algorithm if available and otherwise, it SHOULD use the default 747 Shortest Path algorithm. The specification of the algorithm enables 748 the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific 749 SIDs in SR Policy. 751 For SID types C-through-K, a SID value MAY also be optionally 752 provided to the headend for verification purposes. Section 5.1. 753 describes the resolution and verification of the SIDs and Segment 754 Lists on the headend. 756 When building the MPLS label stack or the IPv6 Segment list from the 757 Segment List, the node instantiating the policy MUST interpret the 758 set of Segments as follows: 760 o The first Segment represents the topmost label or the first IPv6 761 segment. It identifies the active segment the traffic will be 762 directed toward along the explicit SR path. 763 o The last Segment represents the bottommost label or the last IPv6 764 segment the traffic will be directed toward along the explicit SR 765 path. 767 4.1. Explicit Null 769 A Type A SID MAY be any MPLS label, including special purpose labels. 771 For example, assuming that the desired traffic-engineered path from a 772 headend 1 to an endpoint 4 can be expressed by the Segment-List 773 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 774 to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6 traffic 775 can be traffic-engineered from nodes 1 to 4 via the previously 776 described path using an SR Policy with Segment-List <16002, 16003, 777 16004, 2> where the MPLS label value of 2 represents the "IPv6 778 Explicit NULL Label". 780 The penultimate node before node 4 will pop 16004 and will forward 781 the frame on its directly connected interface to node 4. 783 The endpoint receives the traffic with the top label "2" which 784 indicates that the payload is an IPv6 packet. 786 When steering unlabeled IPv6 BGP destination traffic using an SR 787 policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit 788 Null Label Policy is processed as specified in 789 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.5. When an 790 "IPv6 Explicit NULL label" is not present as the bottom label, the 791 headend SHOULD automatically impose one. Refer to Section 8 for more 792 details. 794 5. Validity of a Candidate Path 796 5.1. Explicit Candidate Path 798 An explicit candidate path is associated with a Segment-List or a set 799 of Segment-Lists. 801 An explicit candidate path is provisioned by the operator directly or 802 via a controller. 804 The computation/logic that leads to the choice of the Segment-List is 805 external to the SR Policy headend. The SR Policy headend does not 806 compute the Segment-List. The SR Policy headend only confirms its 807 validity. 809 An explicit candidate path MAY consist of a single explicit Segment- 810 List containing only an implicit-null label to indicate pop-and- 811 forward behavior. The Binding SID (BSID) is popped and the traffic 812 is forwarded based on the inner label or an IP lookup in the case of 813 unlabeled IP packets. Such an explicit path can serve as a fallback 814 or path of last resort for traffic being steered into an SR Policy 815 using its BSID (refer to Section 8.3). 817 A Segment-List of an explicit candidate path MUST be declared invalid 818 when any of the following is true: 820 o It is empty. 821 o Its weight is 0. 822 o It comprises a mix of SR-MPLS and SRv6 segment types. 823 o The headend is unable to perform path resolution for the first SID 824 into one or more outgoing interface(s) and next-hop(s). 825 o The headend is unable to perform SID resolution for any non-first 826 SID of type C-through-K into an MPLS label or an SRv6 SID. 827 o The headend verification fails for any SID for which verification 828 has been explicitly requested. 830 "Unable to perform path resolution" means that the headend has no 831 path to the SID in its SR database. 833 SID verification is performed when the headend is explicitly 834 requested to verify SID(s) by the controller via the signaling 835 protocol used. Implementations MAY provide a local configuration 836 option to enable verification on a global or per policy or per 837 candidate path basis. 839 "Verification fails" for a SID means any of the following: 841 o The headend is unable to find the SID in its SR-DB 842 o The headend detects a mismatch between the SID value provided and 843 the SID value resolved by context provided for SIDs of type 844 C-through-K in its SR-DB. 845 o The headend is unable to perform SID resolution for any non-first 846 SID of type C-through-K into an MPLS label or an SRv6 SID. 848 In multi-domain deployments, it is expected that the headend may be 849 unable to verify the reachability of the SIDs in remote domains. 850 Types A or B MUST be used for the SIDs for which the reachability 851 cannot be verified. Note that the first SID MUST always be reachable 852 regardless of its type. 854 Additionally, a Segment-List MAY be declared invalid when both of the 855 conditions below are met : 857 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 858 advertised by the node specified as the endpoint of the 859 corresponding SR policy. 860 o Its last segment is not an Adjacency SID (including BGP Peer 861 Adjacency SID) of any of the links present on neighbor nodes and 862 that terminate on the node specified as the endpoint of the 863 corresponding SR policy. 865 An explicit candidate path is invalid as soon as it has no valid 866 Segment-List. 868 Additionally, an explicit candidate path MAY be declared invalid when 869 its constituent segment lists (valid or invalid) are using segment 870 types of different SR data planes. 872 5.2. Dynamic Candidate Path 874 A dynamic candidate path is specified as an optimization objective 875 and constraints. 877 The headend of the policy leverages its SR database to compute a 878 Segment-List ("solution Segment-List") that solves this optimization 879 problem for either the SR-MPLS or the SRv6 data-plane as specified. 881 The headend re-computes the solution Segment-List any time the inputs 882 to the problem change (e.g., topology changes). 884 When the local computation is not possible (e.g., a policy's tail-end 885 is outside the topology known to the headend) or not desired, the 886 headend may rely on an external entity. For example, a path 887 computation request may be sent to a PCE supporting PCEP extensions 888 specified in [RFC8664]. 890 If no solution is found to the optimization objective and 891 constraints, then the dynamic candidate path MUST be declared 892 invalid. 894 Section 3 of [I-D.filsfils-spring-sr-policy-considerations] discusses 895 some of the optimization objectives and constraints that may be 896 considered by a dynamic candidate path. It illustrates some of the 897 desirable properties of the computation of the solution Segment-List. 899 5.3. Composite Candidate Path 901 A composite candidate path is specified as a group of its constituent 902 SR Policies. 904 A composite candidate path is valid when it has at least one valid 905 constituent SR Policy. 907 6. Binding SID 909 The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 910 It provides scaling, network opacity, and service independence. 911 Section 6 of [I-D.filsfils-spring-sr-policy-considerations] 912 illustrates some of these benefits. This section describes the 913 association of BSID with an SR Policy. 915 6.1. BSID of a candidate path 917 Each candidate path MAY be defined with a BSID. 919 Candidate Paths of the same SR policy SHOULD have the same BSID. 921 Candidate Paths of different SR policies MUST NOT have the same BSID. 923 6.2. BSID of an SR Policy 925 The BSID of an SR Policy is the BSID of its active candidate path. 927 When the active candidate path has a specified BSID, the SR Policy 928 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 929 available (i.e., not associated with any other usage: e.g. label used 930 by some other MPLS forwarding entry, SRv6 SID used in some other 931 context, to another SID, to another SR Policy, outside the range of 932 SRv6 Locators). 934 In the case of SR-MPLS, SRv6 BSIDs (e.g. with the behavior End.BM 935 [RFC8986]) MAY be associated with the SR Policy in addition to the 936 MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g. with 937 different behaviors like End.B6.Encap and End.B6.Encap.Red [RFC8986]) 938 MAY be associated with the SR Policy. 940 Optionally, instead of only checking that the BSID of the active path 941 is available, a headend MAY check that it is available within the 942 given SID range i.e., Segment Routing Local Block (SRLB) as specified 943 in [RFC8402]. 945 When the specified BSID is not available (optionally is not in the 946 SRLB), an alert message MUST be generated via mechanisms like syslog. 948 In the cases (as described above) where SR Policy does not have a 949 BSID available, then the SR Policy MAY dynamically bind a BSID to 950 itself. Dynamically bound BSID SHOULD use an available SID outside 951 the SRLB. 953 Assuming that at time t the BSID of the SR Policy is B1, if at time 954 t+dt a different candidate path becomes active and this new active 955 path does not have a specified BSID or its BSID is specified but is 956 not available (e.g. it is in use by something else), then the SR 957 Policy MAY keep the previous BSID B1. 959 The association of an SR Policy with a BSID thus MAY change over the 960 life of the SR Policy (e.g., upon active path change). Hence, the 961 BSID SHOULD NOT be used as an identification of an SR Policy. 963 6.2.1. Frequent use-case : unspecified BSID 965 All the candidate paths of the same SR Policy can have an unspecified 966 BSID. 968 In such a case, a BSID MAY be dynamically bound to the SR Policy as 969 soon as the first valid candidate path is received. That BSID is 970 kept through the life of the SR Policy and across changes of active 971 candidate path. 973 6.2.2. Frequent use-case: all specified to the same BSID 975 All the paths of the SR Policy can have the same specified BSID. 977 6.2.3. Specified-BSID-only 979 An implementation MAY support the configuration of the Specified- 980 BSID-only restrictive behavior on the headend for all SR Policies or 981 individual SR Policies. Further, this restrictive behavior MAY also 982 be signaled on a per SR Policy basis to the headend. 984 When this restrictive behavior is enabled, if the candidate path has 985 an unspecified BSID or if the specified BSID is not available when 986 the candidate path becomes active then no BSID is bound to it and the 987 candidate path is considered invalid. An alert MUST be triggered for 988 this error via mechanisms like syslog. Other candidate paths MUST 989 then be evaluated for becoming the active candidate path. 991 6.3. Forwarding Plane 993 A valid SR Policy results in the installation of a BSID-keyed entry 994 in the forwarding plane with the action of steering the packets 995 matching this entry to the selected path of the SR Policy. 997 If the Specified-BSID-only restrictive behavior is enabled and the 998 BSID of the active path is not available (optionally not in the 999 SRLB), then the SR Policy does not install any entry indexed by a 1000 BSID in the forwarding plane. 1002 6.4. Non-SR usage of Binding SID 1004 An implementation MAY choose to associate a Binding SID with any type 1005 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 1006 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 1007 tunnel, etc). This enables the use of other non-SR enabled 1008 interfaces and tunnels as segments in an SR Policy Segment-List 1009 without the need of forming routing protocol adjacencies over them. 1011 The details of this kind of usage are beyond the scope of this 1012 document. A specific packet-optical integration use case is 1013 described in [I-D.anand-spring-poi-sr]. 1015 7. SR Policy State 1017 The SR Policy State is maintained on the headend to represent the 1018 state of the policy and its candidate paths. This is to provide an 1019 accurate representation of whether the SR Policy is being 1020 instantiated in the forwarding plane and which of its candidate paths 1021 and segment-list(s) are active. The SR Policy state MUST also 1022 reflect the reason when a policy and/or its candidate path is not 1023 active due to validation errors or not being preferred. The 1024 operational state information reported for SR Policies are specified 1025 in [I-D.ietf-spring-sr-policy-yang]. 1027 The SR Policy state can be reported by the headend node via BGP-LS 1028 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 1029 [I-D.ietf-pce-binding-label-sid]. 1031 SR Policy state on the headend also includes traffic accounting 1032 information for the flows being steered via the policies. The 1033 details of the SR Policy accounting are beyond the scope of this 1034 document. The aspects related to the SR traffic counters and their 1035 usage in the broader context of traffic accounting in an SR network 1036 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 1037 [I-D.ali-spring-sr-traffic-accounting] respectively. 1039 Implementations MAY support an administrative state to control 1040 locally provisioned policies via mechanisms like CLI or NETCONF. 1042 8. Steering into an SR Policy 1044 A headend can steer a packet flow into a valid SR Policy in various 1045 ways: 1047 o Incoming packets have an active SID matching a local BSID at the 1048 headend. 1050 o Per-destination Steering: incoming packets match a BGP/Service 1051 route which recurses on an SR policy. 1052 o Per-flow Steering: incoming packets match or recurse on a 1053 forwarding array of which some of the entries are SR Policies. 1054 o Policy-based Steering: incoming packets match a routing policy 1055 that directs them on an SR policy. 1057 8.1. Validity of an SR Policy 1059 An SR Policy is invalid when all its candidate paths are invalid as 1060 described in Section 5 and Section 2.10. 1062 By default, upon transitioning to the invalid state, 1064 o an SR Policy and its BSID are removed from the forwarding plane. 1065 o any steering of a service (Pseudowire (PW)), destination (BGP- 1066 VPN), flow or packet on the related SR policy is disabled and the 1067 related service, destination, flow, or packet is routed per the 1068 classic forwarding table (e.g. longest-match to the destination or 1069 the recursing next-hop). 1071 8.2. Drop upon invalid SR Policy 1073 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 1075 o an invalid SR Policy and its BSID is kept in the forwarding plane 1076 with an action to drop. 1077 o any steering of a service (PW), destination (BGP-VPN), flow or 1078 packet on the related SR policy is maintained with the action to 1079 drop all of this traffic. 1081 The drop-upon-invalid behavior has been deployed in use-cases where 1082 the operator wants some PW to only be transported on a path with 1083 specific constraints. When these constraints are no longer met, the 1084 operator wants the PW traffic to be dropped. Specifically, the 1085 operator does not want the PW to be routed according to the IGP 1086 shortest path to the PW endpoint. 1088 8.3. Incoming Active SID is a BSID 1090 Let us assume that headend H has a valid SR Policy P of Segment-List 1091 and BSID B. 1093 In the case of SR-MPLS, when H receives a packet K with label stack 1094 , H pops B and pushes and forwards the 1095 resulting packet according to SID S1. 1097 "Forwarding the resulting packet according to S1" means: If S1 is 1098 an Adj-SID or a PHP-enabled prefix SID advertised by a neighbor, H 1099 sends the resulting packet with label stack on 1100 the outgoing interface associated with S1; Else H sends the 1101 resulting packet with label stack along the 1102 path of S1. 1104 In the case of SRv6, the processing is similar and follows the SR 1105 Policy headend behaviors as specified in section 5 of [RFC8986]. 1107 H has steered the packet into the SR policy P. 1109 H did not have to classify the packet. The classification was done 1110 by a node upstream of H (e.g., the source of the packet or an 1111 intermediate ingress edge node of the SR domain) and the result of 1112 this classification was efficiently encoded in the packet header as a 1113 BSID. 1115 This is another key benefit of the segment routing in general and the 1116 binding SID in particular: the ability to encode a classification and 1117 the resulting steering in the packet header to better scale and 1118 simplify intermediate aggregation nodes. 1120 When Drop-Upon-Invalid (refer Section 8.2) is not in use, for an 1121 invalid SR Policy P, its BSID B is not in the forwarding plane and 1122 hence the packet K is dropped by H. 1124 8.4. Per-Destination Steering 1126 This section describes how a headend applies steering of flows 1127 corresponding to BGP routes over SR Policy using the Color Extended 1128 community [RFC9012]. 1130 In the case of SR-MPLS, let us assume that headend H: 1132 o learns a BGP route R/r via next-hop N, Color Extended community C 1133 and VPN label V. 1134 o has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1135 List and BSID B. 1136 o has a BGP policy that matches on the Color Extended community C 1137 and allows its 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 P of BSID B instead of via N. 1142 Indeed, H's local BGP policy and the received BGP route indicate that 1143 the headend should associate R/r with an SR Policy path to endpoint N 1144 with the SLA associated with color C. The headend, therefore, 1145 installs the BGP route on that policy. 1147 This can be implemented by using the BSID as a generalized next-hop 1148 and installing the BGP route on that generalized next-hop. 1150 When H receives a packet K with a destination matching R/r, H pushes 1151 the label stack and sends the resulting packet along 1152 the path to S1. 1154 Note that any SID associated with the BGP route is inserted after the 1155 Segment-List of the SR Policy (i.e., ). 1157 In the case of SRv6, the processing is similar and follows the SR 1158 Policy headend behaviors as specified in section 5 of [RFC8986]. 1160 The same behavior applies to any type of service route: any AFI/SAFI 1161 of BGP [RFC4760] or LISP [RFC6830] for both IPv4/IPv6. 1163 In a BGP multi-path scenario, the BGP route MAY be resolved over a 1164 mix of paths that include those that are steered over SR Policies and 1165 others resolved via the normal BGP nexthop resolution. 1166 Implementations MAY provide options to prefer one type over the other 1167 or other forms of local policy to determine the paths that are 1168 selected. 1170 8.4.1. Multiple Colors 1172 When a BGP route has multiple Color Extended communities each with a 1173 valid SR Policy, the BGP process installs the route on the SR Policy 1174 giving preference to the Color Extended community with the highest 1175 numerical value. 1177 Let us assume that headend H: 1179 o learns a BGP route R/r via next-hop N, Color Extended communities 1180 C1 and C2. 1181 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1182 List and BSID B1. 1183 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1184 List and BSID B2. 1185 o has a BGP policy that matches the Color Extended communities C1 1186 and C2 and allows their usage as SLA steering information 1188 If all these conditions are met, H installs R/r in RIB/FIB with next- 1189 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1191 When the SR Policy with a specific color is not instantiated or in 1192 the down/inactive state, the SR Policy with the next highest 1193 numerical value of color is considered. 1195 8.5. Recursion on an on-demand dynamic BSID 1197 In the previous section, it was assumed that H had a pre-established 1198 "explicit" SR Policy (color C, endpoint N). 1200 In this section, independent of the a-priori existence of any 1201 explicit candidate path of the SR policy (C, N), it is to be noted 1202 that the BGP process at headend node H triggers the instantiation of 1203 a dynamic candidate path for the SR policy (C, N) as soon as: 1205 o the BGP process learns of a route R/r via N and with Color 1206 Extended community C. 1207 o a local policy at node H authorizes the on-demand SR Policy path 1208 instantiation and maps the color to a dynamic SR Policy path 1209 optimization template. 1211 8.5.1. Multiple Colors 1213 When a BGP route R/r via N has multiple Color Extended communities Ci 1214 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1215 request (color Ci, endpoint N) is triggered for each color Ci. The 1216 SR Policy that is used for steering is then determined as described 1217 in Section 8.4.1. 1219 8.6. Per-Flow Steering 1221 This section provides an example of how a headend might apply per- 1222 flow steering in practice. 1224 Let us assume that headend H: 1226 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1227 List and BSID B1. 1228 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1229 List and BSID B2. 1230 o is configured to instantiate an array of paths to N where the 1231 entry 0 is the IGP path to N, color C1 is the first entry and 1232 color C2 is the second entry. The index into the array is called 1233 a Forwarding Class (FC). The index can have values 0 to 7, 1234 especially when derived from the MPLS TC bits [RFC5462]. 1235 o is configured to match flows in its ingress interfaces (upon any 1236 field such as Ethernet destination/source/VLAN/TOS or IP 1237 destination/source/DSCP or transport ports etc.) and color them 1238 with an internal per-packet forwarding-class variable (0, 1 or 2 1239 in this example). 1241 If all these conditions are met, H installs in RIB/FIB: 1243 o N via recursion on an array A (instead of the immediate outgoing 1244 link associated with the IGP shortest-path to N). 1245 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1246 path to N. 1247 o Entry A(1) set to SR Policy P1 of BSID=B1. 1248 o Entry A(2) set to SR Policy P2 of BSID=B2. 1250 H receives three packets K, K1, and K2 on its incoming interface. 1251 These three packets either longest-match on N or more likely on a 1252 BGP/service route which recurses on N. H colors these 3 packets 1253 respectively with forwarding-class 0, 1, and 2. 1255 As a result, for SR-MPLS: 1257 o H forwards K along the shortest path to N (i.e., pushes the 1258 Prefix-SID of N). 1259 o H pushes on packet K1 and forwards the resulting 1260 frame along the shortest path to S1. 1261 o H pushes on packet K2 and forwards the resulting 1262 frame along the shortest path to S4. 1264 For SRv6, the processing is similar and the segment lists of the 1265 individual SR Policies P1 and P2 are enforced for packets K1 and K2 1266 using the SR Policy headend behaviors as specified in section 5 of 1267 [RFC8986]. 1269 If the local configuration does not specify any explicit forwarding 1270 information for an entry of the array, then this entry is filled with 1271 the same information as entry 0 (i.e., the IGP shortest path). 1273 If the SR Policy mapped to an entry of the array becomes invalid, 1274 then this entry is filled with the same information as entry 0. When 1275 all the array entries have the same information as entry0, the 1276 forwarding entry for N is updated to bypass the array and point 1277 directly to its outgoing interface and next-hop. 1279 The array index values (e.g. 0, 1, and 2) and the notion of 1280 forwarding-class are implementation-specific and only meant to 1281 describe the desired behavior. The same can be realized by other 1282 mechanisms. 1284 This realizes per-flow steering: different flows bound to the same 1285 BGP endpoint are steered on different IGP or SR Policy paths. 1287 A headend MAY support options to apply per-flow steering only for 1288 traffic matching specific prefixes (e.g. specific IGP or BGP 1289 prefixes). 1291 8.7. Policy-based Routing 1293 Finally, headend H MAY be configured with a local routing policy 1294 which overrides any BGP/IGP path and steers a specified packet on an 1295 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1296 automatic routing of IGP prefixes over SR Policies intended for such 1297 purpose. 1299 8.8. Optional Steering Modes for BGP Destinations 1301 8.8.1. Color-Only BGP Destination Steering 1303 In the previous section, it is seen that the steering on an SR Policy 1304 is governed by the matching of the BGP route's next-hop N and the 1305 authorized Color Extended community C with an SR Policy defined by 1306 the tuple (N, C). 1308 This is the most likely form of BGP destination steering and the one 1309 recommended for most use-cases. 1311 This section defines an alternative steering mechanism based only on 1312 the Color Extended community. 1314 Three types of steering modes are defined. 1316 For the default, Type 0, the BGP destination is steered as follows: 1318 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1320 endpoint address and C is a color; 1321 Steer into SR Policy (N, C); 1322 ELSE; 1323 Steer on the IGP path to the next-hop N. 1325 This is the classic case described in this document previously and 1326 what is recommended in most scenarios. 1328 For Type 1, the BGP destination is steered as follows: 1330 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1332 endpoint address and C is a color; 1333 Steer into SR Policy (N, C); 1334 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1335 same address-family of N; 1336 Steer into SR Policy (null endpoint, C); 1337 ELSE IF there is any valid SR Policy 1338 (any address-family null endpoint, C); 1339 Steer into SR Policy (any null endpoint, C); 1340 ELSE; 1341 Steer on the IGP path to the next-hop N. 1343 For Type 2, the BGP destination is steered as follows: 1345 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1346 endpoint address and C is a color; 1347 Steer into SR Policy (N, C); 1348 ELSE IF there is a valid SR Policy (null endpoint, C) 1349 of the same address-family of N; 1350 Steer into SR Policy (null endpoint, C); 1351 ELSE IF there is any valid SR Policy 1352 (any address-family null endpoint, C); 1353 Steer into SR Policy (any null endpoint, C); 1354 ELSE IF there is any valid SR Policy (any endpoint, C) 1355 of the same address-family of N; 1356 Steer into SR Policy (any endpoint, C); 1357 ELSE IF there is any valid SR Policy 1358 (any address-family endpoint, C); 1359 Steer into SR Policy (any address-family endpoint, C); 1360 ELSE; 1361 Steer on the IGP path to the next-hop N. 1363 The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set 1364 to the 0 value). 1366 Please refer to [I-D.ietf-idr-segment-routing-te-policy] for the 1367 updates to the BGP Color Extended community for the implementation of 1368 these mechanisms. 1370 8.8.2. Multiple Colors and CO flags 1372 The steering preference is first based on the highest Color Extended 1373 community value and then Color-Only steering type for the color. 1374 Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1>C2 The steering 1375 preference order is: 1377 o SR policy (NH, C1). 1378 o SR policy (null, C1). 1379 o SR policy (NH, C2). 1380 o SR policy (null, C2). 1381 o IGP to NH. 1383 8.8.3. Drop upon Invalid 1385 This document defined earlier that when all the following conditions 1386 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1387 BSID B instead of via N. 1389 o H learns a BGP route R/r via next-hop N, Color Extended community 1390 C. 1391 o H has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1392 List and BSID B. 1393 o H has a BGP policy that matches the Color Extended community C and 1394 allows its usage as SLA steering information. 1396 This behavior is extended by noting that the BGP policy may require 1397 the BGP steering to always stay on the SR policy whatever its 1398 validity. 1400 This is the "drop upon invalid" option described in Section 8.2 1401 applied to BGP-based steering. 1403 9. Recovering from Network Failures 1405 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1407 In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) 1408 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1409 protection technique for IGP SIDs. The backup path is computed on a 1410 per IGP SID basis along the post-convergence path. 1412 In a network that has deployed TI-LFA, an SR Policy built on the 1413 basis of TI-LFA protected IGP segments leverages the local protection 1414 of the constituent segments. Since TI-LFA protection is based on IGP 1415 computation, there are cases where the path used during the fast- 1416 reroute time window may not meet the exact constraints of the SR 1417 Policy. 1419 In a network that has deployed TI-LFA, an SR Policy instantiated only 1420 with non-protected Adj SIDs does not benefit from any local 1421 protection. 1423 9.2. Using an SR Policy to locally protect a link 1424 1----2-----6----7 1425 | | | | 1426 4----3-----9----8 1428 Figure 1: Local protection using SR Policy 1430 An SR Policy can be instantiated at node 2 to protect link 2to6. A 1431 typical explicit Segment-List would be <3, 9, 6>. 1433 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1434 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are 1435 part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 1436 cannot benefit from TI-LFA automated local protection. The SR Policy 1437 with Segment-List <3, 9, 6> on node 2 can be locally configured to be 1438 a fast-reroute backup path for the link 2to6. 1440 9.3. Using a Candidate Path for Path Protection 1442 An SR Policy allows for multiple candidate paths, of which at any 1443 point in time there is a single active candidate path that is 1444 provisioned in the forwarding plane and used for traffic steering. 1445 However, another (lower preference) candidate path MAY be designated 1446 as the backup for a specific or all (active) candidate path(s). The 1447 following options are possible: 1449 o A pair of disjoint candidate paths are provisioned with one of 1450 them as primary and the other is identified as its backup. 1451 o A specific candidate path is provisioned as the backup for any 1452 (active) candidate path. 1453 o The headend picks the next (lower) preference valid candidate path 1454 as the backup for the active candidate path. 1456 The headend MAY compute a-priori and validate such backup candidate 1457 paths as well as provision them into the forwarding plane as a backup 1458 for the active path. The backup candidate path may be dynamically 1459 computed or explicitly provisioned in such a way that they provide 1460 the most appropriate alternative for the active candidate path. A 1461 fast re-route mechanism MAY then be used to trigger sub 50msec 1462 switchover from the active to the backup candidate path in the 1463 forwarding plane. Mechanisms like Bidirectional Forwarding Detection 1464 (BFD) MAY be used for fast detection of such failures. 1466 10. Security Considerations 1468 This document specifies in detail the SR Policy construct introduced 1469 in [RFC8402] and its instantiation on a router supporting SR along 1470 with descriptions of mechanisms for steering of traffic flows over 1471 it. Therefore, the security considerations of [RFC8402] apply. The 1472 security consideration related to SR-MPLS [RFC8660] and SRv6 1473 [RFC8754] [RFC8986] also apply. 1475 The endpoint of the SR Policy, other than in the case of a null 1476 endpoint, uniquely identifies the tail-end node of the segment routed 1477 path. If an address that is used as an endpoint for an SR Policy is 1478 advertised by more than one node due to a misconfiguration or 1479 spoofing and the same is advertised via an IGP, the traffic steered 1480 over the SR Policy may end up getting diverted to an undesired node 1481 resulting is misrouting. Mechanisms for detection of duplicate 1482 prefix advertisement can be used to identify and correct such 1483 scenarios. The details of these mechanisms are outside the scope of 1484 this document. 1486 The Section 8 specifies mechanism for steering of traffic flows 1487 corresponding to BGP routes over SR Policies matching the color value 1488 signaled via the BGP Color Extended Community attached with the BGP 1489 routes. Misconfiguration or error in setting of the Color Extended 1490 Community with the BGP routes can result in forwarding of packets for 1491 those routes along undesired paths. 1493 In Section 2.1 and Section 2.6, the document mentions that a symbolic 1494 name MAY be signaled along with a candidate path for the SR Policy 1495 and for the SR Policy Candidate Path respectively. While the value 1496 of symbolic names for display clarity is indisputable, as with any 1497 unrestricted freeform text received from external parties, there can 1498 be no absolute assurance that the information the text purports to 1499 show is accurate or even truthful. For this reason, users of 1500 implementations that display such information would be well-advised 1501 not to rely on it without question and to use the specific 1502 identifiers of the SR Policy and SR Policy Candidate Path for 1503 validation. Furthermore, implementations that display such 1504 information might wish to display it in such a fashion as to 1505 differentiate it from known-good information. (Such display 1506 conventions are inherently implementation-specific; one example might 1507 be use of a distinguished text color or style for information that 1508 should be treated with caution.) 1510 This document does not define any new protocol extensions and does 1511 not introduce any further security considerations. 1513 11. Manageability Considerations 1515 This document specifies in detail the SR Policy construct introduced 1516 in [RFC8402] and its instantiation on a router supporting SR along 1517 with descriptions of mechanisms for steering of traffic flows over 1518 it. Therefore, the manageability considerations of [RFC8402] apply. 1520 A YANG model for the configuration and operation of SR Policy has 1521 been defined in [I-D.ietf-spring-sr-policy-yang]. 1523 12. IANA Considerations 1525 The document requests IANA to create a new sub-registry called 1526 "Segment Types" under the top-level "Segment Routing" registry that 1527 was created by [RFC8986]. This sub-registry maintains the alphabetic 1528 identifiers for the segment types (as specified in section 4) that 1529 may be used within a Segment List of an SR Policy. The alphabetical 1530 identifiers run from A to Z and may be extended on exhaustion with 1531 the identifiers AA to AZ, BA to BZ, and so on through till ZZ. This 1532 sub-registry would follow the Specification Required allocation 1533 policy as specified in [RFC8126]. 1535 The initial registrations for this sub-registry are as follows: 1537 +-------+-----------------------------------------------+-----------+ 1538 | Value | Description | Reference | 1539 +-------+-----------------------------------------------+-----------+ 1540 | A | SR-MPLS Label | [This.ID] | 1541 | B | SRv6 SID | [This.ID] | 1542 | C | IPv4 Prefix with optional SR Algorithm | [This.ID] | 1543 | D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1544 | | for SR-MPLS | | 1545 | E | IPv4 Prefix with Local Interface ID | [This.ID] | 1546 | F | IPv4 Addresses for link endpoints as Local, | [This.ID] | 1547 | | Remote pair | | 1548 | G | IPv6 Prefix and Interface ID for link | [This.ID] | 1549 | | endpoints as Local, Remote pair for SR-MPLS | | 1550 | H | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1551 | | Remote pair for SR-MPLS | | 1552 | I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1553 | | for SRv6 | | 1554 | J | IPv6 Prefix and Interface ID for link | [This.ID] | 1555 | | endpoints as Local, Remote pair for SRv6 | | 1556 | K | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1557 | | Remote pair for SRv6 | | 1558 +-------+-----------------------------------------------+-----------+ 1560 Table 2: Initial IANA Registration 1562 12.1. Guidance for Designated Experts 1564 The Designated Expert (DE) is expected to ascertain the existence of 1565 suitable documentation (a specification) as described in [RFC8126] 1566 and to verify that the document is permanently and publicly 1567 available. The DE is also expected to check the clarity of purpose 1568 and use of the requested assignment. Additionally, the DE must 1569 verify that any request for one of these assignments has been made 1570 available for review and comment within the IETF: the DE will post 1571 the request to the SPRING Working Group mailing list (or a successor 1572 mailing list designated by the IESG). If the request comes from 1573 within the IETF, it should be documented in an Internet-Draft. 1574 Lastly, the DE must ensure that any other request for a code point 1575 does not conflict with work that is active or already published 1576 within the IETF. 1578 13. Acknowledgement 1580 The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger 1581 Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha, 1582 Jim Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi, 1583 Matthew Bocci, Cullen Jennings, and Carlos Bernardos for their review 1584 comments and suggestions. 1586 14. Contributors 1588 The following people have contributed to this document: 1590 Siva Sivabalan 1591 Cisco Systems 1592 Email: msiva@cisco.com 1594 Zafar Ali 1595 Cisco Systems 1596 Email: zali@cisco.com 1598 Jose Liste 1599 Cisco Systems 1600 Email: jliste@cisco.com 1602 Francois Clad 1603 Cisco Systems 1604 Email: fclad@cisco.com 1606 Kamran Raza 1607 Cisco Systems 1608 Email: skraza@cisco.com 1610 Mike Koldychev 1611 Cisco Systems 1612 Email: mkoldych@cisco.com 1613 Shraddha Hegde 1614 Juniper Networks 1615 Email: shraddha@juniper.net 1617 Steven Lin 1618 Google, Inc. 1619 Email: stevenlin@google.com 1621 Przemyslaw Krol 1622 Google, Inc. 1623 Email: pkrol@google.com 1625 Martin Horneffer 1626 Deutsche Telekom 1627 Email: martin.horneffer@telekom.de 1629 Dirk Steinberg 1630 Steinberg Consulting 1631 Email: dws@steinbergnet.net 1633 Bruno Decraene 1634 Orange Business Services 1635 Email: bruno.decraene@orange.com 1637 Stephane Litkowski 1638 Orange Business Services 1639 Email: stephane.litkowski@orange.com 1641 Luay Jalil 1642 Verizon 1643 Email: luay.jalil@verizon.com 1645 15. References 1647 15.1. Normative References 1649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1650 Requirement Levels", BCP 14, RFC 2119, 1651 DOI 10.17487/RFC2119, March 1997, 1652 . 1654 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1655 S. Ray, "North-Bound Distribution of Link-State and 1656 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1657 DOI 10.17487/RFC7752, March 2016, 1658 . 1660 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1661 Writing an IANA Considerations Section in RFCs", BCP 26, 1662 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1663 . 1665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1667 May 2017, . 1669 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1670 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1671 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1672 July 2018, . 1674 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1675 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1676 Routing with the MPLS Data Plane", RFC 8660, 1677 DOI 10.17487/RFC8660, December 2019, 1678 . 1680 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1681 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1682 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1683 . 1685 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1686 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1687 (SRv6) Network Programming", RFC 8986, 1688 DOI 10.17487/RFC8986, February 2021, 1689 . 1691 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 1692 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 1693 DOI 10.17487/RFC9012, April 2021, 1694 . 1696 15.2. Informative References 1698 [I-D.ali-spring-sr-traffic-accounting] 1699 Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., 1700 Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D., and 1701 R. Morton, "Traffic Accounting in Segment Routing 1702 Networks", draft-ali-spring-sr-traffic-accounting-06 (work 1703 in progress), November 2021. 1705 [I-D.anand-spring-poi-sr] 1706 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1707 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1708 Integration in Segment Routing", draft-anand-spring-poi- 1709 sr-08 (work in progress), July 2019. 1711 [I-D.filsfils-spring-sr-policy-considerations] 1712 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1713 P. Mattes, "SR Policy Implementation and Deployment 1714 Considerations", draft-filsfils-spring-sr-policy- 1715 considerations-08 (work in progress), October 2021. 1717 [I-D.filsfils-spring-sr-traffic-counters] 1718 Filsfils, C., Ali, Z., Horneffer, M., Voyer, D., Durrani, 1719 M., and R. Raszuk, "Segment Routing Traffic Accounting 1720 Counters", draft-filsfils-spring-sr-traffic-counters-02 1721 (work in progress), October 2021. 1723 [I-D.ietf-idr-segment-routing-te-policy] 1724 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1725 Jain, D., and S. Lin, "Advertising Segment Routing 1726 Policies in BGP", draft-ietf-idr-segment-routing-te- 1727 policy-16 (work in progress), March 2022. 1729 [I-D.ietf-idr-te-lsp-distribution] 1730 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1731 H., and J. Tantsura, "Distribution of Traffic Engineering 1732 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1733 lsp-distribution-16 (work in progress), October 2021. 1735 [I-D.ietf-lsr-flex-algo] 1736 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1737 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1738 algo-18 (work in progress), October 2021. 1740 [I-D.ietf-pce-binding-label-sid] 1741 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 1742 and C. L. (editor), "Carrying Binding Label/Segment 1743 Identifier (SID) in PCE-based Networks.", draft-ietf-pce- 1744 binding-label-sid-15 (work in progress), March 2022. 1746 [I-D.ietf-pce-segment-routing-policy-cp] 1747 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 1748 Bidgoli, "PCEP extension to support Segment Routing Policy 1749 Candidate Paths", draft-ietf-pce-segment-routing-policy- 1750 cp-06 (work in progress), October 2021. 1752 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1753 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 1754 Decraene, B., and D. Voyer, "Topology Independent Fast 1755 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 1756 routing-ti-lfa-08 (work in progress), January 2022. 1758 [I-D.ietf-spring-sr-policy-yang] 1759 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 1760 Matsushima, S., and V. P. Beeram, "YANG Data Model for 1761 Segment Routing Policy", draft-ietf-spring-sr-policy- 1762 yang-01 (work in progress), April 2021. 1764 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 1765 RFC 20, DOI 10.17487/RFC0020, October 1969, 1766 . 1768 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1769 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1770 December 1990, . 1772 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1773 DOI 10.17487/RFC2328, April 1998, 1774 . 1776 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1777 (TE) Extensions to OSPF Version 2", RFC 3630, 1778 DOI 10.17487/RFC3630, September 2003, 1779 . 1781 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1782 "Multiprotocol Extensions for BGP-4", RFC 4760, 1783 DOI 10.17487/RFC4760, January 2007, 1784 . 1786 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1787 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1788 2008, . 1790 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1791 in Support of Generalized Multi-Protocol Label Switching 1792 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1793 . 1795 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 1796 "Traffic Engineering Extensions to OSPF Version 3", 1797 RFC 5329, DOI 10.17487/RFC5329, September 2008, 1798 . 1800 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1801 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1802 . 1804 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1805 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1806 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1807 2009, . 1809 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1810 Locator/ID Separation Protocol (LISP)", RFC 6830, 1811 DOI 10.17487/RFC6830, January 2013, 1812 . 1814 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1815 Previdi, "OSPF Traffic Engineering (TE) Metric 1816 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1817 . 1819 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1820 Computation Element Communication Protocol (PCEP) 1821 Extensions for Stateful PCE", RFC 8231, 1822 DOI 10.17487/RFC8231, September 2017, 1823 . 1825 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1826 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1827 DOI 10.17487/RFC8476, December 2018, 1828 . 1830 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1831 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1832 DOI 10.17487/RFC8491, November 2018, 1833 . 1835 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1836 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1837 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1838 2019, . 1840 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1841 and J. Hardwick, "Path Computation Element Communication 1842 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1843 DOI 10.17487/RFC8664, December 2019, 1844 . 1846 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 1847 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 1848 Using the Border Gateway Protocol - Link State", RFC 8814, 1849 DOI 10.17487/RFC8814, August 2020, 1850 . 1852 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 1853 Ray, S., and J. Dong, "Border Gateway Protocol - Link 1854 State (BGP-LS) Extensions for Segment Routing BGP Egress 1855 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 1856 2021, . 1858 Authors' Addresses 1860 Clarence Filsfils 1861 Cisco Systems, Inc. 1862 Pegasus Parc 1863 De kleetlaan 6a, DIEGEM BRABANT 1831 1864 BELGIUM 1866 Email: cfilsfil@cisco.com 1868 Ketan Talaulikar (editor) 1869 Cisco Systems, Inc. 1870 India 1872 Email: ketant.ietf@gmail.com 1874 Daniel Voyer 1875 Bell Canada 1876 671 de la gauchetiere W 1877 Montreal, Quebec H3B 2M8 1878 Canada 1880 Email: daniel.voyer@bell.ca 1882 Alex Bogdanov 1883 British Telecom 1885 Email: alex.bogdanov@bt.com 1886 Paul Mattes 1887 Microsoft 1888 One Microsoft Way 1889 Redmond, WA 98052-6399 1890 USA 1892 Email: pamattes@microsoft.com