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: 2023-08-14
Issue: 02

Copyright © Huawei Technologies Co., Ltd. 2023. 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 evolution

i
Preface
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, Junlin Quan, Zhaokun Ding, Keyi Zhu, Yuefeng Qiu,
Wenjun Meng, Tao Han, Hongkun Li, Yue Liu, and other leaders and experts from
Huawei Data Communication Product Line for their guidance and support. Our
thanks also go to Hui Tian, Shujun Han, Danni Ma, and other experts from China
Academy of Information and Communications Technology, who not only provided
valuable technical guidance but also carefully reviewed the book.

This book focuses on the most cutting-edge IPv6 technologies, which 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 ................................................................... 13

Chapter 4 Strategies for Indirect Evolution .............................................................. 17

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

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

Chapter 5 Strategies for Direct Evolution ................................................................. 28

5.1 SRv6 and MPLS Coexistence Strategy ....................................................... 29

5.2 SRv6 and MPLS Interworking Strategy ..................................................... 35

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

6.1 Design for Protocol Layer Evolution .......................................................... 37

6.2 Design for Service Layer Evolution ............................................................. 44

ii
Table of Contents
Chapter 7 Summary and Outlook ............................................................................... 53

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
Evolution from MPLS to SRv6

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 provide

3
Background of Network Evolution from MPLS to SRv6
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
Background of Network Evolution from MPLS to SRv6
 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
Background of Network Evolution from MPLS to SRv6
 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

6
Background of Network Evolution from MPLS to SRv6
Next, let's compare the advantages and disadvantages of the two evolution
directions from the following aspects.

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.

7
Background of Network Evolution from MPLS to SRv6
 Figure 2-4 Two modes for the evolution from MPLS to SR-MPLS

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).

8
Background of Network Evolution from MPLS to SRv6
 Figure 2-5 Evolution from MPLS to SRv6

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.

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.

9
Background of Network Evolution from MPLS to SRv6
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.

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

10
Background of Network Evolution from MPLS to SRv6
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 can Complex. Only SR-MPLS TE can
be easily deployed across ASs. Host be used across ASs, and inter-
routes do not need to be advertised AS controllers are required. The
across ASs, and only aggregated local PE requires the loopback
routes need to be imported. This host routes of remote PEs. All
greatly reduces the number of routes the loopback host routes of
and simplifies routing policies. remote PEs need to be leaked.

11
Background of Network Evolution from MPLS to SRv6
Item (Recommended) Evolution from Evolution from MPLS to SR-
MPLS to SRv6 MPLS

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

network programmability, facilitating provides programmability,
new service deployment. issues such as 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.

12
Background of Network Evolution from MPLS to SRv6
 Chapter 3
Evolution from MPLS to SRv6

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.

Figure 3-1 Evolution from 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,

13
Evolution from MPLS to SRv6
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

14
Evolution from MPLS to SRv6
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

15
Evolution from MPLS to SRv6
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.

16
Evolution from MPLS to SRv6
 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.

17
Strategies for Indirect Evolution
Interworking between SR-MPLS BE and LDP involves the following key scenarios:

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.

18
Strategies for Indirect Evolution
 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.

19
Strategies for Indirect Evolution
 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.

20
Strategies for Indirect Evolution
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

21
Strategies for Indirect Evolution
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

22
Strategies for Indirect Evolution
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

23
Strategies for Indirect Evolution
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

Strategy Description Advantage Disadvantage

(Recommended) Deploy both SR- The network is simple in Both SR-MPLS

SR-MPLS and MPLS and SRv6 on terms of layers, and VPN and SRv6 need to
SRv6 coexistence PEs. interworking nodes do not be deployed on
need to be deployed. PEs.
In addition,
configure two BGP SRv6 forwarding and SR- Two peers (IPv4
peers (IPv4 and MPLS forwarding are and IPv6) need
IPv6). implemented for SRv6 site to be configured,
access and SR-MPLS site doubling the
access, respectively. Traffic numbers of sent
detours are not required for and received VPN
the mutual access between routes.
old and new sites.

24
Strategies for Indirect Evolution
 Strategy Description Advantage Disadvantage

SR-MPLS and Deploy a single Protocols are simplified. This The network is
SRv6 stack on PEs and is because only SRv6 instead complex in terms
interworking also VPN of SR-MPLS needs to be of layers, and
interworking nodes deployed for new sites. VPN interworking
on the network. nodes need to be
Only one BGP peer needs to
deployed.
Deploy both SRv6 be configured for each PE to
and MPLS on VPN receive only one copy of Achieving mutual
interworking nodes routes. access between
and configure old and new sites
route re- requires traffic to
origination or be detoured to
stitching. the VPN
interworking
nodes.

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.

25
Strategies for Indirect Evolution
 Figure 4-11 Evolution from SR-MPLS to SRv6

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

26
Strategies for Indirect Evolution
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.

27
Strategies for Indirect Evolution
 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 service involves a large number

28
Strategies for Direct Evolution
 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

29
Strategies for Direct Evolution
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.
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

30
Strategies for Direct Evolution
 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
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

31
Strategies for Direct Evolution
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.

32
Strategies for Direct Evolution
 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.

33
Strategies for Direct Evolution
 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.

34
Strategies for Direct Evolution
 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.

35
Strategies for Direct Evolution
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

36
Strategies for Direct Evolution
 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

37
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.
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.

38
Solution Design for SRv6-oriented Direct Evolution
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 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

39
Solution Design for SRv6-oriented Direct Evolution
 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

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:

40
Solution Design for SRv6-oriented Direct Evolution
 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.
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

41
Solution Design for SRv6-oriented Direct Evolution
 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.

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

42
Solution Design for SRv6-oriented Direct Evolution
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.

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.)

43
Solution Design for SRv6-oriented Direct Evolution
1. Enable SRv6 forwarding.
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.

44
Solution Design for SRv6-oriented Direct Evolution
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 goal

45
Solution Design for SRv6-oriented Direct Evolution
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

46
Solution Design for SRv6-oriented Direct Evolution
 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.

47
Solution Design for SRv6-oriented Direct Evolution
 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.

48
Solution Design for SRv6-oriented Direct Evolution
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 original and new
services run properly before this goal is achieved. In this case, you need to

49
Solution Design for SRv6-oriented Direct Evolution
configure service interworking on PE3 and PE4. The procedure for service layer
evolution is as follows:

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, whereas
EVPN VPLS over SRv6 BE is deployed on the aggregation network between the
SPEs and NPEs.

50
Solution Design for SRv6-oriented Direct Evolution
 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 service
layer evolution is as follows:

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.
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.

51
Solution Design for SRv6-oriented Direct Evolution
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.

52
Solution Design for SRv6-oriented Direct Evolution
 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,

53
Summary and Outlook
allowing evolution strategies and solutions to be continuously enriched and
optimized. We will continue to follow up and revise this book in a timely manner.

54
Summary and Outlook
Contact Us
[email protected]

More IP Network eBooks

https://e.huawei.com/en/topic/enterprise-network/ip-ebook

55
Summary and Outlook