<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-li-spring-sr-e2e-ietf-network-slicing-04"
     ipr="trust200902">
  <front>
    <title abbrev="SR for E2E IETF Network Slicing">Segment Routing for
    End-to-End IETF Network Slicing</title>

    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>lizhenbin@huawei.com</email>
      </address>
    </author>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Ran Pang" initials="R." surname="Pang">
      <organization>China Unicom</organization>

      <address>
        <email>pangran@chinaunicom.cn</email>
      </address>
    </author>

    <author fullname="Yongqing Zhu" initials="Y." surname="Zhu">
      <organization>China Telecom</organization>

      <address>
        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>

    <date day="10" month="July" year="2022"/>

    <abstract>
      <t>IETF network slice can be used to meet the connectivity and
      performance requirement of different services or customers in a shared
      network. An IETF network slice can be realized by mapping a set of
      connectivity constructs to a network resource partition (NRP). In some
      network scenarios, an end-to-end IETF network slice may span multiple
      network domains. Within each domain, traffic of the end-to-end network
      slice service is mapped to a local domain NRP.</t>

      <t>When segment routing (SR) is used to provide multi-domain IETF
      network slices, information of the local domain NRP can be specified
      using special SR binding segments which is called NRP binding segments
      (NRP BSID). Then a multi-domain IETF network slice can be specified
      using a list of NRP BSIDs in the packet, each of which is used by the
      corresponding domain edge nodes to steer the traffic of end-to-end IETF
      network slice into the specific local domain NRP.</t>

      <t>This document describes the functionality of NRP binding segment and
      its instantiation in SR-MPLS and SRv6 data plane.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="I-D.ietf-teas-ietf-network-slices"/> introduces the
      concept and the characteristics of IETF network slice, and describes a
      general framework for IETF network slice management and operation. It
      also introduces the concept Network Resource Partition (NRP), which is a
      collection of resources identified in the underlay network. IETF network
      slice can be realized by mapping a set of connectivity constructs to a
      network resource partition (NRP). <xref
      target="I-D.ietf-teas-enhanced-vpn"/> describes the framework and the
      candidate component technologies for providing enhanced VPN (VPN+)
      services based on VPN and Traffic Engineering (TE) technologies.
      Enhanced VPN (VPN+) can be used for the realization of IETF network
      slices.</t>

      <t><xref target="I-D.dong-teas-nrp-scalability"/> describes the
      scalability considerations in the control plane and data plane of NRP
      and provide the suggestions to improve the scalability of NRP. In the
      data plane, it proposes to carry an NRP-ID in the data packet to
      determine the set of resources reserved for the corresponding NRP. <xref
      target="I-D.ietf-6man-enhanced-vpn-vtn-id"/> describes the mechanism of
      carrying the VTN resource ID (which is equivalant to NRP-ID) of a
      network domain in the IPv6 Hop-by-Hop (HBH) extension header.</t>

      <t>An end-to-end IETF network slice may span multiple network domains.
      Within each domain, traffic of the end-to-end network slice service
      needs to be mapped to a local domain NRP. On the domain edge nodes, the
      NRP in the local domain used for carrying the end-to-end network slice
      needs to be determined. <xref
      target="I-D.li-teas-e2e-ietf-network-slicing"/> describes the framework
      of carrying network slice related identifiers in the data plane, each of
      the network slice related identifiers may have a different network
      scope. It provides an approach of mapping the global NRP-ID to domain
      NRP-IDs at the network domain edge nodes.</t>

      <t>In SR networks, an NRP can be establised and represented using either
      a set of NRP specific resource-aware segments<xref
      target="I-D.ietf-spring-resource-aware-segments"/> <xref
      target="I-D.ietf-spring-sr-for-enhanced-vpn"/>, or an NRP-ID which can
      identify the set of network resources allocated to an NRP.</t>

      <t>When segment routing (SR) is used to provide multi-domain IETF
      network slices, information of the local domain NRP can be specified
      using special SR binding segments called NRP binding segments (NRP
      BSID). Then a multi-domain IETF network slice can be specified using a
      list of NRP BSIDs in the packet, each of which is used by the
      corresponding domain edge nodes to steer the traffic of end-to-end IETF
      network slice into the specific local domain NRP.</t>

      <t>This document describes the functionality of the NRP binding segment
      and its instantiation in SR-MPLS and SRv6 data plane.</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="Segment Routing for IETF E2E Network Slicing">
      <t>With Segment Routing, there are several optional approaches to steer
      the end-to-end network slice traffic into the local domain NRPs.</t>

      <t>The first type of approaches are to use one type of NRP BSID to steer
      traffic to an SR Policy which is associated with a local domain NRP.
      This is called the NRP-TE BSID. There are some variants in terms of the
      detailed behavior:<list style="symbols">
          <t>The first variant is to use one type of NRP BSID to specify the
          mapping of traffic to an SR policy which consists of list of
          resource-aware segments <xref
          target="I-D.ietf-spring-resource-aware-segments"/> associated with a
          local domain NRP.</t>

          <t>The second variant is to use one type of NRP BSID to specify the
          mapping of traffic to an SR policy which is associted with a local
          domain NRP-ID.</t>
        </list></t>

      <t>The second type of approaches are to use one type of NRP BSID to
      steer traffic to follow the shortest path within a local domain NRP.
      This is called the NRP-BE BSID. There are some variants in terms of the
      detailed behavior:</t>

      <t><list style="symbols">
          <t>The first variant is to use one type of NRP BSID to determine a
          local domain NRP-ID, and instruct the domain edge node to
          encapsulate the local domain NRP-ID into the packet.</t>

          <t>The second variant is to use one type of NRP BSID to specify the
          mapping of traffic to a local domain NRP, the local domain NRP-ID is
          specified in some fields of the packet by the ingress node of the
          end-to-end network slice, and is obtained and encapsulated into the
          packet at the domain edge node.</t>
        </list></t>

      <t>The behavior of the first type of NRP BSID is similar to the function
      of the existing SR BSID, the difference is it is associated with a
      particular local domain NRP. The second type of NRP BSID is different
      from the existing SR BSID. The instantiation of the NRP BSIDs in SR-MPLS
      and SRv6 are described in the following sections.</t>
    </section>

    <section title="SRv6 NRP Binding Functions">
      <t><xref target="RFC8986"/> defines the SRv6 Network Programming concept
      and specifies the base set of SRv6 behaviors. The SRv6 End.B6.Encaps
      function is defined to bind to an SRv6 Policy in SRv6 with enapsulation,
      and it can be used for the first variant of the NRP-TE BSID. In this
      case, the SRv6 End.B6 encaps function is used to steer the network slice
      traffic to an SRv6 Policy, which consists of candidate paths built with
      resource-aware SRv6 segment lists that are associated with a local
      domain NRP.</t>

      <t>For other types and variants of NRP binding segments as described in
      section 2, three new SRv6 Binding functions are defined.</t>

      <section title="End.B6NRP.Encaps">
        <t>A new SRv6 function called End.B6NRP.Encaps: Endpoint bound to an
        SRv6 Policy in a NRP with IPv6 NRP-ID encapsulation is defined. This
        is a variation of the End behavior. It instructs the endpoint node to
        determine an SRv6 Policy in a specific NRP of the local domain, and
        encapsulate both the SID list and the NRP-ID specified by the SRv6
        Policy in a new IPv6 header.</t>

        <t>Any SID instance of this behavior is associated with an SR Policy
        B, a NRP-ID V and a source address A.</t>

        <t>When node N receives a packet whose IPv6 DA is S, and S is a local
        End.B6NRP.Encaps SID, N does the following:</t>

        <t><figure>
            <artwork><![CDATA[   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.
   S11.   }
   S12.   Decrement IPv6 Hop Limit by 1
   S13.   Decrement Segments Left by 1
   S14.   Update IPv6 DA with Segment List [Segments Left]
   S15.   Push a new IPv6 header with its own SRH containing B, and 
             set the NRP-ID in the HBH header to V
   S16.   Set the outer IPv6 SA to A
   S17.   Set the outer IPv6 DA to the first SID of B
   S18.   Set the outer Payload Length, Traffic Class, Flow Label,
             Hop Limit, and Next Header fields
   S19.   Submit the packet to the egress IPv6 FIB lookup for
             transmission to the new destination
   S20. }

     | Note: 
     | Comparing with the End.B6.Encaps behavior, the difference is 
     | in step 15, which includes the setting of the NRP-ID in the 
     | IPv6 HBH header
     ]]></artwork>
          </figure></t>
      </section>

      <section title="End.NRP.Encaps">
        <t>A new SRv6 function called End.NRP.Encaps: Endpoint with IPv6 NRP
        encapsulation is defined. This is a variation of the End behavior. It
        instructs the endpoint node to determine the corresponding NRP-ID of
        the local domain based on the mapping relationship between the
        End.NRP.Encaps SID and the NRPs maintained on the endpoint. The NRP-ID
        is encapsulated in the IPv6 HBH header of the outer IPv6 header. </t>

        <t>Any SID instance of this behavior is associated with one NRP-ID V
        and a source address A.</t>

        <t>When node N receives a packet whose IPv6 DA is S, and S is a local
        End.NRP.Encaps SID, N does the following:</t>

        <t><figure>
            <artwork><![CDATA[   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.
   S11.   }
   S12.   Decrement IPv6 Hop Limit by 1
   S13.   Decrement Segments Left by 1
   S14.   Update IPv6 DA with Segment List [Segments Left]
   S15.   Push a new IPv6 header with HBH header, and 
             set the NRP-ID in the VTN option to V 
   S16.   Set the outer IPv6 SA to A
   S17.   Set the outer IPv6 DA to the inner IPv6 DA 
   S18.   Set the outer Payload Length, Traffic Class, Flow Label,
             Hop Limit, and Next Header fields
   S19.   Submit the packet to the egress IPv6 FIB lookup for
             transmission to the new destination
   S20. }

     | Note: 
     | Comparing with the End.B6NRP.Encaps behavior, the difference is 
     | in step 15 to 17, which does not need to include an SRH 
     | in the outer IPv6 header]]></artwork>
          </figure></t>
      </section>

      <section title="End.BNRP.Encaps">
        <t>A new SRv6 function called End.BNRP.Encaps: Endpoint bound to an
        NRP with IPv6 encapsulation is defined. This is a variation of the End
        behavior. For the End.BNRP SID, its corresponding NRP-ID should be
        specified and encapsulated by the ingress node of the multi-domain
        SRv6 Path. It instructs the endpoint node to obtain the corresponding
        NRP-ID from the SRH, and encapsulate it into the IPv6 HBH header of
        the outer IPv6 header. Through the End.BNRP.Encaps, the ingress node
        can flexibly specify the local domain NRP the packet needs to traverse
        in the network.</t>

        <t>Any SID instance of this behavior is associated with one NRP-ID V
        and a source address A.</t>

        <t>There can be several options to carry the local domian NRP-ID
        corresponding to the End.BNRP.Encaps function:</t>

        <t><list style="numbers">
            <t>The NRP-ID is carried in the argument field of the
            End.BNRP.Encaps SID.</t>

            <t>The NRP-ID is carried in the SRH TLV field.</t>

            <t>The NRP-ID is carried in the next SID following the
            End.BNRP.Encaps SID in the SID list.</t>
          </list>Editor's note: In the current version of this document,
        option 1 is preferred, in which the local domain NRP-ID is carried in
        the argument field of the SRv6 SID.</t>

        <t>When an ingress node of an end-to-end SR path encapsulates an
        End.BNRP.Encaps SID into the packet, it SHOULD put the local domain
        NRP-ID which the packet is expected to be steered to in that domain
        into the argument part of the corresponding SID.</t>

        <t>When node N receives a packet whose IPv6 DA is S, and S is a local
        End.BNRP.Encaps SID, N does the following:</t>

        <t><figure>
            <artwork><![CDATA[   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.
   S11.   }
   S12.   Obtain the NRP-ID V from the argument part of the IPv6 DA  
   S13.   Decrement IPv6 Hop Limit by 1
   S14.   Decrement Segments Left by 1
   S15.   Update IPv6 DA with Segment List [Segments Left]
   S16.   Push a new IPv6 header with HBH header, and 
             set the NRP-ID in the VTN option to V 
   S17.   Set the outer IPv6 SA to A
   S18.   Set the outer IPv6 DA to the inner IPv6 DA 
   S19.   Set the outer Payload Length, Traffic Class, Flow Label,
             Hop Limit, and Next Header fields
   S20.   Submit the packet to the egress IPv6 FIB lookup for
             transmission to the new destination
   S21. }

     | Note: 
     | Comparing with the End.NRP.Encaps behavior, the difference is 
     | in the new step 12, which is to obtain the NRP-ID from the 
     | current IPv6 DA.
]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="SR-MPLS NRP BSIDs">
      <t><xref target="I-D.li-mpls-enhanced-vpn-vtn-id"/> describes the
      mechanism of carrying the NRP-ID in the MPLS extension header.</t>

      <t>With SR-MPLS data plane, SR-MPLS BSIDs can be allocated by a domain
      edge node for different NRP binding segment behaviors described in
      section 2.</t>

      <t>For the first type of NRP-TE BSID, an SR-MPLS BSID is bound to an SR
      Policy which consists of the candidate paths built with resource-aware
      segment lists associated with a local domain NRP. When a node receives a
      packet with a locally assigned NRP-TE BSID, it determines the
      corresponding segment list which consists of the resource-aware segments
      of a local domain NRP, and encapsulates the SID list to the MPLS label
      stack.</t>

      <t>For the second type of the NRP-TE BSID, an SR-MPLS BSID is bound to a
      SR Policy associated with a local domain NRP-ID. When a node receives a
      packet with a locally assigned type-2 NRP-TE BSID, it determines the
      corresponding SID list and the local domain NRP-ID, and encapsulate the
      packet with both the SID list and an MPLS VTN extension header which
      carries the local domain NRP-ID. Note this requires to assign a separate
      NRP BSID for each SR policy in the local domain NRPs which the node
      participates in.</t>

      <t>For the first type of the NRP-BE BSID, an SR-MPLS BSID is bound to
      the shortest path in a local domain NRP. When a node receives a packet
      with a locally assigned type-1 NRP-BE BSID, it determines the
      corresponding local NRP-ID based on the mapping relationship between the
      NRP-BE BSID and the NRP-ID, and encapsulates the packet with an MPLS VTN
      extension header which carries the local NRP-ID. Note this requires to
      assign a separate NRP-BE BSID for each local domain NRP.</t>

      <t>For the second type of the NRP-BE BSID, a NRP BSID is bound to the
      shortest path in a local domain NRP, the NRP-ID is specified by the
      ingress node of the multi-domain SR path and is carried in the MPLS VTN
      extension header. When a node receives a packet with a locally assigned
      type-2 NRP-BE BSID, it obtains the corresponding local domain NRP-ID
      from an NRP-ID list in the MPLS VTN extension header, and encapsulate
      the packet with the obtained local domain NRP-ID in the MPLS VTN
      extension header.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Zhibo Hu and Yawei Zhang for their
      review and valuable comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8986'?>

      <?rfc include='reference.I-D.ietf-teas-ietf-network-slices'?>

      <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?>

      <?rfc include='reference.I-D.li-teas-e2e-ietf-network-slicing'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-spring-sr-for-enhanced-vpn'?>

      <?rfc include='reference.I-D.ietf-spring-resource-aware-segments'?>

      <?rfc include='reference.I-D.dong-teas-nrp-scalability'?>

      <?rfc include='reference.I-D.ietf-6man-enhanced-vpn-vtn-id'?>

      <?rfc include='reference.I-D.li-mpls-enhanced-vpn-vtn-id'?>
    </references>
  </back>
</rfc>
