idnits 2.17.1 draft-ietf-spring-segment-routing-policy-01.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 (June 11, 2018) is 2146 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-05 == Outdated reference: A later version (-05) exists of draft-bashandy-rtgwg-segment-routing-ti-lfa-04 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-01 == Outdated reference: A later version (-02) exists of draft-filsfils-spring-sr-traffic-counters-00 == 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-14 == 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 (~~), 16 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: December 13, 2018 D. Voyer 6 Bell Canada 7 A. Bogdanov 8 Google, Inc. 9 P. Mattes 10 Microsoft 11 June 11, 2018 13 Segment Routing Policy Architecture 14 draft-ietf-spring-segment-routing-policy-01.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 December 13, 2018. 49 Copyright Notice 51 Copyright (c) 2018 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 . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . 8 76 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 8 77 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 9 78 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 9 79 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 9 80 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 10 82 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 11 83 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 15 84 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 15 85 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 15 86 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 16 87 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 17 89 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 17 90 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 19 91 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 19 92 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 19 93 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 20 94 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 20 95 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 20 96 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 21 97 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 21 98 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 22 99 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 23 100 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 24 101 8.8. Optional Steering Modes for BGP Destinations . . . . . . 24 102 9. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 9.1. Leveraging TI-LFA local protection of the constituent IGP 104 segments . . . . . . . . . . . . . . . . . . . . . . . . 26 105 9.2. Using an SR Policy to locally protect a link . . . . . . 27 106 9.3. Using a Candidate Path for Path Protection . . . . . . . 27 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 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 [I-D.ietf-spring-segment-routing]. 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 [I-D.ietf-spring-segment-routing] 142 specifies that any instruction can be bound to a segment. Thus, an 143 SR Policy can be built using any type of Segment Identifier (SID) 144 including those 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. 158 The endpoint indicates the destination of the policy. The endpoint 159 is specified as an IPv4 or IPv6 address. In a specific case (refer 160 to Section 8.8.1), the endpoint can be the null address (0.0.0.0 for 161 IPv4, ::0 for IPv6). 163 The color is a 32-bit numerical value that associates the SR Policy 164 with an intent (e.g. low-latency). 166 The endpoint and the color are used to automate the steering of 167 service or transport routes on SR Policies (refer to Section 8). 169 An implementation MAY allow assignment of a symbolic name comprising 170 of printable ASCII characters to an SR Policy to serve as a user- 171 friendly attribute for debug and troubleshooting purposes. Such 172 symbolic names MUST NOT be considered as identifiers for an SR 173 Policy. 175 2.2. Candidate Path and Segment List 177 An SR Policy is associated with one or more candidate paths. A 178 candidate path is the unit for signaling of an SR Policy to a headend 179 via protocols like Path Computation Element (PCE) Communication 180 Protocol (PCEP) [RFC8281] or BGP SR Policy 181 [I-D.ietf-idr-segment-routing-te-policy]. 183 A candidate path is itself associated with a Segment-List (SID-List) 184 or a set of SID-Lists. 186 A SID-List represents a specific source-routed path to send traffic 187 from the headend to the endpoint of the corresponding SR policy. 189 A candidate path is either dynamic or explicit. 191 An explicit candidate path is associated with a SID-List or a set of 192 SID-Lists. 194 A dynamic candidate path expresses an optimization objective and a 195 set of constraints. The headend (potentially with the help of a PCE) 196 computes the solution SID-List (or set of SID-Lists) that solves the 197 optimization problem. 199 If a candidate path is associated with a set of SID-Lists, each SID- 200 List is associated with a weight for weighted load balancing (refer 201 Section 2.11 for details). The default weight is 1. 203 A variation of SR Policy can be used for packet replication. A 204 candidate path could comprise multiple SID-Lists; one for each 205 replication path. In such a scenario, packets are actually 206 replicated through each SID List of the SR Policy to realize a point- 207 to-multipoint service delivery. The weight of each SID-List does not 208 come into the picture in this case since there is no load-balancing. 209 The details of this and other such mechanisms for use of SR Policy 210 for point-to-multipoint delivery are outside the scope of this 211 document. 213 2.3. Protocol-Origin of a Candidate Path 215 A headend may be informed about a candidate path for an SR Policy 216 by various means including: via configuration, PCEP 217 [RFC8281] or BGP [I-D.ietf-idr-segment-routing-te-policy]. 219 Protocol-Origin of a candidate path is an 8-bit value which 220 identifies the component or protocol that originates or signals the 221 candidate path. 223 The table below specifies the RECOMMENDED default values: 225 +-------+---------------------------------------------------------+ 226 | Value | Protocol-Origin | 227 +-------+---------------------------------------------------------+ 228 | 10 | PCEP | 229 | 20 | BGP SR Policy | 230 | 30 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) | 231 +-------+---------------------------------------------------------+ 233 Table 1: Protocol-origin Identifier 235 Implementations MAY allow modifications of these default values 236 assigned to protocols on the headend along similar lines as a routing 237 administrative distance. Its application in the candidate path 238 selection is described in Section 2.9. 240 2.4. Originator of a Candidate Path 242 Originator identifies the node which provisioned or signalled the 243 candidate path on the headend. The originator is expressed in the 244 form of a 160 bit numerical value formed by the concatenation of the 245 fields of the tuple as below: 247 o ASN : represented as a 4 byte number. 249 o Node Address : represented as a 128 bit value. IPv4 addresses are 250 encoded in the lowest 32 bits. 252 Its application in the candidate path selection is described in 253 Section 2.9. 255 When Protocol-Origin is Local, the ASN and node address MAY be set to 256 either the headend or the provisioning controller/node ASN and 257 address. Default value is 0 for both AS and node address. 259 When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the 260 PCE and the AS number SHOULD be set to 0 by default when not 261 available or known. 263 Protocol-Origin is BGP SR Policy, it is provided by the BGP component 264 on the headend and is: 266 o the BGP Router ID and ASN of the node/controller signalling the 267 candidate path when it has a BGP session to the headend, OR 269 o the BGP Router ID of the eBGP peer signalling the candidate path 270 along with ASN of origin when the signalling is done via one or 271 more intermediate eBGP routers, OR 273 o the BGP Originator ID [RFC4456] and the ASN of the node/controller 274 when the signalling is done via one or more route-reflectors over 275 iBGP session. 277 2.5. Discriminator of a Candidate Path 279 The Discriminator is a 32 bit value associated with a candidate path 280 that uniquely identifies it within the context of an SR Policy from a 281 specific Protocol-Origin as specified below: 283 When Protocol-Origin is Local, this is an implementation's 284 configuration model specific unique identifier for a candidate path. 285 Default value is 0. 287 When PCEP is the Protocol-Origin, the method to uniquely identify 288 signalled path will be specified in a future PCEP document. Default 289 value is 0. 291 When BGP SR Policy is the Protocol-Origin, it is the distinguisher 292 specified in Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]. 294 Its application in the candidate path selection is described in 295 Section 2.9. 297 2.6. Identification of a Candidate Path 299 A candidate path is identified in the context of a single SR Policy. 301 A candidate path is not shared across SR Policies. 303 A candidate path is not identified by its SID-List(s). 305 If CP1 is a candidate path of SR Policy Pol1 and CP2 is a 306 candidate path of SR Policy Pol2, then these two candidate paths 307 are independent, even if they happen to have the same SID-List. 308 The SID-List does not identify a candidate path. The SID-List is 309 an attribute of a candidate path. 311 The identity of a candidate path MUST be uniquely established in the 312 context of an SR Policy in order to handle 313 add, delete or modify operations on them in an unambiguous manner 314 regardless of their source(s). 316 The tuple uniquely 317 identifies a candidate path. 319 Candidate paths MAY also be assigned or signaled with a symbolic name 320 comprising printable ASCII characters to serve as a user-friendly 321 attribute for debug and troubleshooting purposes. Such symbolic 322 names MUST NOT be considered as identifiers for a candidate path. 324 2.7. Preference of a Candidate Path 326 The preference of the candidate path is used to select the best 327 candidate path for an SR Policy. The default preference is 100. 329 It is RECOMMENDED that each candidate path of a given SR policy has a 330 different preference. 332 2.8. Validity of a Candidate Path 334 A candidate path is valid if it is usable. A common path validity 335 criterion is the reachability of its constituent SIDs. The 336 validation rules are specified in Section 5. 338 2.9. Active Candidate Path 340 A candidate path is selected when it is valid and it is determined to 341 be the best path of the SR Policy. The selected path is referred to 342 as the "active path" of the SR policy in this document. 344 Whenever a new path is learned or an active path is deleted, the 345 validity of an existing path changes or an existing path is changed, 346 the selection process MUST be re-executed. 348 The candidate path selection process operates on the candidate path 349 Preference. A candidate path is selected when it is valid and it has 350 the highest preference value among all the candidate paths of the SR 351 Policy. 353 In the case of multiple valid candidate paths of the same preference, 354 the tie-breaking rules are evaluated on the identification tuple in 355 the following order until only one valid best path is selected: 357 1. Higher value of Protocol-Origin is selected. 359 2. Lower value of originator is selected. 361 3. Finally, the higher value of discriminator is selected. 363 An implementation MAY choose to override any of the tie-breaking 364 rules above and maintain the already selected candidate path as 365 active path. 367 The rules are framed with multiple protocols and sources in mind and 368 hence may not follow the logic of a single protocol (e.g. BGP best 369 path selection). The motivation behind these rules are as follows: 371 o The Protocol-Origin allows an operator to setup a default 372 selection mechanism across protocol sources, e.g., to prefer 373 locally provisioned over paths signalled via BGP SR Policy or 374 PCEP. 376 o The preference, being the first tiebreaker, allows an operator to 377 influence selection across paths thus allowing provisioning of 378 multiple path options, e.g., CP1 is preferred and if it becomes 379 invalid then fall-back to CP2 and so on. Since preference works 380 across protocol sources it also enables (where necessary) 381 selective override of the default protocol-origin preference, 382 e.g., to prefer a path signalled via BGP SR Policy over what is 383 locally provisioned. 385 o The originator allows an operator to have multiple redundant 386 controllers and still maintain a deterministic behaviour over 387 which of them are preferred even if they are providing the same 388 candidate paths for the same SR policies to the headend. 390 o The discriminator performs the final tiebreaking step to ensure a 391 deterministic outcome of selection regardless of the order in 392 which candidate paths are signalled across multiple transport 393 channels or sessions. 395 [I-D.filsfils-spring-sr-policy-considerations] provides a set of 396 examples to illustrate the active candidate path selection rules. 398 2.10. Validity of an SR Policy 400 An SR Policy is valid when it has at least one valid candidate path. 402 2.11. Instantiation of an SR Policy in the Forwarding Plane 404 A valid SR Policy is instantiated in the forwarding plane. 406 Only the active candidate path is used for forwarding traffic that is 407 being steered onto that policy. 409 If a set of SID-Lists is associated with the active path of the 410 policy, then the steering is per flow and W-ECMP based according to 411 the relative weight of each SID-List. 413 The fraction of the flows associated with a given SID-List is w/Sw 414 where w is the weight of the SID-List and Sw is the sum of the 415 weights of the SID-Lists of the selected path of the SR Policy. 417 The accuracy of the weighted load-balancing depends on the platform 418 implementation. 420 2.12. Priority of an SR Policy 422 Upon topological change, many policies could be recomputed. An 423 implementation MAY provide a per-policy priority configuration. The 424 operator MAY set this field to indicate order in which the policies 425 should be re-computed. Such a priority is represented by an integer 426 in the range (0, 255) where the lowest value is the highest priority. 427 The default value of priority is 128. 429 An SR Policy may comprise multiple Candidate Paths received from the 430 same or different sources. A candidate path MAY be signaled with a 431 priority value. When an SR Policy has multiple candidate paths with 432 distinct signaled non-default priority values, the SR Policy as a 433 whole takes the lowest value (i.e. the highest priority) amongst 434 these signaled priority values. 436 2.13. Summary 438 In summary, the information model is the following: 440 SR policy POL1 441 Candidate-path CP1 443 Preference 200 444 Weight W1, SID-List1 445 Weight W2, SID-List2 446 Candidate-path CP2 448 Preference 100 449 Weight W3, SID-List3 450 Weight W4, SID-List4 452 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is 454 identified by a tuple . 455 CP1 is the active candidate path (it is valid and it has the highest 456 preference). The two SID-Lists of CP1 are installed as the 457 forwarding instantiation of SR policy Pol1. Traffic steered on Pol1 458 is flow-based hashed on SID-List with a ratio 459 W1/(W1+W2). 461 3. Segment Routing Database 463 An SR headend maintains the Segment Routing Database (SR-DB). 465 An SR headend leverages the SR-DB to validate explicit candidate 466 paths and compute dynamic candidate paths. 468 The information in the SR-DB MAY include: 470 o IGP information (topology, IGP metrics based on ISIS [RFC1195] and 471 OSPF [RFC2328] [RFC5340]) 472 o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj- 473 SIDs, BGP Peering SID, SRv6 SIDs) 474 [I-D.ietf-spring-segment-routing] 475 [I-D.ietf-idr-bgpls-segment-routing-epe] 476 [I-D.filsfils-spring-srv6-network-programming] 478 o TE Link Attributes (such as TE metric, SRLG, attribute-flag, 479 extended admin group) [RFC5305] [RFC3630]. 480 o Extended TE Link attributes (such as latency, loss) [RFC7810] 481 [RFC7471] 482 o Inter-AS Topology information 483 [I-D.ietf-idr-bgpls-segment-routing-epe]. 485 The attached domain topology MAY be learned via IGP, BGP-LS or 486 NETCONF. 488 A non-attached (remote) domain topology MAY be learned via BGP-LS or 489 NETCONF. 491 In some use-cases, the SR-DB may only contain the attached domain 492 topology while in others, the SR-DB may contain the topology of 493 multiple domains and in this case it is multi-domain capable. 495 The SR-DB MAY also contain the SR Policies instantiated in the 496 network. This can be collected via BGP-LS 497 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 498 [I-D.sivabalan-pce-binding-label-sid]. This information allows to 499 build an end-to-end policy on the basis of intermediate SR policies 500 (see Section 6 for further details). 502 The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of 503 nodes in the topology. This can be collected via ISIS 504 [I-D.ietf-isis-segment-routing-msd], OSPF 505 [I-D.ietf-ospf-segment-routing-msd], BGP-LS 506 [I-D.ietf-idr-bgp-ls-segment-routing-msd] or PCEP 507 [I-D.ietf-pce-segment-routing]. 509 The use of the SR-DB for computation and validation of SR Policies is 510 outside the scope of this document. Some implementation aspects 511 related to this are covered in 512 [I-D.filsfils-spring-sr-policy-considerations]. 514 4. Segment Types 516 A SID-List is an ordered set of segments represented as where S1 is the first segment. 519 Based on the desired dataplane, either the MPLS label stack or the 520 SRv6 SRH is built from the SID-List. However, the SID-List itself 521 can be specified using different segment-descriptor types and the 522 following are currently defined: 524 Type 1: SR-MPLS Label: 526 A MPLS label corresponding to any of the segment types defined 527 for SR-MPLS (as defined in [I-D.ietf-spring-segment-routing] or 528 other SR-MPLS specifications) can be used. Additionally, 529 reserved labels like explicit-null or in general any MPLS label 530 may also be used. e.g. this type can be used to specify a 531 label representation which maps to an optical transport path on 532 a packet transport node. This type does not require the 533 headend to perform SID resolution. 535 Type 2: SRv6 SID: 536 An IPv6 address corresponding to any of the segment types 537 defined for SRv6 (as defined in 538 [I-D.filsfils-spring-srv6-network-programming] or other SRv6 539 specifications) can be used. This type does not require the 540 headend to perform SID resolution. 542 Type 3: IPv4 Prefix with optional SR Algorithm: 543 The headend is required to resolve the specified IPv4 Prefix 544 Address to the SR-MPLS label corresponding to a Prefix SID 545 segment (as defined in [I-D.ietf-spring-segment-routing]). The 546 SR algorithm (refer to Section 3.1.1 of 547 [I-D.ietf-spring-segment-routing]) to be used MAY also be 548 provided. 550 Type 4: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: 551 In this case the headend is required to resolve the specified 552 IPv6 Global Prefix Address to the SR-MPLS label corresponding 553 to its Prefix SID segment (as defined in 554 [I-D.ietf-spring-segment-routing]). The SR Algorithm (refer to 555 Section 3.1.1 of [I-D.ietf-spring-segment-routing]) to be used 556 MAY also be provided. 558 Type 5: IPv4 Prefix with Local Interface ID: 559 This type allows identification of Adjacency SID (as defined in 560 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 561 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 562 point-to-point links including IP unnumbered links. The 563 headend is required to resolve the specified IPv4 Prefix 564 Address to the Node originating it and then use the Local 565 Interface ID to identify the point-to-point link whose 566 adjacency is being referred to. The Local Interface ID link 567 descriptor follows semantics as specified in [RFC7752]. This 568 type can also be used to indicate indirection into a layer 2 569 interface (i.e. without IP address) like a representation of an 570 optical transport path or a layer 2 Ethernet port or circuit at 571 the specified node. 573 Type 6: IPv4 Addresses for link endpoints as Local, Remote pair: 575 This type allows identification of Adjacency SID (as defined in 576 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 577 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 578 links. The headend is required to resolve the specified IPv4 579 Local Address to the Node originating it and then use the IPv4 580 Remote Address to identify the link adjacency being referred 581 to. The Local and Remote Address pair link descriptors follows 582 semantics as specified in [RFC7752]. 584 Type 7: IPv6 Prefix and Interface ID for link endpoints as Local, 585 Remote pair for SR-MPLS: 586 This type allows identification of Adjacency SID (as defined in 587 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 588 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 589 links including those with only Link Local IPv6 addresses. The 590 headend is required to resolve the specified IPv6 Prefix 591 Address to the Node originating it and then use the Local 592 Interface ID to identify the point-to-point link whose 593 adjacency is being referred to. For other than point-to-point 594 links, additionally the specific adjacency over the link needs 595 to be resolved using the Remote Prefix and Interface ID. The 596 Local and Remote pair of Prefix and Interface ID link 597 descriptor follows semantics as specified in [RFC7752]. This 598 type can also be used to indicate indirection into a layer 2 599 interface (i.e. without IP address) like a representation of an 600 optical transport path or a layer 2 Ethernet port or circuit at 601 the specified node. 603 Type 8: IPv6 Addresses for link endpoints as Local, Remote pair for 604 SR-MPLS: 605 This type allows identification of Adjacency SID (as defined in 606 [I-D.ietf-spring-segment-routing]) or BGP EPE Peering SID (as 607 defined in [I-D.ietf-idr-bgpls-segment-routing-epe]) label for 608 links with Global IPv6 addresses. The headend is required to 609 resolve the specified Local IPv6 Address to the Node 610 originating it and then use the Remote IPv6 Address to identify 611 the link adjacency being referred to. The Local and Remote 612 Address pair link descriptors follows semantics as specified in 613 [RFC7752]. 615 Type 9: IPv6 Global Prefix with optional SR Algorithm for SRv6: 616 The headend is required to resolve the specified IPv6 Global 617 Prefix Address to the SRv6 END function SID (as defined in 618 [I-D.filsfils-spring-srv6-network-programming]) corresponding 619 to the node which is originating the prefix. The SR Algorithm 620 (refer to Section 3.1.1 of [I-D.ietf-spring-segment-routing]) 621 to be used MAY also be provided. 623 Type 10: IPv6 Prefix and Interface ID for link endpoints as Local, 624 Remote pair for SRv6: 625 This type allows identification of SRv6 END.X SID (as defined 626 in [I-D.filsfils-spring-srv6-network-programming]) for links 627 with only Link Local IPv6 addresses. The headend is required 628 to resolve the specified IPv6 Prefix Address to the Node 629 originating it and then use the Local Interface ID to identify 630 the point-to-point link whose adjacency is being referred to. 631 For other than point-to-point links, additionally the specific 632 adjacency needs to be resolved using the Remote Prefix and 633 Interface ID. The Local and Remote pair of Prefix and 634 Interface ID link descriptor follows semantics as specified in 635 [RFC7752]. 637 Type 11: IPv6 Addresses for link endpoints as Local, Remote pair for 638 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 Global IPv6 addresses. The headend is required to resolve 642 the specified Local IPv6 Address to the Node originating it and 643 then use the Remote IPv6 Address to identify the link adjacency 644 being referred to. The Local and Remote Address pair link 645 descriptors follows semantics as specified in [RFC7752]. 647 When the algorithm is not specified for the SID types above which 648 optionally allow for it, the headend SHOULD use the Strict Shortest 649 Path algorithm if available; otherwise it SHOULD use the default 650 Shortest Path algorithm. The specification of algorithm enables the 651 use of IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in 652 SR Policy. 654 For SID types 3-through-11, a SID value may also be optionally 655 provided to the headend for verification purposes. Section 5.1. 656 describes the resolution and verification of the SIDs and Segment 657 Lists on the headend. 659 When building the MPLS label stack or the IPv6 Segment list from the 660 Segment List, the node instantiating the policy MUST interpret the 661 set of Segments as follows: 663 o The first Segment represents the topmost label or the first IPv6 664 segment. It identifies the first segment the traffic will be 665 directed toward along the explicit SR path. 666 o The last Segment represents the bottommost label or the last IPv6 667 segment the traffic will be directed toward along the explicit SR 668 path. 670 4.1. Explicit Null 672 A Type 1 SID may be any MPLS label, including reserved labels. 674 For example, assuming that the desired traffic-engineered path from a 675 headend 1 to an endpoint 4 can be expressed by the SID-List <16002, 676 16003, 16004> where 16002, 16003 and 16004 respectively refer to the 677 IPv4 Prefix SIDs bound to node 2, 3 and 4, then IPv6 traffic can be 678 traffic-engineered from nodes 1 to 4 via the previously described 679 path using an SR Policy with SID-List <16002, 16003, 16004, 2> where 680 mpls label value of 2 represents the "IPv6 Explicit NULL Label". 682 The penultimate node before node 4 will pop 16004 and will forward 683 the frame on its directly connected interface to node 4. 685 The endpoint receives the traffic with top label "2" which indicates 686 that the payload is an IPv6 packet. 688 When steering unlabeled IPv6 BGP destination traffic using an SR 689 policy composed of SID-List(s) based on IPv4 SIDs, the Explicit Null 690 Label Policy is processed as specified in 691 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an 692 "IPv6 Explicit NULL label" is not present as the bottom label, the 693 headend SHOULD automatically impose one. Refer to Section 8 for more 694 details. 696 5. Validity of a Candidate Path 698 5.1. Explicit Candidate Path 700 An explicit candidate path is associated with a SID-List or a set of 701 SID-Lists. 703 An explicit candidate path is provisioned by the operator directly or 704 via a controller. 706 The computation/logic that leads to the choice of the SID list is 707 external to the SR Policy headend. The SR Policy headend does not 708 compute the SID list. The SR Policy headend only confirms its 709 validity. 711 A SID-List of an explicit candidate path MUST be declared invalid 712 when: 714 o It is empty. 715 o Its weight is 0. 716 o The headend is unable to resolve the first SID into one or more 717 outgoing interface(s) and next-hop(s). 719 o The headend is unable to resolve any non-first SID of type 720 3-through-11 into an MPLS label or an SRv6 SID. 721 o The headend verification fails for any SID for which verification 722 has been explicitly requested. 724 "Unable to resolve" means that the headend has no path to the SID in 725 its SR database. 727 SID verification is performed when the headend is explicitly 728 requested to verify SID(s) by the controller via the signaling 729 protocol used. Implementations MAY provide a local configuration 730 option to enable verification on a global or per policy or per 731 candidate path basis. 733 "Verification fails" for a SID means any of the following: 735 o The headend is unable to find the SID in its SR DB 736 o The headend detects mis-match between the SID value and its 737 context provided for SIDs of type 3-through-11 in its SR DB. 738 o The headend is unable to resolve any non-first SID of type 739 3-through-11 into an MPLS label or an SRv6 SID. 741 In multi-domain deployments, it is expected that the headend be 742 unable to verify the reachability of the SIDs in remote domains. 743 Types 1 or 2 MUST be used for the SIDs for which the reachability 744 cannot be verified. Note that the first SID MUST always be reachable 745 regardless of its type. 747 In addition, a SID-List MAY be declared invalid when: 749 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 750 advertised by the node specified as the endpoint of the 751 corresponding SR policy. 752 o Its last segment is not an Adjacency SID (including BGP Peer 753 Adjacency SID) of any of the links present on neighbor nodes and 754 that terminate on the node specified as the endpoint of the 755 corresponding SR policy. 757 An explicit candidate path is invalid as soon as it has no valid SID- 758 List. 760 5.2. Dynamic Candidate Path 762 A dynamic candidate path is specified as an optimization objective 763 and constraints. 765 The headend of the policy leverages its SR database to compute a SID- 766 List ("solution SID-List") that solves this optimization problem. 768 The headend re-computes the solution SID-List any time the inputs to 769 the problem change (e.g., topology changes). 771 When local computation is not possible (e.g., a policy's tailend is 772 outside the topology known to the headend) or not desired, the 773 headend MAY send path computation request to a PCE supporting PCEP 774 extension specified in [I-D.ietf-pce-segment-routing]. 776 If no solution is found to the optimization objective and 777 constraints, then the dynamic candidate path MUST be declared 778 invalid. 780 [I-D.filsfils-spring-sr-policy-considerations] discusses some of the 781 optimization objectives and constraints that may be considered by a 782 dynamic candidate path. It illustrates some of the desirable 783 properties of the computation of the solution SID list. 785 6. Binding SID 787 The Binding SID (BSID) is fundamental to Segment Routing 788 [I-D.ietf-spring-segment-routing]. It provides scaling, network 789 opacity and service independence. 790 [I-D.filsfils-spring-sr-policy-considerations] illustrates some of 791 these benefits. 793 6.1. BSID of a candidate path 795 Each candidate path MAY be defined with a BSID. 797 Candidate Paths of the same SR policy SHOULD have the same BSID. 799 Candidate Paths of different SR policies MUST NOT have the same BSID. 801 6.2. BSID of an SR Policy 803 The BSID of an SR policy is the BSID of its active candidate path. 805 When the active candidate path has a specified BSID, the SR Policy 806 uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is 807 available (i.e., not associated with any other usage: e.g. to another 808 MPLS client, to another SID, to another SR Policy). 810 Optionally, instead of only checking that the BSID of the active path 811 is available, a headend MAY check that it is available within a given 812 SID range i.e., Segment Routing Local Block (SRLB) as specified in 813 [I-D.ietf-spring-segment-routing]. 815 When the specified BSID is not available (optionally is not in the 816 SRLB), an alert message is generated. 818 In the cases (as described above) where SR Policy does not have a 819 BSID available, then the SR Policy MAY dynamically bind a BSID to 820 itself. Dynamically bound BSID SHOULD use an available SID outside 821 the SRLB. 823 Assuming that at time t the BSID of the SR Policy is B1, if at time 824 t+dt a different candidate path becomes active and this new active 825 path does not have a specified BSID or its BSID is specified but is 826 not available (e.g. it is in use by something else), then the SR 827 Policy keeps the previous BSID B1. 829 The association of an SR Policy with a BSID thus MAY change over the 830 life of the SR policy (e.g., upon active path change). Hence, the 831 BSID SHOULD NOT be used as an identification of an SR Policy. 833 6.2.1. Frequent use-cases : unspecified BSID 835 All the candidate paths of the same SR Policy can have an unspecified 836 BSID. 838 In such a case, a BSID MAY be dynamically bound to the SR Policy as 839 soon as the first valid candidate path is received. That BSID is 840 kept along all the life of the SR Policy and across changes of active 841 candidate path. 843 6.2.2. Frequent use-case: all specified to the same BSID 845 All the paths of the SR Policy can have the same specified BSID. 847 6.2.3. Specified-BSID-only 849 An implementation MAY support the configuration of the Specified- 850 BSID-only restrictive behavior on the headend for all SR Policies or 851 individual SR Policies. Further, this restrictive behavior MAY also 852 be signaled on a per SR Policy basis to the headend. 854 When this restrictive behavior is enabled, if the candidate path has 855 an unspecified BSID or if the specified BSID is not available when 856 the candidate path becomes active then no BSID is bound to it and it 857 is considered invalid. An alert is triggered. Other candidate paths 858 MUST then be evaluated for becoming the active candidate path. 860 6.3. Forwarding Plane 862 A valid SR Policy installs a BSID-keyed entry in the forwarding plane 863 with the action of steering the packets matching this entry to the 864 selected path of the SR Policy. 866 If the Specified-BSID-only restrictive behavior is enabled and the 867 BSID of the active path is not available (optionally not in the 868 SRLB), then the SR Policy does not install any entry indexed by a 869 BSID in the forwarding plane. 871 6.4. Non-SR usage of Binding SID 873 An implementation MAY choose to associate a Binding SID with any type 874 of interface (e.g. a layer 3 termination of an Optical Circuit) or a 875 tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE 876 tunnel, etc). This enables the use of other non-SR enabled 877 interfaces and tunnels as segments in an SR Policy SID-List without 878 the need of forming routing protocol adjacencies over them. 880 The details of this kind of usage are beyond the scope of this 881 document. A specific packet optical integration use case is 882 described in [I-D.anand-spring-poi-sr] 884 7. SR Policy State 886 The SR Policy State is maintained on the headend to represent the 887 state of the policy and its candidate paths. This is to provide an 888 accurate representation of whether the SR Policy is being 889 instantiated in the forwarding plane and which of its candidate paths 890 and segment-list(s) are active. The SR Policy state MUST also 891 reflect the reason when a policy and/or its candidate path is not 892 active due to validation errors or not being preferred. 894 The SR Policy state can be reported by the headend node via BGP-LS 895 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and 896 [I-D.sivabalan-pce-binding-label-sid]. 898 SR Policy state on the headend also includes traffic accounting 899 information for the flows being steered via the policies. The 900 details of the SR Policy accounting are beyond the scope of this 901 document. The aspects related to the SR traffic counters and their 902 usage in the broader context of traffic accounting in a SR network 903 are covered in [I-D.filsfils-spring-sr-traffic-counters] and 904 [I-D.ali-spring-sr-traffic-accounting] respectively. 906 Implementations MAY support an administrative state to control 907 locally provisioned policies via mechanisms like CLI or NETCONF. 909 8. Steering into an SR Policy 911 A headend can steer a packet flow into a valid SR Policy in various 912 ways: 914 o Incoming packets have an active SID matching a local BSID at the 915 headend. 916 o Per-destination Steering: incoming packets match a BGP/Service 917 route which recurses on an SR policy. 918 o Per-flow Steering: incoming packets match or recurse on a 919 forwarding array of where some of the entries are SR Policies. 920 o Policy-based Steering: incoming packets match a routing policy 921 which directs them on an SR policy. 923 For simplicity of illustration, this document uses the SR-MPLS 924 example. 926 8.1. Validity of an SR Policy 928 An SR Policy is invalid when all its candidate paths are invalid. 930 By default, upon transitioning to the invalid state, 932 o an SR Policy and its BSID are removed from the forwarding plane. 933 o any steering of a service (PW), destination (BGP-VPN), flow or 934 packet on the related SR policy is disabled and the related 935 service, destination, flow or packet is routed per the classic 936 forwarding table (e.g. longest-match to the destination or the 937 recursing next-hop). 939 8.2. Drop upon invalid SR Policy 941 An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: 943 o an invalid SR Policy and its BSID is kept in the forwarding plane 944 with an action to drop. 945 o any steering of a service (PW), destination (BGP-VPN), flow or 946 packet on the related SR policy is maintained with the action to 947 drop all of this traffic. 949 The drop-upon-invalid behavior has been deployed in use-cases where 950 the operator wants some PW to only be transported on a path with 951 specific constraints. When these constraints are no longer met, the 952 operator wants the PW traffic to be dropped. Specifically, the 953 operator does not want the PW to be routed according to the IGP 954 shortest-path to the PW endpoint. 956 8.3. Incoming Active SID is a BSID 958 Let us assume that headend H has a valid SR Policy P of SID-List and BSID B. 961 When H receives a packet K with label stack , H pops B and 962 pushes and forwards the resulting packet according to 963 SID S1. 965 "Forwarding the resulting packet according to S1" means: If S1 is 966 an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H 967 sends the resulting packet with label stack on 968 the outgoing interface associated with S1; Else H sends the 969 resulting packet with label stack along the 970 path of S1. 972 H has steered the packet into the SR policy P. 974 H did not have to classify the packet. The classification was done 975 by a node upstream of H (e.g., the source of the packet or an 976 intermediate ingress edge node of the SR domain) and the result of 977 this classification was efficiently encoded in the packet header as a 978 BSID. 980 This is another key benefit of the segment routing in general and the 981 binding SID in particular: the ability to encode a classification and 982 the resulting steering in the packet header to better scale and 983 simplify intermediate aggregation nodes. 985 If the SR Policy P is invalid, the BSID B is not in the forwarding 986 plane and hence the packet K is dropped by H. 988 8.4. Per-Destination Steering 990 Let us assume that headend H: 992 o learns a BGP route R/r via next-hop N, extended-color community C 993 and VPN label V. 994 o has a valid SR Policy P to (endpoint = N, color = C) of SID-List 995 and BSID B. 996 o has a BGP policy which matches on the extended-color community C 997 and allows its usage as SLA steering information. 999 If all these conditions are met, H installs R/r in RIB/FIB with next- 1000 hop = SR Policy P of BSID B instead of via N. 1002 Indeed, H's local BGP policy and the received BGP route indicate that 1003 the headend should associate R/r with an SR Policy path to endpoint N 1004 with the SLA associated with color C. The headend therefore installs 1005 the BGP route on that policy. 1007 This can be implemented by using the BSID as a generalized next-hop 1008 and installing the BGP route on that generalized next-hop. 1010 When H receives a packet K with a destination matching R/r, H pushes 1011 the label stack and sends the resulting packet along 1012 the path to S1. 1014 Note that any SID associated with the BGP route is inserted after the 1015 SID-List of the SR Policy (i.e., ). 1017 The same behavior is applicable to any type of service route: any 1018 AFI/SAFI of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. 1020 8.4.1. Multiple Colors 1022 When a BGP route has multiple extended-color communities each with a 1023 valid SR Policy NLRI, the BGP process installs the route on the SR 1024 policy whose color is of highest numerical value. 1026 Let us assume that headend H: 1028 o learns a BGP route R/r via next-hop N, extended-color communities 1029 C1 and C2 and VPN label V. 1030 o has a valid SR Policy P1 to (endpoint = N, color = C1) of SID list 1031 and BSID B1. 1032 o has a valid SR Policy P2 to (endpoint = N, color = C2) of SID list 1033 and BSID B2. 1034 o has a BGP policy which matches on the extended-color communities 1035 C1 and C2 and allows their usage as SLA steering information 1037 If all these conditions are met, H installs R/r in RIB/FIB with next- 1038 hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1. 1040 8.5. Recursion on an on-demand dynamic BSID 1042 In the previous section, it was assumed that H had a pre-established 1043 "explicit" SR Policy (endpoint N, color C). 1045 In this section, independently to the a-priori existence of any 1046 explicit candidate path of the SR policy (N, C), it is to be noted 1047 that the BGP process at headend node H triggers the instantiation of 1048 a dynamic candidate path for the SR policy (N, C) as soon as: 1050 o the BGP process learns of a route R/r via N and with color C. 1052 o a local policy at node H authorizes the on-demand SR Policy path 1053 instantiation and maps the color to a dynamic SR Policy path 1054 optimization template. 1056 8.5.1. Multiple Colors 1058 When a BGP route R/r via N has multiple extended-color communities Ci 1059 (with i=1 ... n), an individual on-demand SR Policy dynamic path 1060 request (endpoint N, color Ci) is triggered for each color Ci. 1062 8.6. Per-Flow Steering 1064 Let us assume that headend H: 1066 o has a valid SR Policy P1 to (endpoint = N, color = C1) of SID-List 1067 and BSID B1. 1068 o has a valid SR Policy P2 to (endpoint = N, color = C2) of SID-List 1069 and BSID B2. 1070 o is configured to instantiate an array of paths to N where the 1071 entry 0 is the IGP path to N, color C1 is the first entry and 1072 Color C2 is the second entry. The index into the array is called 1073 a Forwarding Class (FC). The index can have values 0 to 7. 1074 o is configured to match flows in its ingress interfaces (upon any 1075 field such as Ethernet destination/source/vlan/tos or IP 1076 destination/source/DSCP or transport ports etc.) and color them 1077 with an internal per-packet forwarding-class variable (0, 1 or 2 1078 in this example). 1080 If all these conditions are met, H installs in RIB/FIB: 1082 o N via a recursion on an array A (instead of the immediate outgoing 1083 link associated with the IGP shortest-path to N). 1084 o Entry A(0) set to the immediate outgoing link of the IGP shortest- 1085 path to N. 1086 o Entry A(1) set to SR Policy P1 of BSID=B1. 1087 o Entry A(2) set to SR Policy P2 of BSID=B2. 1089 H receives three packets K, K1 and K2 on its incoming interface. 1090 These three packets either longest-match on N or more likely on a 1091 BGP/service route which recurses on N. H colors these 3 packets 1092 respectively with forwarding-class 0, 1 and 2. As a result: 1094 o H forwards K along the shortest-path to N (which in SR-MPLS 1095 results in the pushing of the prefix-SID of N). 1096 o H pushes on packet K1 and forwards the resulting 1097 frame along the shortest-path to S1. 1098 o H pushes on packet K2 and forwards the resulting 1099 frame along the shortest-path to S4. 1101 If the local configuration does not specify any explicit forwarding 1102 information for an entry of the array, then this entry is filled with 1103 the same information as entry 0 (i.e. the IGP shortest-path). 1105 If the SR Policy mapped to an entry of the array becomes invalid, 1106 then this entry is filled with the same information as entry 0. When 1107 all the array entries have the same information as entry0, the 1108 forwarding entry for N is updated to bypass the array and point 1109 directly to its outgoing interface and next-hop. 1111 The array index values (e.g. 0, 1 and 2) and the notion of 1112 forwarding-class are implementation specific and only meant to 1113 describe the desired behavior. The same can be realized by other 1114 mechanisms. 1116 This realizes per-flow steering: different flows bound to the same 1117 BGP endpoint are steered on different IGP or SR Policy paths. 1119 8.7. Policy-based Routing 1121 Finally, headend H may be configured with a local routing policy 1122 which overrides any BGP/IGP path and steer a specified packet on an 1123 SR Policy. This includes the use of mechanisms like IGP Shortcut for 1124 automatic routing of IGP prefixes over SR Policies intended for such 1125 purpose. 1127 8.8. Optional Steering Modes for BGP Destinations 1129 8.8.1. Color-Only BGP Destination Steering 1131 In the previous section, it is seen that the steering on an SR Policy 1132 is governed by the matching of the BGP route's next-hop N and the 1133 authorized color C with an SR Policy defined by the tuple (N, C). 1135 This is the most likely form of BGP destination steering and the one 1136 recommended for most use-cases. 1138 This section defines an alternative steering mechanism based only on 1139 the color. 1141 This color-only steering variation is governed by two new flags "C" 1142 and "O" defined in the color extended community [ref draft-ietf-idr- 1143 segment-routing-te-policy section 3]. 1145 The Color-Only flags "CO" are set to 00 by default. 1147 When 00, the BGP destination is steered as follows: 1149 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1151 endpoint address and C is a color; 1152 Steer into SR Policy (N, C); 1153 ELSE; 1154 Steer on the IGP path to the next-hop N. 1156 This is the classic case described in this document previously and 1157 what is recommended in most scenarios. 1159 When 01, the BGP destination is steered as follows: 1161 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 1163 endpoint address and C is a color; 1164 Steer into SR Policy (N, C); 1165 ELSE IF there is a valid SR Policy (null endpoint, C) of the 1166 same address-family of N; 1167 Steer into SR Policy (null endpoint, C); 1168 ELSE IF there is any valid SR Policy 1169 (any address-family null endpoint, C); 1170 Steer into SR Policy (any null endpoint, C); 1171 ELSE; 1172 Steer on the IGP path to the next-hop N. 1174 When 10, the BGP destination is steered as follows: 1176 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 1177 endpoint address and C is a color; 1178 Steer into SR Policy (N, C); 1179 ELSE IF there is a valid SR Policy (null endpoint, C) 1180 of the same address-family of N; 1181 Steer into SR Policy (null endpoint, C); 1182 ELSE IF there is any valid SR Policy 1183 (any address-family null endpoint, C); 1184 Steer into SR Policy (any null endpoint, C); 1185 ELSE IF there is any valid SR Policy (any endpoint, C) 1186 of the same address-family of N; 1187 Steer into SR Policy (any endpoint, C); 1188 ELSE IF there is any valid SR Policy 1189 (any address-family endpoint, C); 1190 Steer into SR Policy (any address-family endpoint, C); 1191 ELSE; 1192 Steer on the IGP path to the next-hop N. 1194 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1195 to the 0 value). 1197 The value 11 is reserved for future use and SHOULD NOT be used. Upon 1198 reception, an implementations MUST treat it like 00. 1200 8.8.2. Multiple Colors and CO flags 1202 The steering preference is first based on highest color value and 1203 then CO-dependent for the color. Assuming a Prefix via (NH, 1204 C1(CO=01), C2(CO=01)); C1>C2 The steering preference order is: 1206 o SR policy (NH, C1). 1207 o SR policy (null, C1). 1208 o SR policy (NH, C2). 1209 o SR policy (null, C2). 1210 o IGP to NH. 1212 8.8.3. Drop upon Invalid 1214 This document defined earlier that when all the following conditions 1215 are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of 1216 BSID B instead of via N. 1218 o H learns a BGP route R/r via next-hop N, extended-color community 1219 C and VPN label V. 1220 o H has a valid SR Policy P to (endpoint = N, color = C) of SID-List 1221 and BSID B. 1222 o H has a BGP policy which matches on the extended-color community C 1223 and allows its usage as SLA steering information. 1225 This behavior is extended by noting that the BGP policy may require 1226 the BGP steering to always stay on the SR policy whatever its 1227 validity. 1229 This is the "drop upon invalid" option described in Section 8.2 1230 applied to BGP-based steering. 1232 9. Protection 1234 9.1. Leveraging TI-LFA local protection of the constituent IGP segments 1236 In any topology, Topology-Independent Loop Free Alternate (TI-LFA) 1237 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a 50msec local 1238 protection technique for IGP SIDs. The backup path is computed on a 1239 per IGP SID basis along the post-convergence path. 1241 In a network that has deployed TI-LFA, an SR Policy built on the 1242 basis of TI-LFA protected IGP segments leverages the local protection 1243 of the constituent segments. 1245 In a network that has deployed TI-LFA, an SR Policy instantiated only 1246 with non-protected Adj SIDs does not benefit from any local 1247 protection. 1249 9.2. Using an SR Policy to locally protect a link 1251 1----2-----6----7 1252 | | | | 1253 4----3-----9----8 1255 Figure 1: Local protection using SR Policy 1257 An SR Policy can be instantiated at node 2 to protect the link 2to6. 1258 A typical explicit SID list would be <3, 9, 6>. 1260 A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, 1261 3 and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8 and 9 are part 1262 of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 cannot 1263 benefit from TI-LFA automated local protection. 1265 9.3. Using a Candidate Path for Path Protection 1267 An SR Policy allows for multiple candidate paths, of which at any 1268 point in time there is a single active candidate path that is 1269 provisioned in the forwarding plane and used for traffic steering. 1270 However, another (lower preference) candidate path MAY be designated 1271 as the backup for a specific or all (active) candidate path(s). Such 1272 a backup candidate path is generally disjoint from the active 1273 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 and 1294 Ruediger Geib 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 [I-D.ietf-spring-segment-routing] 1356 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1357 Litkowski, S., and R. Shakir, "Segment Routing 1358 Architecture", draft-ietf-spring-segment-routing-15 (work 1359 in progress), January 2018. 1361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1362 Requirement Levels", BCP 14, RFC 2119, 1363 DOI 10.17487/RFC2119, March 1997, 1364 . 1366 14.2. Informative References 1368 [I-D.ali-spring-sr-traffic-accounting] 1369 Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., 1370 Horneffer, M., Raszuk, R., Litkowski, S., and d. 1371 daniel.voyer@bell.ca, "Traffic Accounting in Segment 1372 Routing Networks", draft-ali-spring-sr-traffic- 1373 accounting-02 (work in progress), June 2018. 1375 [I-D.anand-spring-poi-sr] 1376 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 1377 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 1378 Integration in Segment Routing", draft-anand-spring-poi- 1379 sr-05 (work in progress), February 2018. 1381 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 1382 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 1383 Francois, P., and d. daniel.voyer@bell.ca, "Topology 1384 Independent Fast Reroute using Segment Routing", draft- 1385 bashandy-rtgwg-segment-routing-ti-lfa-04 (work in 1386 progress), April 2018. 1388 [I-D.filsfils-spring-sr-policy-considerations] 1389 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1390 P. Mattes, "SR Policy Implementation and Deployment 1391 Considerations", draft-filsfils-spring-sr-policy- 1392 considerations-01 (work in progress), June 2018. 1394 [I-D.filsfils-spring-sr-traffic-counters] 1395 Filsfils, C., Ali, Z., Horneffer, M., 1396 daniel.voyer@bell.ca, d., Durrani, M., and R. Raszuk, 1397 "Segment Routing Traffic Accounting Counters", draft- 1398 filsfils-spring-sr-traffic-counters-00 (work in progress), 1399 June 2018. 1401 [I-D.filsfils-spring-srv6-network-programming] 1402 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 1403 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1404 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1405 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 1406 M. Sharif, "SRv6 Network Programming", draft-filsfils- 1407 spring-srv6-network-programming-04 (work in progress), 1408 March 2018. 1410 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1411 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 1412 "Signaling Maximum SID Depth using Border Gateway Protocol 1413 Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 1414 (work in progress), October 2017. 1416 [I-D.ietf-idr-bgpls-segment-routing-epe] 1417 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 1418 Dong, "BGP-LS extensions for Segment Routing BGP Egress 1419 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 1420 epe-15 (work in progress), March 2018. 1422 [I-D.ietf-idr-segment-routing-te-policy] 1423 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 1424 E., and S. Lin, "Advertising Segment Routing Policies in 1425 BGP", draft-ietf-idr-segment-routing-te-policy-03 (work in 1426 progress), May 2018. 1428 [I-D.ietf-idr-te-lsp-distribution] 1429 Previdi, S., Dong, J., Chen, M., Gredler, H., and J. 1430 Tantsura, "Distribution of Traffic Engineering (TE) 1431 Policies and State using BGP-LS", draft-ietf-idr-te-lsp- 1432 distribution-08 (work in progress), December 2017. 1434 [I-D.ietf-isis-segment-routing-msd] 1435 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1436 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 1437 ietf-isis-segment-routing-msd-12 (work in progress), May 1438 2018. 1440 [I-D.ietf-lsr-flex-algo] 1441 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1442 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1443 algo-00 (work in progress), May 2018. 1445 [I-D.ietf-ospf-segment-routing-msd] 1446 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1447 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 1448 ietf-ospf-segment-routing-msd-14 (work in progress), May 1449 2018. 1451 [I-D.ietf-pce-segment-routing] 1452 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1453 and J. Hardwick, "PCEP Extensions for Segment Routing", 1454 draft-ietf-pce-segment-routing-11 (work in progress), 1455 November 2017. 1457 [I-D.sivabalan-pce-binding-label-sid] 1458 Sivabalan, S., Tantsura, J., Filsfils, C., Previdi, S., 1459 Hardwick, J., and D. Dhody, "Carrying Binding Label/ 1460 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 1461 binding-label-sid-04 (work in progress), March 2018. 1463 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1464 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1465 December 1990, . 1467 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1468 DOI 10.17487/RFC2328, April 1998, 1469 . 1471 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1472 (TE) Extensions to OSPF Version 2", RFC 3630, 1473 DOI 10.17487/RFC3630, September 2003, 1474 . 1476 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1477 Reflection: An Alternative to Full Mesh Internal BGP 1478 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1479 . 1481 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1482 "Multiprotocol Extensions for BGP-4", RFC 4760, 1483 DOI 10.17487/RFC4760, January 2007, 1484 . 1486 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1487 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1488 2008, . 1490 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1491 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1492 . 1494 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1495 Locator/ID Separation Protocol (LISP)", RFC 6830, 1496 DOI 10.17487/RFC6830, January 2013, 1497 . 1499 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1500 Previdi, "OSPF Traffic Engineering (TE) Metric 1501 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1502 . 1504 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1505 S. Ray, "North-Bound Distribution of Link-State and 1506 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1507 DOI 10.17487/RFC7752, March 2016, 1508 . 1510 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1511 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1512 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1513 . 1515 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1516 Computation Element Communication Protocol (PCEP) 1517 Extensions for Stateful PCE", RFC 8231, 1518 DOI 10.17487/RFC8231, September 2017, 1519 . 1521 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1522 Computation Element Communication Protocol (PCEP) 1523 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1524 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1525 . 1527 Authors' Addresses 1529 Clarence Filsfils 1530 Cisco Systems, Inc. 1531 Pegasus Parc 1532 De kleetlaan 6a, DIEGEM BRABANT 1831 1533 BELGIUM 1535 Email: cfilsfil@cisco.com 1537 Siva Sivabalan (editor) 1538 Cisco Systems, Inc. 1539 2000 Innovation Drive 1540 Kanata, Ontario K2K 3E8 1541 Canada 1543 Email: msiva@cisco.com 1545 Daniel Voyer 1546 Bell Canada 1547 671 de la gauchetiere W 1548 Montreal, Quebec H3B 2M8 1549 Canada 1551 Email: daniel.voyer@bell.ca 1553 Alex Bogdanov 1554 Google, Inc. 1556 Email: bogdanov@google.com 1558 Paul Mattes 1559 Microsoft 1560 One Microsoft Way 1561 Redmond, WA 98052-6399 1562 USA 1564 Email: pamattes@microsoft.com