Get File Stream

MPLS-to-SRv6
Evolution Guide
Authors : Fenghai Guo, Yan Liu
Copyright
Authors: Fenghai Guo, Yan Liu
Key Contributors: Lanjun Luo, Wei Shao, Menghuan Chen, Aishan Zhou
Release Date: 2022-12-16
Issue: 01
Copyright © Huawei Technologies Co., Ltd. 2022. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and
recommendations in this document are provided "AS IS" without warranties, guarantees or representations of
any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Preface
Author Introduction
Fenghai Guo: Senior engineer of Huawei's Information Digitalization and
Experience Assurance (IDEA) Department, DC. After joining Huawei in 2011, he
has been engaged in working on technical documentation for key features of
datacom products for a long time, and has developed multiple eBooks such as
EVPN.
Yan Liu: Engineer of Huawei's IDEA Department, DC. After joining Huawei in
2016, she has been engaged in working on technical documentation for Huawei
routers, and has produced a series of SRv6-related technical videos named IP
New Technology Series (Advanced).
About This Book

This book begins with a brief introduction to the evolution from MPLS to SRv6,
and then describes the background, inevitable trend, and value of the evolution.
In Chapter 3, it briefly analyzes the available paths for the evolution from MPLS
to SRv6. Then, Chapters 4 and 5 detail the specific strategies for different
i
Preface
evolution paths. After that, Chapter 6 provides examples for the detailed solution
design of the recommended direct evolution path. Finally, Chapter 7 introduces
some extended applications for SRv6 networks. Understanding these contents
helps you understand the strategies, solutions, and applications for the evolution
from MPLS to SRv6 in a more comprehensive and in-depth manner.
Intended Audience
This book is intended for network planning engineers, network design engineers,
mid- and senior-level managers at service providers and enterprises, and readers
who want to understand cutting-edge IP network technologies.
Symbol Conventions
Supplements important information in the main text. Note is
used to address information not related to personal injury, equipment damage,
or environment deterioration.
Indicates a low-risk hazard that, if not avoided, could result in

minor or moderate injury.
ii
Preface
Acknowledgments
In writing and publishing this book, we received extensive help and support from
both inside and outside Huawei. We sincerely thank Meng Zuo, Zhigang Wang,
Zhenbin Li, Yanmiao Wang, Zhaokun Ding, Keyi Zhu, Chenxi Wang, Wenjun
Meng, Tao Han, Hongkun Li, Yue Liu, and other leaders and experts from
Huawei Data Communication Product Line for their guidance and support. This
book focuses on subject matters that are still evolving and deepening. While we
have made significant efforts to ensure accuracy, there might be omissions or
deficiencies in the book. Your comments and feedback are warmly welcomed.
i
Preface
Table of Contents
Chapter 1 Overview of Network Evolution from MPLS to SRv6 ............................ 1
Chapter 2 Background of Network Evolution from MPLS to SRv6 ....................... 2
2.1 Challenges Facing MPLS Networks ...............................................................3
2.2 MPLS Network Evolution Direction ...............................................................5
Chapter 3 Evolution from MPLS to SRv6 ................................................................... 12
Chapter 4 Strategies for Indirect Evolution .............................................................. 16
4.1 Strategies for the Evolution from MPLS to SR-MPLS .......................... 16
4.2 Strategies for the Evolution from SR-MPLS to SRv6 ........................... 22
Chapter 5 Strategies for Direct Evolution ................................................................. 26
5.1 SRv6 and MPLS Coexistence Strategy ....................................................... 27
5.2 SRv6 and MPLS Interworking Strategy ..................................................... 33
Chapter 6 Solution Design for SRv6-oriented Direct Evolution ........................... 35
6.1 Design for Protocol Layer Evolution .......................................................... 35
6.2 Design for Service Layer Evolution ............................................................. 43
Chapter 7 Summary and Outlook ............................................................................... 52
ii
Table of Contents
Chapter 1
Overview of Network
Evolution from MPLS to SRv6
Since its inception in 1996, Multiprotocol Label Switching (MPLS) has been
widely deployed on IPv4 backbone networks, metropolitan area networks
(MANs), mobile transport networks, and many other networks after nearly 30
years of development However, no technology can stay in the center of the stage
forever, and MPLS is no exception. With the gradual popularization of IPv6,
services such as 5G and cloud services develop rapidly, imposing urgent
requirements for the upgrade and reconstruction of traditional IPv4/MPLS
networks deployed by carriers and enterprise users. In addition, to meet the
higher requirements of 5G and cloud services on networks, MPLS inevitably
needs to continuously evolve.
So, what will MPLS evolve to? Segment Routing over IPv6 (SRv6) stands out with
many advantages, such as protocol simplification, high compatibility, and
network programmability, becoming the next-generation IP transport technology
that is most likely to replace MPLS. Of course, network technology updates do
not occur overnight. It is a gradual evolutionary process. During this process,
various evolution paths and implementation strategies emerge, each with its
own advantages and disadvantages. Carriers and enterprise users can select
appropriate solutions based on their own service status and network conditions
to smoothly upgrade their networks.
1
Overview of Network Evolution from MPLS to SRv6
Chapter 2
Background of Network
IP networks have developed from the Internet era represented by IPv4 to the all-
IP era represented by MPLS, and are gradually entering the intelligent
connectivity era oriented to 5G and cloud services.
In the intelligence era, connectivity of everything is evolving towards intelligent

connectivity of everything. During the evolution, the connection objects become
more intelligent, the number of connections gets larger, and more types of
services are supported. These are the biggest changes in this process. As such,
traditional networks must also develop to keep pace with the changes. With 5G
and cloud services deployed, traditional IPv4/MPLS networks will have to carry
more and more traffic, increasing the data transmission pressure on the
networks and complicating the network structure. This makes network evolution
inevitable. Traditional MPLS technologies cannot afford to meet the
requirements of new services, and the impact of MPLS limitations of MPLS gets
severe. All these factors trigger new technologies to emerge, promoting network
evolution.
Focusing on the technical implementation of MPLS and the new requirements

for networks in the new era, we will discuss in detail why MPLS networks need
to evolve and in what direction they will evolve.
2
Background of Network Evolution from MPLS to SRv6
2.1 Challenges Facing MPLS Networks
Working as a Layer 2.5 technology, MPLS runs between Layer 2 and Layer 3. It
supports multiple network-layer protocols such as IPv4 and IPv6, and is
compatible with multiple link-layer technologies such as ATM and Ethernet. The
combination of IP and MPLS provides QoS guarantee on connectionless IP
networks. In addition, MPLS label-based forwarding resolves the issue of poor
forwarding performance on IP networks. This is why IPv4/MPLS became
successful in a period of time. However, with the advent of the 5G and cloud era,
traditional IPv4/MPLS networks face the following challenges:
1. Network silos are formed, making cross-domain deployment difficult.
MPLS is deployed in different network domains, such as IP backbone, fixed, and

mobile transport networks, forming independent MPLS domains and
consequently creating multiple network boundaries. However, because many
services require E2E deployment, they need to be deployed across multiple MPLS
domains, making cross-domain MPLS deployment complex. In that regard,
multiple inter-Autonomous System (AS) solutions, such as Option A, Option B,
and Option C, have been proposed for inter-AS MPLS VPN deployment, and each
one involves relatively complex service deployment.
2. Applications are decoupled from network transport, making cloud-network

convergence difficult.
As the Internet and cloud computing develop, more and more cloud data centers
(DCs) are built. To meet the requirements of multi-tenant networking, multiple
overlay technologies were proposed, among which Virtual eXtensible Local Area
Network (VXLAN) is a typical example. In the past, quite a few attempts were
made to provide VPN services by introducing MPLS to DCs. However, these
attempts all wound up in failure due to multiple factors, including numerous
network boundaries, complex management, and insufficient scalability.
3. Poor scalability causes MPLS to fail to meet the network programming

requirements of future services.
MPLS has only a 20-bit label space, with fixed label fields and lengths. This
means that the scalability of the label space is poor. In addition, the 32-bit fixed
encoding format is adopted for MPLS label encapsulation. Although MPLS labels
3
provide certain scalability, as more and more new services develop and require
packet headers to be extended to carry data, MPLS faces more challenges.
4. The protocol status is complex, hampering the construction of large-scale

networks.
Resource Reservation Protocol-Traffic Engineering (RSVP-TE) is a complex

