idnits 2.17.1 draft-ietf-spring-segment-routing-policy-03.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 12, 2019) is 1804 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-02 == Outdated reference: A later version (-08) exists of draft-anand-spring-poi-sr-07 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-03 == 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-04 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-18 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-05 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-11 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-01 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-06 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 0 errors (**), 0 flaws (~~), 11 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 13, 2019 D. Voyer 6 Bell Canada 7 A. Bogdanov 8 Google, Inc. 9 P. Mattes 10 Microsoft 11 May 12, 2019 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-03.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 13, 2019. 49 Copyright Notice 51 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 18 91 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 19 92 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 19 93 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . 27 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 109 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 110 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 111 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 14.1. Normative References . . . . . . . . . . . . . . . . . . 29 113 14.2. Informative References . . . . . . . . . . . . . . . . . 29 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 116 1. Introduction 118 Segment Routing (SR) allows a headend node to steer a packet flow 119 along any path. Intermediate per-flow states are eliminated thanks 120 to source routing [RFC8402]. 122 The headend node is said to steer a flow into an Segment Routing 123 Policy (SR Policy). 125 The header of a packet steered into an SR Policy is augmented with an 126 ordered list of segments associated with that SR Policy. 128 This document details the concepts of SR Policy and steering packets 129 into an SR Policy. These apply equally to the MPLS and SRv6 130 instantiations of segment routing. 132 For reading simplicity, the illustrations are provided for the MPLS 133 instantiations. 135 2. SR Policy 137 An SR Policy is a framework that enables instantiation of an ordered 138 list of segments on a node for implementing a source routing policy 139 with a specific intent for traffic steering from that node. 141 The Segment Routing architecture [RFC8402] specifies that any 142 instruction can be bound to a segment. Thus, an SR Policy can be 143 built using any type of Segment Identifier (SID) including those 144 associated with topological or service instructions. 146 This section defines the key aspects and constituents of an SR 147 Policy. 149 2.1. Identification of an SR Policy 151 An SR Policy is identified through the tuple . In the context of a specific headend, one may identify an 153 SR policy by the tuple. 155 The headend is the node where the policy is instantiated/implemented. 156 The headend is specified as an IPv4 or IPv6 address and is expected 157 to be unique in the domain. 159 The endpoint indicates the destination of the policy. The endpoint 160 is specified as an IPv4 or IPv6 address and is expected to be unique 161 in the domain. In a specific case (refer to Section 8.8.1), the 162 endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6). 164 The color is a 32-bit numerical value that associates the SR Policy 165 with an intent (e.g. low-latency). 167 The endpoint and the color are used to automate the steering of 168 service or transport routes on SR Policies (refer to Section 8). 170 An implementation MAY allow assignment of a symbolic name comprising 171 of printable ASCII characters to an SR Policy to serve as a user- 172 friendly attribute for debug and troubleshooting purposes. Such 173 symbolic names may identify an SR Policy when the naming scheme 174 ensures uniqueness. 176 2.2. Candidate Path and Segment List 178 An SR Policy is associated with one or more candidate paths. A 179 candidate path is the unit for signaling of an SR Policy to a headend 180 via protocols like Path Computation Element (PCE) Communication 181 Protocol (PCEP) [RFC8281] or BGP SR Policy 182 [I-D.ietf-idr-segment-routing-te-policy]. 184 A Segment-List represents a specific source-routed path to send 185 traffic from the headend to the endpoint of the corresponding SR 186 policy. 188 A candidate path is either dynamic or explicit. 190 An explicit candidate path is expressed as a Segment-List or a set of 191 Segment-Lists. 193 A dynamic candidate path expresses an optimization objective and a 194 set of constraints. The headend (potentially with the help of a PCE) 195 computes the solution Segment-List (or set of Segment-Lists) that 196 solves the optimization problem. 198 If a candidate path is associated with a set of Segment-Lists, each 199 Segment-List is associated with a weight for weighted load balancing 200 (refer Section 2.11 for details). The default weight is 1. 202 2.3. Protocol-Origin of a Candidate Path 204 A headend may be informed about a candidate path for an SR Policy 205 by various means including: via configuration, PCEP 206 [RFC8281] or BGP [I-D.ietf-idr-segment-routing-te-policy]. 208 Protocol-Origin of a candidate path is an 8-bit value which 209 identifies the component or protocol that originates or signals the 210 candidate path. 212 The table below specifies the RECOMMENDED default values: 214 +-------+-------------------+ 215 | Value | Protocol-Origin | 216 +-------+-------------------+ 217 | 10 | PCEP | 218 | 20 | BGP SR Policy | 219 | 30 | Via Configuration | 220 +-------+-------------------+ 222 Table 1: Protocol-origin Identifier 224 Implementations MAY allow modifications of these default values 225 assigned to protocols on the headend along similar lines as a routing 226 administrative distance. Its application in the candidate path 227 selection is described in Section 2.9. 229 2.4. Originator of a Candidate Path 231 Originator identifies the node which provisioned or signalled the 232 candidate path on the headend. The originator is expressed in the 233 form of a 160 bit numerical value formed by the concatenation of the 234 fields of the tuple as below: 236 o ASN : represented as a 4 byte number. 238 o Node Address : represented as a 128 bit value. IPv4 addresses are 239 encoded in the lowest 32 bits. 241 Its application in the candidate path selection is described in 242 Section 2.9. 244 When Protocol-Origin is Via Configuration, the ASN and node address 245 MAY be set to either the headend or the provisioning controller/node 246 ASN and address. Default value is 0 for both AS and node address. 248 When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the 249 PCE and the AS number SHOULD be set to 0 by default when not 250 available or known. 252 Protocol-Origin is BGP SR Policy, it is provided by the BGP component 253 on the headend and is: 255 o the BGP Router ID and ASN of the node/controller signalling the 256 candidate path when it has a BGP session to the headend, OR 258 o the BGP Router ID of the eBGP peer signalling the candidate path 259 along with ASN of origin when the signalling is done via one or 260 more intermediate eBGP routers, OR 262 o the BGP Originator ID [RFC4456] and the ASN of the node/controller 263 when the signalling is done via one or more route-reflectors over 264 iBGP session. 266 2.5. Discriminator of a Candidate Path 268 The Discriminator is a 32 bit value associated with a candidate path 269 that uniquely identifies it within the context of an SR Policy from a 270 specific Protocol-Origin as specified below: 272 When Protocol-Origin is Via Configuration, this is an 273 implementation's configuration model specific unique identifier for a 274 candidate path. Default value is 0. 276 When PCEP is the Protocol-Origin, the method to uniquely identify 277 signalled path will be specified in a future PCEP document. Default 278 value is 0. 280 When BGP SR Policy is the Protocol-Origin, it is the distinguisher 281 specified in Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]. 283 Its application in the candidate path selection is described in 284 Section 2.9. 286 2.6. Identification of a Candidate Path 288 A candidate path is identified in the context of a single SR Policy. 290 A candidate path is not shared across SR Policies. 292 A candidate path is not identified by its Segment-List(s). 294 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 295 candidate path of SR Policy Pol2, then these two candidate paths 296 are independent, even if they happen to have the same Segment- 297 List. The Segment-List does not identify a candidate path. The 298 Segment-List is an attribute of a candidate path. 300 The identity of a candidate path MUST be uniquely established in the 301 context of an SR Policy in order to handle 302 add, delete or modify operations on them in an unambiguous manner 303 regardless of their source(s). 305 The tuple uniquely 306 identifies a candidate path. 308 Candidate paths MAY also be assigned or signaled with a symbolic name 309 comprising printable ASCII characters to serve as a user-friendly 310 attribute for debug and troubleshooting purposes. Such symbolic 311 names MUST NOT be considered as identifiers for a candidate path. 313 2.7. Preference of a Candidate Path 315 The preference of the candidate path is used to select the best 316 candidate path for an SR Policy. The default preference is 100. 318 It is RECOMMENDED that each candidate path of a given SR policy has a 319 different preference. 321 2.8. Validity of a Candidate Path 323 A candidate path is usable when it valid. A common path validity 324 criterion is the reachability of its constituent SIDs. The 325 validation rules are specified in Section 5. 327 2.9. Active Candidate Path 329 A candidate path is selected when it is valid and it is determined to 330 be the best path of the SR Policy. The selected path is referred to 331 as the "active path" of the SR policy in this document. 333 Whenever a new path is learned or an active path is deleted, the 334 validity of an existing path changes or an existing path is changed, 335 the selection process MUST be re-executed. 337 The candidate path selection process operates on the candidate path 338 Preference. A candidate path is selected when it is valid and it has 339 the highest preference value among all the candidate paths of the SR 340 Policy. 342 In the case of multiple valid candidate paths of the same preference, 343 the tie-breaking rules are evaluated on the identification tuple in 344 the following order until only one valid best path is selected: 346 1. Higher value of Protocol-Origin is selected. 348 2. If specified by configuration, prefer the existing installed 349 path. 351 3. Lower value of originator is selected. 353 4. Finally, the higher value of discriminator is selected. 355 The rules are framed with multiple protocols and sources in mind and 356 hence may not follow the logic of a single protocol (e.g. BGP best 357 path selection). The motivation behind these rules are as follows: 359 o The Protocol-Origin allows an operator to setup a default 360 selection mechanism across protocol sources, e.g., to prefer 361 configured over paths signalled via BGP SR Policy or PCEP. 363 o The preference, being the first tiebreaker, allows an operator to 364 influence selection across paths thus allowing provisioning of 365 multiple path options, e.g., CP1 is preferred and if it becomes 366 invalid then fall-back to CP2 and so on. Since preference works 367 across protocol sources it also enables (where necessary) 368 selective override of the default protocol-origin preference, 369 e.g., to prefer a path signalled via BGP SR Policy over what is 370 configured. 372 o The originator allows an operator to have multiple redundant 373 controllers and still maintain a deterministic behaviour over 374 which of them are preferred even if they are providing the same 375 candidate paths for the same SR policies to the headend. 377 o The discriminator performs the final tiebreaking step to ensure a 378 deterministic outcome of selection regardless of the order in 379 which candidate paths are signalled across multiple transport 380 channels or sessions. 382 [I-D.filsfils-spring-sr-policy-considerations] provides a set of 383 examples to illustrate the active candidate path selection rules. 385 2.10. Validity of an SR Policy 387 An SR Policy is valid when it has at least one valid candidate path. 389 2.11. Instantiation of an SR Policy in the Forwarding Plane 391 A valid SR Policy is instantiated in the forwarding plane. 393 Only the active candidate path SHOULD be used for forwarding traffic 394 that is being steered onto that policy. 396 If a set of Segment-Lists is associated with the active path of the 397 policy, then the steering is per flow and W-ECMP based according to 398 the relative weight of each Segment-List. 400 The fraction of the flows associated with a given Segment-List is w/ 401 Sw where w is the weight of the Segment-List and Sw is the sum of the 402 weights of the Segment-Lists of the selected path of the SR Policy. 404 The accuracy of the weighted load-balancing depends on the platform 405 implementation. 407 2.12. Priority of an SR Policy 409 Upon topological change, many policies could be recomputed or 410 revalidated. An implementation MAY provide a per-policy priority 411 configuration. The operator MAY set this field to indicate order in 412 which the policies should be re-computed. Such a priority is 413 represented by an integer in the range (0, 255) where the lowest 414 value is the highest priority. The default value of priority is 128. 416 An SR Policy may comprise multiple Candidate Paths received from the 417 same or different sources. A candidate path MAY be signaled with a 418 priority value. When an SR Policy has multiple candidate paths with 419 distinct signaled non-default priority values, the SR Policy as a 420 whole takes the lowest value (i.e. the highest priority) amongst 421 these signaled priority values. 423 2.13. Summary 425 In summary, the information model is the following: 427 SR policy POL1 428 Candidate-path CP1 430 Preference 200 431 Weight W1, SID-List1 432 Weight W2, SID-List2 433 Candidate-path CP2 435 Preference 100 436 Weight W3, SID-List3 437 Weight W4, SID-List4 439 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 441 identified by a tuple . 442 CP1 is the active candidate path (it is valid and it has the highest 443 preference). The two Segment-Lists of CP1 are installed as the 444 forwarding instantiation of SR policy Pol1. Traffic steered on Pol1 445 is flow-based hashed on Segment-List with a ratio 446 W1/(W1+W2). 448 3. Segment Routing Database 450 An SR headend maintains the Segment Routing Database (SR-DB). The 451 SR-DB is a conceptual database to illustrate the various pieces of 452 information and their sources that may help in SR Policy computation 453 and validation. There is no specific requirement for an 454 implementation to create a new database as such. 456 An SR headend leverages the SR-DB to validate explicit candidate 457 paths and compute dynamic candidate paths. 459 The information in the SR-DB MAY include: 461 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 462 OSPF [RFC2328] [RFC5340]) 463 o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj- 464 SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402] 465 [I-D.ietf-idr-bgpls-segment-routing-epe] 466 [I-D.filsfils-spring-srv6-network-programming] 467 o TE Link Attributes (such as TE metric, SRLG, attribute-flag, 468 extended admin group) [RFC5305] [RFC3630]. 469 o Extended TE Link attributes (such as latency, loss) [RFC7810] 470 [RFC7471] 471 o Inter-AS Topology information 472 [I-D.ietf-idr-bgpls-segment-routing-epe]. 474 The attached domain topology MAY be learned via IGP, BGP-LS or 475 NETCONF. 477 A non-attached (remote) domain topology MAY be learned via BGP-LS or 478 NETCONF. 480 In some use-cases, the SR-DB may only contain the attached domain 481 topology while in others, the SR-DB may contain the topology of 482 multiple domains and in this case it is multi-domain capable. 484 The SR-DB MAY also contain the SR Policies instantiated in the 485 network. This can be collected via BGP-LS 486 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 487 [I-D.sivabalan-pce-binding-label-sid]. This information allows to 488 build an end-to-end policy on the basis of intermediate SR policies 489 (see Section 6 for further details). 491 The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of 492 nodes in the topology. This can be collected via ISIS 493 [I-D.ietf-isis-segment-routing-msd], OSPF 494 [I-D.ietf-ospf-segment-routing-msd], BGP-LS 495 [I-D.ietf-idr-bgp-ls-segment-routing-msd] or PCEP 496 [I-D.ietf-pce-segment-routing]. 498 The use of the SR-DB for computation and validation of SR Policies is 499 outside the scope of this document. Some implementation aspects 500 related to this are covered in 501 [I-D.filsfils-spring-sr-policy-considerations]. 503 4. Segment Types 505 A Segment-List is an ordered set of segments represented as where S1 is the first segment. 508 Based on the desired dataplane, either the MPLS label stack or the 509 SRv6 SRH is built from the Segment-List. However, the Segment-List 510 itself can be specified using different segment-descriptor types and 511 the following are currently defined: 513 Type 1: SR-MPLS Label: 514 A MPLS label corresponding to any of the segment types defined 515 for SR-MPLS (as defined in [RFC8402] or other SR-MPLS 516 specifications) can be used. Additionally, reserved labels 517 like explicit-null or in general any MPLS label may also be 518 used. E.g. this type can be used to specify a label 519 representation which maps to an optical transport path on a 520 packet transport node. This type does not require the headend 521 to perform SID resolution. 523 Type 2: SRv6 SID: 525 An IPv6 address corresponding to any of the segment types 526 defined for SRv6 (as defined in 527 [I-D.filsfils-spring-srv6-network-programming] or other SRv6 528 specifications) can be used. This type does not require the 529 headend to perform SID resolution. 531 Type 3: IPv4 Prefix with optional SR Algorithm: 532 The headend is required to resolve the specified IPv4 Prefix 533 Address to the SR-MPLS label corresponding to a Prefix SID 534 segment (as defined in [RFC8402]). The SR algorithm (refer to 535 Section 3.1.1 of [RFC8402]) to be used MAY also be provided. 537 Type 4: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 538 In this case the headend is required to resolve the specified 539 IPv6 Global Prefix Address to the SR-MPLS label corresponding 540 to its Prefix SID segment (as defined in [RFC8402]). The SR 541 Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY 542 also be provided. 544 Type 5: IPv4 Prefix with Local Interface ID: 545 This type allows identification of Adjacency SID (as defined in 546 [RFC8402]) or BGP EPE Peering SID (as defined in 547 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for point-to- 548 point links including IP unnumbered links. The headend is 549 required to resolve the specified IPv4 Prefix Address to the 550 Node originating it and then use the Local Interface ID to 551 identify the point-to-point link whose adjacency is being 552 referred to. The Local Interface ID link descriptor follows 553 semantics as specified in [RFC7752]. This type can also be 554 used to indicate indirection into a layer 2 interface (i.e. 555 without IP address) like a representation of an optical 556 transport path or a layer 2 Ethernet port or circuit at the 557 specified node. 559 Type 6: IPv4 Addresses for link endpoints as Local, Remote pair: 560 This type allows identification of Adjacency SID (as defined in 561 [RFC8402]) or BGP EPE Peering SID (as defined in 562 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for links. The 563 headend is required to resolve the specified IPv4 Local Address 564 to the Node originating it and then use the IPv4 Remote Address 565 to identify the link adjacency being referred to. The Local 566 and Remote Address pair link descriptors follows semantics as 567 specified in [RFC7752]. 569 Type 7: IPv6 Prefix and Interface ID for link endpoints as Local, 570 Remote pair for SR-MPLS: 571 This type allows identification of Adjacency SID (as defined in 572 [RFC8402]) or BGP EPE Peering SID (as defined in 574 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for links 575 including those with only Link Local IPv6 addresses. The 576 headend is required to resolve the specified IPv6 Prefix 577 Address to the Node originating it and then use the Local 578 Interface ID to identify the point-to-point link whose 579 adjacency is being referred to. For other than point-to-point 580 links, additionally the specific adjacency over the link needs 581 to be resolved using the Remote Prefix and Interface ID. The 582 Local and Remote pair of Prefix and Interface ID link 583 descriptor follows semantics as specified in [RFC7752]. This 584 type can also be used to indicate indirection into a layer 2 585 interface (i.e. without IP address) like a representation of an 586 optical transport path or a layer 2 Ethernet port or circuit at 587 the specified node. 589 Type 8: IPv6 Addresses for link endpoints as Local, Remote pair for 590 SR-MPLS: 591 This type allows identification of Adjacency SID (as defined in 592 [RFC8402]) or BGP EPE Peering SID (as defined in 593 [I-D.ietf-idr-bgpls-segment-routing-epe]) label for links with 594 Global IPv6 addresses. The headend is required to resolve the 595 specified Local IPv6 Address to the Node originating it and 596 then use the Remote IPv6 Address to identify the link adjacency 597 being referred to. The Local and Remote Address pair link 598 descriptors follows semantics as specified in [RFC7752]. 600 Type 9: IPv6 Global Prefix with optional SR Algorithm for SRv6: 601 The headend is required to resolve the specified IPv6 Global 602 Prefix Address to the SRv6 END function SID (as defined in 603 [I-D.filsfils-spring-srv6-network-programming]) corresponding 604 to the node which is originating the prefix. The SR Algorithm 605 (refer to Section 3.1.1 of [RFC8402]) to be used MAY also be 606 provided. 608 Type 10: IPv6 Prefix and Interface ID for link endpoints as Local, 609 Remote pair for SRv6: 610 This type allows identification of SRv6 END.X SID (as defined 611 in [I-D.filsfils-spring-srv6-network-programming]) for links 612 with only Link Local IPv6 addresses. The headend is required 613 to resolve the specified IPv6 Prefix Address to the Node 614 originating it and then use the Local Interface ID to identify 615 the point-to-point link whose adjacency is being referred to. 616 For other than point-to-point links, additionally the specific 617 adjacency needs to be resolved using the Remote Prefix and 618 Interface ID. The Local and Remote pair of Prefix and 619 Interface ID link descriptor follows semantics as specified in 620 [RFC7752]. 622 Type 11: IPv6 Addresses for link endpoints as Local, Remote pair for 623 SRv6: 624 This type allows identification of SRv6 END.X SID (as defined 625 in [I-D.filsfils-spring-srv6-network-programming]) for links 626 with Global IPv6 addresses. The headend is required to resolve 627 the specified Local IPv6 Address to the Node originating it and 628 then use the Remote IPv6 Address to identify the link adjacency 629 being referred to. The Local and Remote Address pair link 630 descriptors follows semantics as specified in [RFC7752]. 632 When the algorithm is not specified for the SID types above which 633 optionally allow for it, the headend SHOULD use the Strict Shortest 634 Path algorithm if available; otherwise it SHOULD use the default 635 Shortest Path algorithm. The specification of algorithm enables the 636 use of IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in 637 SR Policy. 639 For SID types 3-through-11, a SID value may also be optionally 640 provided to the headend for verification purposes. Section 5.1. 641 describes the resolution and verification of the SIDs and Segment 642 Lists on the headend. 644 When building the MPLS label stack or the IPv6 Segment list from the 645 Segment List, the node instantiating the policy MUST interpret the 646 set of Segments as follows: 648 o The first Segment represents the topmost label or the first IPv6 649 segment. It identifies the active segment the traffic will be 650 directed toward along the explicit SR path. 651 o The last Segment represents the bottommost label or the last IPv6 652 segment the traffic will be directed toward along the explicit SR 653 path. 655 4.1. Explicit Null 657 A Type 1 SID may be any MPLS label, including reserved labels. 659 For example, assuming that the desired traffic-engineered path from a 660 headend 1 to an endpoint 4 can be expressed by the Segment-List 661 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 662 to the IPv4 Prefix SIDs bound to node 2, 3 and 4, then IPv6 traffic 663 can be traffic-engineered from nodes 1 to 4 via the previously 664 described path using an SR Policy with Segment-List <16002, 16003, 665 16004, 2> where mpls label value of 2 represents the "IPv6 Explicit 666 NULL Label". 668 The penultimate node before node 4 will pop 16004 and will forward 669 the frame on its directly connected interface to node 4. 671 The endpoint receives the traffic with top label "2" which indicates 672 that the payload is an IPv6 packet. 674 When steering unlabeled IPv6 BGP destination traffic using an SR 675 policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit 676 Null Label Policy is processed as specified in 677 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 678 "IPv6 Explicit NULL label" is not present as the bottom label, the 679 headend SHOULD automatically impose one. Refer to Section 8 for more 680 details. 682 5. Validity of a Candidate Path 684 5.1. Explicit Candidate Path 686 An explicit candidate path is associated with a Segment-List or a set 687 of Segment-Lists. 689 An explicit candidate path is provisioned by the operator directly or 690 via a controller. 692 The computation/logic that leads to the choice of the Segment-List is 693 external to the SR Policy headend. The SR Policy headend does not 694 compute the Segment-List. The SR Policy headend only confirms its 695 validity. 697 A Segment-List of an explicit candidate path MUST be declared invalid 698 when: 700 o It is empty. 701 o Its weight is 0. 702 o The headend is unable to perform path resolution for the first SID 703 into one or more outgoing interface(s) and next-hop(s). 704 o The headend is unable to perform SID resolution for any non-first 705 SID of type 3-through-11 into an MPLS label or an SRv6 SID. 706 o The headend verification fails for any SID for which verification 707 has been explicitly requested. 709 "Unable to perform path resolution" means that the headend has no 710 path to the SID in its SR database. 712 SID verification is performed when the headend is explicitly 713 requested to verify SID(s) by the controller via the signaling 714 protocol used. Implementations MAY provide a local configuration 715 option to enable verification on a global or per policy or per 716 candidate path basis. 718 "Verification fails" for a SID means any of the following: 720 o The headend is unable to find the SID in its SR DB 721 o The headend detects mis-match between the SID value and its 722 context provided for SIDs of type 3-through-11 in its SR DB. 723 o The headend is unable to perform SID resolution for any non-first 724 SID of type 3-through-11 into an MPLS label or an SRv6 SID. 726 In multi-domain deployments, it is expected that the headend be 727 unable to verify the reachability of the SIDs in remote domains. 728 Types 1 or 2 MUST be used for the SIDs for which the reachability 729 cannot be verified. Note that the first SID MUST always be reachable 730 regardless of its type. 732 In addition, a Segment-List MAY be declared invalid when: 734 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 735 advertised by the node specified as the endpoint of the 736 corresponding SR policy. 737 o Its last segment is not an Adjacency SID (including BGP Peer 738 Adjacency SID) of any of the links present on neighbor nodes and 739 that terminate on the node specified as the endpoint of the 740 corresponding SR policy. 742 An explicit candidate path is invalid as soon as it has no valid 743 Segment-List. 745 5.2. Dynamic Candidate Path 747 A dynamic candidate path is specified as an optimization objective 748 and constraints. 750 The headend of the policy leverages its SR database to compute a 751 Segment-List ("solution Segment-List") that solves this optimization 752 problem. 754 The headend re-computes the solution Segment-List any time the inputs 755 to the problem change (e.g., topology changes). 757 When local computation is not possible (e.g., a policy's tailend is 758 outside the topology known to the headend) or not desired, the 759 headend MAY send path computation request to a PCE supporting PCEP 760 extension specified in [I-D.ietf-pce-segment-routing]. 762 If no solution is found to the optimization objective and 763 constraints, then the dynamic candidate path MUST be declared 764 invalid. 766 [I-D.filsfils-spring-sr-policy-considerations] discusses some of the 767 optimization objectives and constraints that may be considered by a 768 dynamic candidate path. It illustrates some of the desirable 769 properties of the computation of the solution Segment-List. 771 6. Binding SID 773 The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 774 It provides scaling, network opacity and service independence. 775 [I-D.filsfils-spring-sr-policy-considerations] illustrates some of 776 these benefits. This section describes the association of BSID with 777 an SR Policy. 779 6.1. BSID of a candidate path 781 Each candidate path MAY be defined with a BSID. 783 Candidate Paths of the same SR policy SHOULD have the same BSID. 785 Candidate Paths of different SR policies MUST NOT have the same BSID. 787 6.2. BSID of an SR Policy 789 The BSID of an SR Policy is the BSID of its active candidate path. 791 When the active candidate path has a specified BSID, the SR Policy 792 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 793 available (i.e., not associated with any other usage: e.g. to another 794 MPLS client, to another SID, to another SR Policy). 796 Optionally, instead of only checking that the BSID of the active path 797 is available, a headend MAY check that it is available within a given 798 SID range i.e., Segment Routing Local Block (SRLB) as specified in 799 [RFC8402]. 801 When the specified BSID is not available (optionally is not in the 802 SRLB), an alert message MUST be generated. 804 In the cases (as described above) where SR Policy does not have a 805 BSID available, then the SR Policy MAY dynamically bind a BSID to 806 itself. Dynamically bound BSID SHOULD use an available SID outside 807 the SRLB. 809 Assuming that at time t the BSID of the SR Policy is B1, if at time 810 t+dt a different candidate path becomes active and this new active 811 path does not have a specified BSID or its BSID is specified but is 812 not available (e.g. it is in use by something else), then the SR 813 Policy keeps the previous BSID B1. 815 The association of an SR Policy with a BSID thus MAY change over the 816 life of the SR Policy (e.g., upon active path change). Hence, the 817 BSID SHOULD NOT be used as an identification of an SR Policy. 819 6.2.1. Frequent use-case : unspecified BSID 821 All the candidate paths of the same SR Policy can have an unspecified 822 BSID. 824 In such a case, a BSID MAY be dynamically bound to the SR Policy as 825 soon as the first valid candidate path is received. That BSID is 826 kept along all the life of the SR Policy and across changes of active 827 candidate path. 829 6.2.2. Frequent use-case: all specified to the same BSID 831 All the paths of the SR Policy can have the same specified BSID. 833 6.2.3. Specified-BSID-only 835 An implementation MAY support the configuration of the Specified- 836 BSID-only restrictive behavior on the headend for all SR Policies or 837 individual SR Policies. Further, this restrictive behavior MAY also 838 be signaled on a per SR Policy basis to the headend. 840 When this restrictive behavior is enabled, if the candidate path has 841 an unspecified BSID or if the specified BSID is not available when 842 the candidate path becomes active then no BSID is bound to it and it 843 is considered invalid. An alert MUST be triggered for this error. 844 Other candidate paths MUST then be evaluated for becoming the active 845 candidate path. 847 6.3. Forwarding Plane 849 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 850 with the action of steering the packets matching this entry to the 851 selected path of the SR Policy. 853 If the Specified-BSID-only restrictive behavior is enabled and the 854 BSID of the active path is not available (optionally not in the 855 SRLB), then the SR Policy does not install any entry indexed by a 856 BSID in the forwarding plane. 858 6.4. Non-SR usage of Binding SID 860 An implementation MAY choose to associate a Binding SID with any type 861 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 862 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 863 tunnel, etc). This enables the use of other non-SR enabled 864 interfaces and tunnels as segments in an SR Policy Segment-List 865 without the need of forming routing protocol adjacencies over them. 867 The details of this kind of usage are beyond the scope of this 868 document. A specific packet optical integration use case is 869 described in [I-D.anand-spring-poi-sr] 871 7. SR Policy State 873 The SR Policy State is maintained on the headend to represent the 874 state of the policy and its candidate paths. This is to provide an 875 accurate representation of whether the SR Policy is being 876 instantiated in the forwarding plane and which of its candidate paths 877 and segment-list(s) are active. The SR Policy state MUST also 878 reflect the reason when a policy and/or its candidate path is not 879 active due to validation errors or not being preferred. 881 The SR Policy state can be reported by the headend node via BGP-LS 882 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 883 [I-D.sivabalan-pce-binding-label-sid]. 885 SR Policy state on the headend also includes traffic accounting 886 information for the flows being steered via the policies. The 887 details of the SR Policy accounting are beyond the scope of this 888 document. The aspects related to the SR traffic counters and their 889 usage in the broader context of traffic accounting in a SR network 890 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 891 [I-D.ali-spring-sr-traffic-accounting] respectively. 893 Implementations MAY support an administrative state to control 894 locally provisioned policies via mechanisms like CLI or NETCONF. 896 8. Steering into an SR Policy 898 A headend can steer a packet flow into a valid SR Policy in various 899 ways: 901 o Incoming packets have an active SID matching a local BSID at the 902 headend. 903 o Per-destination Steering: incoming packets match a BGP/Service 904 route which recurses on an SR policy. 906 o Per-flow Steering: incoming packets match or recurse on a 907 forwarding array of where some of the entries are SR Policies. 908 o Policy-based Steering: incoming packets match a routing policy 909 which directs them on an SR policy. 911 For simplicity of illustration, this document uses the SR-MPLS 912 example. 914 8.1. Validity of an SR Policy 916 An SR Policy is invalid when all its candidate paths are invalid as 917 described in Section 5 and Section 2.10. 919 By default, upon transitioning to the invalid state, 921 o an SR Policy and its BSID are removed from the forwarding plane. 922 o any steering of a service (PW), destination (BGP-VPN), flow or 923 packet on the related SR policy is disabled and the related 924 service, destination, flow or packet is routed per the classic 925 forwarding table (e.g. longest-match to the destination or the 926 recursing next-hop). 928 8.2. Drop upon invalid SR Policy 930 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 932 o an invalid SR Policy and its BSID is kept in the forwarding plane 933 with an action to drop. 934 o any steering of a service (PW), destination (BGP-VPN), flow or 935 packet on the related SR policy is maintained with the action to 936 drop all of this traffic. 938 The drop-upon-invalid behavior has been deployed in use-cases where 939 the operator wants some PW to only be transported on a path with 940 specific constraints. When these constraints are no longer met, the 941 operator wants the PW traffic to be dropped. Specifically, the 942 operator does not want the PW to be routed according to the IGP 943 shortest-path to the PW endpoint. 945 8.3. Incoming Active SID is a BSID 947 Let us assume that headend H has a valid SR Policy P of Segment-List 948 and BSID B. 950 When H receives a packet K with label stack , H pops B and 951 pushes and forwards the resulting packet according to 952 SID S1. 954 "Forwarding the resulting packet according to S1" means: If S1 is 955 an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H 956 sends the resulting packet with label stack on 957 the outgoing interface associated with S1; Else H sends the 958 resulting packet with label stack along the 959 path of S1. 961 H has steered the packet into the SR policy P. 963 H did not have to classify the packet. The classification was done 964 by a node upstream of H (e.g., the source of the packet or an 965 intermediate ingress edge node of the SR domain) and the result of 966 this classification was efficiently encoded in the packet header as a 967 BSID. 969 This is another key benefit of the segment routing in general and the 970 binding SID in particular: the ability to encode a classification and 971 the resulting steering in the packet header to better scale and 972 simplify intermediate aggregation nodes. 974 If the SR Policy P is invalid, the BSID B is not in the forwarding 975 plane and hence the packet K is dropped by H. 977 8.4. Per-Destination Steering 979 Let us assume that headend H: 981 o learns a BGP route R/r via next-hop N, extended-color community C 982 and VPN label V. 983 o has a valid SR Policy P to (color = C, endpoint = N) of Segment- 984 List and BSID B. 985 o has a BGP policy which matches on the extended-color community C 986 and allows its usage as SLA steering information. 988 If all these conditions are met, H installs R/r in RIB/FIB with next- 989 hop = SR Policy P of BSID B instead of via N. 991 Indeed, H's local BGP policy and the received BGP route indicate that 992 the headend should associate R/r with an SR Policy path to endpoint N 993 with the SLA associated with color C. The headend therefore installs 994 the BGP route on that policy. 996 This can be implemented by using the BSID as a generalized next-hop 997 and installing the BGP route on that generalized next-hop. 999 When H receives a packet K with a destination matching R/r, H pushes 1000 the label stack and sends the resulting packet along 1001 the path to S1. 1003 Note that any SID associated with the BGP route is inserted after the 1004 Segment-List of the SR Policy (i.e., ). 1006 The same behavior is applicable to any type of service route: any 1007 AFI/SAFI of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1009 8.4.1. Multiple Colors 1011 When a BGP route has multiple extended-color communities each with a 1012 valid SR Policy NLRI, the BGP process installs the route on the SR 1013 policy whose color is of highest numerical value. 1015 Let us assume that headend H: 1017 o learns a BGP route R/r via next-hop N, extended-color communities 1018 C1 and C2 and VPN label V. 1019 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1020 List and BSID B1. 1021 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1022 List and BSID B2. 1023 o has a BGP policy which matches on the extended-color communities 1024 C1 and C2 and allows their usage as SLA steering information 1026 If all these conditions are met, H installs R/r in RIB/FIB with next- 1027 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1029 8.5. Recursion on an on-demand dynamic BSID 1031 In the previous section, it was assumed that H had a pre-established 1032 "explicit" SR Policy (color C, endpoint N). 1034 In this section, independently to the a-priori existence of any 1035 explicit candidate path of the SR policy (C, N), it is to be noted 1036 that the BGP process at headend node H triggers the instantiation of 1037 a dynamic candidate path for the SR policy (C, N) as soon as: 1039 o the BGP process learns of a route R/r via N and with color C. 1040 o a local policy at node H authorizes the on-demand SR Policy path 1041 instantiation and maps the color to a dynamic SR Policy path 1042 optimization template. 1044 8.5.1. Multiple Colors 1046 When a BGP route R/r via N has multiple extended-color communities Ci 1047 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1048 request (color Ci, endpoint N) is triggered for each color Ci. 1050 8.6. Per-Flow Steering 1052 Let us assume that headend H: 1054 o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- 1055 List and BSID B1. 1056 o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- 1057 List and BSID B2. 1058 o is configured to instantiate an array of paths to N where the 1059 entry 0 is the IGP path to N, color C1 is the first entry and 1060 Color C2 is the second entry. The index into the array is called 1061 a Forwarding Class (FC). The index can have values 0 to 7. 1062 o is configured to match flows in its ingress interfaces (upon any 1063 field such as Ethernet destination/source/vlan/tos or IP 1064 destination/source/DSCP or transport ports etc.) and color them 1065 with an internal per-packet forwarding-class variable (0, 1 or 2 1066 in this example). 1068 If all these conditions are met, H installs in RIB/FIB: 1070 o N via a recursion on an array A (instead of the immediate outgoing 1071 link associated with the IGP shortest-path to N). 1072 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1073 path to N. 1074 o Entry A(1) set to SR Policy P1 of BSID=B1. 1075 o Entry A(2) set to SR Policy P2 of BSID=B2. 1077 H receives three packets K, K1 and K2 on its incoming interface. 1078 These three packets either longest-match on N or more likely on a 1079 BGP/service route which recurses on N. H colors these 3 packets 1080 respectively with forwarding-class 0, 1 and 2. As a result: 1082 o H forwards K along the shortest-path to N (which in SR-MPLS 1083 results in the pushing of the prefix-SID of N). 1084 o H pushes on packet K1 and forwards the resulting 1085 frame along the shortest-path to S1. 1086 o H pushes on packet K2 and forwards the resulting 1087 frame along the shortest-path to S4. 1089 If the local configuration does not specify any explicit forwarding 1090 information for an entry of the array, then this entry is filled with 1091 the same information as entry 0 (i.e. the IGP shortest-path). 1093 If the SR Policy mapped to an entry of the array becomes invalid, 1094 then this entry is filled with the same information as entry 0. When 1095 all the array entries have the same information as entry0, the 1096 forwarding entry for N is updated to bypass the array and point 1097 directly to its outgoing interface and next-hop. 1099 The array index values (e.g. 0, 1 and 2) and the notion of 1100 forwarding-class are implementation specific and only meant to 1101 describe the desired behavior. The same can be realized by other 1102 mechanisms. 1104 This realizes per-flow steering: different flows bound to the same 1105 BGP endpoint are steered on different IGP or SR Policy paths. 1107 A headend MAY support options to apply per-flow steering only for 1108 traffic matching specific prefixes (e.g. specific IGP or BGP 1109 prefixes). 1111 8.7. Policy-based Routing 1113 Finally, headend H may be configured with a local routing policy 1114 which overrides any BGP/IGP path and steer a specified packet on an 1115 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1116 automatic routing of IGP prefixes over SR Policies intended for such 1117 purpose. 1119 8.8. Optional Steering Modes for BGP Destinations 1121 8.8.1. Color-Only BGP Destination Steering 1123 In the previous section, it is seen that the steering on an SR Policy 1124 is governed by the matching of the BGP route's next-hop N and the 1125 authorized color C with an SR Policy defined by the tuple (N, C). 1127 This is the most likely form of BGP destination steering and the one 1128 recommended for most use-cases. 1130 This section defines an alternative steering mechanism based only on 1131 the color. 1133 This color-only steering variation is governed by two new flags "C" 1134 and "O" defined in the color extended community [ref draft-ietf-idr- 1135 segment-routing-te-policy section 3]. 1137 The Color-Only flags "CO" are set to 00 by default. 1139 When 00, the BGP destination is steered as follows: 1141 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1143 endpoint address and C is a color; 1144 Steer into SR Policy (N, C); 1145 ELSE; 1146 Steer on the IGP path to the next-hop N. 1148 This is the classic case described in this document previously and 1149 what is recommended in most scenarios. 1151 When 01, the BGP destination is steered as follows: 1153 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1155 endpoint address and C is a color; 1156 Steer into SR Policy (N, C); 1157 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1158 same address-family of N; 1159 Steer into SR Policy (null endpoint, C); 1160 ELSE IF there is any valid SR Policy 1161 (any address-family null endpoint, C); 1162 Steer into SR Policy (any null endpoint, C); 1163 ELSE; 1164 Steer on the IGP path to the next-hop N. 1166 When 10, the BGP destination is steered as follows: 1168 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1169 endpoint address and C is a color; 1170 Steer into SR Policy (N, C); 1171 ELSE IF there is a valid SR Policy (null endpoint, C) 1172 of the same address-family of N; 1173 Steer into SR Policy (null endpoint, C); 1174 ELSE IF there is any valid SR Policy 1175 (any address-family null endpoint, C); 1176 Steer into SR Policy (any null endpoint, C); 1177 ELSE IF there is any valid SR Policy (any endpoint, C) 1178 of the same address-family of N; 1179 Steer into SR Policy (any endpoint, C); 1180 ELSE IF there is any valid SR Policy 1181 (any address-family endpoint, C); 1182 Steer into SR Policy (any address-family endpoint, C); 1183 ELSE; 1184 Steer on the IGP path to the next-hop N. 1186 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1187 to the 0 value). 1189 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1190 reception, an implementations MUST treat it like 00. 1192 8.8.2. Multiple Colors and CO flags 1194 The steering preference is first based on highest color value and 1195 then CO-dependent for the color. Assuming a Prefix via (NH, 1196 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1198 o SR policy (NH, C1). 1199 o SR policy (null, C1). 1200 o SR policy (NH, C2). 1201 o SR policy (null, C2). 1202 o IGP to NH. 1204 8.8.3. Drop upon Invalid 1206 This document defined earlier that when all the following conditions 1207 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1208 BSID B instead of via N. 1210 o H learns a BGP route R/r via next-hop N, extended-color community 1211 C and VPN label V. 1212 o H has a valid SR Policy P to (color = C, endpoint = N) of Segment- 1213 List and BSID B. 1214 o H has a BGP policy which matches on the extended-color community C 1215 and allows its usage as SLA steering information. 1217 This behavior is extended by noting that the BGP policy may require 1218 the BGP steering to always stay on the SR policy whatever its 1219 validity. 1221 This is the "drop upon invalid" option described in Section 8.2 1222 applied to BGP-based steering. 1224 9. Protection 1226 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1228 In any topology, Topology-Independent Loop Free Alternate (TI-LFA) 1229 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1230 protection technique for IGP SIDs. The backup path is computed on a 1231 per IGP SID basis along the post-convergence path. 1233 In a network that has deployed TI-LFA, an SR Policy built on the 1234 basis of TI-LFA protected IGP segments leverages the local protection 1235 of the constituent segments. 1237 In a network that has deployed TI-LFA, an SR Policy instantiated only 1238 with non-protected Adj SIDs does not benefit from any local 1239 protection. 1241 9.2. Using an SR Policy to locally protect a link 1243 1----2-----6----7 1244 | | | | 1245 4----3-----9----8 1247 Figure 1: Local protection using SR Policy 1249 An SR Policy can be instantiated at node 2 to protect the link 2to6. 1250 A typical explicit Segment-List would be <3, 9, 6>. 1252 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1253 3 and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8 and 9 are part 1254 of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 cannot 1255 benefit from TI-LFA automated local protection. The SR Policy with 1256 Segment-List <3, 9, 6> on node 2 can be locally configured to be a 1257 fast-reroute backup path for the link 2to6. 1259 9.3. Using a Candidate Path for Path Protection 1261 An SR Policy allows for multiple candidate paths, of which at any 1262 point in time there is a single active candidate path that is 1263 provisioned in the forwarding plane and used for traffic steering. 1264 However, another (lower preference) candidate path MAY be designated 1265 as the backup for a specific or all (active) candidate path(s). The 1266 following options are possible: 1268 o A pair of disjoint candidate paths are provisioned with one of 1269 them as primary and the other is identified as its backup. 1270 o A specific candidate path is provisioned as the backup for any 1271 (active) candidate path. 1272 o The headend picks the next (lower) preference valid candidate path 1273 as the backup for the active candidate path. 1275 The headend MAY compute a-priori and validate such backup candidate 1276 paths as well as provision them into forwarding plane as backup for 1277 the active path. A fast re-route mechanism MAY then be used to 1278 trigger sub 50msec switchover from the active to the backup candidate 1279 path in the forwarding plane. Mechanisms like BFD MAY be used for 1280 fast detection of such failures. 1282 10. Security Considerations 1284 This document does not define any new protocol extensions and does 1285 not impose any additional security challenges. 1287 11. IANA Considerations 1289 This document has no actions for IANA. 1291 12. Acknowledgement 1293 The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger 1294 Geib and Rob Shakir for their valuable comments and suggestions. 1296 13. Contributors 1298 The following people have contributed to this document: 1300 Ketan Talaulikar 1301 Cisco Systems 1302 Email: ketant@cisco.com 1304 Zafar Ali 1305 Cisco Systems 1306 Email: zali@cisco.com 1308 Jose Liste 1309 Cisco Systems 1310 Email: jliste@cisco.com 1312 Francois Clad 1313 Cisco Systems 1314 Email: fclad@cisco.com 1316 Kamran Raza 1317 Cisco Systems 1318 Email: skraza@cisco.com 1320 Shraddha Hegde 1321 Juniper Networks 1322 Email: shraddha@juniper.net 1324 Steven Lin 1325 Google, Inc. 1326 Email: stevenlin@google.com 1328 Przemyslaw Krol 1329 Google, Inc. 1330 Email: pkrol@google.com 1332 Martin Horneffer 1333 Deutsche Telekom 1334 Email: martin.horneffer@telekom.de 1335 Dirk Steinberg 1336 Steinberg Consulting 1337 Email: dws@steinbergnet.net 1339 Bruno Decraene 1340 Orange Business Services 1341 Email: bruno.decraene@orange.com 1343 Stephane Litkowski 1344 Orange Business Services 1345 Email: stephane.litkowski@orange.com 1347 Luay Jalil 1348 Verizon 1349 Email: luay.jalil@verizon.com 1351 14. References 1353 14.1. Normative References 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, 1357 DOI 10.17487/RFC2119, March 1997, 1358 . 1360 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1361 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1362 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1363 July 2018, . 1365 14.2. Informative References 1367 [I-D.ali-spring-sr-traffic-accounting] 1368 Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., 1369 Horneffer, M., Raszuk, R., Litkowski, S., and d. 1370 daniel.voyer@bell.ca, "Traffic Accounting in Segment 1371 Routing Networks", draft-ali-spring-sr-traffic- 1372 accounting-02 (work in progress), June 2018. 1374 [I-D.anand-spring-poi-sr] 1375 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1376 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1377 Integration in Segment Routing", draft-anand-spring-poi- 1378 sr-07 (work in progress), January 2019. 1380 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 1381 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 1382 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 1383 Camarillo, "Topology Independent Fast Reroute using 1384 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 1385 lfa-05 (work in progress), October 2018. 1387 [I-D.filsfils-spring-sr-policy-considerations] 1388 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1389 P. Mattes, "SR Policy Implementation and Deployment 1390 Considerations", draft-filsfils-spring-sr-policy- 1391 considerations-03 (work in progress), April 2019. 1393 [I-D.filsfils-spring-sr-traffic-counters] 1394 Filsfils, C., Ali, Z., Horneffer, M., 1395 daniel.voyer@bell.ca, d., Durrani, M., and R. Raszuk, 1396 "Segment Routing Traffic Accounting Counters", draft- 1397 filsfils-spring-sr-traffic-counters-00 (work in progress), 1398 June 2018. 1400 [I-D.filsfils-spring-srv6-network-programming] 1401 Filsfils, C., Camarillo, P., Leddy, J., 1402 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1403 Network Programming", draft-filsfils-spring-srv6-network- 1404 programming-07 (work in progress), February 2019. 1406 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1407 Tantsura, J., Chunduri, U., Mirsky, G., Sivabalan, S., and 1408 N. Triantafillis, "Signaling MSD (Maximum SID Depth) using 1409 Border Gateway Protocol Link-State", draft-ietf-idr-bgp- 1410 ls-segment-routing-msd-04 (work in progress), February 1411 2019. 1413 [I-D.ietf-idr-bgpls-segment-routing-epe] 1414 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1415 S., and J. Dong, "BGP-LS extensions for Segment Routing 1416 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1417 segment-routing-epe-18 (work in progress), March 2019. 1419 [I-D.ietf-idr-segment-routing-te-policy] 1420 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 1421 E., and S. Lin, "Advertising Segment Routing Policies in 1422 BGP", draft-ietf-idr-segment-routing-te-policy-05 (work in 1423 progress), November 2018. 1425 [I-D.ietf-idr-te-lsp-distribution] 1426 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1427 H., and J. Tantsura, "Distribution of Traffic Engineering 1428 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1429 lsp-distribution-11 (work in progress), May 2019. 1431 [I-D.ietf-isis-segment-routing-msd] 1432 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1433 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 1434 ietf-isis-segment-routing-msd-19 (work in progress), 1435 October 2018. 1437 [I-D.ietf-lsr-flex-algo] 1438 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1439 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1440 algo-01 (work in progress), November 2018. 1442 [I-D.ietf-ospf-segment-routing-msd] 1443 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1444 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 1445 ietf-ospf-segment-routing-msd-25 (work in progress), 1446 October 2018. 1448 [I-D.ietf-pce-segment-routing] 1449 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1450 and J. Hardwick, "PCEP Extensions for Segment Routing", 1451 draft-ietf-pce-segment-routing-16 (work in progress), 1452 March 2019. 1454 [I-D.sivabalan-pce-binding-label-sid] 1455 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1456 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1457 in PCE-based Networks.", draft-sivabalan-pce-binding- 1458 label-sid-06 (work in progress), February 2019. 1460 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1461 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1462 December 1990, . 1464 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1465 DOI 10.17487/RFC2328, April 1998, 1466 . 1468 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1469 (TE) Extensions to OSPF Version 2", RFC 3630, 1470 DOI 10.17487/RFC3630, September 2003, 1471 . 1473 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1474 Reflection: An Alternative to Full Mesh Internal BGP 1475 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1476 . 1478 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1479 "Multiprotocol Extensions for BGP-4", RFC 4760, 1480 DOI 10.17487/RFC4760, January 2007, 1481 . 1483 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1484 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1485 2008, . 1487 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1488 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1489 . 1491 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1492 Locator/ID Separation Protocol (LISP)", RFC 6830, 1493 DOI 10.17487/RFC6830, January 2013, 1494 . 1496 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1497 Previdi, "OSPF Traffic Engineering (TE) Metric 1498 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1499 . 1501 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1502 S. Ray, "North-Bound Distribution of Link-State and 1503 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1504 DOI 10.17487/RFC7752, March 2016, 1505 . 1507 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1508 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1509 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1510 . 1512 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1513 Computation Element Communication Protocol (PCEP) 1514 Extensions for Stateful PCE", RFC 8231, 1515 DOI 10.17487/RFC8231, September 2017, 1516 . 1518 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1519 Computation Element Communication Protocol (PCEP) 1520 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1521 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1522 . 1524 Authors' Addresses 1526 Clarence Filsfils 1527 Cisco Systems, Inc. 1528 Pegasus Parc 1529 De kleetlaan 6a, DIEGEM BRABANT 1831 1530 BELGIUM 1532 Email: cfilsfil@cisco.com 1534 Siva Sivabalan (editor) 1535 Cisco Systems, Inc. 1536 2000 Innovation Drive 1537 Kanata, Ontario K2K 3E8 1538 Canada 1540 Email: msiva@cisco.com 1542 Daniel Voyer 1543 Bell Canada 1544 671 de la gauchetiere W 1545 Montreal, Quebec H3B 2M8 1546 Canada 1548 Email: daniel.voyer@bell.ca 1550 Alex Bogdanov 1551 Google, Inc. 1553 Email: bogdanov@google.com 1555 Paul Mattes 1556 Microsoft 1557 One Microsoft Way 1558 Redmond, WA 98052-6399 1559 USA 1561 Email: pamattes@microsoft.com