<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?> <!-- use symbolic references tags -->
<?rfc sortrefs="yes"?> <!-- sort the reference entries alphabetically -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?> <!-- control vertical white space -->
<?rfc subcompact="no"?> <!-- keep one blank line between list items -->
<rfc category="info" docName="draft-filsfils-spring-srv6-interop-01" ipr="trust200902">

  <front>

    <title>SRv6 interoperability report</title>

    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street />
          <country>Belgium</country>
        </postal>
        <phone></phone>
        <email>cf@cisco.com</email>
      </address>
    </author>

    <author fullname="Francois Clad" initials="F." surname="Clad" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street />
          <country>France</country>
        </postal>
        <email>fclad@cisco.com</email>
      </address>
    </author>

    <author fullname="Pablo Camarillo Garvia" initials="P." surname="Camarillo" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street />
          <country>Spain</country>
        </postal>
        <email>pcamaril@cisco.com</email>
      </address>
    </author>

    <author fullname="Ahmed AbdelSalam" initials="A." surname="AbdelSalam">
      <organization>Gran Sasso Science Institute</organization>
      <address>
        <postal>
          <street />
          <country>Italy</country>
        </postal>
        <email>ahmed.abdelsalam@gssi.it</email>
      </address>
    </author>

    <author fullname="Stefano Salsano" initials="S." surname="Salsano">
      <organization>Universita di Roma "Tor Vergata"</organization>
      <address>
        <postal>
          <street />
          <country>Italy</country>
        </postal>
        <email>stefano.salsano@uniroma2.it</email>
      </address>
    </author>

    <author fullname="Olivier Bonaventure" initials="O." surname="Bonaventure">
      <organization>Universite catholique de Louvain</organization>
      <address>
        <postal>
          <street />
          <country>Belgium</country>
        </postal>
        <email>olivier.bonaventure@uclouvain.be</email>
      </address>
    </author>

    <author fullname="Jakub Horn" initials="J." surname="Horn">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street />
          <country>USA</country>
        </postal>
        <email>jakuhorn@cisco.com</email>
      </address>
    </author>

    <author fullname="Jose Liste" initials="J." surname="Liste">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street />
          <country>USA</country>
        </postal>
        <email>jliste@cisco.com</email>
      </address>
    </author>

    <date/>

    <area>General</area>
    <workgroup>SPRING</workgroup>

    <keyword>SRv6</keyword>
    <keyword>Segment Routing</keyword>
    <keyword>IPv6 Segment Routing</keyword>

    <abstract>
      <t>Segment Routing (SR) can be applied to the IPv6 data plane by leveraging a new type of routing extension header, called Segment Routing Header (SRH). An SRH contains an ordered list, or sequence, of segments representing topological or service-based instructions, or any combination of those.</t>

      <t>This draft provides an overview of IPv6 Segment Routing (SRv6) implementations and interoperability. It makes an inventory of the various pieces of hardware and software that have been demonstrated to support the processing of an SRH, and details some interoperability scenarios that have been showcased at a public event.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

      <t>Segment Routing (SR), defined in <xref target="RFC8402"/>, allows a node to steer packets through a controlled sequence of instructions, called segments, by prepending an SR header to the packets. The IPv6 instantiation of Segment Routing (SRv6) leverages the Segment Routing Header (SRH), a new type of IPv6 routing extension header defined in <xref target="I-D.ietf-6man-segment-routing-header"/>.</t>

      <t>As described in <xref target="I-D.filsfils-spring-srv6-network-programming"/>, an SRv6 segment is a network instruction composed of a locator and a function that is encoded as an IPv6 address. The segment locator is an IPv6 prefix used by routing devices to steer the packet along the shortest IGP path up to the node that advertises this prefix. Since the active segment is placed in the Destination Address field of the IPv6 header, steering by intermediate devices only involves plain IPv6 forwarding and does not require any SR-specific capability. Once the packet reaches the node indicated by the segment locator, the segment function is identified and the packet is processed accordingly. Although the SR functions are locally defined on each node, a set of general purpose functions have been proposed for standardization in <xref target="I-D.filsfils-spring-srv6-network-programming"/> in order to ease interoperability. This set is further extended with specific purposes functions in <xref target="I-D.ietf-dmm-srv6-mobile-uplane"/> and <xref target="I-D.xuclad-spring-sr-service-programming"/>.</t>
    </section>

    <section title="Routing platforms supporting SRH processing">

      <t>The hardware and software platforms listed below have been demonstrated to support the processing of an SRH as described in <xref target="I-D.ietf-6man-segment-routing-header"/>. This section also indicates the supported SRv6 functions and transit behaviors on open-source software.</t>

      <t>Open-source platforms:
        <list style="symbols">
          <t>Linux kernel<xref target="ref-1"/><xref target="ref-2"/>: End, End.X, End.T, End.DX2, End.DX6, End.DX4, End.DT6, End.B6, End.B6.Encaps, T.Insert, T.Encaps, T.Encaps.L2</t>
          <t>Linux srext module: End, End.X, End.DX2, End.DX6, End.DX4, End.AD, End.AM</t>
          <t>FD.io VPP: End, End.X, End.DX2, End.DX6, End.DX4, End.DT6, End.DT4, End.B6, End.B6.Encaps, End.AS, End.AD, End.AM, T.Insert, T.Encaps, T.Encaps.L2</t>
        </list>
      </t>

      <t>Cisco:
        <list style="symbols">
          <t>Cisco ASR 1000 with IOS XE engineering code</t>
          <t>Cisco ASR 9000 with IOS XR engineering code</t>
          <t>Cisco NCS 5500 with IOS XR engineering code</t>
        </list>
      </t>

      <t>Barefoot Networks:
        <list style="symbols">
          <t>Barefoot Networks Tofino</t>
        </list>
      </t>
    </section>

    <section title="Applications supporting SRH">
      <t>In addition to the aforementioned routing platforms, the following open-source applications have been extended to support the processing of IPv6 packets containing an SRH. For Wireshark, tcpdump, iptables and nftables, these extensions have been included in the mainstream version.
        <list style="symbols">
          <t>Wireshark<xref target="ref-3"/></t>
          <t>tcpdump<xref target="ref-4"/></t>
          <t>iptables<xref target="ref-5"/><xref target="ref-6"/></t>
          <t>nftables<xref target="ref-7"/></t>
          <t>Snort<xref target="ref-8"/></t>
        </list>
      </t>
    </section>

    <section title="Interoperability testing">

      <t>The following interoperability testing scenarios were publicly showcased on August 21-24, 2017 at the SIGCOMM conference.</t>

      <t>Five different implementations of SRv6 behaviors were used for this testing:
        <list style="symbols">
          <t>Software implementation in Linux using the srext kernel module created by University of Rome, Tor Vergata, Italy.</t>
          <t>Software implementation in the FD.io Vector Packet Processor (VPP) virtual router.</t>
          <t>Hardware implementation in Barefoot Networks Tofino NPU using the P4 programming language.</t>
          <t>Hardware implementation in Cisco NCS 5500 router using commercially available NPU.</t>
          <t>Hardware implementation in Cisco ASR 1000 router using custom ASIC.</t>
        </list>
      </t>

      <section title="Testbed configuration">

        <figure anchor="fig-testbed" title="Testbed topology" align="center">
          <artwork align="center"><![CDATA[
+--------+     +---+        +---+        +---+     +--------+
| Site A +-----+ 1 +--------+ 2 +--------+ 3 +-----+ Site B |
+--------+     +-+-+        +---+        +-+-+     +--------+
                 |                         |
                 |     +---+     +---+     |
                 +-----+ 4 +-----+ 5 +-----+
                       +-+-+     +-+-+  
                         |         |
                       +-+-+     +-+-+
                       | 6 |     | 7 |
                       +-+-+     +-+-+
                         |         |
                       +-+-+     +-+-+
                       | 8 |     | 9 |
                       +---+     +---+
          ]]></artwork>
        </figure>

        <t>As shown in the figure above, the testbed consisted of 9 different nodes:
          <list style="symbols">
            <t>Nodes 1 and 3 are Cisco ASR 1000 routers running IOS XE engineering code</t>
            <t>Node 2 is a Cisco ASR 9000 router (realizing IPv6 forwarding only)</t>
            <t>Node 4 is a Barefoot Wedge 100BF router</t>
            <t>Node 5 is a Cisco NCS 5500 router running IOS XR engineering code</t>
            <t>Node 6 is a Linux server running the srext kernel module</t>
            <t>Node 7 is a Linux server running the FD.io VPP</t>
            <t>Node 8 is a Linux container running Snort</t>
            <t>Node 9 is a Linux container running iptables</t>
          </list>
        </t>

        <t>On sites A and B the TRex software is used for traffic generation.</t>

        <t>In addition, after every layer 3 operation in the network, Wireshark traffic analyzer is used to verify proper functionality.</t>
      </section>

      <section title="Scenarios">

        <section title="L3 VPN">

          <t>This scenario covers simple L3 VPN functionality for IPv6 traffic using the SRv6 behaviors T.Encaps and End.DX6 in conjunction with regular IPv6 routing.</t>

          <t>
            <list style="symbols">
              <t>IPv6 traffic is generated in site A and sent towards a destination in site B.</t>
              <t>Node 1 performs the T.Encaps operation on the received traffic. Each packet is encapsulated with an IPv6 header and an SRH containing 1 segment, owned by node 3, then forwarded along the shortest path to 3.</t>
              <t>Node 2 performs standard IPv6 forwarding.</t>
              <t>Node 3 performs the End.DX6 function on the received traffic. Each packet is decapsulated then forwarded on the appropriate interface towards site B.</t>
              <t>Traffic generator in site B captures and verifies the received traffic.</t>
            </list>
          </t>
        </section>

        <section title="L3 VPN with traffic engineering">

          <t>This scenario covers L3 VPN overlay with underlay optimization in a single SRv6 encapsulation (IPv6 header + SRH). It leverages the same T.Encaps and End.DX6 behaviors as the first scenario, combined with the End and End.X functions.</t>

          <t>
            <list style="symbols">
              <t>IPv6 traffic is generated in site A and sent towards a destination in site B.</t>
              <t>Node 1 performs the T.Encaps operation on the received traffic. Each packet is encapsulated with an IPv6 header and an SRH containing 3 segments, respectively owned by nodes 4, 5 and 3. The outer IPv6 Destination Address is set to the first segment and the packets are forwarded accordingly.</t>
              <t>Node 4 performs the End function, forwarding the packets on the shortest paths towards node 5.</t>
              <t>Node 5 performs the End.X function, forwarding the packets on a specific interface towards node 3.</t>
              <t>Node 3 performs the End.DX6, decapsulating and then forwarding each packet on the appropriate interface towards site B.</t>
              <t>Traffic generator in site B captures and verifies the received traffic.</t>
            </list>
          </t>
        </section>

        <section title="L3 VPN with traffic engineering and service chaining">
          <t>This scenario covers L3 VPN overlay with underlay optimization and service chaining. Snort and iptables are SR-unaware services in this situation and accessed via SRv6 dynamic proxy endpoint functions implemented on nodes 6 and 7.</t>

          <t>
            <list style="symbols">
              <t>IPv6 traffic is generated in site A and sent towards a destination in site B.</t>
              <t>Node 1 performs the T.Encaps operation on the received traffic. Each packet is encapsulated with an IPv6 header and an SRH containing 5 segments, respectively owned by nodes 4, 6, 5, 7 and 3. The outer IPv6 Destination Address is set to the first segment and the packets are forwarded accordingly.</t>
              <t>Node 4 performs the End.X function, forwarding the packets on a specific interface towards node 6.</t>
              <t>Node 6 performs the End.AD function, sending the inner IPv6 packet via 8 (Snort) and restoring the encapsulation on the way back.</t>
              <t>Node 5 performs the End function, forwarding the packets on the shortest paths towards node 7.</t>
              <t>Node 7 performs the End.AD function, sending the inner IPv6 packet via 9 (iptables) and restoring the encapsulation on the way back.</t>
              <t>Node 3 performs the End.DX6, decapsulating and then forwarding each packet on the appropriate interface towards site B.</t>
              <t>Traffic generator in site B captures and verifies the received traffic.</t>
            </list>
          </t>
        </section>
      </section>
    </section>

    <section title="Contributors">
      <t>David Lebrun, Prem Jonnalagadda and Milad Sharif substantially contributed to the content of this document.</t>
    </section>

    <section title="Acknowledgements">
      <t>TBD</t>
    </section>

    <section title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section title="Security Considerations">
      <t>This document does not introduce any security consideration.</t>
    </section>

  </middle>
  <back>
    <references title="Informative References">
      <?rfc include="reference.RFC.8402"?>
      <?rfc include="reference.I-D.ietf-6man-segment-routing-header"?>
      <?rfc include="reference.I-D.filsfils-spring-srv6-network-programming"?>
      <?rfc include="reference.I-D.ietf-dmm-srv6-mobile-uplane"?>
      <?rfc include="reference.I-D.xuclad-spring-sr-service-programming"?>

      <reference anchor="ref-1" target="https://doi.org/10.1145/3106328.3106329">
        <front>
          <title>Implementing IPv6 Segment Routing in the Linux Kernel</title>
          <author fullname="David Lebrun and Olivier Bonaventure"><organization/><address/></author>
          <date month="July" year="2017"/>
        </front>
      </reference>

      <reference anchor="ref-2" target="https://inl.info.ucl.ac.be/publications/reaping-benefits-ipv6-segment-routing">
        <front>
          <title>Reaping the Benefits of IPv6 Segment Routing</title>
          <author fullname="David Lebrun"><organization/><address/></author>
          <date month="October" year="2017"/>
        </front>
      </reference>

      <reference anchor="ref-3" target="https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=d6e9665872989c5f343fce47484abe415d77486c">
        <front>
          <title>Add support for Segment Routing (Type 4) Extension Header</title>
          <author fullname="Thibault Gerondal"><organization/><address/></author>
          <date month="June" year="2016"/>
        </front>
      </reference>

      <reference anchor="ref-4" target="https://github.com/the-tcpdump-group/tcpdump/commit/9c33608cb2fb6a64e1b76745efa530a63de08100">
        <front>
          <title>Add support for IPv6 routing header type 4</title>
          <author fullname="Ahmed AbdelSalam"><organization/><address/></author>
          <date month="December" year="2017"/>
        </front>
      </reference>

      <reference anchor="ref-5" target="https://patchwork.ozlabs.org/patch/856578/">
        <front>
          <title>[net-next,v2] netfilter: add segment routing header 'srh' match</title>
          <author fullname="Ahmed AbdelSalam"><organization/><address/></author>
          <date month="January" year="2018"/>
        </front>
      </reference>

      <reference anchor="ref-6" target="https://patchwork.ozlabs.org/patch/859206/">
        <front>
          <title>[iptables,v2] extensions: add support for 'srh' match</title>
          <author fullname="Ahmed AbdelSalam"><organization/><address/></author>
          <date month="January" year="2018"/>
        </front>
      </reference>

      <reference anchor="ref-7" target="http://patchwork.ozlabs.org/patch/879061/">
        <front>
          <title>[nft] nftables: Adding support for segment routing header 'srh'</title>
          <author fullname="Ahmed AbdelSalam"><organization/><address/></author>
          <date month="March" year="2018"/>
        </front>
      </reference>

      <reference anchor="ref-8" target="https://github.com/SRouting/sr-snort">
        <front>
          <title>IPv6 Segment Routing (SRv6) aware snort</title>
          <author fullname="Ahmed AbdelSalam"><organization/><address/></author>
          <date month="March" year="2018"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>

