idnits 2.17.1 draft-ietf-spring-segment-routing-policy-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2020) is 1386 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-04 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-05 == Outdated reference: A later version (-02) exists of draft-filsfils-spring-sr-traffic-counters-00 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-13 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-07 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 -- 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 (~~), 10 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: January 8, 2021 D. Voyer 6 Bell Canada 7 A. Bogdanov 8 Google, Inc. 9 P. Mattes 10 Microsoft 11 July 7, 2020 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-08 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 January 8, 2021. 43 Copyright Notice 45 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 64 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 4 65 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 5 66 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 6 67 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 6 68 2.6. Identification of a Candidate Path . . . . . . . . . . . 7 69 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 7 70 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 7 71 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 9 75 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 10 77 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 14 79 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 15 80 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 15 81 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 16 82 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 17 84 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 17 85 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 19 86 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 19 87 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 19 88 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 20 89 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 20 90 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 20 91 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 21 92 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 21 93 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 22 94 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 23 95 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 24 96 8.8. Optional Steering Modes for BGP Destinations . . . . . . 24 97 9. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 9.1. Leveraging TI-LFA local protection of the constituent IGP 99 segments . . . . . . . . . . . . . . . . . . . . . . . . 26 100 9.2. Using an SR Policy to locally protect a link . . . . . . 27 101 9.3. Using a Candidate Path for Path Protection . . . . . . . 27 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 104 11.1. Guidance for Designated Experts . . . . . . . . . . . . 29 105 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 106 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 107 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 108 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 109 14.2. Informative References . . . . . . . . . . . . . . . . . 31 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 112 1. Introduction 114 Segment Routing (SR) allows a headend node to steer a packet flow 115 along any path. Intermediate per-flow states are eliminated thanks 116 to source routing [RFC8402]. 118 The headend node is said to steer a flow into an Segment Routing 119 Policy (SR Policy). 121 The header of a packet steered into an SR Policy is augmented with an 122 ordered list of segments associated with that SR Policy. 124 This document details the concepts of SR Policy and steering packets 125 into an SR Policy. These apply equally to the MPLS and SRv6 126 instantiations of segment routing. 128 For reading simplicity, the illustrations are provided for the MPLS 129 instantiations. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2. SR Policy 141 An SR Policy is a framework that enables instantiation of an ordered 142 list of segments on a node for implementing a source routing policy 143 with a specific intent for traffic steering from that node. 145 The Segment Routing architecture [RFC8402] specifies that any 146 instruction can be bound to a segment. Thus, an SR Policy can be 147 built using any type of Segment Identifier (SID) including those 148 associated with topological or service instructions. 150 This section defines the key aspects and constituents of an SR 151 Policy. 153 2.1. Identification of an SR Policy 155 An SR Policy is identified through the tuple . In the context of a specific headend, one may identify an 157 SR policy by the tuple. 159 The headend is the node where the policy is instantiated/implemented. 160 The headend is specified as an IPv4 or IPv6 address and is expected 161 to be unique in the domain. 163 The endpoint indicates the destination of the policy. The endpoint 164 is specified as an IPv4 or IPv6 address and is expected to be unique 165 in the domain. In a specific case (refer to Section 8.8.1), the 166 endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6). 168 The color is a 32-bit numerical value that associates the SR Policy 169 with an intent (e.g. low-latency). 171 The endpoint and the color are used to automate the steering of 172 service or transport routes on SR Policies (refer to Section 8). 174 An implementation MAY allow assignment of a symbolic name comprising 175 of printable ASCII characters to an SR Policy to serve as a user- 176 friendly attribute for debug and troubleshooting purposes. Such 177 symbolic names may identify an SR Policy when the naming scheme 178 ensures uniqueness. The SR Policy name may also be signaled along 179 with a candidate path of the SR Policy (refer Section 2.2). An SR 180 Policy may have multiple names associated with it in the scenario 181 where the headend receives different SR Policy names along with 182 candidate paths for the same SR Policy. 184 2.2. Candidate Path and Segment List 186 An SR Policy is associated with one or more candidate paths. A 187 candidate path is the unit for signaling of an SR Policy to a headend 188 via protocols like Path Computation Element (PCE) Communication 189 Protocol (PCEP) [RFC8664] or BGP SR Policy 190 [I-D.ietf-idr-segment-routing-te-policy]. 192 A Segment-List represents a specific source-routed path to send 193 traffic from the headend to the endpoint of the corresponding SR 194 policy. 196 A candidate path is either dynamic or explicit. 198 An explicit candidate path is expressed as a Segment-List or a set of 199 Segment-Lists. 201 A dynamic candidate path expresses an optimization objective and a 202 set of constraints. The headend (potentially with the help of a PCE) 203 computes the solution Segment-List (or set of Segment-Lists) that 204 solves the optimization problem. 206 If a candidate path is associated with a set of Segment-Lists, each 207 Segment-List is associated with a weight for weighted load balancing 208 (refer Section 2.11 for details). The default weight is 1. 210 2.3. Protocol-Origin of a Candidate Path 212 A headend may be informed about a candidate path for an SR Policy 213 by various means including: via configuration, PCEP 214 [RFC8664] or BGP [I-D.ietf-idr-segment-routing-te-policy]. 216 Protocol-Origin of a candidate path is an 8-bit value which 217 identifies the component or protocol that originates or signals the 218 candidate path. 220 The head-end assigns different Protocol-Origin Priority values to 221 each Protocol-Origin. The Protocol-Origin Priority is used as a tie- 222 breaker between candidate-paths of equal preference, as described in 223 Section 2.9. The table below specifies the RECOMMENDED default 224 values of Protocol-Origin Priority: 226 +-------+-------------------+ 227 | Value | Protocol-Origin | 228 +-------+-------------------+ 229 | 10 | PCEP | 230 | 20 | BGP SR Policy | 231 | 30 | Via Configuration | 232 +-------+-------------------+ 234 Table 1: Protocol-Origin Priority default values 236 Implementations MAY allow modifications of these default values 237 assigned to protocols on the headend along similar lines as a routing 238 administrative distance. Its application in the candidate path 239 selection is described in Section 2.9. 241 2.4. Originator of a Candidate Path 243 Originator identifies the node which provisioned or signalled the 244 candidate path on the headend. The originator is expressed in the 245 form of a 160 bit numerical value formed by the concatenation of the 246 fields of the tuple as below: 248 o ASN : represented as a 4 byte number. 250 o Node Address : represented as a 128 bit value. IPv4 addresses are 251 encoded in the lowest 32 bits. 253 Its application in the candidate path selection is described in 254 Section 2.9. 256 When Protocol-Origin is Via Configuration, the ASN and node address 257 MAY be set to either the headend or the provisioning controller/node 258 ASN and address. Default value is 0 for both AS and node address. 260 When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the 261 PCE and the AS number SHOULD be set to 0 by default when not 262 available or known. 264 When Protocol-Origin is BGP SR Policy, the ASN and Node Address are 265 provided by BGP (refer [I-D.ietf-idr-segment-routing-te-policy]) on 266 the headend. 268 2.5. Discriminator of a Candidate Path 270 The Discriminator is a 32 bit value associated with a candidate path 271 that uniquely identifies it within the context of an SR Policy from a 272 specific Protocol-Origin as specified below: 274 When Protocol-Origin is Via Configuration, this is an 275 implementation's configuration model specific unique identifier for a 276 candidate path. Default value is 0. 278 When PCEP is the Protocol-Origin, the method to uniquely identify 279 signalled path will be specified in a future PCEP document. Default 280 value is 0. 282 When BGP SR Policy is the Protocol-Origin, it is the distinguisher 283 (refer Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]). 285 Its application in the candidate path selection is described in 286 Section 2.9. 288 2.6. Identification of a Candidate Path 290 A candidate path is identified in the context of a single SR Policy. 292 A candidate path is not shared across SR Policies. 294 A candidate path is not identified by its Segment-List(s). 296 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 297 candidate path of SR Policy Pol2, then these two candidate paths 298 are independent, even if they happen to have the same Segment- 299 List. The Segment-List does not identify a candidate path. The 300 Segment-List is an attribute of a candidate path. 302 The identity of a candidate path MUST be uniquely established in the 303 context of an SR Policy in order to handle 304 add, delete or modify operations on them in an unambiguous manner 305 regardless of their source(s). 307 The tuple uniquely 308 identifies a candidate path. 310 Candidate paths MAY also be assigned or signaled with a symbolic name 311 comprising printable ASCII characters to serve as a user-friendly 312 attribute for debug and troubleshooting purposes. Such symbolic 313 names MUST NOT be considered as identifiers for a candidate path. 315 2.7. Preference of a Candidate Path 317 The preference of the candidate path is used to select the best 318 candidate path for an SR Policy. The default preference is 100. 320 It is RECOMMENDED that each candidate path of a given SR policy has a 321 different preference. 323 2.8. Validity of a Candidate Path 325 A candidate path is usable when it valid. A common path validity 326 criterion is the reachability of its constituent SIDs. The 327 validation rules are specified in Section 5. 329 2.9. Active Candidate Path 331 A candidate path is selected when it is valid and it is determined to 332 be the best path of the SR Policy. The selected path is referred to 333 as the "active path" of the SR policy in this document. 335 Whenever a new path is learned or an active path is deleted, the 336 validity of an existing path changes or an existing path is changed, 337 the selection process MUST be re-executed. 339 The candidate path selection process operates on the candidate path 340 Preference. A candidate path is selected when it is valid and it has 341 the highest preference value among all the candidate paths of the SR 342 Policy. 344 In the case of multiple valid candidate paths of the same preference, 345 the tie-breaking rules are evaluated on the identification tuple in 346 the following order until only one valid best path is selected: 348 1. Higher value of Protocol-Origin Priority is selected. 350 2. If specified by configuration, prefer the existing installed 351 path. 353 3. Lower value of originator is selected. 355 4. Finally, the higher value of discriminator is selected. 357 The rules are framed with multiple protocols and sources in mind and 358 hence may not follow the logic of a single protocol (e.g. BGP best 359 path selection). The motivation behind these rules are as follows: 361 o The Protocol-Origin allows an operator to setup a default 362 selection mechanism across protocol sources, e.g., to prefer 363 configured over paths signalled via BGP SR Policy or PCEP. 365 o The preference, being the first tiebreaker, allows an operator to 366 influence selection across paths thus allowing provisioning of 367 multiple path options, e.g., CP1 is preferred and if it becomes 368 invalid then fall-back to CP2 and so on. Since preference works 369 across protocol sources it also enables (where necessary) 370 selective override of the default protocol-origin preference, 371 e.g., to prefer a path signalled via BGP SR Policy over what is 372 configured. 374 o The originator allows an operator to have multiple redundant 375 controllers and still maintain a deterministic behaviour over 376 which of them are preferred even if they are providing the same 377 candidate paths for the same SR policies to the headend. 379 o The discriminator performs the final tiebreaking step to ensure a 380 deterministic outcome of selection regardless of the order in 381 which candidate paths are signalled across multiple transport 382 channels or sessions. 384 [I-D.filsfils-spring-sr-policy-considerations] provides a set of 385 examples to illustrate the active candidate path selection rules. 387 2.10. Validity of an SR Policy 389 An SR Policy is valid when it has at least one valid candidate path. 391 2.11. Instantiation of an SR Policy in the Forwarding Plane 393 A valid SR Policy is instantiated in the forwarding plane. 395 Only the active candidate path SHOULD be used for forwarding traffic 396 that is being steered onto that policy. 398 If a set of Segment-Lists is associated with the active path of the 399 policy, then the steering is per flow and W-ECMP based according to 400 the relative weight of each Segment-List. 402 The fraction of the flows associated with a given Segment-List is w/ 403 Sw where w is the weight of the Segment-List and Sw is the sum of the 404 weights of the Segment-Lists of the selected path of the SR Policy. 406 The accuracy of the weighted load-balancing depends on the platform 407 implementation. 409 2.12. Priority of an SR Policy 411 Upon topological change, many policies could be recomputed or 412 revalidated. An implementation MAY provide a per-policy priority 413 configuration. The operator MAY set this field to indicate order in 414 which the policies should be re-computed. Such a priority is 415 represented by an integer in the range (0, 255) where the lowest 416 value is the highest priority. The default value of priority is 128. 418 An SR Policy may comprise multiple Candidate Paths received from the 419 same or different sources. A candidate path MAY be signaled with a 420 priority value. When an SR Policy has multiple candidate paths with 421 distinct signaled non-default priority values, the SR Policy as a 422 whole takes the lowest value (i.e. the highest priority) amongst 423 these signaled priority values. 425 2.13. Summary 427 In summary, the information model is the following: 429 SR policy POL1 430 Candidate-path CP1 432 Preference 200 433 Weight W1, SID-List1 434 Weight W2, SID-List2 435 Candidate-path CP2 437 Preference 100 438 Weight W3, SID-List3 439 Weight W4, SID-List4 441 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 443 identified by a tuple . 444 CP1 is the active candidate path (it is valid and it has the highest 445 preference). The two Segment-Lists of CP1 are installed as the 446 forwarding instantiation of SR policy POL1. Traffic steered on POL1 447 is flow-based hashed on Segment-List with a ratio 448 W1/(W1+W2). 450 3. Segment Routing Database 452 An SR headend maintains the Segment Routing Database (SR-DB). The 453 SR-DB is a conceptual database to illustrate the various pieces of 454 information and their sources that may help in SR Policy computation 455 and validation. There is no specific requirement for an 456 implementation to create a new database as such. 458 An SR headend leverages the SR-DB to validate explicit candidate 459 paths and compute dynamic candidate paths. 461 The information in the SR-DB MAY include: 463 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 464 OSPF [RFC2328] [RFC5340]) 465 o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj- 466 SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402] 467 [I-D.ietf-spring-srv6-network-programming] 468 o TE Link Attributes (such as TE metric, SRLG, attribute-flag, 469 extended admin group) [RFC5305] [RFC3630]. 470 o Extended TE Link attributes (such as latency, loss) [RFC8570] 471 [RFC7471] 472 o Inter-AS Topology information 473 [I-D.ietf-idr-bgpls-segment-routing-epe]. 475 The attached domain topology MAY be learned via IGP, BGP-LS or 476 NETCONF. 478 A non-attached (remote) domain topology MAY be learned via BGP-LS or 479 NETCONF. 481 In some use-cases, the SR-DB may only contain the attached domain 482 topology while in others, the SR-DB may contain the topology of 483 multiple domains and in this case it is multi-domain capable. 485 The SR-DB MAY also contain the SR Policies instantiated in the 486 network. This can be collected via BGP-LS 487 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 488 [I-D.ietf-pce-binding-label-sid]. This information allows to build 489 an end-to-end policy on the basis of intermediate SR policies (see 490 Section 6 for further details). 492 The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of 493 nodes in the topology. This can be collected via ISIS [RFC8491], 494 OSPF [RFC8476], BGP-LS [I-D.ietf-idr-bgp-ls-segment-routing-msd] or 495 PCEP [RFC8664]. 497 The use of the SR-DB for computation and validation of SR Policies is 498 outside the scope of this document. Some implementation aspects 499 related to this are covered in 500 [I-D.filsfils-spring-sr-policy-considerations]. 502 4. Segment Types 504 A Segment-List is an ordered set of segments represented as where S1 is the first segment. 507 Based on the desired dataplane, either the MPLS label stack or the 508 SRv6 SRH is built from the Segment-List. However, the Segment-List 509 itself can be specified using different segment-descriptor types and 510 the following are currently defined: 512 Type A: SR-MPLS Label: 513 A MPLS label corresponding to any of the segment types defined 514 for SR-MPLS (as defined in [RFC8402] or other SR-MPLS 515 specifications) can be used. Additionally, reserved labels 516 like explicit-null or in general any MPLS label may also be 517 used. E.g. this type can be used to specify a label 518 representation which maps to an optical transport path on a 519 packet transport node. This type does not require the headend 520 to perform SID resolution. 522 Type B: SRv6 SID: 523 An IPv6 address corresponding to any of the SID behaviors for 524 SRv6 (as defined in [I-D.ietf-spring-srv6-network-programming] 525 or other SRv6 specifications) can be used. This type does not 526 require the headend to perform SID resolution. 528 Type C: IPv4 Prefix with optional SR Algorithm: 530 The headend is required to resolve the specified IPv4 Prefix 531 Address to the SR-MPLS label corresponding to a Prefix SID 532 segment (as defined in [RFC8402]). The SR algorithm (refer to 533 Section 3.1.1 of [RFC8402]) to be used MAY also be provided. 535 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 536 In this case the headend is required to resolve the specified 537 IPv6 Global Prefix Address to the SR-MPLS label corresponding 538 to its Prefix SID segment (as defined in [RFC8402]). The SR 539 Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY 540 also be provided. 542 Type E: IPv4 Prefix with Local Interface ID: 543 This type allows identification of Adjacency SID or BGP Peer 544 Adjacency SID (as defined in [RFC8402]) label for point-to- 545 point links including IP unnumbered links. The headend is 546 required to resolve the specified IPv4 Prefix Address to the 547 Node originating it and then use the Local Interface ID to 548 identify the point-to-point link whose adjacency is being 549 referred to. The Local Interface ID link descriptor follows 550 semantics as specified in [RFC7752]. This type can also be 551 used to indicate indirection into a layer 2 interface (i.e. 552 without IP address) like a representation of an optical 553 transport path or a layer 2 Ethernet port or circuit at the 554 specified node. 556 Type F: IPv4 Addresses for link endpoints as Local, Remote pair: 557 This type allows identification of Adjacency SID or BGP Peer 558 Adjacency SID (as defined in [RFC8402]) label for links. The 559 headend is required to resolve the specified IPv4 Local Address 560 to the Node originating it and then use the IPv4 Remote Address 561 to identify the link adjacency being referred to. The Local 562 and Remote Address pair link descriptors follows semantics as 563 specified in [RFC7752]. 565 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 566 Remote pair for SR-MPLS: 567 This type allows identification of Adjacency SID or BGP Peer 568 Adjacency SID (as defined in [RFC8402]) label for links 569 including those with only Link Local IPv6 addresses. The 570 headend is required to resolve the specified IPv6 Prefix 571 Address to the Node originating it and then use the Local 572 Interface ID to identify the point-to-point link whose 573 adjacency is being referred to. For other than point-to-point 574 links, additionally the specific adjacency over the link needs 575 to be resolved using the Remote Prefix and Interface ID. The 576 Local and Remote pair of Prefix and Interface ID link 577 descriptor follows semantics as specified in [RFC7752]. This 578 type can also be used to indicate indirection into a layer 2 579 interface (i.e. without IP address) like a representation of an 580 optical transport path or a layer 2 Ethernet port or circuit at 581 the specified node. 583 Type H: IPv6 Addresses for link endpoints as Local, Remote pair for 584 SR-MPLS: 585 This type allows identification of Adjacency SID or BGP Peer 586 Adjacency SID (as defined in [RFC8402]) label for links with 587 Global IPv6 addresses. The headend is required to resolve the 588 specified Local IPv6 Address to the Node originating it and 589 then use the Remote IPv6 Address to identify the link adjacency 590 being referred to. The Local and Remote Address pair link 591 descriptors follows semantics as specified in [RFC7752]. 593 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: 594 The headend is required to resolve the specified IPv6 Global 595 Prefix Address to an SRv6 SID corresponding to a Prefix SID 596 segment (as defined in [RFC8402]), such as a SID associated 597 with the End behavior (as defined in 598 [I-D.ietf-spring-srv6-network-programming]), of the node which 599 is originating the prefix. The SR Algorithm (refer to 600 Section 3.1.1 of [RFC8402]) to be used MAY also be provided. 602 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 603 Remote pair for SRv6: 604 This type allows identification of an SRv6 SID corresponding to 605 an Adjacency SID or BGP Peer Adjacency SID (as defined in 606 [RFC8402]), such as a SID associated with the End.X behavior 607 (as defined in [I-D.ietf-spring-srv6-network-programming]), 608 associated with link or adjacency with only Link Local IPv6 609 addresses. The headend is required to resolve the specified 610 IPv6 Prefix Address to the Node originating it and then use the 611 Local Interface ID to identify the point-to-point link whose 612 adjacency is being referred to. For other than point-to-point 613 links, additionally the specific adjacency needs to be resolved 614 using the Remote Prefix and Interface ID. The Local and Remote 615 pair of Prefix and Interface ID link descriptor follows 616 semantics as specified in [RFC7752]. 618 Type K: IPv6 Addresses for link endpoints as Local, Remote pair for 619 SRv6: 620 This type allows identification of an SRv6 SID corresponding to 621 an Adjacency SID or BGP Peer Adjacency SID (as defined in 622 [RFC8402]), such as a SID associated with the End.X behavior 623 (as defined in [I-D.ietf-spring-srv6-network-programming]), 624 associated with link or adjacency with Global IPv6 addresses. 625 The headend is required to resolve the specified Local IPv6 626 Address to the Node originating it and then use the Remote IPv6 627 Address to identify the link adjacency being referred to. The 628 Local and Remote Address pair link descriptors follows 629 semantics as specified in [RFC7752]. 631 Type L: SRv6 SID with Behavior 632 An SRv6 SID along with its behavior (as defined in 633 [I-D.ietf-spring-srv6-network-programming] or other SRv6 634 specifications) and structure (as defined in 635 [I-D.ietf-spring-srv6-network-programming]) can be used. This 636 type enables the headend to optionally perform validation of 637 the SID when using it for building the Segment List. 639 When the algorithm is not specified for the SID types above which 640 optionally allow for it, the headend SHOULD use the Strict Shortest 641 Path algorithm if available; otherwise it SHOULD use the default 642 Shortest Path algorithm. The specification of algorithm enables the 643 use of IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in 644 SR Policy. 646 For SID types C-through-L, a SID value may also be optionally 647 provided to the headend for verification purposes. Section 5.1. 648 describes the resolution and verification of the SIDs and Segment 649 Lists on the headend. 651 When building the MPLS label stack or the IPv6 Segment list from the 652 Segment List, the node instantiating the policy MUST interpret the 653 set of Segments as follows: 655 o The first Segment represents the topmost label or the first IPv6 656 segment. It identifies the active segment the traffic will be 657 directed toward along the explicit SR path. 658 o The last Segment represents the bottommost label or the last IPv6 659 segment the traffic will be directed toward along the explicit SR 660 path. 662 4.1. Explicit Null 664 A Type A SID may be any MPLS label, including reserved labels. 666 For example, assuming that the desired traffic-engineered path from a 667 headend 1 to an endpoint 4 can be expressed by the Segment-List 668 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 669 to the IPv4 Prefix SIDs bound to node 2, 3 and 4, then IPv6 traffic 670 can be traffic-engineered from nodes 1 to 4 via the previously 671 described path using an SR Policy with Segment-List <16002, 16003, 672 16004, 2> where mpls label value of 2 represents the "IPv6 Explicit 673 NULL Label". 675 The penultimate node before node 4 will pop 16004 and will forward 676 the frame on its directly connected interface to node 4. 678 The endpoint receives the traffic with top label "2" which indicates 679 that the payload is an IPv6 packet. 681 When steering unlabeled IPv6 BGP destination traffic using an SR 682 policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit 683 Null Label Policy is processed as specified in 684 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 685 "IPv6 Explicit NULL label" is not present as the bottom label, the 686 headend SHOULD automatically impose one. Refer to Section 8 for more 687 details. 689 5. Validity of a Candidate Path 691 5.1. Explicit Candidate Path 693 An explicit candidate path is associated with a Segment-List or a set 694 of Segment-Lists. 696 An explicit candidate path is provisioned by the operator directly or 697 via a controller. 699 The computation/logic that leads to the choice of the Segment-List is 700 external to the SR Policy headend. The SR Policy headend does not 701 compute the Segment-List. The SR Policy headend only confirms its 702 validity. 704 An explicit candidate path MAY consist of a single explicit Segment- 705 List containing only an implicit-null label to indicate pop-and- 706 forward behavior. The BSID is popped and the traffic is forwarded 707 based on the inner label or an IP lookup in the case of unlabeled IP 708 packets. Such an explicit path can serve as a fallback or path of 709 last resort for traffic being steered into an SR Policy using its 710 BSID (refer to Section 8.3). 712 A Segment-List of an explicit candidate path MUST be declared invalid 713 when: 715 o It is empty. 716 o Its weight is 0. 717 o The headend is unable to perform path resolution for the first SID 718 into one or more outgoing interface(s) and next-hop(s). 720 o The headend is unable to perform SID resolution for any non-first 721 SID of type C-through-L into an MPLS label or an SRv6 SID. 722 o The headend verification fails for any SID for which verification 723 has been explicitly requested. 725 "Unable to perform path resolution" means that the headend has no 726 path to the SID in its SR database. 728 SID verification is performed when the headend is explicitly 729 requested to verify SID(s) by the controller via the signaling 730 protocol used. Implementations MAY provide a local configuration 731 option to enable verification on a global or per policy or per 732 candidate path basis. 734 "Verification fails" for a SID means any of the following: 736 o The headend is unable to find the SID in its SR DB 737 o The headend detects mis-match between the SID value and its 738 context provided for SIDs of type C-through-L in its SR DB. 739 o The headend is unable to perform SID resolution for any non-first 740 SID of type C-through-L into an MPLS label or an SRv6 SID. 742 In multi-domain deployments, it is expected that the headend be 743 unable to verify the reachability of the SIDs in remote domains. 744 Types A or B MUST be used for the SIDs for which the reachability 745 cannot be verified. Note that the first SID MUST always be reachable 746 regardless of its type. 748 In addition, a Segment-List MAY be declared invalid when: 750 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 751 advertised by the node specified as the endpoint of the 752 corresponding SR policy. 753 o Its last segment is not an Adjacency SID (including BGP Peer 754 Adjacency SID) of any of the links present on neighbor nodes and 755 that terminate on the node specified as the endpoint of the 756 corresponding SR policy. 758 An explicit candidate path is invalid as soon as it has no valid 759 Segment-List. 761 5.2. Dynamic Candidate Path 763 A dynamic candidate path is specified as an optimization objective 764 and constraints. 766 The headend of the policy leverages its SR database to compute a 767 Segment-List ("solution Segment-List") that solves this optimization 768 problem. 770 The headend re-computes the solution Segment-List any time the inputs 771 to the problem change (e.g., topology changes). 773 When local computation is not possible (e.g., a policy's tailend is 774 outside the topology known to the headend) or not desired, the 775 headend MAY send path computation request to a PCE supporting PCEP 776 extension specified in [RFC8664]. 778 If no solution is found to the optimization objective and 779 constraints, then the dynamic candidate path MUST be declared 780 invalid. 782 [I-D.filsfils-spring-sr-policy-considerations] discusses some of the 783 optimization objectives and constraints that may be considered by a 784 dynamic candidate path. It illustrates some of the desirable 785 properties of the computation of the solution Segment-List. 787 6. Binding SID 789 The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 790 It provides scaling, network opacity and service independence. 791 [I-D.filsfils-spring-sr-policy-considerations] illustrates some of 792 these benefits. This section describes the association of BSID with 793 an SR Policy. 795 6.1. BSID of a candidate path 797 Each candidate path MAY be defined with a BSID. 799 Candidate Paths of the same SR policy SHOULD have the same BSID. 801 Candidate Paths of different SR policies MUST NOT have the same BSID. 803 6.2. BSID of an SR Policy 805 The BSID of an SR Policy is the BSID of its active candidate path. 807 When the active candidate path has a specified BSID, the SR Policy 808 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 809 available (i.e., not associated with any other usage: e.g. to another 810 MPLS client, to another SID, to another SR Policy). 812 Optionally, instead of only checking that the BSID of the active path 813 is available, a headend MAY check that it is available within a given 814 SID range i.e., Segment Routing Local Block (SRLB) as specified in 815 [RFC8402]. 817 When the specified BSID is not available (optionally is not in the 818 SRLB), an alert message MUST be generated. 820 In the cases (as described above) where SR Policy does not have a 821 BSID available, then the SR Policy MAY dynamically bind a BSID to 822 itself. Dynamically bound BSID SHOULD use an available SID outside 823 the SRLB. 825 Assuming that at time t the BSID of the SR Policy is B1, if at time 826 t+dt a different candidate path becomes active and this new active 827 path does not have a specified BSID or its BSID is specified but is 828 not available (e.g. it is in use by something else), then the SR 829 Policy keeps the previous BSID B1. 831 The association of an SR Policy with a BSID thus MAY change over the 832 life of the SR Policy (e.g., upon active path change). Hence, the 833 BSID SHOULD NOT be used as an identification of an SR Policy. 835 6.2.1. Frequent use-case : unspecified BSID 837 All the candidate paths of the same SR Policy can have an unspecified 838 BSID. 840 In such a case, a BSID MAY be dynamically bound to the SR Policy as 841 soon as the first valid candidate path is received. That BSID is 842 kept along all the life of the SR Policy and across changes of active 843 candidate path. 845 6.2.2. Frequent use-case: all specified to the same BSID 847 All the paths of the SR Policy can have the same specified BSID. 849 6.2.3. Specified-BSID-only 851 An implementation MAY support the configuration of the Specified- 852 BSID-only restrictive behavior on the headend for all SR Policies or 853 individual SR Policies. Further, this restrictive behavior MAY also 854 be signaled on a per SR Policy basis to the headend. 856 When this restrictive behavior is enabled, if the candidate path has 857 an unspecified BSID or if the specified BSID is not available when 858 the candidate path becomes active then no BSID is bound to it and it 859 is considered invalid. An alert MUST be triggered for this error. 860 Other candidate paths MUST then be evaluated for becoming the active 861 candidate path. 863 6.3. Forwarding Plane 865 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 866 with the action of steering the packets matching this entry to the 867 selected path of the SR Policy. 869 If the Specified-BSID-only restrictive behavior is enabled and the 870 BSID of the active path is not available (optionally not in the 871 SRLB), then the SR Policy does not install any entry indexed by a 872 BSID in the forwarding plane. 874 6.4. Non-SR usage of Binding SID 876 An implementation MAY choose to associate a Binding SID with any type 877 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 878 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 879 tunnel, etc). This enables the use of other non-SR enabled 880 interfaces and tunnels as segments in an SR Policy Segment-List 881 without the need of forming routing protocol adjacencies over them. 883 The details of this kind of usage are beyond the scope of this 884 document. A specific packet optical integration use case is 885 described in [I-D.anand-spring-poi-sr]. 887 7. SR Policy State 889 The SR Policy State is maintained on the headend to represent the 890 state of the policy and its candidate paths. This is to provide an 891 accurate representation of whether the SR Policy is being 892 instantiated in the forwarding plane and which of its candidate paths 893 and segment-list(s) are active. The SR Policy state MUST also 894 reflect the reason when a policy and/or its candidate path is not 895 active due to validation errors or not being preferred. 897 The SR Policy state can be reported by the headend node via BGP-LS 898 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 899 [I-D.ietf-pce-binding-label-sid]. 901 SR Policy state on the headend also includes traffic accounting 902 information for the flows being steered via the policies. The 903 details of the SR Policy accounting are beyond the scope of this 904 document. The aspects related to the SR traffic counters and their 905 usage in the broader context of traffic accounting in a SR network 906 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 907 [I-D.ali-spring-sr-traffic-accounting] respectively. 909 Implementations MAY support an administrative state to control 910 locally provisioned policies via mechanisms like CLI or NETCONF. 912 8. Steering into an SR Policy 914 A headend can steer a packet flow into a valid SR Policy in various 915 ways: 917 o Incoming packets have an active SID matching a local BSID at the 918 headend. 919 o Per-destination Steering: incoming packets match a BGP/Service 920 route which recurses on an SR policy. 921 o Per-flow Steering: incoming packets match or recurse on a 922 forwarding array of where some of the entries are SR Policies. 923 o Policy-based Steering: incoming packets match a routing policy 924 which directs them on an SR policy. 926 For simplicity of illustration, this document uses the SR-MPLS 927 example. 929 8.1. Validity of an SR Policy 931 An SR Policy is invalid when all its candidate paths are invalid as 932 described in Section 5 and Section 2.10. 934 By default, upon transitioning to the invalid state, 936 o an SR Policy and its BSID are removed from the forwarding plane. 937 o any steering of a service (PW), destination (BGP-VPN), flow or 938 packet on the related SR policy is disabled and the related 939 service, destination, flow or packet is routed per the classic 940 forwarding table (e.g. longest-match to the destination or the 941 recursing next-hop). 943 8.2. Drop upon invalid SR Policy 945 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 947 o an invalid SR Policy and its BSID is kept in the forwarding plane 948 with an action to drop. 949 o any steering of a service (PW), destination (BGP-VPN), flow or 950 packet on the related SR policy is maintained with the action to 951 drop all of this traffic. 953 The drop-upon-invalid behavior has been deployed in use-cases where 954 the operator wants some PW to only be transported on a path with 955 specific constraints. When these constraints are no longer met, the 956 operator wants the PW traffic to be dropped. Specifically, the 957 operator does not want the PW to be routed according to the IGP 958 shortest-path to the PW endpoint. 960 8.3. Incoming Active SID is a BSID 962 Let us assume that headend H has a valid SR Policy P of Segment-List 963 and BSID B. 965 When H receives a packet K with label stack , H pops B and 966 pushes and forwards the resulting packet according to 967 SID S1. 969 "Forwarding the resulting packet according to S1" means: If S1 is 970 an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H 971 sends the resulting packet with label stack on 972 the outgoing interface associated with S1; Else H sends the 973 resulting packet with label stack along the 974 path of S1. 976 H has steered the packet into the SR policy P. 978 H did not have to classify the packet. The classification was done 979 by a node upstream of H (e.g., the source of the packet or an 980 intermediate ingress edge node of the SR domain) and the result of 981 this classification was efficiently encoded in the packet header as a 982 BSID. 984 This is another key benefit of the segment routing in general and the 985 binding SID in particular: the ability to encode a classification and 986 the resulting steering in the packet header to better scale and 987 simplify intermediate aggregation nodes. 989 If the SR Policy P is invalid, the BSID B is not in the forwarding 990 plane and hence the packet K is dropped by H. 992 8.4. Per-Destination Steering 994 Let us assume that headend H: 996 o learns a BGP route R/r via next-hop N, extended-color community C 997 and VPN label V. 998 o has a valid SR Policy P to (color = C, endpoint = N) of Segment- 999 List and BSID B. 1000 o has a BGP policy which matches on the extended-color community C 1001 and allows its usage as SLA steering information. 1003 If all these conditions are met, H installs R/r in RIB/FIB with next- 1004 hop = SR Policy P of BSID B instead of via N. 1006 Indeed, H's local BGP policy and the received BGP route indicate that 1007 the headend should associate R/r with an SR Policy path to endpoint N 1008 with the SLA associated with color C. The headend therefore installs 1009 the BGP route on that policy. 1011 This can be implemented by using the BSID as a generalized next-hop 1012 and installing the BGP route on that generalized next-hop. 1014 When H receives a packet K with a destination matching R/r, H pushes 1015 the label stack and sends the resulting packet along 1016 the path to S1. 1018 Note that any SID associated with the BGP route is inserted after the 1019 Segment-List of the SR Policy (i.e., ). 1021 The same behavior is applicable to any type of service route: any 1022 AFI/SAFI of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1024 8.4.1. Multiple Colors 1026 When a BGP route has multiple extended-color communities each with a 1027 valid SR Policy NLRI, the BGP process installs the route on the SR 1028 policy whose color is of highest numerical value. 1030 Let us assume that headend H: 1032 o learns a BGP route R/r via next-hop N, extended-color communities 1033 C1 and C2 and VPN label V. 1034 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1035 List and BSID B1. 1036 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1037 List and BSID B2. 1038 o has a BGP policy which matches on the extended-color communities 1039 C1 and C2 and allows their usage as SLA steering information 1041 If all these conditions are met, H installs R/r in RIB/FIB with next- 1042 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1044 8.5. Recursion on an on-demand dynamic BSID 1046 In the previous section, it was assumed that H had a pre-established 1047 "explicit" SR Policy (color C, endpoint N). 1049 In this section, independently to the a-priori existence of any 1050 explicit candidate path of the SR policy (C, N), it is to be noted 1051 that the BGP process at headend node H triggers the instantiation of 1052 a dynamic candidate path for the SR policy (C, N) as soon as: 1054 o the BGP process learns of a route R/r via N and with color C. 1056 o a local policy at node H authorizes the on-demand SR Policy path 1057 instantiation and maps the color to a dynamic SR Policy path 1058 optimization template. 1060 8.5.1. Multiple Colors 1062 When a BGP route R/r via N has multiple extended-color communities Ci 1063 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1064 request (color Ci, endpoint N) is triggered for each color Ci. 1066 8.6. Per-Flow Steering 1068 Let us assume that headend H: 1070 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1071 List and BSID B1. 1072 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1073 List and BSID B2. 1074 o is configured to instantiate an array of paths to N where the 1075 entry 0 is the IGP path to N, color C1 is the first entry and 1076 Color C2 is the second entry. The index into the array is called 1077 a Forwarding Class (FC). The index can have values 0 to 7. 1078 o is configured to match flows in its ingress interfaces (upon any 1079 field such as Ethernet destination/source/vlan/tos or IP 1080 destination/source/DSCP or transport ports etc.) and color them 1081 with an internal per-packet forwarding-class variable (0, 1 or 2 1082 in this example). 1084 If all these conditions are met, H installs in RIB/FIB: 1086 o N via a recursion on an array A (instead of the immediate outgoing 1087 link associated with the IGP shortest-path to N). 1088 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1089 path to N. 1090 o Entry A(1) set to SR Policy P1 of BSID=B1. 1091 o Entry A(2) set to SR Policy P2 of BSID=B2. 1093 H receives three packets K, K1 and K2 on its incoming interface. 1094 These three packets either longest-match on N or more likely on a 1095 BGP/service route which recurses on N. H colors these 3 packets 1096 respectively with forwarding-class 0, 1 and 2. As a result: 1098 o H forwards K along the shortest-path to N (which in SR-MPLS 1099 results in the pushing of the prefix-SID of N). 1100 o H pushes on packet K1 and forwards the resulting 1101 frame along the shortest-path to S1. 1102 o H pushes on packet K2 and forwards the resulting 1103 frame along the shortest-path to S4. 1105 If the local configuration does not specify any explicit forwarding 1106 information for an entry of the array, then this entry is filled with 1107 the same information as entry 0 (i.e. the IGP shortest-path). 1109 If the SR Policy mapped to an entry of the array becomes invalid, 1110 then this entry is filled with the same information as entry 0. When 1111 all the array entries have the same information as entry0, the 1112 forwarding entry for N is updated to bypass the array and point 1113 directly to its outgoing interface and next-hop. 1115 The array index values (e.g. 0, 1 and 2) and the notion of 1116 forwarding-class are implementation specific and only meant to 1117 describe the desired behavior. The same can be realized by other 1118 mechanisms. 1120 This realizes per-flow steering: different flows bound to the same 1121 BGP endpoint are steered on different IGP or SR Policy paths. 1123 A headend MAY support options to apply per-flow steering only for 1124 traffic matching specific prefixes (e.g. specific IGP or BGP 1125 prefixes). 1127 8.7. Policy-based Routing 1129 Finally, headend H may be configured with a local routing policy 1130 which overrides any BGP/IGP path and steer a specified packet on an 1131 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1132 automatic routing of IGP prefixes over SR Policies intended for such 1133 purpose. 1135 8.8. Optional Steering Modes for BGP Destinations 1137 8.8.1. Color-Only BGP Destination Steering 1139 In the previous section, it is seen that the steering on an SR Policy 1140 is governed by the matching of the BGP route's next-hop N and the 1141 authorized color C with an SR Policy defined by the tuple (N, C). 1143 This is the most likely form of BGP destination steering and the one 1144 recommended for most use-cases. 1146 This section defines an alternative steering mechanism based only on 1147 the color. 1149 This color-only steering variation is governed by two new flags "C" 1150 and "O" defined in the color extended community [ref draft-ietf-idr- 1151 segment-routing-te-policy section 3]. 1153 The Color-Only flags "CO" are set to 00 by default. 1155 When 00, the BGP destination is steered as follows: 1157 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1159 endpoint address and C is a color; 1160 Steer into SR Policy (N, C); 1161 ELSE; 1162 Steer on the IGP path to the next-hop N. 1164 This is the classic case described in this document previously and 1165 what is recommended in most scenarios. 1167 When 01, the BGP destination is steered as follows: 1169 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1171 endpoint address and C is a color; 1172 Steer into SR Policy (N, C); 1173 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1174 same address-family of N; 1175 Steer into SR Policy (null endpoint, C); 1176 ELSE IF there is any valid SR Policy 1177 (any address-family null endpoint, C); 1178 Steer into SR Policy (any null endpoint, C); 1179 ELSE; 1180 Steer on the IGP path to the next-hop N. 1182 When 10, the BGP destination is steered as follows: 1184 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1185 endpoint address and C is a color; 1186 Steer into SR Policy (N, C); 1187 ELSE IF there is a valid SR Policy (null endpoint, C) 1188 of the same address-family of N; 1189 Steer into SR Policy (null endpoint, C); 1190 ELSE IF there is any valid SR Policy 1191 (any address-family null endpoint, C); 1192 Steer into SR Policy (any null endpoint, C); 1193 ELSE IF there is any valid SR Policy (any endpoint, C) 1194 of the same address-family of N; 1195 Steer into SR Policy (any endpoint, C); 1196 ELSE IF there is any valid SR Policy 1197 (any address-family endpoint, C); 1198 Steer into SR Policy (any address-family endpoint, C); 1199 ELSE; 1200 Steer on the IGP path to the next-hop N. 1202 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1203 to the 0 value). 1205 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1206 reception, an implementations MUST treat it like 00. 1208 8.8.2. Multiple Colors and CO flags 1210 The steering preference is first based on highest color value and 1211 then CO-dependent for the color. Assuming a Prefix via (NH, 1212 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1214 o SR policy (NH, C1). 1215 o SR policy (null, C1). 1216 o SR policy (NH, C2). 1217 o SR policy (null, C2). 1218 o IGP to NH. 1220 8.8.3. Drop upon Invalid 1222 This document defined earlier that when all the following conditions 1223 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1224 BSID B instead of via N. 1226 o H learns a BGP route R/r via next-hop N, extended-color community 1227 C and VPN label V. 1228 o H has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1229 List and BSID B. 1230 o H has a BGP policy which matches on the extended-color community C 1231 and allows its usage as SLA steering information. 1233 This behavior is extended by noting that the BGP policy may require 1234 the BGP steering to always stay on the SR policy whatever its 1235 validity. 1237 This is the "drop upon invalid" option described in Section 8.2 1238 applied to BGP-based steering. 1240 9. Protection 1242 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1244 In any topology, Topology-Independent Loop Free Alternate (TI-LFA) 1245 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1246 protection technique for IGP SIDs. The backup path is computed on a 1247 per IGP SID basis along the post-convergence path. 1249 In a network that has deployed TI-LFA, an SR Policy built on the 1250 basis of TI-LFA protected IGP segments leverages the local protection 1251 of the constituent segments. 1253 In a network that has deployed TI-LFA, an SR Policy instantiated only 1254 with non-protected Adj SIDs does not benefit from any local 1255 protection. 1257 9.2. Using an SR Policy to locally protect a link 1259 1----2-----6----7 1260 | | | | 1261 4----3-----9----8 1263 Figure 1: Local protection using SR Policy 1265 An SR Policy can be instantiated at node 2 to protect the link 2to6. 1266 A typical explicit Segment-List would be <3, 9, 6>. 1268 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1269 3 and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8 and 9 are part 1270 of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 cannot 1271 benefit from TI-LFA automated local protection. The SR Policy with 1272 Segment-List <3, 9, 6> on node 2 can be locally configured to be a 1273 fast-reroute backup path for the link 2to6. 1275 9.3. Using a Candidate Path for Path Protection 1277 An SR Policy allows for multiple candidate paths, of which at any 1278 point in time there is a single active candidate path that is 1279 provisioned in the forwarding plane and used for traffic steering. 1280 However, another (lower preference) candidate path MAY be designated 1281 as the backup for a specific or all (active) candidate path(s). The 1282 following options are possible: 1284 o A pair of disjoint candidate paths are provisioned with one of 1285 them as primary and the other is identified as its backup. 1286 o A specific candidate path is provisioned as the backup for any 1287 (active) candidate path. 1288 o The headend picks the next (lower) preference valid candidate path 1289 as the backup for the active candidate path. 1291 The headend MAY compute a-priori and validate such backup candidate 1292 paths as well as provision them into forwarding plane as backup for 1293 the active path. A fast re-route mechanism MAY then be used to 1294 trigger sub 50msec switchover from the active to the backup candidate 1295 path in the forwarding plane. Mechanisms like BFD MAY be used for 1296 fast detection of such failures. 1298 10. Security Considerations 1300 This document specifies in detail the SR Policy construct introduced 1301 in [RFC8402] and its instantiation on a router supporting SR along 1302 with descriptions of mechanisms for steering of traffic flows over 1303 it. Therefore, the security considerations of [RFC8402] apply. This 1304 document does not define any new protocol extensions and does not 1305 introduce any further security considerations. 1307 11. IANA Considerations 1309 This document requests IANA to create a new top-level registry called 1310 "Segment Routing Parameters". This registry is being defined to 1311 serve as a top-level registry for keeping all other Segment Routing 1312 sub-registries. 1314 The document also requests creation of a new sub-registry called 1315 "Segment Types" to be defined under the top-level "Segment Routing 1316 Parameters" registry. This sub-registry maintains the alphabetic 1317 identifiers for the segment types (as specified in section 4) that 1318 may be used within a Segment List of an SR Policy. This sub-registry 1319 would follow the Specification Required allocation policy as 1320 specified in [RFC8126]. 1322 The initial registrations for this sub-registry are as follows: 1324 +-------+-----------------------------------------------+-----------+ 1325 | Value | Description | Reference | 1326 +-------+-----------------------------------------------+-----------+ 1327 | A | SR-MPLS Label | [This.ID] | 1328 | B | SRv6 SID | [This.ID] | 1329 | C | IPv4 Prefix with optional SR Algorithm | [This.ID] | 1330 | D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1331 | | for SR-MPLS | | 1332 | E | IPv4 Prefix with Local Interface ID | [This.ID] | 1333 | F | IPv4 Addresses for link endpoints as Local, | [This.ID] | 1334 | | Remote pair | | 1335 | G | IPv6 Prefix and Interface ID for link | [This.ID] | 1336 | | endpoints as Local, Remote pair for SR-MPLS | | 1337 | H | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1338 | | Remote pair for SR-MPLS | | 1339 | I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1340 | | for SRv6 | | 1341 | J | IPv6 Prefix and Interface ID for link | [This.ID] | 1342 | | endpoints as Local, Remote pair for SRv6 | | 1343 | K | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1344 | | Remote pair for SRv6 | | 1345 | L | SRv6 SID with Behavior | [This.ID] | 1346 +-------+-----------------------------------------------+-----------+ 1348 Table 2: Initial IANA Registration 1350 11.1. Guidance for Designated Experts 1352 The Designated Expert (DE) is expected to ascertain the existence of 1353 suitable documentation (a specification) as described in [RFC8126] 1354 and to verify that the document is permanently and publicly 1355 available. The DE is also expected to check the clarity of purpose 1356 and use of the requested assignment. Additionally, the DE must 1357 verify that any request for one of these assignments has been made 1358 available for review and comment within the IETF: the DE will post 1359 the request to the SPRING Working Group mailing list (or a successor 1360 mailing list designated by the IESG). If the request comes from 1361 within the IETF, it should be documented in an Internet-Draft. 1362 Lastly, the DE must ensure that any other request for a code point 1363 does not conflict with work that is active or already published 1364 within the IETF. 1366 12. Acknowledgement 1368 The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger 1369 Geib, Rob Shakir, Cheng Li and Dhruv Dhody for their review comments 1370 and suggestions. 1372 13. Contributors 1374 The following people have contributed to this document: 1376 Siva Sivabalan 1377 Cisco Systems 1378 Email: msiva@cisco.com 1380 Zafar Ali 1381 Cisco Systems 1382 Email: zali@cisco.com 1384 Jose Liste 1385 Cisco Systems 1386 Email: jliste@cisco.com 1388 Francois Clad 1389 Cisco Systems 1390 Email: fclad@cisco.com 1392 Kamran Raza 1393 Cisco Systems 1394 Email: skraza@cisco.com 1396 Mike Koldychev 1397 Cisco Systems 1398 Email: mkoldych@cisco.com 1400 Shraddha Hegde 1401 Juniper Networks 1402 Email: shraddha@juniper.net 1404 Steven Lin 1405 Google, Inc. 1406 Email: stevenlin@google.com 1408 Przemyslaw Krol 1409 Google, Inc. 1410 Email: pkrol@google.com 1412 Martin Horneffer 1413 Deutsche Telekom 1414 Email: martin.horneffer@telekom.de 1416 Dirk Steinberg 1417 Steinberg Consulting 1418 Email: dws@steinbergnet.net 1419 Bruno Decraene 1420 Orange Business Services 1421 Email: bruno.decraene@orange.com 1423 Stephane Litkowski 1424 Orange Business Services 1425 Email: stephane.litkowski@orange.com 1427 Luay Jalil 1428 Verizon 1429 Email: luay.jalil@verizon.com 1431 14. References 1433 14.1. Normative References 1435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1436 Requirement Levels", BCP 14, RFC 2119, 1437 DOI 10.17487/RFC2119, March 1997, 1438 . 1440 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1441 Writing an IANA Considerations Section in RFCs", BCP 26, 1442 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1443 . 1445 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1446 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1447 May 2017, . 1449 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1450 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1451 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1452 July 2018, . 1454 14.2. Informative References 1456 [I-D.ali-spring-sr-traffic-accounting] 1457 Filsfils, C., Talaulikar, K., Sivabalan, S., Horneffer, 1458 M., Raszuk, R., Litkowski, S., Voyer, D., and R. Morton, 1459 "Traffic Accounting in Segment Routing Networks", draft- 1460 ali-spring-sr-traffic-accounting-04 (work in progress), 1461 February 2020. 1463 [I-D.anand-spring-poi-sr] 1464 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1465 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1466 Integration in Segment Routing", draft-anand-spring-poi- 1467 sr-08 (work in progress), July 2019. 1469 [I-D.filsfils-spring-sr-policy-considerations] 1470 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1471 P. Mattes, "SR Policy Implementation and Deployment 1472 Considerations", draft-filsfils-spring-sr-policy- 1473 considerations-05 (work in progress), April 2020. 1475 [I-D.filsfils-spring-sr-traffic-counters] 1476 Filsfils, C., Ali, Z., Horneffer, M., 1477 daniel.voyer@bell.ca, d., Durrani, M., and R. Raszuk, 1478 "Segment Routing Traffic Accounting Counters", draft- 1479 filsfils-spring-sr-traffic-counters-00 (work in progress), 1480 June 2018. 1482 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1483 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 1484 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 1485 using Border Gateway Protocol - Link State", draft-ietf- 1486 idr-bgp-ls-segment-routing-msd-18 (work in progress), May 1487 2020. 1489 [I-D.ietf-idr-bgpls-segment-routing-epe] 1490 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1491 S., and J. Dong, "BGP-LS extensions for Segment Routing 1492 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1493 segment-routing-epe-19 (work in progress), May 2019. 1495 [I-D.ietf-idr-segment-routing-te-policy] 1496 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1497 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 1498 Routing Policies in BGP", draft-ietf-idr-segment-routing- 1499 te-policy-09 (work in progress), May 2020. 1501 [I-D.ietf-idr-te-lsp-distribution] 1502 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1503 H., and J. Tantsura, "Distribution of Traffic Engineering 1504 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1505 lsp-distribution-13 (work in progress), April 2020. 1507 [I-D.ietf-lsr-flex-algo] 1508 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1509 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1510 algo-07 (work in progress), April 2020. 1512 [I-D.ietf-pce-binding-label-sid] 1513 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 1514 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1515 in PCE-based Networks.", draft-ietf-pce-binding-label- 1516 sid-03 (work in progress), June 2020. 1518 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1519 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1520 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1521 "Topology Independent Fast Reroute using Segment Routing", 1522 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 1523 progress), March 2020. 1525 [I-D.ietf-spring-srv6-network-programming] 1526 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1527 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1528 draft-ietf-spring-srv6-network-programming-16 (work in 1529 progress), June 2020. 1531 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1532 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1533 December 1990, . 1535 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1536 DOI 10.17487/RFC2328, April 1998, 1537 . 1539 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1540 (TE) Extensions to OSPF Version 2", RFC 3630, 1541 DOI 10.17487/RFC3630, September 2003, 1542 . 1544 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1545 "Multiprotocol Extensions for BGP-4", RFC 4760, 1546 DOI 10.17487/RFC4760, January 2007, 1547 . 1549 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1550 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1551 2008, . 1553 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1554 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1555 . 1557 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1558 Locator/ID Separation Protocol (LISP)", RFC 6830, 1559 DOI 10.17487/RFC6830, January 2013, 1560 . 1562 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1563 Previdi, "OSPF Traffic Engineering (TE) Metric 1564 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1565 . 1567 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1568 S. Ray, "North-Bound Distribution of Link-State and 1569 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1570 DOI 10.17487/RFC7752, March 2016, 1571 . 1573 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1574 Computation Element Communication Protocol (PCEP) 1575 Extensions for Stateful PCE", RFC 8231, 1576 DOI 10.17487/RFC8231, September 2017, 1577 . 1579 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1580 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1581 DOI 10.17487/RFC8476, December 2018, 1582 . 1584 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1585 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1586 DOI 10.17487/RFC8491, November 2018, 1587 . 1589 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1590 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1591 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1592 2019, . 1594 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1595 and J. Hardwick, "Path Computation Element Communication 1596 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1597 DOI 10.17487/RFC8664, December 2019, 1598 . 1600 Authors' Addresses 1601 Clarence Filsfils 1602 Cisco Systems, Inc. 1603 Pegasus Parc 1604 De kleetlaan 6a, DIEGEM BRABANT 1831 1605 BELGIUM 1607 Email: cfilsfil@cisco.com 1609 Ketan Talaulikar (editor) 1610 Cisco Systems, Inc. 1611 India 1613 Email: ketant@cisco.com 1615 Daniel Voyer 1616 Bell Canada 1617 671 de la gauchetiere W 1618 Montreal, Quebec H3B 2M8 1619 Canada 1621 Email: daniel.voyer@bell.ca 1623 Alex Bogdanov 1624 Google, Inc. 1626 Email: bogdanov@google.com 1628 Paul Mattes 1629 Microsoft 1630 One Microsoft Way 1631 Redmond, WA 98052-6399 1632 USA 1634 Email: pamattes@microsoft.com