SPRING Working Group                                         C. Filsfils
Internet-Draft                                        K. Talaulikar, Ed.
Intended status: Informational                       Cisco Systems, Inc.
Expires: April 11, 2020                                          P. Krol
                                                            Google, Inc.
                                                            M. Horneffer
                                                        Deutsche Telekom
                                                               P. Mattes
                                                               Microsoft
                                                         October 9, 2019


         SR Policy Implementation and Deployment Considerations
           draft-filsfils-spring-sr-policy-considerations-04

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 11, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Filsfils, et al.         Expires April 11, 2020                 [Page 1]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                 [Page 2]


Internet-Draft          SR Policy Considerations            October 2019


   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
   [I-D.ietf-spring-segment-routing-mpls] and SRv6
   [I-D.filsfils-spring-srv6-network-programming] instantiations of
   segment routing.

   For reading simplicity, the illustrations are provided for the MPLS
   instantiations.

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 11, 2020                 [Page 3]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                 [Page 4]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                 [Page 5]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                 [Page 6]


Internet-Draft          SR Policy Considerations            October 2019


   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]
   [I-D.ietf-pce-segment-routing] 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 11, 2020                 [Page 7]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                 [Page 8]


Internet-Draft          SR Policy Considerations            October 2019


   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 instatiation
      process at time t1 > t0).



Filsfils, et al.         Expires April 11, 2020                 [Page 9]


Internet-Draft          SR Policy Considerations            October 2019


   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 instatiation 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 11, 2020                [Page 10]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                [Page 11]


Internet-Draft          SR Policy Considerations            October 2019


   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
   objective to N.  As N is outside the SRTE DB of H, H requests a



Filsfils, et al.         Expires April 11, 2020                [Page 12]


Internet-Draft          SR Policy Considerations            October 2019


   controller to compute such Segment-List (e.g., PCEP
   [I-D.ietf-pce-segment-routing]).

   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 11, 2020                [Page 13]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                [Page 14]


Internet-Draft          SR Policy Considerations            October 2019


   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
      [I-D.ietf-idr-bgp-ls-segment-routing-ext]
      [I-D.ietf-idr-bgpls-segment-routing-epe]).

   o  its Segment Routing Label Block (SRLB).

   o  its SR Policies and their BSID ([I-D.ietf-pce-segment-routing]
      [I-D.sivabalan-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 11, 2020                [Page 15]


Internet-Draft          SR Policy Considerations            October 2019


   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 PrefixSID of node k according to Alg=0.

   o  SID(k, FlexAlg1) represents the PrefixSID of node k according to
      Flex-Alg1.






Filsfils, et al.         Expires April 11, 2020                [Page 16]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                [Page 17]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                [Page 18]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                [Page 19]


Internet-Draft          SR Policy Considerations            October 2019


13.  References

13.1.  Normative References

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-03 (work in progress), May 2019.

   [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.filsfils-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-filsfils-spring-srv6-network-
              programming-07 (work in progress), February 2019.

   [I-D.ietf-idr-bgp-ls-segment-routing-ext]
              Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,
              and M. Chen, "BGP Link-State extensions for Segment
              Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16
              (work in progress), June 2019.

   [I-D.ietf-idr-bgpls-segment-routing-epe]
              Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
              S., and J. Dong, "BGP-LS extensions for Segment Routing
              BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
              segment-routing-epe-19 (work in progress), May 2019.

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain,
              D., and S. Lin, "Advertising Segment Routing Policies in
              BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in
              progress), July 2019.





Filsfils, et al.         Expires April 11, 2020                [Page 20]


Internet-Draft          SR Policy Considerations            October 2019


   [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-11 (work in progress), May 2019.

   [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-04 (work in progress), September 2019.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "PCEP Extensions for Segment Routing",
              draft-ietf-pce-segment-routing-16 (work in progress),
              March 2019.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-22
              (work in progress), May 2019.

   [I-D.sivabalan-pce-binding-label-sid]
              Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J.,
              Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID
              in PCE-based Networks.", draft-sivabalan-pce-binding-
              label-sid-07 (work in progress), July 2019.

   [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>.






Filsfils, et al.         Expires April 11, 2020                [Page 21]


Internet-Draft          SR Policy Considerations            October 2019


   [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>.

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@cisco.com


   Przemyslaw Krol
   Google, Inc.

   Email: pkrol@google.com




Filsfils, et al.         Expires April 11, 2020                [Page 22]


Internet-Draft          SR Policy Considerations            October 2019


   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 11, 2020                [Page 23]