protocol to implement and requires large numbers of protocol packets to be
exchanged in order to maintain the connection state. As the number of nodes
and tunnels increases, so too does the number of states. The exponential growth
of states imposes significant pressure on the performance of transit nodes,
hampering the construction of large-scale networks.
5. Service management is complex and is not suitable for large-scale service

deployment in the 5G and cloud era.
When multiple services (such as L2VPN and L3VPN services) coexist, protocols
such as Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP),
IGP, and BGP may also coexist on devices. This leads to complex service
deployment and management, making it difficult to achieve large-scale service
deployment in the 5G and cloud era.
Currently, MPLS is widely used as the transport technology on IP mobile

transport networks. As time goes by, the shortcomings of MPLS make it hard to
meet the service development requirements in the new era. To address this issue,
new technologies need to be studied. What are the requirements of the 5G and
cloud era for IPv4/MPLS transport networks? What are the services and their
characteristics in the 5G and cloud era? What kind of new technologies can meet
the requirements of such services?
As shown in Figure 2-1, not only connectivity of everything but also intelligent
connectivity of everything will be realized in the 5G and cloud era. This new era
will also spawn various vertical industries, including smart home, smart city,
Internet of vehicles (IoV), and industrial control. The service characteristics of
these vertical industries vary greatly. For example, smart home requires networks
to support numerous device connections, and services such as IoV and industrial
control require ultra-high reliability and ultra-low latency.
4
Figure 2-1 Network requirements in the 5G and cloud era
Segment Routing (SR) emerges in this context. It introduces service-driven

networks and allows the network architecture to be defined based on services.
Specifically, once applications raise service requirements (such as latency and
bandwidth requirements), a controller is used to collect network topology,
bandwidth usage, latency, and other required information, and then computes
explicit paths based on these requirements. There are two data planes for SR:
MPLS and IPv6. When SR is applied to the MPLS data plane, it is called SR-MPLS
and uses MPLS labels as SIDs. When SR is applied to the IPv6 data plane, it is
called SRv6 and uses IPv6 addresses as SIDs. Next, let's explore how technologies
evolve.
2.2 MPLS Network Evolution Direction

As mentioned in the previous section, MPLS networks are bound to evolve
towards new technologies due to the inability to meet service requirements in
the new era. As a new star in the 5G and cloud era, SR offers two technologies
— SR-MPLS and SRv6. In that regard, which technology should MPLS evolve to?
About this question, there are mainly two options in the industry:
One option is to perform evolution from MPLS to SR-MPLS, as shown in Figure

2-2. This evolution direction helps evolve an existing network from IPv4/MPLS to
SR-MPLS.
5
Figure 2-2 Evolution from MPLS to SR-MPLS
The other option is to perform evolution from MPLS to SRv6, as shown in Figure
2-3. This evolution direction helps evolve an existing network from IPv4/MPLS to
SRv6.
Figure 2-3 Evolution from MPLS to SRv6
Next, let's compare the advantages and disadvantages of the two evolution
directions from the following aspects.
6
Compatibility
An IP network typically involves multiple types of devices, which may be from
different vendors. As such, device compatibility is a very important factor for the
deployment of new technologies during network evolution.
If a transport network needs to evolve from MPLS to SR-MPLS, the following two
modes can be used, as shown in Figure 2-4.
Mode 1: MPLS/SR-MPLS dual stack In this mode, SR-MPLS can be deployed only
after the entire network is upgraded.
Mode 2: MPLS and SR-MPLS interworking In this mode, the Segment Routing
Mapping Server (SRMS) function needs to be deployed for each border node
between the MPLS and SR-MPLS domains to stitch together MPLS and SR LSPs.
Regardless of the evolution mode, the existing network needs to undergo

significant changes in the initial phase, and this evolution will take time.
Figure 2-4 Two modes for the evolution from MPLS to SR-MPLS
7
If a transport network needs to evolve from MPLS to SRv6, on-demand network
upgrade can be implemented, as shown in Figure 2-5. Specifically, in order to
support specific services based on SRv6, only the related devices need to be
upgraded to support SRv6, whereas other devices only need to support common
IPv6 route forwarding. As SRv6 features easy incremental deployment, customers
can enjoy maximized Return on Investment (ROI).
Scalability
As described in the previous section, one of the disadvantages of MPLS is that
cross-domain deployment is difficult. Even if cross-domain MPLS VPN
technologies can meet cross-domain deployment requirements, these
technologies are complex, slowing down service provisioning. Although SR-MPLS
provides programmability, issues such as the poor extensibility of MPLS
encapsulation prevent SR-MPLS from meeting the requirements of Service
Function Chaining (SFC), In-situ Operations, Administration, and Maintenance
(IOAM), and other services, which require metadata to be carried. In addition,
because MPLS labels do not contain reachability information, they must be
bound to routable IP addresses. As such, in cross-domain scenarios, the binding
between 32-bit host routes and labels must be propagated across domains. On a
large-scale network, numerous MPLS entries need to be generated on border
nodes, placing a heavy burden on the control and forwarding planes and
reducing network scalability.
8
One highlight of SRv6 is that it makes cross-domain deployment easier. The
native IPv6 attribute enables SRv6 to work based on aggregated routes. As such,
only a limited number of aggregated routes need to be imported to border
nodes on a large-scale cross-domain network. This not only reduces the
requirements on network device capabilities but also improves network
scalability.
Programmability
SRv6 has stronger network programming capabilities than SR-MPLS. Its network
programmability is reflected in the Segment Routing header (SRH). Generally,
the SRH provides a three-dimensional programming space, as shown in Figure 2-
6.
Figure 2-6 SRv6-enabled three-dimensional programming space
The three-dimensional programming space allows SRv6 to deliver more powerful

network programming capabilities, better meeting different network path
requirements. Taking a step further, SRv6 integrates SDN-powered global
network management and control capabilities to implement flexible
programming, thereby facilitating fast deployment of new services and helping
build truly intelligent networks.
9
Cloud-Network Convergence
As described in the previous section, traditional MPLS cannot be deployed on the
cloud. Because the data plane of SR-MPLS is the same as that of MPLS, it is also
difficult for SR-MPLS to support cloud-network convergence. By contrast, the
data plane of SRv6 is based on IPv6. As such, if both the cloud and network are
based on IPv6, data plane protocols can be unified to effectively support cloud-
network convergence.
From the perspective of terminal collaboration, it is difficult for terminals to

support MPLS. This is also true for SR-MPLS. However, SRv6 has been supported
by Linux since version 4.10, with version 4.14 supporting the most functions
provided by the Function field in an SRv6 SID. This provides technical support for
the cloud-based deployment and E2E implementation of SRv6.
According to the comparison in Table 2-1, in addition to simplifying network

protocols, SRv6 provides higher compatibility, scalability, and network
programmability than MPLS and SR-MPLS. These advantages will play an
important role in network evolution and meet the requirements of the 5G and
cloud era in the future. Therefore, if service evolution permits, evolution from
MPLS to SRv6 is recommended.
Table 2-1 Comparison between the two evolution directions
Item (Recommended) Evolution from Evolution from MPLS to SR-

MPLS to SRv6 MPLS
Compatibility Excellent. Thanks to the support for Poor. All devices in the involved
on-demand upgrade and the domain need to be upgraded to
excellent compatibility, smooth support SR-MPLS, causing
evolution can be implemented, significant network changes. In
allowing services to be quickly addition, the poor compatibility
provisioned on demand. In addition, makes service provisioning
upgrading the entire network is not complex.
required, maximizing the ROI.
Scalability Easy. With IPv6 reachability, SRv6 Complex. Only SR-MPLS TE can
can be easily deployed across ASs. be used across ASs, and inter-AS
Host routes do not need to be controllers are required. The local
advertised across ASs, and only PE requires the loopback host
10
Item (Recommended) Evolution from Evolution from MPLS to SR-
MPLS to SRv6 MPLS
aggregated routes need to be routes of remote PEs. All the

imported. This greatly reduces the loopback host routes of remote
number of routes and simplifies PEs need to be leaked.
routing policies.
Programmability Excellent. SRv6 provides excellent Poor. Although SR-MPLS provides

