<?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="info" docName="draft-peng-spring-srv6-compatibility-02"
     ipr="trust200902">
  <front>
    <title abbrev="SRv6 Compatibility">SRv6 Compatibility with Legacy
    Devices</title>

    <author fullname="Hui Tian" initials="H. " surname="Tian">
      <organization>CAICT</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>tianhui@caict.ac.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Feng Zhao" initials="F. " surname="Zhao">
      <organization>CAICT</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhaofeng@caict.ac.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Chongfeng Xie" initials="C." surname="Xie">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>xiechf.bri@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Tong Li" initials="T. " surname="Li">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>litong@chinaunicom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Jichun Ma" initials="J. " surname="Ma">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>majc16@chinaunicom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Shuping Peng" initials="S." surname="Peng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <region/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>pengshuping@huawei.com</email>
      </address>
    </author>

    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>lizhenbin@huawei.com</email>

        <uri/>
      </address>
    </author>


    <author fullname="James N Guichard" initials="J." surname="Guichard">
      <organization>Futurewei Technologies Ltd.</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>jguichar@futurewei.com</email>

        <uri/>
      </address>
    </author>

    <date day="10" month="January" year="2020"/>

    <area>Routing Area</area>

    <workgroup>SPRING Working Group</workgroup>

    <abstract>
      <t>When deploying SRv6 on legacy devices, there are some compatibility
      challenges that must be addressed such as the support for SRH
      processing.</t>

      <t>This document identifies some of the major challenges, and provides
      solutions that can mitigate those challenges and smooth the migration
      towards SRv6 deployment.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Segment Routing (SR) is a source routing paradigm, which allows a
      headend node to steer packets into an SR policy which is instantiated
      through an ordered list of instructions, i.e. segments <xref
      target="RFC8402"/>. A segment can either be topological or service
      based. SR over IPv6 (SRv6) <xref
      target="I-D.ietf-spring-srv6-network-programming"/> is the instantiation
      of SR on the IPv6 data plane with a new type of routing extension
      header, i.e. SR Header (SRH) <xref
      target="I-D.ietf-6man-segment-routing-header"/>. An SRv6 segment, also
      called SRv6 SID, is a 128-bit value, represented as LOC:FUNCT:ARGS (ARGS
      is optional), and is encoded as an IPv6 address. An ordered list of SRv6
      SIDs forms an SR Policy, which can be used for Traffic Engineering (TE),
      Service Function Chaining (SFC), and In-situ Operations, Administration,
      and Maintenance (IOAM). Meanwhile, the deployment of SRv6 will bring
      challenges for legacy devices that do not natively support SRv6.</t>

      <t>This document provides solutions that can mitigate the identified
      compatibility challenges and ease the evolution towards SRv6
      deployment.</t>
    </section>

    <section title="Compatibility Challenges">
      <t>By adopting SR Policy, state in the network devices can be greatly
      reduced, which ultimately evolves the network into a stateless fabric.
      However, it also brings compatibility challenges on the legacy devices.
      In particular, the legacy devices need to upgrade software and/or
      hardware in order to support the processing of SRH.</t>

      <t>Furthermore, as the segments in the segment list increase the SR
      Policy incrementally expands, the encapsulation header overhead
      increases, which imposes high performance requirements on the
      performance of hardware forwarding (i.e. the capability of the
      chipset).</t>

      <t>This section identifies the challenges for legacy devices imposed by
      SRv6 in the following SPRING use cases.</t>

      <section title="Fast Reroute (FRR)">
        <t>FRR is deployed to cope with link or node failures by precomputing
        backup paths. By relying on SR, Topology Independent Loop-free
        Alternate Fast Re-route (TI-LFA) <xref
        target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> provides a local
        repair mechanism with the ability to activate the data plane
        switch-over on to a loop-free backup path irrespective of topologies
        prior and after the failure.</t>

        <t>Using SR, there is no need to create state in the network in order
        to enforce FRR behavior. Correspondingly, the Point of Local Repair,
        i.e. the protecting router, needs to insert a repair list at the head
        of the segment list in the SRH, encoding the explicit post-convergence
        path to the destination. This action will increase the length of the
        segment list in the SRH as shown in Figure 1.</t>
      </section>

      <section title="Traffic Engineering (TE)">
        <t>TE enables network operators to control specific traffic flows
        going through configured explicit paths. There are loose and strict
        options. With the loose option, only a small number of hops along the
        path is explicitly expressed, while the strict option specifies each
        individual hop in the explicit path, e.g. to encode a low latency path
        from one network node to another.</t>

        <t>With SRv6, the strict source-routed explicit paths will result in a
        long segment list in the SRH as shown in Figure 1, which places high
        requirements on the devices.</t>
      </section>

      <section title="Service Function Chaining (SFC)">
        <t>The SR segments can also encode instructions, called service
        segments, for steering packets through services running on physical
        service appliances or virtual network functions (VNF) running in a
        virtual environment <xref
        target="I-D.ietf-spring-sr-service-programming"/>. These service
        segments can also be integrated in an SR policy along with node and
        adjacency segments. This feature of SR will further increase the
        length of the segment list in the SRH as shown in Figure 1.</t>

        <t>In terms of SR awareness, there are two types of services, i.e.
        SR-aware and SR-unaware services, which both impose new requirements
        on the hardware. The SR-aware service needs to be fully capable of
        processing SR traffic, while for the SR-unaware services, an SR proxy
        function needs to be defined.</t>

        <t>If the Network Service Header (NSH) based SFC <xref
        target="RFC8300"/> has already been deployed in the network, the
        compatibility with existing NSH is required.</t>
      </section>

      <section title="IOAM">
        <t>IOAM, i.e. "in-situ" Operations, Administration, and Maintenance
        (OAM), encodes telemetry and operational information within the data
        packets to complement other "out-of-band" OAM mechanisms, e.g. ICMP
        and active probing. The IOAM data fields, i.e. a node data list, hold
        the information collected as the packets traverse the IOAM domain
        <xref target="I-D.ietf-ippm-ioam-data"/>, which is populated
        iteratively starting with the last entry of the list.</t>

        <t>The IOAM data can be embedded into a variety of transports. To
        support the IOAM on the SRv6 data plane, the O-flag in the SRH is
        defined <xref target="I-D.ali-spring-srv6-oam"/>, which implements the
        "punt a timestamped copy and forward" or "forward and punt a
        timestamped copy" behavior. The IOAM data fields, i.e. the node data
        list, are encapsulated in the IOAM TLV in SRH, which further increases
        the length of the SRH as shown in Figure 1.</t>

        <t><figure>
            <artwork><![CDATA[                                                            +-----------+
                                                            |IPv6 packet|
                                                            +-----------+
                                                            /           /
                                             +-----------+  / IOAM Info /
                                             |IPv6 packet|  /           /
                              +-----------+  +-----------+  +-----------+
                              |IPv6 packet|  /           /  /           /
               +-----------+  +-----------+  /           /  /           /
               |IPv6 packet|  /           /  / SF Chain  /  / SF Chain  /
+-----------+  +-----------+  /  TE Path  /  /           /  /           /
|IPv6 packet|  /TI-LFA Path/  /           /  /           /  /           /
+-----------+  +-----------+  +-----------+  +-----------+  +-----------+
|SA,DA      |  |SA,DA      |  |SA,DA      |  |SA,DA      |  |SA,DA      |
+-----------+  +-----------+  +-----------+  +-----------+  +-----------+
   SRv6 BE       SRv6 BE+        SRv6 TE       SRv6 SFC       SRv6 SFC+    
                 TI-LFA                                         IOAM
]]></artwork>
          </figure>Figure 1. Evolution of SRv6 SRH</t>

        <t>Compatibility challenges for legacy devices can be summarized as
        follows:</t>

        <t><list style="symbols">
            <t>Legacy devices need to upgrade software and/or hardware in
            order to support the processing of SRH</t>

            <t>As the SRH expands, the encapsulation overhead increases and
            correspondingly the effective payload decreases</t>

            <t>As the SRH expands, the hardware forwarding performance reduces
            which requires higher capabilities of the chipset</t>
          </list></t>
      </section>
    </section>

    <section title="Solutions">
      <t>This section provides solutions to mitigate the challenges outlined
      in section 2.</t>

      <section title="Traffic Engineering">
        <t>With strict traffic engineering, the resultant long SID list in the
        SRH raises high requirements on the hardware chipset, which can be
        mitigated by the following solutions.</t>

        <section title="Binding SID (BSID)">
          <t>Binding SID <xref target="RFC8402"/> involves a list of SIDs and
          is bound to an SR Policy. The node(s) that imposes the bound policy
          needs to store the SID list. When a node receives a packet with its
          active segment as a BSID, the node will steer the packet in to the
          bound policy accordingly.</t>

          <t>To reduce the long SID list of a strict TE explicit path, BSID
          can be used at selective nodes, maybe according to the processing
          capacity of the hardware chipset. BSID can also be used to impose
          the repair list in the TI-LFA as described in Section 2.1.</t>
        </section>

        <section title="PCEP FlowSpec">
          <t>When the SR architecture adopts a centralized model, the SDN
          controller (e.g. Path Computation Element (PCE)) only needs to apply
          the SR policy at the head-end. There is no state maintained at
          midpoints and tail-ends. Eliminating state in the network (midpoints
          and tail-points) is a key benefit of utilizing SR. However, it also
          leads to a long SID list for expressing a strict TE path.</t>

          <t>PCEP FlowSpec <xref target="I-D.ietf-pce-pcep-flowspec"/>
          provides a trade-off solution. PCEP FlowSpec is able to disseminate
          Flow Specifications (i.e. filters and actions) to indicate how the
          classified traffic flows will be treated. In an SR-enabled network,
          PCEP FlowSpec can be applied at the midpoints to enforce traffic
          engineering policies where it is needed. In that case, state needs
          to be maintained at the corresponding midpoints of a TE explicit
          path, but the SID list can be shortened.</t>
        </section>
      </section>

      <section title="SFC">
        <t>Currently two approaches are proposed to support SFC over SRv6,
        i.e. stateless SFC <xref
        target="I-D.ietf-spring-sr-service-programming"/> and stateful SFC
        <xref target="I-D.ietf-spring-nsh-sr"/>.</t>

        <section title="Stateless SFC">
          <t>A service can also be assigned an SRv6 SID which is integrated
          into an SR policy and used to steer traffic to it. In terms of the
          capability of processing the SR information in the received packets,
          there are two types of services, i.e. SR-aware service and SR-unware
          service. An SR-aware service can process the SRH in the received
          packets. An SR-unaware service, i.e. legacy service, is not able to
          process the SR information in the traffic it receives, and may drop
          the received packets. In order to support such services in an SRv6
          domain, the SR proxy is introduced to handle the processing of SRH
          on behalf of the SR-unware service. The service SID associated with
          the SR-unaware service is instantiated on the SR proxy, which is
          used to steer traffic to the service.</t>

          <t>The SR proxy intercepts the SR traffic destined for the service
          via the locally instantiated service SID, removes the SR
          information, and sends the non-SR traffic out on a given interface
          to the service. When receiving the traffic coming back from the
          service, the SR proxy will restore the SR information and forwards
          it to the next segment in the segment list.</t>
        </section>

        <section title="Stateful SFC">
          <t>The NSH and SR can be integrated in order to support SFC in an
          efficient and cost-effective manner while maintaining separation of
          the service and transport planes.</t>

          <t>In this NSH-SR integration solution, NSH and SR work jointly and
          complement each other. Specifically, SR is responsible for steering
          packets along a given Service Function Path (SFP) while NSH is for
          maintaining the SFC instance context, i.e. Service Path Identifier
          (SPI), Service Index (SI), and any associated metadata.</t>

          <t>When a service chain is established, a packet associated with
          that chain will be first encapsulated with an NSH and then an SRH,
          and forwarded in the SR domain. When the packet arrives at an SFF
          and needs to be forwarded to an SF, the SFF performs a lookup based
          on the service SID associated with the SF to retrieve the next-hop
          context (a MAC address) between the SFF and SF. Then the SFF strips
          the SRH and forwards the packet with NSH carrying metadata to the SF
          where the packet will be processed as specified in <xref
          target="RFC8300"/>. In this case, the SF is not required to be
          capable of the SR operation, neither is the SR proxy. Meanwhile, the
          stripped SRH will be updated and stored in a cache in the SFF,
          indexed by the NSH SPI for the forwarding of the packet coming back
          from the SF.</t>
        </section>
      </section>

      <section title="Light Weight IOAM">
        <t>In most cases, after the IPv6 Destination Address (DA) is updated
        according to the active segment in the SRH, the SID in the SRH will
        not be used again. However, the entire SID list in the SRH will still
        be carried in the packet along the path till a PSP/USP is
        enforced.</t>

        <t>The light weight IOAM method <xref
        target="I-D.li-spring-passive-pm-for-srv6-np"/> makes use of the used
        segments in the SRH to carry the IOAM information, which saves the
        extra space in the SRH and mitigate the requirements on the
        hardware.</t>
      </section>

      <section title="Postcard Telemetry ">
        <t>Existing in-situ OAM techniques incur encapsulation and header
        overhead issues as described in section 2. Postcard-based Telemetry
        with Packet Marking for SRv6 on-path OAM<xref
        target="I-D.song-ippm-postcard-based-telemetry"/>, provides a solution that
        avoids the extra overhead for encapsulating telemetry-related
        instruction and metadata in SRv6 packets.</t>
      </section>
    </section>

    <section title="Summary">
      <t>The SRH enables a great number of features for SRv6 and opens new
      network programming possibilities. By using SRH, it relieves the network
      devices from state, evolving towards stateless fabric, while the
      complexity in the control plane increases. The corresponding challenges
      imposed on the hardware chipset become high as the SRH expands when
      supporting the diverse use cases. The trade-off solutions presented in
      this document can mitigate these challenges and smooth the evolution in
      operators' networks.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>There are no IANA considerations in this document.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section title="Contributors">
      <t><figure>
          <artwork><![CDATA[Hailong Bai
China Unicom
China]]></artwork>
        </figure></t>

      <t><figure>
          <artwork><![CDATA[Ruizhao Hu
Huawei 
China]]></artwork>
        </figure></t>

      <t>Email: huruizhao@huawei.com</t>

      <t><figure>
          <artwork><![CDATA[Jianwei Mao
Huawei 
China]]></artwork>
        </figure></t>

      <t>Email: maojianwei@huawei.com</t>

      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>

      <?rfc include="reference.RFC.8402"?>

      <?rfc include='reference.I-D.ietf-spring-srv6-network-programming'?>

      <?rfc include='reference.I-D.ietf-6man-segment-routing-header'
?>

      <?rfc include='reference.I-D.ietf-spring-sr-service-programming'
?>

      <?rfc include='reference.I-D.ietf-spring-nsh-sr'
?>

      <?rfc include='reference.I-D.ietf-rtgwg-segment-routing-ti-lfa'
?>

      <?rfc include='reference.RFC.8300'
?>

      <?rfc include='reference.I-D.ietf-ippm-ioam-data'
?>

      <?rfc include='reference.I-D.ali-spring-srv6-oam'
?>

      <?rfc include='reference.I-D.ietf-pce-pcep-flowspec'
?>

      <?rfc include='reference.I-D.li-spring-passive-pm-for-srv6-np'
?>

      <?rfc include='reference.I-D.song-ippm-postcard-based-telemetry'
?>

    </references>
  </back>
</rfc>
