Internet DRAFT - draft-dunbar-sr-sdwan-over-hybrid-networks

draft-dunbar-sr-sdwan-over-hybrid-networks



RTG Working Group                                           L. Dunbar
Internet Draft                                              Futurewei
Intended status: Standard                                  Mehmet Toy
Expires: October 18, 2021                                    Verizon
                                                          May 18, 2021


                          SRv6 across SDWAN paths
               draft-dunbar-sr-sdwan-over-hybrid-networks-07

Abstract

   This document describes the mechanism of steering packets across
   SDWAN segments based on the metadata carried by the SRv6 packets.

   Some of the SDWAN segments are untrusted networks, and some are
   private networks. The goal is to achieve the optimal E2E quality.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 23, 2021.






xxx, et al.           Expires November 18, 2021                [Page 1]

Internet-Draft              SRv6 over SDWAN                    May 2021


Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents


   1. Introduction...................................................2
   2. Conventions used in this document..............................3
      3.1. SDWAN as Last Mile for Accessing Cloud Services...........4
      3.2. SRv6 Domain separated by SDWAN............................4
      4.2. End.SDWANv4...............................................5
      4.3. End.IPsecV4...............................................6
      4.4. End.IPsecV6...............................................8
   7. IANA Considerations...........................................10
   8. Security Considerations.......................................10
   9. Contributors..................................................11
   10. References...................................................11
      10.1. Normative References....................................11
      10.2. Informative References..................................11
   11. Acknowledgments..............................................12
   Authors' Addresses...............................................14


1. Introduction

   SRv6 has many advantages. This document defines using the metadata
   encoded in the SRH for SRv6 packets to cross an SDWAN network.

   SDWAN is about pooling WAN bandwidth from multiple service providers
   to get better WAN bandwidth management, visibility & control. There
   could be multiple underlay paths between a pair of edge nodes,



Majumdar, et al.       Expires October15, 2021                 [Page 2]

Internet-Draft              SRv6 over SDWAN                    May 2021


   potentially managed by different service providers, such as MPLS
   paths and paths over the public internet.

   This document describes the SRv6 SRH metadata encoding for the SRv6
   packets to cross SDWAN for the scenarios described by the [BGP-
   SDWAN-Usage]:

     1) Homogeneous WAN, with edge nodes encrypting all traffic over
     the WAN to other edge nodes, regardless of whether the underlay is
     private or public.

     2) Hybrid WAN Underlay, in which traffic over IP VPN is forwarded
     natively without IPsec protection and carried by IPsec tunnels
     when forwarded over the public Internet.

     3) Private VPN PE-based SDWAN, which is about existing VPN (e.g.,
     EVPN or IPVPN) being expanded by the additional ports facing the
     untrusted Internet for PEs to offload low-priority traffic when
     the VPN paths are congested.


2. Conventions used in this document

   BSID       - Binding SID

   DC         - Data Center

   DN         - Data Network (5G)

   SD-WAN     - Software-Defined Wide Area Network

   SID        - Segment Identifier

   SR         - Segment Routing


3. Use Cases







Majumdar, et al.       Expires October15, 2021                 [Page 3]

Internet-Draft              SRv6 over SDWAN                    May 2021


3.1. SDWAN as Last Mile for Accessing Cloud Services

   Digital Transformation is propelling more and more enterprises to
   utilize the rich Cloud services, such as virtual machines, remote
   databases, analytic tools, machine learning APIs, etc. Cloud
   services enable enterprises to run their workloads/Apps at locations
   geographically close to their end-users and provide advanced
   analytic tools and APIs for the applications and data hosted in the
   Clouds.

   The wide availability at any location, which is one of the
   advantages of Cloud Services, can impose challenges to connect
   enterprises' on-premises applications with their Cloud services
   securely. The SRv6 domain that interconnect the enterprises'
   locations may not reach the Cloud DCs where the Cloud services are
   hosted. SDWAN is positioned as a flexible choice as the last mile to
   bridge the enterprise's SR domain to its desired Cloud services.

          +--------+    +----+        +-----
         /  SRv6    \  /      \      /Cloud DC
   a--> PE1  domain  SE1 SDWAN SE2-cGW--> b
         \          /  \      /      \
          +--------+    +----+        +-----
           Figure 1: SDWAN as last mile