network programmability, programmability, issues such as
facilitating new service deployment. the poor extensibility of MPLS
encapsulation prevent SR-MPLS
from meeting the requirements of
SFC, IOAM, and other services,
which require metadata to be
carried.
Cloud-network Easy. Cloud data center networks Difficult. It is difficult for DCNs,
convergence (DCNs) can easily support IPv6. including virtual machines, to
support MPLS.
With SRv6, carrier networks can be
deployed in DCs and even extended
to user terminals.
11
Chapter 3
There are two typical paths for the evolution from MPLS to SRv6, as shown in
Figure 3-1. Indirect evolution means that a network is upgraded from IPv4/MPLS
to SR-MPLS and then to SRv6, whereas direct evolution means that a network is
directly upgraded from IPv4/MPLS to SRv6.
Indirect Evolution Path

Through the indirect evolution path, a network is upgraded from IPv4/MPLS to
SR-MPLS and then to SRv6. Most live networks are IPv4/MPLS networks, and
carriers have abundant experience in IPv4/MPLS network O&M. In view of this,
12
some carriers may choose to evolve IPv4/MPLS networks to SR-MPLS networks,
and then to SRv6 networks, provided that SRv6 grows in popularity.
To evolve from MPLS to SR-MPLS, all devices in an SR-MPLS domain need to be

upgraded to support SR-MPLS. Otherwise, services will be interrupted. Evolution
from SR-MPLS to SRv6 also requires a network upgrade to support IPv6. When
IPv6 is ready, networks can be gradually and smoothly upgraded to SRv6. That
being said, networks have to support both SR-MPLS and SRv6 in a long term
during evolution. In some scenarios, interworking between SRv6 and SR-MPLS is
required, meaning that dedicated protocols and standards must be defined to
achieve the interworking. The outcome of this is that the complexity of network
protocols, devices, and network O&M increases accordingly.
Within the context of the industry currently advocating simplified networks,

indirect evolution seems to be more complex than direct evolution.
From the perspective of services, how do we choose an appropriate SRv6-

oriented network evolution path? The following uses traditional MPLS HVPN and
seamless MPLS solutions (shown in Figure 3-2 and Figure 3-3 respectively) as
examples to describe how to make a choice.
Figure 3-2 Evolution paths for traditional MPLS HVPN solutions
13
To retain the HVPN model and continue to use L3VPN, you can evolve only
tunnels. In this case, paths 2 and 4 are supported. You can choose an evolution
path based on the device capability. If all devices support SRv6, select path 2.
Otherwise, select path 4.
The EVPN or L3VPN solution can be used to deploy a new VPN for 5G services.
The E2E VPN or HVPN solution can be used for service deployment. In terms of
tunnels, you can choose an evolution path as required. Specifically, if SRv6 is
supported, paths 5 and 6 are recommended. Otherwise, SR-MPLS needs to be
deployed, and paths 3 and 4 are recommended.
Figure 3-3 Evolution paths for traditional seamless MPLS solutions
If the seamless solution needs to be retained for services, only tunnels need to
evolve, and no VPN needs to be newly deployed for 5G services, you are advised
to continue to use the L3VPN solution and evolve only tunnels. In this case, path
5 is recommended.
If both tunnels and services need to evolve to the target solution, path 1 is
recommended.
The EVPN or L3VPN solution can be used to deploy a new VPN for 5G services. In
terms of tunnels, you can choose an evolution path as required. Only one layer
of tunnel is used, and BGP-LSP is not involved. If SRv6 is supported, path 1 is
14
recommended. Otherwise, SR-MPLS needs to be deployed, and path 3 is
recommended.
Direct Evolution Path

Through the direct evolution path, a network is directly upgraded from
IPv4/MPLS to SRv6. The key to achieving this lies in upgrading an IPv4 network
to an IPv6 network. If a network already supports the IPv4/IPv6 dual-stack, this
evolution path will be easy and simple to deploy. Once a network has been
upgraded to IPv6, it can easily evolve to SRv6 by introducing SRv6 capabilities to
related network nodes in the initial phase. As for highlights, on-demand
incremental upgrade is one of the main advantages of SRv6. For example, for
the scenario of L3VPN over SRv6 BE, SRv6 needs to be deployed only on edge
nodes, and transit nodes only need to support IPv6 forwarding, rather than being
upgraded to support SRv6.
Moreover, to support more advanced network functions (e.g., SRv6 TE) in the
future, only some key nodes such as autonomous system boundary routers
(ASBRs) and PEs need to be upgraded to support SRv6. This means that a
networkwide or E2E upgrade is not required. All these benefits are brought
about by the SRv6 smooth evolution capability.
From the perspective of network evolution workload, this evolution path

eliminates the need to deploy an intermediate network such as SR-MPLS,
shortening the network evolution period and avoiding secondary network
reconstruction. In addition, from the perspective of network evolution, IPv6 is the
future of IP networks, which has become a consensus in the industry. As such,
this evolution path is recommended.
15
Chapter 4
Strategies for Indirect
Evolution
Indirect evolution refers to the evolution from IPv4/MPLS to SR-MPLS and then
to SRv6. If a network does not meet the conditions for deploying SRv6, indirect
evolution can be performed. This evolution mainly involves the following steps:
Step 1: evolution from IPv4/MPLS to SR-MPLS to simplify the control plane.
Step 2: evolution from SR-MPLS to SRv6 to achieve data plane unification and
E2E IPv6-only forwarding.
4.1 Strategies for the Evolution from

MPLS to SR-MPLS
MPLS LDP is a mainstream tunneling technology and is widely used on transport
networks. As such, during the evolution from MPLS LDP to SR-MPLS, LDP and
SR-MPLS will coexist for a long time. The LDP and SR-MPLS interworking
technology enables LDP and SR-MPLS networks to be connected, implementing
MPLS forwarding between the two networks.
Interworking between SR-MPLS BE and LDP involves the following key scenarios:
16
Strategies for Indirect Evolution
1. SR-MPLS to LDP: Data traffic is forwarded from an SR-MPLS network to an
LDP network, as shown in Figure 4-1.
Figure 4-1 SR-MPLS to LDP
2. LDP to SR-MPLS: Data traffic is forwarded from an LDP network to an SR-

MPLS network, as shown in Figure 4-2.
Figure 4-2 LDP to SR-MPLS
3. SR-MPLS over LDP: SR-MPLS networks exchange data traffic over an LDP
network, as shown in Figure 4-3.
17
Figure 4-3 SR-MPLS over LDP
4. LDP over SR-MPLS: LDP networks exchange data traffic over an SR-MPLS
network, as shown in Figure 4-4.
Figure 4-4 LDP over SR-MPLS
Evolution Strategies
When deploying SR-MPLS, carriers do not need to replace network hardware.
Instead, they only need to upgrade software to enable SR. In addition, SR-MPLS
can be directly enabled on an MPLS network without the need to disuse or
replace original tunnels. As previously described, SR-MPLS can coexist with LDP.
Therefore, SR-MPLS allows an LDP network to be incrementally upgraded to an
SR-MPLS network, and the interworking technology can be used to achieve E2E
traffic forwarding.
Table 4-1 describes the strategies for the evolution from MPLS to SR-MPLS.
18
Table 4-1 Evolution strategies
Strategy Description Advantage Disadvantage
From outside to The hierarchical network The access The evolution is

inside architecture of a service network is slow due to the
provider consists of core, typically lightly- large number of
aggregation, and access loaded, lowering devices on the
networks. In this strategy, SR- the operation access network.
MPLS-oriented evolution starts risk and allowing
from the access network, the aggregation
moves to the aggregation and core
network, and is finally networks to be
performed on the core network. prepared in
advance.
From inside to The hierarchical network The core network The traffic on the
outside architecture of a service does not involve core network is
provider consists of core, a large number the heaviest.
aggregation, and access of devices, Once a fault
networks. In this strategy, SR- facilitating fast occurs, using this
MPLS-oriented evolution starts evolution to SR- strategy may
from the core network, moves MPLS. This cause huge
to the aggregation network, strategy is traffic impact on
and is finally performed on the recommended the core network,
access network. for experienced adversely
operators. affecting services.
(Recommended) Upgrade some nodes on the The possibility of -

