idnits 2.17.1 draft-ietf-spring-segment-routing-policy-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2020) is 1449 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) == Unused Reference: 'RFC5226' is defined on line 1428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == 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 (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-17 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 == 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 -- 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) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Filsfils 3 Internet-Draft S. Sivabalan, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: November 8, 2020 D. Voyer 6 Bell Canada 7 A. Bogdanov 8 Google, Inc. 9 P. Mattes 10 Microsoft 11 May 7, 2020 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-07.txt 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 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 8, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 69 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 4 70 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 5 71 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 5 72 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 6 73 2.6. Identification of a Candidate Path . . . . . . . . . . . 7 74 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 7 75 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 7 76 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 8 77 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 9 78 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 9 79 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 9 80 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 10 82 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 11 83 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 14 84 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 15 85 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 15 86 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 16 87 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 17 89 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 17 90 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 19 91 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 19 92 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 19 93 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 20 94 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 20 95 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 20 96 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 21 97 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 21 98 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 22 99 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 23 100 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 24 101 8.8. Optional Steering Modes for BGP Destinations . . . . . . 24 102 9. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 9.1. Leveraging TI-LFA local protection of the constituent IGP 104 segments . . . . . . . . . . . . . . . . . . . . . . . . 26 105 9.2. Using an SR Policy to locally protect a link . . . . . . 27 106 9.3. Using a Candidate Path for Path Protection . . . . . . . 27 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 109 11.1. Guidance for Designated Experts . . . . . . . . . . . . 29 110 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 111 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 112 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 113 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 114 14.2. Informative References . . . . . . . . . . . . . . . . . 31 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 117 1. Introduction 119 Segment Routing (SR) allows a headend node to steer a packet flow 120 along any path. Intermediate per-flow states are eliminated thanks 121 to source routing [RFC8402]. 123 The headend node is said to steer a flow into an Segment Routing 124 Policy (SR Policy). 126 The header of a packet steered into an SR Policy is augmented with an 127 ordered list of segments associated with that SR Policy. 129 This document details the concepts of SR Policy and steering packets 130 into an SR Policy. These apply equally to the MPLS and SRv6 131 instantiations of segment routing. 133 For reading simplicity, the illustrations are provided for the MPLS 134 instantiations. 136 2. SR Policy 138 An SR Policy is a framework that enables instantiation of an ordered 139 list of segments on a node for implementing a source routing policy 140 with a specific intent for traffic steering from that node. 142 The Segment Routing architecture [RFC8402] specifies that any 143 instruction can be bound to a segment. Thus, an SR Policy can be 144 built using any type of Segment Identifier (SID) including those 145 associated with topological or service instructions. 147 This section defines the key aspects and constituents of an SR 148 Policy. 150 2.1. Identification of an SR Policy 152 An SR Policy is identified through the tuple . In the context of a specific headend, one may identify an 154 SR policy by the tuple. 156 The headend is the node where the policy is instantiated/implemented. 157 The headend is specified as an IPv4 or IPv6 address and is expected 158 to be unique in the domain. 160 The endpoint indicates the destination of the policy. The endpoint 161 is specified as an IPv4 or IPv6 address and is expected to be unique 162 in the domain. In a specific case (refer to Section 8.8.1), the 163 endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6). 165 The color is a 32-bit numerical value that associates the SR Policy 166 with an intent (e.g. low-latency). 168 The endpoint and the color are used to automate the steering of 169 service or transport routes on SR Policies (refer to Section 8). 171 An implementation MAY allow assignment of a symbolic name comprising 172 of printable ASCII characters to an SR Policy to serve as a user- 173 friendly attribute for debug and troubleshooting purposes. Such 174 symbolic names may identify an SR Policy when the naming scheme 175 ensures uniqueness. 177 2.2. Candidate Path and Segment List 179 An SR Policy is associated with one or more candidate paths. A 180 candidate path is the unit for signaling of an SR Policy to a headend 181 via protocols like Path Computation Element (PCE) Communication 182 Protocol (PCEP) [RFC8281] or BGP SR Policy 183 [I-D.ietf-idr-segment-routing-te-policy]. 185 A Segment-List represents a specific source-routed path to send 186 traffic from the headend to the endpoint of the corresponding SR 187 policy. 189 A candidate path is either dynamic or explicit. 191 An explicit candidate path is expressed as a Segment-List or a set of 192 Segment-Lists. 194 A dynamic candidate path expresses an optimization objective and a 195 set of constraints. The headend (potentially with the help of a PCE) 196 computes the solution Segment-List (or set of Segment-Lists) that 197 solves the optimization problem. 199 If a candidate path is associated with a set of Segment-Lists, each 200 Segment-List is associated with a weight for weighted load balancing 201 (refer Section 2.11 for details). The default weight is 1. 203 2.3. Protocol-Origin of a Candidate Path 205 A headend may be informed about a candidate path for an SR Policy 206 by various means including: via configuration, PCEP 207 [RFC8281] or BGP [I-D.ietf-idr-segment-routing-te-policy]. 209 Protocol-Origin of a candidate path is an 8-bit value which 210 identifies the component or protocol that originates or signals the 211 candidate path. 213 The head-end assigns different Protocol-Origin Priority values to 214 each Protocol-Origin. The Protocol-Origin Priority is used as a tie- 215 breaker between candidate-paths of equal preference, as described in 216 Section 2.9. The table below specifies the RECOMMENDED default 217 values of Protocol-Origin Priority: 219 +-------+-------------------+ 220 | Value | Protocol-Origin | 221 +-------+-------------------+ 222 | 10 | PCEP | 223 | 20 | BGP SR Policy | 224 | 30 | Via Configuration | 225 +-------+-------------------+ 227 Table 1: Protocol-Origin Priority default values 229 Implementations MAY allow modifications of these default values 230 assigned to protocols on the headend along similar lines as a routing 231 administrative distance. Its application in the candidate path 232 selection is described in Section 2.9. 234 2.4. Originator of a Candidate Path 236 Originator identifies the node which provisioned or signalled the 237 candidate path on the headend. The originator is expressed in the 238 form of a 160 bit numerical value formed by the concatenation of the 239 fields of the tuple as below: 241 o ASN : represented as a 4 byte number. 243 o Node Address : represented as a 128 bit value. IPv4 addresses are 244 encoded in the lowest 32 bits. 246 Its application in the candidate path selection is described in 247 Section 2.9. 249 When Protocol-Origin is Via Configuration, the ASN and node address 250 MAY be set to either the headend or the provisioning controller/node 251 ASN and address. Default value is 0 for both AS and node address. 253 When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the 254 PCE and the AS number SHOULD be set to 0 by default when not 255 available or known. 257 Protocol-Origin is BGP SR Policy, it is provided by the BGP component 258 on the headend and is: 260 o the BGP Router ID and ASN of the node/controller signalling the 261 candidate path when it has a BGP session to the headend, OR 263 o the BGP Router ID of the eBGP peer signalling the candidate path 264 along with ASN of origin when the signalling is done via one or 265 more intermediate eBGP routers, OR 267 o the BGP Originator ID [RFC4456] and the ASN of the node/controller 268 when the signalling is done via one or more route-reflectors over 269 iBGP session. 271 2.5. Discriminator of a Candidate Path 273 The Discriminator is a 32 bit value associated with a candidate path 274 that uniquely identifies it within the context of an SR Policy from a 275 specific Protocol-Origin as specified below: 277 When Protocol-Origin is Via Configuration, this is an 278 implementation's configuration model specific unique identifier for a 279 candidate path. Default value is 0. 281 When PCEP is the Protocol-Origin, the method to uniquely identify 282 signalled path will be specified in a future PCEP document. Default 283 value is 0. 285 When BGP SR Policy is the Protocol-Origin, it is the distinguisher 286 specified in Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]. 288 Its application in the candidate path selection is described in 289 Section 2.9. 291 2.6. Identification of a Candidate Path 293 A candidate path is identified in the context of a single SR Policy. 295 A candidate path is not shared across SR Policies. 297 A candidate path is not identified by its Segment-List(s). 299 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 300 candidate path of SR Policy Pol2, then these two candidate paths 301 are independent, even if they happen to have the same Segment- 302 List. The Segment-List does not identify a candidate path. The 303 Segment-List is an attribute of a candidate path. 305 The identity of a candidate path MUST be uniquely established in the 306 context of an SR Policy in order to handle 307 add, delete or modify operations on them in an unambiguous manner 308 regardless of their source(s). 310 The tuple uniquely 311 identifies a candidate path. 313 Candidate paths MAY also be assigned or signaled with a symbolic name 314 comprising printable ASCII characters to serve as a user-friendly 315 attribute for debug and troubleshooting purposes. Such symbolic 316 names MUST NOT be considered as identifiers for a candidate path. 318 2.7. Preference of a Candidate Path 320 The preference of the candidate path is used to select the best 321 candidate path for an SR Policy. The default preference is 100. 323 It is RECOMMENDED that each candidate path of a given SR policy has a 324 different preference. 326 2.8. Validity of a Candidate Path 328 A candidate path is usable when it valid. A common path validity 329 criterion is the reachability of its constituent SIDs. The 330 validation rules are specified in Section 5. 332 2.9. Active Candidate Path 334 A candidate path is selected when it is valid and it is determined to 335 be the best path of the SR Policy. The selected path is referred to 336 as the "active path" of the SR policy in this document. 338 Whenever a new path is learned or an active path is deleted, the 339 validity of an existing path changes or an existing path is changed, 340 the selection process MUST be re-executed. 342 The candidate path selection process operates on the candidate path 343 Preference. A candidate path is selected when it is valid and it has 344 the highest preference value among all the candidate paths of the SR 345 Policy. 347 In the case of multiple valid candidate paths of the same preference, 348 the tie-breaking rules are evaluated on the identification tuple in 349 the following order until only one valid best path is selected: 351 1. Higher value of Protocol-Origin Priority is selected. 353 2. If specified by configuration, prefer the existing installed 354 path. 356 3. Lower value of originator is selected. 358 4. Finally, the higher value of discriminator is selected. 360 The rules are framed with multiple protocols and sources in mind and 361 hence may not follow the logic of a single protocol (e.g. BGP best 362 path selection). The motivation behind these rules are as follows: 364 o The Protocol-Origin allows an operator to setup a default 365 selection mechanism across protocol sources, e.g., to prefer 366 configured over paths signalled via BGP SR Policy or PCEP. 368 o The preference, being the first tiebreaker, allows an operator to 369 influence selection across paths thus allowing provisioning of 370 multiple path options, e.g., CP1 is preferred and if it becomes 371 invalid then fall-back to CP2 and so on. Since preference works 372 across protocol sources it also enables (where necessary) 373 selective override of the default protocol-origin preference, 374 e.g., to prefer a path signalled via BGP SR Policy over what is 375 configured. 377 o The originator allows an operator to have multiple redundant 378 controllers and still maintain a deterministic behaviour over 379 which of them are preferred even if they are providing the same 380 candidate paths for the same SR policies to the headend. 382 o The discriminator performs the final tiebreaking step to ensure a 383 deterministic outcome of selection regardless of the order in 384 which candidate paths are signalled across multiple transport 385 channels or sessions. 387 [I-D.filsfils-spring-sr-policy-considerations] provides a set of 388 examples to illustrate the active candidate path selection rules. 390 2.10. Validity of an SR Policy 392 An SR Policy is valid when it has at least one valid candidate path. 394 2.11. Instantiation of an SR Policy in the Forwarding Plane 396 A valid SR Policy is instantiated in the forwarding plane. 398 Only the active candidate path SHOULD be used for forwarding traffic 399 that is being steered onto that policy. 401 If a set of Segment-Lists is associated with the active path of the 402 policy, then the steering is per flow and W-ECMP based according to 403 the relative weight of each Segment-List. 405 The fraction of the flows associated with a given Segment-List is w/ 406 Sw where w is the weight of the Segment-List and Sw is the sum of the 407 weights of the Segment-Lists of the selected path of the SR Policy. 409 The accuracy of the weighted load-balancing depends on the platform 410 implementation. 412 2.12. Priority of an SR Policy 414 Upon topological change, many policies could be recomputed or 415 revalidated. An implementation MAY provide a per-policy priority 416 configuration. The operator MAY set this field to indicate order in 417 which the policies should be re-computed. Such a priority is 418 represented by an integer in the range (0, 255) where the lowest 419 value is the highest priority. The default value of priority is 128. 421 An SR Policy may comprise multiple Candidate Paths received from the 422 same or different sources. A candidate path MAY be signaled with a 423 priority value. When an SR Policy has multiple candidate paths with 424 distinct signaled non-default priority values, the SR Policy as a 425 whole takes the lowest value (i.e. the highest priority) amongst 426 these signaled priority values. 428 2.13. Summary 430 In summary, the information model is the following: 432 SR policy POL1 433 Candidate-path CP1 435 Preference 200 436 Weight W1, SID-List1 437 Weight W2, SID-List2 438 Candidate-path CP2 440 Preference 100 441 Weight W3, SID-List3 442 Weight W4, SID-List4 444 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 446 identified by a tuple . 447 CP1 is the active candidate path (it is valid and it has the highest 448 preference). The two Segment-Lists of CP1 are installed as the 449 forwarding instantiation of SR policy Pol1. Traffic steered on Pol1 450 is flow-based hashed on Segment-List with a ratio 451 W1/(W1+W2). 453 3. Segment Routing Database 455 An SR headend maintains the Segment Routing Database (SR-DB). The 456 SR-DB is a conceptual database to illustrate the various pieces of 457 information and their sources that may help in SR Policy computation 458 and validation. There is no specific requirement for an 459 implementation to create a new database as such. 461 An SR headend leverages the SR-DB to validate explicit candidate 462 paths and compute dynamic candidate paths. 464 The information in the SR-DB MAY include: 466 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 467 OSPF [RFC2328] [RFC5340]) 468 o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj- 469 SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402] 470 [I-D.ietf-idr-bgpls-segment-routing-epe] 471 [I-D.filsfils-spring-srv6-network-programming] 472 o TE Link Attributes (such as TE metric, SRLG, attribute-flag, 473 extended admin group) [RFC5305] [RFC3630]. 474 o Extended TE Link attributes (such as latency, loss) [RFC7810] 475 [RFC7471] 477 o Inter-AS Topology information 478 [I-D.ietf-idr-bgpls-segment-routing-epe]. 480 The attached domain topology MAY be learned via IGP, BGP-LS or 481 NETCONF. 483 A non-attached (remote) domain topology MAY be learned via BGP-LS or 484 NETCONF. 486 In some use-cases, the SR-DB may only contain the attached domain 487 topology while in others, the SR-DB may contain the topology of 488 multiple domains and in this case it is multi-domain capable. 490 The SR-DB MAY also contain the SR Policies instantiated in the 491 network. This can be collected via BGP-LS 492 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 493 [I-D.sivabalan-pce-binding-label-sid]. This information allows to 494 build an end-to-end policy on the basis of intermediate SR policies 495 (see Section 6 for further details). 497 The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of 498 nodes in the topology. This can be collected via ISIS 499 [I-D.ietf-isis-segment-routing-msd], OSPF 500 [I-D.ietf-ospf-segment-routing-msd], BGP-LS 501 [I-D.ietf-idr-bgp-ls-segment-routing-msd] or PCEP 502 [I-D.ietf-pce-segment-routing]. 504 The use of the SR-DB for computation and validation of SR Policies is 505 outside the scope of this document. Some implementation aspects 506 related to this are covered in 507 [I-D.filsfils-spring-sr-policy-considerations]. 509 4. Segment Types 511 A Segment-List is an ordered set of segments represented as where S1 is the first segment. 514 Based on the desired dataplane, either the MPLS label stack or the 515 SRv6 SRH is built from the Segment-List. However, the Segment-List 516 itself can be specified using different segment-descriptor types and 517 the following are currently defined: 519 Type A: SR-MPLS Label: 520 A MPLS label corresponding to any of the segment types defined 521 for SR-MPLS (as defined in [RFC8402] or other SR-MPLS 522 specifications) can be used. Additionally, reserved labels 523 like explicit-null or in general any MPLS label may also be 524 used. E.g. this type can be used to specify a label 525 representation which maps to an optical transport path on a 526 packet transport node. This type does not require the headend 527 to perform SID resolution. 529 Type B: SRv6 SID: 530 An IPv6 address corresponding to any of the segment types 531 defined for SRv6 (as defined in 532 [I-D.filsfils-spring-srv6-network-programming] or other SRv6 533 specifications) can be used. This type does not require the 534 headend to perform SID resolution. 536 Type C: IPv4 Prefix with optional SR Algorithm: 537 The headend is required to resolve the specified IPv4 Prefix 538 Address to the SR-MPLS label corresponding to a Prefix SID 539 segment (as defined in [RFC8402]). The SR algorithm (refer to 540 Section 3.1.1 of [RFC8402]) to be used MAY also be provided. 542 Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 543 In this case the headend is required to resolve the specified 544 IPv6 Global Prefix Address to the SR-MPLS label corresponding 545 to its Prefix SID segment (as defined in [RFC8402]). The SR 546 Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY 547 also be provided. 549 Type E: IPv4 Prefix with Local Interface ID: 550 This type allows identification of Adjacency SID (as defined in 551 [RFC8402]) or BGP EPE Peering SID (as defined in 552 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for point-to- 553 point links including IP unnumbered links. The headend is 554 required to resolve the specified IPv4 Prefix Address to the 555 Node originating it and then use the Local Interface ID to 556 identify the point-to-point link whose adjacency is being 557 referred to. The Local Interface ID link descriptor follows 558 semantics as specified in [RFC7752]. This type can also be 559 used to indicate indirection into a layer 2 interface (i.e. 560 without IP address) like a representation of an optical 561 transport path or a layer 2 Ethernet port or circuit at the 562 specified node. 564 Type F: IPv4 Addresses for link endpoints as Local, Remote pair: 565 This type allows identification of Adjacency SID (as defined in 566 [RFC8402]) or BGP EPE Peering SID (as defined in 567 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for links. The 568 headend is required to resolve the specified IPv4 Local Address 569 to the Node originating it and then use the IPv4 Remote Address 570 to identify the link adjacency being referred to. The Local 571 and Remote Address pair link descriptors follows semantics as 572 specified in [RFC7752]. 574 Type G: IPv6 Prefix and Interface ID for link endpoints as Local, 575 Remote pair for SR-MPLS: 576 This type allows identification of Adjacency SID (as defined in 577 [RFC8402]) or BGP EPE Peering SID (as defined in 578 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for links 579 including those with only Link Local IPv6 addresses. The 580 headend is required to resolve the specified IPv6 Prefix 581 Address to the Node originating it and then use the Local 582 Interface ID to identify the point-to-point link whose 583 adjacency is being referred to. For other than point-to-point 584 links, additionally the specific adjacency over the link needs 585 to be resolved using the Remote Prefix and Interface ID. The 586 Local and Remote pair of Prefix and Interface ID link 587 descriptor follows semantics as specified in [RFC7752]. This 588 type can also be used to indicate indirection into a layer 2 589 interface (i.e. without IP address) like a representation of an 590 optical transport path or a layer 2 Ethernet port or circuit at 591 the specified node. 593 Type H: IPv6 Addresses for link endpoints as Local, Remote pair for 594 SR-MPLS: 595 This type allows identification of Adjacency SID (as defined in 596 [RFC8402]) or BGP EPE Peering SID (as defined in 597 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for links with 598 Global IPv6 addresses. The headend is required to resolve the 599 specified Local IPv6 Address to the Node originating it and 600 then use the Remote IPv6 Address to identify the link adjacency 601 being referred to. The Local and Remote Address pair link 602 descriptors follows semantics as specified in [RFC7752]. 604 Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: 605 The headend is required to resolve the specified IPv6 Global 606 Prefix Address to the SRv6 END function SID (as defined in 607 [I-D.filsfils-spring-srv6-network-programming]) corresponding 608 to the node which is originating the prefix. The SR Algorithm 609 (refer to Section 3.1.1 of [RFC8402]) to be used MAY also be 610 provided. 612 Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 613 Remote pair for SRv6: 614 This type allows identification of SRv6 END.X SID (as defined 615 in [I-D.filsfils-spring-srv6-network-programming]) for links 616 with only Link Local IPv6 addresses. The headend is required 617 to resolve the specified IPv6 Prefix Address to the Node 618 originating it and then use the Local Interface ID to identify 619 the point-to-point link whose adjacency is being referred to. 620 For other than point-to-point links, additionally the specific 621 adjacency needs to be resolved using the Remote Prefix and 622 Interface ID. The Local and Remote pair of Prefix and 623 Interface ID link descriptor follows semantics as specified in 624 [RFC7752]. 626 Type K: IPv6 Addresses for link endpoints as Local, Remote pair for 627 SRv6: 628 This type allows identification of SRv6 END.X SID (as defined 629 in [I-D.filsfils-spring-srv6-network-programming]) for links 630 with Global IPv6 addresses. The headend is required to resolve 631 the specified Local IPv6 Address to the Node originating it and 632 then use the Remote IPv6 Address to identify the link adjacency 633 being referred to. The Local and Remote Address pair link 634 descriptors follows semantics as specified in [RFC7752]. 636 When the algorithm is not specified for the SID types above which 637 optionally allow for it, the headend SHOULD use the Strict Shortest 638 Path algorithm if available; otherwise it SHOULD use the default 639 Shortest Path algorithm. The specification of algorithm enables the 640 use of IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in 641 SR Policy. 643 For SID types C-through-K, a SID value may also be optionally 644 provided to the headend for verification purposes. Section 5.1. 645 describes the resolution and verification of the SIDs and Segment 646 Lists on the headend. 648 When building the MPLS label stack or the IPv6 Segment list from the 649 Segment List, the node instantiating the policy MUST interpret the 650 set of Segments as follows: 652 o The first Segment represents the topmost label or the first IPv6 653 segment. It identifies the active segment the traffic will be 654 directed toward along the explicit SR path. 655 o The last Segment represents the bottommost label or the last IPv6 656 segment the traffic will be directed toward along the explicit SR 657 path. 659 4.1. Explicit Null 661 A Type A SID may be any MPLS label, including reserved labels. 663 For example, assuming that the desired traffic-engineered path from a 664 headend 1 to an endpoint 4 can be expressed by the Segment-List 665 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 666 to the IPv4 Prefix SIDs bound to node 2, 3 and 4, then IPv6 traffic 667 can be traffic-engineered from nodes 1 to 4 via the previously 668 described path using an SR Policy with Segment-List <16002, 16003, 669 16004, 2> where mpls label value of 2 represents the "IPv6 Explicit 670 NULL Label". 672 The penultimate node before node 4 will pop 16004 and will forward 673 the frame on its directly connected interface to node 4. 675 The endpoint receives the traffic with top label "2" which indicates 676 that the payload is an IPv6 packet. 678 When steering unlabeled IPv6 BGP destination traffic using an SR 679 policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit 680 Null Label Policy is processed as specified in 681 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 682 "IPv6 Explicit NULL label" is not present as the bottom label, the 683 headend SHOULD automatically impose one. Refer to Section 8 for more 684 details. 686 5. Validity of a Candidate Path 688 5.1. Explicit Candidate Path 690 An explicit candidate path is associated with a Segment-List or a set 691 of Segment-Lists. 693 An explicit candidate path is provisioned by the operator directly or 694 via a controller. 696 The computation/logic that leads to the choice of the Segment-List is 697 external to the SR Policy headend. The SR Policy headend does not 698 compute the Segment-List. The SR Policy headend only confirms its 699 validity. 701 An explicit candidate path MAY consist of a single explicit Segment- 702 List containing only an implicit-null label to indicate pop-and- 703 forward behavior. The BSID is popped and the traffic is forwarded 704 based on the inner label or an IP lookup in the case of unlabeled IP 705 packets. Such an explicit path can serve as a fallback or path of 706 last resort for traffic being steered into an SR Policy using its 707 BSID (refer to Section 8.3). 709 A Segment-List of an explicit candidate path MUST be declared invalid 710 when: 712 o It is empty. 713 o Its weight is 0. 714 o The headend is unable to perform path resolution for the first SID 715 into one or more outgoing interface(s) and next-hop(s). 717 o The headend is unable to perform SID resolution for any non-first 718 SID of type C-through-K into an MPLS label or an SRv6 SID. 719 o The headend verification fails for any SID for which verification 720 has been explicitly requested. 722 "Unable to perform path resolution" means that the headend has no 723 path to the SID in its SR database. 725 SID verification is performed when the headend is explicitly 726 requested to verify SID(s) by the controller via the signaling 727 protocol used. Implementations MAY provide a local configuration 728 option to enable verification on a global or per policy or per 729 candidate path basis. 731 "Verification fails" for a SID means any of the following: 733 o The headend is unable to find the SID in its SR DB 734 o The headend detects mis-match between the SID value and its 735 context provided for SIDs of type C-through-K in its SR DB. 736 o The headend is unable to perform SID resolution for any non-first 737 SID of type C-through-K into an MPLS label or an SRv6 SID. 739 In multi-domain deployments, it is expected that the headend be 740 unable to verify the reachability of the SIDs in remote domains. 741 Types A or B MUST be used for the SIDs for which the reachability 742 cannot be verified. Note that the first SID MUST always be reachable 743 regardless of its type. 745 In addition, a Segment-List MAY be declared invalid when: 747 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 748 advertised by the node specified as the endpoint of the 749 corresponding SR policy. 750 o Its last segment is not an Adjacency SID (including BGP Peer 751 Adjacency SID) of any of the links present on neighbor nodes and 752 that terminate on the node specified as the endpoint of the 753 corresponding SR policy. 755 An explicit candidate path is invalid as soon as it has no valid 756 Segment-List. 758 5.2. Dynamic Candidate Path 760 A dynamic candidate path is specified as an optimization objective 761 and constraints. 763 The headend of the policy leverages its SR database to compute a 764 Segment-List ("solution Segment-List") that solves this optimization 765 problem. 767 The headend re-computes the solution Segment-List any time the inputs 768 to the problem change (e.g., topology changes). 770 When local computation is not possible (e.g., a policy's tailend is 771 outside the topology known to the headend) or not desired, the 772 headend MAY send path computation request to a PCE supporting PCEP 773 extension specified in [I-D.ietf-pce-segment-routing]. 775 If no solution is found to the optimization objective and 776 constraints, then the dynamic candidate path MUST be declared 777 invalid. 779 [I-D.filsfils-spring-sr-policy-considerations] discusses some of the 780 optimization objectives and constraints that may be considered by a 781 dynamic candidate path. It illustrates some of the desirable 782 properties of the computation of the solution Segment-List. 784 6. Binding SID 786 The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 787 It provides scaling, network opacity and service independence. 788 [I-D.filsfils-spring-sr-policy-considerations] illustrates some of 789 these benefits. This section describes the association of BSID with 790 an SR Policy. 792 6.1. BSID of a candidate path 794 Each candidate path MAY be defined with a BSID. 796 Candidate Paths of the same SR policy SHOULD have the same BSID. 798 Candidate Paths of different SR policies MUST NOT have the same BSID. 800 6.2. BSID of an SR Policy 802 The BSID of an SR Policy is the BSID of its active candidate path. 804 When the active candidate path has a specified BSID, the SR Policy 805 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 806 available (i.e., not associated with any other usage: e.g. to another 807 MPLS client, to another SID, to another SR Policy). 809 Optionally, instead of only checking that the BSID of the active path 810 is available, a headend MAY check that it is available within a given 811 SID range i.e., Segment Routing Local Block (SRLB) as specified in 812 [RFC8402]. 814 When the specified BSID is not available (optionally is not in the 815 SRLB), an alert message MUST be generated. 817 In the cases (as described above) where SR Policy does not have a 818 BSID available, then the SR Policy MAY dynamically bind a BSID to 819 itself. Dynamically bound BSID SHOULD use an available SID outside 820 the SRLB. 822 Assuming that at time t the BSID of the SR Policy is B1, if at time 823 t+dt a different candidate path becomes active and this new active 824 path does not have a specified BSID or its BSID is specified but is 825 not available (e.g. it is in use by something else), then the SR 826 Policy keeps the previous BSID B1. 828 The association of an SR Policy with a BSID thus MAY change over the 829 life of the SR Policy (e.g., upon active path change). Hence, the 830 BSID SHOULD NOT be used as an identification of an SR Policy. 832 6.2.1. Frequent use-case : unspecified BSID 834 All the candidate paths of the same SR Policy can have an unspecified 835 BSID. 837 In such a case, a BSID MAY be dynamically bound to the SR Policy as 838 soon as the first valid candidate path is received. That BSID is 839 kept along all the life of the SR Policy and across changes of active 840 candidate path. 842 6.2.2. Frequent use-case: all specified to the same BSID 844 All the paths of the SR Policy can have the same specified BSID. 846 6.2.3. Specified-BSID-only 848 An implementation MAY support the configuration of the Specified- 849 BSID-only restrictive behavior on the headend for all SR Policies or 850 individual SR Policies. Further, this restrictive behavior MAY also 851 be signaled on a per SR Policy basis to the headend. 853 When this restrictive behavior is enabled, if the candidate path has 854 an unspecified BSID or if the specified BSID is not available when 855 the candidate path becomes active then no BSID is bound to it and it 856 is considered invalid. An alert MUST be triggered for this error. 857 Other candidate paths MUST then be evaluated for becoming the active 858 candidate path. 860 6.3. Forwarding Plane 862 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 863 with the action of steering the packets matching this entry to the 864 selected path of the SR Policy. 866 If the Specified-BSID-only restrictive behavior is enabled and the 867 BSID of the active path is not available (optionally not in the 868 SRLB), then the SR Policy does not install any entry indexed by a 869 BSID in the forwarding plane. 871 6.4. Non-SR usage of Binding SID 873 An implementation MAY choose to associate a Binding SID with any type 874 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 875 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 876 tunnel, etc). This enables the use of other non-SR enabled 877 interfaces and tunnels as segments in an SR Policy Segment-List 878 without the need of forming routing protocol adjacencies over them. 880 The details of this kind of usage are beyond the scope of this 881 document. A specific packet optical integration use case is 882 described in [I-D.anand-spring-poi-sr] 884 7. SR Policy State 886 The SR Policy State is maintained on the headend to represent the 887 state of the policy and its candidate paths. This is to provide an 888 accurate representation of whether the SR Policy is being 889 instantiated in the forwarding plane and which of its candidate paths 890 and segment-list(s) are active. The SR Policy state MUST also 891 reflect the reason when a policy and/or its candidate path is not 892 active due to validation errors or not being preferred. 894 The SR Policy state can be reported by the headend node via BGP-LS 895 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 896 [I-D.sivabalan-pce-binding-label-sid]. 898 SR Policy state on the headend also includes traffic accounting 899 information for the flows being steered via the policies. The 900 details of the SR Policy accounting are beyond the scope of this 901 document. The aspects related to the SR traffic counters and their 902 usage in the broader context of traffic accounting in a SR network 903 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 904 [I-D.ali-spring-sr-traffic-accounting] respectively. 906 Implementations MAY support an administrative state to control 907 locally provisioned policies via mechanisms like CLI or NETCONF. 909 8. Steering into an SR Policy 911 A headend can steer a packet flow into a valid SR Policy in various 912 ways: 914 o Incoming packets have an active SID matching a local BSID at the 915 headend. 916 o Per-destination Steering: incoming packets match a BGP/Service 917 route which recurses on an SR policy. 918 o Per-flow Steering: incoming packets match or recurse on a 919 forwarding array of where some of the entries are SR Policies. 920 o Policy-based Steering: incoming packets match a routing policy 921 which directs them on an SR policy. 923 For simplicity of illustration, this document uses the SR-MPLS 924 example. 926 8.1. Validity of an SR Policy 928 An SR Policy is invalid when all its candidate paths are invalid as 929 described in Section 5 and Section 2.10. 931 By default, upon transitioning to the invalid state, 933 o an SR Policy and its BSID are removed from the forwarding plane. 934 o any steering of a service (PW), destination (BGP-VPN), flow or 935 packet on the related SR policy is disabled and the related 936 service, destination, flow or packet is routed per the classic 937 forwarding table (e.g. longest-match to the destination or the 938 recursing next-hop). 940 8.2. Drop upon invalid SR Policy 942 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 944 o an invalid SR Policy and its BSID is kept in the forwarding plane 945 with an action to drop. 946 o any steering of a service (PW), destination (BGP-VPN), flow or 947 packet on the related SR policy is maintained with the action to 948 drop all of this traffic. 950 The drop-upon-invalid behavior has been deployed in use-cases where 951 the operator wants some PW to only be transported on a path with 952 specific constraints. When these constraints are no longer met, the 953 operator wants the PW traffic to be dropped. Specifically, the 954 operator does not want the PW to be routed according to the IGP 955 shortest-path to the PW endpoint. 957 8.3. Incoming Active SID is a BSID 959 Let us assume that headend H has a valid SR Policy P of Segment-List 960 and BSID B. 962 When H receives a packet K with label stack , H pops B and 963 pushes and forwards the resulting packet according to 964 SID S1. 966 "Forwarding the resulting packet according to S1" means: If S1 is 967 an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H 968 sends the resulting packet with label stack on 969 the outgoing interface associated with S1; Else H sends the 970 resulting packet with label stack along the 971 path of S1. 973 H has steered the packet into the SR policy P. 975 H did not have to classify the packet. The classification was done 976 by a node upstream of H (e.g., the source of the packet or an 977 intermediate ingress edge node of the SR domain) and the result of 978 this classification was efficiently encoded in the packet header as a 979 BSID. 981 This is another key benefit of the segment routing in general and the 982 binding SID in particular: the ability to encode a classification and 983 the resulting steering in the packet header to better scale and 984 simplify intermediate aggregation nodes. 986 If the SR Policy P is invalid, the BSID B is not in the forwarding 987 plane and hence the packet K is dropped by H. 989 8.4. Per-Destination Steering 991 Let us assume that headend H: 993 o learns a BGP route R/r via next-hop N, extended-color community C 994 and VPN label V. 995 o has a valid SR Policy P to (color = C, endpoint = N) of Segment- 996 List and BSID B. 997 o has a BGP policy which matches on the extended-color community C 998 and allows its usage as SLA steering information. 1000 If all these conditions are met, H installs R/r in RIB/FIB with next- 1001 hop = SR Policy P of BSID B instead of via N. 1003 Indeed, H's local BGP policy and the received BGP route indicate that 1004 the headend should associate R/r with an SR Policy path to endpoint N 1005 with the SLA associated with color C. The headend therefore installs 1006 the BGP route on that policy. 1008 This can be implemented by using the BSID as a generalized next-hop 1009 and installing the BGP route on that generalized next-hop. 1011 When H receives a packet K with a destination matching R/r, H pushes 1012 the label stack and sends the resulting packet along 1013 the path to S1. 1015 Note that any SID associated with the BGP route is inserted after the 1016 Segment-List of the SR Policy (i.e., ). 1018 The same behavior is applicable to any type of service route: any 1019 AFI/SAFI of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1021 8.4.1. Multiple Colors 1023 When a BGP route has multiple extended-color communities each with a 1024 valid SR Policy NLRI, the BGP process installs the route on the SR 1025 policy whose color is of highest numerical value. 1027 Let us assume that headend H: 1029 o learns a BGP route R/r via next-hop N, extended-color communities 1030 C1 and C2 and VPN label V. 1031 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1032 List and BSID B1. 1033 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1034 List and BSID B2. 1035 o has a BGP policy which matches on the extended-color communities 1036 C1 and C2 and allows their usage as SLA steering information 1038 If all these conditions are met, H installs R/r in RIB/FIB with next- 1039 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1041 8.5. Recursion on an on-demand dynamic BSID 1043 In the previous section, it was assumed that H had a pre-established 1044 "explicit" SR Policy (color C, endpoint N). 1046 In this section, independently to the a-priori existence of any 1047 explicit candidate path of the SR policy (C, N), it is to be noted 1048 that the BGP process at headend node H triggers the instantiation of 1049 a dynamic candidate path for the SR policy (C, N) as soon as: 1051 o the BGP process learns of a route R/r via N and with color C. 1053 o a local policy at node H authorizes the on-demand SR Policy path 1054 instantiation and maps the color to a dynamic SR Policy path 1055 optimization template. 1057 8.5.1. Multiple Colors 1059 When a BGP route R/r via N has multiple extended-color communities Ci 1060 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1061 request (color Ci, endpoint N) is triggered for each color Ci. 1063 8.6. Per-Flow Steering 1065 Let us assume that headend H: 1067 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1068 List and BSID B1. 1069 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1070 List and BSID B2. 1071 o is configured to instantiate an array of paths to N where the 1072 entry 0 is the IGP path to N, color C1 is the first entry and 1073 Color C2 is the second entry. The index into the array is called 1074 a Forwarding Class (FC). The index can have values 0 to 7. 1075 o is configured to match flows in its ingress interfaces (upon any 1076 field such as Ethernet destination/source/vlan/tos or IP 1077 destination/source/DSCP or transport ports etc.) and color them 1078 with an internal per-packet forwarding-class variable (0, 1 or 2 1079 in this example). 1081 If all these conditions are met, H installs in RIB/FIB: 1083 o N via a recursion on an array A (instead of the immediate outgoing 1084 link associated with the IGP shortest-path to N). 1085 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1086 path to N. 1087 o Entry A(1) set to SR Policy P1 of BSID=B1. 1088 o Entry A(2) set to SR Policy P2 of BSID=B2. 1090 H receives three packets K, K1 and K2 on its incoming interface. 1091 These three packets either longest-match on N or more likely on a 1092 BGP/service route which recurses on N. H colors these 3 packets 1093 respectively with forwarding-class 0, 1 and 2. As a result: 1095 o H forwards K along the shortest-path to N (which in SR-MPLS 1096 results in the pushing of the prefix-SID of N). 1097 o H pushes on packet K1 and forwards the resulting 1098 frame along the shortest-path to S1. 1099 o H pushes on packet K2 and forwards the resulting 1100 frame along the shortest-path to S4. 1102 If the local configuration does not specify any explicit forwarding 1103 information for an entry of the array, then this entry is filled with 1104 the same information as entry 0 (i.e. the IGP shortest-path). 1106 If the SR Policy mapped to an entry of the array becomes invalid, 1107 then this entry is filled with the same information as entry 0. When 1108 all the array entries have the same information as entry0, the 1109 forwarding entry for N is updated to bypass the array and point 1110 directly to its outgoing interface and next-hop. 1112 The array index values (e.g. 0, 1 and 2) and the notion of 1113 forwarding-class are implementation specific and only meant to 1114 describe the desired behavior. The same can be realized by other 1115 mechanisms. 1117 This realizes per-flow steering: different flows bound to the same 1118 BGP endpoint are steered on different IGP or SR Policy paths. 1120 A headend MAY support options to apply per-flow steering only for 1121 traffic matching specific prefixes (e.g. specific IGP or BGP 1122 prefixes). 1124 8.7. Policy-based Routing 1126 Finally, headend H may be configured with a local routing policy 1127 which overrides any BGP/IGP path and steer a specified packet on an 1128 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1129 automatic routing of IGP prefixes over SR Policies intended for such 1130 purpose. 1132 8.8. Optional Steering Modes for BGP Destinations 1134 8.8.1. Color-Only BGP Destination Steering 1136 In the previous section, it is seen that the steering on an SR Policy 1137 is governed by the matching of the BGP route's next-hop N and the 1138 authorized color C with an SR Policy defined by the tuple (N, C). 1140 This is the most likely form of BGP destination steering and the one 1141 recommended for most use-cases. 1143 This section defines an alternative steering mechanism based only on 1144 the color. 1146 This color-only steering variation is governed by two new flags "C" 1147 and "O" defined in the color extended community [ref draft-ietf-idr- 1148 segment-routing-te-policy section 3]. 1150 The Color-Only flags "CO" are set to 00 by default. 1152 When 00, the BGP destination is steered as follows: 1154 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1156 endpoint address and C is a color; 1157 Steer into SR Policy (N, C); 1158 ELSE; 1159 Steer on the IGP path to the next-hop N. 1161 This is the classic case described in this document previously and 1162 what is recommended in most scenarios. 1164 When 01, the BGP destination is steered as follows: 1166 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1168 endpoint address and C is a color; 1169 Steer into SR Policy (N, C); 1170 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1171 same address-family of N; 1172 Steer into SR Policy (null endpoint, C); 1173 ELSE IF there is any valid SR Policy 1174 (any address-family null endpoint, C); 1175 Steer into SR Policy (any null endpoint, C); 1176 ELSE; 1177 Steer on the IGP path to the next-hop N. 1179 When 10, the BGP destination is steered as follows: 1181 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1182 endpoint address and C is a color; 1183 Steer into SR Policy (N, C); 1184 ELSE IF there is a valid SR Policy (null endpoint, C) 1185 of the same address-family of N; 1186 Steer into SR Policy (null endpoint, C); 1187 ELSE IF there is any valid SR Policy 1188 (any address-family null endpoint, C); 1189 Steer into SR Policy (any null endpoint, C); 1190 ELSE IF there is any valid SR Policy (any endpoint, C) 1191 of the same address-family of N; 1192 Steer into SR Policy (any endpoint, C); 1193 ELSE IF there is any valid SR Policy 1194 (any address-family endpoint, C); 1195 Steer into SR Policy (any address-family endpoint, C); 1196 ELSE; 1197 Steer on the IGP path to the next-hop N. 1199 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1200 to the 0 value). 1202 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1203 reception, an implementations MUST treat it like 00. 1205 8.8.2. Multiple Colors and CO flags 1207 The steering preference is first based on highest color value and 1208 then CO-dependent for the color. Assuming a Prefix via (NH, 1209 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1211 o SR policy (NH, C1). 1212 o SR policy (null, C1). 1213 o SR policy (NH, C2). 1214 o SR policy (null, C2). 1215 o IGP to NH. 1217 8.8.3. Drop upon Invalid 1219 This document defined earlier that when all the following conditions 1220 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1221 BSID B instead of via N. 1223 o H learns a BGP route R/r via next-hop N, extended-color community 1224 C and VPN label V. 1225 o H has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1226 List and BSID B. 1227 o H has a BGP policy which matches on the extended-color community C 1228 and allows its usage as SLA steering information. 1230 This behavior is extended by noting that the BGP policy may require 1231 the BGP steering to always stay on the SR policy whatever its 1232 validity. 1234 This is the "drop upon invalid" option described in Section 8.2 1235 applied to BGP-based steering. 1237 9. Protection 1239 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1241 In any topology, Topology-Independent Loop Free Alternate (TI-LFA) 1242 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1243 protection technique for IGP SIDs. The backup path is computed on a 1244 per IGP SID basis along the post-convergence path. 1246 In a network that has deployed TI-LFA, an SR Policy built on the 1247 basis of TI-LFA protected IGP segments leverages the local protection 1248 of the constituent segments. 1250 In a network that has deployed TI-LFA, an SR Policy instantiated only 1251 with non-protected Adj SIDs does not benefit from any local 1252 protection. 1254 9.2. Using an SR Policy to locally protect a link 1256 1----2-----6----7 1257 | | | | 1258 4----3-----9----8 1260 Figure 1: Local protection using SR Policy 1262 An SR Policy can be instantiated at node 2 to protect the link 2to6. 1263 A typical explicit Segment-List would be <3, 9, 6>. 1265 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1266 3 and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8 and 9 are part 1267 of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 cannot 1268 benefit from TI-LFA automated local protection. The SR Policy with 1269 Segment-List <3, 9, 6> on node 2 can be locally configured to be a 1270 fast-reroute backup path for the link 2to6. 1272 9.3. Using a Candidate Path for Path Protection 1274 An SR Policy allows for multiple candidate paths, of which at any 1275 point in time there is a single active candidate path that is 1276 provisioned in the forwarding plane and used for traffic steering. 1277 However, another (lower preference) candidate path MAY be designated 1278 as the backup for a specific or all (active) candidate path(s). The 1279 following options are possible: 1281 o A pair of disjoint candidate paths are provisioned with one of 1282 them as primary and the other is identified as its backup. 1283 o A specific candidate path is provisioned as the backup for any 1284 (active) candidate path. 1285 o The headend picks the next (lower) preference valid candidate path 1286 as the backup for the active candidate path. 1288 The headend MAY compute a-priori and validate such backup candidate 1289 paths as well as provision them into forwarding plane as backup for 1290 the active path. A fast re-route mechanism MAY then be used to 1291 trigger sub 50msec switchover from the active to the backup candidate 1292 path in the forwarding plane. Mechanisms like BFD MAY be used for 1293 fast detection of such failures. 1295 10. Security Considerations 1297 This document does not define any new protocol extensions and does 1298 not impose any additional security challenges. 1300 11. IANA Considerations 1302 This document requests IANA to create a new top-level registry called 1303 "Segment Routing Parameters". This registry is being defined to 1304 serve as a top-level registry for keeping all other Segment Routing 1305 sub-registries. 1307 The document also requests creation of a new sub-registry called 1308 "Segment Types" to be defined under the top-level "Segment Routing 1309 Parameters" registry. This sub-registry maintains the alphabetic 1310 identifiers for the segment types (as specified in section 4) that 1311 may be used within a Segment List of an SR Policy. This sub-registry 1312 would follow the Specification Required allocation policy as 1313 specified in [RFC8126]. 1315 The initial registrations for this sub-registry are as follows: 1317 +-------+-----------------------------------------------+-----------+ 1318 | Value | Description | Reference | 1319 +-------+-----------------------------------------------+-----------+ 1320 | A | SR-MPLS Label | [This.ID] | 1321 | B | SRv6 SID | [This.ID] | 1322 | C | IPv4 Prefix with optional SR Algorithm | [This.ID] | 1323 | D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1324 | | for SR-MPLS | | 1325 | E | IPv4 Prefix with Local Interface ID | [This.ID] | 1326 | F | IPv4 Addresses for link endpoints as Local, | [This.ID] | 1327 | | Remote pair | | 1328 | G | IPv6 Prefix and Interface ID for link | [This.ID] | 1329 | | endpoints as Local, | | 1330 | | Remote pair for SR-MPLS | | 1331 | H | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1332 | | Remote pair for SR-MPLS | | 1333 | I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | 1334 | | for SRv6 | | 1335 | J | IPv6 Prefix and Interface ID for link | [This.ID] | 1336 | | endpoints as Local, Remote pair for SRv6 | | 1337 | K | IPv6 Addresses for link endpoints as Local, | [This.ID] | 1338 | | Remote pair for SRv6 | | 1339 +-------+-----------------------------------------------+-----------+ 1341 Table 2: Initial IANA Registration 1343 11.1. Guidance for Designated Experts 1345 The Designated Expert (DE) is expected to ascertain the existence of 1346 suitable documentation (a specification) as described in [RFC8126] 1347 and to verify that the document is permanently and publicly 1348 available. The DE is also expected to check the clarity of purpose 1349 and use of the requested assignment. Additionally, the DE must 1350 verify that any request for one of these assignments has been made 1351 available for review and comment within the IETF: the DE will post 1352 the request to the SPRING Working Group mailing list (or a successor 1353 mailing list designated by the IESG). If the request comes from 1354 within the IETF, it should be documented in an Internet-Draft. 1355 Lastly, the DE must ensure that any other request for a code point 1356 does not conflict with work that is active or already published 1357 within the IETF. 1359 12. Acknowledgement 1361 The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger 1362 Geib and Rob Shakir for their valuable comments and suggestions. 1364 13. Contributors 1366 The following people have contributed to this document: 1368 Ketan Talaulikar 1369 Cisco Systems 1370 Email: ketant@cisco.com 1372 Zafar Ali 1373 Cisco Systems 1374 Email: zali@cisco.com 1376 Jose Liste 1377 Cisco Systems 1378 Email: jliste@cisco.com 1380 Francois Clad 1381 Cisco Systems 1382 Email: fclad@cisco.com 1384 Kamran Raza 1385 Cisco Systems 1386 Email: skraza@cisco.com 1388 Shraddha Hegde 1389 Juniper Networks 1390 Email: shraddha@juniper.net 1392 Steven Lin 1393 Google, Inc. 1394 Email: stevenlin@google.com 1396 Przemyslaw Krol 1397 Google, Inc. 1398 Email: pkrol@google.com 1400 Martin Horneffer 1401 Deutsche Telekom 1402 Email: martin.horneffer@telekom.de 1404 Dirk Steinberg 1405 Steinberg Consulting 1406 Email: dws@steinbergnet.net 1408 Bruno Decraene 1409 Orange Business Services 1410 Email: bruno.decraene@orange.com 1411 Stephane Litkowski 1412 Orange Business Services 1413 Email: stephane.litkowski@orange.com 1415 Luay Jalil 1416 Verizon 1417 Email: luay.jalil@verizon.com 1419 14. References 1421 14.1. Normative References 1423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1424 Requirement Levels", BCP 14, RFC 2119, 1425 DOI 10.17487/RFC2119, March 1997, 1426 . 1428 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1429 IANA Considerations Section in RFCs", RFC 5226, 1430 DOI 10.17487/RFC5226, May 2008, 1431 . 1433 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1434 Writing an IANA Considerations Section in RFCs", BCP 26, 1435 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1436 . 1438 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1439 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1440 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1441 July 2018, . 1443 14.2. Informative References 1445 [I-D.ali-spring-sr-traffic-accounting] 1446 Filsfils, C., Talaulikar, K., Sivabalan, S., Horneffer, 1447 M., Raszuk, R., Litkowski, S., Voyer, D., and R. Morton, 1448 "Traffic Accounting in Segment Routing Networks", draft- 1449 ali-spring-sr-traffic-accounting-04 (work in progress), 1450 February 2020. 1452 [I-D.anand-spring-poi-sr] 1453 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1454 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1455 Integration in Segment Routing", draft-anand-spring-poi- 1456 sr-08 (work in progress), July 2019. 1458 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 1459 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 1460 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 1461 Camarillo, "Topology Independent Fast Reroute using 1462 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 1463 lfa-05 (work in progress), October 2018. 1465 [I-D.filsfils-spring-sr-policy-considerations] 1466 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1467 P. Mattes, "SR Policy Implementation and Deployment 1468 Considerations", draft-filsfils-spring-sr-policy- 1469 considerations-05 (work in progress), April 2020. 1471 [I-D.filsfils-spring-sr-traffic-counters] 1472 Filsfils, C., Ali, Z., Horneffer, M., 1473 daniel.voyer@bell.ca, d., Durrani, M., and R. Raszuk, 1474 "Segment Routing Traffic Accounting Counters", draft- 1475 filsfils-spring-sr-traffic-counters-00 (work in progress), 1476 June 2018. 1478 [I-D.filsfils-spring-srv6-network-programming] 1479 Filsfils, C., Camarillo, P., Leddy, J., 1480 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1481 Network Programming", draft-filsfils-spring-srv6-network- 1482 programming-07 (work in progress), February 2019. 1484 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1485 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 1486 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 1487 using Border Gateway Protocol - Link State", draft-ietf- 1488 idr-bgp-ls-segment-routing-msd-17 (work in progress), 1489 April 2020. 1491 [I-D.ietf-idr-bgpls-segment-routing-epe] 1492 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1493 S., and J. Dong, "BGP-LS extensions for Segment Routing 1494 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1495 segment-routing-epe-19 (work in progress), May 2019. 1497 [I-D.ietf-idr-segment-routing-te-policy] 1498 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1499 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 1500 Routing Policies in BGP", draft-ietf-idr-segment-routing- 1501 te-policy-08 (work in progress), November 2019. 1503 [I-D.ietf-idr-te-lsp-distribution] 1504 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1505 H., and J. Tantsura, "Distribution of Traffic Engineering 1506 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1507 lsp-distribution-13 (work in progress), April 2020. 1509 [I-D.ietf-isis-segment-routing-msd] 1510 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1511 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 1512 ietf-isis-segment-routing-msd-19 (work in progress), 1513 October 2018. 1515 [I-D.ietf-lsr-flex-algo] 1516 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1517 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1518 algo-07 (work in progress), April 2020. 1520 [I-D.ietf-ospf-segment-routing-msd] 1521 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1522 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 1523 ietf-ospf-segment-routing-msd-25 (work in progress), 1524 October 2018. 1526 [I-D.ietf-pce-segment-routing] 1527 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1528 and J. Hardwick, "PCEP Extensions for Segment Routing", 1529 draft-ietf-pce-segment-routing-16 (work in progress), 1530 March 2019. 1532 [I-D.sivabalan-pce-binding-label-sid] 1533 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1534 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1535 in PCE-based Networks.", draft-sivabalan-pce-binding- 1536 label-sid-07 (work in progress), July 2019. 1538 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1539 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1540 December 1990, . 1542 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1543 DOI 10.17487/RFC2328, April 1998, 1544 . 1546 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1547 (TE) Extensions to OSPF Version 2", RFC 3630, 1548 DOI 10.17487/RFC3630, September 2003, 1549 . 1551 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1552 Reflection: An Alternative to Full Mesh Internal BGP 1553 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1554 . 1556 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1557 "Multiprotocol Extensions for BGP-4", RFC 4760, 1558 DOI 10.17487/RFC4760, January 2007, 1559 . 1561 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1562 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1563 2008, . 1565 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1566 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1567 . 1569 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1570 Locator/ID Separation Protocol (LISP)", RFC 6830, 1571 DOI 10.17487/RFC6830, January 2013, 1572 . 1574 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1575 Previdi, "OSPF Traffic Engineering (TE) Metric 1576 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1577 . 1579 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1580 S. Ray, "North-Bound Distribution of Link-State and 1581 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1582 DOI 10.17487/RFC7752, March 2016, 1583 . 1585 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1586 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1587 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1588 . 1590 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1591 Computation Element Communication Protocol (PCEP) 1592 Extensions for Stateful PCE", RFC 8231, 1593 DOI 10.17487/RFC8231, September 2017, 1594 . 1596 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1597 Computation Element Communication Protocol (PCEP) 1598 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1599 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1600 . 1602 Authors' Addresses 1604 Clarence Filsfils 1605 Cisco Systems, Inc. 1606 Pegasus Parc 1607 De kleetlaan 6a, DIEGEM BRABANT 1831 1608 BELGIUM 1610 Email: cfilsfil@cisco.com 1612 Siva Sivabalan (editor) 1613 Cisco Systems, Inc. 1614 2000 Innovation Drive 1615 Kanata, Ontario K2K 3E8 1616 Canada 1618 Email: msiva@cisco.com 1620 Daniel Voyer 1621 Bell Canada 1622 671 de la gauchetiere W 1623 Montreal, Quebec H3B 2M8 1624 Canada 1626 Email: daniel.voyer@bell.ca 1628 Alex Bogdanov 1629 Google, Inc. 1631 Email: bogdanov@google.com 1633 Paul Mattes 1634 Microsoft 1635 One Microsoft Way 1636 Redmond, WA 98052-6399 1637 USA 1639 Email: pamattes@microsoft.com