idnits 2.17.1 draft-filsfils-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2489 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) -- Looks like a reference, but probably isn't: '0' on line 562 -- Looks like a reference, but probably isn't: '254' on line 562 -- Looks like a reference, but probably isn't: '4000' on line 738 -- Looks like a reference, but probably isn't: '8000' on line 738 -- Looks like a reference, but probably isn't: '4009' on line 741 -- Looks like a reference, but probably isn't: '5000' on line 741 == Missing Reference: '4000-4499' is mentioned on line 753, but not defined == Missing Reference: '4500-5000' is mentioned on line 753, but not defined == Unused Reference: 'GLOBECOM' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'SIGCOMM' is defined on line 1276, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GLOBECOM' == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-07 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-10 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'SIGCOMM' Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils 3 Internet-Draft S. Sivabalan 4 Intended status: Standards Track K. Raza 5 Expires: January 4, 2018 J. Liste 6 F. Clad 7 Cisco Systems, Inc. 8 D. Yoyer 9 Bell Canada. 10 S. Lin 11 A. Bogdanov 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 July 3, 2017 22 Segment Routing Policy for Traffic Engineering 23 draft-filsfils-spring-segment-routing-policy-01.txt 25 Abstract 27 Segment Routing (SR) allows a headend node to steer a packet flow 28 along any path. Intermediate per-flow states are eliminated thanks 29 to source routing. The headend node steers a flow into an SR Policy. 30 The header of a packet steered in an SR Policy is augmented with the 31 ordered list of segments associated with that SR Policy. This 32 document details the concepts of SR Policy and steering into an SR 33 Policy. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 4, 2018. 58 Copyright Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. SR Traffic Engineering Architecture . . . . . . . . . . . . . 4 77 3. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. SR Policy Active Path Selection Examples . . . . . . . . . . 8 79 5. Segment-list . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 10 81 6. SR Policy Multi-Domain Database . . . . . . . . . . . . . . . 11 82 7. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 7.1. W-ECMP . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 12 85 7.3. Fast Convergence . . . . . . . . . . . . . . . . . . . . 12 86 8. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8.2. Allocation . . . . . . . . . . . . . . . . . . . . . . . 14 89 8.2.1. Dynamic BSID Allocation . . . . . . . . . . . . . . . 14 90 8.2.2. Explicit BSID Allocation . . . . . . . . . . . . . . 15 91 8.2.3. Generic BSID Allocation . . . . . . . . . . . . . . . 15 92 9. Centralized Discovery . . . . . . . . . . . . . . . . . . . . 16 93 10. Dynamic Path . . . . . . . . . . . . . . . . . . . . . . . . 17 94 10.1. Optimization Objective . . . . . . . . . . . . . . . . . 17 95 10.2. Constraints . . . . . . . . . . . . . . . . . . . . . . 18 96 10.3. SR Native Algorithm . . . . . . . . . . . . . . . . . . 19 97 10.4. Path to SID . . . . . . . . . . . . . . . . . . . . . . 19 98 10.5. PCE Computed Path . . . . . . . . . . . . . . . . . . . 20 99 11. Signaling Paths of an SR Policy to a Head-end . . . . . . . . 20 100 11.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 11.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 11.3. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . 21 103 11.4. CLI . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 12. Steering into an SR Policy . . . . . . . . . . . . . . . . . 21 105 12.1. Incoming Active SID is a BSID . . . . . . . . . . . . . 21 106 12.2. Recursion on a BSID . . . . . . . . . . . . . . . . . . 22 107 12.2.1. Multiple Colors . . . . . . . . . . . . . . . . . . 23 108 12.3. Recursion on an on-demand dynamic BSID . . . . . . . . . 23 109 12.3.1. Multiple Colors . . . . . . . . . . . . . . . . . . 23 110 12.4. An array of BSIDs associated with an IGP entry . . . . . 23 111 12.5. A Routing Policy on a BSID . . . . . . . . . . . . . . . 24 112 13. Optional Steering Modes for BGP Destinations . . . . . . . . 25 113 13.1. Color-Only BGP Destination Steering . . . . . . . . . . 25 114 13.2. Drop on Invalid . . . . . . . . . . . . . . . . . . . . 25 115 14. Multipoint SR Policy . . . . . . . . . . . . . . . . . . . . 26 116 14.1. Spray SR Policy . . . . . . . . . . . . . . . . . . . . 26 117 15. Reporting SR Policy . . . . . . . . . . . . . . . . . . . . . 26 118 16. Work in Progress . . . . . . . . . . . . . . . . . . . . . . 26 119 17. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 120 18. Normative References . . . . . . . . . . . . . . . . . . . . 27 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 123 1. Introduction 125 Segment Routing (SR) allows a headend node to steer a packet flow 126 along any path. Intermediate per-flow states are eliminated thanks 127 to source routing [I-D.ietf-spring-segment-routing]. 129 The headend node is said to steer a flow into an Segment Routing 130 Policy (SR Policy). 132 The header of a packet steered in an SR Policy is augmented with the 133 ordered list of segments associated with that SR Policy. 135 This document details the concepts of SR Policy and steering into an 136 SR Policy. These apply equally to the MPLS and SRv6 instantiations 137 of segment routing. 139 For reading simplicity, the illustrations are provided for the MPLS 140 instantiations. 142 2. SR Traffic Engineering Architecture 144 +--------+ +--------+ 145 | BGP | | PCEP | 146 +--------+ +--------+ 147 \ / 148 +--------+ +--------+ +--------+ 149 | CLI |--| SRTE |--| NETCONF| 150 +--------+ +--------+ +--------+ 151 | 152 +--------+ 153 | FIB | 154 +--------+ 156 Figure 1: SR Policy architecture 158 The Segment Routing Traffic Engineering (SRTE) process installs a 159 Segment Routing Policy (SR Policy) in the forwarding plane (FIB). 161 An SR policy is represented in FIB as a BSID-keyed entry. For 162 traffic steering purpose, suitable SR policy is identified using 163 either BSID or IP prefix. 165 For a given SR policy, the SRTE process MAY learn multiple candidate 166 paths from different sources: NETCONF with OpenConfig or YANG model 167 (work in progress), PCEP [I-D.ietf-pce-pce-initiated-lsp], local 168 configuration or BGP [I-D.previdi-idr-segment-routing-te-policy]. 170 The SRTE process selects the best candidate path and installs it in 171 FIB. 173 +--------+ +--------+ 174 | BGP-LS | | IGP | 175 +--------+ +--------+ 176 \ / 177 +--------+ +--------+ 178 | SRTE |--| NETCONF| 179 +--------+ +--------+ 181 Figure 2: Topology/link-state database architecture 183 The SRTE process maintains an SRTE database (SRTE-DB). 185 The SRTE-DB includes information that a headend requires to compute 186 path (if possible) for SR policies as well as setup and validate SR 187 policies. 189 The information in the SRTE-DB includes (but not limited to): 191 o Regular IGP information (topology, IGP metrics). 193 o Segment Routing information (such as SRGB, Prefix-SIDs, Adj-SIDs). 195 o TE Link Attributes (such as TE metric, SRLG, attribute-flag, 196 extended admin group). 198 The SRTE-DB is multi-domain capable. 200 The attached domain topology MAY be learned via IGP, BGP-LS or 201 NETCONF. 203 A non-attached (remote) domain topology MAY be learned via BGP-LS or 204 NETCONF. 206 In some use-cases, the SRTE-DB may only contain the attached domain 207 topology while in others, the SRTE-DB may contain the topology of 208 multiple domains. 210 3. SR Policy 212 An SR Policy is identified through the following tuple: 214 o The head-end where the policy is instantiated/implemented. 216 o The endpoint (i.e.: the destination of the policy). 218 o The color (an arbitrary numerical value). 220 At a given head-end, an SR Policy is fully identified by the tuple. 223 An endpoint can be specified as an IPv4 or IPv6 address (including 224 null address, i.e., 0.0.0.0 and ::0 for IPv4 and IPv6 address 225 families respectively as explained later in this document). 227 An SR Policy is associated with one or more candidate paths. A path 228 refers to a list of segments (i.e. Segment-list) or a set of 229 Segment-lists. A Segment-list represents a specific way to send 230 traffic from the head-end to the end-point of the corresponding SR 231 policy. If a path contains multiple Segment-lists, each list can be 232 associated with a weight for equal or unequal cost load-balancing 233 (default is equal cost load-balancing). 235 For each SR Policy, at most one candidate path is selected, and only 236 the selected path is used for forwarding traffic that is being 237 steered onto that policy. 239 A candidate path is either dynamic or explicit. 241 A dynamic path expresses an optimization objective and a set of 242 constraints. The headend computes a solution to the optimization 243 problem as a Segment-list or a set of Segment-lists. When the 244 headend does not have enough topological information (e.g. multi- 245 domain problem), the headend may delegate the computation to a PCE. 246 Whenever the network state changes, the path is recomputed. 248 An explicit path is a Segment-list or a set of Segment-lists. 250 A candidate path has a preference. If not specified, the default 251 preference is 100. 253 A candidate path is associated with a single Binding SID (BSID) in 254 the context of the corresponding SR policy. If a candidate path is 255 selected (active path), its BSID must be the same as that of the 256 corresponding SR policy. If more than one SR policies might happen 257 to be associated with an identical candidate path, each candidate 258 path MUST be associated with a unique BSID to ensure that each policy 259 has a distinct BSID. 261 A candidate path is valid if it is usable. A common path validity 262 criterion is the reachability of its constituent SIDs. The 263 validation rules are defined in a later section. 265 A Path is selected (i.e. it is the best path of the policy) when it 266 is valid and its preference is the best (highest value) among all the 267 candidate paths of the SR Policy. The selected path is referred to 268 as the "active path" of the SR policy in this document. 270 Whenever a new path is learned or the validity of an existing path 271 changes or an existing path is changed, the selection process must be 272 re-executed. 274 A headend may be informed about a candidate path for a policy by various means including: local configuration, NETCONF, 276 PCEP or BGP. The protocol source of the path does not matter as to 277 how an active path is chosen. For a given Policy, when comparing a 278 candidate path learned via one means to a candidate path learned via 279 another means (e.g., one via BGP another via PCEP), a valid path will 280 be regarded as preferable to the other based on the preference. It 281 has to be noted that if several candidate paths of the same SR policy 282 (endpoint, color) are signaled via BGP to a head-end, it is 283 recommended that each NLRI use a different distinguisher. Refer to 284 examples later in this document. 286 In the vast majority of use-cases known to date, a path is associated 287 with a single Segment-list and each path of a policy has a different 288 preference. 290 The BSID of an SR Policy refers to its selected path. 292 At any given time, a given BSID MUST map to a single SR policy and 293 indirectly map to its selected path. However, the mapping from a 294 given BSID to an SR Policy may change over the life of the SR policy, 295 and the true identification of a policy is the tuple . 298 An SR Policy is active at a headend as soon as this 299 head-end knows about a valid path for this policy. 301 An active SR Policy installs a BSID-keyed entry in the forwarding 302 plane with the action of steering the packets matching this entry to 303 the selected path of the SR Policy. 305 If a set of Segment-lists is associated with the selected path of the 306 policy, then the steering is flow and W-ECMP based according to the 307 relative weight of each Segment-list. 309 In summary, the information model is the following: 311 SR policy FOO 312 Candidate-paths 313 path preference 200 (selected) 314 BSID1 315 Weight W1, Segment-list1: SID11...SID1i 316 Weight W2, Segment-list2: SID21...SID2j 317 path preference 100 318 BSID2 319 Weight W3, Segment-list3: SID31...SID3i 320 Weight W4, Segment-list4: SID41...SID4j 322 The numbers 200 and 100 are preferences of the paths associated with 323 the policy. 325 In general BSDIn = BSID1 = BSID2 ... If paths of an SR policy have 326 different BSIDs, then the BSID of the SR policy is that of the 327 selected path. 329 4. SR Policy Active Path Selection Examples 331 Example 1: 333 Consider headend H where two candidate paths of the same SR Policy 334 (endpoint, color) are signaled via BGP and whose respective NLRIs 335 have the same route distinguishers: 337 NLRI A with distinguisher = RD1, color = C, endpoint = N, preference 338 P1. 340 NLRI B with distinguisher = RD1, color = C, endpoint = N, preference 341 P2. 343 o Because the NLRIs are identical (same distinguisher), BGP will 344 perform bestpath selection. Note that there are no changes to BGP 345 best path selection algorithm. 346 o H installs one advertisement as bestpath into the BGP table. 347 o A single advertisement is passed to the SRTE process. 348 o SRTE process does not perform any path selection. 350 Note that the candidate path's preference value do not have any 351 effect on the BGP bestpath selection process. 353 Example 2: 355 Consider headend H where two candidate paths of the same SR Policy 356 (endpoint, color) are signaled via BGP and whose respective NLRIs 357 have different route distinguishers: NLRI A with distinguisher = RD1, 358 color = C, endpoint = N, preference P1. NLRI B with distinguisher = 359 RD2, color = C, endpoint = N, preference P2. 361 o Because the NLRIs are different (different distinguisher), BGP 362 will not perform bestpath selection. 363 o H installs both advertisements into the BGP table. 364 o Both advertisements are passed to the SRTE process. 365 o SRTE process at H selects the candidate path advertised by NLRI B 366 as the active path for the SR policy since P2 is greater than P1. 368 Note that the recommended approach is to use NLRIs with different 369 distinguishers when several candidate paths for the same SR Policy 370 (endpoint, color) are signaled via BGP to a headend. 372 Example 3: 374 Consider that a headend H learns two candidate paths of the same SR 375 Policy (endpoint, color); one signaled via BGP and another via Local 376 configuration. 378 NLRI A with distinguisher = RD1, color = C, endpoint = N, preference 379 P1. 381 Local "foo" with color = C, endpoint = N, preference P2. 383 o H installs NLRI A into the BGP table. 384 o NLRI A and "foo" are both passed to the SRTE process. 385 o SRTE process at H selects the candidate path indicated by "foo" as 386 the active path for the SR policy since P2 is greater than P1. 388 When an SR Policy has multiple valid candidate paths with the the 389 same best preference, the SRTE process at a headend MAY keep the 390 oldest candidate path as the active path as explained in the 391 following examples: 393 Example 1: 395 Consider headend H with two candidate paths of the same SR Policy 396 (endpoint, color) and the same preference value. 398 o NLRI A with distinguisher RD1, color C, endpoint N, preference P1 399 (selected as active path at time t0). 400 o NLRI B with distinguisher RD2, color C, endpoint N, preference P1 401 (passed to SRTE process at time t1). 403 After t1, SRTE process at H retains candidate path associated with 404 NLRI A as active path of the SR policy. 406 Example 2: 408 Consider headend H with two candidate paths of the same SR Policy 409 (endpoint, color) and the same preference value. 411 o Local "foo" with color C, endpoint N, preference P1 (selected as 412 active path at time t0). 413 o NLRI A with distinguisher RD1, color C, endpoint N, preference P1 414 (passed to SRTE process at time t1). 416 After t1, SRTE process at H retains candidate path associated with 417 Local candidate path "foo" as active path of the SR policy. 419 Note that a headend node MUST NOT install in FIB the "merged" set of 420 segment-lists associated with the candidate paths with the best 421 preference. 423 5. Segment-list 425 A Segment-list includes segments of different types (1 to 8) and an 426 optional weight value that is used for W-ECMP. 428 The following segment types are defined: 430 Type 1: SID only, in the form of MPLS Label. 431 Type 2: SID only, in the form of IPv6 address. 432 Type 3: IPv4 Node Address with optional SID. 433 Type 4: IPv6 Node Address with optional SID. 434 Type 5: IPv4 Address + index with optional SID. 435 Type 6: IPv4 Local and Remote addresses with optional SID. 436 Type 7: IPv6 Address + index with optional SID. 437 Type 8: IPv6 Local and Remote addresses with optional SID. 439 The optional SID can be an MPLS label (SR applied to the MPLS 440 dataplane) or an IPv6 SID (SRv6, SR applied to the IPv6 dataplane). 442 When SR is applied to MPLS, a type 1 SID may be any MPLS label 443 including (but not limited to): segment types described in 444 [I-D.ietf-spring-segment-routing], static MPLS labels and /or 445 reserved labels. 447 When building the MPLS label stack or the IPv6 Segment list from the 448 Segment List, the node instantiating the policy MUST interpret the 449 set of Segments as follows: 451 o The first Segment represents the topmost label or the first IPv6 452 segment. It identifies the first segment the traffic will be 453 directed toward along the SR explicit path. 454 o The last Segment represents the bottommost label or the last IPv6 455 segment the traffic will be directed toward along the SR explicit 456 path. 458 A Segment-list is represented as where S1 is the 459 first SID. 461 5.1. Explicit Null 463 A Type 1 SID may be any MPLS label, including reserved labels. 465 For example, assuming that the desired traffic-engineered path from a 466 headend 1 to an endpoint 4 can be expressed by the Segment-list 467 <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer 468 to the IPv4 Prefix SIDs bound to node 2, 3 and 4, then IPv6 traffic 469 can be traffic-engineered from nodes 1 to 4 via the previously 470 described path using an SR Policy with Segment-list <16002, 16003, 471 16004, 2> where mpls label value of 2 represents the "IPv6 Explicit 472 NULL Label". 474 The penultimate node before node 4 will pop 16004 and will forward 475 the frame on its directly connected interface to node 4. 477 The endpoint receives the traffic with top label "2" which indicates 478 that the payload is an IPv6 packet. 480 When steering unlabeled IPv6 BGP destination traffic using an SR 481 policy composed of Segment-list(s) based on IPv4 SIDs, the headend 482 node SHOULD automatically impose the "IPv6 Explicit NULL Label" as 483 bottom of stack label. Refer to "Steering" section later in this 484 document. 486 6. SR Policy Multi-Domain Database 488 A headend can learn an attached domain topology via its IGP or a BGP- 489 LS session. A headend can learn a non-attached domain topology via a 490 BGP-LS session. 492 A headend collects all these topologies in the SR-TE database (SRTE- 493 DB). 495 The SRTE-DB is multi-domain capable. 497 In some deployments, the SRTE-DB may only contain the attached domain 498 topology while in others, the SRTE-DB may contain the topology of 499 multiple domains. 501 7. Operations 503 7.1. W-ECMP 505 Packets steered to an SR Policy (i.e. to its BSID either via presence 506 in the packet header as active segment or via FIB recursion) are 507 load-balanced on a weighted basis among the Segment-lists associated 508 with the selected path of the SR Policy. 510 The fraction of the flows associated with a given Segment-list is w/ 511 Sw where w is the weight of the Segment-list and Sw is the sum of the 512 weights of the Segment-lists of the selected path of the SR Policy. 514 The accuracy of the weighted load-balancing depends on the platform 515 implementation. 517 7.2. Path Validation 519 A Segment-list MUST be declared invalid when: 521 o It is empty. 522 o The headend is unable to resolve the first SID into one or more 523 outgoing interface(s) and next-hop(s). 524 o The headend is unable to resolve any non-first SID of type 3-to-8 525 into an MPLS label or an SRv6 SID. 527 Unreachable means that the headend has no path to the SID in its 528 SRTE-DB. 530 In multi-domain deployments, it is expected that the headend be 531 unable to verify the reachability of the SIDs in remote domains. 532 Types 1 and 2 MUST be used for the SIDs for which the reachability 533 cannot be verified. Note that the first SID must always be reachable 534 whatever is type. 536 In addition, a Segment-list MAY be declared invalid when: 538 o Its last segment is not a Prefix SID (including BGP Peer Node-SID) 539 advertised by the node specified as the endpoint of the 540 corresponding SR policy. 541 o Its last segment is not an Adjacency SID (including BGP Peer 542 Adjacency SID) of any of the links present on neighbor nodes and 543 that terminate on the node specified as the endpoint of the 544 corresponding SR policy. 546 A Path is invalid as soon as it has no valid Segment-list. 548 The headend of an SR Policy updates the validity of a Segment-list 549 upon network topological change. 551 A path of an SR Policy is invalid when all its Segment-lists are 552 invalid. 554 An SR Policy is invalid when all its paths are invalid. 556 7.3. Fast Convergence 558 Upon topological change, many policies could be recomputed. An 559 implementation MAY provide a per-policy priority field. The operator 560 MAY set this field to indicate in which order the policies should be 561 re-computed. Such a priority may be represented by an integer in the 562 range [0, 254] where the lowest value is the highest priority. 564 8. Binding SID 566 8.1. Benefits 568 The Binding SID (BSID) is fundamental to Segment Routing. It 569 provides scaling, network opacity and service independence. 571 A---DCI1----C----D----E----DCI3---H 572 / | | \ 573 S | | Z 574 \ | | / 575 B---DCI2----F---------G----DCI4---K 576 <==DC1==><=========Core========><==DC2==> 578 Figure 3: A Simple Datacenter Topology 580 A simplified illustration is provided on the basis of the previous 581 diagram where we assume that S, A, B, Data Center Interconnect DCI1 582 and DCI2 share the same IGP-SR instance in the data-center 1 (DC1). 583 DCI1, DCI2, C, D, E, F, G, DCI3 and DCI4 share the same IGP-SR domain 584 in the core. DCI3, DCI4, H, K and Z share the same IGP-SR domain in 585 the data-center 2 (DC2). 587 In this example, we assume no redistribution between the IGP's and no 588 presence of BGP. The inter-domain communication is only provided by 589 SR through SR Policies. 591 The latency from S to DCI1 equals to DCI2. The latency from Z to 592 DCI3 equals to DCI4. All the intra-DC links have the same IGP metric 593 10. 595 The path DCI1, C, D, E, DCI3 has a lower latency and lower capacity 596 than the path DCI2, F, G, DCI4. 598 The IGP metrics of all the core links are set to 10 except the links 599 D-E which is set to 100. 601 A low-latency multi-domain policy from S to Z may be expressed as 602 where: 604 o DCI1 is the prefix SID of DCI1. 605 o BSID is the Binding SID bound to an SR policy 606 instantiated at DCI1. 607 o Z is the prefix SID of Z. 609 Without the use of an intermediate core SR Policy (efficiently 610 summarized by a single BSID), S would need to steer its low-latency 611 flow into the policy . 613 The use of a BSID (and the intermediate bound SR Policy) decreases 614 the number of segments imposed by the source. 616 A BSID acts as a stable anchor point which isolates one domain from 617 the churn of another domain. Upon topology changes within the core 618 of the network, the low-latency path from DCI1 to DCI3 may change. 619 While the path of an intermediate policy changes, its BSID does not 620 change. Hence the policy used by the source does not change, hence 621 the source is shielded from the churn in another domain. 623 A BSID provides opacity and independence between domains. The 624 administrative authority of the core domain may not want to share 625 information about its topology. The use of a BSID allows keeping the 626 service opaque. S is not aware of the details of how the low-latency 627 service is provided by the core domain. S is not aware of the need 628 of the core authority to temporarily change the intermediate path. 630 8.2. Allocation 632 There are three approaches to allocate a BSID to an SR Policy: all 633 the paths have no explicit BSID (called dynamic allocation), all the 634 paths have the same explicit BSID (explicit allocation) and finally a 635 mix of paths with and without explicit BSID (generic allocation). 637 In practice, all the use-cases seen to-date either use the explicit 638 allocation or the dynamic allocation. The explicit allocation is 639 most-often associated with controller-instantiated SR Policies. The 640 dynamic allocation is most-often associated with router-based on- 641 demand SR Policies. 643 8.2.1. Dynamic BSID Allocation 645 No path of the SR Policy have a specified BSID. 647 In such a case, the SR-TE implementation allocates a SID to the SR 648 Policy and keeps it along the whole existence of the policy. 650 In the case of SR-MPLS, the SR-TE implementation binds a local 651 dynamic label in the same way LDP, RSVP-TE or BGP would do. 653 8.2.2. Explicit BSID Allocation 655 All the paths of the SR Policy have the same specified BSID, with the 656 same behavioral preference in case this specified BSID is not 657 available. 659 If the specified BSID is available, then it is bound to the SR Policy 660 and used along the existence of the policy. 662 If the specified BSID is not available, then a SYSLOG/NETCONF message 663 is generated and if the preferred behavior is to fall-back on the 664 dynamic allocation, then the dynamic allocation is performed. 666 If the specified BSID is not available and the operator-requested 667 behavior is to not fall-back on the dynamic allocation, then a 668 SYSLOG/NETCONF message is generated and the SR Policy does not 669 install any BSID entry in the forwarding plane. 671 A later section will explain how controllers can discover the local 672 SIDs available at a node N so as to pick an explicit BSID for a SR 673 Policy to be instantiated at headend N. 675 8.2.2.1. Explicit BSID Allocation within a Label Block 677 A headend node MAY validate BSID allocation within a label block 678 (e.g., SRLB). In this case the following applies: 680 o If the specified BSID falls outside this block, then a SYSLOG/ 681 NETCONF message is generated and the SR Policy MUST NOT install 682 any BSID entry in the forwarding plane. 683 o If the specified BSID falls inside this block but conflicts with 684 either a BSID of another policy or with another application (e.g. 685 explicit Adjacency SID), then a SYSLOG/NETCONF message is 686 generated and the SR Policy MUST NOT install any BSID entry in the 687 forwarding plane. 689 8.2.3. Generic BSID Allocation 691 This section details the BSID allocation when a policy is made of 692 paths with different BSID allocation behaviors (e.g., mix of paths 693 with and without an explicit BSID, potentially with different 694 explicit BSIDs). 696 When the selected path has a specified BSID, the SR Policy uses that 697 BSID if this value (label in MPLS, IPv6 address in SRv6) is available 698 (i.e. not associated with any other usage: e.g. to another MPLS 699 client, to another SID, to another SR Policy). 701 If the selected path's BSID is not available, then the SR Policy 702 keeps the previous BSID. If the SR Policy did not have a previous 703 BSID, then the SR Policy dynamically binds a BSID to itself. 705 Note that a path may request that only its specified BSID be used. 706 In that case, if that BSID is not available and that path is active, 707 then no BSID is bound to the policy and a SYSLOG/NETCONF is 708 triggered. In this case, the SR Policy does not install any entry 709 indexed by a BSID in the forwarding plane. 711 When an SR Policy has multiple valid paths with the best preference 712 but with different BSIDs, it is left to the implementation to decide 713 which BSID to install. This case is unlikely in practice for two 714 reasons. First, all known use-cases share the same BSID across all 715 the paths of a given SR Policy. Second, all known use-cases have a 716 different preference for each path. Hence in practice a single path 717 will be active and with a stable BSID on a per-policy basis. 719 9. Centralized Discovery 721 This section explains how controllers can discover the local SIDs 722 available at a node N so as to pick an explicit BSID for a SR Policy 723 to be instantiated at headend N. 725 Any controller can discover the following properties of a node N 726 (e.g. via BGP-LS, NETCONF etc.): 728 o its local Segment Routing Label Block (SRLB). 729 o its local topology. 730 o its topology-related SIDs (Adj SID and EPE SID). 731 o its SR Policies and their BSID 732 ([I-D.ietf-idr-te-lsp-distribution]). 734 Any controller can thus infer the available SIDs in the SRLB of any 735 node. 737 As an example, a controller discovers the following characteristics 738 of N: SRLB [4000, 8000], 3 Adj SIDs (4001, 4002, 4003), 2 EPE SIDs 739 (4004, 4005) and 3 SRTE policies (whose BSIDs are respectively 4006, 740 4007 and 4008). This controller can deduce that the SRLB sub-range 741 [4009, 5000] is free for allocation. 743 Likely, the next question is: how do we ensure that different 744 controllers do not pick the same available SID at the same time for 745 different SR Policies. 747 Clearly, a controller is not restricted to use the next numerically 748 available SID in the available SRLB sub-range. It can pick any label 749 in the subset of available labels. This random pick make the chance 750 for a collision unlikely. 752 An operator could also sub-allocate the SRLB between different 753 controllers (e.g. [4000-4499] to controller 1 and [4500-5000] to 754 controller 2). 756 Inter-controller state-synchronization may be used to avoid/detect 757 collision in BSID. 759 All these techniques make the likelihood of a collision between 760 different controllers very unlikely. 762 In the unlikely case of a collision, the controllers will detect it 763 through SYSLOG/NETCONF, BGP-LS reporting 764 ([I-D.ietf-idr-te-lsp-distribution]) or PCEP notification. They then 765 have the choice to continue the operation of their SR Policy with the 766 dynamically allocated BSID or re-try with another explicit pick. 768 Note: in deployments where PCE Protocol (PCEP) is used between head- 769 end and controller (PCE), a head-end can report BSID as well as 770 policy attributes (e.g., type of disjointness) and operational and 771 administrative states to controller. Similarly, a controller can 772 also assign/update the BSID of a policy via PCEP when instantiating 773 or updating SR Policy. 775 10. Dynamic Path 777 A dynamic path is a path that expresses an optimization objective and 778 constraints. 780 The headend of the policy is responsible to compute a Segment-list 781 ("solution Segment-list") that fits this optimization problem. The 782 headend is responsible for computing the solution Segment-list any 783 time the inputs to the problem change (e.g. topology changes). 785 10.1. Optimization Objective 787 We define two optimization objectives: 789 o Min-Metric - requests computation of a solution Segment-list 790 optimized for a selected metric. 791 o Min-Metric with margin and maximum number of SIDs - Min-Metric 792 with two changes: a margin of by which two paths with similar 793 metrics would be considered equal, a constraint on the max number 794 of SIDs in the Segment-list. 796 The "Min-Metric" optimization objective requests to compute a 797 solution Segment-list such that packets flowing through the solution 798 Segment-list use ECMP-aware paths optimized for the selected metric. 799 The "Min-Metric" objective can be instantiated for the IGP metric xor 800 the TE metric xor the latency extended TE metric. This metric is 801 called the O metric (the optimized metric) to distinguish it from the 802 IGP metric. The solution Segment-list must be computed to minimize 803 the number of SIDs and the number of Segment-lists. 805 If the selected O metric is the IGP metric and the headend and 806 tailend are in the same IGP domain, then the solution Segment-list is 807 made of the single prefix-SID of the tailend. 809 When the selected O metric is not the IGP metric, then the solution 810 Segment-list is made of prefix SIDs of intermediate nodes, Adjacency 811 SIDs along intermediate links and potentially BSIDs of intermediate 812 policies. 814 In many deployments there are insignificant metric differences 815 between mostly equal path (e.g. a difference of 100 usec of latency 816 between two paths from NYC to SFO would not matter in most cases). 817 The "Min-Metric with margin" objective supports such requirement. 819 The "Min-Metric with margin and maximum number of SIDs" optimization 820 objective requests to compute a solution Segment-list such that 821 packets flowing through the solution Segment-list do not use a path 822 whose cumulated O metric is larger than the shortest-path O metric + 823 margin. 825 If this is not possible because of the number of SIDs constraint, 826 then the solution Segment-list minimizes the O metric while meeting 827 the maximum number of SID constraints. 829 10.2. Constraints 831 The following constraints can be defined: 833 o Inclusion and/or exclusion of TE affinity. 834 o Inclusion and/or exclusion of IP address. 835 o Inclusion and/or exclusion of SRLG. 836 o Inclusion and/or exclusion of admin-tag. 837 o Maximum accumulated metric (IGP, TE and latency). 838 o Maximum number of SIDs in the solution Segment-list. 839 o Maximum number of weighted Segment-lists in the solution set. 840 o Diversity to another service instance (e.g., link, node, or SRLG 841 disjoint paths originating from different head-ends). 843 10.3. SR Native Algorithm 845 1----------------2----------------3 846 |\ / 847 | \ / 848 | 4-------------5-------------7 849 | \ /| 850 | +-----------6-----------+ | 851 8------------------------------9 853 Figure 4: Illustration used to describe SR native algorithm 855 Let us assume that all the links have the same IGP metric of 10 and 856 let us consider the dynamic path defined as: Min-Metric(from 1, to 3, 857 IGP metric, margin 0) with constraint "avoid link 2-to-3". 859 A classical circuit implementation would do: prune the graph, compute 860 the shortest-path, pick a single non-ECMP branch of the ECMP-aware 861 shortest-path and encode it as a Segment-list. The solution Segment- 862 list would be <4, 5, 7, 3>. 864 An SR-native algorithm would find a Segment-list that minimizes the 865 number of SIDs and maximize the use of all the ECMP branches along 866 the ECMP shortest path. In this illustration, the solution Segment- 867 list would be <7, 3>. 869 In the vast majority of SR use-cases, SR-native algorithms should be 870 preferred: they preserve the native ECMP of IP and they minimize the 871 dataplane header overhead. 873 In some specific use-case (e.g. TDM migration over IP where the 874 circuit notion prevails), one may prefer a classic circuit 875 computation followed by an encoding into SIDs. 877 SR-native algorithms are a local node behavior and are thus outside 878 the scope of this document. 880 10.4. Path to SID 882 Let us assume the below diagram where all the links have an IGP 883 metric of 10 and a TE metric of 10 except the link AB which has an 884 IGP metric of 20 and the link AD which has a TE metric of 100. Let 885 us consider the min-metric(from A, to D, TE metric, margin 0). 887 B---C 888 | | 889 A---D 891 Figure 5: Illustration used to describe path to SID conversion 893 The solution path to this problem is ABCD. 895 This path can be expressed in SIDs as $#60;B, D$#62; where B and D 896 are the IGP prefix SIDs respectively associated with nodes B and D in 897 the diagram. 899 Indeed, from A, the IGP path to B is AB (IGP metric 20 better than 900 ADCB of IGP metric 30). From B, the IGP path to D is BCD (IGP metric 901 20 better than BAD of IGP metric 30). 903 While the details of the algorithm remain a local node behavior, a 904 high-level description follows: start at the headend and find an IGP 905 prefix SID that leads as far down the desired path as possible 906 (without using any link not included in the desired path). If no 907 prefix SID exists, use the Adj SID to the first neighbor along the 908 path. Restart from the node that was reached. 910 10.5. PCE Computed Path 912 A local computation should be preferred whenever possible. When 913 local computation is not possible (e.g., a policy's tail-end is 914 outside the topology known to the head-end), the head-end may send 915 path computation request to a PCE supporting PCEP extension specified 916 in [I-D.ietf-pce-segment-routing]. 918 11. Signaling Paths of an SR Policy to a Head-end 920 A headend H can be informed about a candidate path for an SR policy 921 (endpoint, color) via several means: BGP, PCEP, CLI, netconf. 923 We remind that the selection of the best path for a policy is 924 independent of the protocol source of the path. 926 11.1. BGP 928 Please refer to [I-D.previdi-idr-segment-routing-te-policy] 930 11.2. PCEP 932 Please refer to [I-D.ietf-pce-pce-initiated-lsp] 934 11.3. NETCONF 936 Operator MUST be able to install policy via NETCONF with OpenConfig/ 937 YANG models (work in progress). 939 11.4. CLI 941 Operator MUST be able to install policy via CLI. 943 12. Steering into an SR Policy 945 A headend can steer a packet flow on an SR Policy in various ways: 947 o Incoming packets have an active SID matching a local BSID at the 948 head-end. 949 o Incoming packets match a BGP/Service route which recurses on the 950 BSID of a local policy. 951 o Incoming packets match a BGP/Service route which recurses on an 952 array of paths to the BGP nhop where some of the paths in the 953 array are local SR Policies. 954 o Incoming packets match a routing policy which directs them on a 955 local SR policy. 957 For simplicity of illustration, we will use the SR-MPLS example. 959 12.1. Incoming Active SID is a BSID 961 Let us assume that headend H has a local SR Policy P of Segment-list 962 and BSID B. 964 When H receives a packet with label stack , H pops B and 965 pushes . H sends the resulting packet with label stack 966 along the path to S1. 968 The previous is an example assuming that S1 is the Prefix-SID of a 969 remote node in the network. 971 Actual programming of the first segment in the segment-list MUST take 972 into accountthe type of segment represented by the SID. 974 To illustrate the previous point, let us assume that headend H has a 975 local SR Policy Q of Segment-list (where S1 is an Adj- 976 SID at H) and BSID B. When H receives a packet with label stack , H pops B and pushes . H sends the resulting packet 978 with label stack along the outgoing interface(s) 979 associated with Adj-SID S1. 981 H has steered the packet in the 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 such as to better scale 992 and simplify intermediate aggregation nodes. 994 12.2. Recursion on a BSID 996 Let us assume that headend H: 998 o learns about a BGP route R/r via next-hop N, extended-color 999 community C and label V. 1000 o has a local SR Policy P to (endpoint = N, color = C) of Segment- 1001 list and BSID B. 1002 o has a local BGP policy which matches on the extended-color 1003 community C and allows its usage as an SR-TE SLA steering 1004 information. 1006 In such a case, H installs R/r in RIB/FIB with next-hop = B (instead 1007 of N). 1009 Indeed, H's local BGP policy and the received BGP route indicate that 1010 the headend should associate R/r with an SR-TE path to N with the SLA 1011 associated with color C. The headend therefore installs the BGP 1012 route on that policy. 1014 This can be implemented by using the BSID as a generalized nhop and 1015 installing the BGP route on that generalized next-hop. 1017 When H receives a packet with a destination matching R/r, H pushes 1018 the label stack and sends the resulting packet along 1019 the path to S1. 1021 Note that any label associated with the BGP route is pushed after the 1022 Segment-list of the SR Policy. 1024 12.2.1. Multiple Colors 1026 When a BGP route has multiple extended-color communities each with a 1027 valid SRTE policy, the BGP process installs the route on the Binding 1028 SID corresponding to the SR policy whose color is of highest 1029 numerical value. 1031 Let us assume that headend H: 1033 o learns about a BGP route R/r via next-hop N, extended-color 1034 communities C1 and C2 and label V. 1035 o has a local SR Policy P1 to (endpoint = N, color = C1) of SID list 1036 and BSID B1. 1037 o has a local SR Policy P2 to (endpoint = N, color = C2) of SID list 1038 and BSID B2. 1039 o has a local BGP policy which matches on the extended-color 1040 communities C1 and C2 and allows their usage as an SR-TE SLA 1041 steering information. 1043 In such a case, H installs R/r in RIB/FIB with next-hop = B2 (instead 1044 of N) because C2 > C1. 1046 12.3. Recursion on an on-demand dynamic BSID 1048 In the previous section, we assumed that H had a pre-established 1049 "explicit" SR Policy (endpoint N, color C). 1051 In this section,independently to the a-priori existence of any 1052 explicit path of the SR policy (N, C), we note that the BGP process 1053 at node H triggers the SRTE process at node H to instantiate a 1054 dynamic path for the SR policy (N, C) as soon as: 1056 o the BGP process learns of a route R/r via N and with color C. 1057 o a local policy at node H authorizes the on-demand SRTE path 1058 instantiation and maps the color to a dynamic SRTE optimization 1059 template. 1061 12.3.1. Multiple Colors 1063 When a BGP route R/r via N has multiple extended-color communities Ci 1064 (with i=1 ... n), an individual on-demand SR-TE dynamic path request 1065 (endpoint N, color Ci) is triggered for each color Ci. 1067 12.4. An array of BSIDs associated with an IGP entry 1069 Let us assume that head-end H: 1071 o learns about a BGP route R/r via next-hop N and label V. 1073 o has a local SR Policy P1 to (endpoint = N, color = C1) of Segment- 1074 list and BSID B1. 1075 o has a local SR Policy P2 to (endpoint = N, color = C2) of Segment- 1076 list and BSID B2. 1077 o is configured to instantiate an array of paths to N where the 1078 entry 0 is the IGP path to N, color C1 is the first entry and 1079 Color C2 is the second entry. The index into the array is called 1080 a Forwarding Class (FC). The index can have values 0 to 7. 1081 o is configured to match flows in its ingress interfaces (upon any 1082 field such as Ethernet destination/source/vlan/tos or IP 1083 destination/source/DSCP or transport ports etc.) and color them 1084 with an internal per-packet forwarding-class variable (0, 1 or 2 1085 in this example). 1087 In such a case, H installs in RIB/FIB: 1089 o R/r in with next-hop N (as usual). 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. 1094 o Entry A(1) set to B1. 1095 o Entry A(2) set to B2. 1097 H receives three packets P, P1 and P2 on its incoming interface. H 1098 colors them respectively with forwarding-class 0, 1 and 2. As a 1099 result: 1101 o H pushes on packet P and forwards the resulting frame along 1102 the shortest-path to N (which in SR-MPLS results in the pushing of 1103 the prefix-SID of N. 1104 o H pushes on packet P1 and forwards the resulting 1105 frame along the shortest-path to S1. 1106 o H pushes on packet P2 and forwards the resulting 1107 frame along the shortest-path to S4. 1109 If the local configuration does not specify any explicit forwarding 1110 information for an entry of the array, then this entry is filled with 1111 the same information as entry 0 (i.e. the IGP shortest-path). 1113 This realizes per-flow steering: different flows bound to the same 1114 BGP destination R/r are steered on different SR-TE paths. 1116 12.5. A Routing Policy on a BSID 1118 Finally, headend H may be configured with a local routing policy 1119 which overrides any BGP/IGP path and steer a specified flow on an SR 1120 Policy. 1122 13. Optional Steering Modes for BGP Destinations 1124 13.1. Color-Only BGP Destination Steering 1126 In the previous section "Recursion on a BSID", we have seen that the 1127 steering on an SR Policy is governed by the matching of the BGP 1128 route's next-hop N and the authorized color C with a local SR Policy 1129 defined by the tuple (N, C). 1131 This is the most likely form of BGP destination steering and the one 1132 we recommend. 1134 In this section, we define an alternative steering mechanism based 1135 only on the color. 1137 This color-only steering variation is governed by two new flags "C" 1138 and "O" defined in the color extended community. 1140 The Color-Only flags "CO" are set to 00 by default. 1142 When 00, the BGP destination is preferably steered onto a valid SR 1143 Policy (N, C) where N is an IPv4/6 endpoint address and C is a color 1144 value else it is steered on the IGP path to the next-hop N. This is 1145 the classic case we described before and that we recommend. 1147 When 01, the BGP destination is preferably steered onto a valid SR 1148 Policy (N, C) else onto a valid SR Policy (null endpoint, C) of the 1149 same address-family of N else on any valid SR Policy (any null 1150 endpoint, C) else on the IGP path to the next-hop N. 1152 When 10, the BGP destination is preferably steered onto a valid SR 1153 Policy (N, C) else onto a valid SR Policy (null endpoint, C) of the 1154 same address-family of N else on any valid SR Policy (any null 1155 endpoint, C) else on any valid SR Policy (any endpoint, C) of the 1156 same address-family of N else on any valid SR Policy (any endpoint, 1157 C) else on the IGP path to the next-hop N. 1159 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set 1160 to the 0 value). 1162 When 11, it is treated like 00. 1164 13.2. Drop on Invalid 1166 The local BGP policy authorizing the use of an extended color 1167 community steering on an SR policy may specify that if the related SR 1168 Policy becomes invalid then the related BSID should remain in RIB/FIB 1169 and point to null0 (drop any packet recursing on that BSID). 1171 Recall that, by default, for a BGP route R/r via next-hop N with 1172 extended-color community C, when the SR Policy (N, C) becomes 1173 invalid, then BGP re-installs R/r in RIB/FIB via N (the IGP path to 1174 N). 1176 14. Multipoint SR Policy 1178 14.1. Spray SR Policy 1180 A Spray SR-TE policy is a variant of an SR-TE policy which involves 1181 packet replication. 1183 Any traffic steered into a Spray SR Policy is replicated along the 1184 Segment-lists of its selected path. 1186 In the context of a Spray SR Policy, the selected path SHOULD have 1187 more than one Segment-list. The weights of the Segment-lists is not 1188 applicable for a Spray SR Policy. They MUST be set to 1. 1190 Like any SR policy, a Spray SR Policy has a BSID instantiated into 1191 the forwarding plane. 1193 Traffic is typically steered into a Spray SR Policy in two ways: 1195 o local policy-based routing at the headend of the policy. 1196 o remote classification and steering via the BSID of the Spray SR 1197 Policy. 1199 15. Reporting SR Policy 1201 Stateful PCEP ([I-D.ietf-pce-stateful-pce] and 1202 [I-D.sivabalan-pce-binding-label-sid] provides an ability for head- 1203 end to report BSID, attributes, and operational/administrative 1204 states. Using this protocol, a PCE can also update an existing SR 1205 Policy whose path computation is delegated to it as well as 1206 instantiate new SR Policy on a head-end. 1208 BGP-LS reports an SR Policy via ([I-D.ietf-idr-te-lsp-distribution] 1210 16. Work in Progress 1212 o Open configuration model. 1213 o Yang model. 1215 17. Acknowledgement 1217 18. Normative References 1219 [GLOBECOM] 1220 Filsfils, C., Nainar, N., Pignataro, C., Cardona, J., and 1221 P. Francois, "The Segment Routing Architecture, IEEE 1222 Global Communications Conference (GLOBECOM)", 2015. 1224 [I-D.ietf-idr-te-lsp-distribution] 1225 Previdi, S., Dong, J., Chen, M., Gredler, H., and j. 1226 jefftant@gmail.com, "Distribution of Traffic Engineering 1227 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1228 lsp-distribution-07 (work in progress), July 2017. 1230 [I-D.ietf-isis-segment-routing-extensions] 1231 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1232 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 1233 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1234 segment-routing-extensions-13 (work in progress), June 1235 2017. 1237 [I-D.ietf-pce-pce-initiated-lsp] 1238 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1239 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1240 Model", draft-ietf-pce-pce-initiated-lsp-10 (work in 1241 progress), June 2017. 1243 [I-D.ietf-pce-segment-routing] 1244 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1245 and J. Hardwick, "PCEP Extensions for Segment Routing", 1246 draft-ietf-pce-segment-routing-09 (work in progress), 1247 April 2017. 1249 [I-D.ietf-pce-stateful-pce] 1250 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1251 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1252 pce-21 (work in progress), June 2017. 1254 [I-D.ietf-spring-segment-routing] 1255 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1256 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1257 spring-segment-routing-12 (work in progress), June 2017. 1259 [I-D.previdi-idr-segment-routing-te-policy] 1260 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. 1261 Lin, "Advertising Segment Routing Policies in BGP", draft- 1262 previdi-idr-segment-routing-te-policy-07 (work in 1263 progress), June 2017. 1265 [I-D.sivabalan-pce-binding-label-sid] 1266 Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., 1267 Hardwick, J., and M. Nanduri, "Carrying Binding Label/ 1268 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 1269 binding-label-sid-02 (work in progress), October 2016. 1271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1272 Requirement Levels", BCP 14, RFC 2119, 1273 DOI 10.17487/RFC2119, March 1997, 1274 . 1276 [SIGCOMM] Hartert, R., Vissicchio, S., Schaus, P., Bonaventure, O., 1277 Filsfils, C., Telkamp, T., and P. Francois, "A Declarative 1278 and Expressive Approach to Control Forwarding Paths in 1279 Carrier-Grade Networks, ACM SIGCOMM", 2015. 1281 Authors' Addresses 1283 Clarence Filsfils 1284 Cisco Systems, Inc. 1285 Pegasus Parc 1286 De kleetlaan 6a, DIEGEM BRABANT 1831 1287 BELGIUM 1289 Email: cfilsfil@cisco.com 1291 Siva Sivabalan 1292 Cisco Systems, Inc. 1293 2000 Innovation Drive 1294 Kanata, Ontario K2K 3E8 1295 Canada 1297 Email: msiva@cisco.com 1298 Kamran Raza 1299 Cisco Systems, Inc. 1300 2000 Innovation Drive 1301 Kanata, Ontario K2K 3E8 1302 Canada 1304 Email: skraza@cisco.com 1306 Jose Liste 1307 Cisco Systems, Inc. 1308 821 Alder Drive 1309 Milpitas, California 95035 1310 USA 1312 Email: jliste@cisco.com 1314 Francois Clad 1315 Cisco Systems, Inc. 1317 Email: fclad@cisco.com 1319 Daniel Voyer 1320 Bell Canada. 1321 671 de la gauchetiere W 1322 Montreal, Quebec H3B 2M8 1323 Canada 1325 Email: daniel.voyer@bell.ca 1327 Steven Lin 1328 Google, Inc. 1330 Email: stevenlin@google.com 1332 Alex Bogdanov 1333 Google, Inc. 1335 Email: bogdanov@google.com 1336 Martin Horneffer 1337 Deutsche Telekom 1339 Email: martin.horneffer@telekom.de 1341 Dirk Steinberg 1342 Steinberg Consulting 1344 Email: dws@steinbergnet.net 1346 Bruno Decraene 1347 Orange Business Services 1349 Email: bruno.decraene@orange.com 1351 Stephane Litkowski 1352 Orange Business Services 1354 Email: stephane.litkowski@orange.com