Incremental involved network to support service
deployment SR-MPLS and phase out interruption is
existing transport protocols as minimized, and
required in order to minimize E2E traffic
service interruptions. This forwarding can
strategy is recommended for be implemented
evolution. It enables you to through the LDP
directly enable SR-MPLS on the and SR-MPLS
existing LDP network while interworking
ensuring that LDP and SR-MPLS technology.
work independently.
19
Evolution Phases
The evolution from MPLS LDP to SR-MPLS can be divided into the following
phases:
Initial state: All nodes on the MPLS backbone network run LDP, as shown in
Figure 4-5.
Figure 4-5 LDP only
Phase 1: SR-MPLS and LDP coexist, and LDP tunnels are the preferred ones.
After SR-MPLS is enabled, the control plane of each involved device still selects
LDP tunnels, as shown in Figure 4-6. This is because LDP tunnels are selected by
default in scenarios where traffic recurses to tunnels.
Figure 4-6 LDP tunnels preferred when SR-MPLS and LDP coexist
20
Phase 2: SR-MPLS tunnels are preferentially selected.
Configure global and prefix labels on SR-MPLS-capable nodes. It is

recommended that you start this configuration from edge nodes.
Configure a policy for preferentially selecting SR-MPLS BE tunnels in order to

increase the SR-MPLS tunnel priority so that SR-MPLS tunnels are preferentially
selected and LDP tunnels are no longer used for forwarding, as shown in Figure
4-7.
Figure 4-7 SR-MPLS tunnels preferred when SR-MPLS and LDP coexist
Phase 3: LDP tunnels are removed so that only SR-MPLS tunnels are retained on
the MPLS backbone network, as shown in Figure 4-8.
Figure 4-8 SR-MPLS only
21
4.2 Strategies for the Evolution from
SR-MPLS to SRv6
5G networks have come. To promote the development of such networks, users
hope to use IPv6 addresses to deploy VPNs more easily. SRv6 is therefore
introduced, extending the IPv6 header to implement label forwarding-like
processing through existing IPv6 forwarding technologies. SRv6 instantiates
certain IPv6 addresses as segment IDs (SIDs), each of which has its own explicit
functions. Different SID operations are performed to achieve simplified VPNs and
flexible path planning.
Evolution Strategies
In the previous section, we described the strategies for the evolution from MPLS
to SR-MPLS. When a network is ready for SRv6 deployment, you can consider the
evolution from SR-MPLS to SRv6. This evolution mainly involves the following
strategies:
1. SR-MPLS and SRv6 coexist, as shown in Figure 4-9.
Figure 4-9 SR-MPLS and SRv6 coexistence
22
2. SR-MPLS and SRv6 interwork, as shown in Figure 4-10.
Figure 4-10 SR-MPLS and SRv6 interworking
Table 4-2 describes the two evolution strategies.
Table 4-2 Evolution strategies
(Recommen Deploy both SR- The network is simple in Both SR-MPLS and
ded) SR- MPLS and SRv6 on terms of layers, and VPN SRv6 need to be
MPLS and PEs. interworking nodes do not deployed on PEs.
SRv6 need to be deployed.
In addition, Two peers (IPv4 and
coexistence
configure two BGP SRv6 forwarding and SR- IPv6) need to be
peers (IPv4 and MPLS forwarding are configured, doubling
IPv6). implemented for SRv6 site the numbers of sent
access and SR-MPLS site and received VPN
access, respectively. Traffic routes.
detours are not required for
the mutual access between
old and new sites.
23
SR-MPLS Deploy a single Protocols are simplified. This The network is

and SRv6 stack on PEs and is because only SRv6 instead complex in terms of
interworking also VPN of SR-MPLS needs to be layers, and VPN
interworking nodes deployed for new sites. interworking nodes
on the network. need to be deployed.
Only one BGP peer needs to
Deploy both SRv6 be configured for each PE to Achieving mutual
and MPLS on VPN receive only one copy of access between old
interworking nodes routes. and new sites
and configure requires traffic to be
route re- detoured to the VPN
origination or interworking nodes.
stitching.
Evolution Phases
The following uses L3VPN as an example to describe the evolution phases of
L3VPN service tunnels from SR-MPLS to SRv6 based on the SR-MPLS and SRv6
coexistence strategy. Figure 4-11 shows the network deployment mode for the
evolution.
The overall evolution process can be divided into the following phases:
Initial state: L3VPN over SR-MPLS is deployed.
Phase 1: Deploy dual stack.
1. Evolution from IGP IPv4 to IGP IPv4 and IPv6 dual stack
2. Evolution from the BGP peer relationship to the BGP and BGP4+
dual-stack peer relationship
3. Deployment of SRv6 and SR-MPLS dual-stack tunnels for L3VPN
Phase 2: Switch L3VPN services to SRv6 tunnels. This means that service tunnels
are evolved from SR-MPLS to SRv6.
Phase 3: Delete the SR-MPLS tunnels.
24
Figure 4-11 Evolution from SR-MPLS to SRv6
25
Chapter 5
Strategies for Direct Evolution
Direct evolution from MPLS to SRv6 is recommended. MPLS is based on IPv4

control protocols, such as IS-ISv4, OSPF, BGP, and LDP. By contrast, SRv6 is based
on IPv6 control protocols, such as IS-ISv6, OSPFv3, and BGP4+. As such,
strategies for direct evolution need to be determined based on the following
points:
1. IGP evolves from IPv4 to IPv4 and IPv6 dual stack.

2. BGP evolves from the pure BGP peer relationship to the BGP and BGP4+
dual-stack peer relationship.
3. Tunnels that are used to carry services evolve from MPLS to SRv6 BE or SRv6
TE Policy.
Because dual-stack deployment for IGP and BGP is mature, this chapter focuses
on tunnel evolution strategies. Depending on the network scenarios, there are
two tunnel evolution strategies, as shown in Figure 5-1.
1. Evolution based on the coexistence strategy: This strategy applies to

scenarios where the evolution is performed based on existing MPLS
networks. During the evolution, SRv6 and MPLS need to coexist. New
services are forwarded using SRv6, and old services are still forwarded using
MPLS. This strategy can also be used in scenarios where service endpoints
are newly created. In this case, you only need to upgrade endpoint devices
to support SRv6, thereby implementing E2E VPN over SRv6. Transit nodes
only need to support IPv6 forwarding instead of SRv6. In addition, if a
26
service involves a large number of endpoints, which cannot be upgraded to
SRv6 at the same time, the coexistence strategy can be used for evolution.
2. Evolution based on the interworking strategy: This strategy applies to
scenarios where SRv6 areas are newly created on a network or a network
contains not only MPLS areas but also SRv6 areas (upgraded from certain
MPLS areas). In such scenarios, interworking nodes need to be configured
for the two types of areas to interwork.
Figure 5-1 Two strategies for direct evolution
5.1 SRv6 and MPLS Coexistence

Strategy
Generally, network upgrade cannot be completed overnight. Therefore, SRv6-
capable and SRv6-incapable devices may coexist for a long time. If there is no
clear boundary between the deployment areas of the two types of devices on the
27
network, the coexistence strategy is typically used for evolution. This strategy
supports two solutions: dual-stack coexistence and overlay coexistence.
Dual-Stack Coexistence
If this solution is used for evolution, you need to consider dual stack coexistence
from the following two aspects:
1. Control protocols
− IGP dual stack coexistence. For example, IPv4 and IPv6 dual stack is
enabled for IS-IS, or OSPF and OSPFv3 coexist.
− BGP dual stack coexistence: MPLS VPN and SRv6 VPN both use BGP as
the service signaling protocol. The former uses IPv4 addresses to
establish BGP sessions, whereas the latter uses IPv6 addresses. In this
case, the same BGP address family, such as the BGP EVPN address
family, needs to be used for the coexistence of MPLS VPN and SRv6
VPN.
2. Service transport
− New services are carried over SRv6, and existing services are still carried
over MPLS.
− Existing services carried over MPLS can be smoothly migrated to SRv6.
− If a service flow passes through a large number of network nodes,
these nodes may not be upgraded to SRv6 at the same time. In this
case, the service flow needs to be carried over both SRv6 and MPLS.
The following uses the evolution from MPLS L3VPN to SRv6 L3VPN as an
example to describe how the dual-stack coexistence solution is implemented. On
the network shown in Figure 5-2, SRv6 is not initially deployed, so that all
services are carried over MPLS tunnels. The dual-stack coexistence solution is
used to enable all services on the network to be carried over SRv6 through the
following phases:
1. Create an SRv6 forwarding plane. Specifically, deploy IGP IPv6 on all nodes
on the network, upgrade PE1, PE3, and PE4 to SRv6-capable devices,
establish BGP4+ peer relationships between the three nodes and RRs, and
deploy L3VPN over SRv6.
28
2. Configure route-policies to allow new and existing services to coexist.
Specifically, on PE1, PE3, and PE4, configure VPN routes to be advertised by
different dual-stack peers. The routes advertised by IPv4 peers carry MPLS
labels and will automatically recurse to MPLS tunnels. By contrast, the
routes advertised by IPv6 peers carry SIDs and will automatically recurse to
SRv6 tunnels. When PE1, PE3, and PE4 receive both VPN routes carrying
MPLS labels and VPN routes carrying SIDs, route-policies are used to
determine the preferred routes, thereby controlling the tunnels used to carry
services.
3. After all services on the entire network are carried over SRv6, you can delete
BGP peer and MPLS configurations to achieve the evolution to the target
network.
Figure 5-2 Evolution using the dual-stack coexistence solution
Overlay Coexistence Solution

