idnits 2.17.1 draft-ietf-spring-segment-routing-policy-10.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 (April 27, 2021) is 1094 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-11 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-14 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-14 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-08 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-06 -- 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 (~~), 9 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: October 29, 2021 D. Voyer 6 Bell Canada 7 A. Bogdanov 8 Google, Inc. 9 P. Mattes 10 Microsoft 11 April 27, 2021 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-10 16 Abstract 18 Segment Routing (SR) allows a headend node to steer a packet flow 19 along any path. Intermediate per-flow states are eliminated thanks 20 to source routing. The headend node steers a flow into an SR Policy. 21 The header of a packet steered in an SR Policy is augmented with an 22 ordered list of segments associated with that SR Policy. This 23 document details the concepts of SR Policy and steering into an SR 24 Policy. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 29, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 64 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 5 65 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 6 66 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 6 67 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 7 68 2.6. Identification of a Candidate Path . . . . . . . . . . . 7 69 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8 70 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 8 71 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 8 72 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 9 73 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 9 74 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 10 75 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 11 77 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 16 79 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 16 80 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 16 81 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 18 82 5.3. Composite Candidate Path . . . . . . . . . . . . . . . . 18 83 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 19 85 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 19 86 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 20 87 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 20 88 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 21 89 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 21 90 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 22 91 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 22 92 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 22 93 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 23 94 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 24 95 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 25 96 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 26 97 8.8. Optional Steering Modes for BGP Destinations . . . . . . 26 98 9. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 9.1. Leveraging TI-LFA local protection of the constituent IGP 100 segments . . . . . . . . . . . . . . . . . . . . . . . . 28 101 9.2. Using an SR Policy to locally protect a link . . . . . . 29 102 9.3. Using a Candidate Path for Path Protection . . . . . . . 29 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 105 11.1. Guidance for Designated Experts . . . . . . . . . . . . 31 106 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 107 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 108 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 109 14.1. Normative References . . . . . . . . . . . . . . . . . . 33 110 14.2. Informative References . . . . . . . . . . . . . . . . . 33 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 113 1. Introduction 115 Segment Routing (SR) allows a headend node to steer a packet flow 116 along any path. Intermediate per-flow states are eliminated thanks 117 to source routing [RFC8402]. 119 The headend node is said to steer a flow into a Segment Routing 120 Policy (SR Policy). 122 The header of a packet steered into an SR Policy is augmented with an 123 ordered list of segments associated with that SR Policy. 125 This document details the concepts of SR Policy and steering packets 126 into an SR Policy. These apply equally to the MPLS and SRv6 127 instantiations of segment routing. 129 For reading simplicity, the illustrations are provided for the MPLS 130 instantiations. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 2. SR Policy 142 An SR Policy is a framework that enables the instantiation of an 143 ordered list of segments on a node for implementing a source routing 144 policy with a specific intent for traffic steering from that node. 146 The Segment Routing architecture [RFC8402] specifies that any 147 instruction can be bound to a segment. Thus, an SR Policy can be 148 built using any type of Segment Identifier (SID) including those 149 associated with topological or service instructions. 151 This section defines the key aspects and constituents of an SR 152 Policy. 154 2.1. Identification of an SR Policy 156 An SR Policy is identified through the tuple . In the context of a specific headend, one may identify an 158 SR policy by the tuple. 160 The headend is the node where the policy is instantiated/implemented. 161 The headend is specified as an IPv4 or IPv6 address and is expected 162 to be unique in the domain. 164 The endpoint indicates the destination of the policy. The endpoint 165 is specified as an IPv4 or IPv6 address and is expected to be unique 166 in the domain. In a specific case (refer to Section 8.8.1), the 167 endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6). 169 The color is a 32-bit numerical value that associates the SR Policy 170 with an intent (e.g. low-latency). 172 The endpoint and the color are used to automate the steering of 173 service or transport routes on SR Policies (refer to Section 8). 175 An implementation MAY allow assignment of a symbolic name comprising 176 of printable ASCII characters to an SR Policy to serve as a user- 177 friendly attribute for debugging and troubleshooting purposes. Such 178 symbolic names may identify an SR Policy when the naming scheme 179 ensures uniqueness. The SR Policy name may also be signaled along 180 with a candidate path of the SR Policy (refer to Section 2.2). An SR 181 Policy may have multiple names associated with it in the scenario 182 where the headend receives different SR Policy names along with 183 candidate paths for the same SR Policy. 185 2.2. Candidate Path and Segment List 187 An SR Policy is associated with one or more candidate paths. A 188 candidate path is the unit for signaling of an SR Policy to a headend 189 via protocols like Path Computation Element (PCE) Communication 190 Protocol (PCEP) [RFC8664] or BGP SR Policy 191 [I-D.ietf-idr-segment-routing-te-policy]. 193 A Segment-List represents a specific source-routed path to send 194 traffic from the headend to the endpoint of the corresponding SR 195 policy. 197 A candidate path is either dynamic, explicit, or composite. 199 An explicit candidate path is expressed as a Segment-List or a set of 200 Segment-Lists. 202 A dynamic candidate path expresses an optimization objective and a 203 set of constraints. The headend (potentially with the help of a PCE) 204 computes the solution Segment-List (or set of Segment-Lists) that 205 solves the optimization problem. 207 If a candidate path is associated with a set of Segment-Lists, each 208 Segment-List is associated with weight for weighted load balancing 209 (refer to Section 2.11 for details). The default weight is 1. 211 A composite candidate path acts as a container for grouping SR 212 Policies. The composite candidate path construct enables the 213 combination of SR Policies, each with explicit candidate paths and/or 214 dynamic candidate paths with potentially different optimization 215 objectives and constraints, for load-balanced steering of packet 216 flows over its constituent SR Policies. The following criteria apply 217 for inclusion of constituent SR Policies using a composite candidate 218 path under a parent SR Policy: 220 o the endpoints of the constituent SR Policies and the parent SR 221 Policy MUST be identical 223 o The colors of each of the constituent SR Policies and the parent 224 SR Policy MUST be different 226 o the constituent SR Policies MUST NOT use composite candidate paths 228 Each constituent SR Policy of a composite candidate path is 229 associated with weight for load-balancing purposes (refer to 230 Section 2.11 for details). The default weight is 1. 232 2.3. Protocol-Origin of a Candidate Path 234 A headend may be informed about a candidate path for an SR Policy 235 by various means including: via configuration, PCEP 236 [RFC8664] or BGP [I-D.ietf-idr-segment-routing-te-policy]. 238 Protocol-Origin of a candidate path is an 8-bit value which 239 identifies the component or protocol that originates or signals the 240 candidate path. 242 The head-end assigns different Protocol-Origin Priority values to 243 each Protocol-Origin. The Protocol-Origin Priority is used as a tie- 244 breaker between candidate-paths of equal preference, as described in 245 Section 2.9. The table below specifies the RECOMMENDED default 246 values of Protocol-Origin Priority: 248 +-------+-------------------+ 249 | Value | Protocol-Origin | 250 +-------+-------------------+ 251 | 10 | PCEP | 252 | 20 | BGP SR Policy | 253 | 30 | Via Configuration | 254 +-------+-------------------+ 256 Table 1: Protocol-Origin Priority default values 258 Implementations MAY allow modifications of these default values 259 assigned to protocols on the headend along similar lines as a routing 260 administrative distance. Its application in the candidate path 261 selection is described in Section 2.9. 263 2.4. Originator of a Candidate Path 265 Originator identifies the node which provisioned or signaled the 266 candidate path on the headend. The originator is expressed in the 267 form of a 160-bit numerical value formed by the concatenation of the 268 fields of the tuple as below: 270 o ASN : represented as a 4-byte number. 272 o Node Address : represented as a 128-bit value. IPv4 addresses are 273 encoded in the lowest 32 bits. 275 Its application in the candidate path selection is described in 276 Section 2.9. 278 When Protocol-Origin is Via Configuration, the ASN and node address 279 MAY be set to either the headend or the provisioning controller/node 280 ASN and address. The default value is 0 for both AS and node 281 address. 283 When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the 284 PCE and the AS number SHOULD be set to 0 by default when not 285 available or known. 287 When Protocol-Origin is BGP SR Policy, the ASN and Node Address are 288 provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) 289 on the headend. 291 2.5. Discriminator of a Candidate Path 293 The Discriminator is a 32-bit value associated with a candidate path 294 that uniquely identifies it within the context of an SR Policy from a 295 specific Protocol-Origin as specified below: 297 When Protocol-Origin is Via Configuration, this is an 298 implementation's configuration model-specific unique identifier for a 299 candidate path. The default value is 0. 301 When PCEP is the Protocol-Origin, the method to uniquely identify 302 signalled path will be specified in a future PCEP document. The 303 default value is 0. 305 When BGP SR Policy is the Protocol-Origin, it is the distinguisher 306 (refer to Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]). 308 Its application in the candidate path selection is described in 309 Section 2.9. 311 2.6. Identification of a Candidate Path 313 A candidate path is identified in the context of a single SR Policy. 315 A candidate path is not shared across SR Policies. 317 A candidate path is not identified by its Segment-List(s). 319 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 320 candidate path of SR Policy Pol2, then these two candidate paths 321 are independent, even if they happen to have the same Segment- 322 List. The Segment-List does not identify a candidate path. The 323 Segment-List is an attribute of a candidate path. 325 The identity of a candidate path MUST be uniquely established in the 326 context of an SR Policy to handle add, 327 delete or modify operations on them in an unambiguous manner 328 regardless of their source(s). 330 The tuple uniquely 331 identifies a candidate path. 333 Candidate paths MAY also be assigned or signaled with a symbolic name 334 comprising printable ASCII characters to serve as a user-friendly 335 attribute for debugging and troubleshooting purposes. Such symbolic 336 names MUST NOT be considered as identifiers for a candidate path. 338 2.7. Preference of a Candidate Path 340 The preference of the candidate path is used to select the best 341 candidate path for an SR Policy. The default preference is 100. 343 It is RECOMMENDED that each candidate path of a given SR policy has a 344 different preference. 346 2.8. Validity of a Candidate Path 348 A candidate path is usable when it valid. A common path validity 349 criterion is the reachability of its constituent SIDs. The 350 validation rules are specified in Section 5. 352 2.9. Active Candidate Path 354 A candidate path is selected when it is valid and it is determined to 355 be the best path of the SR Policy. The selected path is referred to 356 as the "active path" of the SR policy in this document. 358 Whenever a new path is learned or an active path is deleted, the 359 validity of an existing path changes or an existing path is changed, 360 the selection process MUST be re-executed. 362 The candidate path selection process operates on the candidate path 363 Preference. A candidate path is selected when it is valid and it has 364 the highest preference value among all the candidate paths of the SR 365 Policy. 367 In the case of multiple valid candidate paths of the same preference, 368 the tie-breaking rules are evaluated on the identification tuple in 369 the following order until only one valid best path is selected: 371 1. Higher value of Protocol-Origin Priority is selected. 373 2. If specified by configuration, prefer the existing installed 374 path. 376 3. Lower value of originator is selected. 378 4. Finally, the higher value of discriminator is selected. 380 The rules are framed with multiple protocols and sources in mind and 381 hence may not follow the logic of a single protocol (e.g. BGP best 382 path selection). The motivation behind these rules are as follows: 384 o The Protocol-Origin allows an operator to set up a default 385 selection mechanism across protocol sources, e.g., to prefer 386 configured over paths signaled via BGP SR Policy or PCEP. 388 o The preference, being the first tiebreaker, allows an operator to 389 influence selection across paths thus allowing provisioning of 390 multiple path options, e.g., CP1 is preferred and if it becomes 391 invalid then fallback to CP2 and so on. Since preference works 392 across protocol sources, it also enables (where necessary) 393 selective override of the default protocol-origin preference, 394 e.g., to prefer a path signaled via BGP SR Policy over what is 395 configured. 397 o The originator allows an operator to have multiple redundant 398 controllers and still maintain a deterministic behavior over which 399 of them are preferred even if they are providing the same 400 candidate paths for the same SR policies to the headend. 402 o The discriminator performs the final tiebreaking step to ensure a 403 deterministic outcome of selection regardless of the order in 404 which candidate paths are signaled across multiple transport 405 channels or sessions. 407 [I-D.filsfils-spring-sr-policy-considerations] provides a set of 408 examples to illustrate the active candidate path selection rules. 410 2.10. Validity of an SR Policy 412 An SR Policy is valid when it has at least one valid candidate path. 414 2.11. Instantiation of an SR Policy in the Forwarding Plane 416 A valid SR Policy is instantiated in the forwarding plane. 418 Only the active candidate path SHOULD be used for forwarding traffic 419 that is being steered onto that policy. 421 If a set of Segment-Lists is associated with the active path of the 422 policy, then the steering is per-flow and weighted-ECMP (W-ECMP) 423 based according to the relative weight of each Segment-List. 425 The fraction of the flows associated with a given Segment-List is w/ 426 Sw, where w is the weight of the Segment-List and Sw is the sum of 427 the weights of the Segment-Lists of the selected path of the SR 428 Policy. 430 When a composite candidate path is active, the fraction of flows 431 steered into each constituent SR Policy is equal to the relative 432 weight of each constituent SR Policy. Further load balancing of 433 flows steered into a constituent SR Policy is performed based on the 434 weights of the Segment-List of the active candidate path of that 435 constituent SR Policy. 437 The accuracy of the weighted load-balancing depends on the platform 438 implementation. 440 2.12. Priority of an SR Policy 442 Upon topological change, many policies could be recomputed or 443 revalidated. An implementation MAY provide a per-policy priority 444 configuration. The operator MAY set this field to indicate the order 445 in which the policies should be re-computed. Such a priority is 446 represented by an integer in the range (0, 255) where the lowest 447 value is the highest priority. The default value of priority is 128. 449 An SR Policy may comprise multiple Candidate Paths received from the 450 same or different sources. A candidate path MAY be signaled with a 451 priority value. When an SR Policy has multiple candidate paths with 452 distinct signaled non-default priority values, the SR Policy as a 453 whole takes the lowest value (i.e. the highest priority) amongst 454 these signaled priority values. 456 2.13. Summary 458 In summary, the information model is the following: 460 SR policy POL1 461 Candidate-path CP1 463 Preference 200 464 Weight W1, SID-List1 465 Weight W2, SID-List2 466 Candidate-path CP2 468 Preference 100 469 Weight W3, SID-List3 470 Weight W4, SID-List4 472 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 474 identified by a tuple . 475 CP1 is the active candidate path (it is valid and has the highest 476 preference). The two Segment-Lists of CP1 are installed as the 477 forwarding instantiation of SR policy POL1. Traffic steered on POL1 478 is flow-based hashed on Segment-List with a ratio 479 W1/(W1+W2). 481 The information model of SR Policy POL100 having a composite 482 candidate path is the following: 484 SR policy POL100 485 Candidate-path CP1 487 Preference 200 488 Weight W1, SR policy 489 Weight W2, SR policy 491 The constituent SR Policies POL1 and POL2 have an information model 492 as described at the start of this section. They are referenced only 493 by color in the composite candidate path since their headend and 494 endpoint are identical to the POL100. The valid Segment-Lists of the 495 active candidate path of POL1 and POL2 are installed in the 496 forwarding. Traffic steered on POL100 is flow-based hashed on POL1 497 with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing 498 over its Segment-Lists are performed as described earlier in this 499 section. 501 3. Segment Routing Database 503 An SR headend maintains the Segment Routing Database (SR-DB). The 504 SR-DB is a conceptual database to illustrate the various pieces of 505 information and their sources that may help in SR Policy computation 506 and validation. There is no specific requirement for an 507 implementation to create a new database as such. 509 An SR headend leverages the SR-DB to validate explicit candidate 510 paths and compute dynamic candidate paths. 512 The information in the SR-DB MAY include: 514 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 515 OSPF [RFC2328] [RFC5340]) 516 o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj- 517 SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402] [RFC8986] 518 o TE Link Attributes (such as TE metric, SRLG, attribute-flag, 519 extended admin group) [RFC5305] [RFC3630]. 521 o Extended TE Link attributes (such as latency, loss) [RFC8570] 522 [RFC7471] 523 o Inter-AS Topology information 524 [I-D.ietf-idr-bgpls-segment-routing-epe]. 526 The attached domain topology MAY be learned via IGP, BGP-LS or 527 NETCONF. 529 A non-attached (remote) domain topology MAY be learned via BGP-LS or 530 NETCONF. 532 In some use-cases, the SR-DB may only contain the attached domain 533 topology while in others, the SR-DB may contain the topology of 534 multiple domains and in this case, it is multi-domain capable. 536 The SR-DB MAY also contain the SR Policies instantiated in the 537 network. This can be collected via BGP-LS 538 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 539 [I-D.ietf-pce-binding-label-sid]. This information allows to build 540 an end-to-end policy on the basis of intermediate SR policies (see 541 Section 6 for further details). 543 The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of 544 nodes in the topology. This can be collected via ISIS [RFC8491], 545 OSPF [RFC8476], BGP-LS [RFC8814] or PCEP [RFC8664]. 547 The use of the SR-DB for computation and validation of SR Policies is 548 outside the scope of this document. Some implementation aspects 549 related to this are covered in 550 [I-D.filsfils-spring-sr-policy-considerations]. 552 4. Segment Types 554 A Segment-List is an ordered set of segments represented as where S1 is the first segment. 557 Based on the desired dataplane, either the MPLS label stack or the 558 SRv6 SRH is built from the Segment-List. However, the Segment-List 559 itself can be specified using different segment-descriptor types and 560 the following are currently defined: 562 Type A: SR-MPLS Label: 563 An MPLS label corresponding to any of the segment types defined 564 for SR-MPLS (as defined in [RFC8402] or other SR-MPLS 565 specifications) can be used. Additionally, reserved labels 566 like explicit-null or in general any MPLS label may also be 567 used. E.g. this type can be used to specify a label 568 representation that maps to an optical transport path on a 569 packet transport node. This type does not require the headend 570 to perform SID resolution. 572 Type B: SRv6 SID: 573 An IPv6 address corresponding to any of the SID behaviors for 574 SRv6 (as defined in [RFC8986] or other SRv6 specifications) can 575 be used. This type does not require the headend to perform SID 576 resolution. Optionally, the SRv6 SID behavior (as defined in 577 [RFC8986] or other SRv6 specifications) and structure (as 578 defined in [RFC8986]) MAY also be provided for the headend to 579 perform validation of the SID when using it for building the 580 Segment List. 582 Type C: IPv4 Prefix with optional SR Algorithm: 583 The headend is required to resolve the specified IPv4 Prefix 584 Address to the SR-MPLS label corresponding to a Prefix SID 585 segment (as defined in [RFC8402]). The SR algorithm (refer to 586 Section 3.1.1 of [RFC8402]) to be used MAY also be provided. 588 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 589 In this case, the headend is required to resolve the specified 590 IPv6 Global Prefix Address to the SR-MPLS label corresponding 591 to its Prefix SID segment (as defined in [RFC8402]). The SR 592 Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY 593 also be provided. 595 Type E: IPv4 Prefix with Local Interface ID: 596 This type allows identification of Adjacency SID or BGP Peer 597 Adjacency SID (as defined in [RFC8402]) label for point-to- 598 point links including IP unnumbered links. The headend is 599 required to resolve the specified IPv4 Prefix Address to the 600 Node originating it and then use the Local Interface ID to 601 identify the point-to-point link whose adjacency is being 602 referred to. The Local Interface ID link descriptor follows 603 semantics as specified in [RFC7752]. This type can also be 604 used to indicate indirection into a layer 2 interface (i.e. 605 without IP address) like a representation of an optical 606 transport path or a layer 2 Ethernet port or circuit at the 607 specified node. 609 Type F: IPv4 Addresses for link endpoints as Local, Remote pair: 610 This type allows identification of Adjacency SID or BGP Peer 611 Adjacency SID (as defined in [RFC8402]) label for links. The 612 headend is required to resolve the specified IPv4 Local Address 613 to the Node originating it and then use the IPv4 Remote Address 614 to identify the link adjacency being referred to. The Local 615 and Remote Address pair link descriptors follow semantics as 616 specified in [RFC7752]. 618 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 619 Remote pair for SR-MPLS: 620 This type allows identification of Adjacency SID or BGP Peer 621 Adjacency SID (as defined in [RFC8402]) label for links 622 including those with only Link-Local IPv6 addresses. The 623 headend is required to resolve the specified IPv6 Prefix 624 Address to the Node originating it and then use the Local 625 Interface ID to identify the point-to-point link whose 626 adjacency is being referred to. For other than point-to-point 627 links, additionally the specific adjacency over the link needs 628 to be resolved using the Remote Prefix and Interface ID. The 629 Local and Remote pair of Prefix and Interface ID link 630 descriptor follows semantics as specified in [RFC7752]. This 631 type can also be used to indicate indirection into a layer 2 632 interface (i.e. without IP address) like a representation of an 633 optical transport path or a layer 2 Ethernet port or circuit at 634 the specified node. 636 Type H: IPv6 Addresses for link endpoints as Local, Remote pair for 637 SR-MPLS: 638 This type allows identification of Adjacency SID or BGP Peer 639 Adjacency SID (as defined in [RFC8402]) label for links with 640 Global IPv6 addresses. The headend is required to resolve the 641 specified Local IPv6 Address to the Node originating it and 642 then use the Remote IPv6 Address to identify the link adjacency 643 being referred to. The Local and Remote Address pair link 644 descriptors follow semantics as specified in [RFC7752]. 646 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: 647 The headend is required to resolve the specified IPv6 Global 648 Prefix Address to an SRv6 SID corresponding to a Prefix SID 649 segment (as defined in [RFC8402]), such as a SID associated 650 with the End behavior (as defined in [RFC8986]), of the node 651 which is originating the prefix. The SR Algorithm (refer to 652 Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as defined 653 in [RFC8986] or other SRv6 specifications) and structure (as 654 defined in [RFC8986]) MAY also be provided. 656 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 657 Remote pair for SRv6: 658 This type allows identification of an SRv6 SID corresponding to 659 an Adjacency SID or BGP Peer Adjacency SID (as defined in 660 [RFC8402]), such as a SID associated with the End.X behavior 661 (as defined in [RFC8986]), associated with link or adjacency 662 with only Link-Local IPv6 addresses. The headend is required 663 to resolve the specified IPv6 Prefix Address to the Node 664 originating it and then use the Local Interface ID to identify 665 the point-to-point link whose adjacency is being referred to. 667 For other than point-to-point links, additionally the specific 668 adjacency needs to be resolved using the Remote Prefix and 669 Interface ID. The Local and Remote pair of Prefix and 670 Interface ID link descriptor follows semantics as specified in 671 [RFC7752]. The SR Algorithm (refer to Section 3.1.1 of 672 [RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or 673 other SRv6 specifications) and structure (as defined in 674 [RFC8986]) MAY also be provided. 676 Type K: IPv6 Addresses for link endpoints as Local, Remote pair for 677 SRv6: 678 This type allows identification of an SRv6 SID corresponding to 679 an Adjacency SID or BGP Peer Adjacency SID (as defined in 680 [RFC8402]), such as a SID associated with the End.X behavior 681 (as defined in [RFC8986]), associated with link or adjacency 682 with Global IPv6 addresses. The headend is required to resolve 683 the specified Local IPv6 Address to the Node originating it and 684 then use the Remote IPv6 Address to identify the link adjacency 685 being referred to. The Local and Remote Address pair link 686 descriptors follow semantics as specified in [RFC7752]. The SR 687 Algorithm (refer to Section 3.1.1 of [RFC8402]), the SRv6 SID 688 behavior (as defined in [RFC8986] or other SRv6 specifications) 689 and structure (as defined in [RFC8986]) MAY also be provided. 691 When the algorithm is not specified for the SID types above which 692 optionally allow for it, the headend SHOULD use the Strict Shortest 693 Path algorithm if available; otherwise, it SHOULD use the default 694 Shortest Path algorithm. The specification of the algorithm enables 695 the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific 696 SIDs in SR Policy. 698 For SID types C-through-K, a SID value may also be optionally 699 provided to the headend for verification purposes. Section 5.1. 700 describes the resolution and verification of the SIDs and Segment 701 Lists on the headend. 703 When building the MPLS label stack or the IPv6 Segment list from the 704 Segment List, the node instantiating the policy MUST interpret the 705 set of Segments as follows: 707 o The first Segment represents the topmost label or the first IPv6 708 segment. It identifies the active segment the traffic will be 709 directed toward along the explicit SR path. 710 o The last Segment represents the bottommost label or the last IPv6 711 segment the traffic will be directed toward along the explicit SR 712 path. 714 4.1. Explicit Null 716 A Type A SID may be any MPLS label, including reserved labels. 718 For example, assuming that the desired traffic-engineered path from a 719 headend 1 to an endpoint 4 can be expressed by the Segment-List 720 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 721 to the IPv4 Prefix SIDs bound to node 2, 3, and 4, then IPv6 traffic 722 can be traffic-engineered from nodes 1 to 4 via the previously 723 described path using an SR Policy with Segment-List <16002, 16003, 724 16004, 2> where the MPLS label value of 2 represents the "IPv6 725 Explicit NULL Label". 727 The penultimate node before node 4 will pop 16004 and will forward 728 the frame on its directly connected interface to node 4. 730 The endpoint receives the traffic with the top label "2" which 731 indicates that the payload is an IPv6 packet. 733 When steering unlabeled IPv6 BGP destination traffic using an SR 734 policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit 735 Null Label Policy is processed as specified in 736 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 737 "IPv6 Explicit NULL label" is not present as the bottom label, the 738 headend SHOULD automatically impose one. Refer to Section 8 for more 739 details. 741 5. Validity of a Candidate Path 743 5.1. Explicit Candidate Path 745 An explicit candidate path is associated with a Segment-List or a set 746 of Segment-Lists. 748 An explicit candidate path is provisioned by the operator directly or 749 via a controller. 751 The computation/logic that leads to the choice of the Segment-List is 752 external to the SR Policy headend. The SR Policy headend does not 753 compute the Segment-List. The SR Policy headend only confirms its 754 validity. 756 An explicit candidate path MAY consist of a single explicit Segment- 757 List containing only an implicit-null label to indicate pop-and- 758 forward behavior. The BSID is popped and the traffic is forwarded 759 based on the inner label or an IP lookup in the case of unlabeled IP 760 packets. Such an explicit path can serve as a fallback or path of 761 last resort for traffic being steered into an SR Policy using its 762 BSID (refer to Section 8.3). 764 A Segment-List of an explicit candidate path MUST be declared invalid 765 when: 767 o It is empty. 768 o Its weight is 0. 769 o The headend is unable to perform path resolution for the first SID 770 into one or more outgoing interface(s) and next-hop(s). 771 o The headend is unable to perform SID resolution for any non-first 772 SID of type C-through-K into an MPLS label or an SRv6 SID. 773 o The headend verification fails for any SID for which verification 774 has been explicitly requested. 776 "Unable to perform path resolution" means that the headend has no 777 path to the SID in its SR database. 779 SID verification is performed when the headend is explicitly 780 requested to verify SID(s) by the controller via the signaling 781 protocol used. Implementations MAY provide a local configuration 782 option to enable verification on a global or per policy or per 783 candidate path basis. 785 "Verification fails" for a SID means any of the following: 787 o The headend is unable to find the SID in its SR DB 788 o The headend detects a mis-match between the SID value and its 789 context provided for SIDs of type C-through-L in its SR DB. 790 o The headend is unable to perform SID resolution for any non-first 791 SID of type C-through-K into an MPLS label or an SRv6 SID. 793 In multi-domain deployments, it is expected that the headend be 794 unable to verify the reachability of the SIDs in remote domains. 795 Types A or B MUST be used for the SIDs for which the reachability 796 cannot be verified. Note that the first SID MUST always be reachable 797 regardless of its type. 799 Additionally, a Segment-List MAY be declared invalid when: 801 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 802 advertised by the node specified as the endpoint of the 803 corresponding SR policy. 804 o Its last segment is not an Adjacency SID (including BGP Peer 805 Adjacency SID) of any of the links present on neighbor nodes and 806 that terminate on the node specified as the endpoint of the 807 corresponding SR policy. 809 An explicit candidate path is invalid as soon as it has no valid 810 Segment-List. 812 5.2. Dynamic Candidate Path 814 A dynamic candidate path is specified as an optimization objective 815 and constraints. 817 The headend of the policy leverages its SR database to compute a 818 Segment-List ("solution Segment-List") that solves this optimization 819 problem. 821 The headend re-computes the solution Segment-List any time the inputs 822 to the problem change (e.g., topology changes). 824 When the local computation is not possible (e.g., a policy's tail-end 825 is outside the topology known to the headend) or not desired, the 826 headend MAY send path computation request to a PCE supporting PCEP 827 extension specified in [RFC8664]. 829 If no solution is found to the optimization objective and 830 constraints, then the dynamic candidate path MUST be declared 831 invalid. 833 [I-D.filsfils-spring-sr-policy-considerations] discusses some of the 834 optimization objectives and constraints that may be considered by a 835 dynamic candidate path. It illustrates some of the desirable 836 properties of the computation of the solution Segment-List. 838 5.3. Composite Candidate Path 840 A composite candidate path is specified as a group of its constituent 841 SR Policies. 843 A composite candidate path is valid when it has at least one valid 844 constituent SR Policy. 846 6. Binding SID 848 The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 849 It provides scaling, network opacity, and service independence. 850 [I-D.filsfils-spring-sr-policy-considerations] illustrates some of 851 these benefits. This section describes the association of BSID with 852 an SR Policy. 854 6.1. BSID of a candidate path 856 Each candidate path MAY be defined with a BSID. 858 Candidate Paths of the same SR policy SHOULD have the same BSID. 860 Candidate Paths of different SR policies MUST NOT have the same BSID. 862 6.2. BSID of an SR Policy 864 The BSID of an SR Policy is the BSID of its active candidate path. 866 When the active candidate path has a specified BSID, the SR Policy 867 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 868 available (i.e., not associated with any other usage: e.g. to another 869 MPLS client, to another SID, to another SR Policy). In the case of 870 SR-MPLS, an SRv6 BSID (e.g. with the behavior End.BM [RFC8986]) MAY 871 be associated with the SR Policy in addition to the MPLS BSID. In 872 the case of SRv6, multiple SRv6 BSIDs (e.g. with different behaviors 873 like End.B6.Encap and End.B6.Encap.Red [RFC8986]) MAY be associated 874 with the SR Policy. 876 Optionally, instead of only checking that the BSID of the active path 877 is available, a headend MAY check that it is available within a given 878 SID range i.e., Segment Routing Local Block (SRLB) as specified in 879 [RFC8402]. 881 When the specified BSID is not available (optionally is not in the 882 SRLB), an alert message MUST be generated. 884 In the cases (as described above) where SR Policy does not have a 885 BSID available, then the SR Policy MAY dynamically bind a BSID to 886 itself. Dynamically bound BSID SHOULD use an available SID outside 887 the SRLB. 889 Assuming that at time t the BSID of the SR Policy is B1, if at time 890 t+dt a different candidate path becomes active and this new active 891 path does not have a specified BSID or its BSID is specified but is 892 not available (e.g. it is in use by something else), then the SR 893 Policy keeps the previous BSID B1. 895 The association of an SR Policy with a BSID thus MAY change over the 896 life of the SR Policy (e.g., upon active path change). Hence, the 897 BSID SHOULD NOT be used as an identification of an SR Policy. 899 6.2.1. Frequent use-case : unspecified BSID 901 All the candidate paths of the same SR Policy can have an unspecified 902 BSID. 904 In such a case, a BSID MAY be dynamically bound to the SR Policy as 905 soon as the first valid candidate path is received. That BSID is 906 kept through the life of the SR Policy and across changes of active 907 candidate path. 909 6.2.2. Frequent use-case: all specified to the same BSID 911 All the paths of the SR Policy can have the same specified BSID. 913 6.2.3. Specified-BSID-only 915 An implementation MAY support the configuration of the Specified- 916 BSID-only restrictive behavior on the headend for all SR Policies or 917 individual SR Policies. Further, this restrictive behavior MAY also 918 be signaled on a per SR Policy basis to the headend. 920 When this restrictive behavior is enabled, if the candidate path has 921 an unspecified BSID or if the specified BSID is not available when 922 the candidate path becomes active then no BSID is bound to it and it 923 is considered invalid. An alert MUST be triggered for this error. 924 Other candidate paths MUST then be evaluated for becoming the active 925 candidate path. 927 6.3. Forwarding Plane 929 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 930 with the action of steering the packets matching this entry to the 931 selected path of the SR Policy. 933 If the Specified-BSID-only restrictive behavior is enabled and the 934 BSID of the active path is not available (optionally not in the 935 SRLB), then the SR Policy does not install any entry indexed by a 936 BSID in the forwarding plane. 938 6.4. Non-SR usage of Binding SID 940 An implementation MAY choose to associate a Binding SID with any type 941 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 942 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 943 tunnel, etc). This enables the use of other non-SR enabled 944 interfaces and tunnels as segments in an SR Policy Segment-List 945 without the need of forming routing protocol adjacencies over them. 947 The details of this kind of usage are beyond the scope of this 948 document. A specific packet-optical integration use case is 949 described in [I-D.anand-spring-poi-sr]. 951 7. SR Policy State 953 The SR Policy State is maintained on the headend to represent the 954 state of the policy and its candidate paths. This is to provide an 955 accurate representation of whether the SR Policy is being 956 instantiated in the forwarding plane and which of its candidate paths 957 and segment-list(s) are active. The SR Policy state MUST also 958 reflect the reason when a policy and/or its candidate path is not 959 active due to validation errors or not being preferred. 961 The SR Policy state can be reported by the headend node via BGP-LS 962 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 963 [I-D.ietf-pce-binding-label-sid]. 965 SR Policy state on the headend also includes traffic accounting 966 information for the flows being steered via the policies. The 967 details of the SR Policy accounting are beyond the scope of this 968 document. The aspects related to the SR traffic counters and their 969 usage in the broader context of traffic accounting in an SR network 970 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 971 [I-D.ali-spring-sr-traffic-accounting] respectively. 973 Implementations MAY support an administrative state to control 974 locally provisioned policies via mechanisms like CLI or NETCONF. 976 8. Steering into an SR Policy 978 A headend can steer a packet flow into a valid SR Policy in various 979 ways: 981 o Incoming packets have an active SID matching a local BSID at the 982 headend. 983 o Per-destination Steering: incoming packets match a BGP/Service 984 route which recurses on an SR policy. 985 o Per-flow Steering: incoming packets match or recurse on a 986 forwarding array of where some of the entries are SR Policies. 987 o Policy-based Steering: incoming packets match a routing policy 988 that directs them on an SR policy. 990 For simplicity of illustration, this document uses the SR-MPLS 991 example. 993 8.1. Validity of an SR Policy 995 An SR Policy is invalid when all its candidate paths are invalid as 996 described in Section 5 and Section 2.10. 998 By default, upon transitioning to the invalid state, 1000 o an SR Policy and its BSID are removed from the forwarding plane. 1001 o any steering of a service (PW), destination (BGP-VPN), flow or 1002 packet on the related SR policy is disabled and the related 1003 service, destination, flow, or packet is routed per the classic 1004 forwarding table (e.g. longest-match to the destination or the 1005 recursing next-hop). 1007 8.2. Drop upon invalid SR Policy 1009 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 1011 o an invalid SR Policy and its BSID is kept in the forwarding plane 1012 with an action to drop. 1013 o any steering of a service (PW), destination (BGP-VPN), flow or 1014 packet on the related SR policy is maintained with the action to 1015 drop all of this traffic. 1017 The drop-upon-invalid behavior has been deployed in use-cases where 1018 the operator wants some PW to only be transported on a path with 1019 specific constraints. When these constraints are no longer met, the 1020 operator wants the PW traffic to be dropped. Specifically, the 1021 operator does not want the PW to be routed according to the IGP 1022 shortest path to the PW endpoint. 1024 8.3. Incoming Active SID is a BSID 1026 Let us assume that headend H has a valid SR Policy P of Segment-List 1027 and BSID B. 1029 When H receives a packet K with label stack , H pops B and 1030 pushes and forwards the resulting packet according to 1031 SID S1. 1033 "Forwarding the resulting packet according to S1" means: If S1 is 1034 an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H 1035 sends the resulting packet with label stack on 1036 the outgoing interface associated with S1; Else H sends the 1037 resulting packet with label stack along the 1038 path of S1. 1040 H has steered the packet into the SR policy P. 1042 H did not have to classify the packet. The classification was done 1043 by a node upstream of H (e.g., the source of the packet or an 1044 intermediate ingress edge node of the SR domain) and the result of 1045 this classification was efficiently encoded in the packet header as a 1046 BSID. 1048 This is another key benefit of the segment routing in general and the 1049 binding SID in particular: the ability to encode a classification and 1050 the resulting steering in the packet header to better scale and 1051 simplify intermediate aggregation nodes. 1053 If the SR Policy P is invalid, the BSID B is not in the forwarding 1054 plane and hence the packet K is dropped by H. 1056 8.4. Per-Destination Steering 1058 Let us assume that headend H: 1060 o learns a BGP route R/r via next-hop N, extended-color community C 1061 and VPN label V. 1062 o has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1063 List and BSID B. 1064 o has a BGP policy that matches on the extended-color community C 1065 and allows its usage as SLA steering information. 1067 If all these conditions are met, H installs R/r in RIB/FIB with next- 1068 hop = SR Policy P of BSID B instead of via N. 1070 Indeed, H's local BGP policy and the received BGP route indicate that 1071 the headend should associate R/r with an SR Policy path to endpoint N 1072 with the SLA associated with color C. The headend, therefore, 1073 installs the BGP route on that policy. 1075 This can be implemented by using the BSID as a generalized next-hop 1076 and installing the BGP route on that generalized next-hop. 1078 When H receives a packet K with a destination matching R/r, H pushes 1079 the label stack and sends the resulting packet along 1080 the path to S1. 1082 Note that any SID associated with the BGP route is inserted after the 1083 Segment-List of the SR Policy (i.e., ). 1085 The same behavior applies to any type of service route: any AFI/SAFI 1086 of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1088 In a BGP multi-path scenario, the BGP route may be resolved over a 1089 mix of paths that include those that are steered over SR Policies and 1090 others resolved via the normal BGP nexthop resolution. 1091 Implementations MAY provide options to prefer one type over the other 1092 or other forms of local policy to determine the paths that are 1093 selected. 1095 8.4.1. Multiple Colors 1097 When a BGP route has multiple extended-color communities each with a 1098 valid SR Policy, the BGP process installs the route on the SR Policy 1099 giving preference to the color with the highest numerical value. 1101 Let us assume that headend H: 1103 o learns a BGP route R/r via next-hop N, extended-color communities 1104 C1 and C2 and VPN label V. 1105 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1106 List and BSID B1. 1107 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1108 List and BSID B2. 1109 o has a BGP policy that matches the extended-color communities C1 1110 and C2 and allows their usage as SLA steering information 1112 If all these conditions are met, H installs R/r in RIB/FIB with next- 1113 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1115 When the SR Policy with a specific color is not instantiated or in 1116 the down/inactive state, the SR Policy with the next highest 1117 numerical value of color is considered. 1119 8.5. Recursion on an on-demand dynamic BSID 1121 In the previous section, it was assumed that H had a pre-established 1122 "explicit" SR Policy (color C, endpoint N). 1124 In this section, independent of the a-priori existence of any 1125 explicit candidate path of the SR policy (C, N), it is to be noted 1126 that the BGP process at headend node H triggers the instantiation of 1127 a dynamic candidate path for the SR policy (C, N) as soon as: 1129 o the BGP process learns of a route R/r via N and with color C. 1130 o a local policy at node H authorizes the on-demand SR Policy path 1131 instantiation and maps the color to a dynamic SR Policy path 1132 optimization template. 1134 8.5.1. Multiple Colors 1136 When a BGP route R/r via N has multiple extended-color communities Ci 1137 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1138 request (color Ci, endpoint N) is triggered for each color Ci. The 1139 SR Policy that is used for steering is then determined as described 1140 in Section 8.4.1. 1142 8.6. Per-Flow Steering 1144 Let us assume that headend H: 1146 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1147 List and BSID B1. 1148 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1149 List and BSID B2. 1150 o is configured to instantiate an array of paths to N where the 1151 entry 0 is the IGP path to N, color C1 is the first entry and 1152 Color C2 is the second entry. The index into the array is called 1153 a Forwarding Class (FC). The index can have values 0 to 7. 1154 o is configured to match flows in its ingress interfaces (upon any 1155 field such as Ethernet destination/source/VLAN/TOS or IP 1156 destination/source/DSCP or transport ports etc.) and color them 1157 with an internal per-packet forwarding-class variable (0, 1 or 2 1158 in this example). 1160 If all these conditions are met, H installs in RIB/FIB: 1162 o N via recursion on an array A (instead of the immediate outgoing 1163 link associated with the IGP shortest-path to N). 1164 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1165 path to N. 1166 o Entry A(1) set to SR Policy P1 of BSID=B1. 1167 o Entry A(2) set to SR Policy P2 of BSID=B2. 1169 H receives three packets K, K1, and K2 on its incoming interface. 1170 These three packets either longest-match on N or more likely on a 1171 BGP/service route which recurses on N. H colors these 3 packets 1172 respectively with forwarding-class 0, 1, and 2. As a result: 1174 o H forwards K along the shortest path to N (which in SR-MPLS 1175 results in the pushing of the prefix-SID of N). 1176 o H pushes on packet K1 and forwards the resulting 1177 frame along the shortest path to S1. 1178 o H pushes on packet K2 and forwards the resulting 1179 frame along the shortest path to S4. 1181 If the local configuration does not specify any explicit forwarding 1182 information for an entry of the array, then this entry is filled with 1183 the same information as entry 0 (i.e. the IGP shortest path). 1185 If the SR Policy mapped to an entry of the array becomes invalid, 1186 then this entry is filled with the same information as entry 0. When 1187 all the array entries have the same information as entry0, the 1188 forwarding entry for N is updated to bypass the array and point 1189 directly to its outgoing interface and next-hop. 1191 The array index values (e.g. 0, 1, and 2) and the notion of 1192 forwarding-class are implementation-specific and only meant to 1193 describe the desired behavior. The same can be realized by other 1194 mechanisms. 1196 This realizes per-flow steering: different flows bound to the same 1197 BGP endpoint are steered on different IGP or SR Policy paths. 1199 A headend MAY support options to apply per-flow steering only for 1200 traffic matching specific prefixes (e.g. specific IGP or BGP 1201 prefixes). 1203 8.7. Policy-based Routing 1205 Finally, headend H may be configured with a local routing policy 1206 which overrides any BGP/IGP path and steer a specified packet on an 1207 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1208 automatic routing of IGP prefixes over SR Policies intended for such 1209 purpose. 1211 8.8. Optional Steering Modes for BGP Destinations 1213 8.8.1. Color-Only BGP Destination Steering 1215 In the previous section, it is seen that the steering on an SR Policy 1216 is governed by the matching of the BGP route's next-hop N and the 1217 authorized color C with an SR Policy defined by the tuple (N, C). 1219 This is the most likely form of BGP destination steering and the one 1220 recommended for most use-cases. 1222 This section defines an alternative steering mechanism based only on 1223 the color. 1225 This color-only steering variation is governed by two new "CO" bits 1226 defined in the color extended community in section 3 of 1227 [I-D.ietf-idr-segment-routing-te-policy]. 1229 The Color-Only flags "CO" are set to 00 by default. 1231 When 00, the BGP destination is steered as follows: 1233 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1235 endpoint address and C is a color; 1236 Steer into SR Policy (N, C); 1237 ELSE; 1238 Steer on the IGP path to the next-hop N. 1240 This is the classic case described in this document previously and 1241 what is recommended in most scenarios. 1243 When 01, the BGP destination is steered as follows: 1245 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1247 endpoint address and C is a color; 1248 Steer into SR Policy (N, C); 1249 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1250 same address-family of N; 1251 Steer into SR Policy (null endpoint, C); 1252 ELSE IF there is any valid SR Policy 1253 (any address-family null endpoint, C); 1254 Steer into SR Policy (any null endpoint, C); 1255 ELSE; 1256 Steer on the IGP path to the next-hop N. 1258 When 10, the BGP destination is steered as follows: 1260 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1261 endpoint address and C is a color; 1262 Steer into SR Policy (N, C); 1263 ELSE IF there is a valid SR Policy (null endpoint, C) 1264 of the same address-family of N; 1265 Steer into SR Policy (null endpoint, C); 1266 ELSE IF there is any valid SR Policy 1267 (any address-family null endpoint, C); 1268 Steer into SR Policy (any null endpoint, C); 1269 ELSE IF there is any valid SR Policy (any endpoint, C) 1270 of the same address-family of N; 1271 Steer into SR Policy (any endpoint, C); 1272 ELSE IF there is any valid SR Policy 1273 (any address-family endpoint, C); 1274 Steer into SR Policy (any address-family endpoint, C); 1275 ELSE; 1276 Steer on the IGP path to the next-hop N. 1278 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1279 to the 0 value). 1281 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1282 reception, an implementation MUST treat it like 00. 1284 8.8.2. Multiple Colors and CO flags 1286 The steering preference is first based on the highest color value and 1287 then CO-dependent for the color. Assuming a Prefix via (NH, 1288 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1290 o SR policy (NH, C1). 1291 o SR policy (null, C1). 1292 o SR policy (NH, C2). 1293 o SR policy (null, C2). 1294 o IGP to NH. 1296 8.8.3. Drop upon Invalid 1298 This document defined earlier that when all the following conditions 1299 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1300 BSID B instead of via N. 1302 o H learns a BGP route R/r via next-hop N, extended-color community 1303 C and VPN label V. 1304 o H has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1305 List and BSID B. 1306 o H has a BGP policy that matches the extended-color community C and 1307 allows its usage as SLA steering information. 1309 This behavior is extended by noting that the BGP policy may require 1310 the BGP steering to always stay on the SR policy whatever its 1311 validity. 1313 This is the "drop upon invalid" option described in Section 8.2 1314 applied to BGP-based steering. 1316 9. Protection 1318 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1320 In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) 1321 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1322 protection technique for IGP SIDs. The backup path is computed on a 1323 per IGP SID basis along the post-convergence path. 1325 In a network that has deployed TI-LFA, an SR Policy built on the 1326 basis of TI-LFA protected IGP segments leverages the local protection 1327 of the constituent segments. Since TI-LFA protection is based on IGP 1328 computation, there are cases where the path used during the fast- 1329 reroute time window may not meet the exact constraints of the SR 1330 Policy. 1332 In a network that has deployed TI-LFA, an SR Policy instantiated only 1333 with non-protected Adj SIDs does not benefit from any local 1334 protection. 1336 9.2. Using an SR Policy to locally protect a link 1338 1----2-----6----7 1339 | | | | 1340 4----3-----9----8 1342 Figure 1: Local protection using SR Policy 1344 An SR Policy can be instantiated at node 2 to protect the link 2to6. 1345 A typical explicit Segment-List would be <3, 9, 6>. 1347 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1348 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are 1349 part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 1350 cannot benefit from TI-LFA automated local protection. The SR Policy 1351 with Segment-List <3, 9, 6> on node 2 can be locally configured to be 1352 a fast-reroute backup path for the link 2to6. 1354 9.3. Using a Candidate Path for Path Protection 1356 An SR Policy allows for multiple candidate paths, of which at any 1357 point in time there is a single active candidate path that is 1358 provisioned in the forwarding plane and used for traffic steering. 1359 However, another (lower preference) candidate path MAY be designated 1360 as the backup for a specific or all (active) candidate path(s). The 1361 following options are possible: 1363 o A pair of disjoint candidate paths are provisioned with one of 1364 them as primary and the other is identified as its backup. 1365 o A specific candidate path is provisioned as the backup for any 1366 (active) candidate path. 1367 o The headend picks the next (lower) preference valid candidate path 1368 as the backup for the active candidate path. 1370 The headend MAY compute a-priori and validate such backup candidate 1371 paths as well as provision them into the forwarding plane as a backup 1372 for the active path. A fast re-route mechanism MAY then be used to 1373 trigger sub 50msec switchover from the active to the backup candidate 1374 path in the forwarding plane. Mechanisms like BFD MAY be used for 1375 fast detection of such failures. 1377 10. Security Considerations 1379 This document specifies in detail the SR Policy construct introduced 1380 in [RFC8402] and its instantiation on a router supporting SR along 1381 with descriptions of mechanisms for steering of traffic flows over 1382 it. Therefore, the security considerations of [RFC8402] apply. This 1383 document does not define any new protocol extensions and does not 1384 introduce any further security considerations. 1386 11. IANA Considerations 1388 The document requests IANA to create a new sub-registry called 1389 "Segment Types" under the top-level "Segment Routing" registry. This 1390 sub-registry maintains the alphabetic identifiers for the segment 1391 types (as specified in section 4) that may be used within a Segment 1392 List of an SR Policy. This sub-registry would follow the 1393 Specification Required allocation policy as specified in [RFC8126]. 1395 The initial registrations for this sub-registry are as follows: 1397 +-------+-----------------------------------------------+-----------+ 1398 | Value | Description | Reference | 1399 +-------+-----------------------------------------------+-----------+ 1400 | A | SR-MPLS Label | [This.ID] | 1401 | B | SRv6 SID | [This.ID] | 1402 | C | IPv4 Prefix with optional SR Algorithm | [This.ID] | 1403 | D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1404 | | for SR-MPLS | | 1405 | E | IPv4 Prefix with Local Interface ID | [This.ID] | 1406 | F | IPv4 Addresses for link endpoints as Local, | [This.ID] | 1407 | | Remote pair | | 1408 | G | IPv6 Prefix and Interface ID for link | [This.ID] | 1409 | | endpoints as Local, Remote pair for SR-MPLS | | 1410 | H | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1411 | | Remote pair for SR-MPLS | | 1412 | I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1413 | | for SRv6 | | 1414 | J | IPv6 Prefix and Interface ID for link | [This.ID] | 1415 | | endpoints as Local, Remote pair for SRv6 | | 1416 | K | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1417 | | Remote pair for SRv6 | | 1418 +-------+-----------------------------------------------+-----------+ 1420 Table 2: Initial IANA Registration 1422 11.1. Guidance for Designated Experts 1424 The Designated Expert (DE) is expected to ascertain the existence of 1425 suitable documentation (a specification) as described in [RFC8126] 1426 and to verify that the document is permanently and publicly 1427 available. The DE is also expected to check the clarity of purpose 1428 and use of the requested assignment. Additionally, the DE must 1429 verify that any request for one of these assignments has been made 1430 available for review and comment within the IETF: the DE will post 1431 the request to the SPRING Working Group mailing list (or a successor 1432 mailing list designated by the IESG). If the request comes from 1433 within the IETF, it should be documented in an Internet-Draft. 1434 Lastly, the DE must ensure that any other request for a code point 1435 does not conflict with work that is active or already published 1436 within the IETF. 1438 12. Acknowledgement 1440 The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger 1441 Geib, Rob Shakir, Cheng Li and Dhruv Dhody for their review comments 1442 and suggestions. 1444 13. Contributors 1446 The following people have contributed to this document: 1448 Siva Sivabalan 1449 Cisco Systems 1450 Email: msiva@cisco.com 1452 Zafar Ali 1453 Cisco Systems 1454 Email: zali@cisco.com 1456 Jose Liste 1457 Cisco Systems 1458 Email: jliste@cisco.com 1460 Francois Clad 1461 Cisco Systems 1462 Email: fclad@cisco.com 1464 Kamran Raza 1465 Cisco Systems 1466 Email: skraza@cisco.com 1468 Mike Koldychev 1469 Cisco Systems 1470 Email: mkoldych@cisco.com 1472 Shraddha Hegde 1473 Juniper Networks 1474 Email: shraddha@juniper.net 1476 Steven Lin 1477 Google, Inc. 1478 Email: stevenlin@google.com 1480 Przemyslaw Krol 1481 Google, Inc. 1482 Email: pkrol@google.com 1484 Martin Horneffer 1485 Deutsche Telekom 1486 Email: martin.horneffer@telekom.de 1488 Dirk Steinberg 1489 Steinberg Consulting 1490 Email: dws@steinbergnet.net 1491 Bruno Decraene 1492 Orange Business Services 1493 Email: bruno.decraene@orange.com 1495 Stephane Litkowski 1496 Orange Business Services 1497 Email: stephane.litkowski@orange.com 1499 Luay Jalil 1500 Verizon 1501 Email: luay.jalil@verizon.com 1503 14. References 1505 14.1. Normative References 1507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1508 Requirement Levels", BCP 14, RFC 2119, 1509 DOI 10.17487/RFC2119, March 1997, 1510 . 1512 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1513 Writing an IANA Considerations Section in RFCs", BCP 26, 1514 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1515 . 1517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1518 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1519 May 2017, . 1521 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1522 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1523 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1524 July 2018, . 1526 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1527 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1528 (SRv6) Network Programming", RFC 8986, 1529 DOI 10.17487/RFC8986, February 2021, 1530 . 1532 14.2. Informative References 1534 [I-D.ali-spring-sr-traffic-accounting] 1535 Filsfils, C., Talaulikar, K., Sivabalan, S., Horneffer, 1536 M., Raszuk, R., Litkowski, S., Voyer, D., and R. Morton, 1537 "Traffic Accounting in Segment Routing Networks", draft- 1538 ali-spring-sr-traffic-accounting-05 (work in progress), 1539 April 2021. 1541 [I-D.anand-spring-poi-sr] 1542 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1543 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1544 Integration in Segment Routing", draft-anand-spring-poi- 1545 sr-08 (work in progress), July 2019. 1547 [I-D.filsfils-spring-sr-policy-considerations] 1548 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1549 P. Mattes, "SR Policy Implementation and Deployment 1550 Considerations", draft-filsfils-spring-sr-policy- 1551 considerations-07 (work in progress), April 2021. 1553 [I-D.filsfils-spring-sr-traffic-counters] 1554 Filsfils, C., Ali, Z., Horneffer, M., Voyer, D., Durrani, 1555 M., and R. Raszuk, "Segment Routing Traffic Accounting 1556 Counters", draft-filsfils-spring-sr-traffic-counters-01 1557 (work in progress), April 2021. 1559 [I-D.ietf-idr-bgpls-segment-routing-epe] 1560 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1561 S., and J. Dong, "BGP-LS extensions for Segment Routing 1562 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1563 segment-routing-epe-19 (work in progress), May 2019. 1565 [I-D.ietf-idr-segment-routing-te-policy] 1566 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1567 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 1568 Routing Policies in BGP", draft-ietf-idr-segment-routing- 1569 te-policy-11 (work in progress), November 2020. 1571 [I-D.ietf-idr-te-lsp-distribution] 1572 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1573 H., and J. Tantsura, "Distribution of Traffic Engineering 1574 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1575 lsp-distribution-14 (work in progress), October 2020. 1577 [I-D.ietf-lsr-flex-algo] 1578 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1579 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1580 algo-14 (work in progress), February 2021. 1582 [I-D.ietf-pce-binding-label-sid] 1583 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 1584 and C. Li, "Carrying Binding Label/Segment Identifier in 1585 PCE-based Networks.", draft-ietf-pce-binding-label-sid-08 1586 (work in progress), April 2021. 1588 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1589 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 1590 Decraene, B., and D. Voyer, "Topology Independent Fast 1591 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 1592 routing-ti-lfa-06 (work in progress), February 2021. 1594 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1595 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1596 December 1990, . 1598 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1599 DOI 10.17487/RFC2328, April 1998, 1600 . 1602 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1603 (TE) Extensions to OSPF Version 2", RFC 3630, 1604 DOI 10.17487/RFC3630, September 2003, 1605 . 1607 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1608 "Multiprotocol Extensions for BGP-4", RFC 4760, 1609 DOI 10.17487/RFC4760, January 2007, 1610 . 1612 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1613 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1614 2008, . 1616 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1617 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1618 . 1620 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1621 Locator/ID Separation Protocol (LISP)", RFC 6830, 1622 DOI 10.17487/RFC6830, January 2013, 1623 . 1625 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1626 Previdi, "OSPF Traffic Engineering (TE) Metric 1627 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1628 . 1630 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1631 S. Ray, "North-Bound Distribution of Link-State and 1632 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1633 DOI 10.17487/RFC7752, March 2016, 1634 . 1636 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1637 Computation Element Communication Protocol (PCEP) 1638 Extensions for Stateful PCE", RFC 8231, 1639 DOI 10.17487/RFC8231, September 2017, 1640 . 1642 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1643 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1644 DOI 10.17487/RFC8476, December 2018, 1645 . 1647 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1648 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1649 DOI 10.17487/RFC8491, November 2018, 1650 . 1652 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1653 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1654 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1655 2019, . 1657 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1658 and J. Hardwick, "Path Computation Element Communication 1659 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1660 DOI 10.17487/RFC8664, December 2019, 1661 . 1663 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 1664 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 1665 Using the Border Gateway Protocol - Link State", RFC 8814, 1666 DOI 10.17487/RFC8814, August 2020, 1667 . 1669 Authors' Addresses 1671 Clarence Filsfils 1672 Cisco Systems, Inc. 1673 Pegasus Parc 1674 De kleetlaan 6a, DIEGEM BRABANT 1831 1675 BELGIUM 1677 Email: cfilsfil@cisco.com 1678 Ketan Talaulikar (editor) 1679 Cisco Systems, Inc. 1680 India 1682 Email: ketant@cisco.com 1684 Daniel Voyer 1685 Bell Canada 1686 671 de la gauchetiere W 1687 Montreal, Quebec H3B 2M8 1688 Canada 1690 Email: daniel.voyer@bell.ca 1692 Alex Bogdanov 1693 Google, Inc. 1695 Email: bogdanov@google.com 1697 Paul Mattes 1698 Microsoft 1699 One Microsoft Way 1700 Redmond, WA 98052-6399 1701 USA 1703 Email: pamattes@microsoft.com