| Network Working Group | H. Tian |
| Internet-Draft | F. Zhao |
| Intended status: Informational | CAICT |
| Expires: September 7, 2020 | C. Xie |
| China Telecom | |
| T. Li | |
| J. Ma | |
| China Unicom | |
| S. Peng | |
| Z. Li | |
| Y. Xiao | |
| Huawei Technologies | |
| March 6, 2020 |
SRv6 Deployment Consideration
draft-tian-spring-srv6-deployment-consideration-01
SRv6 has significant advantages over SR-MPLS and has attracted more and more attention and interest from network operators and verticals. Smooth network migration towards SRv6 is a key focal point and this document provides network design and migration guidance and recommendations on solutions in various scenarios. Deployment cases with SRv6 are also introduced.
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 RFC 2119.
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 September 7, 2020.
Copyright (c) 2020 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.
SRv6 is the instantiation of Segment Routing deployed on the IPv6 data plane[RFC8200]. Therefore, in order to support SRv6, the network must first be enabled for IPv6. Over the past several years, IPv6 has been actively promoted all over the world, and the deployments of IPv6 have been ever-increasing which provides the basis for the deployments of SRv6.
With IPv6 as its data plane, for network migration towards SRv6, both software and hardware need to be upgraded. Compared with other new protocols, only IGP and BGP need to be extended to support SRv6, which significantly simplifies the software upgrade required. While the hardware needs to support the new SRv6 header SRH[I-D.ietf-6man-segment-routing-header], the design of SRv6 assures compatibility with the existing IPv6 network as an SRv6 SID is designed as a 128-bit IPv6 address and the encapsulation of an SRv6 packet is the same as an IPv6 packet. When only L3VPN over SRv6 BE (Best-Effort) is deployed, there will be no SRH. Therefore, no additional hardware capabilities are required but only software upgrade for protocol extensions.
As the number of services supported by SRv6 increase, e.g. SFC, network slicing, iOAM etc., more SIDs in the SRH may impose new requirements on the hardware. Besides upgrading the hardware, various solutions [I-D.peng-spring-srv6-compatibility] have already been proposed to relieve the imposed pressure on the hardware, such as Binding SID (BSID) etc. to guarantee the compatibility with the existing network. On the other hand SRv6 has many more advantages over SR-MPLS for the network migration to support new services.
This document summarizes the advantages of SRv6 and provides network migration guidance and recommendations on solutions in various scenarios.
Compared with SR-MPLS, SRv6 has significant advantages especially in large scale networking scenarios.
The increasing complexity of service deployment is of concern for network operators, especially in large-scale networking scenarios. With solutions such as multi-segment PW and Option A [RFC4364], the number of service-touch points has increased, and the services, with associated OAM features cannot be deployed end-to-end.
/------Metro------\ /----Core----\ /------Metro-------\
LB PE1 ASBR ASBR PE2 LB
1.1.1.1 2.2.2.2
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|A | |B | |ER| | | |PE| | | |PE| | | |ER| |B | |A |
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
SR-LSP SR-LSP SR-LSP SR-LSP SR-LSP
|<--->|<---------->| |<--------->| |<--------->|<--->|
BGP-LSP
|<---------------------------------------------------------->|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+IP + +IP + +IP + +IP + +IP + +IP + +IP + +IP + +IP +
+ETH+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +ETH+
+---+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +---+
+SR + +SR + +ETH+ +SR + +ETH+ +SR + +SR +
+ETH+ +ETH+ +---+ +ETH+ +---+ +ETH+ +ETH+
+---+ +---+ +---+ +---+ +---+
(a) SR-MPLS
/------Metro------\ /----Core----\ /------Metro-------\
LOC PE1 ASBR ASBR PE2 LOC
A1::100:: A2::200::
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|A | |B | |ER| | | |PE| | | |PE| | | |ER| |B | |A |
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
\_____A1::/80____/ \__A0::/80__/ \____A2::/80____/
Aggregated Route Aggregated Route Aggregated Route
+---+ +----------+ +----------+ +----------+ +---+
+IP + + IP + + IP + + IP + +IP +
+ETH + +w./wo.SRH + +w./wo.SRH + +w./wo.SRH + +ETH+
+---+ + ETH + + ETH + + ETH + +---+
+----------+ +----------+ +----------+
(b) SRv6
Figure 1. Large-scale Networking with (a) SR-MPLS vs. (b) SRv6
In the SR cross-domain scenario, in order to set up end-to-end SR tunnels, the SIDs in each domain need to be imported to other domains.
The MPLS label itself does not hold any reachability information, so it must be attached to a routable address, which means that the matching relationship between the label and FEC needs to be maintained along the path.
SR-MPLS uses the MPLS data plane. When the network migrates to SR-MPLS, there are two ways, as shown in Figure 2:
Regardless of which migration option is chosen, big changes in a wide area is required at the initial stage therefore causing a long time-to-market.
In contrast, the network can be migrated to SRv6 on demand. Wherever the services need to be turned on, only the relevant devices need to be upgraded to enable SRv6, and all other devices only need to support IPv6 forwarding and need not be aware of SRv6. When Traffic Engineering (TE) services are needed, only the key nodes along the path need to be upgraded to support SRv6.
(~~~~~~MPLS/SR-MPLS~~~~~~~)
( +---+ +---+ +---+ )
MPLS Migration Options Option 1 ( |SM | |SM | |SM | )
--->( +---+ +---+ +---+ )
/ ( +---+ +---+ +---+ )
(~~~~~~~~~~MPLS~~~~~~~~~~~) / ( |SM | |SM | |SM | )
( +---+ +---+ +---+ ) / ( +---+ +---+ +---+ )
( | M | | M | | M | ) / ~~~~~~~~~~~~~~~~~~~~~~~~~~
( +---+ +---+ +---+ ) \
( +---+ +---+ +---+ ) \ (~~MPLS~~|~~~~~SR-MPLS~~~~~)
( | M | | M | | M | ) \ ( +---+ | +---+ +---+ )
( +---+ +---+ +---+ ) \ ( | M | | |SM | |SM | )
~~~~~~~~~~~~~~~~~~~~~~~~~~ --->( +---+ | +---+ +---+ )
Option 2 ( +---+ | +---+ +---+ )
( | M | | |SM | |SM | )
( +---+ | +---+ +---+ )
~~~~~~~~~~~~~~~~~~~~~~~~~~
SRv6 Migration
(~~~~~~~~~~MPLS~~~~~~~~~~~) (~~~~~~SRv6 on demand~~~~~)
( +---+ +---+ +---+ ) ( +---+ +---+ +---+ )
( | M | | M | | M | ) ( |S6 | | M | | M | )
( +---+ +---+ +---+ ) ----------> ( +---+ +---+ +---+ )
( +---+ +---+ +---+ ) ( +---+ +---+ +---+ )
( | M | | M | | M | ) ( | M | | M | |S6 | )
( +---+ +---+ +---+ ) ( +---+ +---+ +---+ )
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
Figure 2. MPLS Domain Migration vs. SRv6 On-Demand Upgrade
With SRv6, the service deployment can be significantly simplified in some scenarios.
When the customer of the VPN service carrier (Provider Carrier) is itself a VPN service carrier (Customer Carrier), it becomes the scenario of Carrier's Carrier. For this scenario, with SRv6, the service deployment can be significantly simplified.
To achieve better scalability, the CEs of the Provider Carrier (i.e. the PEs of the Customer Carriers) only distribute the internal network routes to the PEs of the Provider Carrier. The customers' routes of the Customer Carriers (i.e. from CE3 and CE4) will not be distributed into the network of the Provide Carrier. Therefore, LDP or Labeled BGP will be run between the CEs of the Provider Carrier (i.e. CE1 and CE2 in the Figure 3) and the PEs of the Provider Carrier (i.e. PE1 and PE2 in the Figure 3), and LDP will be run between the CEs of the Provider Carrier (i.e. the PEs of the Customer Carriers) and the PEs of the Customer Carrier (i.e. PE3 and PE4 in the Figure 3). MP-BGP will be run between the PEs of the Customer Carrier. The overall service deployment is very complex.
If SRv6 is deployed by the Customer Carrier and the Provider Carrier, no LDP will be ever needed. The Locator routes and Loopback routes of the Customer Carriers can be distributed into the network of the Provider Carrier via BGP, and within each carrier's network only IGP is needed. The end-to-end VPN services can be provided just based on the IPv6 interconnections, and the customer carrier is just like a normal CE to the provider carrier, which significantly simplified the VPN service deployment.
Customer Carrier Provider Carrier Customer Carrier
/------------\ /-------------\ /-----------\
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE3|--|PE3| |CE1|--|PE1| |PE2|--|CE2| |PE4|--|CE4|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
MPLS IGP/LDP IGP/LDP MP-IBGP IGP/LDP IGP/LDP
or Labeled BGP or Labeled BGP
SR-MPLS IGP Labeled BGP MP-IBGP Labeled BGP IGP
SRv6 IGP BGP MP-IBGP BGP IGP
|<--------->||<---->||<---------->||<--->||<--------->|
MP-IBGP
|<--------------------------------------------------->|
Figure 3. Service deployment with MPLS, SR-MPLS and SRv6
In a MPLS network, generally RSVP-TE is deployed in the P nodes of the network, and LDP is running between these P nodes and the PE nodes. Customers access to VPN services via the PE nodes. This scenario is called LDP over TE, which is a typical deployment for carriers who want to achieve the TE capability over MPLS network while keep scalability. However, such network configuration and service deployment are very complex.
With SRv6 which can provide both TE capability and IP reachability, the service deployment can be significantly simplified. Only IGP and BGP are needed in the network to launch VPN services.
+---+ +---+ +---+ +---+ +---+ +---+
|CE1|---------|PE1|------|P1 |\-------/|P2 |------|PE2|--------|CE2|
+---+ +---+ +---+ \ / +---+ +---+ +---+
/
+---+ +---+ +---+ / \ +---+ +---+ +---+
|CE3|---------|PE3|------|P3 |/-------\|P4 |------|PE4|--------|CE4|
+---+ +---+ +---+ +---+ +---+ +---+
MPLS LDP RSVP-TE LDP
SR-MPLS IGP (SR-MPLS)
SRv6 IGP (SRv6)
|<-------->|<------------>|<------->|
MP-BGP
|<--------------------------------->|
Figure 4. Service deployment with (a) MPLS/SR-MPLS vs. (b) SRv6
Address Planning is a very important factor for s successful network design, especially an IPv6 network, which will directly affect the design of routing, tunnel, and security. A good address plan can bring big benefit for service deployment and network operation.
If a network has already deployed IPv6 and set up IPv6 subnets, one of the subnets can be selected for the SRv6 Locator planning, and the existing IPv6 address plan will not be impacted.
If a network has not yet deployed IPv6 and there has not been an address plan, it needs to perform the IPv6 address planning first taking the following steps,
For an SRv6 network, in the first step for IPv6 address planning, the following principles are suggested to follow,
Considering the above-mentioned IPv6 address planning principles, it has been adopted in some deployment cases to set Locator length 96bits, function length 20bits, and args 12bits.
When Locator is imported in ISIS, the system will automatically assign END SID with Flavors such as PSP (Penultimate Segment Pop) and distribute the Locator subnet route through ISIS.
The Flavor PSP, that is, SRH is popped at penultimate segment, provides the following benefits,
Incremental deployment is the key for a smooth network migration to SRv6. In order to quickly launch SRv6 network services and enjoy the benefits brought by SRv6, the recommended incremental SRv6 deployment steps are given as follows. These are based on practical deployment experience earned from the use cases described in [I-D.matsushima-spring-srv6-deployment-status].
The referenced network topology is shown in Figure 5.
/---- Path 1 ----\
+------+ +----+ +---/--+ +---\--+ +----+ +------+
|Site 1|----|PE 1|----|ASBR 1| IP Core |ASBR 2|----|PE 2|----|Site 2|
+------+ +----+ +---\--+ +---/--+ +----+ +------+
\---- Path 2 ----/
Figure 5. Reference Network Topology
Step1. All the network devices are upgraded to support IPv6.
Step 2. According to service demands, only a set of selected PE devices are upgraded to support SRv6 in order to immediately deploy SRv6 overlay VPN services. For instance, in Figure 3, PE1 and PE2 are SRv6-enabled.
Step 3. Besides the PE devices, some P devices are upgraded to support SRv6 in order to deploy loose TE which enables network path adjustment and optimization. SFC is also a possible service provided by upgrading some of the network devices.
Step 4. All the network devices are upgraded to support SRv6. In this case, it is now possible to deploy strict TE, which enables the deterministic networking and other strict security inspection.
As the network migration to SRv6 is progressing, in most cases SRv6-based services and SR-MPLS-based services will coexist.
As shown in Figure 6, in the Non-Standalone (NSA) case specified by 3GPP Release 15, 5G networks will be supported by existing 4G infrastructure. 4G eNB connects to CSG 2, 5G gNB connects to CSG 1, and EPC connects to RSG 1.
To support the 4G services, network services need to be provided between CSG 2 and RSG 1 for interconnecting 4G eNB and EPC, while for the 5G services, network services need to be deployed between CSG 1 and RSG 1 for interconnecting 5G gNB and EPC. Meanwhile, to support X2 interface between the eNB and gNB, network services also need to be deployed between the CSG 1 and CSG 2.
+-----+
| eNB |------\
+-----+ \
+-----+
|CSG 2|-------+-----+ +-----+ +-----+
/+-----+ |ASG 1|-------------|RSG 1|------| EPC |
+-----+ +--/--+ +-----+ +-----+ +-----+
| gNB |-----|CSG 1| Domain 1 | Domain 2 |
+-----+ +--\--+ +-----+ +-----+
\+-----+ |ASG 2|-------------|RSG 2|
|CSG 3|-------+-----+ +-----+
+-----+
Figure 6. A 3GPP Non-Standalone deployment case
When 5G services are to be supported, more stringent network services are required, e.g. low latency and high bandwidth. SRv6-based network services could be deployed between CSG 1 and RSG 1 for interconnecting 5G gNB and EPC.
In order to perform smooth network migration, a dual-stack solution can be adopted which deploys both SRv6 and MPLS stack in one node.
With the dual-stack solution, only CSG 1 and RSG 1 need to be upgraded with SRv6/MPLS dual stack. In this case, CSG 1 can immediately start SRv6-based network services to RSG 1 for support of 5G services, but continue to use MPLS-based services to CSG 2 for X2 interface communications. The upgrade at CSG 1 will not affect the existing 4G services supported by the MPLS-based network services between CSG 2 and RSG 1. RSG1 can provide MPLS services to CSG2 for 4G services as well as SRv6 services to CSG 1 for 5G services.
With the current network, the launch of leased line service is slow, the network operation and maintainence is complex, and the configuration points are many. SRv6 can solve the issues above. There have already been several successful SRv6 deployments following the incremental deployment guidance shown in Section 3.
China Telecom Si'chuan (Si'chuan Telecom) has enabled SRv6 at the PE node of the Magic-Mirror DC in Mei'shan, Cheng'du, Pan'zhihua and other cities. The SRv6 BE tunnel has been deployed through the 163 backbone network which has the IPv6 capability. It enables the fast launch of the Magic-Mirror video service, the interconnection of the DCs in various cities, and the isolation of video services. The deployment case is shown in Figure 7.
/---------163--------\
+------+ / \ +-------+
| Magic| +----+ +--/-+ +--\-+ +----+ | Magic |
|Mirror|----|PE 1|----|CR 1| IP Backbone |CR 2|----|PE 2|----|Mirror |
| DC 1 | +----+ +--\-+ +--/-+ +----+ | DC 2 |
+------+ \ / +-------+
+-\---+ +---/-+
|ASBR1|----CN2-----|ASBR2|
+-----+ +-----+
IGP/IBGP EBGP IGP/IBGP
|<------->|<-------------------------->|<-------->|
EBGP VPNv4 Peer
|<----------------------------------------------->|
L3VPN over SRv6
|<----------------------------------------------->|
Figure 7. China Telecom Si'chuan deployment case
The packet enters the SRv6 BE tunnel from the egress PE of DC, and the packet is forwarded according to the Native IP of the 163 backbone network. When the packet reaches the peer PE, the SRH is decapsulated, and then the IP packet is forwarded in the VRF according to the service SID (for example, End.DT4).
In order to further implement the path selection, ASBRs can be upgraded to support SRv6. Different SRv6 policies are configured on the DC egress PE so that different VPN traffic reaches the peer PE through the 163 backbone network and the CN2 backbone network respectively.
/-------------\ /------------\ /-----------\
+-/-+ Guangzhou +-\-+ +-/-+ IPv6 +-\-+ +-/-+ Beijing +-\-+
|PE1| |CR1|---|CR2| Backbone |CR3|---|CR4| |PE2|
+-\-+ Metro +-/-+ +-\-+ 169 +-/-+ +-\-+ Metro +-/-+
\-------------/ \------------/ \-----------/
|<--OSPF/ISIS-->|<-EBGP->|<-Native IPv6->|<-EBGP->|<-OSPF/ISIS->|
|<----------------------- EBGP VPNv4 Peer --------------------->|
|<----------------------- L3VPN over SRv6 --------------------->|
Figure 8. China Unicom SRv6 L3VPN case
China Unicom has deployed SRv6 L3VPN over 169 IPv6 backbone network from Guangzhou to Beijing to provide inter-domain Cloud VPN service. The deployment case is shown in Figure 8.
PE1 and PE2 establish EBGP peer and advertise VPNv4 routes with each other. If one site connects to two PEs, metro network will use multi RD, community and local preference rules to choose one best route and one backup.
After basic routing among networks and VPN routes between the two PEs are all ready, two PEs encapsulate and forward VPN traffic within SRv6 tunnel. The tunnel is SRv6 best effort (BE) tunnel. It introduces only outer IPv6 header but not SRH header into traffic packets. After encapsulation, the packet is treated as common IPv6 packet and forwarded to the egress PE, which performs decapsulation and forwards the VPN traffic according to specific VRF.
Guangdong Unicom has also lauched the SRv6 L3VPN among Guangzhou, Shenzhen, and Dongguan, which has passed the interop test between different vendors.
With SRv6 enabled at the PE devices, the VPN service can be launched very quickly without impact on the existing traffic. With SRv6 TE further deployed, more benefits of using SRv6 can be exploited.
There are no IANA considerations in this document.
TBD.
The section on the PSP use cases is inspired from the discussions over the mailing list. The authors would like to acknowledge the constructive discussions from Daniel Voyer, Jingrong Xie, etc..
Hailong Bai China Unicom China
Email:
Jichun Ma China Unicom China
Email:
Huizhi Wen Huawei China
Email: wenhuizhi@huawei.com
Ruizhao Hu Huawei China
Email: huruizhao@huawei.com
Jianwei Mao Huawei China
Email: maojianwei@huawei.com
| [I-D.ietf-6man-segment-routing-header] | Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S. and D. Voyer, "IPv6 Segment Routing Header (SRH)", Internet-Draft draft-ietf-6man-segment-routing-header-26, October 2019. |
| [I-D.ietf-spring-srv6-network-programming] | Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-ietf-spring-srv6-network-programming-12, March 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4364] | Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006. |
| [RFC5659] | Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, DOI 10.17487/RFC5659, October 2009. |
| [RFC8200] | Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017. |
| [I-D.matsushima-spring-srv6-deployment-status] | Matsushima, S., Filsfils, C., Ali, Z. and Z. Li, "SRv6 Implementation and Deployment Status", Internet-Draft draft-matsushima-spring-srv6-deployment-status-05, January 2020. |
| [I-D.peng-spring-srv6-compatibility] | Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li, Z. and J. Guichard, "SRv6 Compatibility with Legacy Devices", Internet-Draft draft-peng-spring-srv6-compatibility-02, January 2020. |