The overlay coexistence solution can be used when both the ingress and egress
of a service are upgraded to SRv6-capable devices, but transit nodes do not need
to be upgraded or cannot be upgraded temporarily due to some reasons (for
29
example, the service traverses a third-party network or the hardware of some
transit nodes does not support SRv6). In this case, a basic IPv6 underlay network
can be deployed on the transit nodes to realize E2E SRv6 service provisioning. If
key requirements such as traffic optimization are raised in the future, some key
nodes can be incrementally upgraded to support SRv6. Depending on the usage
scenario, this solution supports the following four implementation modes:
Mode 1: native IPv6 overlay. On the network shown in Figure 5-3, SRv6 is
deployed on the PEs. Only basic IPv6 protocols are deployed on the Ps
functioning as transit nodes, so that SRv6 services are forwarded over native IPv6
on these nodes. This mode applies to SRv6 evolution on carrier- or enterprise-
operated networks.
Figure 5-3 Native IPv6 overlay mode
Mode 2: 6PE overlay. On the network shown in Figure 5-4, 6PE is deployed on
the Ps functioning as transit nodes, and BGP is configured to advertise the
locator and LSR ID routes of the ingress and egress PEs. In this case, SRv6
services are forwarded through IPv6 over MPLS on the transit nodes. This mode
applies to scenarios where dual-stack is difficult to deploy on the intermediate
network and 6PE can be deployed for transition.
30
Figure 5-4 6PE overlay mode
Mode 3: L3VPN overlay. On the network shown in Figure 5-5, L3VPNv6 is

deployed on the intermediate network, and the Ps use VPN instances to
advertise the locator and LSR ID VPN routes of the ingress and egress PEs. SRv6
services are forwarded through MPLS L3VPNv6 on the intermediate network. In
this case, only one VPN instance needs to be deployed on the intermediate
network for locator and LSR ID route learning, enabling all SRv6 VPN services to
be forwarded in overlay mode in this VPN instance. This mode applies to
scenarios where a third-party network that supports MPLS L3VPNv6 is traversed.
31
Figure 5-5 L3VPN overlay mode
Mode 4: L2VPN overlay. On the network shown in Figure 5-6, an L2VPN is

deployed on the intermediate network, and IGP IPv6 or BGP4+ is deployed
between the local and remote ASBRs to directly exchange locator and LSR ID
routes. SRv6 services are only transparently transmitted at Layer 2 on the
intermediate network, and upper-layer routing and service information is
imperceptible. This mode applies to scenarios where a third-party network that
supports MPLS L2VPN private lines is traversed.
32
Figure 5-6 L2VPN overlay mode
5.2 SRv6 and MPLS Interworking

Strategy
During network evolution, it is possible that MPLS is not expected to be deployed
after SRv6 is independently deployed in a new area, or that all services in the
areas where SRv6 is upgraded area by area are carried over SRv6. In such
scenarios, there is a clear boundary between the deployment area of SRv6-
capable devices and that of SRv6-incapable devices. As such, the SRv6 and MPLS
interworking strategy is recommended for network evolution. The following
describes the evolution solution implemented in this strategy.
33
On the network shown in Figure 5-7, SRv6 is not initially deployed, so that all
services are carried over MPLS tunnels. A new area named A1 is created, with
only SRv6 deployed. To enable all services on the network to be carried over
SRv6 through the interworking strategy, perform the following steps:
1. Deploy VPN over SRv6 in the new area A1. Specifically, upgrade PE2 and PE3
to SRv6-capable devices, configure IGP IPv6 on PE2 and PE3, and deploy
VPN over SRv6 between the two devices. To carry L3 services, configure
L3VPN or EVPN L3VPN as the VPN solution. To carry L2 services, configure
EVPN VPLS or EVPN VPWS as the VPN solution.
2. Configure PE2 as the interworking node to ensure that services in the old
and new areas can interwork. According to the types of carried services, the
interworking function on PE2 can be configured using either of the following
methods:
− For L3VPN or EVPN L3VPN services, configure route re-origination on
PE2 to enable SRv6 and MPLS to interwork.
− For EVPN VPLS or EVPN VPWS services, deploy a bridge domain (BD)
on PE2 and bind the EVPN instance in the SRv6 area and the VSI in the
MPLS area to the BD to enable SRv6 and MPLS to interwork.
3. After the old area named A0 is upgraded, all services are switched to VPN
over SRv6, thereby achieving evolution to the target network.
Figure 5-7 Implementation of the interworking strategy
34
Chapter 6
Solution Design for SRv6-
oriented Direct Evolution
As previously described, considering the cost and efficiency of network upgrade,

it is recommended that MPLS be directly evolved to SRv6. Next, let's look at the
detailed solution design for the direct evolution. A complete evolution solution
typically consists of the following two phases:
 Protocol layer evolution: This phase mainly involves IPv6 address planning,
IGP evolution, BGP evolution, and SRv6 deployment.
 Service layer evolution: In this phase, a proper evolution strategy
(coexistence or interworking) needs to be selected based on the service
scenario on the live network to achieve the VPN service-layer upgrade.
6.1 Design for Protocol Layer Evolution

IPv6 Address Planning
Because the target network uses SRv6 to carry services, IPv6 address planning is
an important part of the evolution solution and also the basis for subsequent
routing protocol evolution. To properly and efficiently complete IPv6 address
35
Solution Design for SRv6-oriented Direct Evolution
planning, comply with the following rules for IPv6 address allocation on the
target network:
1. Uniformity: All IPv6 addresses on the entire network, including basic network
addresses and service addresses, are uniformly planned.
2. Uniqueness: Thanks to the large IPv6 address space, each IPv6 address can
be unique on the entire network.
3. Separation: This rule covers two aspects: 1. Service addresses and basic
network addresses are separately planned to facilitate traffic path and
security control on edge nodes. 2. SRv6 locators, loopback addresses, and
link addresses are planned in different address blocks to avoid address
overlapping.
4. Hierarchy and aggregatability: Address planning must ensure the
aggregation and advertisement of IPv6 addresses between different IGP
areas and between ASs. Aggregation greatly reduces the number of routes
on the network and significantly reduces the risk of route flapping spreading
from one area to another, providing basic assurance for E2E SRv6
deployment on large-scale networks. To facilitate aggregation, IPv6
addresses must be allocated hierarchically according to the following
requirements.
− A separate IPv6 network prefix is allocated to each backbone network.
− A separate IPv6 network prefix is allocated to each metro network.
− Each pair of metro aggregation devices (active and standby) is
allocated a separate IPv6 subnet prefix from the corresponding metro
network prefix.
− Each access network's IGP area is allocated a separate IPv6 subnet
prefix from the network prefix of the corresponding metro aggregation
devices.
− Each access device is allocated a separate IPv6 subnet prefix from the
network prefix of the corresponding access network's IGP area.
5. Security: Key source tracing information, including address attributes and
locations, must be embedded into IPv6 addresses to implement fast source
tracing of IPv6 addresses.
6. Scalability: In IPv6 address allocation, a certain address space needs to be
reserved in each address block for future service development.
36
7. Readability: IPv6 addresses are typically expressed in hexadecimal notation.
Therefore, it is recommended that each IPv6 address be divided into groups
of 4 bits to improve readability.
After understanding IPv6 address allocation rules, clarify the IPv6 address
allocation requirements of the target network in the following sequence:
1. Calculate the number of networks and areas involved.

