SR Policy Implementation and Deployment Considerations
draft-filsfils-spring-sr-policy-considerations-08
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Clarence Filsfils , Ketan Talaulikar , Przemysław Gniewomir Król , Martin Horneffer , Paul Mattes | ||
Last updated | 2021-10-22 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-filsfils-spring-sr-policy-considerations-08
SPRING Working Group C. Filsfils Internet-Draft K. Talaulikar, Ed. Intended status: Informational Cisco Systems, Inc. Expires: April 25, 2022 P. Krol Google, Inc. M. Horneffer Deutsche Telekom P. Mattes Microsoft October 22, 2021 SR Policy Implementation and Deployment Considerations draft-filsfils-spring-sr-policy-considerations-08 Abstract Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. SR Policy framework enables the instantiation and the management of necessary state on the headend node for flows along a source routed paths using an ordered list of segments associated with their specific SR Policies. This document describes some of the implementation and deployment aspects that are useful for operationalizing the SR Policy architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 25, 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Filsfils, et al. Expires April 25, 2022 [Page 1] Internet-Draft SR Policy Considerations October 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. SR Policy Headend Architecture . . . . . . . . . . . . . . . 3 3. Dynamic Path Computation . . . . . . . . . . . . . . . . . . 4 3.1. Optimization Objective . . . . . . . . . . . . . . . . . 4 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. SR Native Algorithm . . . . . . . . . . . . . . . . . . . 6 3.4. Path to SID . . . . . . . . . . . . . . . . . . . . . . . 7 4. Candidate Path Selection . . . . . . . . . . . . . . . . . . 7 5. Distributed and/or Centralized Control Plane . . . . . . . . 11 5.1. Distributed Control Plane within a single Link-State IGP area . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Distributed Control Plane across several Link-State IGP areas . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Centralized Control Plane . . . . . . . . . . . . . . . . 12 5.4. Distributed and Centralized Control Plane . . . . . . . . 12 6. Binding SID Aspects . . . . . . . . . . . . . . . . . . . . . 13 6.1. Benefits of Binding SID . . . . . . . . . . . . . . . . . 13 6.2. Centralized Discovery of available BSID . . . . . . . . . 14 7. Flex-Algorithm Based SR Policies . . . . . . . . . . . . . . 16 8. Layer 2 and Optical Transport . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated with source routing [RFC8402]. Filsfils, et al. Expires April 25, 2022 [Page 2] Internet-Draft SR Policy Considerations October 2021 The headend node steers a flow into a Segment Routing Policy (SR Policy) by augmenting packet headers with the ordered list of segments associated with that SR Policy. [I-D.ietf-spring-segment-routing-policy] defines the SR Policy architecture and details the concepts of SR Policy and steering into an SR Policy. This document describes some of the implementation aspects for SR Policy framework which should be considered as suggestions. The same behavior, as defined in [I-D.ietf-spring-segment-routing-policy], may in fact be realized with other alternate approaches. The deployment aspects described in this document are also meant to only serve as guidelines. This document describes these aspects and other considerations related to SR Policy concepts as they are important to facilitate multi-vendor interoperable deployments for various SR Policy use-cases. These apply equally to the MPLS [RFC8660] and SRv6 [RFC8986] instantiations of segment routing. For reading simplicity, the illustrations are provided for the MPLS instantiation. 2. SR Policy Headend Architecture This section provides a conceptual overview of components (or functions) that interact to implement SR Policy on a headend +--------+ +--------+ | BGP | | PCEP | +--------+ +--------+ \ / +--------+ +----------+ +--------+ | | | SR | | | | CLI |--| Policy |--| NETCONF| | | | | | | +--------+ +----------+ +--------+ | +--------+ | FIB | +--------+ Figure 1: SR Policy Architecture at a Headend The SR Policy functionality at a headend can be implemented in an SR Policy (SRP) process as illustrated in Figure 1 . Filsfils, et al. Expires April 25, 2022 [Page 3] Internet-Draft SR Policy Considerations October 2021 The SRP process interacts with other processes to learn candidate paths. The SRP process selects the active path of an SR Policy. The SRP process interacts with the RIB/FIB process to install an active SR Policy in the dataplane. In order to validate explicit candidate paths and compute dynamic candidate paths, the SRP process maintains an SR Database (SR-DB) as specified in [I-D.ietf-spring-segment-routing-policy]. The SRP process interacts with other processes as shown in Figure 2 to collect the SR-DB information. +--------+ +--------+ +--------+ | BGP SR | | BGP-LS | | IGP | | Policy | +--------+ +--------+ +--------+ \ | / +--------+ +-----------+ +--------+ | PCEP |---| SRP |--| NETCONF| +--------+ +-----------+ +--------+ Figure 2: Topology/link-state database architecture The SR Policy architecture supports both centralized and distributed control-plane. 3. Dynamic Path Computation A dynamic candidate path for SR Policy is specified as an optimization objective and constraints and needs to be computed by either the headend or a Path Computation Element (PCE). The distributed or centralized computation aspect is described further in Section 5. This section describes the computation aspects of a dynamic path. 3.1. Optimization Objective This document describes two optimization objectives: o Min-Metric - requests computation of a solution Segment-List optimized for a selected metric. o Min-Metric with margin and maximum number of SIDs - Min-Metric with two changes: a margin of by which two paths with similar metrics would be considered equal, a constraint on the max number of SIDs in the Segment-List. Filsfils, et al. Expires April 25, 2022 [Page 4] Internet-Draft SR Policy Considerations October 2021 The "Min-Metric" optimization objective requests to compute a solution Segment-List such that packets flowing through the solution Segment-List use ECMP-aware paths optimized for the selected metric. The "Min-Metric" objective can be instantiated for the IGP metric ([RFC1195] [RFC2328] [RFC5340]) xor the TE metric ([RFC5305] [RFC3630]) xor the latency extended TE metric ([RFC8570] [RFC7471]). This metric is called the O metric (the optimized metric) to distinguish it from the IGP metric. The solution Segment-List must be computed to minimize the number of SIDs and the number of Segment- Lists. If the selected O metric is the IGP metric and the headend and tailend are in the same IGP domain, then the solution Segment-List is made of the single prefix-SID of the tailend. When the selected O metric is not the IGP metric, then the solution Segment-List is made of prefix SIDs of intermediate nodes, Adjacency SIDs along intermediate links and potentially Binding SIDs (BSIDs) of intermediate policies. In many deployments there are insignificant metric differences between mostly equal path (e.g. a difference of 100 usec of latency between two paths from NYC to SFO would not matter in most cases). The "Min-Metric with margin" objective supports such requirement. The "Min-Metric with margin and maximum number of SIDs" optimization objective requests to compute a solution Segment-List such that packets flowing through the solution Segment-List do not use a path whose cumulative O metric is larger than the shortest-path O metric + margin. If this is not possible because of the number of SIDs constraint, then one option is that the solution Segment-List minimizes the O metric while meeting the maximum number of SID constraints (i.e. path with the least value of O metric while using <= the number of SIDs specified). The other default option is to not come up with a solution unless the desired SLA is guaranteed. Section 7 describes another approach for computing a solution Segment-List consisting of a single segment when the O metric is not the IGP metric by using the Flex Algorithm Prefix-SID of the tailend. 3.2. Constraints The following constraints can be described: o Inclusion and/or exclusion of TE affinity. Filsfils, et al. Expires April 25, 2022 [Page 5] Internet-Draft SR Policy Considerations October 2021 o Inclusion and/or exclusion of IP address. o Inclusion and/or exclusion of SRLG. o Inclusion and/or exclusion of admin-tag. o Maximum accumulated metric (IGP, TE and latency). o Maximum number of SIDs in the solution Segment-List. o Maximum number of weighted Segment-Lists in the solution set. o Diversity to another service instance (e.g., link, node, or SRLG disjoint paths originating from different head-ends). 3.3. SR Native Algorithm 1----------------2----------------3 |\ / | \ / | 4-------------5-------------7 | \ /| | +-----------6-----------+ | 8------------------------------9 Figure 3: Illustration used to describe SR native algorithm Let us assume that all the links have the same IGP metric of 10 and let us consider the dynamic path defined as: Min-Metric(from 1, to 3, IGP metric, margin 0) with constraint "avoid link 2-to-3". A classical circuit implementation would do: prune the graph, compute the shortest-path, pick a single non-ECMP branch of the ECMP-aware shortest-path and encode it as a Segment-List. The solution Segment- List would be <4, 5, 7, 3>. An SR-native algorithm would find a Segment-List that minimizes the number of SIDs and maximize the use of all the ECMP branches along the ECMP shortest path. In this illustration, the solution Segment- List would be <7, 3>. In the vast majority of SR use-cases, SR-native algorithms should be preferred: they preserve the native ECMP of IP and they minimize the dataplane header overhead. In some specific use-case (e.g. TDM migration over IP where the circuit notion prevails), one may prefer a classic circuit computation followed by an encoding into SIDs (potentially only using Filsfils, et al. Expires April 25, 2022 [Page 6] Internet-Draft SR Policy Considerations October 2021 non-protected Adj SIDs that pin the path to specific links and avoid ECMP to reflect the TDM paradigm). SR-native algorithms are a local node behavior and are thus outside the scope of this document. 3.4. Path to SID Let us assume the below diagram where all the links have an IGP metric of 10 and a TE metric of 10 except the link AB which has an IGP metric of 20 and the link AD which has a TE metric of 100. Let us consider the min-metric(from A, to D, TE metric, margin 0). B---C | | A---D Figure 4: Illustration used to describe path to SID conversion The solution path to this problem is ABCD. This path can be expressed in SIDs as <B, D> where B and D are the IGP prefix SIDs respectively associated with nodes B and D in the diagram. Indeed, from A, the IGP path to B is AB (IGP metric 20 better than ADCB of IGP metric 30). From B, the IGP path to D is BCD (IGP metric 20 better than BAD of IGP metric 30). While the details of the algorithm remain a local node behavior, a high-level description follows: start at the headend and find an IGP prefix SID that leads as far down the desired path as possible(without using any link not included in the desired path). If no prefix SID exists, use the Adj SID to the first neighbor along the path. Restart from the node that was reached. 4. Candidate Path Selection An SR Policy may have multiple candidate paths that are provisioned or signaled [I-D.ietf-idr-segment-routing-te-policy] [RFC8664] from one of more sources. The tie-breaker rules defined in [I-D.ietf-spring-segment-routing-policy] result in determination of a single "active path" in a formal definition. This section describe some examples for the candidate path selection based on the same rules. Filsfils, et al. Expires April 25, 2022 [Page 7] Internet-Draft SR Policy Considerations October 2021 Example 1: Consider headend H where two candidate paths of the same SR Policy <color, endpoint> are signaled via BGP [I-D.ietf-idr-segment-routing-te-policy] and whose respective NLRIs have the same route distinguishers: NLRI A with distinguisher = RD1, color = C, endpoint = N, preference P1. NLRI B with distinguisher = RD1, color = C, endpoint = N, preference P2. o Because the NLRIs are identical (same distinguisher), BGP will perform bestpath selection. Note that there are no changes to BGP best path selection algorithm. o H installs one advertisement as bestpath into the BGP table. o A single advertisement is passed to the SR Policy instantiation process. o The SRP process does not perform any path selection. Note that the candidate path's preference value does not have any effect on the BGP bestpath selection process. Example 2: Consider headend H where two candidate paths of the same SR Policy <color, endpoint> are signaled via BGP and whose respective NLRIs have different route distinguishers: NLRI A with distinguisher = RD1, color = C, endpoint = N, preference P1. NLRI B with distinguisher = RD2, color = C, endpoint = N, preference P2. o Because the NLRIs are different (different distinguisher), BGP will not perform bestpath selection. o H installs both advertisements into the BGP table. o Both advertisements are passed to the SR Policy instantiation process. Filsfils, et al. Expires April 25, 2022 [Page 8] Internet-Draft SR Policy Considerations October 2021 o SRP process at H selects the candidate path advertised by NLRI B as the active path for the SR policy since P2 is greater than P1. Note that the recommended approach is to use NLRIs with different distinguishers when several candidate paths for the same SR Policy (color, endpoint) are signaled via BGP to a headend. Example 3: Consider that a headend H learns two candidate paths of the same SR Policy <color, endpoint> one signaled via BGP and another via Local configuration. NLRI A with distinguisher = RD1, color = C, endpoint = N, preference P1. Local "foo" with color = C, endpoint = N, preference P2. o H installs NLRI A into the BGP table. o NLRI A and "foo" are both passed to the SRP process. o SRP process at H selects the candidate path indicated by "foo" as the active path for the SR policy since P2 is greater than P1. Now, let us consider cases, when an SR Policy has multiple valid candidate paths with the same best preference, the SRP process at a headend uses the rules described in [I-D.ietf-spring-segment-routing-policy] section 2.9 to select the active path. This is explained in the following examples: Example 4: Consider headend H with two candidate paths of the same SR Policy <color, endpoint> and the same preference value received from the same controller R and where RD2 is higher than RD1. o NLRI A with distinguisher RD1, color C, endpoint N, preference P1(selected as active path at time t0). o NLRI B with distinguisher RD2 (RD2 is greater than RD1), color C, endpoint N, preference P1 (passed to SR Policy instantiation process at time t1 > t0). Filsfils, et al. Expires April 25, 2022 [Page 9] Internet-Draft SR Policy Considerations October 2021 After t1, SRP process at H selects candidate path associated with NLRI B as active path of the SR policy since RD2 is higher than RD1. Here the time when the headend receives the candidate path via BGP is not a factor in the selection. Note that, in such a scenario where there are redundant sessions to the same controller, the recommended approach is to use the same RD value for conveying the same candidate paths and let the BGP best path algorithm pick the best path. Example 5: Consider headend H with two candidate paths of the same SR Policy <color, endpoint> and the same preference value both received from the same controller R and where RD2 is higher than RD1. Consider also that headend H is configured to override the discriminator tiebreaker specified in [I-D.ietf-spring-segment-routing-policy] section 2.9 o NLRI A with distinguisher RD1, color C, endpoint N, preference P1 (selected as active path at time t0). o NLRI B with distinguisher RD2, color C, endpoint N, preference P1 (passed to SR Policy instantiation process at time t1). Even after t1, SRP process at H retains candidate path associated with NLRI A as active path of the SR policy since the discriminator tiebreaker is disabled at H. Example 6: Consider headend H with two candidate paths of the same SR Policy <color, endpoint> and the same preference value. o Local "foo" with color C, endpoint N, preference P1 (selected as active path at time t0). o NLRI A with distinguisher RD1, color C, endpoint N, preference P1 (passed to SRP process at time t1). Even after t1, SRP process at H retains candidate path associated with local candidate path "foo" as active path of the SR policy since Filsfils, et al. Expires April 25, 2022 [Page 10] Internet-Draft SR Policy Considerations October 2021 the Local protocol is preferred over BGP by default based on its higher protocol identifier value. Example 7: Consider headend H with two candidate paths of the same SR Policy <color, endpoint> and the same preference value but received via NETCONF from two controllers R and S (where S > R) o Path A from R with distinguisher D1, color C, endpoint N, preference P1 (selected as active path at time t0). o Path B from S with distinguisher D2, color C, endpoint N, preference P1 (passed to SRP process at time t1). Note that the NETCONF process sends both paths to the SRP process since it does not have any tiebreaker logic. After t1, SRP process at H selects candidate path associated with Path B as active path of the SR policy. 5. Distributed and/or Centralized Control Plane 5.1. Distributed Control Plane within a single Link-State IGP area Consider a single-area IGP with per-link latency measurement and advertisement of the measured latency in the extended-TE IGP TLV. A head-end H is configured with a single dynamic candidate path for SR policy P with a low-latency optimization objective and endpoint E. Clearly the SRP process at H learns the topology (and extended TE latency information) from the IGP and computes the solution Segment- List providing the low-latency path to E. No centralized controller is involved in such a deployment. The SR-DB at H only uses the Link-State Database (LSDB) provided by the IGP. 5.2. Distributed Control Plane across several Link-State IGP areas Consider a domain D composed of two link-state IGP single-area instances (I1 and I2) where each sub-domain benefits from per-link latency measurement and advertisement of the measured latency in the related IGP. The link-state information of each IGP is advertised via BGP-LS [RFC7752] towards a set of BGP-LS route reflectors (RR). Filsfils, et al. Expires April 25, 2022 [Page 11] Internet-Draft SR Policy Considerations October 2021 H is a headend in IGP I1 sub-domain and E is an endpoint in IGP I2 sub-domain. Using a BGP-LS session to any BGP-LS RR, H's SRP process may learn the link-state information of the remote domain I2. H can thus compute the low-latency path from H to E as a solution Segment-List that spans the two domains I1 and I2. The SR-DB at H collects the LSDB from both sub-domains (I1 and I2). No centralized controller is required. 5.3. Centralized Control Plane Considering the same domain D as in the previous section, let us now assume that H does not have a BGP-LS session to the BGP-LS RR's. Instead, let us assume a controller "C" has at least one BGP-LS session to the BGP-LS RR's. The controller C learns the topology and extended latency information from both sub-domains via BGP-LS. It computes a low-latency path from H to E as a Segment-List <S1, S2, S3> and programs H with the related explicit candidate path. The headend H does not compute the solution Segment-List (it cannot). The headend only validates the received explicit candidate path. Most probably, the controller encodes the SID's of the Segment-List with Type-1. In that case, The headend's validation simply consists in resolving the first SID on an outgoing interface and next-hop. The SR-DB at H only includes the LSDB provided by the IGP I1. The SR-DB of the controller collects the LSDB from both sub- domains(I1 and I2). 5.4. Distributed and Centralized Control Plane Consider the same domain D as in the previous section. H's SRP process is configured to associate color C1 with a low- latency optimization objective. H's BGP process is configured to steer a Route R/r of extended-color community C1 and of next-hop N via an SR policy (N, C1). Upon receiving a first BGP route of color C1 and of next-hop N, H recognizes the need for an SR Policy (N, C1) with a low-latency Filsfils, et al. Expires April 25, 2022 [Page 12] Internet-Draft SR Policy Considerations October 2021 objective to N. As N is outside the SRTE DB of H, H requests a controller to compute such Segment-List (e.g., PCEP [RFC8664]). This is an example of hybrid control-plane: the BGP distributed control plane signals the routes and their TE requirements. Upon receiving these BGP routes, a local headend either computes the solution Segment-List (entirely distributed when the endpoint is in the SR-DB of the headend) else delegates the computation to a controller (hybrid distributed/centralized control-plane). The SR-DB at H only includes the LSDB provided by the IGP. The SR-DB of the controller collects the LSDB from both sub-domains. 6. Binding SID Aspects The Binding SID (BSID) is fundamental to Segment Routing. It provides scaling, network opacity and service independence. This section describes implementation and operational aspects related to the Binding SID. 6.1. Benefits of Binding SID A simplified illustration is provided on the basis of Figure 5 where it is assumed that S, A, B, Data Center Interconnect DCI1 and DCI2 share the same IGP-SR instance in the data-center 1 (DC1). DCI1, DCI2, C, D, E, F, G, DCI3 and DCI4 share the same IGP-SR domain in the core. DCI3, DCI4, H, K and Z share the same IGP-SR domain in the data-center 2 (DC2). A---DCI1----C----D----E----DCI3---H / | | \ S | | Z \ | | / B---DCI2----F---------G----DCI4---K <==DC1==><=========Core========><==DC2==> Figure 5: A Simple Datacenter Topology In this example, it is assumed no redistribution between the IGP's and no presence of BGP-LU. The inter-domain communication is only provided by SR through SR Policies. Filsfils, et al. Expires April 25, 2022 [Page 13] Internet-Draft SR Policy Considerations October 2021 The latency from S to DCI1 equals to DCI2. The latency from Z to DCI3 equals to DCI4. All the intra-DC links have the same IGP metric 10. The path DCI1, C, D, E, DCI3 has a lower latency and lower capacity than the path DCI2, F, G, DCI4. The IGP metrics of all the core links are set to 10 except the links D-E which is set to 100. A low-latency multi-domain policy from S to Z may be expressed as <DCI1, BSID, Z> where: o DCI1 is the prefix SID of DCI1. o BSID is the Binding SID bound to an SR policy <D, D2E, DCI3> instantiated at DCI1. o Z is the prefix SID of Z. Without the use of an intermediate core SR Policy (efficiently summarized by a single BSID), S would need to steer its low-latency flow into the policy <DCI1, D, D2E, DCI3, Z>. The use of a BSID (and the intermediate bound SR Policy) decreases the number of segments imposed by the source. A BSID acts as a stable anchor point which isolates one domain from the churn of another domain. Upon topology changes within the core of the network, the low-latency path from DCI1 to DCI3 may change. While the path of an intermediate policy changes, its BSID does not change. Hence the policy used by the source does not change, hence the source is shielded from the churn in another domain. A BSID provides opacity and independence between domains. The administrative authority of the core domain may not want to share information about its topology. The use of a BSID allows keeping the service opaque. S is not aware of the details of how the low-latency service is provided by the core domain. S is not aware of the need of the core authority to temporarily change the intermediate path. 6.2. Centralized Discovery of available BSID This section explains how controllers can discover the local SIDs available at a node N so as to pick an explicit BSID for a SR Policy to be instantiated at headend N. Filsfils, et al. Expires April 25, 2022 [Page 14] Internet-Draft SR Policy Considerations October 2021 Any controller can discover the following properties of a node N (e.g., via BGP-LS , NETCONF etc.): o its local topology [RFC7752]. o its topology-related SIDs (Prefix SIDs, Adj SID and EPE SID [RFC9085] [RFC9086]). o its Segment Routing Label Block (SRLB). o its SR Policies and their BSID ([RFC8664] [I-D.ietf-pce-binding-label-sid] [I-D.ietf-idr-te-lsp-distribution]). Any controller can thus infer the available SIDs in the SRLB of any node with the assumption that all SIDs allocated from the SRLB on that node are being advertised by it via some protocols or mechanisms to the controller. As an example, a controller discovers the following characteristics of N: SRLB (4000, 8000), 3 Adj SIDs (4001, 4002, 4003), 2 EPE SIDs (4004, 4005) and 3 SRTE policies (whose BSIDs are respectively 4006, 4007 and 4008). This controller can deduce that the SRLB sub-range (4009, 8000) is free for allocation. A controller is not restricted to use the next numerically available SID in the available SRLB sub-range. It can pick any label in the subset of available labels. This random pick make the chance for a collision unlikely. An operator could also sub-allocate the SRLB between different controllers (e.g. (4000-4499) to controller 1 and (4500-5000) to controller 2). Inter-controller state-synchronization may be used to avoid/detect collision in BSID. All these techniques make the likelihood of a collision between different controllers very unlikely. In the unlikely case of a collision, the controllers will detect it through system alerts, BGP-LS reporting using [I-D.ietf-idr-te-lsp-distribution] or PCEP notification [RFC8231]. They then have the choice to continue the operation of their SR Policy with the dynamically allocated BSID or re-try with another explicit pick. Filsfils, et al. Expires April 25, 2022 [Page 15] Internet-Draft SR Policy Considerations October 2021 Note: in deployments where PCE Protocol (PCEP) is used between head- end and controller (PCE), a head-end can report BSID as well as policy attributes (e.g., type of disjointness) and operational and administrative states to controller. Similarly, a controller can also assign/update the BSID of a policy via PCEP when instantiating or updating SR Policy. 7. Flex-Algorithm Based SR Policies SR allows for association of algorithms to Prefix SIDs [RFC8402]. [I-D.ietf-lsr-flex-algo] defines the IGP based Flex-Algorithm solution which allows IGPs themselves to compute constraint based paths over the network. Prefix SIDs for the specific flex-algorithm and associated with a node are used in the forwarding plane to steer along the specific constraint path to that node. As specified in [RFC8402] these IGP Flex Algo Prefix SIDs can be used as segments within SR Policies thereby leveraging the underlying IGP Flex Algo solution. 1--RED--2-------6 | | | 4-------3--RED--9 Figure 6: Illustration for Flex-Alg SID Now let us assume that o 1, 2, 3 and 4 are part of IGP 1. o 2, 6, 9 and 3 are part of IGP 2. o All the IGP link costs are 10. o Links 1to2 and 3to9 are colored with IGP Link Affinity Red. o Flex-Alg1 is defined in both IGPs as: avoid red, minimize IGP metric. o All nodes of each IGP domain are enabled for FlexAlg1 o SID(k, 0) represents the Prefix SID of node k according to Alg=0. o SID(k, FlexAlg1) represents the Prefix SID of node k according to Flex-Alg1. Filsfils, et al. Expires April 25, 2022 [Page 16] Internet-Draft SR Policy Considerations October 2021 A controller can steer a flow from 1 to 9 through an end-to-end path that avoids the RED links of both IGP domains thanks to the explicit SR Policy <SID(2, FlexAlg1), SID9(FlexAlg1)>. 8. Layer 2 and Optical Transport 1----2----3----4----5 I2(lambda L241)\ / I4(lambda L241) Optical Figure 7: SR Policy with integrated DWDM An explicit candidate path can express a path through a transport layer beneath IP (ATM, FR, DWDM). The transport layer could be ATM, FR, DWDM, back-to-back Ethernet etc. The transport path is modelled as a link between two IP nodes with the specific assumption that no distributed IP routing protocol runs over the link. The link may have IP address or be IP unnumbered. Depending on the transport protocol case, the link can be a physical DWDM interface and a lambda (integrated solution), an Ethernet interface and a VLAN, an ATM interface with a VPI/VCI, a FR interface with a DLCI etc. Using the DWDM integrated use-case of Figure 7 as an illustration, let us assume o nodes 1, 2, 3, 4 and 5 are IP routers running an SR-enable IGP on the links 1-2, 2-3, 3-4 and 4-5. o The SRGB is homogeneous (16000, 24000). o Node K's prefix SID is 16000+K. o node 2 has an integrated DWDM interface I2 with Lambda L1. o node 4 has an integrated DWDM interface I4 with Lambda L2. o the optical network is provisioned with a circuit from 2 to 4 with continuous lambda L241 (details outside the scope of this document). o Node 2 is provisioned with an SR policy with Segment-List <I2(L241)> and Binding SID B where I2(L241) is of type 5 (IPv4) or type 7 (IPv6), see section 4 of [I-D.ietf-spring-segment-routing-policy] . o node 1 steers a packet P1 towards the prefix SID of node 5 (16005). Filsfils, et al. Expires April 25, 2022 [Page 17] Internet-Draft SR Policy Considerations October 2021 o node 1 steers a packet P2 on the SR policy <16002, B, 16005>. In such a case, the journey of P1 will be 1-2-3-4-5 while the journey of P2 will be 1-2-lambda(L241)-4-5. P2 skips the IP hop 3 and leverages the DWDM circuit from node 2 to node 4. P1 follows the shortest-path computed by the distributed routing protocol. The path of P1 is unaltered by the addition, modification or deletion of optical bypass circuits. The salient point of this example is that the SR Policy architecture seamlessly support explicit candidate paths through any transport sub-layer. BGP-LS Extensions to describe the sub-IP-layer characteristics of the SR Policy are out of scope of this document (e.g. in Figure 7, the DWDM characteristics of the SR Policy at node 2 in terms of latency, loss, security, domain/country traversed by the circuit etc.). Further details of the SR Policy use-case for Packet Optical networks are specified in [I-D.anand-spring-poi-sr] . 9. Security Considerations The security considerations related to Segment Routing architecture are described in [RFC8402] and for SR Policy architecture are described in [I-D.ietf-spring-segment-routing-policy] and they apply to this document as well. 10. IANA Considerations This document has no actions for IANA. 11. Acknowledgement The authors like to thank Tarek Saad, Dhanendra Jain, Muhammad Durrani and Rob Shakir for their valuable comments and suggestions. 12. Contributors The following people have contributed to this document: Siva Sivabalan Cisco Systems Email: msiva@cisco.com Zafar Ali Cisco Systems Email: zali@cisco.com Filsfils, et al. Expires April 25, 2022 [Page 18] Internet-Draft SR Policy Considerations October 2021 Jose Liste Cisco Systems Email: jliste@cisco.com Francois Clad Cisco Systems Email: fclad@cisco.com Kamran Raza Cisco Systems Email: skraza@cisco.com Shraddha Hegde Juniper Networks Email: shraddha@juniper.net Steven Lin Google, Inc. Email: stevenlin@google.com Alex Bogdanov Google, Inc. Email: bogdanov@google.com Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca Dirk Steinberg Steinberg Consulting Email: dws@steinbergnet.net Bruno Decraene Orange Business Services Email: bruno.decraene@orange.com Stephane Litkowski Orange Business Services Email: stephane.litkowski@orange.com Luay Jalil Verizon Email: luay.jalil@verizon.com Filsfils, et al. Expires April 25, 2022 [Page 19] Internet-Draft SR Policy Considerations October 2021 13. References 13.1. Normative References [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-13 (work in progress), May 2021. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. 13.2. Informative References [I-D.anand-spring-poi-sr] Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical Integration in Segment Routing", draft-anand-spring-poi- sr-08 (work in progress), July 2019. [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft-ietf-idr-segment-routing- te-policy-13 (work in progress), June 2021. [I-D.ietf-idr-te-lsp-distribution] Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, H., and J. Tantsura, "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", draft-ietf-idr-te- lsp-distribution-15 (work in progress), May 2021. [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-17 (work in progress), July 2021. [I-D.ietf-pce-binding-label-sid] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. L. (editor), "Carrying Binding Label/Segment Identifier in PCE-based Networks.", draft-ietf-pce- binding-label-sid-11 (work in progress), October 2021. Filsfils, et al. Expires April 25, 2022 [Page 20] Internet-Draft SR Policy Considerations October 2021 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>. [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>. [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>. [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>. [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>. Filsfils, et al. Expires April 25, 2022 [Page 21] Internet-Draft SR Policy Considerations October 2021 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>. [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>. [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, August 2021, <https://www.rfc-editor.org/info/rfc9085>. [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 2021, <https://www.rfc-editor.org/info/rfc9086>. Authors' Addresses Clarence Filsfils Cisco Systems, Inc. Pegasus Parc De kleetlaan 6a, DIEGEM BRABANT 1831 BELGIUM Email: cfilsfil@cisco.com Ketan Talaulikar (editor) Cisco Systems, Inc. Email: ketant.ietf@gmail.com Przemyslaw Krol Google, Inc. Email: pkrol@google.com Filsfils, et al. Expires April 25, 2022 [Page 22] Internet-Draft SR Policy Considerations October 2021 Martin Horneffer Deutsche Telekom Email: martin.horneffer@telekom.de Paul Mattes Microsoft One Microsoft Way Redmond, WA 98052-6399 USA Email: pamattes@microsoft.com Filsfils, et al. Expires April 25, 2022 [Page 23]