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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC8754 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml">
<!ENTITY SR_TE_PL PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-spring-segment-routing-policy.xml">
<!ENTITY SR_VPN_BGP PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-bess-srv6-services.xml">
<!ENTITY SR_SFC PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-spring-sr-service-programming.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8200 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8200.xml">
<!ENTITY RFC8986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8986.xml">

]>

<?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, i.e, [RFC2119] instead of [1] -->
<?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 autobreaks="yes"?>
<rfc category="info" docName="draft-filsfils-spring-srv6-net-pgm-illustration-04" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
         or pre5378Trust200902  -->

    <front>

     <!--title abbrev="Abbreviated Title">SRv6 Network Programming</title> -->
     <title>Illustrations for SRv6 Network Programming</title>

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

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

     <author fullname="Zhenbin Li" initials="Z." surname="Li">
        <organization>Huawei Technologies</organization>
        <address>
            <postal>
                <street></street>
                <city></city>
                <region></region>
                <code></code>
                <country>China</country>
            </postal>
            <phone></phone>
            <email>lizhenbin@huawei.com</email>
        </address>
     </author>

     <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
         <organization abbrev="SoftBank">SoftBank</organization>
         <address>
             <postal>
                 <street>1-9-1,Higashi-Shimbashi,Minato-Ku</street>
                 <city>Tokyo  105-7322</city>
                 <region></region>
                 <code></code>
                 <country>Japan</country>
             </postal>
             <phone></phone>
             <email>satoru.matsushima@g.softbank.co.jp</email>
         </address>
     </author>

     <author fullname="Bruno Decraene" initials="B." surname="Decraene">
        <organization>Orange</organization>
        <address>
            <postal>
                <street></street>
                <city></city>
                <region></region>
                <code></code>
                <country>France</country>
            </postal>
            <email>bruno.decraene@orange.com</email>
        </address>
     </author>

     <author fullname="Dirk Steinberg" initials="D." surname="Steinberg">
        <organization>Lapishills Consulting Limited</organization>
        <address>
            <postal>
                <street></street>
                <city></city>
                <region></region>
                <code></code>
                <country>Cyprus</country>
            </postal>
            <email>dirk@lapishills.com</email>
        </address>
     </author>

     <author fullname="David Lebrun" initials="D." surname="Lebrun">
        <organization>Google</organization>
        <address>
            <postal>
                <street></street>
                <city></city>
                <region></region>
                <code></code>
                <country>Belgium</country>
            </postal>
            <email>david.lebrun@uclouvain.be</email>
        </address>
     </author>

     <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
        <organization>Bloomberg LP</organization>
        <address>
            <postal>
                <street></street>
                <city></city>
                <region></region>
                <code></code>
                <country>United States of America</country>
            </postal>
            <email>robert@raszuk.net</email>
        </address>
     </author>     

     <author fullname="John Leddy" initials="J." surname="Leddy">
        <organization>Individual Contributor</organization>
        <address>
            <postal>
                <street></street>
                <city></city>
                <region></region>
                <code></code>
                <country>United States of America</country>
            </postal>
            <email>john@leddy.net</email>
        </address>
     </author>

     <date />

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

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

     <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

        <abstract>
            <t>This document illustrates how <xref target="RFC8986">SRv6 Network Programming</xref> can be used to create interoperable and protected overlays with underlay optimization and service programming.</t>
        </abstract>
        <note 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>
        </note>
    </front>

    <middle>
        <section title="Introduction">
            <t>Segment Routing leverages the source routing paradigm. An ingress node steers a packet through a ordered list of instructions, called segments. Each one of these instructions represents a function to be called at a specific location in the network. A function is locally defined on the node where it is executed and may range from simply moving forward in the segment list to any complex user-defined behavior. The network programming consists in combining segment routing functions, both simple and complex, to achieve a networking objective that goes beyond mere packet routing.</t>
            <t><xref target="RFC8986" /> defines the SRv6 Network Programming concept and the main segment routing behaviors.</t>
            <t>This document illustrates how these concepts can be used to enable the creation of interoperable overlays with underlay optimization and service programming.</t>
            <t>The terminology for this document is defined in <xref target="RFC8986" />.</t>
        </section>

        <section title="Illustration">
            <t>We introduce a simplified SID allocation technique to ease the reading of the text. We document the reference diagram. We then illustrate the network programming concept through different use-cases. These use-cases have been thought to allow straightforward combination between each other.</t>

            <section title="Simplified SID allocation">
                <t>To simplify the illustration, we assume:
                    <list style="symbol">
                        <t>2001:db8::/32 is an IPv6 block allocated by a RIR to the operator</t>
                        <t>2001:db8:0::/48 is dedicated to the internal address space</t>
                        <t>2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space</t>
                        <t>We assume a location expressed in 64 bits and a function expressed in 16 bits</t>
                        <t>Node k has a classic IPv6 loopback address 2001:db8::k/128 which is advertised in the IGP</t>
                        <t>Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs will be explicitly assigned from that block</t>
                        <t>Node k advertises 2001:db8:cccc:k::/64 in its IGP</t>
                        <t>Function :1:: (function 1, for short) represents the End function with PSP support</t>
                        <t>Function :C2:: (function C2, for short) represents the End.X function towards neighbor 2</t>
                    </list></t>
                <t>Each node k has:
                    <list style="symbol">
                        <t>An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an End function with additional support for PSP</t>
                        <t>An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to an End.X function to neighbor J with additional support for PSP</t>
                    </list></t>
            </section>

            <section title="Reference diagram">
                <t>Let us assume the following topology where all the links have IGP metric 10 except the link 3-4 which is 100.</t>
                <t>Nodes A, B and 1 to 8 are considered within the network domain while nodes CE-A, CE-B and CE-C are outside the domain.</t>
                <figure anchor="illustration" title="Reference topology" align="center"><artwork align="center"><![CDATA[
        CE-B
           \
            3------4---5
            |       \ /
            |        6 
            |       / 
    A--1--- 2------7---8--B
      /                 \
   CE-A                 CE-C 
Tenant100            Tenant100 with
                       IPv4 203.0.113.0/24 
                ]]></artwork></figure>
            </section>

            <section title="Basic security">
                <t>Any edge node such as 1 would be configured with an ACL on any of its external interface (e.g. from CE-A) which drops any traffic with SA or DA in 2001:db8:cccc::/48. See SEC-1.</t>
                <t>Any core node such as 6 could be configured with an ACL with the SEC-2 behavior "IF (DA == LocalSID) &amp;&amp; (SA is not in 2001:db8:0::/48 or 2001:db8:cccc::/48) THEN drop".</t>
                <t>SEC-3 protection is a default property of SRv6. A SID must be explicitly instantiated. In our illustration, the only available SIDs are those explicitly instantiated.</t>
            </section>

            <section anchor="illustration_l3vpn" title="SR-L3VPN">
                <t>Let us illustrate the SR-L3VPN use-case applied to IPv4.</t>
                <t>Nodes 1 and 8 are configured with a tenant 100, each respectively connected to CE-A and CE-C.</t>
                <t>Node 8 is configured with a locally instantiated End.DT4 SID 2001:db8:cccc:8:D100:: bound to tenant IPv4 table 100.</t>
                <t>Via BGP signaling or an SDN-based controller, Node 1's tenant-100 IPv4 table is programmed with an IPv4 SR-VPN route 203.0.113.0/24 via SRv6 policy &lt;2001:db8:cccc:8:D100::&gt;.</t>
                <t>When 1 receives a packet P from CE-A destined to 203.0.113.20, 1 looks up 203.0.113.20 in its tenant-100 IPv4 table and finds an SR-VPN entry 203.0.113.0/24 via SRv6 policy &lt;2001:db8:cccc:8:D100::&gt;. As a consequence, 1 pushes an outer IPv6 header with SA=2001:db8::1, DA=2001:db8:cccc:8:D100:: and NH=4. 1 then forwards the resulting packet on the shortest path to 2001:db8:cccc:8::/64.</t>
                <t>When 8 receives the packet, 8 matches the DA in its &quot;My SID Table&quot;, finds the bound function End.DT4(100) and confirms NH=4. As a result, 8 decaps the outer header, looks up the inner IPv4 DA in tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards CE-C.</t>
                <t>The reader can easily infer all the other SR-IPVPN instantiations: </t>
                <figure align="center"><artwork><![CDATA[
+---------------------------------+----------------------------------+
| Route at ingress PE(1)          | SR-VPN Egress SID of egress PE(8)|
+---------------------------------+----------------------------------+
| IPv4 tenant route with egress   | End.DT4 function bound to        |
| tenant table lookup             | IPv4-tenant-100 table            |
+---------------------------------+----------------------------------+
| IPv4 tenant route without egress| End.DX4 function bound to        |
| tenant table lookup             | CE-C (IPv4)                      |
+---------------------------------+----------------------------------+
| IPv6 tenant route with egress   | End.DT6 function bound to        |
| tenant table lookup             | IPv6-tenant-100 table            |
+---------------------------------+----------------------------------+
| IPv6 tenant route without egress| End.DX6 function bound to        |
| tenant table lookup             | CE-C (IPv6)                      |
+---------------------------------+----------------------------------+
                ]]></artwork></figure>
            </section>

            <section title="SR-Ethernet-VPWS">
                <t>Let us illustrate the SR-Ethernet-VPWS use-case.</t>
                <t>Node 8 is configured a locally instantiated End.DX2 SID 2001:db8:cccc:8:DC2C:: bound to local attachment circuit {ethernet CE-C}.</t>
                <t>Via BGP signalling or an SDN controller, node 1 is programmed with an Ethernet VPWS service for its local attachment circuit {ethernet CE-A} with remote endpoint 2001:db8:cccc:8:DC2C::.</t>

                <t>When 1 receives a frame F from CE-A, node 1 pushes an outer IPv6 header with SA=2001:db8::1, DA=2001:db8:cccc:8:DC2C:: and NH=143. Note that no additional header is pushed. 1 then forwards the resulting packet on the shortest path to 2001:db8:cccc:8::/64.</t>
                <t>When 8 receives the packet, 8 matches the DA in its &quot;My SID Table&quot; and finds the bound function End.DX2. After confirming that next-header=143, 8 decaps the outer IPv6 header and forwards the inner Ethernet frame towards CE-C.</t>
                <t>The reader can easily infer the Ethernet VPWS use-case:</t>
                <figure align="center"><artwork align="center"><![CDATA[
+------------------------+-----------------------------------+
| Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8) |
+------------------------+-----------------------------------+
| Ethernet VPWS          | End.DX2 function bound to         |
|                        | CE-C (Ethernet)                   |
+------------------------+-----------------------------------+
                ]]></artwork></figure>
            </section>

            <section title="SR-EVPN-FXC">
                <t>Let us illustrate the SR-EVPN-FXC use-case (Flexible cross-connect service).</t>

                <t>Node 8 is configured with a locally instantiated End.DX2V SID 2001:db8:cccc:8:DC2C:: bound to the L2 table T1. Node 8 is also configured with local attachment circuits {ethernet CE1-C VLAN:100} and {ethernet CE2-C VLAN:200} in table T1.</t>
                <t>Via an SDN controller or derived from a BGP-based sginalling, the node 1 is programmed with an EVPN-FXC service for its local attachment circuit {ethernet CE-A} with remote endpoint 2001:db8:cccc:8:DC2C::. For this purpose, the EVPN Type-1 route is used.</t>

                <t>When node 1 receives a frame F from CE-A, it pushes an outer IPv6 header with SA=2001:db8::1, DA=2001:db8:cccc:8:DC2C:: and NH=143. Note that no additional header is pushed. Node 1 then forwards the resulting packet on the shortest path to 2001:db8:cccc:8::/64.</t>
                <t>When node 8 receives the packet, it matches the IP DA in its &quot;My SID Table&quot; and finds the bound function End.DX2V. After confirming that next-header=143, node 8 decaps the outer IPv6 header, performs a VLAN loopkup in table T1 and forwards the inner Ethernet frame to matching interface e.g. for VLAN 100, packet is forwarded to CE1-C and for VLAN 200, frame is forwarded to CE2-C.</t>
                <t>The reader can easily infer the Ethernet FXC use-case:</t>
                <figure align="center"><artwork align="center"><![CDATA[
+---------------------------------+------------------------------------+
| Route at ingress PE (1)         | SR-VPN Egress SID of egress PE (8) |
+---------------------------------+------------------------------------+
| EVPN-FXC                        | End.DX2V function bound to         |
|                                 | CE1-C / CE2-C (Ethernet)           |
+---------------------------------+------------------------------------+
                ]]></artwork></figure>
            </section>

            <section title="SR-EVPN">
                <t>The following section details some of the particular use-cases of SR-EVPN. In particular bridging (unicast and multicast), multi-homing ESI filtering, L3 EVPN and EVPN-IRB.</t>
                <section title="EVPN Bridging">
                    <t>Let us illustrate the SR-EVPN unicast and multicast bridging.</t>

                    <t>Nodes 1, 3 and 8 are configured with a EVPN bridging service (E-LAN service).</t>

                    <t>Node 1 is configured with a locally instantiated End.DT2U SID 2001:db8:cccc:1:D2AA:: bound to a local L2 table T1 where EVPN is enabled. This SID will be used to attract unicast traffic. Additionally, Node 1 is configured with a locally instantiated End.DT2M SID 2001:db8:cccc:1:D2AF:: bound to the same local L2 table T1. This SID will be used to attract multicast traffic. Node 1 is also configured with local attachment circuit {ethernet CE-A VLAN:100} associated to table T1.</t>

                    <t>A similar instantiation is done at Node 3 and Node 8 resulting in:
                        <list style="format - ">
                            <t>Node 1 - My SID table:
                                <list style="format - ">
                                    <t>End.DT2U SID: 2001:db8:cccc:1:D2AA:: table T1</t>
                                    <t>End.DT2M SID: 2001:db8:cccc:1:D2AF:: table T1</t>
                                </list>
                            </t>
                            <t>Node 3 - My SID table:
                                <list style="format - ">
                                    <t>End.DT2U SID: 2001:db8:cccc:3:D2BA:: table T3</t>
                                    <t>End.DT2M SID: 2001:db8:cccc:3:D2BF:: table T3</t>
                                </list>
                            </t>
                            <t>Node 8 - My SID table:
                                <list style="format - ">
                                    <t>End.DT2U SID: 2001:db8:cccc:8:D2CA:: table T8</t>
                                    <t>End.DT2M SID: 2001:db8:cccc:8:D2CB:: table T8</t>
                                </list>
                            </t>
                        </list>
                    </t>

                    <t>Nodes 1, 4 and 8 are going to exchange the End.DT2M SIDs via BGP-based EVPN Type-3 route. Upon reception of the EVPN Type-3 routes, each node build its own replication list per L2 table that will be used for ingress BUM traffic replication. The replication lists are the following:
                        <list style="format - ">
                            <t>Node 1 - replication list: {2001:db8:cccc:3:D2BF:: and 2001:db8:cccc:8:D2CF::}</t>
                            <t>Node 3 - replication list: {2001:db8:cccc:1:D2AF:: and 2001:db8:cccc:8:D2CF::}</t>
                            <t>Node 8 - replication list: {2001:db8:cccc:1:D2AF:: and 2001:db8:cccc:3:D2CF::}</t>
                        </list>
                    </t>

                    <t>When node 1 receives a BUM frame F from CE-A, it replicates that frame to every node in the replication list. For node 3, it pushes an outer IPv6 header with SA=2001:db8::1, DA=2001:db8:cccc:3:D2BF:: and NH=143. For node 8, it performs the same operation but DA=2001:db8:cccc:8:D2CF::. Note that no additional headers are pushed. Node 1 then forwards the resulting packets on the shortest path for each destination.</t>

                    <t>When node 3 receives the packet, it matches the DA in its &quot;My SID Table&quot; and finds the bound function End.DT2M with its related layer2 table T3. After confirming that next-header=143, node 3 decaps the outer IPv6 header and forwards the inner Ethernet frame to all layer-2 output interface found in table T3. Similar processing is also performed by node 8 upon packet reception. This example is the same for any BUM stream coming from CE-B or CE-C.</t>
                    <t><vspace blankLines="1" /></t>

                    <t>Node 1,3 and 8 are also performing software MAC learning to exchange MAC reachability information (unicast traffic) via BGP among themselves.</t>
                    <t>Each MAC being learnt is exchanged using BGP-based EVPN Type-2 route.</t>

                    <t>When node 1 receives an unicast frame F from CE-A, it learns its MAC-SA=CEA in software. Node 1 transmits that MAC and its associated SID 2001:db8:cccc:1:D2AA:: using BGP-based EVPN route-type 2 to all remote nodes.</t>

                    <t>When node 3 receives an unicast frame F from CE-B destinated to MAC-DA=CEA, it performs a L2 lookup on T3 to find the associated SID. It pushes an outer IPv6 header with SA=2001:db8::3, DA=2001:db8:cccc:1:D2AA:: and NH=143. Node 3 then forwards the resulting packet on the shortest path to 2001:db8:cccc:1::/64. Similar processing is also performed by node 8.</t>
                </section>

                <section title="EVPN Multi-homing with ESI filtering">
                    <t>In L2 network, support for traffic loop avoidance is mandatory. In EVPN all-active multi-homing scenario enforces that requirement using ESI filtering. Let us illustrate how it works:</t>
                    <t>Nodes 3 and 4 are peering partners of a redundancy group where the access CE-B, is connected in an all-active multi-homing way with these two nodes. Hence, the topology is the following:</t>
                    <figure title="EVPN ESI filtering - Reference topology" align="center"><artwork align="center"><![CDATA[
              CE-B
             /    \
            3------4---5
            |       \ /
            |        6 
            |       / 
    A--1--- 2------7---8--B
      /                 \
   CE-A                 CE-C 
Tenant100            Tenant100 with
                       IPv4 203.0.113.0/24
                ]]></artwork></figure>
                    <t>Nodes 3 and 4 are configured with an EVPN bridging service (E-LAN service).</t>
                    <t>Node 3 is configured with a locally instantiated End.DT2M SID 2001:db8:cccc:3:D2BF:: bound to a local L2 table T1 where EVPN is enabled. This SID is also configured with the optional argument Arg.FE2 that specifies the attachment circuit. Particularly, node 3 assigns identifier 0xC1 to {ethernet CE-B}.</t>
                    <t>Node 4 is configured with a locally instantiated End.DT2M SID 2001:db8:cccc:4:D2BF:: bound to a local L2 table T1 where EVPN is enabled. This SID is also configured with the optional argument Arg.FE2 that specifies the attachment circuit. Particularly, node 4 assigns identifier 0xC2 to {ethernet CE-B}.</t>

                    <t>Both End.DT2M SIDs are exchanged between nodes via BGP-based EVPN Type-3 routes. Upon reception of EVPN Type-3 routes, each node build its own replication list per L2 table T1.</t>
                    <t>On the other hand, the End.DT2M SID arguments (Arg.F2) are exchanged between nodes via SRv6 VPN SID attached to the BGP-based EVPN Type-1 route. The BGP ESI-filtering extended community label is set to implicit-null <xref target="I-D.ietf-bess-srv6-services"/>.</t>

                    <t>Upon reception of EVPN Type-1 route and Type-3 route, node 3 merges merges the End.DT2M SID (2001:db8:cccc:4:D2BF:) with the Arg.FE2(0:0:0:C2::) from node 4 (its peering partner). This is done by a simple OR bitwise operation. As a result, the replication list on node 3 for the PEs 1,4 and 8 is: {2001:db8:cccc:1:D2AF::; 2001:db8:cccc:4:D2BF:C2::;  2001:db8:cccc:8:D2CF::}.</t>
                    <t>In a similar manner, the replication list on node 4 for the PEs 1,3 and 8 is: {2001:db8:cccc:1:D2AF::; 2001:db8:cccc:3:D2BF:C1::;  2001:db8:cccc:8:D2CF::}. Note that in this case the SID for PE3 contains the OR bitwise operation of SIDs 2001:db8:cccc:3:D2BF:: and 0:0:0:C1::.</t>
 
                    <t>When node 3 receives a BUM frame F from CE-B, it replicates that frame to remote PEs. For node 4, it pushes an outer IPv6 header with SA=2001:db8::3, DA=2001:db8:cccc:4:D2BF:C2:: and NH=143. Note that no additional header is pushed. Node 3 then forwards the resulting packet on the shortest path to node 4, and once the packet arrives to node 4, the End.DT2M function is executed forwarding to all L2 OIFs except the ones corresponding to identifier 0xC2.</t>
                </section>

                <section title="EVPN Layer-3">
                    <t>EVPN layer-3 works exactly in the same way than L3VPN. Please refer to section <xref target="illustration_l3vpn" /></t>
                </section>

                <section title="EVPN Integrated Routing Bridging (IRB)">
                    <t>EVPN IRB brings Layer-2 and Layer-3 together. It uses BGP-based EVPN Type-2 route to achieve Layer-2 intra-subnet and Layer-3 inter-subnet forwarding. The EVPN Type-2 route-2 maintains the MAC/IP association.</t>

                    <t>Node 8 is configured with a locally instantiated End.DT2U SID 2001:db8:cccc:8:D2C:: used for unicast L2 traffic. Node 8 is also configured with locally instantiated End.DT4 SID 2001:db8:cccc:8:D100:: bound to IPv4 tenant table 100.</t>

                    <t>Node 1 is going to be configured with the EVPN IRB service.</t>

                    <t>Node 8 signals to other remote PEs (1, 3) each ARP/ND request learned via BGP-based EVPN Type-2 route. For example, when node 8 receives an ARP/ND packet P from a host (203.0.113.20) on CE-C destined to 192.0.2.10, it learns its MAC-SA=CEC in software. It also learns the ARP/ND entry (IP SA=203.0.113.20) in its cache. Node 8 transmits that MAC/IP and its associated L3 SID (2001:db8:cccc:8:D100::) and L2 SID (2001:db8:cccc:8:D2C::).</t>

                    <t>When node 1 receives a packet P from CE-A destined to 203.0.113.20 from a host (192.0.2.10), node 1 looks up its tenant-100 IPv4 table and finds an SR-VPN entry for that prefix. As a consequence, node 1 pushes an outer IPv6 header with SA=2001:db8::1, DA=2001:db8:cccc:8:D100:: and NH=4. Node 1 then forwards the resulting packet on the shortest path to 2001:db8:cccc:8::/64. EVPN inter-subnet forwarding is then achieved.</t>

                    <t>When node 1 receives a packet P from CE-A destined to 203.0.113.20 from a host (192.0.2.11), P looks up its L2 table T1 MAC-DA lookup to find the associated SID. It pushes an outer IPv6 header with SA=2001:db8::1, DA=2001:db8:cccc:8:D2C:: and NH=143. Note that no additional header is pushed. Node 8 then forwards the resulting packet on the shortest path to 2001:db8:cccc:8::/64. EVPN intra-subnet forwarding is then achieved.</t>
                </section>
            </section>


            <section title="SR TE for Underlay SLA">
                <section title="SR policy from the Ingress PE">
                    <t>Let's assume that node 1's tenant-100 IPv4 route "203.0.113.0/24 via 2001:db8:cccc:8:D100::" is programmed with a color/community that requires low-latency underlay optimization <xref target="I-D.ietf-spring-segment-routing-policy"/>.</t>
                    <t>In such case, node 1 either computes the low-latency path to the egress node itself or delegates the computation to a PCE.</t>
                    <t>In either case, the location of the egress PE can easily be found by looking for who originates the locator comprising the SID 2001:db8:cccc:8:D100::. This can be found in the IGP's LSDB for a single domain case, and in the BGP-LS LSDB for a multi-domain case.</t>
                    <t>Let us assume that the TE metric encodes the per-link propagation latency. Let us assume that all the links have a TE metric of 10, except link 27 which has TE metric 100.</t>
                    <t>The low-latency path from 1 to 8 is thus 1234678.</t>
                    <t>This path is encoded in a SID list as: first a hop through 2001:db8:cccc:3:C4:: and then a hop to 8.</t>
                    <t>As a consequence the SR-VPN entry 203.0.113.0/24 installed in the Node1's Tenant-100 IPv4 table is: H.Encaps with SRv6 Policy &lt;2001:db8:cccc:3:C4::, 2001:db8:cccc:8:D100::&gt;.</t>
                    <t>When 1 receives a packet P from CE-A destined to 203.0.113.20, P looks up its tenant-100 IPv4 table and finds an SR-VPN entry 203.0.113.0/24. As a consequence, 1 pushes an outer header with SA=2001:db8::1, DA=2001:db8:cccc:3:C4::, NH=SRH followed by SRH (2001:db8:cccc:8:D100::, 2001:db8:cccc:3:C4::; SL=1; NH=4). 1 then forwards the resulting packet on the interface to 2.</t>
                    <t>2 forwards to 3 along the path to 2001:db8:cccc:3::/64.</t>
                    <t>When 3 receives the packet, 3 matches the DA in its &quot;My SID Table&quot; and finds the bound function End.X to neighbor 4. 3 notes the PSP capability of the SID 2001:db8:cccc:3:C4::. 3 sets the DA to the next SID 2001:db8:cccc:8:D100::. As 3 is the penultimate segment hop, it performs PSP and pops the SRH. 3 forwards the resulting packet to 4.</t>
                    <t>4, 6 and 7 forwards along the path to 2001:db8:cccc:8::/64.</t>
                    <t>When 8 receives the packet, 8 matches the DA in its &quot;My SID Table&quot; and finds the bound function End.DT(100). As a result, 8 decaps the outer header, looks up the inner IPv4 DA (203.0.113.20) in tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards CE-B.</t>
                </section>

                <section title="SR policy at a midpoint">
                    <t>Let us analyze a policy applied at a midpoint on a packet without SRH.</t>
                    <t>Packet P1 is (2001:db8::1, 2001:db8:cccc:8:D100::).</t>
                    <t>Let us consider P1 when it is received by node 2 and let us assume that that node 2 is configured to steer 2001:db8:cccc:8::/64 in a H.Insert.Red behavior associated with SR policy &lt;2001:db8:cccc:3:C4::&gt;.</t>
                    <t>In such a case, node 2 would send the following modified packet P1 on the link to 3:</t>
                    <t>(2001:db8::1, 2001:db8:cccc:3:C4::)(2001:db8:cccc:8:D100::; SL=1).</t>
                    <t>The rest of the processing is similar to the previous section.</t>
                    <t><vspace blankLines="1" /></t>
                    <t>Let us analyze a policy applied at a midpoint on a packet with an SRH.</t>
                    <t>Packet P2 is (2001:db8::1, 2001:db8:cccc:7:1::)(2001:db8:cccc:8:D100::; SL=1).</t>
                    <t>Let us consider P2 when it is received by node 2 and let us assume that node 2 is configured to steer 2001:db8:cccc:7::/64 in a H.Insert.Red behavior associated with SR policy &lt;2001:db8:cccc:3:C4::, 2001:db8:cccc:5:1::&gt;.</t>
                    <t>In such a case, node 2 would send the following modified packet P2 on the link to 4:</t>
                    <t>(2001:db8::1, 2001:db8:cccc:3:C4::)(2001:db8:cccc:7:1::, 2001:db8:cccc:5:1::; SL=2)(2001:db8:cccc:8:D100::; SL=1)</t>
                    <t>Node 3 would send the following packet to 4: (2001:db8::1, 2001:db8:cccc:5:1::)(2001:db8:cccc:7:1::, 2001:db8:cccc:5:1::; SL=1)(2001:db8:cccc:8:D100::; SL=1)</t>
                    <t>Node 4 would send the following packet to 5: (2001:db8::1, 2001:db8:cccc:5:1::)(2001:db8:cccc:7:1::, 2001:db8:cccc:5:1::; SL=1)(2001:db8:cccc:8:D100::; SL=1)</t>
                    <t>Node 5 would send the following packet to 6: (2001:db8::1, 2001:db8:cccc:7:1::)(2001:db8:cccc:8:D100::; SL=1)</t>
                    <t>Node 6 would send the following packet to 7: (2001:db8::1, 2001:db8:cccc:7:1::)(2001:db8:cccc:8:D100::; SL=1)</t>
                    <t>Node 7 would send the following packet to 8: (2001:db8::1, 2001:db8:cccc:8:D100::)</t>
                </section>
            </section>

            <section title="End-to-End policy with intermediate BSID">
                <t>Let us now describe a case where the ingress VPN edge node steers the packet destined to 203.0.113.20 towards the egress edge node connected to the tenant100 site with 203.0.113.0/24, but via an intermediate SR Policy represented by a single routable Binding SID. Let us illustrate this case with an intermediate policy which both encodes underlay optimization for low-latency and the service programming via two SR-aware container-based apps.</t>
                <t>Let us assume that the End.B6.Insert SID 2001:db8:cccc:2:B1:: is configured at node 2 and is associated with midpoint SR policy &lt;2001:db8:cccc:3:C4::, 2001:db8:cccc:9:A1::, 2001:db8:cccc:6:A2::&gt;.</t>
                <t>2001:db8:cccc:3:C4:: realizes the low-latency path from the ingress PE to the egress PE. This is the underlay optimization part of the intermediate policy.</t>
                <t>2001:db8:cccc:9:A1:: and 2001:db8:cccc:6:A2:: represent two SR-aware NFV applications residing in containers respectively connected to node 9 and 6.</t>
                <t>Let us assume the following ingress VPN policy for 203.0.113.0/24 in tenant 100 IPv4 table of node 1: H.Encaps with SRv6 Policy &lt;2001:db8:cccc:2:B1::, 2001:db8:cccc:8:D100::&gt;.</t>
                <t>This ingress policy will steer the 203.0.113.0/24 tenant-100 traffic towards the correct egress PE and via the required intermediate policy that realizes the SLA and NFV requirements of this tenant customer.</t>
                <t>Node 1 sends the following packet to 2: (2001:db8::1, 2001:db8:cccc:2:B1::) (2001:db8:cccc:8:D100::, 2001:db8:cccc:2:B1::; SL=1)</t>
                <t>Node 2 sends the following packet to 4: (2001:db8::1, 2001:db8:cccc:3:C4::) (2001:db8:cccc:6:A2::, 2001:db8:cccc:9:A1::, 2001:db8:cccc:3:C4::; SL=2)(2001:db8:cccc:8:D100::, 2001:db8:cccc:2:B1::; SL=1)</t>
                <t>Node 4 sends the following packet to 5: (2001:db8::1, 2001:db8:cccc:9:A1::) (2001:db8:cccc:6:A2::, 2001:db8:cccc:9:A1::, 2001:db8:cccc:3:C4::; SL=1)(2001:db8:cccc:8:D100::, 2001:db8:cccc:2:B1::; SL=1)</t>
                <t>Node 5 sends the following packet to 9: (2001:db8::1, 2001:db8:cccc:9:A1::) (2001:db8:cccc:6:A2::, 2001:db8:cccc:9:A1::, 2001:db8:cccc:3:C4::; SL=1)(2001:db8:cccc:8:D100::, 2001:db8:cccc:2:B1::; SL=1)</t>
                <t>Node 9 sends the following packet to 6: (2001:db8::1, 2001:db8:cccc:6:A2::) (2001:db8:cccc:8:D100::, 2001:db8:cccc:2:B1::; SL=1)</t>
                <t>Node 6 sends the following packet to 7: (2001:db8::1, 2001:db8:cccc:8:D100::) </t>
                <t>Node 7 sends the following packet to 8: (2001:db8::1, 2001:db8:cccc:8:D100::) which decaps and forwards to CE-B.</t>
                <t>The benefits of using an intermediate Binding SID are well-known and key to the Segment Routing architecture: the ingress edge node needs to push fewer SIDs, the ingress edge node does not need to change its SR policy upon change of the core topology or re-homing of the container-based apps on different servers. Conversely, the core and service organizations do not need to share details on how they realize underlay SLA's or where they home their NFV apps.</t>
            </section>

            <section title="TI-LFA">
                <t>Let us assume two packets P1 and P2 received by node 2 exactly when the failure of link 27 is detected.
                    <list style="empty">
                        <t>P1: (2001:db8::1, 2001:db8:cccc:7:1::)</t>
                        <t>P2: (2001:db8::1, 2001:db8:cccc:7:1::)(2001:db8:cccc:8:D100::; SL=1)</t>
                    </list></t>
                <t>Node 2's pre-computed TI-LFA backup path for the destination 2001:db8:cccc:7::/64 is &lt;2001:db8:cccc:3:C4::&gt;. It is installed as a H.Insert.Red transit behavior.</t>
                <t>Node 2 protects the two packets P1 and P2 according to the pre-computed TI-LFA backup path and send the following modified packets on the link to 4:
                    <list style="empty">
                        <t>P1: (2001:db8::1, 2001:db8:cccc:3:C4::)(2001:db8:cccc:7:1::; SL=1)</t>
                        <t>P2: (2001:db8::1, 2001:db8:cccc:3:C4::)(2001:db8:cccc:7:1::; SL=1) (2001:db8:cccc:8:D100::; SL=1)</t>
                    </list></t>
                <t>Node 4 then sends the following modified packets to 5:
                    <list style="empty">
                        <t>P1: (2001:db8::1, 2001:db8:cccc:7:1::)</t>
                        <t>P2: (2001:db8::1, 2001:db8:cccc:7:1::)(2001:db8:cccc:8:D100::; SL=1)</t>
                    </list></t>
                <t>Then these packets follow the rest of their post-convergence path towards node 7 and then go to node 8 for the VPN decaps.</t>
            </section>

            <section title="SR TE for Service programming">
                <t>We have illustrated the service programming through SR-aware apps in a previous section.</t>
                <t>We illustrate the use of End.AS function <xref target="I-D.ietf-spring-sr-service-programming"/> to service chain an IP flow bound to the internet through two SR-unaware applications hosted in containers.</t>
                <t>Let us assume that servers 20 and 70 are respectively connected to nodes 2 and 7. They are respectively configured with SID spaces 2001:db8:cccc:20::/64 and 2001:db8:cccc:70::/64. Their connected routers advertise the related prefixes in the IGP. Two SR-unaware container-based applications App2 and App7 are respectively hosted on server 20 and 70. Server 20 (70) is configured explicitly with an End.AS SID 2001:db8:cccc:20:2:: for App2 (2001:db8:cccc:70:7:: for App7).</t>
                <t>Let us assume a broadband customer with a home gateway CE-A connected to edge router 1. Router 1 is configured with an SR policy which encapsulates all the traffic received from CE-A into a H.Encaps policy &lt;2001:db8:cccc:20:2::, 2001:db8:cccc:70:7::, 2001:db8:cccc:8:D0::&gt; where 2001:db8:cccc:8:D0:: is an End.DT4 SID instantiated at node 8.</t>
                <t>P1 is a packet sent by the broadband customer to 1: (X, Y) where X and Y are two IPv4 addresses.</t>
                <t>1 sends the following packet to 2: (A1::, 2001:db8:cccc:20:2::)(2001:db8:cccc:8:D0::, 2001:db8:cccc:70:7::, 2001:db8:cccc:20:2::; SL=2; NH=4)(X, Y).</t>
                <t>2 forwards the packet to server 20.</t>
                <t>20 receives the packet (A1::, 2001:db8:cccc:20:2::)(2001:db8:cccc:8:D0::, 2001:db8:cccc:70:7::, 2001:db8:cccc:20:2::; SL=2; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App2. App2 works on the packet and forwards it back to 20. 20 pushes the outer IPv6 header with SRH (A1::, 2001:db8:cccc:70:7::)(2001:db8:cccc:8:D0::, 2001:db8:cccc:70:7::, 2001:db8:cccc:20:2::; SL=1; NH=4) and sends the (whole) IPv6 packet with the encapsulated IPv4 packet back to 2.</t>
                <t>2 and 7 forward to server 70.</t>
                <t>70 receives the packet (A1::, 2001:db8:cccc:70:7::)(2001:db8:cccc:8:D0::, 2001:db8:cccc:70:7::, 2001:db8:cccc:20:2::; SL=1; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App7. App7 works on the packet and forwards it back to 70. 70 pushes the outer IPv6 header with SRH (A1::, 2001:db8:cccc:8:D0::)(2001:db8:cccc:8:D0::, 2001:db8:cccc:70:7::, 2001:db8:cccc:20:2::; SL=0; NH=4) and sends the (whole) IPv6 packet with the encapsulated IPv4 packet back to 7.</t>
                <t>7 forwards to 8.</t>
                <t>8 receives (A1::, 2001:db8:cccc:8:D0::)(2001:db8:cccc:8:D0::, 2001:db8:cccc:70:7::, 2001:db8:cccc:20:2::; SL=0; NH=4)(X, Y) and performs the End.DT4 function and sends the IP packet (X, Y) towards its internet destination.</t>
                <t><vspace blankLines="15" /></t>
            </section>
        </section>

        <?rfc needLines="10" ?>
        <section title="Benefits">
            <section title="Seamless deployment">
                <t>The VPN use-case can be realized with SRv6 capability deployed solely at the ingress and egress PE's.
                    <list style="empty">
                        <t>All the nodes in between these PE's act as transit routers as per <xref target="RFC8200"/>. No software/hardware upgrade is required on all these nodes. They just need to support IPv6 per <xref target="RFC8200"/>.</t>
                    </list></t>
                <t>The SRTE/underlay-SLA use-case can be realized with SRv6 capability deployed at few strategic nodes.
                    <list style="empty">
                        <t>It is well-known from the experience deploying SR-MPLS that underlay SLA optimization requires few SIDs placed at strategic locations. This was illustrated in our example with the low-latency optimization which required the operator to enable one single core node with SRv6 (node 4) where one single and End.X SID towards node 5 was instantiated. This single SID is sufficient to force the end-to-end traffic via the low-latency path.</t>
                    </list></t>
                <t>The TI-LFA benefits are collected incrementally as SRv6 capabilities are deployed.
                    <list style="empty">
                        <t>It is well-know that TI-LFA is an incremental node-by-node deployment. When a node N is enabled for TI-LFA, it computes TI-LFA backup paths for each primary path to each IGP destination. In more than 50% of the case, the post-convergence path is loop-free and does not depend on the presence of any remote SRv6 SID. In the vast majority of cases, a single segment is enough to encode the post-convergence path in a loop-free manner. If the required segment is available (that node has been upgraded) then the related back-up path is installed in FIB, else the pre-existing situation (no backup) continues. Hence, as the SRv6 deployment progresses, the coverage incrementally increases. Eventually, when the core network is SRv6 capable, the TI-LFA coverage is complete.</t>
                    </list></t>
                <t>The service programming use-case can be realized with SRv6 capability deployed at few strategic nodes.
                    <list style="empty">
                        <t>The service-programming deployment is again incremental and does not require any pre-deployment of SRv6 in the network. When an NFV app A1 needs to be enabled for inclusion in an SRv6 service chain, all what is required is to install that app in a container or VM on an SRv6-capable server (Linux 4.10 or FD.io 17.04 release). The app can either be SR-aware or not, leveraging the proxy functions.</t>
                        <t>By leveraging the various End functions it can also be used to support any current VNF/CNF implementations and their forwarding methods (e.g. Layer 2).</t>
                        <t>The ability to leverage SR TE policies and BSIDs also permits building scalable, hierarchical service-chains.</t>
                    </list></t>
            </section>

            <section title="Integration">
                <t>The SRv6 network programming concept allows integrating all the application and service requirements: multi-domain underlay SLA optimization with scale, overlay VPN/Tenant, sub-50msec automated FRR, security and service programming.</t>
            </section>

            <section title="Security">
                <t>The combination of well-known techniques (SEC-1, SEC-2) and carefully chosen architectural rules (SEC-3) ensure a secure deployment of SRv6 inside a multi-domain network managed by a single organization.</t>
                <t>Inter-domain security will be described in a companion document.</t>
            </section>
        </section>

        <?rfc needLines="1" ?>
        <section anchor="Acknowledgements" title="Acknowledgements">
            <t>The authors would like to acknowledge Stefano Previdi, Dave Barach, Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, Jisu Bhattacharya, Saleem Hafeez and Michael Huang.</t>
        </section>

        <?rfc needLines="1" ?>
        <section title="Contributors">

            <t>Daniel Bernier<vspace blankLines="0" />
            Bell Canada<vspace blankLines="0" />
            Canada</t>
            <t>Email: daniel.bernier@bell.ca<vspace blankLines="0" /></t>

            <t>Daniel Voyer<vspace blankLines="0" />
            Bell Canada<vspace blankLines="0" />
            Canada</t>
            <t>Email: daniel.voyer@bell.ca<vspace blankLines="0" /></t>

            <t>Bart Peirens<vspace blankLines="0" />
            Proximus<vspace blankLines="0" />
            Belgium</t>
            <t>Email: bart.peirens@proximus.com<vspace blankLines="0" /></t>

            <t>Hani Elmalky<vspace blankLines="0" />
            Ericsson<vspace blankLines="0" />
            United States of America</t>
            <t>Email: hani.elmalky@gmail.com<vspace blankLines="0" /></t>
            
            <t>Prem Jonnalagadda<vspace blankLines="0" />
            Barefoot Networks<vspace blankLines="0" />
            United States of America</t>
            <t>Email: prem@barefootnetworks.com<vspace blankLines="0" /></t>

            <t>Milad Sharif<vspace blankLines="0" />
            Barefoot Networks<vspace blankLines="0" />
            United States of America</t>
            <t>Email: msharif@barefootnetworks.com<vspace blankLines="0" /></t>

            <t>Stefano Salsano<vspace blankLines="0" />
            Universita di Roma "Tor Vergata"<vspace blankLines="0" />
            Italy</t>
            <t>Email: stefano.salsano@uniroma2.it<vspace blankLines="0" /></t>

            <t>Ahmed AbdelSalam<vspace blankLines="0" />
            Gran Sasso Science Institute<vspace blankLines="0" />
            Italy</t>
            <t>Email: ahmed.abdelsalam@gssi.it</t>

            <t>Gaurav Naik<vspace blankLines="0" />
            Drexel University<vspace blankLines="0" />
            United States of America</t>
            <t>Email: gn@drexel.edu<vspace blankLines="0" /></t>

            <t>Arthi Ayyangar<vspace blankLines="0" />
            Arista<vspace blankLines="0" />
            United States of America</t>
            <t>Email: arthi@arista.com<vspace blankLines="0" /></t>

            <t>Satish Mynam<vspace blankLines="0" />
            Innovium Inc.<vspace blankLines="0" />
            United States of America</t>
            <t>Email: smynam@innovium.com<vspace blankLines="0" /></t>

            <t>Wim Henderickx<vspace blankLines="0" />
            Nokia<vspace blankLines="0" />
            Belgium</t>
            <t>Email: wim.henderickx@nokia.com<vspace blankLines="0" /></t>

            <t>Shaowen Ma<vspace blankLines="0" />
            Juniper<vspace blankLines="0" />
            Singapore</t>
            <t>Email: mashao@juniper.net<vspace blankLines="0" /></t>

            <t>Ahmed Bashandy<vspace blankLines="0" />
            Individual<vspace blankLines="0" />
            United States of America</t>
            <t>Email: abashandy.ietf@gmail.com<vspace blankLines="0" /></t>

            <t>Francois Clad<vspace blankLines="0" />
            Cisco Systems, Inc.<vspace blankLines="0" />
            France</t>
            <t>Email: fclad@cisco.com<vspace blankLines="0" /></t>

            <t>Kamran Raza<vspace blankLines="0" />
            Cisco Systems, Inc.<vspace blankLines="0" />
            Canada</t>
            <t>Email: skraza@cisco.com<vspace blankLines="0" /></t>

            <t>Darren Dukes<vspace blankLines="0" />
            Cisco Systems, Inc.<vspace blankLines="0" />
            Canada</t>
            <t>Email: ddukes@cisco.com<vspace blankLines="0" /></t>

            <t>Patrice Brissete <vspace blankLines="0" />
            Cisco Systems, Inc.<vspace blankLines="0" />
            Canada</t>
            <t>Email: pbrisset@cisco.com<vspace blankLines="0" /></t>

            <t>Zafar Ali<vspace blankLines="0" />
            Cisco Systems, Inc.<vspace blankLines="0" />
            United States of America</t>
            <t>Email: zali@cisco.com</t>
        </section>
    </middle>
    <back>
        <references title="References">
            &RFC2119;
            &RFC8174;
            &RFC8754;
            &RFC8986;
            &SR_VPN_BGP;
            &SR_TE_PL;
            &RFC8200;
            &SR_SFC;
        </references>
    </back>
</rfc>
