<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.6 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc category="std" docName="draft-dong-idr-flowspec-network-slice-ts-00"
     ipr="trust200902">
  <front>
    <title abbrev="BGP Flowspec for NS-TS">BGP Flowspec for IETF Network Slice
    Traffic Steering</title>

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

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

    <author fullname="Subin Wang" initials="S." surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>
        </postal>

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

    <author fullname="Wenying Jiang" initials="W." surname="Jiang">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>jiangwenying@chinamobile.com</email>
      </address>
    </author>

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

    <workgroup>IDR Working Group</workgroup>

    <abstract>
      <t>BGP Flow Specification (Flowspec) provides a mechanism to distribute
      traffic flow specifications and the forwarding actions to be performed
      to the specific traffic flows. A set of Flowspec components are defined
      to specify the matching criteria that can be applied to the packet, and
      a set of BGP extended communities are defined to encode the actions a
      routing system can take on a packet which matches the flow
      specification.</t>

      <t>An IETF Network Slice enables connectivity between a set of Service
      Demarcation Points (SDPs) with specific Service Level Objectives (SLOs)
      and Service Level Expectations (SLEs) over a common underlay network. To
      meet the connectivity and performance requirement of specific network
      slice services, network slice service traffic needs to be mapped to an
      Network Resource Partition (NRP). The edge nodes of the NRP needs to
      identify the traffic flows which belong to a network slice and steer the
      matched traffic to the corresponding NRP or a specific path within the
      corresponding NRP.</t>

      <t>BGP Flowspec can be used to distribute the matching criteria and the
      forwarding actions to be preformed on specific network slice services.
      The existing Flowspec components can be used for the matching of
      specific network slice services flows at the edge of an NRP. While new
      traffic action needs to be defined for the steering of network slice
      service flows into an NRP. This document defines the extensions to BGP
      Flowspec for IETF network slice traffic steering (NS-TS).</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>BGP Flow Specification (Flowspec) <xref target="RFC8955"/> <xref
      target="RFC8956"/> and BGP Flow Specification Version 2 <xref
      target="I-D.ietf-idr-flowspec-v2"/> provide the BGP based mechanism to
      distribute traffic flow specifications and the forwarding actions to be
      performed to the matched traffic flows. A set of Flowspec components are
      defined to specify the matching criteria that is applied to the packet,
      and a set of Traffic Filtering Action are defined to encode the actions
      a routing system can take on a packet which matches the flow
      specification.</t>

      <t>As described in <xref target="I-D.ietf-teas-ietf-network-slices"/>,
      An IETF Network Slice enables connectivity between a set of Service
      Demarcation Points (SDPs) with specific Service Level Objectives (SLOs)
      and Service Level Expectations (SLEs) over a common underlay network. To
      meet the connectivity and performance requirement of specific network
      slice services, the network slice services need to be mapped to an
      Network Resource Partition (NRP). Each NRP is a collection of resources
      (bufferage, queuing, scheduling, etc.) in the underlay network. The edge
      nodes of the NRP needs to identify the traffic flows which belong a
      network slice and steer the matched traffic to the corresponding NRP or
      a specific path within the corresponding NRP.</t>

      <t>BGP Flowspec can be used to distribute the matching criteria and the
      forwarding actions to be preformed on specific network slice services.
      The existing flowspec filter components defined in BGP Flowpsec can be
      used for the matching of specific network slice services flows. This
      document defines the extensions to BGP Flowspec actions for IETF network
      slice traffic steering (NS-TS).</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="Matching Rules for Network Slice Traffic">
      <t>A set of traffic matching rules can be used as the criteria to match
      the traffic flows of a IETF network slice. The BGP Flowspec components
      as defined in</t>

      <t><xref target="RFC8955"/> <xref target="RFC8956"/> can be used to
      specify the matching rules for network slice service packets. New
      Flowspec components may be defined for the matching of specific types of
      network slice services, which are for further study.</t>
    </section>

    <section title="Network Slice Traffic Steering Actions">
      <t>For packets which match the flow specification of a network slice,
      specific forwarding actions need to be applied to the packet. As the
      network slice is mapped to an NRP in the underlay network, the packet
      will be forwarded in the corresponding NRP using either a shortest path
      or a traffic engineering (TE) path.</t>

      <t>This section describes several actions to be performed on packets
      which match the flow specification of a network slice.</t>

      <section title="Traffic Steering to NRP BE Path">
        <t>Packets of a network slice can be steered into an NRP and forwarded
        to the NRP egress node following the shortest path with the NRP. In
        this case, the identifier of the NRP needs to be carried in the packet
        so that the packet forwarding will be performed using the set of
        resources allocated to the NRP. Depends on the type of the data plane
        NRP specific identifier, there are two options of this traffic
        steering.</t>

        <section title="Redirect to NRP specific Resource-aware Segment">
          <t>When resource-aware SR segments <xref
          target="I-D.ietf-spring-resource-aware-segments"/> are used to
          represent the network resources allocated to an NRP, packets of a
          network slice could be steered into an NRP BE path by encapsulating
          the packets with an resource-aware segment of the egress node in the
          NRP. For SRv6 data plane, this could be achieved using the
          redirect-to-ip action defined in <xref
          target="I-D.ietf-idr-flowspec-redirect-ip"/>. The mechanism for
          SR-MPLS data plane will be specified in a future version.</t>
        </section>

        <section title="Encapsulate-NRP-ID Action">
          <t>When a data plane NRP ID is used to identify the set of network
          resources allocated to an NRP, packets of a network slice could be
          steered into an NRP BE path by encapsulating the packets with an NRP
          ID together with the address of the egress node in the NRP.</t>

          <t>A new BGP extended community is defined for the
          "Encapsulate-NRP-ID" action.</t>

          <t><figure>
              <artwork><![CDATA[    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Sub-Type    |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         NRP ID (4 octets)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 1. The format of Encapsulate-NRP-ID action]]></artwork>
            </figure></t>

          <t>where:</t>

          <t><list style="symbols">
              <t>Type: 0x80. It belongs to the Generic Transitive Extended
              Community Type as defined in <xref target="RFC9184"/>.</t>

              <t>Sub-type: 1 octet to be assigned by IANA.</t>

              <t>Flags: 2-octet flag field. All the flags are unused.</t>

              <t>NRP ID: 4-octet domain significant identifier of an NRP.</t>
            </list></t>

          <t>If a packet matches the flow specification of an IETF network
          slice, and the traffic actions associated with the flow
          specification is the Encapsulate-NRP-ID action, then the packet is
          encapsulated with an NRP ID in the packet header. The
          Encapsulate-NRP-ID action MAY be used together with the
          "Rediect-to-IP" action as defined in <xref
          target="I-D.ietf-idr-flowspec-redirect-ip"/>, in that case the
          destination address of the outer IP header is set to to the IP
          address in the redirect to IP next-hop action. The IPv6
          encapsulation of NRP ID is specified in <xref
          target="I-D.ietf-6man-enhanced-vpn-vtn-id"/>. The encapsulation of
          NRP-ID in other data plane is for further study and out of the scope
          of this document.</t>
        </section>
      </section>

      <section title="Traffic Steering to NRP TE Path">
        <t>Packets of a network slice can be steered into a TE path within the
        corresponding NRP. In an SR network, the network slice traffic can be
        steered into an SR Policy <xref
        target="I-D.ietf-spring-segment-routing-policy"/> which is associated
        with the corresponding NRP.</t>

        <t>In SR networks where the NRP is instantiated using NRP specific
        resource-aware segments <xref
        target="I-D.ietf-spring-resource-aware-segments"/>, the segment list
        of the SR policy are built with resource-aware SR segments which
        represents the subset of network resources allocated to the NRP on
        different network segments. </t>

        <t>In SR networks where the data plane NRP-ID is used to identify the
        set of network resources allocated to the NRP, the mechanism as
        defined in<xref target="I-D.dong-idr-sr-policy-nrp"/> provides the BGP
        SR Policy extensions to associate an SR Policy candidate path with an
        NRP-ID.</t>

        <t>In both the above two cases, the mechanism defined in <xref
        target="I-D.jiang-idr-ts-flowspec-srv6-policy"/> could be used to
        steer traffic to an SR Policy which is associated with an NRP.</t>
      </section>
    </section>

    <section anchor="security-considerations" title="Security Considerations">
      <t>The security considerations of BGP and BGP Flowspec apply to this
      document.</t>
    </section>

    <section anchor="iana-considerations" title="IANA Considerations">
      <t>IANA is requested to assign a new sub-type from "Generic Transitive
      Extended Community Sub-Types" registry.</t>

      <t><figure>
          <artwork align="center"><![CDATA[      Value            Description                Reference
      -----     ---------------------------     -------------
       TBA      Flowspec Encapsulate-NRP-ID     This document
]]></artwork>
        </figure></t>
    </section>

    <section anchor="acknowledgments" title="Acknowledgments">
      <t>The authors would like to thank Haibo Wang and Shunwan Zhuang for the
      review and discussion of this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119"
                 target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement
          Levels</title>

          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>

          <date month="March" year="1997"/>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. This document specifies
            an Internet Best Current Practices for the Internet Community, and
            requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="14"/>

        <seriesInfo name="RFC" value="2119"/>

        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>

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

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

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

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

      <?rfc include='reference.I-D.ietf-idr-flowspec-v2'?>

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

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-6man-enhanced-vpn-vtn-id'?>

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

      <?rfc include='reference.I-D.ietf-idr-flowspec-redirect-ip'?>

      <?rfc include='reference.I-D.ietf-spring-segment-routing-policy'?>

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

      <?rfc include='reference.I-D.dong-idr-sr-policy-nrp'?>

      <?rfc include='reference.I-D.jiang-idr-ts-flowspec-srv6-policy'?>
    </references>
  </back>

  <!---->
</rfc>