3.2. SRv6 Domain separated by SDWAN

   SRv6 deployment is incremental. Some services do need to cross
   segments that do not support SRv6, as shown in the Figure below.

          +--------+    +----+    +-------+
         /  SRv6    \  /      \  /  SRv6   \
   a--> PE1 domain 1 SE1 SDWAN SE2 domain 2 PE4 --> b
         \          /  \      /  \         /
          +--------+    +----+    +-------+
     Figure 2: SDWAN connecting two SRv6 domains


4. SDWAN Path Programming in SRv6

   An SDWAN path between two edge nodes can be an IPsec tunnel, an MPLS
   path, an IPv4, or an IPv6 path over a private IP network. For an



Majumdar, et al.       Expires October15, 2021                 [Page 4]

Internet-Draft              SRv6 over SDWAN                    May 2021


   SRv6 packet to cross an SDWAN domain, the edge node, such as SE1 &
   SE2 in Figure 1 & Figure 2, can make the local decision in choosing
   an SDWAN path between the two edge nodes. Alternatively, the
   controller can instruct the SR domain head node, like the PE1 in
   Figure 2, to encode the metadata in the SRH that can indicate the
   SDWAN path for the SDWAN ingress node SE1.

4.2. End.SDWANv4

   End.SDWANv4 is an End function for the receiving node to locally
   select an SDWAN path destined towards the IPv4 destination address
   encoded in the SRH.

   The SDWAN tunnel information are encoded in another 128-bit value
   following the SID or SRH TLVs.

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          IPv4 SDWAN Tunnel Information                        |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              SRv6 End.SDWANv4 SID                             |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 3. IPv4 SDWAN Sub-Path Encoding in SRH

   The SDWAN Tunnel Information encoding follows the format from
   [SDWAN-Edge-Discovery]:

 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       |          Reserved                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPv4 SDWAN tunnel Src Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPv4 SDWAN tunnel Dest address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~              Inner encapsulation Sub-TLV                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 4. SDWAN Tunnel Encoding



   Type = SDWAN-Hybrid: for the end node to locally select an SDWAN
   path with inner encapsulation type to carry the packet.


Majumdar, et al.       Expires October15, 2021                 [Page 5]

Internet-Draft              SRv6 over SDWAN                    May 2021


   The inner encapsulation Sub-TLV can be GRE Sub-TLV or VxLAN Sub-TLV
   as specified in the [Tunnel-Encap].

   For SRH to indicate exact SDWAN MPLS path to forward the packet, the
   SRH encoding should follow the encoding described in the [SRv6-
   traverse-MPLS].

   This document's Section 4.2 and 4.3 describes the encoding for SR
   head node to indicate the IPsec IPv4 or IPv6 tunnels in SRH,
   respectively.


4.3. End.IPsecV4

   End.IPsecV4 is an End function with IPv4 IPsec tunnel instantiation,
   i.e., instructing the receiving node to encapsulate the packet with
   an IPsec tunnel and forward to the IPv4 destination. The IPsec
   tunnel information can be encoded following the SID or SRH TLVs.

   An End.IPsecV4 SID MUST be encoded preceding the IPsec tunnel
   information encapsulation.

   The SRv6 path of crossing IPv4 IPsec tunnel is called IPv4 IPsec
   sub-path. The IPsec tunnel attributes are encoded by an END.IPsecV4
   SID and the following IPv4 IPsec tunnel information encapsulation as
   shown in the following figure.

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          IPv4 IPsec Tunnel Information                        |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              SRv6 End.IPsecV4 SID                             |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 5. IPv4 IPsec Sub-Path Encoding in SRH


   The IPv4 IPsec tunnel should be ESP Tunnel mode. For ESP Tunnel
   mode, there can be additional inner encapsulation. SDWAN edge nodes
   can also encapsulate the ESP IPsec packet inside UDP for NAT
   traversal and better ECMP [RFC3948].

   Here is the IPsec tunnel information encoding:

 0                   1                   2                   3


Majumdar, et al.       Expires October15, 2021                 [Page 6]

Internet-Draft              SRv6 over SDWAN                    May 2021


 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       |     Reserved                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPv4 SDWAN tunnel Src Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPv4 SDWAN tunnel Dest Address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPsec SA Sub-TLV                                   |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~              Inner encapsulation Sub-TLV                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 6. IPv4 IPsec Tunnel Encoding

   Type = IPv4 IPsec

   The IPsec SA sub-TLV, specified by [SDWAN-Edge-Discovery], lists the
   identifiers of the pre-established IPsec tunnels between the SDWAN
   Src Address and the Dest Address. One or multiple identifiers are
   listed in the IPsec-SA-ID Sub-TLV for the IPsec tunnels between the
   Source and the Destination addresses.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subTLV-Type  = IPsec-SA-ID    |       Length =                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     IPsec SA Identifier = 1                   |
