[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

TEAS                                                        Shaofu. Peng
Internet-Draft                                                 Ran. Chen
Intended status: Standards Track                         Gregory. Mirsky
Expires: May 7, 2020                                     ZTE Corporation
                                                            Fengwei. Qin
                                                            China Mobile
                                                        November 4, 2019


              Packet Network Slicing using Segment Routing
                   draft-peng-teas-network-slicing-01

Abstract

   This document presents a mechanism aimed at providing a solution for
   network slicing in the transport network for 5G services.  The
   proposed mechanism uses a unified administrative instance identifier
   to distinguish different virtual network resources for both intra-
   domain and inter-domain network slicing scenarios.  Combined with the
   segment routing technology, the mechanism could be used for both
   best-effort and traffic engineered services for tenants.

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

Copyright Notice

   Copyright (c) 2019 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



Peng, et al.               Expires May 7, 2020                  [Page 1]


Internet-Draft       Packet Network Slicing using SR       November 2019


   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.  Network Slicing Requirements  . . . . . . . . . . . . . . . .   3
     2.1.  Dedicated Virtual Networks  . . . . . . . . . . . . . . .   3
     2.2.  End-to-End Slicing  . . . . . . . . . . . . . . . . . . .   3
     2.3.  Unified NSI . . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Traffic Engineering . . . . . . . . . . . . . . . . . . .   4
     2.5.  Summarized Requirements . . . . . . . . . . . . . . . . .   5
   3.  Conventions used in this document . . . . . . . . . . . . . .   5
   4.  Overview of Existing Identifiers  . . . . . . . . . . . . . .   5
     4.1.  AG and EAG Bit  . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Multi-Topology Identifier . . . . . . . . . . . . . . . .   6
     4.3.  SR Policy Color . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Flex-algorithm Identifier . . . . . . . . . . . . . . . .   7
     4.5.  New Slice-based Identifier Introduced . . . . . . . . . .   7
   5.  Overview of AII-based Mechanism . . . . . . . . . . . . . . .   8
   6.  Resource Allocation per AII . . . . . . . . . . . . . . . . .  10
     6.1.  L3 Link Resource AII Configuration  . . . . . . . . . . .  10
     6.2.  L2 Link Resource AII Configuration  . . . . . . . . . . .  11
     6.3.  Node Resource AII Configuration . . . . . . . . . . . . .  11
   7.  Combined with SR Flex-algorithm for Stack Depth Optimization   12
     7.1.  Best-effort Service AII-specific  . . . . . . . . . . . .  12
     7.2.  Traffic Engineering service AII-specific  . . . . . . . .  12
   8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  intra-domain network slicing  . . . . . . . . . . . . . .  13
     8.2.  inter-domain network slicing via BGP-LS . . . . . . . . .  14
     8.3.  inter-domain network slicing via BGP-LU . . . . . . . . .  16
   9.  Implementation suggestions  . . . . . . . . . . . . . . . . .  17
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  18
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   13. Normative references  . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   According to 5G context, network slicing is the collection of a set
   of technologies to create specialized, dedicated logical networks as
   a service (NaaS) in support of network service differentiation and
   meeting the diversified requirements from vertical industries.
   Through the flexible and customized design of functions, isolation



Peng, et al.               Expires May 7, 2020                  [Page 2]


Internet-Draft       Packet Network Slicing using SR       November 2019


   mechanisms, and operation and management (O&M) tools, network slicing
   is capable of providing dedicated virtual networks over a shared
   infrastructure.  A Network Slice Instance (NSI) is the realization of
   network slicing concept.  It is an E2E logical network, which
   comprises of a group of network functions, resources, and connection
   relationships.  An NSI typically covers multiple technical domains,
   which include a terminal, access network (AN), transport network (TN)
   and a core network (CN), as well as a DC domain that hosts third-
   party applications from vertical industries.  Different NSIs may have
   different network functions and resources.  They may also share some
   of the network functions and resources.

   For a transport network, network slicing requires the underlying
   network to support partitioning of the network resources to provide
   the client with dedicated (private) networking, computing, and
   storage resources drawn from a shared pool.  The slices may be seen
   as virtual networks.

2.  Network Slicing Requirements

2.1.  Dedicated Virtual Networks

   An end-to-end virtual network with dedicated resources is the
   advantage of network slicing than traditional DiffServ QoS and VPN.
   For example, DiffServ QoS can distinguish VoIP traffic and other type
   of traffic (such as high-definition video, web browsing), but can not
   distinguish the same type of traffic from different tenants, nor
   isolation of these traffic at all.

   Another example is the IoT traffic of health monitoring network which
   connected hospital and outpatient, it always has strict privacy and
   safety requirements, including where the data can be stored and who
   can access the data, all this can not be satisfied by DiffServ QoS as
   it has not any function of network computing and storage.

   Dedicated VN is a distinct object purchased by a customer, and it
   provides specific function with predictable performance, guaranteed
   level of isolation and safety.  It is not just as QoS.

2.2.  End-to-End Slicing

   Only an end-to-end slice and fine-grained network can match ultra
   delay and safety requirements of special service.  End-to-end means
   that it is constructed with AN-slice, TN-slice, and CN-slice part.

   Although 3GPP technical specifications mainly focus on the operation
   and management of AN-slice and CN-slice, which include some NF
   (network function) components, TN-slice is also created and destroyed



Peng, et al.               Expires May 7, 2020                  [Page 3]


Internet-Draft       Packet Network Slicing using SR       November 2019


   according to the related NSI lifecycle.  In fact, the 3GPP management
   system will request expected link requirements related to the network
   slice (e.g., topology, QOS parameters) with the help of the
   management system that handles the TN part related to the slice.

   For TN part, the link requirements are independent of the existing
   domain partition of the network, i.e., any intra- or inter-domain
   link is the candidate resource for the slice.  It is also independent
   of the existing underlay frame or routing technologies (IGP, BGP,
   Segment Routing, Flex-E, etc.), i.e., any L2 or L3 link is the
   candidate resource.

2.3.  Unified NSI

   An NSI is indentified by S-NSSAI (Single Network Slice Selection
   Assistance Information), which is allocated per PDU session and has
   semantic global within the AN and CN.

   For the purpose of operation and management simplicity, it is also
   better to have a unified identifier with semantic global to
   distinguish different TN-slice during the whole TN.  TN-slice
   identifier has a mapping relation with S-NSSAI, perhaps 1:1 or 1:n.

   Instead, using different slice identifier across multi-domain of TN
   for the specific TN-slice will introduce much and unnecessary
   complexity, especially for case two devices belongs to different
   domain try to exchange slice-based information directly, without the
   help of SDN controller to translate the unified TN-slice identifier
   to an individual domain-wide indentifier.

2.4.  Traffic Engineering

   5G system is expected to be able to provide optimized support for a
   variety of different communication services, different traffic loads,
   and different end-user communities.  For example, the communication
   services using network slicing may include: vehicle-to-everything
   (V2X) services, 5G seamless enhanced Mobile BroadBand (eMBB) service
   with FMC (fixed-mobile convergence), massive IoT connections.  Among
   these service types, high data rates, high traffic densities, low-
   latency, high-reliability are highlighted requirements.

   Traffic engineering mechanism in TN must support the above
   requirements, bandwidth and delay are two primary TE constraints.








Peng, et al.               Expires May 7, 2020                  [Page 4]


Internet-Draft       Packet Network Slicing using SR       November 2019


2.5.  Summarized Requirements

   In summary, the following requirements would be satisfied:

   REQ1: Provide a distinct virtual network, including dedicated
   topology, computation, and storage resource, not only traditional
   QoS;

   REQ2: Unified NSI for easy operation and maintenance;

   REQ3: E2E network slicing, including both intra-domain and inter-
   domain case;

   REQ4: Customization resource for QoS purpose, bandwidth and delay are
   basic constraints;

   REQ5: Layer 2 as well as Layer 3 link resource partition;

3.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119.

4.  Overview of Existing Identifiers

   Currently there are multiple existing mature identifiers that could
   be used to identify the virtual network resource in the transport
   network, such as:

   o  Administrative Group (AG) described in [RFC3630], [RFC5329],
      [RFC5305] and Extended Administrative Groups (EAGs) described in
      [RFC7308]

   o  Multi-Topology Routing (MTR) described in [RFC5120], [RFC4915],
      [RFC5340]

   o  SR policy color described in
      [I-D.ietf-spring-segment-routing-policy]

   o  FA-id described in [I-D.ietf-lsr-flex-algo]

   However, all these identifiers are not sufficient to meet the above
   requirements of TN-slice.  Note that all these identifiers have use
   case of their own, besides the network slicing use case.  Next, we
   will discuss each of them to determine their matching of slicing
   requirements.




Peng, et al.               Expires May 7, 2020                  [Page 5]


Internet-Draft       Packet Network Slicing using SR       November 2019


4.1.  AG and EAG Bit

   AG and EAG are limited to serve as a link color scheme used in TE
   path computation to meet the requirements of TE service for a tenant.
   It is difficult to use them for an NSI allocation mapping (assuming
   that each bit position of AG/EAG represents an NSI).  Hence, they do
   not meet REQ1.  At the same time, AG or EAG cannot be a FIB
   identifier for best-effort service for the same tenant.

   AG and EAG are only as L3 link attribute, not appropriate for
   L2-bundles member, i.e., not meeting REQ5.

   Note that AG and EAG have semantic global, so they meet REQ2,3.

4.2.  Multi-Topology Identifier

   MTR is limited to serve as an IGP logical topology scheme only used
   in the intra-domain scenario.  Thus it is challenging to select
   inter-area link resources based on MT-ID when E2E inter-domain TE
   path needs to be created for a tenant.  That is, it does not meet
   REQ3.

   Different IGP domain within the same TN-slice may be configured with
   different MT-ID.  Thus MT-ID does not meet REQ2.

   MT-ID is only as L3 link attribute, not appropriate for L2-bundles
   member, so it does not meet REQ5.

4.3.  SR Policy Color

   The color of SR policy defines a TE purpose, which includes a set of
   constraints such as bandwidth, delay, TE metric, etc.  Therefore
   color is an abstract target, and it is difficult to get a distinct
   virtual network according to a specific color value.  In most cases,
   only the headend and some other border nodes need to maintain the
   color template, and a color-based virtual network is hard to present
   because of too few participants and lack of interaction scheme.  That
   is, the color does not meet REQ1.

   We can continue to define TE affinity information in color-template,
   but that is only appropriate for L3 link, not for L2-bundles member,
   so the color does not meet REQ5.

   Note that the color has global semantic, so it meets REQ3.







Peng, et al.               Expires May 7, 2020                  [Page 6]


Internet-Draft       Packet Network Slicing using SR       November 2019


4.4.  Flex-algorithm Identifier

   Indeed, FA-id is a short mapping of SR policy color, and it may
   inherit the matched-degree of the Policy Color.  However, FA-id has
   its own characteristics.  A specific FA-id can have more distributed
   participants and define explicit link resource so that an explicit FA
   plane can be created.  Unfortunately, different best-effort and TE
   service of the same slice-tenant will define different constraints,
   resulting in the need to occupy more FA-id resources for one slice-
   tenant.  The relationship between FA-id and slice is not clear.  That
   is, FA-id does not meet REQ1.

   On the other hand, FA-id, like MT-ID, is limited to serve as an IGP
   algorithm scheme used in the intra-domain scenario.  It is
   challenging to select inter-area (especially inter-AS) link resources
   according to FA-id when the E2E inter-domain TE path needs to be
   created for the tenant.  So, FA-id does not meet REQ3.

   Different IGP domain within the same TN-slice may configure different
   FA-ids, so it does not meet REQ2.

   What is more important, tha the path in FA plane identified by FA-id
   is MP2P LSP, so it is hard to define bandwidth reservation for
   service.  So, FA-id does not meet REQ4.

   The link include/exclude rules defined by FA-id is only appropriate
   for the L3 link, not for L2-bundles member, so FA-id does not meet
   REQ5.

4.5.  New Slice-based Identifier Introduced

   Thus, there needs to introduce a new characteristic of NSI that meets
   the above-listed requirements to isolate underlay resources, and it
   is a slice-based identifier.

   Firstly, it could serve as TE criteria for TE service, this aspect is
   like AG/EAG; and secondly, as a FIB table identifier for best-effort
   service, this aspect is like MT-ID or FA-id.

   This document introduces a new property of NSI called "Administrative
   Instance Identifier" (AII) and corresponding method of how to
   instantiate it in the underlay network to match the above-listed
   requirements.








Peng, et al.               Expires May 7, 2020                  [Page 7]


Internet-Draft       Packet Network Slicing using SR       November 2019


5.  Overview of AII-based Mechanism

   [I-D.ietf-teas-enhanced-vpn] described a framework to create virtual
   networks in a packet network.
   [I-D.ali-spring-network-slicing-building-blocks] described how SR
   policy [I-D.ietf-spring-segment-routing-policy] is competent for
   network slicing.  This document continues to specify the detailed
   mechanism, according to 3GPP network slicing requirements, based on
   SR policy with necessary enhancement to signal association of shared
   resources required to create and manage an NSI and steer the packets
   to the path within the specific NSI.

   SR policy color has semantic global in order to be conveniently
   exchanged between two PE routers.  They configure the same color
   template information for the same color value.  AII also with global
   semantic can be contained in color template to enhance SR policy to
   create a TE path within global TN-slice identified by AII.  Besides
   TE service served by explicit SR policy instance, best-effort service
   is served by AII-specific FIB that is created by default once AII
   configured.

   The following is how AII-based mechanism works:

   At the initial stage, each link in a physical network can be colored
   to conform with network slicing requirements.  As previously
   mentioned, AII can be used to color links to partition underlay
   resources.  Also, we may continue to use AG or EAG to color links for
   traditional TE within a virtual network specified by an AII.  A
   single or multiple AIIs could be configured on each intra-domain or
   inter-domain link regardless of IGP instance configuration.  At the
   minimum, a link always belongs to default AII (the value is 0).  The
   number of AIIs configured on a node's links determines the number of
   virtual networks the node belongs to.

   The extension of the existing IGP-TE mechanisms [RFC3630] and
   [RFC5305] to distribute AII information in an AS as a new TE
   parameter of a link will be defined in another document.

   An SDN controller, using BGP-LS [RFC7752] or another interface, will
   have a distinct view of each virtual network specified by AII.  The
   extension of BGP-LS will also be defined in another document.

   Using the CSPF algorithm, a TE path for any best-effort (BE) or
   traffic-engineered (TE) service can be calculated within a virtual
   network specified by the AII.  The computation criteria could be
   <AII, min igp-metric> or <AII, traditional TE critieria> for the BE
   and TE respectively.  Combined with segment routing, the TE path
   could be represented as:



Peng, et al.               Expires May 7, 2020                  [Page 8]


Internet-Draft       Packet Network Slicing using SR       November 2019


   o  a single node-SID of the destination node, for the best-effort
      service in the domain;

   o  node-SIDs of the border node and the destination node, adjacency-
      SID of inter-domain link, for the inter-domain best-effort
      service;

   o  an explicit adjacency-SID list or compressed with several loose
      node-SID, for P2P traffic engineered service.

   Because packets of the best-effort service could be transported over
   an MP2P LSP without congestion control, SR best-effort FIB for each
   virtual network specified by AII to forward best-effort packets may
   be created in the IGP domain.  Thus, CSPF computation with criteria
   <AII, min igp-metric> is distributed on each node in the IGP domain.
   That is similar to the behavior in [I-D.ietf-lsr-flex-algo], but the
   distributed CSPF computation is triggered by AII.

   To distinguish forwarding behavior of different virtual networks,
   prefix-SID need to be allocated per AII and advertised in the IGP
   domain.

   For inter-domain case, in addition to the destination node-SID,
   several node-SIDs of the domain border node and adjacency-SID of
   inter-domain link are also needed to construct the E2E segment list.
   The segment list could be computed with the help of the SDN
   controller, which needs to take account of AII information during the
   computation.  The head-end of the segment list maintains the
   corresponding SR-TE tunnel or SR policy.

   As same as the prefix-SID, adjacency-SID needs to be allocated per
   AII to distinguish the forwarding behavior of different virtual
   networks.

   For P2P traffic engineering service, especially such as the ulra-
   reliable low-latency communication service, it SHOULD not transfer
   over an MP2P LSP to avoid the risk of traffic congestion.  The
   segment list could consist of pure adjacency-SID per AII specific.
   The head-end of the segment list maintains the corresponding SR-TE
   tunnel or SR policy.

   However, label stack depth of the segment list MAY be optimized at a
   later time based on local policies.

   At this moment, we can steer traffic of overlay service to the above
   SR best-effort FIB, SR-TE tunnel, or SR policy instance for the
   specific virtual network.  The overlay service could specify a color
   for TE purposes.  For example, color 1000 means <AII=10, min igp-



Peng, et al.               Expires May 7, 2020                  [Page 9]


Internet-Draft       Packet Network Slicing using SR       November 2019


   metric> to say "I need best-effort forwarding within AII 10
   resource", color 1001 means <AII=10, delay=10ms, AG=0x1> to say "I
   need traffic engineering forwarding within AII 10 resource, and only
   using link with AG equal to 0x1 to reach guarantee of not exceeding
   10ms delay time".  Service with color 1000 will be steered to an SR
   best-effort FIB entry, or an SR-TE tunnel/policy in case of inter-
   domain.  Service with color 1001 will be steered to an SR-TE tunnel/
   policy.

   Note that there is a simple variants of AII-based slicing scheme for
   initial slicing requirement of service, where the SDN controller in
   management partition the whole E2E network topology to multiple
   strictly isolated VNs identified by AII in local, but let the
   forwarding equipments be totally unware of that.  The overlay service
   is steered to the SR policy whose adjacency-segment list is limited
   within specific VN.  This variants need not introduce any complex
   virtual network technologies to forwarding equipments, however only
   for limited scenes.

6.  Resource Allocation per AII

6.1.  L3 Link Resource AII Configuration

   In IGP domain, each numbered or unnumbered L3 link could be
   configured with AII information and synchronized among IGP neighbors.
   The IGP link-state database will contain L3 links with AII
   information to support TE path computation taking account of AII
   criteria.  For a numbered L3 link, it could be represented as a tuple
   <local node-id, remote node-id, local ip-address, remote ip-address>
   , for unnumbered it could be <local node-id, remote node-id, local
   interface-id, remote interface-id>.  Each L3 link could be configured
   to belong to a single AII or multiple AIIs.  Note that an L3 link
   always belongs to default AII(0).

   For different <L3 link, AII> tuple it would allocate a different
   adjacency-SID, as well as advertising with different resource portion
   such as bandwidth occupied.

   Note that AII is independent of IGP instance.  An L3 link that is not
   part of the IGP domain, such as the special purpose for a static
   route, or an inter-domain link, can also be configured with AII
   information and allocate adjacency-SID per AII as the same as IGP
   links.  BGP-LS could be used to collect link state data with AII
   information to the controller, BGP-LS has already provided a
   mechanism to collect link state data from many source protocols, such
   as IGP, Direct, Static configuration, etc., to cover network slicing
   requirements.




Peng, et al.               Expires May 7, 2020                 [Page 10]


Internet-Draft       Packet Network Slicing using SR       November 2019


6.2.  L2 Link Resource AII Configuration

   [I-D.ietf-isis-l2bundles] described how to encode adjacency-SID for
   each L2 member link of an L3 parent link.  In the network slicing
   scenario, it is beneficial to deploy LAG or another virtual
   aggregation interface between two nodes.  If that, the dedicated link
   resources belong to different virtual networks could be added or
   removed on demand, they are treated as L2 member links of a single L3
   virtual interface.  It is the single L3 virtual interface which needs
   to occupy IP resource and join the IGP instance.  Creating a new
   slice-specific link on demand or removing the old one is likely to
   affect little configurations.

   For network slicing purpose, [I-D.ietf-isis-l2bundles] need to be
   extended to advertise the AII attribute for each L2 member link.  For
   different <L2 link, AII> tuple it would allocate a different
   adjacency-SID, as well as advertising with different resource portion
   such as bandwidth occupied.

   In practice, each L2 member link of an L3 parent link SUGGESTED to be
   configured to belong to a single AII, and different L2 member link
   will have different single AII configuration, with different
   adjacency-SID.  Note that in this case, the L3 parent link belongs to
   default AII(0), but each L2 member link belongs to the specific non-
   default AII.  An L2 member link maybe a Flex-E channel or UDUK tunnel
   created/destroyed on demand.

   In the control plane, routing protocol packets following the L3
   parent link will select the L2 member link with the highest priority.
   At the same time, in the forwarding plane, data packets that belong
   to the specific virtual network will pass along the L2 member link
   with the specific AII value.

   TE path computation based on link-state database need inspect the
   detailed L2 members of an L3 adjacency to select the expected L2 link
   resource.

6.3.  Node Resource AII Configuration

   For topology resource, each node needs to allocate node-SID per AII
   when it joins the related virtual network.  All nodes in the IGP
   domain can run the CSPF algorithm with criteria <AII, min IGP metric>
   to compute best-effort next-hop to any other destination nodes for a
   virtual network AII-specific based on the link-state database that
   containing AII information, so that SR best-effort FIB can be
   constructed for each AII.  Static routes could also be added to the
   AII-specific FIB.




Peng, et al.               Expires May 7, 2020                 [Page 11]


Internet-Draft       Packet Network Slicing using SR       November 2019


   An intra-domain overlay best-effort service belongs to a virtual
   network could be directly matched in the SR best-effort FIB for the
   specific AII.  At the same time, an inter-domain overlay best-effort
   service belongs to a virtual network could be over a segment list
   containing domain border node-SID and destination node-SID which
   could be matched in the SR best-effort FIB for the specific AII.

7.  Combined with SR Flex-algorithm for Stack Depth Optimization

   [I-D.ietf-lsr-flex-algo] introduced a mechanism to do label stack
   depth optimization for an SR policy in IGP domain part.  As the color
   of SR policy defined a TE purpose, traditionally the headend or SDN
   controller will compute an expected TE path to meet that purpose.  It
   is necessary to map a color (32 bits) to an FA-id (8 bits) when SR
   flex-algorithm enabled for an SR policy.  Besides that, it is
   necessary to enable the FA-id on each node that wants to join the
   same FA plane manually.  The FAD could copy the TE constraints (not
   including bandwidth case) contained in the color template.  We need
   to consider the cost of losing the flexibility of color when
   executing the flex-algo optimization, and also consider the gap
   between P2P TE requirements and MP2P SR FA LSP capability, to reach
   the right balance when deciding which SR policy need optimization.

7.1.  Best-effort Service AII-specific

   As described above, for best-effort service we have already
   constructed SR best-effort FIB per AII, that is mostly like Flex-
   algo.  Thus, it is not necessary to map to FA-id again for a color
   template which has defined a best-effort behavior within the
   dedicated AII.  Of course, if someone forced to remap it, there is no
   downside for the operation, the overlay best-effort service (with a
   color which defined specific AII, best-effort requirement, and
   mapping FA-id) in IGP domain will try to recurse over <AII, prefix>
   or <FA-id, prefix> FIB entry.

7.2.  Traffic Engineering service AII-specific

   An SR-TE tunnel/policy that served for traffic engineering service of
   a virtual network specified by an AII was generated and computed
   according to the relevant color template, which contained specific
   AII and some other traditional TE constraints.  If we config mapping
   FA-id under the color template, the SR-TE tunnel/policy instance
   could inherit forwarding information from corresponding SR Flex-Algo
   FIB entry.







Peng, et al.               Expires May 7, 2020                 [Page 12]


Internet-Draft       Packet Network Slicing using SR       November 2019


8.  Examples

   In this section, we will further illustrate the point through some
   examples.  All examples share the same figure below.



                  .-----.                               .-----.
                 (       )                             (       )
             .--(         )--.                     .--(         )--.
        +---+----link A1----+---+             +---+----link A1----+---+
        |PE1|----link A2----|PE2|---link A1---|PE3|----link A2----|PE2|
        |   |----link B1----|   |---link B1---|   |----link B1----|   |
        +---+----link B2----+---+             +---+----link B2----+---+
            (                  )                  (                  )
              '--(  AS1    )--'                    '--(   AS2    )--'
                  (       )                            (       )
                   '-----'                              '-----'

                     Figure 1 Network Slicing via AII

   Suppose that each link belongs to separate virtual network, e.g.,
   link Ax belongs to the virtual network colored by AII A, link Bx
   belongs to the virtual network colored by AII B. link x1 has an IGP
   metric smaller than link x2, but TE metric lager.

   To simplify the use case, each AS just contained a single IGP area.

8.1.  intra-domain network slicing

   From the perspective of node PE1 in AS1, it will calculate best-
   effort forwarding entry for each AII instance (including default AII)
   to destinations in the same IGP area.  For example:

   For <AII=0, destination=ASBR1> entry, forwarding information could be
   ECMP during link A1 and link B1, with destination node-SID 100 for
   <AII=0, destination=ASBR1>.

   For <AII=A, destination=ASBR1> entry, forwarding information could be
   link A1, with destination node-SID 200 for <AII=A,
   destination=ASBR1>.

   For <AII=B, destination=ASBR1> entry, forwarding information could be
   link B1, with destination node-SID 300 for <AII=B,
   destination=ASBR1>.






Peng, et al.               Expires May 7, 2020                 [Page 13]


Internet-Draft       Packet Network Slicing using SR       November 2019


   It could also initiate an SR-TE instance (SR tunnel or SR policy)
   with the particular color template on PE1, PE1 is headend and ASBR1
   is destination node.  For example:

   For SR-TE instance 1 with color template which defined criteria
   including {default AII, min TE metric}, forwarding information could
   be ECMP during two segment list {adjacency-SID 1002 for <AII=0, link
   A2> @PE1} and {adjacency-SID 1004 for <AII=0, link B2> @PE1}.

   For SR-TE instance 2 with the color template which defined criteria
   including {AII=A, min TE metric}, forwarding information could be
   presented as the segment list {adjacency-SID 2002 for <AII=A, link
   A2> @PE1}.

   For SR-TE instance 3 with the color template which defined criteria
   including {AII=B, min TE metric}, forwarding information could be
   presented as the segment list {adjacency-SID 3004 for <AII=B, link
   B2> @PE1}.

   Furthermore, we can use SR Flex-algo to optimize the above SR-TE
   instance.  For example, for SR-TE instance 1, we can define FA-ID 201
   with FAD that contains the same information as the color template, in
   turn, FA-ID 202 for SR-TE instance 2, FA-ID 203 for SR-TE instance 3.
   Note that each FA-ID also needs to be enabled on ASBR1.  So that the
   corresponding SR FA entry could be:

   For <FA-ID=201, destination=ASBR1> entry, forwarding information
   could be ECMP during link A2 and link B2, with destination node-SID
   600 for <FA-ID=201, destination=ASBR1>.

   For <FA-ID=202, destination=ASBR1> entry, forwarding information
   could be link A2, with destination node-SID 700 for <FA-ID=202,
   destination=ASBR1>.

   For <FA-ID=203, destination=ASBR1> entry, forwarding information
   could be link B2, with destination node-SID 800 for <FA-ID=203,
   destination=ASBR1>.

8.2.  inter-domain network slicing via BGP-LS

   [RFC7752] BGP-LS describes the methodology that using BGP protocol to
   transfer the Link-State information that maybe originated from IGP
   instance (for intra-domain topology information) or from local direct
   interface or static configuration(for inter-domain topology
   information).  [I-D.ietf-idr-bgpls-inter-as-topology-ext] also
   describes a method to firstly put inter-domain interconnections to
   IGP instance, then always import data from IGP protocol source to




Peng, et al.               Expires May 7, 2020                 [Page 14]


Internet-Draft       Packet Network Slicing using SR       November 2019


   BGP-LS.  In any case BGP-LS need extend to transfer the Link-State
   data with AII information.

   An E2E inner-AS SR-TE instance with particular color template could
   be initiated on PE1, PE1 is head-end and PE2 is destination node.
   BGP-LS could be used to inform the SDN controller about the underlay
   network topology information including AII attribute.  Thus the
   controller could calculate E2E TE path within the particular virtual
   network.

   o For best-effort service, for example:

   For SR-TE instance 4 with color template which defined criteria
   including {default AII, min IGP metric}, forwarding information could
   be segment list {node-SID 100 for <AII=0, destination=ASBR1> ,
   adjacency-SID 1001 for <AII=0, link A1> @ASBR1, node-SID 400 for
   <AII=0, destination=PE2> }.

   For SR-TE instance 5 with color template which defined criteria
   including {AII=A, min IGP metric}, forwarding information could be
   segment list {node-SID 200 for <AII=A, destination=ASBR1> ,
   adjacency-SID 1001 for <AII=A, link A1> @ASBR1, node-SID 500 for
   <AII=A, destination=PE2> }.

   For SR-TE instance 6 with color template which defined criteria
   including {AII=B, min IGP metric}, forwarding information could be
   segment list {node-SID 300 for <AII=B, destination=ASBR1> ,
   adjacency-SID 1003 for <AII=B, link B1> @ASBR1, node-SID 600 for
   <AII=B, destination=PE2> }.

   o For TE service, for example:

   For SR-TE instance 7 with color template which defined criteria
   including {default AII, min TE metric}, forwarding information could
   be ECMP during two segment list {adjacency-SID 1002 for <AII=0, link
   A2> @PE1, adjacency-SID 1001 for <AII=0, link A1> @ASBR1, adjacency-
   SID 1002 for <AII=0, link A2> @ASBR2} and {adjacency-SID 1004 for
   <AII=0, link B2> @PE1, adjacency-SID 1003 for <AII=0, link B1>
   @ASBR1, adjacency-SID 1004 for <AII=0, link B2> @ASBR2}.

   For SR-TE instance 8 with color template which defined criteria
   including {AII=A, min TE metric}, forwarding information could be
   segment list {adjacency-SID 2002 for <AII=A, link A2> @PE1,
   adjacency-SID 2001 for <AII=A, link A1> @ASBR1, adjacency-SID 2002
   for <AII=A, link A2> @ASBR2}.

   For SR-TE instance 9 with color template which defined criteria
   including {AII=B, min TE metric}, forwarding information could be



Peng, et al.               Expires May 7, 2020                 [Page 15]


Internet-Draft       Packet Network Slicing using SR       November 2019


   segment list {adjacency-SID 3004 for <AII=B, link B2> @PE1,
   adjacency-SID 3003 for <AII=B, link B1> @ASBR1, adjacency-SID 3004
   for <AII=B, link B2> @ASBR2}.

   For TE service, if we use SR Flex-algo to do optimizaztion, the above
   forwarding information of each TE instance could inherit the
   corresponding SR FA entry, it would look like this:

   For SR-TE instance 7, forwarding information could be ECMP during two
   segment list {node-SID 600 for <FA-ID=201, destination=ASBR1> ,
   adjacency-SID 1001 for <AII=0, link A1> @ASBR1, node-SID 600 for <FA-
   ID=201, destination=PE2> } and {adjacency-SID 1004 for <AII=0, link
   B2> @PE1, adjacency-SID 1003 for <AII=0, link B1> @ASBR1, adjacency-
   SID 1004 for <AII=0, link B2> @ASBR2}.

   For SR-TE instance 8 with color template which defined criteria
   including {AII=A, min TE metric}, forwarding information could be
   segment list {node-SID 700 for <FA-ID=202, destination=ASBR1> ,
   adjacency-SID 2001 for <AII=A, link A1> @ASBR1, node-SID 700 for <FA-
   ID=202, destination=PE2> }.

   For SR-TE instance 9 with color template which defined criteria
   including {AII=B, min TE metric}, forwarding information could be
   segment list {node-SID 800 for <FA-ID=203, destination=ASBR1> ,
   adjacency-SID 3003 for <AII=B, link B1> @ASBR1, node-SID 800 for <FA-
   ID=203, destination=PE2> }.

8.3.  inter-domain network slicing via BGP-LU

   In some deployments, operators adopt BGP-LU to build inter-domain
   MPLS LSP, overlay service will be directly over BGP-LU LSP.  If
   overlay service has TE requirements that defined by a color, that
   means that BGP-LU LSP needs to have a sense of color too, i.e., BGP-
   LU label could be allocated per color.  At entry node of each domain,
   BGP-LU LSP generated for specific color will be over intra-domain SR-
   TE or SR Best-effort path generated for that color again.  At exit
   node of each domain, BGP-LU LSP generated for specific color will
   select inter-domain forwarding resource per color.  Especially, an
   ASBR will select slice-specfic inter-AS link according to AII
   information of color template.

   [RFC7911] defined that multiple paths UPDATE message for the same
   destination prefix can be advertised in BGP, each UPDATE can contain
   the Color Extended Community ([I-D.ietf-idr-tunnel-encaps]) with
   different color value.

   In figure 1, PE2 can allocate and advertise six labels for its
   loopback plus color 1, 2, 3, 4, 5, 6 respectively.  Suppose color 1



Peng, et al.               Expires May 7, 2020                 [Page 16]


Internet-Draft       Packet Network Slicing using SR       November 2019


   defines {default AII, min IGP metric}, color 2 defines {AII=A, min
   IGP metric}, color 3 defines {AII=B, min IGP metric}, and color 4
   defines {default AII, min TE metric}, color 5 defines {AII=A, min TE
   metric}, color 6 defines {AII=B, min TE metric}. PE2 will advertise
   these labels to ASBR2 and ASBR2 then continues to allocate six labels
   each for prefix PE2 plus different color.  Other nodes will have the
   same operation.  Ultimately PE1 will maintain six BGP-LU LSP.

   For example, the BGP-LU LSP for color 1 will be over SR best-effort
   FIB entry node-SID 100 for <AII=0, destination=ASBR1> to pass through
   AS1, over adjacency-SID 1001 for <AII=0, link A1>@ASBR1 to pass
   inter-AS, over SR best-effort FIB entry node-SID 400 for <AII=0,
   destination=PE2> to pass through AS2.

   For example, The BGP-LU LSP for color 4 will over SR-TE instance 1
   (see section 6.1), or SR best-effort FIB entry node-SID 600 for <FA-
   id=201, destination=ASBR1> (see section 6.1) to pass through AS1,
   over adjacency-SID 1001 for <AII=0, link A1>@ASBR1 to pass inter-AS,
   over SR-TE instance 1' or corresponding SR FA entry to pass through
   AS2.  Note that ASBR1 need also understand the meaning of a specific
   color and select forwarding resource between two AS.

9.  Implementation suggestions

   As a node often contains control plane and forwarding plane, a
   suggestion is that only default AII specific FTN table, i.e,
   traditional FTN table, need be installed on forwarding plane, so that
   there are not any modification and upgrade requirement for hardware
   and existing MPLS forwarding mechanism.  FTN entry for non-default
   AII instance will only be maintained on the control plane and be used
   for overlay service iteration according to next-hop plus color (color
   will give AII information and mapping FA-id information).  Note that
   ILM entry for all AII need be installed on forwarding plane, that
   does not bring any confusion because of prefix-SID allocation per
   AII.

   SR NHLFE entry and other iteration entry such as <next-hop, color>
   can contain AII information for expected packet scheduling.

   The implementation cost is low by means of existing segment routing
   infrastructure.

10.  IANA Considerations

   TBD.






Peng, et al.               Expires May 7, 2020                 [Page 17]


Internet-Draft       Packet Network Slicing using SR       November 2019


11.  Security Considerations

   TBD.

12.  Acknowledgements

   TBD.

13.  Normative references

   [I-D.ali-spring-network-slicing-building-blocks]
              Ali, Z., Filsfils, C., Camarillo, P., and d.
              daniel.voyer@bell.ca, "Building blocks for Slicing in
              Segment Routing Network", draft-ali-spring-network-
              slicing-building-blocks-01 (work in progress), March 2019.

   [I-D.ietf-idr-bgpls-inter-as-topology-ext]
              Wang, A., Chen, H., Talaulikar, K., Zhuang, S., and S. Ma,
              "BGP-LS Extension for Inter-AS Topology Retrieval", draft-
              ietf-idr-bgpls-inter-as-topology-ext-07 (work in
              progress), September 2019.

   [I-D.ietf-idr-tunnel-encaps]
              Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
              Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-14
              (work in progress), September 2019.

   [I-D.ietf-isis-l2bundles]
              Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
              E. Aries, "Advertising L2 Bundle Member Link Attributes in
              IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
              May 2017.

   [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-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-03 (work in progress),
              May 2019.








Peng, et al.               Expires May 7, 2020                 [Page 18]


Internet-Draft       Packet Network Slicing using SR       November 2019


   [I-D.ietf-teas-enhanced-vpn]
              Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for Enhanced Virtual Private Networks (VPN+)
              Service", draft-ietf-teas-enhanced-vpn-03 (work in
              progress), September 2019.

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

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

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

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

   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
              "Traffic Engineering Extensions to OSPF Version 3",
              RFC 5329, DOI 10.17487/RFC5329, September 2008,
              <https://www.rfc-editor.org/info/rfc5329>.

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

   [RFC7308]  Osborne, E., "Extended Administrative Groups in MPLS
              Traffic Engineering (MPLS-TE)", RFC 7308,
              DOI 10.17487/RFC7308, July 2014,
              <https://www.rfc-editor.org/info/rfc7308>.







Peng, et al.               Expires May 7, 2020                 [Page 19]


Internet-Draft       Packet Network Slicing using SR       November 2019


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

   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <https://www.rfc-editor.org/info/rfc7911>.

Authors' Addresses

   Shaofu Peng
   ZTE Corporation

   Email: peng.shaofu@zte.com.cn


   Ran Chen
   ZTE Corporation

   Email: chen.ran@zte.com.cn


   Gregory Mirsky
   ZTE Corporation

   Email: gregimirsky@gmail.com


   Fengwei Qin
   China Mobile

   Email: qinfengwei@chinamobile.com
















Peng, et al.               Expires May 7, 2020                 [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/