< draft-dunbar-sr-sdwan-over-hybrid-networks-04.txt   draft-dunbar-sr-sdwan-over-hybrid-networks-05.txt >
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft Futurewei Internet Draft Futurewei
Intended status: Informational Mehmet Toy Intended status: Informational Mehmet Toy
Expires: Aug 2019 Verizon Expires: January 8, 2020 Verizon
June 13, 2019 July 8, 2019
Segment routing for SD-WAN paths over hybrid networks Segment routing for SD-WAN paths over hybrid networks
draft-dunbar-sr-sdwan-over-hybrid-networks-04 draft-dunbar-sr-sdwan-over-hybrid-networks-05
Abstract Abstract
This document describes a method for end-to-end (E2E) SD-WAN paths This document describes a method for end-to-end (E2E) SD-WAN paths
to traverse specific list of network segments, some of which are to traverse specific list of underlay network segments, some of
private networks which include SR enabled segments, some of which which can be private networks which include SR enabled segments,
may be the public IP networks that do not support SR, to achieve the some of which can be the public IP networks that do not support SR,
desired optimal E2E quality. to achieve the desired optimal E2E quality.
The method described in this draft uses the principle of segment The method described in this draft uses the principle of segment
routing to enforce a SD-WAN path' head-end selected route traversing routing to enforce a SD-WAN path' head-end selected route traversing
through a list of specific nodes of multiple network segments through a list of specific nodes of multiple network segments
without requiring the nodes in each network segment to have the without requiring the nodes in each network segment to have the
intelligence (or maintaining states) of selecting next hop or next intelligence (or maintaining states) of selecting next hop or next
domain. domain.
Status of this Memo Status of this Memo
skipping to change at page 2, line 16 skipping to change at page 2, line 16
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 13, 2019. This Internet-Draft will expire on January 8, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
5. SD-WAN path over multiple SP managed domains..................16 5. SD-WAN path over multiple SP managed domains..................16
5.1. When Both SP domains support SR..........................18 5.1. When Both SP domains support SR..........................18
5.2. When SP-2 does not support SR............................18 5.2. When SP-2 does not support SR............................18
5.3. When SP-1 and SP-2 don't want to share network information19 5.3. When SP-1 and SP-2 don't want to share network information19
5.4. TLV to pass Metadata through SRv6 Domain.................19 5.4. TLV to pass Metadata through SRv6 Domain.................19
6. Security Considerations.......................................20 6. Security Considerations.......................................20
7. IANA Considerations...........................................21 7. IANA Considerations...........................................21
8. References....................................................21 8. References....................................................21
8.1. Normative References.....................................21 8.1. Normative References.....................................21
8.2. Informative References...................................21 8.2. Informative References...................................21
9. Acknowledgments...............................................22 9. Acknowledgments...............................................23
1. Introduction 1. Introduction
This document describes a method to enforce a SD-WAN path's head-end This document describes a method to enforce a SD-WAN path's head-end
selected route traversing through a list of specific nodes of selected route traversing through a list of specific nodes of
multiple network segments without requiring the nodes in each multiple network segments without requiring the nodes in each
network segments to have the intelligence (or maintaining states) of network segments to have the intelligence (or maintaining states) of
selecting next hop or next segments. Those networks over which the selecting next hop or next segments. Those networks over which the
SD-WAN path traverse have at least one SR enabled network, and some SD-WAN path traverse have at least one SR enabled network, and some
network segments (especially the last mile access portion) being network segments (especially the last mile access portion) being
existing IP networks (such as existing IPv4, IPv6 or others). existing IP networks (such as existing IPv4, IPv6 or others).
SD-WAN, as described by ONUG (Open Network User Group), is about SD-WAN, as described by ONUG (Open Network User Group) and [SDWAN-
pooling WAN bandwidth from multiple service providers to get better Net2Cloud], is about pooling WAN bandwidth from multiple service
WAN bandwidth management, visibility & control. providers to get better WAN bandwidth management, visibility &
control.
Throughout this document, the term "Classic SD-WAN" refers to a pair Throughout this document, the term "Classic SD-WAN" refers to a pair
of CPEs in two locations aggregating N Service Providers' paths, of CPEs in two locations aggregating N Service Providers' paths,
such as MPLS Paths and public internet paths. [SR-SD-WAN] describes such as MPLS Paths and public internet paths. [SR-SD-WAN] describes
using explicit routes within the SRv6 or SR-MPLS enabled networks to using explicit routes within the SRv6 or SR-MPLS enabled networks to
reach the desired quality for SD-WAN paths over the SRv6 or SR-MPLS reach the desired quality for SD-WAN paths over the SRv6 or SR-MPLS
enabled networks respectively. enabled networks respectively.
[SDWAN-Framework] describes three distinct SD-WAN scenarios from an [BGP-SDWAN-Usage] describes three distinct SD-WAN scenarios from an
edge node's perspective: edge node's perspective:
1) All traffic is encrypted over WAN ports, so that network 1) All traffic is encrypted over WAN ports, so that network
service providers can extend its existing VPN to reach sites only service providers can extend its existing VPN to reach sites only
reachable via third party untrusted networks (such as public reachable via third party untrusted networks (such as public
internet); internet);
2) Edge node has some ports connected to VPNs over which traffic 2) Edge node has some ports connected to VPNs over which traffic
can go natively without encryption and other ports to the public can go natively without encryption and other ports to the public
Internet over which traffic are encrypted; or Internet over which traffic are encrypted; or
skipping to change at page 4, line 24 skipping to change at page 4, line 24
3) VPN PEs adding Internet facing WAN ports to offload low 3) VPN PEs adding Internet facing WAN ports to offload low
priority traffic when the VPN backbone paths/links are congested. priority traffic when the VPN backbone paths/links are congested.
This document focuses on the scenario 1) above, where a SD-WAN path This document focuses on the scenario 1) above, where a SD-WAN path
is spanning over SR enabled networks and over public IP networks, is spanning over SR enabled networks and over public IP networks,
such as existing IPv4, LTE, etc. Under this scenario, the endpoints such as existing IPv4, LTE, etc. Under this scenario, the endpoints
of the SD-WAN path (e.g. the CPE devices, one or both) are not of the SD-WAN path (e.g. the CPE devices, one or both) are not
directly attached to PEs of a SR domain. directly attached to PEs of a SR domain.
The goal is to place as large portion as possible of the SD-WAN path The goal is to place as large portion as possible of the SD-WAN path
over a provider VPN to achive more optimal transport quality, or over a provider VPN to achieve more optimal transport quality, or
steering the SD-WAN path traversing specific ingress/egress PEs to steering the SD-WAN path traversing specific ingress/egress PEs to
reach optimal cost, quality, regulatory or other reasons. reach optimal cost, quality, regulatory or other reasons.
2. Definition of terms 2. Definition of terms
Cloud DC: Off-Premises Data Centers that usually host applications Cloud DC: Off-Premises Data Centers that usually host applications
and workload owned by different organizations or and workload owned by different organizations or
tenants. tenants.
Controller: Used interchangeably with SD-WAN controller to manage Controller: Used interchangeably with SD-WAN controller to manage
skipping to change at page 7, line 25 skipping to change at page 7, line 27
directly attached to the PEs of a SR Domain. directly attached to the PEs of a SR Domain.
3.3. How & Why SR is useful for those use cases 3.3. How & Why SR is useful for those use cases
Let us assume that the SD-WAN Controller is capable of computing Let us assume that the SD-WAN Controller is capable of computing
optimal paths between two end-points (e.g. E1<->E2 in the Figure 2), optimal paths between two end-points (e.g. E1<->E2 in the Figure 2),
either by communicating with the SR Domain controller/management- either by communicating with the SR Domain controller/management-
system, or by other methods which is out of the scope of this system, or by other methods which is out of the scope of this
document. document.
The SR domain must have a set of PEs that have at least one port When a SR domain has multiple PEs with ports facing the external
facing the external networks (such as the public internet or LTE networks (such as the public internet or LTE termination), SD-WAN
termination). paths can traverse the SR domain via different ingress/egress PEs
resulting in different E2E performance.
Under this circumstance, SD-WAN end-points usually can reach
multiple PEs.
In the diagram below, E1 <-> E2 SD-WAN (most likely IPsec encrypted In the diagram below, E1 <-> E2 SD-WAN (most likely IPsec encrypted
tunnel) path can traverse C1 <-> C4, C1<->C6, C3<->C6, or C3<->C4 tunnel) path can traverse C1 <-> C4, C1<->C6, C3<->C6, or C3<->C4
within the VPN. There are many flows (by different Apps) between E1 within the VPN. There are many flows (by different Apps) between E1
<-> E2. Some flows may need to traverse C1<->C4, others may need to <-> E2. Some flows may need to traverse C1<->C4, others may need to
traverse C3<->C6 or other segments within the VPN, which are traverse C3<->C6 or other segments within the VPN, which are
determined by the SD-WAN controller based on the characteristics & determined by the SD-WAN controller based on the characteristics &
need of the Apps, such as cost, available bandwidth, latency, or need of the Apps, such as cost, available bandwidth, latency, or
special functions only available at specific locations, etc. special functions only available at specific locations, etc.
skipping to change at page 22, line 36 skipping to change at page 22, line 36
April 2018. April 2018.
[MPLS-SR] A. Bashandy, et al, "Segment Routing with MPLS data [MPLS-SR] A. Bashandy, et al, "Segment Routing with MPLS data
plane", draft-ietf-spring-segment-routing-mpls-13, in plane", draft-ietf-spring-segment-routing-mpls-13, in
progress, April 2018. progress, April 2018.
[RFC7510] X. Xu, et al, "Encapsulating MPLS in UDP", April 2015. [RFC7510] X. Xu, et al, "Encapsulating MPLS in UDP", April 2015.
[RFC8086] L. Yong, et al, "GRE-in-UDP Encapsulation", March 2017. [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", [MEF-Cloud] "Cloud Services Architecture Technical Specification",
Work in progress, April 2018 Work in progress, April 2018
9. Acknowledgments 9. Acknowledgments
Many thanks to Dean Cheng and Jim Guichard for the discussion and Many thanks to Dean Cheng and Jim Guichard for the discussion and
contributions. contributions.
Authors' Addresses Authors' Addresses
 End of changes. 10 change blocks. 
20 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/