+---------------------------------------------------------------+
|                     IPsec SA Identifier = 2                   |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 7. IPsec SA Sub-TLV



   The inner encapsulation Sub-TLV can be GRE Sub-TLV or VxLAN Sub-TLV
   as specified in the [Tunnel-Encap].

   When node N receives a packet whose IPv4 DA is S and S is a local
   End.IPsecV4 SID, the line S15 - S16 from the End processing
   [RFC8986] is replaced by the following:

   S15. Encapsulates the SRv6 packet with a new IPsec tunnel
        encapsulation bound to the End.IPsecV4 SID S.



Majumdar, et al.       Expires October15, 2021                 [Page 7]

Internet-Draft              SRv6 over SDWAN                    May 2021


   S16. Submit the IPsec encapsulated packet to the egress IPv4 FIB
        lookup for transmission to the IPsec end point IPv4
        destination.

   S17. }



4.4. End.IPsecV6

   End.IPsecV6 is an End function with IPv6 IPsec tunnel instantiation,
   i.e., instructing the receiving node to encapsulate the packet with
   IPsec tunnel and forwarded to the IPv6 destination.

   End.IPsecV6 behavior is very much like End.IPsecV4 except the
   destination and source address of the IPsec tunnel are IPv6
   addresses.

   When node N receives a packet whose IPv6 DA is S and S is a local
   End.IPsecV6 SID, the line S15 - S16 from the End processing
   [RFC8986] is replaced by the following:

   S15. Encapsulates the SRv6 packet with a new IPsec tunnel
        encapsulation bound to the End.IPsecV6 SID S.

   S16. Submit the IPsec encapsulated packet to the egress IPv6 FIB
        lookup for transmission to the IPsec end point IPv6
        destination.

   S17. }

   The SRv6 path of crossing IPv6 IPsec tunnel is called IPv6 IPsec
   sub-path. The IPsec tunnel attributes are encoded by an END.IPsecV6
   SID and the following IPv6 IPsec tunnel information encapsulation as
   shown in the following figure.

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          IPv6 IPsec Tunnel Information                        |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              SRv6 End.IPsecV6 SID                             |
 ~                                                               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 8. IPv6 IPsec Sub-Path Encoding in SRH



Majumdar, et al.       Expires October15, 2021                 [Page 8]

Internet-Draft              SRv6 over SDWAN                    May 2021




   The IPv6 IPsec tunnel can be ESP Transport mode or Tunnel mode. For
   ESP Tunnel mode, there can be additional inner encapsulation. SDWAN
   edge nodes can also encapsulate the ESP IPsec packet inside UDP for
   NAT traversal and better ECMP [RFC3948].

   Here is the IPv6 IPsec tunnel information encoding:

 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       |     Reserved                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPv6 SDWAN tunnel Src Address                      |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPv6 SDWAN tunnel Dest Address                     |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            IPsec SA Sub-TLV                                   |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~              Inner encapsulation Sub-TLV                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 9. IPv6 IPsec Tunnel Encoding


   Type = IPv6 IPsec



5. Packets from SDWAN to SRv6 Domain

   For the SDWAN as Last Mile use case illustrated in Figure 1, packets
   from "b" -> "a" traverse from SDWAN domain to SRv6 domain. A Binding
   SID needs to be inserted by the SDWAN Edge node SE2 so that the SR
   domain ingress can replace the Binding SID with a list of SIDs
   across the SRv6 domain.

   For an SDWAN path over an IPsec Tunnel, the Binding SID is encoded
   in the GRE key field for the GRE inner encapsulation or encoded in
   the VNID field for the VxLAN inner encapsulation.





Majumdar, et al.       Expires October15, 2021                 [Page 9]