2. Calculate the number of devices involved in each area. Each of the devices
needs to use an IPv6 address with the prefix length of 128 bits as its
loopback interface address.
3. Calculate the number of physical links involved in each area, including links
between devices, links between devices and users, and links between devices
and upper-layer carriers. Typically, it is recommended that IPv6 addresses
with the prefix length of 126 bits be allocated to LAN links and IPv6
addresses with the prefix length of 127 bits be allocated to P2P links.
4. Calculate the number of users in each area. Typically, IPv6 addresses with
the prefix length of 60 or 64 bits are allocated to consumer users, and IPv6
addresses with the prefix length of 48 or 56 bits are allocated to commercial
users.
Based on the preceding steps, you can obtain the number of IPv6 addresses
required by the target network and allocate IPv6 addresses layer by layer
according to the preceding allocation rules.
IGP Evolution Design

For the basic network, intra-AS route advertisement mainly depends on IGP. As
such, after IPv6 address planning is complete, the next step is to design IGP
evolution. Because the original network still runs IGP IPv4 whereas SRv6 requires
IGP IPv6, it is important to implement IPv4 and IPv6 dual stack deployment in
IGP evolution. The key points of IGP evolution design are summarized as follows
(as shown in Figure 6-1):
1. Protocol selection: To achieve better scalability, the recommended IGP is IS-

IS.
2. Process and level deployment: At the access layer, IS-IS multi-process
deployment is recommended. At the aggregation and core layers, IS-IS
multi-level deployment is recommended, and route import can be
37
performed if necessary. This design effectively controls the number of routes
and reduces the risk of route flapping spreading.
3. Topology planning: Using the independent IS-ISv6 topology is recommended.
In this way, you can set a separate cost for IS-ISv6, enabling path
computation to be independently performed for the IS-ISv4 and IS-ISv6
topologies without mutual influence.
4. Interface configuration: Enable IS-ISv6 and configure IPv6 costs for involved
interfaces.
5. Reliability design: Enable BFD for IS-ISv6 to implement fast detection and IS-
ISv6 FRR to implement fast recovery. Fast route convergence does not need
to be separately configured for IS-ISv6. Instead, basic IS-IS settings can be
directly used to implement this function.
Figure 6-1 IGP evolution design
38
BGP Evolution Design
Route advertisement between ASs mainly depends on BGP, which also provides
control signaling for VPNs. As such, BGP evolution design significantly impacts
subsequent service layer evolution and needs to be thoroughly considered. First
of all, establish BGP peer relationships according to the following rules:
 On the public network, it is recommended that only EBGP peer relationships

be established. You are advised not to establish IBGP peer relationships
between common devices except RRs.
 On a VPN, considering network scalability and the route specifications of
devices, you are advised not to establish any cross-domain BGP peer
relationship between the PEs at both ends of the network. Instead, you are
advised to hierarchically establish BGP peer relationships layer by layer.
 On a network with a controller deployed, because the controller uses BGP-LS
to collect information such as the topology, bandwidth, and link delay, BGP-
LS IPv6 peer relationships need to be established between common nodes
and RRs and between RRs and the controller.
Then, determine whether to deploy standalone RRs based on the following rules:
 For a new network area or an area to be upgraded to SRv6, it is

recommended that standalone RRs be deployed to simplify peer relationship
establishment. If standalone RRs have been deployed on the live network,
they can be directly used.
 For the entire network, it is recommended that non-standalone RRs
(generally access gateways) be deployed at the access layer and standalone
RRs be deployed at the aggregation and core layers.
Based on the preceding rules, the key points of BGP evolution design are
summarized as follows (as shown in Figure 6-2):
1. Peer relationship settings: BGP4+ peer relationships need to be established

between SRv6 nodes to advertise SRv6 public network and VPN routes. If a
controller is deployed, BGP-LS also needs to be enabled between the BGP4+
peers. In this way, IPv4 services carried by MPLS are not affected, and IPv6
networks can be directly deployed for new nodes. In addition, new BGP4+
peers can share some parameter settings, including the AS number and
router ID, with the original BGP peers.
39
2. RR settings: Typically, BGP and BGP4+ peers share RR settings. RR
deployment positions need to be reconsidered only when new service nodes
have changed the overall network layout.
3. Mutual route import: In an AS, IGP is mainly used for multual route import,
and configuring IBGP peers for devices (except RRs) is not recommended.
Between ASs, configure mutual route import between IGP and BGP on edge
nodes, and then establish EBGP peer relationships between the edge nodes
of different ASs to implement inter-AS route advertisement.
4. Traffic path optimization:
− During the evolution, route priorities can be set for different peers,
avoiding complex route-policy design.
− Depending on the VPN used by services, the Add-Path function can be
deployed in the BGP EVPN or BGP VPNv6 address family view to
implement VPN FRR or equal-cost load balancing.
− To prevent loops, you can set the same reflection cluster ID for
standalone RRs deployed at the aggregation and core layers but
different reflection cluster IDs for non-standalone RRs deployed at the
access layer.
40
Figure 6-2 BGP evolution design
SRv6 Deployment Solutions

The ultimate goal of network evolution described in this section is to use SRv6 to
carry services. As such, SRv6 deployment solutions must also be considered in the
protocol layer design for the target network. Currently, they mainly include SRv6
BE and SRv6 TE Policy. Figure 6-3 shows how the two solutions are implemented.
41
Figure 6-3 SRv6 deployment
SRv6 BE Deployment
SRv6 BE is a tunneling technology that provides basic SRv6 capabilities. After

basic protocol layer configuration is complete, perform the following operations
to deploy SRv6 BE:
1. Configure basic SRv6 functions, including enabling SRv6 forwarding and

configuring a locator.
2. Enable IS-IS SRv6 and configure IS-IS to advertise SRv6 BE locator routes.
3. Configure service-layer BGP VPN or EVPN routes to carry SIDs and enable
the function to recurse VPN or EVPN routes to SRv6 BE paths based on the
SIDs.
SRv6 TE Policy Deployment
SRv6 TE Policy is a tunneling technology developed based on SRv6. Leveraging

the color attribute and endpoint information, it enables network paths to be
planned based on specific Service Level Agreement (SLA) requirements, realizing
fine granularity of service value. After basic protocol-layer configuration is
complete, perform the following operations to deploy SRv6 TE Policy: (This
example uses the static configuration mode.)
1. Enable SRv6 forwarding.
42
2. Configure SRv6 SIDs, based on which SRv6 paths are created. SRv6 SIDs can
be statically configured (recommended) or dynamically generated through
IS-IS.
3. Configure segment lists and specify the SIDs through which each SRv6 TE
Policy explicitly passes.
4. Create SRv6 TE Policies, set color attributes and endpoint information, and
configure multiple candidate paths for each SRv6 TE Policy. In addition, set
different preferences for the candidate paths, so that the valid candidate
path with the highest preference functions as the primary and the one with
the second highest preference as the backup.
5. According to the types of carried services, configure different tunnel policies
to steer the services into corresponding SRv6 TE Policies.
In a controller-based deployment scenario, the controller collects topology, SID,

and link attribute information through BGP-LS, computes SRv6 TE Policy paths,
and then delivers the paths to the ingress through the BGP IPv6 SR-Policy peer
relationship to generate SRv6 TE Policy forwarding entries.
6.2 Design for Service Layer Evolution

After completing the preparations for protocol layer evolution, select a proper
strategy (coexistence or interworking) for service layer evolution based on the
service status.
Typically, on a traditional MPLS VPN, MPLS L3VPN is used to carry L3 services,

and MPLS VPLS or MPLS VPWS is used to carry L2 services. By contrast, typically,
on an SRv6 VPN (the evolution target), L3VPN over SRv6 or EVPN L3VPN over
SRv6 is used to carry L3 services, and EVPN VPLS over SRv6 or EVPN VPWS over
SRv6 is used to carry L2 services. This means that there are many combination
scenarios for service layer evolution. This section uses the evolution from MPLS
L3VPN to EVPN L3VPN over SRv6 for L3 services and the evolution from MPLS
VPLS to EVPN VPLS over SRv6 for L2 services as examples.
43
Coexistence Strategy-based Service Evolution
Solutions
Solution 1: evolution from MPLS L3VPN to EVPN L3VPN over SRv6. For this
evolution, if you want to gradually replace MPLS L3VPN on service nodes with
EVPN L3VPN over SRv6, using a coexistence strategy-based evolution solution is
recommended. In this solution, MPLS L3VPN and EVPN L3VPN over SRv6 can
share the same VPN instance, and service access interfaces do not need to be
bound to VPN instances again. During the evolution, SRv6 and MPLS tunnels
coexist, meaning that different tunnels are used for services destined for
different remote PEs. Specifically, an SRv6 tunnel is used to carry the EVPN
L3VPN services sent to the SRv6-capable remote PE, whereas an MPLS tunnel is
used to carry the common L3VPN services sent to the SRv6-incapable remote PE.
The following uses the networking scenario shown in Figure 6-4 as an example
to describe how to implement the service evolution solution.
Figure 6-4 Coexistence strategy-based service evolution solution 1
On the network shown in Figure 6-4, assume that PE2 and the RR have been
upgraded to support SRv6, and the newly added node PE1 supports SRv6. The
44
goal is to evolve MPLS L3VPN to EVPN L3VPN over SRv6 BE. The procedure for
service layer evolution is as follows:
1. Complete protocol-layer configuration on PE1, including configuring IPv6

