idnits 2.17.00 (12 Aug 2021) /tmp/idnits18660/draft-filsfils-spring-sr-policy-considerations-09.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 document date (April 24, 2022) is 20 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-idr-te-lsp-distribution-16 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Filsfils 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational K. Talaulikar, Ed. 5 Expires: October 26, 2022 Arrcus Inc 6 P. Krol 7 Google, Inc. 8 M. Horneffer 9 Deutsche Telekom 10 P. Mattes 11 Microsoft 12 April 24, 2022 14 SR Policy Implementation and Deployment Considerations 15 draft-filsfils-spring-sr-policy-considerations-09 17 Abstract 19 Segment Routing (SR) allows a headend node to steer a packet flow 20 along any path. Intermediate per-flow states are eliminated thanks 21 to source routing. SR Policy framework enables the instantiation and 22 the management of necessary state on the headend node for flows along 23 a source routed paths using an ordered list of segments associated 24 with their specific SR Policies. This document describes some of the 25 implementation and deployment aspects that are useful for 26 operationalizing the SR Policy architecture. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 26, 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. SR Policy Headend Architecture . . . . . . . . . . . . . . . 3 64 3. Dynamic Path Computation . . . . . . . . . . . . . . . . . . 5 65 3.1. Optimization Objective . . . . . . . . . . . . . . . . . 5 66 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. SR Native Algorithm . . . . . . . . . . . . . . . . . . . 6 68 3.4. Path to SID . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Candidate Path Selection . . . . . . . . . . . . . . . . . . 8 70 5. Distributed and/or Centralized Control Plane . . . . . . . . 12 71 5.1. Distributed Control Plane within a single Link-State IGP 72 area . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.2. Distributed Control Plane across several Link-State IGP 74 areas . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.3. Centralized Control Plane . . . . . . . . . . . . . . . . 12 76 5.4. Distributed and Centralized Control Plane . . . . . . . . 13 77 6. Binding SID Aspects . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Benefits of Binding SID . . . . . . . . . . . . . . . . . 14 79 6.2. Centralized Discovery of available BSID . . . . . . . . . 15 80 7. Flex-Algorithm Based SR Policies . . . . . . . . . . . . . . 16 81 8. Layer 2 and Optical Transport . . . . . . . . . . . . . . . . 17 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 85 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 88 13.2. Informative References . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 Segment Routing (SR) allows a headend node to steer a packet flow 94 along any path. Intermediate per-flow states are eliminated with 95 source routing [RFC8402]. 97 The headend node steers a flow into a Segment Routing Policy (SR 98 Policy) by augmenting packet headers with the ordered list of 99 segments associated with that SR Policy. 100 [I-D.ietf-spring-segment-routing-policy] defines the SR Policy 101 architecture and details the concepts of SR Policy and steering into 102 an SR Policy. 104 This document describes some of the implementation aspects for SR 105 Policy framework which should be considered as suggestions. The same 106 behavior, as defined in [I-D.ietf-spring-segment-routing-policy], may 107 in fact be realized with other alternate approaches. The deployment 108 aspects described in this document are also meant to only serve as 109 guidelines. This document describes these aspects and other 110 considerations related to SR Policy concepts as they are important to 111 facilitate multi-vendor interoperable deployments for various SR 112 Policy use-cases. 114 These apply equally to the MPLS [RFC8660] and SRv6 [RFC8986] 115 instantiations of segment routing. 117 For reading simplicity, the illustrations are provided for the MPLS 118 instantiation. 120 2. SR Policy Headend Architecture 122 This section provides a conceptual overview of components (or 123 functions) that interact to implement SR Policy on a headend 124 +--------+ +--------+ 125 | BGP | | PCEP | 126 +--------+ +--------+ 127 \ / 128 +--------+ +----------+ +--------+ 129 | | | SR | | | 130 | CLI |--| Policy |--| NETCONF| 131 | | | | | | 132 +--------+ +----------+ +--------+ 133 | 134 +--------+ 135 | FIB | 136 +--------+ 138 Figure 1: SR Policy Architecture at a Headend 140 The SR Policy functionality at a headend can be implemented in an SR 141 Policy (SRP) process as illustrated in Figure 1 . 143 The SRP process interacts with other processes to learn candidate 144 paths. 146 The SRP process selects the active path of an SR Policy. 148 The SRP process interacts with the RIB/FIB process to install an 149 active SR Policy in the dataplane. 151 In order to validate explicit candidate paths and compute dynamic 152 candidate paths, the SRP process maintains an SR Database (SR-DB) as 153 specified in [I-D.ietf-spring-segment-routing-policy]. The SRP 154 process interacts with other processes as shown in Figure 2 to 155 collect the SR-DB information. 157 +--------+ +--------+ +--------+ 158 | BGP SR | | BGP-LS | | IGP | 159 | Policy | +--------+ +--------+ 160 +--------+ \ | / 161 +--------+ +-----------+ +--------+ 162 | PCEP |---| SRP |--| NETCONF| 163 +--------+ +-----------+ +--------+ 165 Figure 2: Topology/link-state database architecture 167 The SR Policy architecture supports both centralized and distributed 168 control-plane. 170 3. Dynamic Path Computation 172 A dynamic candidate path for SR Policy is specified as an 173 optimization objective and constraints and needs to be computed by 174 either the headend or a Path Computation Element (PCE). The 175 distributed or centralized computation aspect is described further in 176 Section 5. This section describes the computation aspects of a 177 dynamic path. 179 3.1. Optimization Objective 181 This document describes two optimization objectives: 183 o Min-Metric - requests computation of a solution Segment-List 184 optimized for a selected metric. 186 o Min-Metric with margin and maximum number of SIDs - Min-Metric 187 with two changes: a margin of by which two paths with similar 188 metrics would be considered equal, a constraint on the max number 189 of SIDs in the Segment-List. 191 The "Min-Metric" optimization objective requests to compute a 192 solution Segment-List such that packets flowing through the solution 193 Segment-List use ECMP-aware paths optimized for the selected metric. 194 The "Min-Metric" objective can be instantiated for the IGP metric 195 ([RFC1195] [RFC2328] [RFC5340]) xor the TE metric ([RFC5305] 196 [RFC3630]) xor the latency extended TE metric ([RFC8570] [RFC7471]). 197 This metric is called the O metric (the optimized metric) to 198 distinguish it from the IGP metric. The solution Segment-List must 199 be computed to minimize the number of SIDs and the number of Segment- 200 Lists. 202 If the selected O metric is the IGP metric and the headend and 203 tailend are in the same IGP domain, then the solution Segment-List is 204 made of the single prefix-SID of the tailend. 206 When the selected O metric is not the IGP metric, then the solution 207 Segment-List is made of prefix SIDs of intermediate nodes, Adjacency 208 SIDs along intermediate links and potentially Binding SIDs (BSIDs) of 209 intermediate policies. 211 In many deployments there are insignificant metric differences 212 between mostly equal path (e.g. a difference of 100 usec of latency 213 between two paths from NYC to SFO would not matter in most cases). 214 The "Min-Metric with margin" objective supports such requirement. 216 The "Min-Metric with margin and maximum number of SIDs" optimization 217 objective requests to compute a solution Segment-List such that 218 packets flowing through the solution Segment-List do not use a path 219 whose cumulative O metric is larger than the shortest-path O metric + 220 margin. 222 If this is not possible because of the number of SIDs constraint, 223 then one option is that the solution Segment-List minimizes the O 224 metric while meeting the maximum number of SID constraints (i.e. path 225 with the least value of O metric while using <= the number of SIDs 226 specified). The other default option is to not come up with a 227 solution unless the desired SLA is guaranteed. 229 Section 7 describes another approach for computing a solution 230 Segment-List consisting of a single segment when the O metric is not 231 the IGP metric by using the Flex Algorithm Prefix-SID of the tailend. 233 3.2. Constraints 235 The following constraints can be described: 237 o Inclusion and/or exclusion of TE affinity. 239 o Inclusion and/or exclusion of IP address. 241 o Inclusion and/or exclusion of SRLG. 243 o Inclusion and/or exclusion of admin-tag. 245 o Maximum accumulated metric (IGP, TE and latency). 247 o Maximum number of SIDs in the solution Segment-List. 249 o Maximum number of weighted Segment-Lists in the solution set. 251 o Diversity to another service instance (e.g., link, node, or SRLG 252 disjoint paths originating from different head-ends). 254 3.3. SR Native Algorithm 256 1----------------2----------------3 257 |\ / 258 | \ / 259 | 4-------------5-------------7 260 | \ /| 261 | +-----------6-----------+ | 262 8------------------------------9 264 Figure 3: Illustration used to describe SR native algorithm 266 Let us assume that all the links have the same IGP metric of 10 and 267 let us consider the dynamic path defined as: Min-Metric(from 1, to 3, 268 IGP metric, margin 0) with constraint "avoid link 2-to-3". 270 A classical circuit implementation would do: prune the graph, compute 271 the shortest-path, pick a single non-ECMP branch of the ECMP-aware 272 shortest-path and encode it as a Segment-List. The solution Segment- 273 List would be <4, 5, 7, 3>. 275 An SR-native algorithm would find a Segment-List that minimizes the 276 number of SIDs and maximize the use of all the ECMP branches along 277 the ECMP shortest path. In this illustration, the solution Segment- 278 List would be <7, 3>. 280 In the vast majority of SR use-cases, SR-native algorithms should be 281 preferred: they preserve the native ECMP of IP and they minimize the 282 dataplane header overhead. 284 In some specific use-case (e.g. TDM migration over IP where the 285 circuit notion prevails), one may prefer a classic circuit 286 computation followed by an encoding into SIDs (potentially only using 287 non-protected Adj SIDs that pin the path to specific links and avoid 288 ECMP to reflect the TDM paradigm). 290 SR-native algorithms are a local node behavior and are thus outside 291 the scope of this document. 293 3.4. Path to SID 295 Let us assume the below diagram where all the links have an IGP 296 metric of 10 and a TE metric of 10 except the link AB which has an 297 IGP metric of 20 and the link AD which has a TE metric of 100. Let 298 us consider the min-metric(from A, to D, TE metric, margin 0). 300 B---C 301 | | 302 A---D 304 Figure 4: Illustration used to describe path to SID conversion 306 The solution path to this problem is ABCD. 308 This path can be expressed in SIDs as where B and D are the 309 IGP prefix SIDs respectively associated with nodes B and D in the 310 diagram. 312 Indeed, from A, the IGP path to B is AB (IGP metric 20 better than 313 ADCB of IGP metric 30). From B, the IGP path to D is BCD (IGP metric 314 20 better than BAD of IGP metric 30). 316 While the details of the algorithm remain a local node behavior, a 317 high-level description follows: start at the headend and find an IGP 318 prefix SID that leads as far down the desired path as 319 possible(without using any link not included in the desired path). 320 If no prefix SID exists, use the Adj SID to the first neighbor along 321 the path. Restart from the node that was reached. 323 4. Candidate Path Selection 325 An SR Policy may have multiple candidate paths that are provisioned 326 or signaled [I-D.ietf-idr-segment-routing-te-policy] [RFC8664] from 327 one of more sources. The tie-breaker rules defined in 328 [I-D.ietf-spring-segment-routing-policy] result in determination of a 329 single "active path" in a formal definition. 331 This section describe some examples for the candidate path selection 332 based on the same rules. 334 Example 1: 336 Consider headend H where two candidate paths of the same SR Policy 337 are signaled via BGP 338 [I-D.ietf-idr-segment-routing-te-policy] and whose respective NLRIs 339 have the same route distinguishers: 341 NLRI A with distinguisher = RD1, color = C, endpoint = N, preference 342 P1. 344 NLRI B with distinguisher = RD1, color = C, endpoint = N, preference 345 P2. 347 o Because the NLRIs are identical (same distinguisher), BGP will 348 perform bestpath selection. Note that there are no changes to BGP 349 best path selection algorithm. 351 o H installs one advertisement as bestpath into the BGP table. 353 o A single advertisement is passed to the SR Policy instantiation 354 process. 356 o The SRP process does not perform any path selection. 358 Note that the candidate path's preference value does not have any 359 effect on the BGP bestpath selection process. 361 Example 2: 363 Consider headend H where two candidate paths of the same SR Policy 364 are signaled via BGP and whose respective NLRIs 365 have different route distinguishers: 367 NLRI A with distinguisher = RD1, color = C, endpoint = N, preference 368 P1. 370 NLRI B with distinguisher = RD2, color = C, endpoint = N, preference 371 P2. 373 o Because the NLRIs are different (different distinguisher), BGP 374 will not perform bestpath selection. 376 o H installs both advertisements into the BGP table. 378 o Both advertisements are passed to the SR Policy instantiation 379 process. 381 o SRP process at H selects the candidate path advertised by NLRI B 382 as the active path for the SR policy since P2 is greater than P1. 384 Note that the recommended approach is to use NLRIs with different 385 distinguishers when several candidate paths for the same SR Policy 386 (color, endpoint) are signaled via BGP to a headend. 388 Example 3: 390 Consider that a headend H learns two candidate paths of the same SR 391 Policy one signaled via BGP and another via Local 392 configuration. 394 NLRI A with distinguisher = RD1, color = C, endpoint = N, preference 395 P1. 397 Local "foo" with color = C, endpoint = N, preference P2. 399 o H installs NLRI A into the BGP table. 401 o NLRI A and "foo" are both passed to the SRP process. 403 o SRP process at H selects the candidate path indicated by "foo" as 404 the active path for the SR policy since P2 is greater than P1. 406 Now, let us consider cases, when an SR Policy has multiple valid 407 candidate paths with the same best preference, the SRP process at a 408 headend uses the rules described in 409 [I-D.ietf-spring-segment-routing-policy] section 2.9 to select the 410 active path. This is explained in the following examples: 412 Example 4: 414 Consider headend H with two candidate paths of the same SR Policy 415 and the same preference value received from the 416 same controller R and where RD2 is higher than RD1. 418 o NLRI A with distinguisher RD1, color C, endpoint N, preference 419 P1(selected as active path at time t0). 421 o NLRI B with distinguisher RD2 (RD2 is greater than RD1), color C, 422 endpoint N, preference P1 (passed to SR Policy instantiation 423 process at time t1 > t0). 425 After t1, SRP process at H selects candidate path associated with 426 NLRI B as active path of the SR policy since RD2 is higher than RD1. 427 Here the time when the headend receives the candidate path via BGP is 428 not a factor in the selection. 430 Note that, in such a scenario where there are redundant sessions to 431 the same controller, the recommended approach is to use the same RD 432 value for conveying the same candidate paths and let the BGP best 433 path algorithm pick the best path. 435 Example 5: 437 Consider headend H with two candidate paths of the same SR Policy 438 and the same preference value both received from 439 the same controller R and where RD2 is higher than RD1. 441 Consider also that headend H is configured to override the 442 discriminator tiebreaker specified in 443 [I-D.ietf-spring-segment-routing-policy] section 2.9 444 o NLRI A with distinguisher RD1, color C, endpoint N, preference P1 445 (selected as active path at time t0). 447 o NLRI B with distinguisher RD2, color C, endpoint N, preference P1 448 (passed to SR Policy instantiation process at time t1). 450 Even after t1, SRP process at H retains candidate path associated 451 with NLRI A as active path of the SR policy since the discriminator 452 tiebreaker is disabled at H. 454 Example 6: 456 Consider headend H with two candidate paths of the same SR Policy 457 and the same preference value. 459 o Local "foo" with color C, endpoint N, preference P1 (selected as 460 active path at time t0). 462 o NLRI A with distinguisher RD1, color C, endpoint N, preference P1 463 (passed to SRP process at time t1). 465 Even after t1, SRP process at H retains candidate path associated 466 with local candidate path "foo" as active path of the SR policy since 467 the Local protocol is preferred over BGP by default based on its 468 higher protocol identifier value. 470 Example 7: 472 Consider headend H with two candidate paths of the same SR Policy 473 and the same preference value but received via 474 NETCONF from two controllers R and S (where S > R) 476 o Path A from R with distinguisher D1, color C, endpoint N, 477 preference P1 (selected as active path at time t0). 479 o Path B from S with distinguisher D2, color C, endpoint N, 480 preference P1 (passed to SRP process at time t1). 482 Note that the NETCONF process sends both paths to the SRP process 483 since it does not have any tiebreaker logic. After t1, SRP process 484 at H selects candidate path associated with Path B as active path of 485 the SR policy. 487 5. Distributed and/or Centralized Control Plane 489 5.1. Distributed Control Plane within a single Link-State IGP area 491 Consider a single-area IGP with per-link latency measurement and 492 advertisement of the measured latency in the extended-TE IGP TLV. 494 A head-end H is configured with a single dynamic candidate path for 495 SR policy P with a low-latency optimization objective and endpoint E. 497 Clearly the SRP process at H learns the topology (and extended TE 498 latency information) from the IGP and computes the solution Segment- 499 List providing the low-latency path to E. 501 No centralized controller is involved in such a deployment. 503 The SR-DB at H only uses the Link-State Database (LSDB) provided by 504 the IGP. 506 5.2. Distributed Control Plane across several Link-State IGP areas 508 Consider a domain D composed of two link-state IGP single-area 509 instances (I1 and I2) where each sub-domain benefits from per-link 510 latency measurement and advertisement of the measured latency in the 511 related IGP. The link-state information of each IGP is advertised 512 via BGP-LS [RFC7752] towards a set of BGP-LS route reflectors (RR). 513 H is a headend in IGP I1 sub-domain and E is an endpoint in IGP I2 514 sub-domain. 516 Using a BGP-LS session to any BGP-LS RR, H's SRP process may learn 517 the link-state information of the remote domain I2. H can thus 518 compute the low-latency path from H to E as a solution Segment-List 519 that spans the two domains I1 and I2. 521 The SR-DB at H collects the LSDB from both sub-domains (I1 and I2). 523 No centralized controller is required. 525 5.3. Centralized Control Plane 527 Considering the same domain D as in the previous section, let us now 528 assume that H does not have a BGP-LS session to the BGP-LS RR's. 529 Instead, let us assume a controller "C" has at least one BGP-LS 530 session to the BGP-LS RR's. 532 The controller C learns the topology and extended latency information 533 from both sub-domains via BGP-LS. It computes a low-latency path 534 from H to E as a Segment-List and programs H with the 535 related explicit candidate path. 537 The headend H does not compute the solution Segment-List (it cannot). 538 The headend only validates the received explicit candidate path. 539 Most probably, the controller encodes the SID's of the Segment-List 540 with Type-1. In that case, The headend's validation simply consists 541 in resolving the first SID on an outgoing interface and next-hop. 543 The SR-DB at H only includes the LSDB provided by the IGP I1. 545 The SR-DB of the controller collects the LSDB from both sub- 546 domains(I1 and I2). 548 5.4. Distributed and Centralized Control Plane 550 Consider the same domain D as in the previous section. 552 H's SRP process is configured to associate color C1 with a low- 553 latency optimization objective. 555 H's BGP process is configured to steer a Route R/r of extended-color 556 community C1 and of next-hop N via an SR policy (N, C1). 558 Upon receiving a first BGP route of color C1 and of next-hop N, H 559 recognizes the need for an SR Policy (N, C1) with a low-latency 560 objective to N. As N is outside the SRTE DB of H, H requests a 561 controller to compute such Segment-List (e.g., PCEP [RFC8664]). 563 This is an example of hybrid control-plane: the BGP distributed 564 control plane signals the routes and their TE requirements. Upon 565 receiving these BGP routes, a local headend either computes the 566 solution Segment-List (entirely distributed when the endpoint is in 567 the SR-DB of the headend) else delegates the computation to a 568 controller (hybrid distributed/centralized control-plane). 570 The SR-DB at H only includes the LSDB provided by the IGP. 572 The SR-DB of the controller collects the LSDB from both sub-domains. 574 6. Binding SID Aspects 576 The Binding SID (BSID) is fundamental to Segment Routing. It 577 provides scaling, network opacity and service independence. 579 This section describes implementation and operational aspects related 580 to the Binding SID. 582 6.1. Benefits of Binding SID 584 A simplified illustration is provided on the basis of Figure 5 where 585 it is assumed that S, A, B, Data Center Interconnect DCI1 and DCI2 586 share the same IGP-SR instance in the data-center 1 (DC1). DCI1, 587 DCI2, C, D, E, F, G, DCI3 and DCI4 share the same IGP-SR domain in 588 the core. DCI3, DCI4, H, K and Z share the same IGP-SR domain in the 589 data-center 2 (DC2). 591 A---DCI1----C----D----E----DCI3---H 592 / | | \ 593 S | | Z 594 \ | | / 595 B---DCI2----F---------G----DCI4---K 596 <==DC1==><=========Core========><==DC2==> 598 Figure 5: A Simple Datacenter Topology 600 In this example, it is assumed no redistribution between the IGP's 601 and no presence of BGP-LU. The inter-domain communication is only 602 provided by SR through SR Policies. 604 The latency from S to DCI1 equals to DCI2. The latency from Z to 605 DCI3 equals to DCI4. All the intra-DC links have the same IGP metric 606 10. 608 The path DCI1, C, D, E, DCI3 has a lower latency and lower capacity 609 than the path DCI2, F, G, DCI4. 611 The IGP metrics of all the core links are set to 10 except the links 612 D-E which is set to 100. 614 A low-latency multi-domain policy from S to Z may be expressed as 615 where: 617 o DCI1 is the prefix SID of DCI1. 619 o BSID is the Binding SID bound to an SR policy 620 instantiated at DCI1. 622 o Z is the prefix SID of Z. 624 Without the use of an intermediate core SR Policy (efficiently 625 summarized by a single BSID), S would need to steer its low-latency 626 flow into the policy . 628 The use of a BSID (and the intermediate bound SR Policy) decreases 629 the number of segments imposed by the source. 631 A BSID acts as a stable anchor point which isolates one domain from 632 the churn of another domain. Upon topology changes within the core 633 of the network, the low-latency path from DCI1 to DCI3 may change. 634 While the path of an intermediate policy changes, its BSID does not 635 change. Hence the policy used by the source does not change, hence 636 the source is shielded from the churn in another domain. 638 A BSID provides opacity and independence between domains. The 639 administrative authority of the core domain may not want to share 640 information about its topology. The use of a BSID allows keeping the 641 service opaque. S is not aware of the details of how the low-latency 642 service is provided by the core domain. S is not aware of the need 643 of the core authority to temporarily change the intermediate path. 645 6.2. Centralized Discovery of available BSID 647 This section explains how controllers can discover the local SIDs 648 available at a node N so as to pick an explicit BSID for a SR Policy 649 to be instantiated at headend N. 651 Any controller can discover the following properties of a node N 652 (e.g., via BGP-LS , NETCONF etc.): 654 o its local topology [RFC7752]. 656 o its topology-related SIDs (Prefix SIDs, Adj SID and EPE SID 657 [RFC9085] [RFC9086]). 659 o its Segment Routing Label Block (SRLB). 661 o its SR Policies and their BSID ([RFC8664] 662 [I-D.ietf-pce-binding-label-sid] 663 [I-D.ietf-idr-te-lsp-distribution]). 665 Any controller can thus infer the available SIDs in the SRLB of any 666 node with the assumption that all SIDs allocated from the SRLB on 667 that node are being advertised by it via some protocols or mechanisms 668 to the controller. 670 As an example, a controller discovers the following characteristics 671 of N: SRLB (4000, 8000), 3 Adj SIDs (4001, 4002, 4003), 2 EPE SIDs 672 (4004, 4005) and 3 SRTE policies (whose BSIDs are respectively 4006, 673 4007 and 4008). This controller can deduce that the SRLB sub-range 674 (4009, 8000) is free for allocation. 676 A controller is not restricted to use the next numerically available 677 SID in the available SRLB sub-range. It can pick any label in the 678 subset of available labels. This random pick make the chance for a 679 collision unlikely. 681 An operator could also sub-allocate the SRLB between different 682 controllers (e.g. (4000-4499) to controller 1 and (4500-5000) to 683 controller 2). 685 Inter-controller state-synchronization may be used to avoid/detect 686 collision in BSID. 688 All these techniques make the likelihood of a collision between 689 different controllers very unlikely. 691 In the unlikely case of a collision, the controllers will detect it 692 through system alerts, BGP-LS reporting using 693 [I-D.ietf-idr-te-lsp-distribution] or PCEP notification [RFC8231]. 694 They then have the choice to continue the operation of their SR 695 Policy with the dynamically allocated BSID or re-try with another 696 explicit pick. 698 Note: in deployments where PCE Protocol (PCEP) is used between head- 699 end and controller (PCE), a head-end can report BSID as well as 700 policy attributes (e.g., type of disjointness) and operational and 701 administrative states to controller. Similarly, a controller can 702 also assign/update the BSID of a policy via PCEP when instantiating 703 or updating SR Policy. 705 7. Flex-Algorithm Based SR Policies 707 SR allows for association of algorithms to Prefix SIDs [RFC8402]. 708 [I-D.ietf-lsr-flex-algo] defines the IGP based Flex-Algorithm 709 solution which allows IGPs themselves to compute constraint based 710 paths over the network. Prefix SIDs for the specific flex-algorithm 711 and associated with a node are used in the forwarding plane to steer 712 along the specific constraint path to that node. 714 As specified in [RFC8402] these IGP Flex Algo Prefix SIDs can be used 715 as segments within SR Policies thereby leveraging the underlying IGP 716 Flex Algo solution. 718 1--RED--2-------6 719 | | | 720 4-------3--RED--9 722 Figure 6: Illustration for Flex-Alg SID 724 Now let us assume that 726 o 1, 2, 3 and 4 are part of IGP 1. 728 o 2, 6, 9 and 3 are part of IGP 2. 730 o All the IGP link costs are 10. 732 o Links 1to2 and 3to9 are colored with IGP Link Affinity Red. 734 o Flex-Alg1 is defined in both IGPs as: avoid red, minimize IGP 735 metric. 737 o All nodes of each IGP domain are enabled for FlexAlg1 739 o SID(k, 0) represents the Prefix SID of node k according to Alg=0. 741 o SID(k, FlexAlg1) represents the Prefix SID of node k according to 742 Flex-Alg1. 744 A controller can steer a flow from 1 to 9 through an end-to-end path 745 that avoids the RED links of both IGP domains thanks to the explicit 746 SR Policy . 748 8. Layer 2 and Optical Transport 750 1----2----3----4----5 751 I2(lambda L241)\ / I4(lambda L241) 752 Optical 754 Figure 7: SR Policy with integrated DWDM 756 An explicit candidate path can express a path through a transport 757 layer beneath IP (ATM, FR, DWDM). The transport layer could be ATM, 758 FR, DWDM, back-to-back Ethernet etc. The transport path is modelled 759 as a link between two IP nodes with the specific assumption that no 760 distributed IP routing protocol runs over the link. The link may 761 have IP address or be IP unnumbered. Depending on the transport 762 protocol case, the link can be a physical DWDM interface and a lambda 763 (integrated solution), an Ethernet interface and a VLAN, an ATM 764 interface with a VPI/VCI, a FR interface with a DLCI etc. 766 Using the DWDM integrated use-case of Figure 7 as an illustration, 767 let us assume 769 o nodes 1, 2, 3, 4 and 5 are IP routers running an SR-enable IGP on 770 the links 1-2, 2-3, 3-4 and 4-5. 772 o The SRGB is homogeneous (16000, 24000). 774 o Node K's prefix SID is 16000+K. 776 o node 2 has an integrated DWDM interface I2 with Lambda L1. 778 o node 4 has an integrated DWDM interface I4 with Lambda L2. 780 o the optical network is provisioned with a circuit from 2 to 4 with 781 continuous lambda L241 (details outside the scope of this 782 document). 784 o Node 2 is provisioned with an SR policy with Segment-List 785 and Binding SID B where I2(L241) is of type 5 (IPv4) or 786 type 7 (IPv6), see section 4 of 787 [I-D.ietf-spring-segment-routing-policy] . 789 o node 1 steers a packet P1 towards the prefix SID of node 5 790 (16005). 792 o node 1 steers a packet P2 on the SR policy <16002, B, 16005>. 794 In such a case, the journey of P1 will be 1-2-3-4-5 while the journey 795 of P2 will be 1-2-lambda(L241)-4-5. P2 skips the IP hop 3 and 796 leverages the DWDM circuit from node 2 to node 4. P1 follows the 797 shortest-path computed by the distributed routing protocol. The path 798 of P1 is unaltered by the addition, modification or deletion of 799 optical bypass circuits. 801 The salient point of this example is that the SR Policy architecture 802 seamlessly support explicit candidate paths through any transport 803 sub-layer. 805 BGP-LS Extensions to describe the sub-IP-layer characteristics of the 806 SR Policy are out of scope of this document (e.g. in Figure 7, the 807 DWDM characteristics of the SR Policy at node 2 in terms of latency, 808 loss, security, domain/country traversed by the circuit etc.). 810 Further details of the SR Policy use-case for Packet Optical networks 811 are specified in [I-D.anand-spring-poi-sr] . 813 9. Security Considerations 815 The security considerations related to Segment Routing architecture 816 are described in [RFC8402] and for SR Policy architecture are 817 described in [I-D.ietf-spring-segment-routing-policy] and they apply 818 to this document as well. 820 10. IANA Considerations 822 This document has no actions for IANA. 824 11. Acknowledgement 826 The authors like to thank Tarek Saad, Dhanendra Jain, Muhammad 827 Durrani and Rob Shakir for their valuable comments and suggestions. 829 12. Contributors 831 The following people have contributed to this document: 833 Siva Sivabalan 834 Cisco Systems 835 Email: msiva@cisco.com 837 Zafar Ali 838 Cisco Systems 839 Email: zali@cisco.com 841 Jose Liste 842 Cisco Systems 843 Email: jliste@cisco.com 845 Francois Clad 846 Cisco Systems 847 Email: fclad@cisco.com 849 Kamran Raza 850 Cisco Systems 851 Email: skraza@cisco.com 853 Shraddha Hegde 854 Juniper Networks 855 Email: shraddha@juniper.net 857 Steven Lin 858 Google, Inc. 859 Email: stevenlin@google.com 861 Alex Bogdanov 862 Google, Inc. 863 Email: bogdanov@google.com 865 Daniel Voyer 866 Bell Canada 867 Email: daniel.voyer@bell.ca 868 Dirk Steinberg 869 Steinberg Consulting 870 Email: dws@steinbergnet.net 872 Bruno Decraene 873 Orange Business Services 874 Email: bruno.decraene@orange.com 876 Stephane Litkowski 877 Orange Business Services 878 Email: stephane.litkowski@orange.com 880 Luay Jalil 881 Verizon 882 Email: luay.jalil@verizon.com 884 13. References 886 13.1. Normative References 888 [I-D.ietf-spring-segment-routing-policy] 889 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 890 P. Mattes, "Segment Routing Policy Architecture", draft- 891 ietf-spring-segment-routing-policy-22 (work in progress), 892 March 2022. 894 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 895 Decraene, B., Litkowski, S., and R. Shakir, "Segment 896 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 897 July 2018, . 899 13.2. Informative References 901 [I-D.anand-spring-poi-sr] 902 Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., 903 Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical 904 Integration in Segment Routing", draft-anand-spring-poi- 905 sr-08 (work in progress), July 2019. 907 [I-D.ietf-idr-segment-routing-te-policy] 908 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 909 Jain, D., and S. Lin, "Advertising Segment Routing 910 Policies in BGP", draft-ietf-idr-segment-routing-te- 911 policy-17 (work in progress), April 2022. 913 [I-D.ietf-idr-te-lsp-distribution] 914 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 915 H., and J. Tantsura, "Distribution of Traffic Engineering 916 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 917 lsp-distribution-16 (work in progress), October 2021. 919 [I-D.ietf-lsr-flex-algo] 920 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 921 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 922 algo-19 (work in progress), April 2022. 924 [I-D.ietf-pce-binding-label-sid] 925 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 926 and C. L. (editor), "Carrying Binding Label/Segment 927 Identifier (SID) in PCE-based Networks.", draft-ietf-pce- 928 binding-label-sid-15 (work in progress), March 2022. 930 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 931 dual environments", RFC 1195, DOI 10.17487/RFC1195, 932 December 1990, . 934 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 935 DOI 10.17487/RFC2328, April 1998, 936 . 938 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 939 (TE) Extensions to OSPF Version 2", RFC 3630, 940 DOI 10.17487/RFC3630, September 2003, 941 . 943 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 944 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 945 2008, . 947 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 948 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 949 . 951 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 952 Previdi, "OSPF Traffic Engineering (TE) Metric 953 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 954 . 956 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 957 S. Ray, "North-Bound Distribution of Link-State and 958 Traffic Engineering (TE) Information Using BGP", RFC 7752, 959 DOI 10.17487/RFC7752, March 2016, 960 . 962 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 963 Computation Element Communication Protocol (PCEP) 964 Extensions for Stateful PCE", RFC 8231, 965 DOI 10.17487/RFC8231, September 2017, 966 . 968 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 969 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 970 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 971 2019, . 973 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 974 Decraene, B., Litkowski, S., and R. Shakir, "Segment 975 Routing with the MPLS Data Plane", RFC 8660, 976 DOI 10.17487/RFC8660, December 2019, 977 . 979 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 980 and J. Hardwick, "Path Computation Element Communication 981 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 982 DOI 10.17487/RFC8664, December 2019, 983 . 985 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 986 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 987 (SRv6) Network Programming", RFC 8986, 988 DOI 10.17487/RFC8986, February 2021, 989 . 991 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 992 H., and M. Chen, "Border Gateway Protocol - Link State 993 (BGP-LS) Extensions for Segment Routing", RFC 9085, 994 DOI 10.17487/RFC9085, August 2021, 995 . 997 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 998 Ray, S., and J. Dong, "Border Gateway Protocol - Link 999 State (BGP-LS) Extensions for Segment Routing BGP Egress 1000 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 1001 2021, . 1003 Authors' Addresses 1004 Clarence Filsfils 1005 Cisco Systems, Inc. 1006 Pegasus Parc 1007 De kleetlaan 6a, DIEGEM BRABANT 1831 1008 BELGIUM 1010 Email: cfilsfil@cisco.com 1012 Ketan Talaulikar (editor) 1013 Arrcus Inc 1015 Email: ketant.ietf@gmail.com 1017 Przemyslaw Krol 1018 Google, Inc. 1020 Email: pkrol@google.com 1022 Martin Horneffer 1023 Deutsche Telekom 1025 Email: martin.horneffer@telekom.de 1027 Paul Mattes 1028 Microsoft 1029 One Microsoft Way 1030 Redmond, WA 98052-6399 1031 USA 1033 Email: pamattes@microsoft.com