TEAS Working Group                                                Z. Ali
Internet-Draft                                               C. Filsfils
Intended status: Informational                              P. Camarillo
Expires: March 7, 2023                                     Cisco Systems
                                                                D. Voyer
                                                             Bell Canada
                                                           S. Matsushima
                                                                Softbank
                                                                R. Rokui
                                                                   Ciena
                                                              A. Dhamija
                                                                 Rakuten
                                                           P. Maheshwari
                                                                  Airtel
                                                       September 7, 2022

               Building blocks for Network Slice Realization
                        in Segment Routing Network

             draft-ali-teas-spring-ns-building-blocks-03.txt

   Abstract

   This document describes how to realize the IETF network slice using the
   Segment Routing based technology. It explains how the
   building blocks specified for the Segment Routing can be used for
   this purpose.

   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 March 7, 2023.


   Copyright Notice

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

   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.



                                                                [Page 1]

   Internet-Draft      Network Slice Realization in SR Network


   Table of Contents

      1  Introduction...................................................2
      2  Segment Routing Policy.........................................3
         2.1  Flex-Algorithm Based SR Policies .........................4
         2.2  On-demand SR policy ......................................5
         2.3  Automatic Steering .......................................6
         2.4  Inter-domain Considerations ..............................6
      3  TI-LFA and Microloop Avoidance.................................7
      4  SR VPN.........................................................7
      5  Stateless Service Programming..................................7
      6  Operations, Administration, and Maintenance (OAM)..............8
      7  QoS............................................................8
      8  Stateless Network Slice Identification.........................9
         8.1  Stateless Slice Identification in SRv6....................9
             8.2  Stateless Slice Identification in SR-MPLS................10
      8  IETF Network Slice Controller (NSC)...........................10
      9  Illustration..................................................10
      10   Security Considerations ....................................10
      11   IANA Considerations ........................................11
      12   References .................................................11
         12.1   Normative References ..................................11
      13   Acknowledgments ............................................11
      14   Contributors ...............................................11


   1  Introduction

   As more and more Service Providers and Enterprises operate a
   single network infrastructure to support an ever-increasing
   number of services, the ability to custom fit transport to
   application needs is critically important. This includes
   creating network slices with different characteristics can
   coexist on top of the shared network infrastructure.

   Network Slicing is meant to create (end-to-end) partitioned
   network infrastructure that can be used to provide
   differentiated connectivity behaviors to fulfill the
   requirements of a diverse set of services. Services belonging to
   different Network slices can be wholly disjoint or can share
   different parts of the network infrastructure.

   The definition of network slice for use within the IETF and the
   characteristics of IETF network slice are specified in
   [I-D.ietf-teas-ietf-network-slice-definition].  A framework for
   reusing IETF VPN and traffic-engineering technologies to realize
   IETF network slices is discussed in
   [I-D.ietf-teas-ietf-network-slices].
   These documents also discuss the function of an IETF Network Slice
   Controller and the requirements on its northbound and southbound
   interfaces.

   Segment Routing enables Service Providers to support realization
   of the Network Slicing in IP/MPLS transport network.
   The network as a whole, in a distributed and
   entirely automated manner, can share a single infrastructure
   resource along multiple virtual services (slices). For example,
   one IETF network slice is optimized continuously for low-cost
   transport; a second one is optimized continuously for low-latency
   transport; a third one is orchestrated to support disjoint




   Internet-Draft      Network Slice Realization in SR Network


   services, etc. The optimization objective of each of these
   slices is programmable by the operator.

   The Segment Routing specification already contains the various
   building blocks required to create network slices. This includes
   the following.

     . SR Policy with or without Flexible Algorithm.
     . TI-LFA with O(50 msec) protection in the slice underlay.
     . SR VPN.
     . SR Service Programming (NFV, SFC).
     . Operation, Administration and Management (OAM) and
        Performance Management (PM).
     . QoS using DiffServ.
     . Stateless Network Slice Identification
     . Orchestration at the Controller.

   Each of these building blocks works independently of each other.
   Their functionality can be combined to satisfy service
   provider's requirement for the Network Slicing. An external
   controller plays an important role to orchestrate these building
   blocks into a Slicing service
   (see I-D.ietf-teas-ietf-network-slice-definition]).

   This document elaborates on the attributes of each of these
   building blocks for Network Slicing in IP and/or MPLS underlay
   network. The document also highlights how each IETF network Slice
   can benefit from traffic engineering, network function
   virtualization/ service chaining (service programming),
   OAM, performance management, SDN readiness, O (50 msec)
   TI-LFA protection, etc. features of SR while respecting resource
   partitioning employed over the common networking infrastructure.

   The document equally applicable to the SR-MPLS and SRv6
   instantiations of segment routing.

   The following subsection elaborates on each of these build
   blocks.

   2  Segment Routing Policy

   Segment Routing (SR) allows a headend node to steer a packet
   flow along any path without creating intermediate per-flow
   states [I-D.ietf-spring-segment-routing-policy]. The headend
   node steers a flow into a Segment Routing Policy (SR Policy).
   I.e., the SR Policy can be used to steer traffic along any
   arbitrary path in the network. This allows operators to enforce
   low-latency and / or disjoint paths, regardless of the normal
   forwarding paths.




   Internet-Draft      Network Slice Realization in SR Network


   The SR policy is able to support various optimization objectives
   [I-D.draft-filsfils-spring-sr-policy-considerations]. The
   optimization objectives can be instantiated for the IGP metric
   ([RFC1195] [RFC2328] [RFC5340]) xor the TE metric ([RFC5305],
   [RFC3630]) xor the latency extended TE metric ([RFC7810]
   [RFC7471]). In addition, an SR policy is able to various
   constraints, including inclusion and/or exclusion of TE
   affinity, inclusion and/or exclusion of IP address, inclusion
   and/or exclusion of SRLG, inclusion and/or exclusion of admin-
   tag, maximum accumulated metric (IGP, TE, and latency), maximum
   number of SIDs in the solution SID-List, maximum number of
   weighted SID-Lists in the solution set, diversity to another
   service instance (e.g., link, node, or SRLG disjoint paths
   originating from different head-ends), etc. [I-D.draft-filsfils-
   spring-sr-policy-considerations]. The supports for various
   optimization objectives and constraints enables SR policy to
   create Slices in the network.

   SR policy can be instantiated with or without IGP Flexible
   Algorithm feature. The following subsection describes the SR
   Flexible Algorithm feature and how SR policy can utilize this
   feature.

   2.1 Flex-Algorithm

   Flexible Algorithm enriches the SR Policy solution by adding
   additional segments having different properties than the IGP
   Prefix segments. Flex Algo adds flexible, user-defined segments
   to the SRTE toolbox. Specifically, it allows for association of
   the "intent" to Prefix SIDs. [I-D.ietf-lsr-flex-algo] defines
   the IGP based Flex-Algorithm
   solution which allows IGPs themselves to compute paths
   constraint by the "intent" represented by the Flex-Algorithm.

   The Flex-Algorithm has the following attributes:

     . Algorithm associate to the SID a specific TE intent
        expressed as an optimization objective (an algorithm) [I-
        D.ietf-lsr-flex-algo].
     . Flexibility includes the ability of network operators to
        define the intent of each algorithm they implement.
     . By design the mapping between the Flex-Algorithm and its
        meaning is flexible and is defined by the user.
     . Flexibility also includes ability for operators to make the
        decision to exclude some specific links from the shortest
        path computation, e.g.,



   Internet-Draft      Network Slice Realization in SR Network


          o operator 1 may define Algo 128 to compute the shortest
      path for TE metric and exclude red affinity links.
          o operator 2 may define Algo 128 to compute the shortest
      path for latency metric and exclude blue affinity
      links.

   An IETF Network Slice can be realized by associating of a
   Flexible-Algorithm value with the Slice via IETF network slice
   controller (NSC).

   Flex Alg leverages SR on-demand next hop (ODN) and Automated
   Steering for intent-based instantiation of traffic engineered
   paths described in the following sub-sections. Specifically, as
   specified in [RFC8402] the IGP Flex Algo
   Prefix SIDs can also be used as segments within SR Policies
   thereby leveraging the underlying IGP Flex Algo solution.

   2.2 On-demand SR policy

   Segment Routing On-Demand Next-hop (ODN) functionality enables
   on-demand creation of SR Policies for service traffic. Using a
   Path Computation Element (PCE), end-to-end SR Policy paths can
   be computed to provide end-to-end Segment Routing connectivity,
   even in multi-domain networks running with or without IGP
   Flexible-Algorithm [I-D.draft-ietf-spring-segment-routing-
   policy].

   The On-Demand Next-hop functionality provides optimized service
   paths to meet customer and application SLAs (such as latency,
   disjointness) without any pre-configured TE tunnel and with the
   automatic steering of the service traffic on the SR Policy
   without a static route, autoroute-announce, or policy-based
   routing.

   With this functionality, the IETF Network Slice Controller can
   realize the IETF network slice based on their requirements. The
   head-end router requests the PCE to compute the path for the
   service and then instantiates an SR Policy with the computed
   path and steers the service traffic into that SR Policy. If the
   topology changes, the stateful PCE updates the SR Policy path.
   This happens seamlessly, while TI-LFA protects the traffic in
   case the topology change happened due to a failure.




   Internet-Draft      Network Slice Realization in SR Network


   2.3 Automatic Steering

   Automatically steering traffic into an IETF Network Slice is one of
   the fundamental requirement for Slicing. That is made possible
   by the "Automated Steering" functionality of SR. Specifically,
   SR policy can be used for traffic engineer paths
   within a slice, "automatically steer" traffic to the right slice
   and connect IGP Flex-Algorithm domains sharing the same
   "intent".

   A headend can steer a packet flow into a valid SR Policy within
   a slice in various ways [I-D.draft-ietf-spring-segment-routing-
   policy]:
     . Incoming packets have an active SID matching a local
        Binding SID (BSID) at the headend.
     . Per-destination Steering: incoming packets match a
        BGP/Service route which recurses on an SR policy.
     . Per-flow Steering: incoming packets match or recurse on a
        forwarding array of where some of the entries are SR
        Policies.
     . Policy-based Steering: incoming packets match a routing
        policy which directs them on an SR policy.

   2.4 Inter-domain Considerations

   The network slicing needs to be extended across multiple domains
   such that each domain can satisfy the intent consistently. SR
   has native inter-domain mechanisms, e.g., SR policies are
   designed to span multiple domains using a PCE based solution [I-
   D.ietf-spring-segment-routing], [I-D.ietf-spring-segment-
   routing-central-epe]. An edge router upon service configuration
   automatically requests to the Segment Routing PCE an inter-
   domain path to the remote service endpoint. The path can either
   be for simple best-effort inter-domain reachability or for
   reachability with an SLA contract and can be restricted to a
   Network Slice.

   The SR native mechanisms for inter-domain are easily extendable
   to include the case when different IGP Flex-Algorithm values are
   used to represent the same intent. E.g., in domain1 Service
   Provider 1 (SP1) may use flex-algo 128 to indicate low latency
   Slice and in domain2 Service Provider 2 (SP2) may use flex-algo
   129 to indicate low latency Slice. When an automation system at
   a PE1 in SP1 network configures a service with next hop (PE2) in
   SP2 network, SP1 contacts a Path Computation Element (PCE) to
   find a route to PE2. In the request, the PE1 also indicates the
   intent (i.e., the Flex-Algo 128) in the PCEP message. As the PCE
   has a complete understanding of both Domains, it can understand
   the path computation in Domain1 needs to be performed for
   Algorithm 128 and path computation in Domain2 needs to be



   Internet-Draft      Network Slice Realization in SR Network


   performed for Algorithm 129 (i.e., in the Low Latency Network
   Slice in both domains).

   3  TI-LFA and Microloop Avoidance

   The Segment Routing-based fast-reroute solution, TI-LFA, can
   provide per-destination sub-50msec protection upon any single
   link, node or SRLG failure regardless of the topology. The
   traffic is rerouted straight to the post-convergence path, hence
   avoiding any intermediate flap via an intermediate path. The
   primary and backup path computation is completely automatic by
   the IGP.

   [I-D.draft-bashandy-rtgwg-segment-routing-ti-lfa] proposes a
   Topology Independent Loop-free Alternate Fast Re-route (TI-LFA),
   aimed at protecting node and adjacency segments within O(50
   msec) in the Segment Routing networks. Furthermore, [I-D. draft-
   bashandy-rtgwg-segment-routing-uloop] provides a mechanism
   leveraging Segment Routing to ensure loop-freeness during the
   IGP reconvergence process following a link-state change event.

   As mentioned earlier, Network Slicing in Segment Routing works
   seamlessly with all the other components of the Segment Routing.
   This, of course, includes TI-LFA and microloop avoidance within
   a Slice, with the added benefit that backup path only uses
   resources available to the Slice. For example, when Flexible
   Algorithm is used, the TI-LFA backup path computation is
   performed such that it is optimized per Flexible-Algorithm. The
   backup path shares the same properties are the primary path. The
   backup path does not use a resource outside the Slice of the
   primary path it is protecting.


   4  SR VPN

   Virtual Private Networks (VPNs) provides a mean for creating a
   logically separated network to a different set of users access
   to a common network. Segment Routing is equipped with the rich
   multi-service virtual private network (VPN) capabilities,
   including Layer 3 VPN (L3VPN), Virtual Private Wire Service
   (VPWS), Virtual Private LAN Service (VPLS), and Ethernet VPN
   (EVPN). The ability of Segment Routing to support different VPN
   technologies is one of the fundamental building blocks for
   creating slicing an SR network.





   Internet-Draft      Network Slice Realization in SR Network


   5  Stateless Service Programming

   An important part of an IETF Network Slicing is the orchestration
   of virtualized service containers. [I-D.draft-xuclad-spring-sr-
   service-chaining] describes how to implement service segments
   and achieve stateless service programming in SR-MPLS and SRv6
   networks. It introduces the notion of service segments. The
   ability of encoding the service segments along with the
   topological segment enables service providers to forward packets
   along a specific network path, but also steer them through VNFs
   or physical service appliances available in the network.

   In an SR network, each of the service, running either on a
   physical appliance or in a virtual environment, is associated
   with a segment identifier (SID) for the service.  These service
   SIDs are then leveraged as part of a SID-list to steer packets
   through the corresponding services.  Service SIDs may be
   combined with topological SIDs to achieve service programming
   while steering the traffic through a specific topological path
   in the network. In this fashion, SR provides a fully integrated
   solution for overlay, underlay and service programming building
   blocks needed to satisfy network slicing requirements.


   6  Operations, Administration, and Maintenance (OAM)

   There are various OAM elements that are critical to satisfy
   Network Slicing requirements. These includes but not limited to
   the following:

     . Measuring per-link TE Matric.
     . Flooding per-link TE Matric.
     . Taking TE Matric into account during path calculation.
     . Taking TE Matric bound into account during path calculation.
     . SLA Monitoring: Service Provider can monitor each SR Policy
        in a Slice to Monitor SLA offered by the Policy using
        technique described in [I-D.draft-gandhi-spring-udp-pm].
        This includes monitoring end-to-end delays on all ECMP
        paths of the Policy as well as monitoring traffic loss on a
        Policy. Remedial mechanisms can be used to ensure that the
        SR policy conforms to the SLA contract.


   7  QoS

   Segment Routing relies on MPLS and IP Differentiated Services.
   Differentiated services enhancements are intended to enable
   scalable service discrimination in the Internet without the need
   for per-flow state and signaling at every hop. [RFC2475] defines




   Internet-Draft      Network Slice Realization in SR Network


   an architecture for implementing scalable service
   differentiation in the Internet. This architecture is composed
   of many functional elements implemented in network nodes,
   including a small set of per-hop forwarding behaviors, packet
   classification functions, and traffic conditioning functions
   including metering, marking, shaping, and policing.

   The DiffServ architecture achieves scalability by implementing
   complex classification and conditioning functions only at
   network boundary nodes, and by applying per-hop behaviors to
   aggregates of traffic depending on the traffic marker.
   Specifically, the node at the ingress of the DiffServ domain
   conditions, classifies and marks the traffic into a limited
   number of traffic classes. The function is used to ensure that
   the slice's traffic conforms to the contract associated with the
   slice.

   Per-hop behaviors are defined to permit a reasonably granular
   means of allocating buffer and bandwidth resources at each node
   among competing traffic streams. Specifically, per class
   scheduling and queuing control mechanisms are applied at each IP
   hop to the traffic classes depending on packet's marking.
   Techniques such as queue management and a variety of scheduling
   mechanisms are used to get the required packet behavior to meet
   the slice's SLA.

   8  Stateless Network Slice Identification

   Some use-cases require a slice identifier (SLID) in the packet
   to provide differentiated treatment of the packets belonging
   to different network slices.

   The network slice instantiation using the SLID in the packet
   is required to work with the building blocks described in the
   previous sections. For example, the QoS/ DiffServ needs to be
   observed on a per slice basis. The slice identification needs
   to be topologically independent and stateless.

   8.1  Stateless Slice Identification in SRv6

   [I-D.draft-filsfils-spring-srv6-stateless-slice-id] describes
   a stateless encoding of slice identification in the outer IPv6
   the header of an SRv6 domain. As defined in RFC8754 [RFC8754],
   when an ingress PE receives a packet that traverses the SR domain,
   it encapsulates the packet in an outer IPv6 header and an optional
   SRH. Based on a local policy of the SR domain, the Flow Label field
   of the outer IPv6 header carries the SLID. Specifically, the SLID
   is added in the 8 most significant bits of the Flow Label field
   of the outer IPv6 header.  The remaining 12 bits of the Flow Label
   field are set as described in section 5.5 of [RFC8754] for
   inter-domain packets. Based on the local policy of the SR domain,
   the draft also uses one of the bits in the Traffic Class field of
   the outer IPv6 header to indicate that the entropy label contains
   the SLID.

   The network slicing mechanism described in
   [I-D.draft-filsfils-spring-srv6-stateless-slice-id] works seamlessly
   with the building blocks described in the previous sections. For
   example, the slice identification is independent of topology and
   the network's QoS/DiffServ policy. It enables scalable network
   slicing for SRv6 overlays.

   8.2  Stateless Slice Identification in SR-MPLS

   [I-D.draft-decraene-mpls-slid-encoded-entropy-label-id] describes a
   similar stateless encoding of slice identification in the SR-MPLS domain.
   Specifically, the document extends the use of the Entropy Label to carry
   the SLID. The number of bits to be used for encoding the SLID in the
   Entropy Label is governed by a local policy of the SR domain. Based on
   the local policy of the SR domain, the draft uses one of the bits in the
   TTL field of the Entropy Label to indicate that the Entropy Label contains
   the SLID.

   The network slicing mechanism described in
   [I-D.draft-decraene-mpls-slid-encoded-entropy-label-id] works seamlessly
   with the building blocks described in the previous sections. For
   example, the slice identification is independent of topology and
   the network's QoS/DiffServ policy. It enables scalable network
   slicing for SR-MPLS overlays.





   Internet-Draft      Network Slice Realization in SR Network


   8  IETF Network Slice Controller (NSC)

   The role of IETF Network Slice Controller (NSC) is described in
   I-D.ietf-teas-ietf-network-slice-definition].
   It plays a vital role in realization the IETF network slice
   using the SR building blocks discussed above. The NSC also
   performs admission control and traffic placement for slice
   management at the transport layer.

   The SDN friendliness of the SR technology becomes handy to realize the
   orchestration. The controller may use PCEP or Netconf to interact with
   the routers. The router implements Yang model for SR-based network
   slicing.

   Specification of the controller technology for orchestrating
   Network Slices, services and admission control for the services
   is outside the scope of this draft.

   9  Illustration

   To be added in a later revision.

   10 Security Considerations

   This document does not impose any additional security
   challenges.

   Internet-Draft      Network Slice Realization in SR Network


   11 IANA Considerations

   This document does not define any new protocol or any extension
   to an existing protocol.


   12 References

   12.1 Normative References

      [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119,
                 DOI 10.17487/RFC2119, March 1997,
                 <https://www.rfc-editor.org/info/rfc2119>.

   7.2. Informative References

   [I-D.ietf-teas-ietf-network-slices] Farrel, A., et al,
        "Framework for IETF Network Slices",
        draft-ietf-teas-ietf-network-slices (work in progress)

   [I-D.ietf-teas-ietf-network-slice-definition] Rokui, R. et al,
        "Definition of IETF Network Slices",
        draft-ietf-teas-ietf-network-slice-definition
        (work in progress).

   [I-D.ietf-spring-segment-routing-policy]
         Filsfils, C., Sivabalan, et al, "Segment Routing Policy
         For Traffic Engineering", draft-ietf-spring-segment-
         routing-policy (work in progress).

   [I-D.ietf-lsr-flex-algo] P. Psenak, et al,
         draft-ietf-lsr-flex-algo, work in progress.

   [RFC8402]
         Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
         Litkowski, S., and R. Shakir, "Segment Routing
         Architecture", RFC8402.

   [I-D.draft-filsfils-spring-sr-policy-considerations]
         Filsfils, C., et al. draft-filsfils-spring-sr-policy-
         considerations (work in progress)

   [RFC8754]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-16 (work in
              progress), February 2019.

   [I-D.draft-filsfils-spring-srv6-stateless-slice-id] Filsfils, C., et al.
          draft-filsfils-spring-srv6-stateless-slice-id, work in progress.


   [I-D.draft-decraene-mpls-slid-encoded-entropy-label-id] Decraene B.,
          Filsfils, C., Henderickx W., Saad T., Beeram V.,
          work in progress.

   13 Acknowledgments

   14 Contributors
      Francois Clad
      Cisco Systems, Inc.
      fclad@cisco.com


   Internet-Draft      Network Slice Realization in SR Network

   Authors' Addresses

      Zafar Ali
      Cisco Systems, Inc.
      Email: zali@cisco.com

      Clarence Filsfils
      Cisco Systems, Inc.
      Email: cf@cisco.com

      Pablo Camarillo Garvia
      Cisco Systems, Inc.
      Email: pcamaril@cisco.com

      Daniel Voyer
      Bell Canada
      Email: daniel.voyer@bell.ca

      Satoru Matsushima
      Softbank
      Email: satoru.matsushima@g.softbank.co.jp

      Reza Rokui
      Ciena
      Canada
      Email: rrokui@Ciena.com

      Amit Dhamija
      Rakuten
      Email: amit.dhamija@rakuten.com

      Praveen Maheshwari
      Airtel
      Email: Praveen.Maheshwari@airtel.com