| Network Working Group | D. Dukes, Ed. |
| Internet-Draft | C. Filsfils |
| Intended status: Standards Track | Cisco Systems |
| Expires: December 7, 2018 | G. Dawra |
| X. Xu | |
| Alibaba | |
| D. Voyer | |
| Bell Canada | |
| P. Camarillo | |
| F. Clad | |
| Cisco Systems | |
| S. Salsano | |
| Univ. of Rome Tor Vergata | |
| June 5, 2018 |
SR For SDWAN: VPN with Underlay SLA
draft-dukes-spring-sr-for-sdwan-00
This document describes how SR enables underlay Service Level Agreements (SLA) to a VPN with scale and security while ensuring service opacity. This solution applies to Over-The-Top VPN (OTT VPN) and Software-Defined WAN (SDWAN).
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 7, 2018.
Copyright (c) 2018 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 (https://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.
This document describes how SR enables underlay SLA to a VPN with scale and security while ensuring service opacity. This solution applies to Over-The-Top VPN (OTT VPN) with SLA differentiation, and Software-Defined WAN (SDWAN) with SLA differentiation.
The body of this text uses SRv6 for illustration. A similar solution leveraging SR-MPLS is illustrated in an appendix.
This document assumes familiarity with the following IETF documents:
For clarity, this version of the document uses the SDWAN example with SRv6 to illustrate how SR can be used to provide underlay SLA to overlay services. The journey of a packet from the left site to the right site of the SDWAN Overlay is described. The solution applies similarly for the return path.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
+------------+ /-----------/
| SDWAN | / /
| Control | / [SDWAN-C]...
+------------+ / / :
/-----------/ :
:
/-------------------------------------------/ :
+---------+ / / :
| SDWAN | / [A]-----[E1]***********[E2]--------[Z] / :
| Overlay | / : : / :
+---------+/ :...... : / :
/-----------------------:--------:----------/ :
: : :
: : :
/----------/ : : :
+------------+ / / : : :
| SP | / [SR-C] / : : :
| Control | / : / : : :
+------------+ /------:---/ ....: .. :
: : : :
: : : :
+------------+ : /---:-------------:-------------/ :
| SP | : / : : / :
| Underlay | : / [C1]----------[C2] / :
+------------+ :/ \ / / :
: \ /--/ / :
/: \ / / :
/ :...........[C3]..........................:
/ /
/-------------------------------/
**** = logical connection
:... = physical connection, between layers
/--\ = physical connection, within a layer
Figure 1: SDWAN Reference Diagram
An SDWAN overlay is composed of two sites A and Z, connected to the Internet via edge nodes E1 and E2 respectively. E1 and E2 (customer edge nodes) are connected via a Service Provider (SP) underlay to form the VPN between the sites.
C1, C2 and C3 are nodes of the SP underlay, where C1 and C2 are Provider Edge nodes. ISIS is deployed in the SP underlay with the same cost on each link.
E1 and E2 connect to C1 and C2 respectively. The shortest path from C1 to C2 is the best-effort path. The explicit path C1-C3-C2 is the low-latency path. By default, traffic transported from C1 to C2 follows the best-effort path. By default, an SDWAN cannot benefit from the low-latency path from C1 to C2.
The address of A is 10.10.0.10/32 and the address of Z is 10.26.0.26/32. E1 and E2 respectively advertise 10.10/16 and 10.26/16 to the SDWAN controller SDWAN-C via a secure channel over the Internet. The solution is applicable to any traffic exchanged between the sites, including IPv4, IPv6 or L2. For clarity, a single example with IPv4 in the SDWAN Overlay is used.
The SP operates an SR controller SR-C capable of computing constrained paths from C1 to C2.
Let’s consider the path taken by traffic from A to Z, across the SDWAN, between nodes E1 and E2 with addresses E1:: and E2:: respectively.
Host A sends a packet P to Z via E1. Packet P has source address 10.10.0.10 and destination address 10.26.0.26, illustrated as P (10.10.0.10,10.26.0.26)(payload). E1, upon receipt of P, determines E2 is the edge node to be used to reach Z. Edge node E1 encrypts, encapsulates and forwards the packet P toward E2 and Z, and it is handled as follow:
This example illustrates that, classically (i.e., without the SR solution described in this document), the SDWAN cannot leverage the rich infrastructure of the SP to meet its needs. The SP is constrained to offer best-effort transit which does not reflect the capabilities of its infrastructure.
SR enables the SDWAN to steer selected flows through selected transport paths of the SP, using the same example in Figure 1.
This small example, with only 3 SP routers, assumes all three support SRv6. As explained in [I-D.filsfils-spring-srv6-network-programming], a typical deployment would only require SRv6 at a few strategic waypoints deployed through the network.
It also assumes ISIS supports the lightweight SRv6 extension described in [I-D.bashandy-isis-srv6-extensions].
The illustration convention from [I-D.filsfils-spring-srv6-network-programming] is used such that:
The Control-Plane (CP) workflow that leads to the instantiation of this Binding SID will be explained in the Control-Plane section.
Let’s again consider the path from A to Z for a packet P, but this time E1 has been configured by SDWAN-C to steer packet P into a preferred low-latency path of the SP bound to the binding SID C1:B21.
When the Binding SID C1::B21 is processed at C1, the SR TE Policy is selected and the SRH for SID list <C3::,C2::> is inserted into P:
At C3, the SegmentsLeft is decremented as the END SID C3:: is processed, and C2:: is placed in the destination address:
At C2, the SegmentsLeft is decremented to 0, and penultimate segment pop is applied as the END SID C2:: is processed and E2:: is placed in the destination address while the SRH is removed:
Finally, E2 decrypts the packet and strips the outer header to forward the original packet to Z:
The SDWAN edge nodes (E1,E2) maintain their existing behavior of
The only change is that the Ingress node now monitors and selects an SRv6 binding SID then pushes an SRH with two SIDs.
Note as well that the ingress and egress edge nodes never see the actual SID list used by the SP to deliver the preferred path. A variation of this design allows for the BSID to be kept in the packet so that the egress node can detect which packets have been steered on which preferred path (for accounting or monitoring purposes).
This is a fairly simple example of how SRv6 binding SIDs and SR TE policies may be used to provide multiple diverse paths for SDWAN traffic traversing a single provider network.
As per SRv6 network programming [I-D.filsfils-spring-srv6-network-programming], each SRTE policy and its bound BSID is associated with a unique traffic counter. This allows the SP to implement various forms of billing and reporting to the customer of the preferred path.
The domain of trust security solution documented in [I-D.filsfils-spring-srv6-network-programming] is utilized.
Specifically SEC1, SEC2 and SEC3 guarantee that external traffic to the SP cannot exercise the SID’s of the SP.
The following behavior is added: the ACL implementing SEC1 and SEC2 on node C1 is updated to specifically allow traffic from E1:: to C1::B21.
Only the SDWAN edge that has ordered the preferential service can use it.
Any other customer of the SP is unable to use the preferential path bound to BSID C1::B21.
The SDWAN site that has ordered the preferential service is unable to directly program the network of the SP using the internal SID’s of the SP. The SDWAN edge node is restricted to the BSID, which opacifies the SP operation.
Well known authentication technology with details provided in subsequent revisions will be added, detailing the scenario with SDWAN edge nodes not directly connected to the SP node terminating the binding SID.
Well known authentication technology with details provided in subsequent revisions will be added, detailing the scenario with SDWAN edge nodes connected to the SP node offering binding SID via an intermediate SP.
The SDWAN overlay in Figure 1 is managed by an SDWAN controller, SDWAN-C.
The control protocols used by the SDWAN-C to signal the site routes, the BSID’s and the site policies (which traffic on which BSID when) securely over the SP network to E1 and E2 is outside the scope of this document.
The SP underlay operates its internal SR deployment with an SR controller (SR-C). SR-C interacts with the SP’s network (Cj) through standardized protocols (PCE[RFC4674] , PCEP [RFC5440]/[RFC4657], BGP RR[RFC4456], BGP-TE [I-D.ietf-idr-segment-routing-te-policy], BGP-LS [RFC7752])
Most likely, the SP would operate its underlay SLA service with a service controller (SERV-C) that is separate from SR-C. To simplify the illustration, this text assumes that SERV-C and SR-C are integrated.
This section describes the high-level interaction between these controllers for the low-latency use-case described in this document, where an enterprise operator installs a policy in the SDWAN-C requiring a low latency service between E1 and E2.
+----------+
|Enterprise|
| Operator |
+----------+
+---+ | +----------+ +-------+ +---+
|E1 | | | SDWAN-C | | SR-C | |C1 |
+---+ | +----------+ +-------+ +---+
| | | | |
| |-------i----->| | |
| |Require low | | |
| |latency from | | |
| |E1 to E2 for | | |
| |some traffic | | |
| | +------ii----> |
| | request service |----+ |
| | from E1:: to | iii |
| | E2:: for low |<---+ |
| | latency |Compute an SR|
| | | |Policy for E1|
| | |to E2 |
| | | |
| | |-----iv----->|
| | | Program SR TE
| | | Policy |
| | | |
| | |<-----v------+
| |<----vi-----| Report policy
| |reply with | installed |
| |binding SID | |
|<-------vii----------|C1:B21::
| Notify |
| SID C1:B21:: |
| for low latency
| E1:: to E2::
|
Figure 2: Controlplane Flow
The SP network does not hold any per-SDWAN-flow state in the core of its network.
The SP network does not hold any complex L3-L7 flow classification at the edge of its network.
The SP network is unaware of any policy change of the SDWAN instance either in terms of which flow to classify, when to steer it and on which path.
The SP’s role only consists in statefully maintaining SRTE policies at the edge of the network and maintaining a few 100’s of SID’s inside its core network. This is the stateless property of Segment Routing.
The SP network does not share any information of its infrastructure, topology, capacity, internal SID’s.
The SDWAN instance does not share any information on its traffic classification, steering policy and business logic.
The traffic destined to a BSID is individually accounted [I-D.filsfils-spring-srv6-network-programming].
The SP and SDWAN instance can agree on various forms of billing for the usage of the preferential path.
By default, the SP’s SR infrastructure is protected by the simple domain of trust solution documented in [I-D.filsfils-spring-srv6-network-programming].
A BSID (and the related preferential path) can only be accessed by the specific SDWAN instance (and site) that ordered the service.
The security solution supports any SDWAN site connection type: directly connected to the SP edge or not.
Reusing the example from Section 3.3, with an SP core that supports SR MPLS as defined in [I-D.ietf-spring-segment-routing-mpls]. Each node C1, C2 and C3 have node-SIDs defined, resulting in labels 16001, 16002, and 16003 respectively. In such a case a packet from A to Z has an SRv6 binding SID applied, associated with an SR policy at node C1. Node C1 translates the binding SID to an MPLS label stack which is pushed on the packet.
For example:
Let’s again consider the path from A to Z for a packet P where E1 has been configured by SDWAN-C to steer packet P into a preferred low-latency path of the SP bound to the binding SID C1::B22.
When the Binding SID C1::B22 is processed at C1, the SR TE Policy is selected and the label stack for SID list <16003,16002> is pushed on P. In practice 16003 is not pushed on the wire since it has been distributed with PHP:
At C3, 16002 is popped and PHP requires no new label be pushed as P is forwarded via the link to C2:
At C2, there is no more label stack so it forwards E2:: using the global IPv6 table toward E2:
Finally, E2 decrypts the packet and strips the outer header to forward the original packet to Z:
Again the only change is that the Ingress node now selects an MPLS binding SID for traffic taking the lowest latency path. The Ingress node has no knowledge of the SP underlay.
As defined in Section 3.4
The SRv6 SID is secured as defined in Section 3.5
MPLS is not enabled on the CE-to-PE link.
To be completed in future revisions
Reusing the example from Section 3.3, with an SP core that supports the SR MPLS extensions defined in [I-D.ietf-isis-segment-routing-extensions]. Each node C1, C2 and C3 have node-SIDs defined, resulting in labels 16001, 16002, and 16003 respectively.
Let’s again consider the path from A to Z for a packet P, but this time E1 has been configured by SDWAN-C to steer packet P into a preferred low-latency path of the SP bound to an MPLS binding SID.
For example:
Let’s again consider the path from A to Z for a packet P where E1 has been configured by SDWAN-C to steer packet P into a preferred low-latency path of the SP bound to the binding SID 24102.
When C1 receives P, it decapsulates the UDP header and pops the Binding SID 24102, the SR TE Policy is selected and the label stack for SID list <16003,16002> is pushed on P. In practice, 16003 is not pushed on the wire since it has been distributed with PHP.
The remainder of this use case is identical to Section 7.1. The only change is that the Ingress node now uses an MPLS binding SID transported over UDP instead of an SRv6 binding SID, allowing the use of an IPv6 or IPv4 transport from CE to PE.
As defined in Section 3.4
[RFC7510] defines the use of DTLS to authenticate and encrypt the MPLS in UDP encapsulation between CE and PE. The authentication ensures the source is authorized to send traffic to a binding SID.
After the source is verified as authorized, the source address and Binding SID SHOULD be checked to determine if the source is permitted to use the specific Binding SID in the MPLS label.
MPLS is not enabled on the CE-to-PE link.
No current considerations.
A domain of trust is secured via methods documented in [I-D.filsfils-spring-srv6-network-programming]
| [I-D.filsfils-spring-srv6-network-programming] | Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P. and M. Sharif, "SRv6 Network Programming", Internet-Draft draft-filsfils-spring-srv6-network-programming-04, March 2018. |