addresses, IS-ISv6, BGP4+, and SRv6 BE.
2. Add EVPN RT configuration to the L3VPN instance on PE1, while keeping the
original common L3VPN RT configuration.
3. Establish a BGP EVPN peer relationship between PE1 and the RR, enable the
BGP4+ peer relationship with the RR in the BGP-EVPN address family view
of PE1, and configure PE1 to send EVPN routes carrying SRv6 encapsulation
attributes to its peer.
4. In the BGP-VPN instance view of PE1, enable VPN routes to carry SIDs when
being sent to EVPN and enable route recursion to be performed based on
the SIDs carried in EVPN routes.
5. In this case, both BGP and BGP4+ peer configurations exist on PE1, PE2, and
the RR. The route advertisement and selection process is as follows:
a. To communicate with both SRv6-capable and SRv6-incapable nodes,
PE1 sends VPN routes carrying MPLS VPN labels and SRv6 VPN SIDs
through the BGP and BGP4+ peer relationships, respectively.
b. The RR receives two VPN routes with the same prefix from PE1. Instead
of selecting a preferred route, the RR reflects the routes according to
the address type. Specifically, it reflects both routes to PE2 but only the
BGP VPNv4 route to PE3.
c. PE2 receives two VPN routes with the next hop being PE1 from the RR.
One is a VPNv4 route carrying an MPLS VPN label and received
through the BGP peer relationship, and the other is an EVPN route
carrying an SRv6 VPN SID and received through the BGP4+ peer
relationship. If the other attributes of the two routes are the same, PE2
preferentially selects the VPNv4 route received through the BGP peer
relationship. Otherwise, you can configure a policy to enable PE2 to
preferentially select the route received through the BGP peer
relationship before you check that the EVPN L3VPN over SRv6 BE
service path is normal. In this case, L3VPN traffic is still carried over
MPLS tunnels.
d. After checking that the EVPN L3VPN over SRv6 BE service path is
normal, increase the priority of routes learned through the BGP4+ peer
45
relationship on PE2 to enable PE2 to preferentially select the EVPN
route carrying an SRv6 VPN SID and received through the BGP4+ peer
relationship. In this way, traffic from PE2 to PE1 is forwarded over SRv6
BE.
e. PE3 receives only the route carrying an MPLS VPN label from the RR.
As such, traffic from PE3 to PE1 is still forwarded over an MPLS tunnel.
Similarly, PE1 receives only the route carrying an MPLS VPN label from
PE3 through the BGP peer relationship. As such, traffic from PE1 to PE3
is also carried over an MPLS tunnel.
6. After all BGP peers support SRv6, you can delete the BGP peer relationship
and MPLS configuration from PE1.
Solution 2: evolution from MPLS VPLS to EVPN VPLS over SRv6. VPLS is an
MP2MP L2VPN service. There are two methods for the evolution from MPLS
VPLS to EVPN VPLS over SRv6. One method is to directly deploy EVPN VPLS over
SRv6 on all PEs, unbind VPLS instances from all access interfaces, and then bind
EVPN instances to the interfaces. The other method is to configure EVPN VPLS
over SRv6 for PEs one by one to enable EVPN VPLS over SRv6 to coexist with
MPLS VPLS, and then delete the original VPLS instances after all PEs are
upgraded. When there are a large number of L2VPN access interfaces, method 1
is difficult to implement, causing method 2 to be indispensable. In this case, a
coexistence strategy-based service evolution solution can be used to achieve
smooth evolution of services on the live network. The following uses the
networking scenario shown in Figure 6-5 as an example to describe how to
implement the service evolution solution.
46
Figure 6-5 Coexistence strategy-based service evolution solution 2
Assume that PE2 and PE4 are newly added nodes that support SRv6, and PE3
with services does not support SRv6. The goal is to evolve MPLS VPLS to EVPN
VPLS over SRv6 BE. The procedure for service layer evolution is as follows:
1. Complete protocol-layer configuration on PE2 and PE4, including configuring

IPv6 addresses, IS-ISv6, BGP4+, and SRv6 BE.
2. Configure BD EVPN instances on PE2 and PE4, configure EVPN routes to
carry SIDs, and enable the function to recurse EVPN routes to SRv6 BE paths
based on the SIDs.
3. Change common VPLS to BD VPLS on PE2 and PE4.
4. Bind the EVPN instance and VSI to the same BD on PE2 and PE4.
5. Change the access interface of the VSI to an EVC sub-interface and bind it to
the BD on PE2 and PE4. In this way, EVPN VPLS over SRv6 BE runs between
PE2 and PE4, and common PWs remain unchanged between PE2 and PE3
and between PE4 and PE3. To avoid broadcast loops, the common PW
relationship between PE2 and PE4 automatically becomes invalid. On PE2
and PE4, EVPN VPLS over SRv6 BE and MPLS VPLS are bound to the same
BD, and the EVPN instance and VSI share the same MAC forwarding table.
Therefore, PE2, PE3, and PE4 can communicate at Layer 2.
6. After all the other service nodes support SRv6, configure them to run EVPN
VPLS over SRv6 BE, and then delete all MPLS VPLS configurations.
47
Interworking Strategy-based Service Evolution
Solutions
Solution 1: evolution from MPLS L3VPN to EVPN L3VPN over SRv6. For this
evolution, if EVPN L3VPN over SRv6 is deployed only in new areas, MPLS L3VPN
is still kept in existing areas, and there is a clear boundary between the two
types of areas, using an interworking strategy-based evolution solution is
recommended. In this solution, the key point is to configure the service
interworking function on edge nodes. The following uses the networking
scenario shown in Figure 6-6 as an example to describe how to implement the
service evolution solution.
Figure 6-6 Interworking strategy-based service evolution solution 1
On the network shown in Figure 6-6, assume that the area A0 consisting of PE1,
PE2, PE3, and PE4 runs only MPLS L3VPN. Newly added nodes PE5 and PE6
support SRv6, and they form the area A1 together with PE3 and PE4. It is
expected that only EVPN L3VPN over SRv6 BE runs in the area A1. The goal is to
enable all the devices on the network to run EVPN L3VPN over SRv6 BE after
replacing PE1 and PE2 with SRv6-capable devices, while ensuring that both the
48
original and new services run properly before this goal is achieved. In this case,
you need to configure service interworking on PE3 and PE4. The procedure for
1. Complete protocol-layer configuration on each node in the area A1,

