idnits 2.17.1 draft-filsfils-spring-segment-routing-policy-06.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 21, 2018) is 2164 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) == Missing Reference: 'I-D.filsfils-spring-sr-policy-considerations' is mentioned on line 793, but not defined == Outdated reference: A later version (-08) exists of draft-ali-spring-sr-traffic-accounting-00 == Outdated reference: A later version (-08) exists of draft-anand-spring-poi-sr-05 == Outdated reference: A later version (-05) exists of draft-bashandy-rtgwg-segment-routing-ti-lfa-04 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-01 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-03 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-08 == Outdated reference: A later version (-19) exists of draft-ietf-isis-segment-routing-msd-12 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-00 == Outdated reference: A later version (-25) exists of draft-ietf-ospf-segment-routing-msd-13 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-04 -- 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 (~~), 15 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 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: November 22, 2018 S. Hegde 6 Juniper Networks, Inc. 7 D. Voyer 8 Bell Canada. 9 S. Lin 10 A. Bogdanov 11 P. Krol 12 Google, Inc. 13 M. Horneffer 14 Deutsche Telekom 15 D. Steinberg 16 Steinberg Consulting 17 B. Decraene 18 S. Litkowski 19 Orange Business Services 20 P. Mattes 21 Microsoft 22 Z. Ali 23 K. Talaulikar 24 J. Liste 25 F. Clad 26 K. Raza 27 Cisco Systems, Inc. 28 May 21, 2018 30 Segment Routing Policy Architecture 31 draft-filsfils-spring-segment-routing-policy-06.txt 33 Abstract 35 Segment Routing (SR) allows a headend node to steer a packet flow 36 along any path. Intermediate per-flow states are eliminated thanks 37 to source routing. The headend node steers a flow into an SR Policy. 38 The header of a packet steered in an SR Policy is augmented with the 39 ordered list of segments associated with that SR Policy. This 40 document details the concepts of SR Policy and steering into an SR 41 Policy. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in [RFC2119]. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on November 22, 2018. 66 Copyright Notice 68 Copyright (c) 2018 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 86 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 5 87 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 5 88 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 6 89 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 7 90 2.6. Identification of a Candidate Path . . . . . . . . . . . 7 91 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8 92 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 8 93 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 8 94 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 9 95 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 9 96 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 10 97 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 11 99 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 12 100 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 15 101 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 16 102 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 16 103 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 17 104 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 18 106 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 18 107 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 19 108 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 19 109 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 19 110 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 20 111 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 20 112 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 21 113 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 21 114 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 22 115 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 23 116 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 23 117 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 24 118 8.8. Optional Steering Modes for BGP Destinations . . . . . . 24 119 9. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 27 120 9.1. Leveraging TI-LFA local protection of the constituent IGP 121 segments . . . . . . . . . . . . . . . . . . . . . . . . 27 122 9.2. Using an SR Policy to locally protect a link . . . . . . 27 123 9.3. Using a Candidate Path for Path Protection . . . . . . . 27 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 125 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 126 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 127 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 128 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 129 13.2. Informative References . . . . . . . . . . . . . . . . . 28 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 132 1. Introduction 134 Segment Routing (SR) allows a headend node to steer a packet flow 135 along any path. Intermediate per-flow states are eliminated thanks 136 to source routing [I-D.ietf-spring-segment-routing]. 138 The headend node is said to steer a flow into an Segment Routing 139 Policy (SR Policy). 141 The header of a packet steered in an SR Policy is augmented with the 142 ordered list of segments associated with that SR Policy. 144 This document details the concepts of SR Policy and steering into an 145 SR Policy. These apply equally to the MPLS and SRv6 instantiations 146 of segment routing. 148 For reading simplicity, the illustrations are provided for the MPLS 149 instantiations. 151 2. SR Policy 153 An SR Policy is a framework that enables instantiation of an ordered 154 list of segments on a node for implementing a source routing policy 155 with a specific intent for traffic steering from that node. 157 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 158 specifies that any instruction can be bound to a segment. Thus, an 159 SR Policy can be built using any types of Segment Identifiers (SIDs) 160 including those associated with topological or service instructions. 162 This section defines the key aspects and constituents of an SR 163 Policy. 165 2.1. Identification of an SR Policy 167 An SR Policy is identified through the tuple . In the context of a specific headend, one may identify an 169 SR policy by the tuple. 171 The headend is the node where the policy is instantiated/implemented. 172 The headend is specified as an IPv4 or IPv6 address. 174 The endpoint indicates the destination of the policy. The endpoint 175 is specified as an IPv4 or IPv6 address. In a specific case (refer 176 to Section 8.8.1), the endpoint can be the null address (0.0.0.0 for 177 IPv4, ::0 for IPv6). 179 The color is a 32-bit numerical value that associates the SR Policy 180 with an intent (e.g. low-latency). 182 The endpoint and the color are used to automate the steering of 183 service or transport routes on SR Policies (refer to Section 8). 185 An implementation MAY allow assignment of a symbolic name comprising 186 of printable ASCII characters to an SR Policy to serve as an user- 187 friendly attribute for debug and troubleshooting purposes. Such 188 symbolic names MUST NOT be considered as identifiers for an SR 189 Policy. 191 2.2. Candidate Path and Segment List 193 An SR Policy is associated with one or more candidate paths. A 194 candidate path is the unit for signaling of an SR Policy to a headend 195 via protocols like Path Computation Element (PCE) Communication 196 Protocol (PCEP) [RFC8281] or BGP SR Policy 197 [I-D.ietf-idr-segment-routing-te-policy]. 199 A candidate path is itself associated with a Segment-List (SID-List) 200 or a set of SID-Lists. 202 A SID-List represents a specific source-routed way to send traffic 203 from the headend to the endpoint of the corresponding SR policy. 205 A candidate path is either dynamic or explicit. 207 An explicit candidate path is associated with a SID-List or a set of 208 SID-Lists. 210 A dynamic candidate path expresses an optimization objective and a 211 set of constraints. The headend (potentially with the help of a PCE) 212 computes the solution SID-List (or set of SID-Lists) that solves the 213 optimization problem. 215 When a candidate path is associated with a set of SID-Lists, each 216 SID-List is associated with a weight for weighted load balancing 217 (refer Section 2.11 for details). The default weight is 1. 219 A variation of SR Policy can be used for packet replication. A 220 candidate path could comprise multiple SID-Lists; one for each 221 replication path. In such a scenario, packets are actually 222 replicated through each SID List of the SR Policy to realize a point- 223 to-multipoint service delivery. The weight of each SID-List does not 224 come into the picture in this case since there is no load-balancing. 225 The details of this and other such mechanisms for use of SR Policy 226 for point-to-multipoint delivery are outside the scope of this 227 document. 229 2.3. Protocol-Origin of a Candidate Path 231 A headend may be informed about a candidate path for an SR Policy 232 by various means including: via configuration, PCEP 233 [RFC8281] or BGP [I-D.ietf-idr-segment-routing-te-policy]. 235 Protocol-Origin of a candidate path is an 8-bit value which 236 identifies the component or protocol that originates or signals the 237 candidate path. 239 The table below specifies the RECOMMENDED default values: 241 +-------+---------------------------------------------------------+ 242 | Value | Protocol-Origin | 243 +-------+---------------------------------------------------------+ 244 | 10 | PCEP | 245 | 20 | BGP SR Policy | 246 | 30 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) | 247 +-------+---------------------------------------------------------+ 249 Table 1: Protocol-origin Identifier 251 Implementations MAY allow modifications of these default values 252 assigned to protocols on the headend along similar lines as a routing 253 administrative distance. Its application in the candidate path 254 selection is described in Section 2.9. 256 2.4. Originator of a Candidate Path 258 Originator identifies the node which provisioned or signalled the 259 candidate path on the headend. The originator is expressed in the 260 form of a 160 bit numerical value formed by the concatenation of the 261 fields of the tuple as below: 263 o ASN : represented as a 4 byte number. 265 o Node Address : represented as a 128 bit value. IPv4 addresses are 266 encoded in the lowest 32 bits. 268 Its application in the candidate path selection is described in 269 Section 2.9. 271 When Protocol-Origin is Local, the ASN and node address MAY be set to 272 either the headend or the provisioning controller/node ASN and 273 address. Default value is 0 for both AS and node address. 275 When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the 276 PCE and the AS number SHOULD be set to 0 by default when not 277 available or known. 279 Protocol-Origin is BGP SR Policy, it is provided by the BGP component 280 on the headend and is: 282 o the BGP Router ID and ASN of the node/controller signalling the 283 candidate path when it has a BGP session to the headend, OR 285 o the BGP Router ID of the eBGP peer signalling the candidate path 286 along with ASN of origin when the signalling is done via one or 287 more intermediate eBGP routers, OR 289 o the BGP Originator ID [RFC4456] and the ASN of the node/controller 290 when the signalling is done via one or more route-reflectors over 291 iBGP session. 293 2.5. Discriminator of a Candidate Path 295 The Discriminator is a 32 bit value associated with a candidate path 296 that uniquely identifies it within the context of an SR Policy from a 297 specific Protocol-Origin as specified below: 299 When Protocol-Origin is Local, this is an implementation's 300 configuration model specific unique identifier for a candidate path. 301 Default value is 0. 303 When PCEP is the Protocol-Origin, the method to uniquely identify 304 signalled path will be specified in a future PCEP document. Default 305 value is 0. 307 When BGP SR Policy is the Protocol-Origin, it is the distinguisher 308 specified in Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]. 310 Its application in the candidate path selection is described in 311 Section 2.9. 313 2.6. Identification of a Candidate Path 315 A candidate path is identified in the context of a single SR Policy. 317 A candidate path is not shared across SR Policies. 319 A candidate path is not identified by its SID-List(s). 321 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 322 candidate path of SR Policy Pol2, then these two candidate paths 323 are independent, even if they happen to have the same SID-List. 324 The SID-List does not identify a candidate path. The SID-List is 325 an attribute of a candidate path. 327 The identity of a candidate path MUST be uniquely established in the 328 context of an SR Policy in order to handle 329 add, delete or modify operations on them in an unambiguous manner 330 regardless of their source(s). 332 The tuple uniquely 333 identify a candidate path. 335 Candidate paths MAY also be assigned or signaled with a symbolic name 336 comprising printable ASCII characters to serve as a user-friendly 337 attribute for debug and troubleshooting purposes. Such symbolic 338 names MUST NOT be considered as identifiers for a candidate path. 340 2.7. Preference of a Candidate Path 342 The preference of the candidate path is used to select the best 343 candidate path for an SR Policy. The default preference is 100. 345 It is RECOMMENDED that each candidate path of a given SR policy has a 346 different preference. 348 2.8. Validity of a Candidate Path 350 A candidate path is valid if it is usable. A common path validity 351 criterion is the reachability of its constituent SIDs. The 352 validation rules are specified in Section 5. 354 2.9. Active Candidate Path 356 A candidate path is selected when it is valid and it is determined to 357 be the best path of the SR Policy. The selected path is referred to 358 as the "active path" of the SR policy in this document. 360 Whenever a new path is learned or an active path is deleted, the 361 validity of an existing path changes or an existing path is changed, 362 the selection process MUST be re-executed. 364 The candidate path selection process operates on the candidate path 365 Preference. A candidate path is selected when it is valid and it has 366 the highest preference value among all the candidate paths of the SR 367 Policy. 369 In the case of multiple valid candidate paths of the same preference, 370 the tie-breaking rules are evaluated on the identification tuple in 371 the following order until only one valid best path is selected: 373 1. Higher value of Protocol-Origin is selected. 375 2. Lower value of originator is selected. 377 3. Finally, the higher value of discriminator is selected. 379 An implementation MAY choose to override any of the tie-breaking 380 rules above and maintain the already selected candidate path as 381 active path. 383 The rules are framed with multiple protocols and sources in mind and 384 hence may not follow the logic of a single protocol (e.g. BGP best 385 path selection). The motivation behind these rules are as follows: 387 o The Protocol-Origin allows an operator to setup a default 388 selection mechanism across protocol sources, e.g., to prefer 389 locally provisioned over paths signalled via BGP SR Policy or 390 PCEP. 392 o The preference, being the first tiebreaker, allows an operator to 393 influence selection across paths thus allowing provisioning of 394 multiple path options, e.g., CP1 is preferred and if it becomes 395 invalid then fall-back to CP2 and so on. Since preference works 396 across protocol sources it also enables (where necessary) 397 selective override of the default protocol-origin preference, 398 e.g., to prefer a path signalled via BGP SR Policy over what is 399 locally provisioned. 401 o The originator allows an operator to have multiple redundant 402 controllers and still maintain a deterministic behaviour over 403 which of them are preferred even if they are providing the same 404 candidate paths for the same SR policies to the headend. 406 o The discriminator performs the final tiebreaking step to ensure a 407 deterministic outcome of selection regardless of the order in 408 which candidate paths are signalled across multiple transport 409 channels or sessions. 411 [I-D.filsfils-spring-sr-policy-considerations] provides a set of 412 examples to illustrate the active candidate path selection rules. 414 2.10. Validity of an SR Policy 416 An SR Policy is valid when it has at least one valid candidate path. 418 2.11. Instantiation of an SR Policy in the Forwarding Plane 420 A valid SR Policy is instantiated in the forwarding plane. 422 Only the active candidate path is used for forwarding traffic that is 423 being steered onto that policy. 425 If a set of SID-Lists is associated with the active path of the 426 policy, then the steering is per flow and W-ECMP based according to 427 the relative weight of each SID-List. 429 The fraction of the flows associated with a given SID-List is w/Sw 430 where w is the weight of the SID-List and Sw is the sum of the 431 weights of the SID-Lists of the selected path of the SR Policy. 433 The accuracy of the weighted load-balancing depends on the platform 434 implementation. 436 2.12. Priority of an SR Policy 438 Upon topological change, many policies could be recomputed. An 439 implementation MAY provide a per-policy priority configuration. The 440 operator MAY set this field to indicate order in which the policies 441 should be re-computed. Such a priority is represented by an integer 442 in the range (0, 255) where the lowest value is the highest priority. 443 The default value of priority is 128. 445 An SR Policy may comprise multiple Candidate Paths received from the 446 same or different sources. A candidate path MAY be signaled with a 447 priority value. When an SR Policy has multiple candidate paths with 448 distinct signaled non-default priority values, the SR Policy as a 449 whole takes the lowest value (i.e. the highest priority) amongst 450 these signaled priority values. 452 2.13. Summary 454 In summary, the information model is the following: 456 SR policy POL1 457 Candidate-path CP1 459 Preference 200 460 Weight W1, SID-List1 461 Weight W2, SID-List2 462 Candidate-path CP2 464 Preference 100 465 Weight W3, SID-List3 466 Weight W4, SID-List4 468 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 470 identified by a tuple . 471 CP1 is the active candidate path (it is valid and it has the highest 472 preference). The two SID-Lists of CP1 are installed as the 473 forwarding instantiation of SR policy Pol1. Traffic steered on Pol1 474 is flow-based hashed on SID-List with a ratio 475 W1/(W1+W2). 477 3. Segment Routing Database 479 An SR headend maintains the Segment Routing Database (SR-DB). 481 An SR headend leverages the SR-DB to validate explicit candidate 482 paths and compute dynamic candidate paths. 484 The information in the SR-DB MAY include: 486 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 487 OSPF [RFC2328] [RFC5340]) 488 o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj- 489 SIDs, BGP Peering SID, SRv6 SIDs) 490 [I-D.ietf-spring-segment-routing] 491 [I-D.ietf-idr-bgpls-segment-routing-epe] 492 [I-D.filsfils-spring-srv6-network-programming] 493 o TE Link Attributes (such as TE metric, SRLG, attribute-flag, 494 extended admin group) [RFC5305] [RFC3630]. 495 o Extended TE Link attributes (such as latency, loss) [RFC7810] 496 [RFC7471] 497 o Inter-AS Topology information 498 [I-D.ietf-idr-bgpls-segment-routing-epe]. 500 The attached domain topology MAY be learned via IGP, BGP-LS or 501 NETCONF. 503 A non-attached (remote) domain topology MAY be learned via BGP-LS or 504 NETCONF. 506 In some use-cases, the SR-DB may only contain the attached domain 507 topology while in others, the SR-DB may contain the topology of 508 multiple domains and in this case it is multi-domain capable. 510 The SR-DB MAY also contain the SR Policies instantiated in the 511 network. This can be collected via BGP-LS 512 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 513 [I-D.sivabalan-pce-binding-label-sid]. This information allows to 514 build an end-to-end policy on the basis of intermediate SR policies 515 (see Section 6 for further details). 517 The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of 518 nodes in the topology. This can be collected via ISIS 519 [I-D.ietf-isis-segment-routing-msd], OSPF 520 [I-D.ietf-ospf-segment-routing-msd], BGP-LS 522 [I-D.ietf-idr-bgp-ls-segment-routing-msd] or PCEP 523 [I-D.ietf-pce-segment-routing]. 525 The use of the SR-DB for computation and validation of SR Policies is 526 outside the scope of this document. Some implementation aspects 527 related to this are covered in [I-D.filsfils-spring-sr-policy- 528 considerations]. 530 4. Segment Types 532 A SID-List is an ordered set of segments represented as where S1 is the first segment. 535 Based on the desired dataplane, either the MPLS label stack or the 536 SRv6 SRH is built from the SID-List. However, the SID-List itself 537 can specified using different segment-descriptor types and the 538 following are currently defined: 540 Type 1: SR-MPLS Label: 541 A MPLS label corresponding to any of the segment types defined 542 for SR-MPLS (as defined in [I-D.ietf-spring-segment-routing] or 543 other SR-MPLS specifications) can be used. Additionally, 544 reserved labels like explicit-null or in general any MPLS label 545 may also be used. e.g. this type can be used to specify a 546 label representation which maps to an optical transport path on 547 a packet transport node. This type does not require the 548 headend to perform SID resolution. 550 Type 2: SRv6 SID: 551 An IPv6 address corresponding to any of the segment types 552 defined for SRv6 (as defined in 553 [I-D.filsfils-spring-srv6-network-programming] or other SRv6 554 specifications) can be used. This type does not require the 555 headend to perform SID resolution. 557 Type 3: IPv4 Prefix with optional SR Algorithm: 558 The headend is required to resolve the specified IPv4 Prefix 559 Address to the SR-MPLS label corresponding to a Prefix SID 560 segment (as defined in [I-D.ietf-spring-segment-routing]). The 561 SR algorithm (refer to Section 3.1.1 of 562 [I-D.ietf-spring-segment-routing]) to be used MAY also be 563 provided. 565 Type 4: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 566 In this case the headend is required to resolve the specified 567 IPv6 Global Prefix Address to the SR-MPLS label corresponding 568 to its Prefix SID segment (as defined in 569 [I-D.ietf-spring-segment-routing]). The SR Algorithm (refer to 570 Section 3.1.1 of [I-D.ietf-spring-segment-routing]) to be used 571 MAY also be provided. 573 Type 5: IPv4 Prefix with Local Interface ID: 574 This type allows identification of Adjacency SID (as defined in 575 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 576 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 577 point-to-point links including IP unnumbered links. The 578 headend is required to resolve the specified IPv4 Prefix 579 Address to the Node originating it and then use the Local 580 Interface ID to identify the point-to-point link whose 581 adjacency is being referred to. The Local Interface ID link 582 descriptor follows semantics as specified in [RFC7752]. This 583 type can also be used to indicate indirection into a layer 2 584 interface (i.e. without IP address) like a representation of an 585 optical transport path or a layer 2 Ethernet port or circuit at 586 the specified node. 588 Type 6: IPv4 Addresses for link endpoints as Local, Remote pair: 589 This type allows identification of Adjacency SID (as defined in 590 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 591 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 592 links. The headend is required to resolve the specified IPv4 593 Local Address to the Node originating it and then use the IPv4 594 Remote Address to identify the link adjacency being referred 595 to. The Local and Remote Address pair link descriptors follows 596 semantics as specified in [RFC7752]. 598 Type 7: IPv6 Prefix and Interface ID for link endpoints as Local, 599 Remote pair for SR-MPLS: 600 This type allows identification of Adjacency SID (as defined in 601 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 602 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 603 links including those with only Link Local IPv6 addresses. The 604 headend is required to resolve the specified IPv6 Prefix 605 Address to the Node originating it and then use the Local 606 Interface ID to identify the point-to-point link whose 607 adjacency is being referred to. For other than point-to-point 608 links, additionally the specific adjacency over the link needs 609 to be resolved using the Remote Prefix and Interface ID. The 610 Local and Remote pair of Prefix and Interface ID link 611 descriptor follows semantics as specified in [RFC7752]. This 612 type can also be used to indicate indirection into a layer 2 613 interface (i.e. without IP address) like a representation of an 614 optical transport path or a layer 2 Ethernet port or circuit at 615 the specified node. 617 Type 8: IPv6 Addresses for link endpoints as Local, Remote pair for 618 SR-MPLS: 619 This type allows identification of Adjacency SID (as defined in 620 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 621 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 622 links with Global IPv6 addresses. The headend is required to 623 resolve the specified Local IPv6 Address to the Node 624 originating it and then use the Remote IPv6 Address to identify 625 the link adjacency being referred to. The Local and Remote 626 Address pair link descriptors follows semantics as specified in 627 [RFC7752]. 629 Type 9: IPv6 Global Prefix with optional SR Algorithm for SRv6: 630 The headend is required to resolve the specified IPv6 Global 631 Prefix Address to the SRv6 END function SID (as defined in 632 [I-D.filsfils-spring-srv6-network-programming]) corresponding 633 to the node which is originating the prefix. The SR Algorithm 634 (refer to Section 3.1.1 of [I-D.ietf-spring-segment-routing]) 635 to be used MAY also be provided. 637 Type 10: IPv6 Prefix and Interface ID for link endpoints as Local, 638 Remote pair for SRv6: 639 This type allows identification of SRv6 END.X SID (as defined 640 in [I-D.filsfils-spring-srv6-network-programming]) for links 641 with only Link Local IPv6 addresses. The headend is required 642 to resolve the specified IPv6 Prefix Address to the Node 643 originating it and then use the Local Interface ID to identify 644 the point-to-point link whose adjacency is being referred to. 645 For other than point-to-point links, additionally the specific 646 adjacency needs to be resolved using the Remote Prefix and 647 Interface ID. The Local and Remote pair of Prefix and 648 Interface ID link descriptor follows semantics as specified in 649 [RFC7752]. 651 Type 11: IPv6 Addresses for link endpoints as Local, Remote pair for 652 SRv6: 653 This type allows identification of SRv6 END.X SID (as defined 654 in [I-D.filsfils-spring-srv6-network-programming]) for links 655 with Global IPv6 addresses. The headend is required to resolve 656 the specified Local IPv6 Address to the Node originating it and 657 then use the Remote IPv6 Address to identify the link adjacency 658 being referred to. The Local and Remote Address pair link 659 descriptors follows semantics as specified in [RFC7752]. 661 When the algorithm is not specified for the SID types above which 662 optionally allow for it, the headend SHOULD use the Strict Shortest 663 Path algorithm if available; otherwise it SHOULD use the default 664 Shortest Path algorithm. The specification of algorithm enables the 665 use of IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in 666 SR Policy. 668 For SID types 3-through-11, a SID value may also be optionally 669 provided to the headend for verification purposes. Section 5.1. 670 describes the resolution and verification of the SIDs and Segment 671 Lists on the headend. 673 When building the MPLS label stack or the IPv6 Segment list from the 674 Segment List, the node instantiating the policy MUST interpret the 675 set of Segments as follows: 677 o The first Segment represents the topmost label or the first IPv6 678 segment. It identifies the first segment the traffic will be 679 directed toward along the SR explicit path. 680 o The last Segment represents the bottommost label or the last IPv6 681 segment the traffic will be directed toward along the SR explicit 682 path. 684 4.1. Explicit Null 686 A Type 1 SID may be any MPLS label, including reserved labels. 688 For example, assuming that the desired traffic-engineered path from a 689 headend 1 to an endpoint 4 can be expressed by the SID-List <16002, 690 16003, 16004> where 16002, 16003 and 16004 respectively refer to the 691 IPv4 Prefix SIDs bound to node 2, 3 and 4, then IPv6 traffic can be 692 traffic-engineered from nodes 1 to 4 via the previously described 693 path using an SR Policy with SID-List <16002, 16003, 16004, 2> where 694 mpls label value of 2 represents the "IPv6 Explicit NULL Label". 696 The penultimate node before node 4 will pop 16004 and will forward 697 the frame on its directly connected interface to node 4. 699 The endpoint receives the traffic with top label "2" which indicates 700 that the payload is an IPv6 packet. 702 When steering unlabeled IPv6 BGP destination traffic using an SR 703 policy composed of SID-List(s) based on IPv4 SIDs, the Explicit Null 704 Label Policy is processed as specified in 705 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 706 "IPv6 Explicit NULL label" is not present as the bottom label, the 707 headend SHOULD automatically impose one. Refer to Section 8) later 708 in this document for more details. 710 5. Validity of a Candidate Path 712 5.1. Explicit Candidate Path 714 An explicit candidate path is associated with a SID-List or a set of 715 SID-Lists. 717 An explicit candidate path is provisioned by the operator directly or 718 via a controller. 720 The computation/logic that leads to the choice of the SID list is 721 external to the SR Policy headend. The SR Policy headend does not 722 compute the SID list. The SR Policy headend only confirms its 723 validity. 725 A SID-List of an explicit candidate path MUST be declared invalid 726 when: 728 o It is empty. 729 o Its weight is 0. 730 o The headend is unable to resolve the first SID into one or more 731 outgoing interface(s) and next-hop(s). 732 o The headend is unable to resolve any non-first SID of type 733 3-through-11 into an MPLS label or an SRv6 SID. 734 o The headend verification fails for any SID for which verification 735 has been explicitly requested. 737 "Unable to resolve" means that the headend has no path to the SID in 738 its SR database. 740 SID verification is performed when the headend is explicitly 741 requested to verify SID(s) by the controller via the signaling 742 protocol used. Implementations MAY provide a local configuration 743 option to enable verification on a global or per policy or per 744 candidate path basis. 746 "Verification fails" for a SID means any of the following: 748 o The headend is unable to find the SID in its SR DB 749 o The headend detects mis-match between the SID value and its 750 context provided for SIDs of type 3-through-11 in its SR DB. 751 o The headend is unable to resolve any non-first SID of type 752 3-through-11 into an MPLS label or an SRv6 SID. 754 In multi-domain deployments, it is expected that the headend be 755 unable to verify the reachability of the SIDs in remote domains. 756 Types A or B MUST be used for the SIDs for which the reachability 757 cannot be verified. Note that the first SID MUST always be reachable 758 regardless of its type. 760 In addition, a SID-List MAY be declared invalid when: 762 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 763 advertised by the node specified as the endpoint of the 764 corresponding SR policy. 765 o Its last segment is not an Adjacency SID (including BGP Peer 766 Adjacency SID) of any of the links present on neighbor nodes and 767 that terminate on the node specified as the endpoint of the 768 corresponding SR policy. 770 An explicit candidate path is invalid as soon as it has no valid SID- 771 List. 773 5.2. Dynamic Candidate Path 775 A dynamic candidate path is specified as an optimization objective 776 and constraints. 778 The headend of the policy leverages its SR database to compute a SID- 779 List ("solution SID-List") that solves this optimization problem. 781 The headend re-computes the solution SID-List any time the inputs to 782 the problem change (e.g., topology changes). 784 When local computation is not possible (e.g., a policy's tailend is 785 outside the topology known to the headend) or not desired, the 786 headend MAY send path computation request to a PCE supporting PCEP 787 extension specified in [I-D.ietf-pce-segment-routing]. 789 If no solution is found to the optimization objective and 790 constraints, then the dynamic candidate path MUST be declared 791 invalid. 793 [I-D.filsfils-spring-sr-policy-considerations] discusses some of the 794 optimization objectives and constraints that may be considered by a 795 dynamic candidate path. It illustrates some of the desirable 796 properties of the computation of the solution SID list. 798 6. Binding SID 800 The Binding SID (BSID) is fundamental to Segment Routing 801 [I-D.ietf-spring-segment-routing]. It provides scaling, network 802 opacity and service independence. [I-D.filsfils-spring-sr-policy- 803 considerations] illustrates some of these benefits. 805 6.1. BSID of a candidate path 807 Each candidate path MAY be defined with a BSID. 809 Candidate Paths of the same SR policy SHOULD have the same BSID. 811 Candidate Paths of different SR policies MUST NOT have the same BSID. 813 6.2. BSID of an SR Policy 815 The BSID of an SR policy is the BSID of its active candidate path. 817 When the active candidate path has a specified BSID, the SR Policy 818 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 819 available (i.e., not associated with any other usage: e.g. to another 820 MPLS client, to another SID, to another SR Policy). 822 Optionally, instead of only checking that the BSID of the active path 823 is available, a headend MAY check that it is available within a given 824 SID range i.e., Segment Routing Local Block (SRLB) as specified in 825 [I-D.ietf-spring-segment-routing]. 827 When the specified BSID is not available (optionally is not in the 828 SRLB), an alert message is generated. 830 In the cases (as described above) where SR Policy does not have a 831 BSID available, then the SR Policy MAY dynamically bind a BSID to 832 itself. Dynamically bound BSID SHOULD use an available SID outside 833 the SRLB. 835 Assuming that at time t the BSID of the SR Policy is B1, if at time 836 t+dt a different candidate path becomes active and this new active 837 path does not have a specified BSID or its BSID is specified but is 838 not available, then the SR Policy keeps the previous BSID B1. 840 The association of an SR Policy with a BSID thus MAY change over the 841 life of the SR policy (e.g., upon active path change). Hence, the 842 BSID cannot be used as an identification of an SR Policy. 844 6.2.1. Frequent use-cases : unspecified BSID 846 All the candidate paths of the same SR Policy can have an unspecified 847 BSID. 849 In such a case, a BSID MAY be dynamically bound to the SR Policy as 850 soon as the first valid candidate path is received. That BSID is 851 kept along all the life of the SR Policy and across changes of active 852 candidate path. 854 6.2.2. Frequent use-case: all specified to the same BSID 856 All the paths of the SR Policy can have the same specified BSID. 858 6.2.3. Specified-BSID-only 860 An implementation MAY support the configuration of the Specified- 861 BSID-only restrictive behavior on the headend for all SR Policies or 862 individual SR Policies. Further, this restrictive behavior MAY also 863 be signaled on a per SR Policy basis to the headend. 865 When this restrictive behavior is enabled, if the candidate path has 866 an unspecified BSID or if the specified BSID is not available when 867 the candidate path becomes active then no BSID is bound to it and it 868 is considered invalid. An alert is triggered. Other candidate paths 869 can then be evaluated for becoming the active candidate path. 871 6.3. Forwarding Plane 873 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 874 with the action of steering the packets matching this entry to the 875 selected path of the SR Policy. 877 If the Specified-BSID-only restrictive behavior is enabled and the 878 BSID of the active path is not available (optionally not in the 879 SRLB), then the SR Policy does not install any entry indexed by a 880 BSID in the forwarding plane. 882 6.4. Non-SR usage of Binding SID 884 An implementation MAY choose to associate a Binding SID with any type 885 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 886 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 887 tunnel, etc). This enables the use of other non-SR enabled 888 interfaces and tunnels as segments in an SR Policy SID-List without 889 the need of forming routing protocol adjacencies over them. 891 The details of this kind of usage are beyond the scope of this 892 document. A specific packet optical integration use case is 893 described in [I-D.anand-spring-poi-sr] 895 7. SR Policy State 897 The SR Policy State is maintained on the headend to represent the 898 state of the policy and its candidate paths. This is to provide an 899 accurate representation of whether the SR Policy is being 900 instantiated in the forwarding plane and which of its candidate paths 901 and segment-list(s) are active. The SR Policy state MUST also 902 reflect the reason when a policy and/or its candidate path is not 903 active due to validation errors or not being preferred. 905 The SR Policy state can be reported by the headend node via BGP-LS 906 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 907 [I-D.sivabalan-pce-binding-label-sid]. 909 SR Policy state on the headend also includes traffic accounting 910 information for the flows being steered via the policies. The 911 details of the SR Policy accounting are beyond the scope of this 912 document and [I-D.ali-spring-sr-traffic-accounting] covers these 913 aspects in the broader context of traffic accounting in a SR network. 915 Implementations MAY support an administrative state to control 916 locally provisioned policies via mechanisms like CLI or NETCONF. 918 8. Steering into an SR Policy 920 A headend can steer a packet flow into a valid SR Policy in various 921 ways: 923 o Incoming packets have an active SID matching a local BSID at the 924 headend. 925 o Per-destination Steering: incoming packets match a BGP/Service 926 route which recurses on an SR policy. 927 o Per-flow Steering: incoming packets match or recurse on a 928 forwarding array of where some of the entries are SR Policies. 929 o Policy-based Steering: incoming packets match a routing policy 930 which directs them on an SR policy. 932 For simplicity of illustration, this document uses the SR-MPLS 933 example. 935 8.1. Validity of an SR Policy 937 An SR Policy is invalid when all its candidate paths are invalid. 939 By default, upon transitioning to the invalid state, 941 o an SR Policy and its BSID are removed from the forwarding plane. 942 o any steering of a service (PW), destination (BGP-VPN), flow or 943 packet on the related SR policy is disabled and the related 944 service, destination, flow or packet is routed per the classic 945 forwarding table (e.g. longest-match to the destination or the 946 recursing next-hop). 948 8.2. Drop upon invalid SR Policy 950 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 952 o an invalid SR Policy and its BSID is kept in the forwarding plane 953 with an action to drop. 954 o any steering of a service (PW), destination (BGP-VPN), flow or 955 packet on the related SR policy is maintained with the action to 956 drop all of this traffic. 958 The drop-upon-invalid behavior has been deployed in use-cases where 959 the operator wants some PW to only be transported on a path with 960 specific constraints. When these constraints are no longer met, the 961 operator wants the PW traffic to be dropped. Specifically, the 962 operator does not want the PW to be routed according to the IGP 963 shortest-path to the PW endpoint. 965 8.3. Incoming Active SID is a BSID 967 Let us assume that headend H has a valid SR Policy P of SID-List and BSID B. 970 When H receives a packet K with label stack , H pops B and 971 pushes and forwards the resulting packet according to 972 SID S1. 974 "Forwarding the resulting packet according to S1" means: If S1 is 975 an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H 976 sends the resulting packet with label stack on 977 the outgoing interface associated with S1; Else H sends the 978 resulting packet with label stack along the 979 path of S1. 981 H has steered the packet in the SR policy P. 983 H did not have to classify the packet. The classification was done 984 by a node upstream of H (e.g., the source of the packet or an 985 intermediate ingress edge node of the SR domain) and the result of 986 this classification was efficiently encoded in the packet header as a 987 BSID. 989 This is another key benefit of the segment routing in general and the 990 binding SID in particular: the ability to encode a classification and 991 the resulting steering in the packet header to better scale and 992 simplify intermediate aggregation nodes. 994 If the SR Policy P is invalid, the BSID B is not in the forwarding 995 plane and hence the packet K is dropped by H. 997 8.4. Per-Destination Steering 999 Let us assume that headend H: 1001 o learns a BGP route R/r via next-hop N, extended-color community C 1002 and VPN label V. 1003 o has a valid SR Policy P to (endpoint = N, color = C) of SID-List 1004 and BSID B. 1005 o has a BGP policy which matches on the extended-color community C 1006 and allows its usage as SLA steering information. 1008 If all these conditions are met, H installs R/r in RIB/FIB with next- 1009 hop = SR Policy P of BSID B instead of via N. 1011 Indeed, H's local BGP policy and the received BGP route indicate that 1012 the headend should associate R/r with an SR Policy path to N with the 1013 SLA associated with color C. The headend therefore installs the BGP 1014 route on that policy. 1016 This can be implemented by using the BSID as a generalized next-hop 1017 and installing the BGP route on that generalized next-hop. 1019 When H receives a packet K with a destination matching R/r, H pushes 1020 the label stack and sends the resulting packet along 1021 the path to S1. 1023 Note that any SID associated with the BGP route is inserted after the 1024 SID-List of the SR Policy (i.e., ). 1026 The same behavior is applicable to any type of service route: any 1027 AFI/SAFI of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1029 8.4.1. Multiple Colors 1031 When a BGP route has multiple extended-color communities each with a 1032 valid SR Policy NLRI, the BGP process installs the route on the SR 1033 policy whose color is of highest numerical value. 1035 Let us assume that headend H: 1037 o learns a BGP route R/r via next-hop N, extended-color communities 1038 C1 and C2 and VPN label V. 1039 o has a valid SR Policy P1 to (endpoint = N, color = C1) of SID list 1040 and BSID B1. 1041 o has a valid SR Policy P2 to (endpoint = N, color = C2) of SID list 1042 and BSID B2. 1043 o has a BGP policy which matches on the extended-color communities 1044 C1 and C2 and allows their usage as SLA steering information 1046 If all these conditions are met, H installs R/r in RIB/FIB with next- 1047 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1049 8.5. Recursion on an on-demand dynamic BSID 1051 In the previous section, it was assumed that H had a pre-established 1052 "explicit" SR Policy (endpoint N, color C). 1054 In this section, independently to the a-priori existence of any 1055 explicit candidate path of the SR policy (N, C), it is to be noted 1056 that the BGP process at headend node H triggers the instantiation of 1057 a dynamic candidate path for the SR policy (N, C) as soon as: 1059 o the BGP process learns of a route R/r via N and with color C. 1060 o a local policy at node H authorizes the on-demand SR Policy path 1061 instantiation and maps the color to a dynamic SR Policy path 1062 optimization template. 1064 8.5.1. Multiple Colors 1066 When a BGP route R/r via N has multiple extended-color communities Ci 1067 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1068 request (endpoint N, color Ci) is triggered for each color Ci. 1070 8.6. Per-Flow Steering 1072 Let us assume that headend H: 1074 o has a valid SR Policy P1 to (endpoint = N, color = C1) of SID-List 1075 and BSID B1. 1076 o has a valid SR Policy P2 to (endpoint = N, color = C2) of SID-List 1077 and BSID B2. 1078 o is configured to instantiate an array of paths to N where the 1079 entry 0 is the IGP path to N, color C1 is the first entry and 1080 Color C2 is the second entry. The index into the array is called 1081 a Forwarding Class (FC). The index can have values 0 to 7. 1082 o is configured to match flows in its ingress interfaces (upon any 1083 field such as Ethernet destination/source/vlan/tos or IP 1084 destination/source/DSCP or transport ports etc.) and color them 1085 with an internal per-packet forwarding-class variable (0, 1 or 2 1086 in this example). 1088 If all these conditions are met, H installs in RIB/FIB: 1090 o N via a recursion on an array A (instead of the immediate outgoing 1091 link associated with the IGP shortest-path to N). 1092 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1093 path to N. 1095 o Entry A(1) set to SR Policy P1 of BSID=B1. 1096 o Entry A(2) set to SR Policy P2 of BSID=B2. 1098 H receives three packets K, K1 and K2 on its incoming interface. 1099 These three packets either longest-match on N or more likely on a 1100 BGP/service route which recurses on N. H colors these 3 packets 1101 respectively with forwarding-class 0, 1 and 2. As a result: 1103 o H forwards K along the shortest-path to N (which in SR-MPLS 1104 results in the pushing of the prefix-SID of N). 1105 o H pushes on packet K1 and forwards the resulting 1106 frame along the shortest-path to S1. 1107 o H pushes on packet K2 and forwards the resulting 1108 frame along the shortest-path to S4. 1110 If the local configuration does not specify any explicit forwarding 1111 information for an entry of the array, then this entry is filled with 1112 the same information as entry 0 (i.e. the IGP shortest-path). 1114 If the SR Policy mapped to an entry of the array becomes invalid, 1115 then this entry is filled with the same information as entry 0. When 1116 all the array entries have the same information as entry0, the 1117 forwarding entry for N is updated to bypass the array and point 1118 directly to its outgoing interface and next-hop. 1120 The array index values (e.g. 0, 1 and 2) and the notion of 1121 forwarding-class are implementation specific and only meant to 1122 describe the desired behavior. The same can be realized by other 1123 mechanisms. 1125 This realizes per-flow steering: different flows bound to the same 1126 BGP endpoint are steered on different IGP or SR Policy paths. 1128 8.7. Policy-based Routing 1130 Finally, headend H may be configured with a local routing policy 1131 which overrides any BGP/IGP path and steer a specified packet on an 1132 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1133 automatic routing of IGP prefixes over SR Policies intended for such 1134 purpose. 1136 8.8. Optional Steering Modes for BGP Destinations 1138 8.8.1. Color-Only BGP Destination Steering 1140 In the previous section, it is seen that the steering on an SR Policy 1141 is governed by the matching of the BGP route's next-hop N and the 1142 authorized color C with an SR Policy defined by the tuple (N, C). 1144 This is the most likely form of BGP destination steering and the one 1145 recommended for most use-cases. 1147 This section defines an alternative steering mechanism based only on 1148 the color. 1150 This color-only steering variation is governed by two new flags "C" 1151 and "O" defined in the color extended community [ref draft-ietf-idr- 1152 segment-routing-te-policy section 3]. 1154 The Color-Only flags "CO" are set to 00 by default. 1156 When 00, the BGP destination is steered as follows: 1158 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1160 endpoint address and C is a color; 1161 Steer into SR Policy (N, C); 1162 ELSE; 1163 Steer on the IGP path to the next-hop N. 1165 This is the classic case described in this document previously and 1166 what is recommended in most scenarios. 1168 When 01, the BGP destination is steered as follows: 1170 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1172 endpoint address and C is a color; 1173 Steer into SR Policy (N, C); 1174 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1175 same address-family of N; 1176 Steer into SR Policy (null endpoint, C); 1177 ELSE IF there is any valid SR Policy 1178 (any address-family null endpoint, C); 1179 Steer into SR Policy (any null endpoint, C); 1180 ELSE; 1181 Steer on the IGP path to the next-hop N. 1183 When 10, the BGP destination is steered as follows: 1185 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1186 endpoint address and C is a color; 1187 Steer into SR Policy (N, C); 1188 ELSE IF there is a valid SR Policy (null endpoint, C) 1189 of the same address-family of N; 1190 Steer into SR Policy (null endpoint, C); 1191 ELSE IF there is any valid SR Policy 1192 (any address-family null endpoint, C); 1193 Steer into SR Policy (any null endpoint, C); 1194 ELSE IF there is any valid SR Policy (any endpoint, C) 1195 of the same address-family of N; 1196 Steer into SR Policy (any endpoint, C); 1197 ELSE IF there is any valid SR Policy 1198 (any address-family endpoint, C); 1199 Steer into SR Policy (any address-family endpoint, C); 1200 ELSE; 1201 Steer on the IGP path to the next-hop N. 1203 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1204 to the 0 value). 1206 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1207 reception, an implementations MUST treat it like 00. 1209 8.8.2. Multiple Colors and CO flags 1211 The steering preference is first based on highest color value and 1212 then CO-dependent for the color. Assuming a Prefix via (NH, 1213 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1215 o SR policy (NH, C1). 1216 o SR policy (null, C1). 1217 o SR policy (NH, C2). 1218 o SR policy (null, C2). 1219 o IGP to NH. 1221 8.8.3. Drop upon Invalid 1223 This document defined earlier that when all the following conditions 1224 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1225 BSID B instead of via N. 1227 o H learns a BGP route R/r via next-hop N, extended-color community 1228 C and VPN label V. 1229 o H has a valid SR Policy P to (endpoint = N, color = C) of SID-List 1230 and BSID B. 1231 o H has a BGP policy which matches on the extended-color community C 1232 and allows its usage as SLA steering information. 1234 This behavior is extended by noting that the BGP policy may require 1235 the BGP steering to always stay on the SR policy whatever its 1236 validity. 1238 This is the "drop upon invalid" option described in section 10.2 1239 applied to BGP-based steering. 1241 9. Protection 1243 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1245 In any topology, Topology-Independent Loop Free Alternate (TI-LFA) 1246 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1247 protection technique for IGP SIDs. The backup path is computed on a 1248 per IGP SID basis along the post-convergence path. 1250 In a network that has deployed TI-LFA, an SR Policy built on the 1251 basis of TI-LFA protected IGP segments leverages the local protection 1252 of the constituent segments. 1254 In a network that has deployed TI-LFA, an SR Policy instantiated only 1255 with non-protected Adj SIDs does not benefit from any local 1256 protection. 1258 9.2. Using an SR Policy to locally protect a link 1260 1----2-----6----7 1261 | | | | 1262 4----3-----9----8 1264 Figure 1: Local protection using SR Policy 1266 An SR Policy can be instantiated at node 2 to protect the link 2to6. 1267 A typical explicit SID list would be <3, 9, 6>. 1269 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1270 3 and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8 and 9 are part 1271 of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 cannot 1272 benefit from TI-LFA automated local protection. 1274 9.3. Using a Candidate Path for Path Protection 1276 An SR Policy allows for multiple candidate paths, of which at any 1277 point in time there is a single active candidate path that is 1278 provisioned in the forwarding plane and used for traffic steering. 1279 However, another (lower preference) candidate path MAY be designated 1280 as the backup for a specific or all (active) candidate path(s). Such 1281 a backup candidate path is generally disjoint from the active 1282 candidate path. 1284 The headend MAY compute a-priori and validate such backup candidate 1285 paths as well as provision them into forwarding plane as backup for 1286 the active path. A fast re-route mechanism MAY then be used to 1287 trigger sub 50msec switchover from the active to the backup candidate 1288 path in the forwarding plane. Mechanisms like BFD MAY be used for 1289 fast detection of such failures. 1291 10. Security Considerations 1293 This document does not define any new protocol extensions and does 1294 not impose any additional security challenges. 1296 11. IANA Considerations 1298 This document has no actions for IANA. 1300 12. Acknowledgement 1302 The authors would like to thank Tarek Saad and Dhanendra Jain for 1303 their valuable comments and suggestions. 1305 13. References 1307 13.1. Normative References 1309 [I-D.ietf-spring-segment-routing] 1310 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1311 Litkowski, S., and R. Shakir, "Segment Routing 1312 Architecture", draft-ietf-spring-segment-routing-15 (work 1313 in progress), January 2018. 1315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1316 Requirement Levels", BCP 14, RFC 2119, 1317 DOI 10.17487/RFC2119, March 1997, 1318 . 1320 13.2. Informative References 1322 [I-D.ali-spring-sr-traffic-accounting] 1323 Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., 1324 Horneffer, M., Raszuk, R., Litkowski, S., and d. 1325 daniel.voyer@bell.ca, "Traffic Accounting in Segment 1326 Routing Networks", draft-ali-spring-sr-traffic- 1327 accounting-00 (work in progress), March 2018. 1329 [I-D.anand-spring-poi-sr] 1330 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1331 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1332 Integration in Segment Routing", draft-anand-spring-poi- 1333 sr-05 (work in progress), February 2018. 1335 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 1336 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 1337 Francois, P., and d. daniel.voyer@bell.ca, "Topology 1338 Independent Fast Reroute using Segment Routing", draft- 1339 bashandy-rtgwg-segment-routing-ti-lfa-04 (work in 1340 progress), April 2018. 1342 [I-D.filsfils-spring-srv6-network-programming] 1343 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 1344 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1345 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1346 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 1347 M. Sharif, "SRv6 Network Programming", draft-filsfils- 1348 spring-srv6-network-programming-04 (work in progress), 1349 March 2018. 1351 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1352 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 1353 "Signaling Maximum SID Depth using Border Gateway Protocol 1354 Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 1355 (work in progress), October 2017. 1357 [I-D.ietf-idr-bgpls-segment-routing-epe] 1358 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 1359 Dong, "BGP-LS extensions for Segment Routing BGP Egress 1360 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 1361 epe-15 (work in progress), March 2018. 1363 [I-D.ietf-idr-segment-routing-te-policy] 1364 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 1365 E., and S. Lin, "Advertising Segment Routing Policies in 1366 BGP", draft-ietf-idr-segment-routing-te-policy-03 (work in 1367 progress), May 2018. 1369 [I-D.ietf-idr-te-lsp-distribution] 1370 Previdi, S., Dong, J., Chen, M., Gredler, H., and J. 1371 Tantsura, "Distribution of Traffic Engineering (TE) 1372 Policies and State using BGP-LS", draft-ietf-idr-te-lsp- 1373 distribution-08 (work in progress), December 2017. 1375 [I-D.ietf-isis-segment-routing-msd] 1376 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1377 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 1378 ietf-isis-segment-routing-msd-12 (work in progress), May 1379 2018. 1381 [I-D.ietf-lsr-flex-algo] 1382 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1383 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1384 algo-00 (work in progress), May 2018. 1386 [I-D.ietf-ospf-segment-routing-msd] 1387 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1388 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 1389 ietf-ospf-segment-routing-msd-13 (work in progress), May 1390 2018. 1392 [I-D.ietf-pce-segment-routing] 1393 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1394 and J. Hardwick, "PCEP Extensions for Segment Routing", 1395 draft-ietf-pce-segment-routing-11 (work in progress), 1396 November 2017. 1398 [I-D.sivabalan-pce-binding-label-sid] 1399 Sivabalan, S., Tantsura, J., Filsfils, C., Previdi, S., 1400 Hardwick, J., and D. Dhody, "Carrying Binding Label/ 1401 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 1402 binding-label-sid-04 (work in progress), March 2018. 1404 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1405 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1406 December 1990, . 1408 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1409 DOI 10.17487/RFC2328, April 1998, 1410 . 1412 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1413 (TE) Extensions to OSPF Version 2", RFC 3630, 1414 DOI 10.17487/RFC3630, September 2003, 1415 . 1417 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1418 Reflection: An Alternative to Full Mesh Internal BGP 1419 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1420 . 1422 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1423 "Multiprotocol Extensions for BGP-4", RFC 4760, 1424 DOI 10.17487/RFC4760, January 2007, 1425 . 1427 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1428 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1429 2008, . 1431 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1432 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1433 . 1435 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1436 Locator/ID Separation Protocol (LISP)", RFC 6830, 1437 DOI 10.17487/RFC6830, January 2013, 1438 . 1440 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1441 Previdi, "OSPF Traffic Engineering (TE) Metric 1442 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1443 . 1445 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1446 S. Ray, "North-Bound Distribution of Link-State and 1447 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1448 DOI 10.17487/RFC7752, March 2016, 1449 . 1451 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1452 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1453 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1454 . 1456 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1457 Computation Element Communication Protocol (PCEP) 1458 Extensions for Stateful PCE", RFC 8231, 1459 DOI 10.17487/RFC8231, September 2017, 1460 . 1462 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1463 Computation Element Communication Protocol (PCEP) 1464 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1465 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1466 . 1468 Authors' Addresses 1469 Clarence Filsfils 1470 Cisco Systems, Inc. 1471 Pegasus Parc 1472 De kleetlaan 6a, DIEGEM BRABANT 1831 1473 BELGIUM 1475 Email: cfilsfil@cisco.com 1477 Siva Sivabalan 1478 Cisco Systems, Inc. 1479 2000 Innovation Drive 1480 Kanata, Ontario K2K 3E8 1481 Canada 1483 Email: msiva@cisco.com 1485 Shraddha Hegde 1486 Juniper Networks, Inc. 1487 Embassy Business Park 1488 Bangalore, KA 560093 1489 India 1491 Email: shraddha@juniper.net 1493 Daniel Voyer 1494 Bell Canada. 1495 671 de la gauchetiere W 1496 Montreal, Quebec H3B 2M8 1497 Canada 1499 Email: daniel.voyer@bell.ca 1501 Steven Lin 1502 Google, Inc. 1504 Email: stevenlin@google.com 1506 Alex Bogdanov 1507 Google, Inc. 1509 Email: bogdanov@google.com 1510 Przemyslaw Krol 1511 Google, Inc. 1513 Email: pkrol@google.com 1515 Martin Horneffer 1516 Deutsche Telekom 1518 Email: martin.horneffer@telekom.de 1520 Dirk Steinberg 1521 Steinberg Consulting 1523 Email: dws@steinbergnet.net 1525 Bruno Decraene 1526 Orange Business Services 1528 Email: bruno.decraene@orange.com 1530 Stephane Litkowski 1531 Orange Business Services 1533 Email: stephane.litkowski@orange.com 1535 Paul Mattes 1536 Microsoft 1537 One Microsoft Way 1538 Redmond, WA 98052-6399 1539 USA 1541 Email: pamattes@microsoft.com 1543 Zafar Ali 1544 Cisco Systems, Inc. 1546 Email: zali@cisco.com 1547 Ketan Talaulikar 1548 Cisco Systems, Inc. 1550 Email: ketant@cisco.com 1552 Jose Liste 1553 Cisco Systems, Inc. 1554 821 Alder Drive 1555 Milpitas, California 95035 1556 USA 1558 Email: jliste@cisco.com 1560 Francois Clad 1561 Cisco Systems, Inc. 1563 Email: fclad@cisco.com 1565 Kamran Raza 1566 Cisco Systems, Inc. 1567 2000 Innovation Drive 1568 Kanata, Ontario K2K 3E8 1569 Canada 1571 Email: skraza@cisco.com