Internet-Draft              SRv6 over SDWAN                    May 2021


   For an SDWAN path over an MPLS underlay, the last MPLS label is used
   as the Binding SID for the SRv6 edge node to convert to a list of
   SRv6 SIDs across the SRv6 domain.

                   Controller---+
                      |         |Binding SID Z
                      |         |
          +--------+  | +----+  |     +-----
         /  SRv6    \ v/      \ v    /Cloud DC
   a<-- PE1  domain  SE1 SDWAN SE2-cGW<-- b
         \          /  \      /      \
          +--------+    +----+        +-----
                     {Z}
                      |
                      v
                  {M, N, O}     {Z}

      Figure 10: Binding SID inserted by SDWAN Edge

   For the SRv6 domain separated by SDWAN use case illustrated in
   Figure 2, the End.SDWANv4/v6 or End.IPsecv4/v6 SID should not be the
   last SID in the SRH. After the SDWAN egress node decapsulates the
   SDWAN header (IPsec header or MPLS header), the remaining SIDs in
   the packet's SRH can forward the packet across the remaining SRv6
   domain.

6. Illustration

   To Be Added

7. IANA Considerations

   TBD.

8. Security Considerations

    Allowing traffic from untrusted network brings the following
security risks:
   1) Potential DDoS attack to the PEs with ports facing the untrusted
     network. I.e. the PE resource being attacked by unwanted traffic.
   2) Potential risk of provider VPN network bandwidth being stolen by
     the entities who spoofed the addresses of SDWAN end nodes.




Majumdar, et al.       Expires October15, 2021                [Page 10]

Internet-Draft              SRv6 over SDWAN                    May 2021


To mitigate security risk of 1) above, it is necessary for ports facing
internet to enable Anti-DDoS feature to prevent major DDoS attack to
those PEs.
To mitigate the security risk of 2) above, RFC7510 defines the use of
DTLS to authenticate and encrypt the RFC7510 encapsulation.



9. Contributors



10. References


10.1. Normative References

   [RFC2890]   G. Dommety  "Key and Sequence Number Extensions to GRE".
   Sep. 2000.


10.2. Informative References

   [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation,
             storage, distribution and enforcement of policies for
             network security", Nov 2007.

   [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and
             Internet Key Exchange (IKE) Document Roadmap", Feb 2011.

   [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", Feb 2006

   [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual
             Private Networks (L2VPNs)", Sept 2006.

   [SR-SDWAN] D. Dukes, et al, "SR for SDWAN: VPN with Underlay SLA",
             draft-dukes-sr-for-sdwan-00, in progress, Oct 2017

   [SRv6-SRH] S. Previdi, et al, "IPv6 Segment Routing Header (SRH)",
             draft-ietf-6man-segment-routing-header-13, in progress,
             April 2018.


Majumdar, et al.       Expires October15, 2021                [Page 11]

Internet-Draft              SRv6 over SDWAN                    May 2021


   [MPLS-SR] A. Bashandy, et al, "Segment Routing with MPLS data
             plane", draft-ietf-spring-segment-routing-mpls-13, in
             progress, April 2018.

   [RFC7510] X. Xu, et al, "Encapsulating MPLS in UDP", April 2015.

   [RFC8086] L. Yong, et al, "GRE-in-UDP Encapsulation", March 2017.

   [BGP-SDWAN-Usage] L. Dunbar, et al, "BGP Usage for SDWAN Overlay
             Networks, draft-dunbar-bess-bgp-sdwan-usage-01, in
             progress, July 2019.

   [SDWAN-Net2Cloud] L. Dunbar, et al, "Dynamic Networks to Hybrid
             Cloud DCs Problem Statement", draft-ietf-rtgwg-net2cloud-
             problem-statement-04, in progress, July 2019.

   [MEF-Cloud] "Cloud Services Architecture Technical Specification",
             Work in progress, April 2018


   [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay
   Networks", draft-dunbar-bess-bgp-sdwan-usage-08, January 2021



   [BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge
   Discovery", draft-dunbar-idr-sdwan-edge-discovery-00, January 2021



   [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation
             Attribute", draft-ietf-idr-tunnel-encaps-19, March 2021.

11. Acknowledgments

   TBD.

   This document was prepared using 2-Word-v2.0.template.dot.







Majumdar, et al.       Expires October15, 2021                [Page 12]

Internet-Draft              SRv6 over SDWAN                    May 2021


















































Majumdar, et al.       Expires October15, 2021                [Page 13]

Internet-Draft              SRv6 over SDWAN                    May 2021


Authors' Addresses



   Linda Dunbar
   Futurewei
   2330 Central Expressway
   Santa Clara, CA  95050
   Email: linda.dunbar@futurewei.com

   Mehmet Toy
   Verizon
   One Verizon Way
   Basking Ridge, NJ 07920
   Email: mehmet.toy@verizon.com
































Majumdar, et al.       Expires October15, 2021                [Page 14]