including configuring IPv6 addresses, IS-ISv6, BGP4+, and SRv6 BE.
2. On PE5 and PE6, configure an EVPN L3VPN instance. In the BGP-VPN
instance view, enable VPN routes to carry SIDs when being sent to EVPN. In
addition, enable route recursion to be performed based on the SIDs carried
in EVPN routes. In this way, SRv6 BE is enabled to carry EVPN L3VPN
services.
3. Configure L3VPN instances on PE3 and PE4 and set common RTs and EVPN
RTs.
4. Establish a BGP4+ peer relationship between PE3 and RR1 in the area A1
and a BGP peer relationship between PE3 and RR0 in the area A0. Repeat
this step for PE4.
5. Enable PE3 and PE4 to advertise SRv6 EVPN routes to RR1 and VPNv4 routes
to RR0, and then configure route re-origination between the BGP-EVPN and
BGP-VPNv4 address families. The route re-origination process is as follows:
The routes sent from PE5 and PE6 to PE3 and PE4 through RR1 are EVPN
routes carrying SRv6 SIDs. After reaching PE3 and PE4, the routes are
installed into VPN routing tables, thereby becoming VPN routes. The VPN
routes are re-originated into VPNv4 routes carrying MPLS labels and then
sent to PE1 and PE2 through RR0. By contrast, the routes sent from PE1 and
PE2 to PE3 and PE4 through RR0 are VPNv4 routes carrying MPLS labels.
After reaching PE3 and PE4, the routes are also installed into VPN routing
tables, thereby becoming VPN routes. The VPN routes are re-originated into
EVPN routes carrying SRv6 SIDs and then sent to PE5 and PE6 through RR1.
In this way, the original and new services can seamlessly interwork.
6. After PE1 and PE2 are upgraded, configure all services to run EVPN L3VPN
over SRv6 BE, and then delete the interworking configuration on PE3 and
PE4.
Solution 2: evolution from MPLS VPLS to EVPN VPLS over SRv6. During the
evolution from MPLS VPLS to EVPN VPLS over SRv6, if some nodes on the live
network cannot be upgraded to EVPN nodes, using an interworking strategy-
based evolution solution is recommended. On the network shown in Figure 6-7,
MPLS VPLS is deployed on the access network between the UPEs and SPEs,
49
whereas EVPN VPLS over SRv6 BE is deployed on the aggregation network
between the SPEs and NPEs.
Figure 6-7 Interworking strategy-based service evolution solution 2
The goal is to enable all the devices on the network to run EVPN VPLS over SRv6
BE after replacing the UPEs with SRv6-capable devices, while ensuring that both
the original and new services run properly before this goal is achieved. In this
case, you need to configure service interworking on the SPEs. The procedure for
1. Complete protocol-layer configuration on each node of the aggregation

network, including configuring IPv6 addresses, IS-ISv6, BGP4+, and SRv6 BE.
2. Configure BD EVPN instances on the NPEs and SPEs, configure EVPN routes
to carry SIDs, and enable the function to recurse EVPN routes to SRv6 BE
paths based on the SIDs. In this way, SRv6 BE is enabled to carry EVPN VPLS
services.
3. On the SPEs, bind the BD EVPN instance and BD VSI to the same BD.
4. In the VSIs of the SPEs, specify the UPE role for UPE1 and UPE2. If primary
and backup PWs are configured for MPLS VPLS, set the AC interfaces of
EVPN VPLS to PWs on the SPEs and configure the same ESI for the primary
and backup PWs.
50
5. Set the MPLS LSR ID and EVPN source address to the same IP address on the
SPEs. In this way, MPLS VPLS is used to carry service traffic between the
UPEs and SPEs, whereas EVPN VPLS over SRv6 BE is used to carry service
traffic between the SPEs and NPEs.
6. After the UPEs are upgraded, configure all services to run EVPN VPLS over
SRv6 BE, and then delete the interworking configuration on the SPEs.
51
Chapter 7
Summary and Outlook
With the booming of 5G, Internet of Things (IoT), and cloud services, people-to-
people communication has been further extended to connections between things
and between people and things. This causes the number of nodes and
connections that networks need to support to be increased to an unprecedented
scale. In addition, the ever enriching service scenarios and connection
applications pose higher requirements on IP networks. For example, how to
flexibly provide differentiated connection services for different services, how to
monitor network conditions in real time, and how to adjust networks based on
the network status in a timely manner. To meet these requirements, it is urgent
to combine IPv6 infrastructure networks with other technologies to develop IPv6
Enhanced networks. SRv6 — a key IPv6 Enhanced technology — will become a
main transport protocol for multiple services on IPv6 infrastructure networks.
Currently, a large number of IPv4/MPLS networks exist, meaning that there will
be many application requirements and a huge development space for MPLS-to-
SRv6 evolution solutions. In the future, the evolution may be combined with
intelligent network management platforms, including SDN controllers (such as
iMaster NCE) and smart O&M tools, to make live network evolution smoother,
more convenient, and more efficient.
In this book, the strategies, solutions, and extended applications for the evolution
from MPLS to SRv6 are only examples provided based on existing cases. With the
deepening of the evolution from MPLS to SRv6, more scenarios will be explored,
allowing evolution strategies and solutions to be continuously enriched and
52
Summary and Outlook
optimized. We will continue to follow up and revise this book in a timely
manner.
53
Summary and Outlook
Contact Us
networkinfo@huawei.com
More IP Network eBooks

https://e.huawei.com/cn/solutions/enterprise-networks/ip-ebook
54
Summary and Outlook

Get File Stream

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Get File Stream

Uploaded by

Copyright:

Available Formats

MPLS-to-SRv6

Copyright © Huawei Technologies Co., Ltd. 2022. All rights reserved.

Trademarks and Permissions

About This Book

Indicates a low-risk hazard that, if not avoided, could result in

Chapter 1 Overview of Network Evolution from MPLS to SRv6 ............................ 1

Chapter 2 Background of Network Evolution from MPLS to SRv6 ....................... 2

2.1 Challenges Facing MPLS Networks ...............................................................3

2.2 MPLS Network Evolution Direction ...............................................................5

Chapter 3 Evolution from MPLS to SRv6 ................................................................... 12

Chapter 4 Strategies for Indirect Evolution .............................................................. 16

4.1 Strategies for the Evolution from MPLS to SR-MPLS .......................... 16

4.2 Strategies for the Evolution from SR-MPLS to SRv6 ........................... 22

Chapter 5 Strategies for Direct Evolution ................................................................. 26

5.1 SRv6 and MPLS Coexistence Strategy ....................................................... 27

5.2 SRv6 and MPLS Interworking Strategy ..................................................... 33

Chapter 6 Solution Design for SRv6-oriented Direct Evolution ........................... 35

6.1 Design for Protocol Layer Evolution .......................................................... 35

6.2 Design for Service Layer Evolution ............................................................. 43

Chapter 7 Summary and Outlook ............................................................................... 52

In the intelligence era, connectivity of everything is evolving towards intelligent

Focusing on the technical implementation of MPLS and the new requirements

1. Network silos are formed, making cross-domain deployment difficult.

MPLS is deployed in different network domains, such as IP backbone, fixed, and

2. Applications are decoupled from network transport, making cloud-network

3. Poor scalability causes MPLS to fail to meet the network programming

4. The protocol status is complex, hampering the construction of large-scale

Resource Reservation Protocol-Traffic Engineering (RSVP-TE) is a complex

5. Service management is complex and is not suitable for large-scale service

Currently, MPLS is widely used as the transport technology on IP mobile

Segment Routing (SR) emerges in this context. It introduces service-driven

2.2 MPLS Network Evolution Direction

One option is to perform evolution from MPLS to SR-MPLS, as shown in Figure

Figure 2-3 Evolution from MPLS to SRv6

Regardless of the evolution mode, the existing network needs to undergo

Figure 2-5 Evolution from MPLS to SRv6

Figure 2-6 SRv6-enabled three-dimensional programming space

The three-dimensional programming space allows SRv6 to deliver more powerful

From the perspective of terminal collaboration, it is difficult for terminals to

According to the comparison in Table 2-1, in addition to simplifying network

Table 2-1 Comparison between the two evolution directions

Item (Recommended) Evolution from Evolution from MPLS to SR-

aggregated routes need to be routes of remote PEs. All the

Programmability Excellent. SRv6 provides excellent Poor. Although SR-MPLS provides

Figure 3-1 Evolution from MPLS to SRv6

Indirect Evolution Path

To evolve from MPLS to SR-MPLS, all devices in an SR-MPLS domain need to be

Within the context of the industry currently advocating simplified networks,

From the perspective of services, how do we choose an appropriate SRv6-

Figure 3-2 Evolution paths for traditional MPLS HVPN solutions

Figure 3-3 Evolution paths for traditional seamless MPLS solutions

Direct Evolution Path

From the perspective of network evolution workload, this evolution path

Step 1: evolution from IPv4/MPLS to SR-MPLS to simplify the control plane.

4.1 Strategies for the Evolution from

Figure 4-1 SR-MPLS to LDP

2. LDP to SR-MPLS: Data traffic is forwarded from an LDP network to an SR-

Figure 4-2 LDP to SR-MPLS

Figure 4-4 LDP over SR-MPLS

Strategy Description Advantage Disadvantage

From outside to The hierarchical network The access The evolution is

(Recommended) Upgrade some nodes on the The possibility of -

Figure 4-5 LDP only