NE40E Feature Description - Segment Routing

HUAWEI NE40E Universal Service Router
Feature Description - Segment

Routing
Issue 01
Date 2017-07-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2017. 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.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2017-07-30) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Feature Description - Segment Routing Contents
Contents
1 About This Document .................................................................................................................. 1

2 Segment Routing ........................................................................................................................... 4
2.1 Introduction .................................................................................................................................................................. 4
2.2 Feature Updates ............................................................................................................................................................ 6
2.3 Principles ...................................................................................................................................................................... 6
2.3.1 Basic Principles ......................................................................................................................................................... 6
2.3.2 SR LSP .................................................................................................................................................................... 11
2.3.3 IS-IS SR ................................................................................................................................................................... 14
2.3.4 SR-TE ...................................................................................................................................................................... 23
2.3.5 Importing Traffic...................................................................................................................................................... 33
2.3.6 TI-LFA FRR ............................................................................................................................................................. 40
2.3.7 SR OAM .................................................................................................................................................................. 51
2.3.8 Applications ............................................................................................................................................................. 52
2.3.9 Acronyms and Abbreviations ................................................................................................................................... 52
Issue 01 (2017-07-30) Huawei Proprietary and Confidential ii

Feature Description - Segment Routing 1 About This Document
1 About This Document
Purpose
This document describes the Segment Routing feature in terms of its overview, principles, and
applications.
Related Version
The following table lists the product version related to this document.
Product Name Version
NE40E Series V800R009C10

U2000 V200R017C50
Intended Audience
This document is intended for:
Network planning engineers
Commissioning engineers
Data configuration engineers
System maintenance engineers
Security Declaration
Encryption algorithm declaration
The encryption algorithms DES/3DES/SKIPJACK/RC2/RSA (RSA-1024 or
lower)/MD2/MD4/MD5 (in digital signature scenarios and password encryption)/SHA1
(in digital signature scenarios) have a low security, which may bring security risks. If
protocols allowed, using more secure encryption algorithms, such as AES/RSA
(RSA-2048 or higher)/SHA2/HMAC-SHA2 is recommended.
Password configuration declaration
Do not set both the start and end characters of a password to "%^%#". This causes
the password to be displayed directly in the configuration file.
Issue 01 (2017-07-30) Huawei Proprietary and Confidential 1

To further improve device security, periodically change the password.

Personal data declaration
Your purchased products, services, or features may use users' some personal data during
service operation or fault locating. You must define user privacy policies in compliance
with local laws and take proper measures to fully protect personal data.
Feature declaration
The NetStream feature may be used to analyze the communication information of
terminal customers for network traffic statistics and management purposes. Before
enabling the NetStream feature, ensure that it is performed within the boundaries
permitted by applicable laws and regulations. Effective measures must be taken to
ensure that information is securely protected.
The mirroring feature may be used to analyze the communication information of
terminal customers for a maintenance purpose. Before enabling the mirroring
function, ensure that it is performed within the boundaries permitted by applicable
laws and regulations. Effective measures must be taken to ensure that information is
securely protected.
The packet header obtaining feature may be used to collect or store some
communication information about specific customers for transmission fault and
error detection purposes. Huawei cannot offer services to collect or store this
information unilaterally. Before enabling the function, ensure that it is performed
within the boundaries permitted by applicable laws and regulations. Effective
measures must be taken to ensure that information is securely protected.
Reliability design declaration
Network planning and site design must comply with reliability design principles and
provide device- and solution-level protection. Device-level protection includes planning
principles of dual-network and inter-board dual-link to avoid single point or single link
of failure. Solution-level protection refers to a fast convergence mechanism, such as FRR
and VRRP.
Special Declaration
This document serves only as a guide. The content is written based on device
information gathered under lab conditions. The content provided by this document is
intended to be taken as general guidance, and does not cover all scenarios. The content
provided by this document may be different from the information on user device
interfaces due to factors such as version upgrades and differences in device models,
board restrictions, and configuration files. The actual user device information takes
precedence over the content provided by this document. The preceding differences are
beyond the scope of this document.
The maximum values provided in this document are obtained in specific lab
environments (for example, only a certain type of board or protocol is configured on a
tested device). The actually obtained maximum values may be different from the
maximum values provided in this document due to factors such as differences in
hardware configurations and carried services.
Interface numbers used in this document are examples. Use the existing interface
numbers on devices for configuration.
The pictures of hardware in this document are for reference only.
Symbol Conventions
The symbols that may be found in this document are defined as follows.

Symbol Description
Indicates an imminently hazardous situation which, if not
avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
Calls attention to important information, best practices and
tips.
NOTE is used to address information not related to
personal injury, equipment damage, and environment
deterioration.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue
contains all updates made in previous issues.
Changes in Issue 02 (2017-07-30)
This issue is the second official release. The software version of this issue is
V800R009C10SPC100.
Changes in Issue 01 (2017-05-30)
This issue is the first official release. The software version of this issue is
V800R009C10.

Feature Description - Segment Routing 2 Segment Routing
2 Segment Routing
About This Chapter

2.1 Introduction
2.2 Feature Updates
2.3 Principles
2.1 Introduction
Definition
Segment routing (SR) is a method designed to forward data packets on a network based on
source routes. Segment routing divides a network path into several segments and assigns a
segment ID to each segment and network forwarding node. The segments and nodes are
sequentially arranged (segment list) to form a forwarding path.
Segment routing encodes the segment list identifying a forwarding path into a data packet
header. The segment ID is transmitted along with the packet. After receiving the data packet,
the receive end parses the segment list. If the top segment ID in the segment list identifies the
local node, the node removes the segment ID and proceeds with the follow-up procedure. If
the top segment ID does not identify the local node, the node uses the Equal Cost Multiple
Path (ECMP) algorithm to forward the packet to a next node.
Purpose
The conventional IP data packet forwarding depends on IP addresses along the shortest path
to a destination. To minimize the latency in voice, online games, and video conference
services, the fast reroute (FRR) technique emerged. To provide large bandwidth for leased line
services, for example, group customer services, the traffic engineering (TE) technique was
introduced. These techniques follow the rule that helps a network adapt to service growth. The
increasing types of services pose a variety of network requirements. For example, real-time
UC&C applications prefer to paths of low delay and low jitter, and big data applications
prefer to high bandwidth tunnels with a low packet loss rate. In this situation, the rule helping
the network adapt to service growth cannot catch up with the rapid service development and
even makes network deployment more complex and difficult to maintain.

The solution is to allow services to drive network development and to define the network
architecture. Specifically, an application (App) raises requirements (on the delay, bandwidth,
and packet loss rate). A controller collects information, such as network topology, bandwidth
usage, and delay information and computes an explicit path that satisfies the service
requirements.
Figure 2-1 Service-driven network
Segment routing emerges in this context. Segment routing is used to simply define an explicit
path. Nodes need to merely maintain the segment routing information to adapt to rapid service
growth in real time. Segment routing has the following characteristics:
Extends existing protocols to allow for better smooth evolution of live networks.
Strikes a balance between centralized control and the distributed mode.
Uses the source routing technique to provide capabilities of rapid interaction between
networks and upper-layer applications.
Benefits
Segment routing offers the following benefits:
The MPLS control protocol is simplified.
A controller or an IGP is used to uniformly compute paths and distribute labels, without
using RSVP-TE or LDP. The existing MPLS forwarding architecture remains on the
forwarding plane.
Provides topology independent-loop-free alternate (TI-LFA), which improves FRR
protection.
SR, in combination with the RLFA algorithm, supports any topology in theory and
overcomes drawbacks in conventional tunnel protection.
Provides the higher capacity expansion capability.

MPLS TE is a connection-oriented technique. To maintain connections, nodes need to

send and process a large number of Keepalive packets, posing heavy burdens on the
control plane. Segment routing controls any service paths by merely operating labels on
the ingress, and transit node do not have to maintain path information, which reduces the
burdens on the control plane.
In addition, segment routing needs labels equal to the sum of the number of
network-wide nodes and the number of local adjacencies. The label quantity is related
only to the network scale, not to the number of tunnels or the service volume.
Better implements SDN.
Segment routing is designed based on the source routing concept. Using the source node
alone can control forwarding paths over which packets are transmitted across a network.
The segment routing technique and the centralized patch computing module are used
together to flexibly and conveniently control and adjust paths.
2.2 Feature Updates

Version Change Description
V800R009C10 Newly supports SR-BE.
Newly supports node labels in SR-TE.
V800R008C11 Newly supports SR-TE tunnels established
by a controller to run NETCONF to deliver
SR-TE tunnel configurations to a forwarder.
V800R008C10 Newly supports manual SR-TE tunnels.
2.3 Principles
2.3.1 Basic Principles
Basic Concepts
Segment routing involves the following concepts:
Segment routing domain: is a set of nodes based on the source route.
Segment ID (SID): uniquely identifies a segment. A SID is mapped to an MPLS label on
the forwarding plane.
SRGB: A segment routing global block (SRGB) is a set of local labels reserved for
segment routing of users. All nodes in an SR domain use the same SRGB, which is easy
to manage and troubleshoot. Deploying the same SRGB on all nodes is recommended.

Segment Category
Table 2-1 Segment category
Label Generati Function Example

on Mode
Adjacenc Allocated Identifies a link on a network. Figure 2-2
y by the An IGP floods it to the other NEs. The
Segment ingress adjacency segment is visible globally and
using a takes effect locally.
dynamic
protocol. The adjacency SID is a local label out of the
SRGB range.
Prefix Manually Identifies the prefix of a destination address. Figure 2-3
Segment configured An IGP floods it to the other NEs. The prefix
. segment is visible globally and takes effect
globally.
A prefix SID is an offset within the SRGB
range and advertised by a source node. The
receive end uses the local SRGB to compute
label values and generate forwarding entries.
The node segment, a special prefix segment,
identifies a specific node. When an IP address
is configured for a loopback interface, the IP
address functions as the prefix SID that is a
type of node SID.
Figure 2-2 Adjacency SID
1001 1002
1003

Figure 2-3 Prefix SID + Node SID
101 102 103
Prefix SID:
16001
16001
10.1.1.0/24
Node SID:
101, 102, 103
In simple words, a prefix segment indicates a destination address, and an adjacency segment
indicates a link over which data packets travel. The prefix and adjacency segments are similar
to the destination IP address and outbound interface, respectively, in conventional IP
forwarding. In an IGP area, a network element (NE) sends extended IGP messages to flood its
own node SID and adjacency SID. Upon receipt of the message, any NE can obtain
information about the other NEs.
Combining prefix (node) SIDs and adjacency SIDs in sequence can construct any network
path. Every hop on a path identifies a next hop based on the segment information on the top of
the label stack. The segment information is stacked in sequence at the top of the data header.
If segment information at the stack top contains the identifier of another node, the
receive end forwards a data packet to a next hop using ECMP.
If segment information at the stack identifies the local node, the receive end removes
the top segment and proceeds with the follow-up procedure.
In actual application, the adjacency segment, prefix segment, and node segment can be used
independently or in combinations. The following three scenarios are involved.
Prefix Segment
A prefix segment-based forwarding path is computed by an IGP using the SPF algorithm. In
Figure 2-4, node Z is a destination, and its prefix SID is 100. After an IGP floods the prefix
SID, all nodes in the IGP area lean the prefix SID of node Z. Each node runs SPF to compute
the shortest path to node Z. Such a path is a smallest-cost path. If these paths have the same
cost, they perform ECMP. If they have different costs, they perform link backup. The prefix
segment-based forwarding paths are not fixed, and the ingress cannot control the whole
forwarding path.

Figure 2-4 Prefix segment-based forwarding paths
100 100 100

B D F
Cost:1 Cost:1
100
Cost:1 Cost:1
A Primary Z
Loopback
path
Cost:10 Cost:10 Cost:10 X.X.X.X
Secondary Prefix SID=100
path
Cost:2 Cost:2
Cost:2 Cost:2
C E G
Adjacency Segment
In Figure 2-5, an adjacency segment is assigned to each link. The adjacency segments are
contained in a segment list defined on the ingress. The segment list is used to strictly specify
any explicit path. This mode can better implement SDN.
Figure 2-5 Adjacency segment-based forwarding path
2004
4005 4005
5007 5007
1002 7009 7009
2004 B D F
4005 2004
5007
7009 1002
A Z
4005
5007
7009
C E G
5007
7009 7009
Adjacency Segment + Node Segment

In Figure 2-6, adjacency and node segments are combined to forcibly include a specific link
into a path. Nodes can use node segments to compute the shortest path based on SPF or to
load-balance traffic among paths. In this mode, paths are not strictly fixed, and therefore, they
are also called loose explicit paths.

Figure 2-6 Adjacency segment + node segment-based forwarding path
101
4005 4005
100 100
B D Node F
101
4005 SID=101
100
A Z
Pop
4005
Loopback
X.X.X.X
Prefix SID=100
C E G
100 100
SR Forwarding Mechanism
SR can be used directly in the MPLS architecture, where the forwarding mechanism remains.
SIDs are encoded as MPLS labels. The segment list is encoded as a label stack. The segment
to be processed is at the stack top. Once a segment is processed, its label is removed from a
label stack.
Label Conflicts and Handling Rules

Prefix segments are manually configured. These settings on different devices may conflict
with one another. Label conflicts are as follows:
Prefix conflict: The same prefix is associated with two different SIDs.
SID conflict: The same SID is associated with different prefixes.
If label conflicts occur, handle prefix conflicts before SID conflicts and use the following
rules to preferentially select a SID or prefix:
1. A prefix with a larger mask is preferred.
2. The prefix of a smaller value is preferred.
3. A smaller SID is preferred.
For example, label conflicts occur in the following four routes (in the form of prefix/mask
SID):
a. 1.1.1.1/32 1
b. 1.1.1.1/32 2
c. 2.2.2.2/32 3
d. 3.3.3.3/32 1
The process of handling the label conflicts is as follows:
1. Prefix conflicts are handled. Routers a and b lead to a prefix conflict. Route a has a
smaller SID than route b. Route a is preferred. After the conflict is handled, the
following three routes are selected:

a. 1.1.1.1/32 1
c. 2.2.2.2/32 3
d. 3.3.3.3/32 1
2. SID conflicts are handled. Routes a and d lead to a SID conflict. Route a has a smaller
prefix than route d, route a is preferred. After the conflict is handled, the following two
routes are selected:
a. 1.1.1.1/32 1
c. 2.2.2.2/32 3
2.3.2 SR LSP
Segment Routing Best Effort (SR-BE) uses an IGP to run the shortest path algorithm to
compute an optimal SR LSP. SR LSPs are established using the segment routing technique,
uses prefix or node segments to guide data packet forwarding.
The establishment and data forwarding of SR LSPs are similar with those of LDP LSPs. SR
LSPs have no tunnel interfaces.
Creating an SR LSP
Creating an SR LSP involves the following operations:
Devices report topology information to a controller (if the controller is used to create a
tunnel) and are assigned labels.
The devices compute paths.
SR LSPs are created primarily using prefix labels. A destination node runs an IGP to advertise
prefix SIDs, and forwarders parse them and compute label values based on local SRGBs.
Each node then runs an IGP to collect topology information, runs the SPF algorithm to
calculate a label forwarding path, and delivers the computed next hop and outgoing label
(OuterLabel) to the forwarding table to guide data packet forwarding.
Figure 2-7 Prefix label-based LSP establishment and data forwarding
SRGB SRGB SRGB SRGB

[16000-23999] [26000-65535] [36000-65535] [16000-65535]
A B C D Loopback
X.X.X.X
Prefix SID=100
Push Swap Swap Pop
26100 36100 16100
Payload Payload Payload Payload Payload
Table 2-2 describes the process of using prefix labels to create an LSP shown in Figure 2-7.
Table 2-2 LSP creation process
St Dev Operation
e ice
p

St Dev Operation
e ice
p
1 D An SRGB and a prefix SID are configured on a loopback interface of D. D

generates forwarding entries, encapsulates the SRGB and prefix SID into an
LSP (for exmaple, IS-IS Router Capability TLV-242 containing
SR-Capabilities Sub-TLV), and floods the LSP across the whole network
through IGP.
2 C After the other devices receive the LSP, they parse the LSP, obtain the prefix
B SID advertised by device D, and use the prefix to compute labels based on
local SRGBs. They run IGP to compute a label switched path and find
A next-hop devices and outgoing labels.
Device B is used as an example. Device B parses the prefix SID released by
device D and computes a label value based on the local SRGB (26000 to
65535). The value is calculated using the following formula:
Label = SRGB start value + Prefix SID value = 26000 + 100 = 26100
IS-IS calculates an outgoing label based on the following formula:
OuterLabel = SRGB start value advertised by the next hop devices + Prefix
SID value = 36000 + 100 = 36100
In this example, the next-hop device is device C, and device C releases the
SRGB (36000 to 65535).
Data Forwarding
Similar to MPLS, SR-TE operates labels by pushing, swapping, or popping them.
Push: After a packet enters an SR LSP, the ingress adds a label between the Layer 2 and
IP header. Alternatively, the ingress adds a label stack above the existing label stack.
Swap: When packets are forwarded in an SR domain, a node searches the label
forwarding table for a label assigned by a next hop and swaps the label on the top of the
label stack with the matching label in each SR packet.
Pop: After the packets leave out of an SR-TE tunnel, a node finds an outbound interface
mapped to the label on the top of the label stack and removes the top label.
Table 2-3 describes the data forwarding process on the network shown in Figure 2-7.
Table 2-3 Packet forwarding process
St Dev Operation
e ice
p
1 A Receives a data packet, adds label 26100 to the packet, and forwards the
packet.
2 B Receives the labeled packet, swaps label 26100 for label 36100, and forwards
the packet.
3 C Receives the labeled packet, swaps label 36100 for label 16100, and forwards

St Dev Operation
e ice
p
the packet.
4 D Removes label 16100 and forwards the packet along a matching route.
PHP, MPLS QoS, and TTL

Penultimate hop popping (PHP) is enabled on the egress on which a label becomes useless.
The egress assigns a label to a penultimate node on an LSP so that the label is removed to
relieve the burden on the egress. The egress then forwards the packet over an IP route or
based on the next label.
PHP is configured on the egress. In Figure 2-7, PHP is not enabled, and NE-C is a penultimate
hop of an SR tunnel. NE-C uses a valid label to reach NE-D. If PHP is enabled, NE-C sends a
packet without an SR label to NE-D.
Enabling PHP affects both the MPLS QoS and TTL functions. For details, see Table 2-4.
Table 2-4 PHP, MPLS QoS, and TTL
Label Type Description MPLS EXP TTL Scenario

(QoS)
explicit-null PHP is not The MPLS The TTL Label resources

supported. The EXP field is processing is on the egress
egress assigns reserved. QoS normal. are saved. If
an explicit-null is supported. E2E services
label. The IPv4 carry QoS
explicit-null attributes to be
label value is 0. contained in the
EXP field in a
label, an
explicit-null can
be used.
implicit-null PHP is The MPLS The TTL field The forwarding
supported. The EXP field is is lost. burden on the
egress assigns lost, and QoS is egress is
an implicit-null not supported. reduced, and
label. The forwarding
implicit-null efficiency is
label value is 3. improved.
If an
implicit-null
label is
distributed to an
NE, the NE
directly
removes the
label without
having to swap

Label Type Description MPLS EXP TTL Scenario

(QoS)
an existing
label at the top
of the stack for
it. The egress
then forwards
the packet over
an IP route or
based on the
next label.
non-null PHP is not The MPLS The TTL Using a
supported. The EXP field is processing is non-null label
egress assigns a reserved. QoS normal. consumes a
common label is supported. great number of
to a penultimate resources on the
hop. egress and is
not
recommended.
The non-null
label helps the
egress identify
various types of
services.
RFC 3443 defines two MPLS TLL processing modes: uniform and pipe.
Uniform: The egress copies the TTL value in an MPLS packet to the TTL field in the IP
or inner packet.
Pipe: The egress does not copy the TTL value in an MPLS packet to the TTL field in the
IP or inner packet.
2.3.3 IS-IS SR
Segment routing uses an IGP to advertise topology information, prefix information, a segment
routing global block (SRGB), and label information. To complete the preceding functions, the
IGP extends some TLVs of protocol packets. IS-IS mainly defines sub-TLVs that enable SID
and NE SR capabilities.
IS-IS SID TLV Extensions

Prefix-SID Sub-TLV
The Prefix-SID sub-TLV carries IGP-Prefix-SID information. Figure 2-8 shows the format of
the Prefix-SID sub-TLV.

Figure 2-8 Prefix-SID Sub-TLV format
0 7 15 23 31
Type Length Flags Algorithm
SID/Index/Label (variable)
Table 2-5 Meanings of fields in the Prefix-SID Sub-TLV
Field Name Length Description

Type 8 bits Unassigned. The recommended value is 3.
Length 8 bits Packet length.
Flags 8 bits Flags field. Figure 2-9 shows its format.
Figure 2-9 Flags field
Flags
R N P E V L
The meaning of each flag is as follows:

R: re-advertised flag. If this flag is set, a prefix is imported
from another protocol or penetrates from another level
(such as when a prefix is penetrated from an IS-IS Level 1
area to a Level 2 area).
N: node SID flag. If this flag is set, a prefix SID identifies
a node. If a prefix SID is set to a loopback interface
address, this flag bit is set.
P: no-PHP flag. If this flag is set, PHP is disabled so that
the penultimate node sends a labeled packet to the egress.
E: explicit null label flag. If this flag is set, the explicit
null label function is enabled. An upstream neighbor must
replace an existing label with an explicit null label before
forwarding a packet.
V: value flag. If this flag is set, a prefix SID carries a
value, instead of an index. By default, the flag is not set.
L: local flag. If this flag is set, the value or index carried
in a prefix SID is of local significance. By default, the flag
is not set.
A node must compute an outgoing prefix label based on the P
and E flags in a prefix SID advertised by a next hop,
regardless whether the optimal path to the prefix SID passes
through the next hop. When a node advertises reachability
messages (for example, from Level-1 to Level-2) generated
by another IS-IS Speaker, the local node must set the P flag


and clear the E flag in a prefix SID.
The following behavior is related to P and E flags:
If the P flag is not set, any upstream node of the prefix
SID producer must strip off the prefix SID, which is
similar to PHP in MPLS forwarding. The MPLS EXP bit
is also cleared. In addition, if the P flag is not set, the
received E flag bit is ignored.
If the P flag is set, the following situations occur:
If the E flag is not set, any upstream node of the prefix
SID producer must reserve the prefix SID on the top of
the label stack. This method is used in path stitching.
For example, a prefix SID producer may use this label
to forward a packet to another MPLS LSP.
If the E flag is set, any upstream node of the prefix
SID producer must replace the prefix SID label with an
explicit null label. In this mode, the MPLS EXP flag is
retained. If the prefix SID producer is the destination,
the node can receive the original MPLS EXP field
value. The MPLS EXP flag can be used in QoS
services.
Algorithm 8 bits Algorithm:
0: Shortest Path First
1: Strict Shortest Path First
SID/Index/L Variable This field contains either of the following information based
abel length on the V and L flags:
(variable) 4-byte label offset value, within an ID/label range. In this
case, V and L flags are not set.
3-byte local label: The rightmost 20 bits are a label value.
In this case, the V and L flags must be set.
Adj-SID Sub-TLV
An Adj-SID Sub-TLV is optional and carries IGP Adjacency SID information. Figure 2-10
shows its format.
Figure 2-10 Adj-SID Sub-TLV format
0 7 15 23 31
Type Length Flags Weight
SID/Label/Index (variable)
Table 2-6 Meanings of fields in the Adj-SID Sub-TLV


Flags
F B V L S P

F: address family flag.
0: IPv4
1: IPv6
B: backup flag. If the flag is set, an Adj-SID is used to
protect another node.
V: value flag. If this flag is set, an Adj-SID carries a label
value. The flag is set by default.
L: local flag. If this flag is set, the Adj-SID value or index
is of local significance. The flag is set by default.
S: sequence flag. If this flag is set, an Adj-SID is an
adjacency sequence.
P: permanent label. If this flag is set, an Adj-SID is a
permanently assigned SID, which is unchanged,
regardless of a device restart or interface flapping.
Weight 8 bits Weight. The Adj-SID weight is used for load balancing.
SID/Index/L Variable This field contains either of the following information based
abel length on the V and L flags:
(variable) 3-byte local label: The rightmost 20 bits are a label value.
In this case, the V and L flags must be set.
4-byte label offset value, within an ID/label range. In this
case, V and L flags are not set.
A designated intermediate system (DIS) is elected as a medium during IS-IS communication

on a LAN. On the LAN, an NE merely needs to advertise a link message to the DIS and
obtain all link information from the DIS, but does not need to exchange link information
between NEs.
In Segment routing implementation, each NE advertises Adj-SIDs to all neighbors. On the
LAN, each NE advertises only an Adj-SID to the DIS and encapsulates neighbors' Adj-SIDs
in a new TLV, which is a LAN-Adj-SID Sub-TLV. The TLV contains all Adj-SID that the NE
allocates to all LAN neighbors.

Figure 2-12 shows the format of the LAN-Adj-SID Sub-TLV.
Figure 2-12 LAN-Adj-SID Sub-TLV format
0 7 15 23 31
Type Length Flags Weight
System-ID
(6 octets)
SID/Label/Index (variable)
SID/Label Sub-TLV
A SID/Label Sub-TLV includes a SID or an MPLS label. The SID/Label Sub-TLV is a part of
the SR-Capabilities Sub-TLV and SR Local Block Sub-TLV.
Figure 2-13 shows the format of the SID/Label Sub-TLV.
Figure 2-13 SID/Label Sub-TLV format
0 7 15 23 31
Type Length
SID/Label (variable)
Table 2-7 Meanings of fields in the SID/Label Sub-TLV

SID/Label Variable If the Length field value is set to 3, the rightmost 20 bits
(variable) length indicate an MPLS label.
IS-IS SR Capability TLV Extension

SR-Capabilities Sub-TLV
In segment routing, each NE must be able to advertise its SR capability and global SID range
(or global label index). To implement the preceding requirement, an SR-Capabilities Sub-TLV
is defined and embed in the IS-IS Router Capability TLV-242 for transfer. The
SR-Capabilities Sub-TLV can be propagated only within the same IS-IS level area.
Figure 2-14 shows the format of the SR-Capabilities Sub-TLV.

Figure 2-14 SR-Capabilities Sub-TLV format
0 7 15 23 31
Type Length Flags
Range
SID/Label Sub-TLV (variable)
Table 2-8 Meanings of fields in the SR-Capabilities Sub-TLV

Flags
I V

I: MPLS IPv4 flag. If the flag is set, SR MPLS IPv4
packets received by all interfaces can be processed.
V: MPLS IPv6 flag. If the flag is set, SR MPLS IPv6
packets received by all interfaces can be processed.
Range 8 bits SRGB range.
The advertising end releases the following SR-Capabilities in
the following ranges.
SR-Capability 1:Range: 100, SID value: 100
SR-Capability 2: Range: 100, SID value: 1000
SR-Capability 3: Range: 100, SID value: 500
The receive end links the preceding ranges and generates an
SRGB.
SRGB = [100, 199]
[1000, 1099]
[500, 599]
Different label indexes may span multiple ranges.
Index 0: label 100
...
Index 99: label 199
Index 100: label 1000
...


...
SID/Label Variable See SID/Label Sub-TLV. The SRGB start value is included.
Sub-TLV length When multiple SRGBs are configured, ensure that the SRGB
(variable) sequence is correct and the SRGBs do not overlap.
SR-Algorithm Sub-TLV
NEs use different algorithms, for example, the SPF algorithm and various SPF variant
algorithms, to compute paths to the other nodes or prefixes. The newly defined SR-Algorithm
Sub-TLV enables an NE to advertise its own algorithm. The SR-Algorithm Sub-TLV is also
carried in the IS-IS Router Capability TLV-242 for transfer. The SR-Algorithm Sub-TLV can
be propagated within the same IS-IS level.
Figure 2-16 shows the format of the SR-Algorithm Sub-TLV.
Figure 2-16 SR-Algorithm Sub-TLV format
0 7 15 23 31
Type Length
Algorithm 1 Algorithm 2 Algorithm ... Algorithm n
Table 2-9 Meanings of fields in the SR-Algorithm Sub-TLV

Algorithm 8 bits Algorithm.
SR Local Block Sub-TLV

The SR Local Block Sub-TLV contains a label range that an NE reserves for local SIDs. The
local SIDs are used as adjacency SIDs or are allocated by the other components. For example,
an application (App) or a controller instructs the NE to assign a special local SID. To notify
the App or controller of available local SIDs, the NE must advertise an SR local block SRLB.
Figure 2-17 shows the format of the SR Local Block Sub-TLV.

Figure 2-17 SR Local Block Sub-TLV format
0 7 15 23 31
Type Length Flags
Range One or
SID/Label Sub-TLV (variable) more
Table 2-10 Meanings of fields in the SR Local Block Sub-TLV

Flags 8 bits Flags field. This field is not defined.
Range 8 bits SRLG range.
SID/Label Variable See SID/Label Sub-TLV. The SRGB start value is included.
Sub-TLV length When multiple SRGBs are configured, ensure that the SRGB
(variable) sequence is correct and the SRGBs do not overlap.
The SRLB TLV advertised by the NE may contain a label range that is out of the SRLB. Such
a label range is assigned locally and is not advertised in the SRLB. For example, an adjacency
SID is assigned a local label, not a label within the SRLB range.
IS-IS SR LSP Creation

An intra-IGP-area SR LSP is created.
In Figure 2-18, devices run IS-IS. Segment routing is used and enables each device to
advertise the SR capability and supported SRGB. In addition, the advertising end advertises a
prefix SID offset within the SRGB range. The receive end computes an effective label value
to generate a forwarding entry.

Figure 2-18 IS-IS SR LSP creation
SRGB SRGB
[26000-65535] [36000-65535]
Device B Device C
SRGB SRGB
[16000-23999] [16000-65535]
Device D
Device A Loopback X.X.X.X
Prefix SID=100
Device E Device F
Devices A through F are deployed in areas of the same level. All Devices run IS-IS. An SR
tunnel originates from Device A and is terminated at Device D. An SRGB is configured on
Device D. A prefix SID is set on the loopback interface of Device D. Device D encapsulates
the SRGB and prefix SID into a link state protocol data unit (LSP) (for example, IS-IS Router
Capability TLV-242 containing SR-Capability Sub-TLV) and floods the LSP across the
network. After another Device receives the SRGB and prefix SID, it uses them to compute a
forwarding label, uses the IS-IS topology information, and runs the Dijkstra algorithm to
calculate an LSP and LSP forwarding entries.
An inter-IGP area SR LSP is created
In Figure 2-19, to establish an inter-area SR LSP, the prefix SID must be advertised across
areas by penetrating these areas. This overcomes the restriction on IS-IS's flooding scope
within each area.
Figure 2-19 Inter-IGP area SR LSP
SRGB SRGB
[26000-65535] [36000-65535]
Device B Device C
Level-1/2 Level-1/2
SRGB SRGB
[16000-23999] [16000-65535]
Device D
Area2 Level-1
Device A Loopback X.X.X.X
Area1 Level-1 Prefix SID=100
Device E Device F
Devices A through D are deployed in different areas, and all devices run IS-IS. An SR tunnel
originates from Device A and is terminated at Device D. An SRGB is configured on Device D.
A prefix SID is set on the loopback interface of Device D. Device D generates and delivers
forwarding entries. It encapsulates the SRGB and prefix SID into an LSP (for example, IS-IS
Router Capability TLV-242 containing SR-Capability Sub-TLV) and floods the LSP across

the network. Upon receipt of the LSP, Device C parses the LSP to obtain the prefix SID,
calculates and delivers forwarding entries, and penetrates the prefix SID and prefix address to
the Level-2 area. Device B parses the LSP to obtain the prefix SID, calculates and delivers
forwarding entries, and penetrates the prefix SID and prefix address to the Level-1 area.
Device B parses the LSP and obtains the prefix SID, uses IS-IS to collect topology
information, and runs the Dijkstra algorithm to compute a label switched path and tunnel
forwarding entries.
2.3.4 SR-TE
SR-Traffic Engineering (SR-TE) is a new Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) tunneling technique implemented based on an Interior Gateway Protocol
(IGP) extension. The controller calculates a path for an SR-TE tunnel and forwards a
computed label stack to the ingress configured on a forwarder. The ingress uses the label stack
to generate an LSP in the SR-TE tunnel. Therefore, the label stack is used to control the path
along which packets are transmitted on a network.
SR-TE Advantages
SR-TE tunnels are capable of meeting the rapid development requirements of
software-defined networking (SDN), which Resource Reservation Protocol-TE (RSVP-TE)
tunnels are unable to meet.Table 2-11 describes the comparison between SR-TE and
RSVP-TE.
Table 2-11 Comparison between SR-TE and RSVP-TE tunnels
Item SR-TE RSVP-TE

Label The extended IGP assigns and Each LSP is assigned a label, which
allocatio distributes MPLS labels. Each link is consumes a great number of labels
n assigned only a single label, and all resources and results in heavy
LSPs share the label, which reduces workloads maintaining label
resource consumption and forwarding tables.
maintenance workload of label
forwarding tables.
Control An IGP is used, which reduces the RSVP is used, and the control plane is
plane number of protocols to be used. complex.
Path Path planning and access control are There is no centralized controller to
adjustme centralized on the controller, and perform path planning and access
nt and paths can be flexibly controlled. control. The path control capability is
control A service path can be controlled by poor.
operating a label only on the ingress. Configurations must be delivered to
Configurations do not need to be each node.
delivered to each node, which
improves programmability.
Related Concepts
Label Stack

A label stack is a set of Adj Segment labels in the form of a stack stored in a packet header.
Each Adj SID label in the stack identifies a link to a local node, and the label stack describes
all links along an SR-TE LSP. In packet forwarding, a node searches for a link mapped to
each Adj Segment label in a packet, removes the label, and forwards the packet. After all
labels are removed from the label stack, the packet is sent out of an SR-TE tunnel.
Stick Label and Stick Node
If a label stack depth exceeds that supported by a forwarder, the label stack cannot carry all
link labels on a whole LSP. In this situation, the controller assigns multiple label stacks to the
forwarder. The controller delivers a label stack to an appropriate node and assigns a special
label to associate label stacks to implement segment-based forwarding. The special label is a
stitching label, and the appropriate node is a stitching node.
The controller assigns a stitching label at the bottom of a label stack to a stitching node. After
a packet arrives at the stitching node, the stitching node swaps a label stack associated with
the stitching label based on the label-stack mapping. The stitching node forwards the packet
based on the label stack for the next segment.
Topology Collection and Label Allocation
Network Topology Collection Modes

Network topology information is collected in either of the following modes:
A forwarder runs IS-IS to collect network topology information and report the
information to the controller.
Both the controller and forwarders run IS-IS. Each forwarder floods network topology
information to one another. Each forwarder reports the information to the controller.
Label Allocation Modes

Allocated by forwarders
A forwarder runs an IGP (IS-IS is supported only) to assign labels and reports label
information to a controller. SR-TE uses link labels (adjacency segment). Link labels are
assigned by the ingress. They are valid locally and unidirectional. Link labels are advertised
using IS-IS. In Figure 2-20, link label 9003 identifies the PE1-to-P1 link and is assigned by
PE1. Link label 9004 identifies the P3-to-PE1 link and is assigned by P3.

Figure 2-20 IS-IS label assignment
IS-IS SR is enabled on PE1, PE2, and P1 through P4 to establish IS-IS neighbor relationships
between each pair of directly connected nodes. In SR-capable IS-IS instances, each outbound
IS-IS interface is assigned an SR Adj Segment label. SR IS-IS advertises the Adj Segment
labels across a network. P3 is used as an example. In Figure 2-20, IS-IS-based label allocation
is as follows:
1. P3 runs IS-IS to apply for a local dynamic label for a direct link. For example, P3 assigns
link label 9002 to the P3-to-P4 link.
2. P3 runs IS-IS to advertise the link label and flood it across the network.
3. P3 uses the label to generate a label forwarding table.
4. After the other nodes on the network run IS-IS to learn the Adj Segment label advertised
by P3, the nodes do not generate local forwarding tables.
PE1, P1, P2, P3, and P4 assign and advertise link labels in the same way as P3 does. The label
forwarding table is then generated on each node. Each node establishes an IS-IS neighbor
relationship with the controller, generates topology information, including SR labels, and
reports topology information to the controller. A node establishes an IS-IS neighbor
relationship with the controller, generates topology information, including SR labels, and
reports topology information to the controller.
Allocated by the controller
The controller runs NETCONF to assign SR labels to forwarders.

Figure 2-21 Controller-based label allocation
In Figure 2-21, the controller and forwarder have IS-IS configured. IS-IS collects network
topology information and reports it the controller. The controller assigns a label to each link
and runs NETCONF to deliver labels to the ingress forwarder. The forwarder generates a link
label forwarding table.
SR-TE Tunnel Establishment
SR-TE Tunnel
Segment Routing Traffic Engineering (SR-TE) runs the SR protocol and uses TE constraints
to create a tunnel. The tunnel contains multiple LSPs that share a tunnel interface.

Figure 2-22 SR-TE Tunnel
P1 P2
PE1 PE2
SR-TE Tunnel
P3 P4
Primary LSP
Backup LSP
In Figure 2-22, a primary LSP is established along the path PE1->P1->P2->PE2, and a backup
path is established along the path PE1->P3->P4->PE2. The two LSPs have the same tunnel ID
of an SR-TE tunnel. The LSP originates from the ingress, passes through transit nodes, and is
terminated at the egress.
SR-TE tunnel establishment involves configuring and establishing an SR-TE tunnel. Before
an SR-TE tunnel is created, IS-IS neighbor relationships must be established between
forwarders to implement network layer connectivity, to assign labels, and to collect network
topology information. Forwarders send label and network topology information to the
controller, and the controller uses the information to calculate paths.
SR-TE Tunnel Configuration

SR-TE tunnel attributes are used to create tunnels. An SR-TE tunnel can be configured on a
controller or a forwarder.
An SR-TE tunnel is configured on a controller.
The controller runs NETCONF to deliver tunnel attributes to a forwarder (as shown in
Figure 2-23). The forwarder runs PCEP to delegate the tunnel to the controller for
management. (Upon receipt of the SR-TE tunnel configuration, the forwarder runs PCEP
to delegate LSPs to the controller. The controller calculates paths, generates labels, and
maintains the SR-TE tunnels.)
An SR-TE tunnel is manually configured on a forwarder.
An SR-TE tunnel is manually configured on a forwarder. The forwarder delegates LSPs
to the controller for management.
SR-TE Tunnel Establishment

If a service (for example, VPN) is bound to an SR-TE tunnel, a device establishes an SR-TE
tunnel based on the following process, as shown in Figure 2-23.

Figure 2-23 Networking for SR-TE tunnels established using configurations that a controller runs
NETCONF to deliver to a forwarder
The process of establishing an SR-TE tunnel is as follows:

1. The controller uses SR-TE tunnel constraints and Path Computation Element (PCE) to
calculate paths and combines link labels into a label stack that is the calculation result.
If the label stack depth exceeds the upper limit supported by a forwarder, the label stack
can only carry some labels, and the controller needs to divide a label stack into multiple
stacks for an entire path.
In Figure 2-23, the controller calculates a path PE1->P3->P1->P2->P4->PE2 for an
SR-TE tunnel. The path is mapped to two label stacks {1003, 1006, 100} and {1005,
1009, 1010}. Label 100 is a stitching label, and the others are link labels.
2. The controller runs NETCONF to deliver the label stacks to the forwarder.
In Figure 2-23, the process of delivering label stacks on the controller is as follows:
a. The controller delivers label stack {1005, 1009, 1010} to P1 and assigns a stitching
label of value 100 associated with the label stack. Label 100 is the bottom label in
the label stack on PE1.
b. The controller delivers label stack {1003, 1006, 100} to the ingress PE1.
3. The forwarder uses the delivered label stacks to establish an LSP for an SR-TE tunnel.
An SR-TE tunnel does not support MTU negotiation. Therefore, the MTUs configured on nodes along
the SR-TE tunnel must be the same. If an SR-TE tunnel is created manually, set an MTU value on the
tunnel interface or use the default MTU of 1500 bytes. On the SR-TE tunnel, the smaller value between
MTUs on the tunnel interface and outbound interface takes effect.

SR-TE Data Forwarding

A forwarder operates a label in a packet based on the label stack mapped to the SR-TE LSP,
searches for an outbound interface hop by hop based on the top label of the label stack, and
uses the label to guide the packet to the tunnel destination address.
SR-TE Data Forwarding (Link)

In Figure 2-24, an example is provided to describe the process of forwarding SR-TE data with
manually specified link labels.
Figure 2-24 SR-TE data packet forwarding (based on link labels)
In Figure 2-24, the SR-TE path calculated by the controller is A -> B -> C -> D -> F -> E. The
path is mapped to two label stacks {1003, 1006, 100} and {1005, 1009, 1010}. The two label
stacks are delivered to ingress A and stitching node C, respectively. Label 100 is a stitching
label and is associated with label stack {1005, 1009, 1010}. The other labels are link labels.
Process of forwarding data packets along an SR-TE tunnel is shown as following:
1. The ingress A adds a label stack of {1003, 1006, 100}. The ingress A uses the outer label
of 1003 in the label stack to match against a link and finds A-B link as an outbound
interface. The ingress A strips off label 1003 from the label stack {1003, 1006, 100} and
forwards the packet downstream through A-B outbound interface.
2. Node B uses the outer label of 1006 in the label stack to match against a link and finds
B-C link as an outbound interface. Node B strips off label 1006 from the label stack
{1006, 100}. The pack carrying the label stack {100} travels through the B-to-C link to
the downstream node C.

3. After stitching node C receives the packet, it identifies stitching label 100 by querying
the stitching label entries, swaps the label for the associated label stack {1005, 1009,
1010}. Stitching node C uses the top label 1005 to search for an outbound interface
connected to the C-to-D link and removes label 1005. Stitching node C forwards the
packet carrying the label stack {1009, 1010} along the C-to-D link to the downstream
node D. For more details about stick label and stick node, see 2.3.4 SR-TE.
4. After nodes D and E receive the packet, they treat the packet in the same way as node B.
Node E removes the last label 1010 and forwards the data packet to node F.
5. Egress F receives the packet without a label and forwards the packet along a route that is
found in a routing table.
The preceding information shows that after link labels are manually specified, devices strictly
forward the data packets hop by hop along the explicit path designated in the label stack. This
forwarding method is also called strict explicit-path SR-TE.
SR-TE Data Forwarding (Node+Link)

The node+link mixed label stack can be manually specified. With this stack used, the
inter-node node labels can be set. The controller runs PCEP or NETCONF to deliver the stack
to the forwarder ingress, and forwarders use the label stack to forward packets through
outbound interfaces to the destination IP address of an LSP.
Figure 2-25 SR-TE forwarding principles (node+link)
On the network shown in Figure 2-25, a node+link mixed label stack is configured. On the
ingress node A, the mixed label stack is {1000, 2000, 101}. Labels 1000 and 2000 are link
labels, and label 101 is a node label.
1. Node A finds an A-D outbound interface based on label 1000 on the top of the label
stack. Node A removes label 1000 and forwards the packet to the next hop node D.

2. Similar to node A, node D finds the outbound interface mapped to label 2000 on the top
of the label stack. Node D removes label 2000 and forwards the packet to the next hop
node F.
3. Node F processes label 1001 on the top of the label stack. This label is to perform load
balancing. Node F replaces this label with labels 201 and 301 and forwards the packet to
nodes H and E. Traffic packets are balanced on links based on 5-tuple information.
4. After receiving node labels 201 and 301, nodes H and E that are at the penultimate hops
removes labels and forwards packets to node G to complete the E2E traffic forwarding.
The preceding information shows that after link and node labels are manually specified, a
device can forward the data packets along the shortest path or load-balance the data packets
over paths. The paths are not fixed, and therefore, this forwarding method is called loose
explicit-path SR-TE.
BFD for SR-TE

SR-TE does not use a protocol. Once a label stack is delivered to an SR-TE node, the node
establishes an SR-TE LSP. The LSP does not encounter the protocol Down state, except for
the situation when the label stack is withdrawn. Therefore, BFD must be used to monitor
faults in the SR-TE LSP. A fault detected by BFD triggers a primary/backup SR-TE LSP
switchover. BFD for SR-TE is an E2E rapid detection mechanism that rapidly detects faults in
links of an SR-TE tunnel. BFD for SR-TE modes are as follows:
BFD for SR-TE LSP: SR-TE LSPs rely on BFD for link detection. If a BFD session has
not been established when an SR-TE LSP is created, the LSP remains Down. To prevent
traffic loss in the case of a primary SR-TE LSP failure, BFD for SR-TE LSP can be
configured, but a backup LSP must be available. BFD for SR-TE LSP supports both
static and dynamic BFD sessions:
Static BFD session: The local and remote discriminators are manually specified.
The local discriminator of the local node must be equal to the remote discriminator
of the remote node. The remote discriminator of the local node must be equal to the
local discriminator of the remote node. A discriminator inconsistency causes a
failure to establish a BFD session. After the BFD session is established, the interval
at which BFD packets are received and the interval at which BFD packets are sent
can be modified.
Dynamic BFD session: The local and remote discriminators do not need to be
manually specified. After a routing protocol neighbor relationship is established, the
RM delivers parameters to instruct the BFD module to establish a BFD session. The
devices on both ends of a BFD session to be established negotiate the local
discriminator, remote discriminator, interval at which BFD packets are received,
and interval at which BFD packets are sent.
A BFD session is bound to an SR-TE LSP. This means that a BFD session is established
between the ingress and egress. A BFD packet is sent by the ingress and forwarded to the
egress through an LSP. The egress responds to the BFD packet. A BFD session on the
ingress can rapidly detect the status of the path through which the LPS passes.
If a link fault is detected, the BFD module notifies the forwarding plane of the fault. The
forwarding plane searches for a backup SR-TE LSP and switches traffic to the backup
SR-TE LSP.
BFD for SR-TE tunnel: BFD for SR-TE tunnel must be used with BFD for SR-TE LSP.
BFD for SR-TE LSP controls the status of the primary/backup LSP switchover.
BFD for SR-TE tunnel checks actual status of tunnels.
If BFD for SR-TE tunnel is not configured, the default tunnel status keeps Up,
and the effective status cannot be determined.

If BFD for SR-TE tunnel is configured and the BFD status is set to
administrative Down, the BFD session does not work, and the tunnel interface
status is unknown.
BFD for SR-TE tunnel is configured and the BFD status is not set to
administrative Down, the tunnel interface status is inconsistent with the BFD
status.
The interface status of an SR-TE tunnel keeps consistent with the status of BFD for
SR-TE tunnel. The BFD session goes Up slowly because of BFD negotiation. If a
new label stack is delivered for a tunnel in the Down state and the BFD for this
tunnel goes Up, the process takes more than 10 seconds. As a result, hard tunnel
convergence is delayed if no protection is enabled for the tunnel.
BFD for SR-TE (one-arm mode): A Huawei device on the ingress cannot use BFD for
SR-TE LSP to communicate with a non-Huawei device on the egress. In this situation,
no BFD session can be established. In this case, one-arm BFD for SR-TE can be used.
On the ingress, enable BFD and specify the one-arm mode to establish a BFD session.
After the BFD session is established, the ingress sends BFD packets to the egress
through transit nodes along an SR-TE tunnel. After the forwarding plane receives BFD
packets, it removes MPLS labels and searches for a route matching the destination IP
address of the ingress. The forwarding plane on the egress loops back the BFD packets to
the ingress. The ingress processes the BFD packets. This process is the one-arm
detection mechanism.
In the following example, VPN traffic is iterated to an SR-TE LSP, in the scenario of which
BFD for SR-TE LSP is used.
Figure 2-26 BFD for SR-TE
Link header
9004
9003
9005
A E
VPN label P1 P2 Link header
IP header IP header
Payload Payload
BFD
CE1 PE1 PE2 CE2
PE1->P4: 9004 P3->PE2: 9005
Link header Link header

9003 P4->P3: 9003 VPN label
9005 IP header
VPN label Payload
IP header P4 Link header P3
Payload 9005
Primary SR-TE LSP
VPN label
Backup SR-TE LSP
IP header
Payload BFD Session

A, CE1, CE2, and E are deployed on the same VPN, and CE2 advertises a route to E. PE2
assigns the VPN label to E. PE1 installs the route to E and the VPN label. The path of the
SR-TE tunnel from PE1 to PE2 is PE1 -> P4 -> P3 -> PE2, and the label stack is {9004, 9003,
9005}. When A sends a packet destined for E, PE1 finds the packet's outbound interface based
on label 9004 and adds label 9003, label 9005, and the inner VPN label assigned by PE2.
Configure BFD to monitor the SR-TE tunnel. If BFD enters the DetectDown state, the VPN is
iterated to another SR-TE tunnel.
2.3.5 Importing Traffic

After an SR LSP or SE-TE tunnel is established, service traffic needs to be imported to the SR
LSP or SR-TE tunnel. The common methods are to use a static route, tunnel policies, or an
automatic route. Services include public network services, EVPN, L2VPN, and L3VPN.
Table 2-12 Support for tunnels
Traffic Direction SR LSP SR-TE Tunnel

Mode/Tunnel
Type
Static route No tunnel interface is available. A tunnel interface is available.

Therefore, auto routes cannot be A static route can direct traffic
used to direct traffic to SR to an SR-TE tunnel.
LSPs.
Tunnel policy The tunnel select-sequence Either the tunnel
method can be used, whereas a select-sequence method or a
tunnel binding policy cannot be tunnel binding policy can be
used. used.
Auto route No tunnel interface is available. A tunnel interface is available.
Therefore, auto routes cannot be An auto route can direct traffic
used to direct traffic to SR to an SR-TE tunnel.
LSPs.
Static Route
Static routes on an SR-TE tunnel work in the same way as common static routes. When
configuring a static route, set the outbound interface of a static route to an SR-TE tunnel
interface so that traffic transmitted over the route is directed to the SR-TE tunnel.
Tunnel Policy
By default, VPN traffic is forwarded through LDP LSPs, not SR LSPs or SR-TE tunnels. If
the default LDP LSPs cannot meet VPN traffic requirement, a tunnel policy is used to direct
VPN traffic to an SR LSP or an SR-TE tunnel.
The tunnel policy may be a tunnel type prioritizing policy or a tunnel binding policy. Select
either of the following policies as needed:
Select-seq mode: This policy changes the type of tunnel selected for VPN traffic. An SR
LSP or SR-TE tunnel is selected as a public tunnel for VPN traffic based on the
prioritized tunnel types. If no LDP LSPs are available, SR LSPs are selected by default.

Tunnel binding mode: This policy defines a specific destination IP address, and this
address is bound to an SR-TE tunnel for VPN traffic to guarantee QoS.
Auto Route
An IGP uses an auto route related to an SR-TE tunnel that functions as a logical link to
compute a path. The tunnel interface is used as an outbound interface in the auto route.
According to the network plan, a node determines whether an LSP link is advertised to a
neighbor node for packet forwarding. An auto route is configured using either of the following
methods:
Forwarding shortcut: The node does not advertise an SR-TE tunnel to its neighbor nodes.
The SR-TE tunnel can be involved only in local route calculation, but cannot be used by
the other nodes.
Forwarding adjacency: The node advertises an SR-TE tunnel to its neighbor nodes. The
SR-TE tunnel is involved in global route calculation and can be used by the other nodes.
Forwarding shortcut and forwarding adjacency are mutually exclusive, and cannot be used
simultaneously.
When the forwarding adjacency is used, a reverse tunnel must be configured for a routing protocol
to perform bidirectional check after a node advertises LSP links to the other nodes. The forwarding
adjacency must be enabled for both tunnels in opposite directions.
Policy-Based Routing
The policy-based routing (PBR) allows a device to select routes based on user-defined
policies, which improves traffic security and balances traffic. If PBR is enabled on an SR
network, IP packets are forwarded over specific LSPs based on PBR rules.
SR-TE PBR, the same as IP unicast PBR, is implemented by defining a set of matching rules
and behaviors. The rules and behaviors are defined using the apply clause with an SR-TE
tunnel interface used as an outbound interface. If packets do not match PBR rules, they are
properly forwarded using IP; if they match PBR rules, they are forwarded over specific
tunnels.
Public IP Routes Iterated to SR LSPs
Public Network BGP Route Iterated to an SR LSP

If an Internet user performs IP forwarding to access the Internet, core devices on a forwarding
path must learn many Internet routes. This imposes a heavy load on the core devices and
affects the performance of these devices. To tackle the problems, a user access device can be
configured to iterate non-labeled public network BGP or static routes to a segment routing
(SR) LSP. User packets travel through the SR LSP to access the Internet. The iteration to the
SR LSP prevents the problems induced by insufficient performance, heavy burdens, and
service transmission on the core devices on the network.

Figure 2-27 Public network BGP route iterated to an SR LSP
SRGB SRGB SRGB SRGB

[16000-65535] [26000-65535] [36000-65535] [16000-65535]
PE1 P1 Segment P2 PE2
Routing
Loopback
X.X.X.X
Internet Prefix SID=100
BGP
26100 36100 16100

IP head IP head IP head IP head IP head
In Figure 2-27, the deployment is as follows:

A BGP peer relationship between PEs is established to enable the PEs to learn the peer
routes.
An E2E IS-IS neighbor relationship is established between each pair of directly
connected devices, and segment routing is configured on PEs and Ps.
A BGP route is iterated to an SR LSP on each PE.
Static Route Iterated to an SR LSP

The next hop of a static route may be unreachable. Such a route must be iterated to a path. If
such a static route is iterated to an SR LSP, packets over the static route are forwarded based
on labels.
Figure 2-28 Static route iterated to an SR LSP
SRGB SRGB SRGB SRGB

[16000-65535] [26000-65535] [36000-65535] [16000-65535]
PE1 P1 Segment P2 PE2
Routing
Loopback
X.X.X.X
Internet Prefix SID=100
26100 36100 16100


A static route is configured on PE1. The next-hop IP address is set to PE2's loopback IP
address.

PE1 establishes an SR LSP destined for PE2's loopback IP address.

After receiving an IP packet, PE1 adds a label into the packet and forwards the packet
along the SR LSP.
L3VPN Iterated to SR LSPs
Basic VPN Iterated to an SR LSP

If an Internet user performs IP forwarding to access the Internet, core devices on a forwarding
path must learn many Internet routes. This imposes a heavy load on the core devices and
affects the performance of these devices. To tackle the problems, a VPN instance can be
iterated to a segment routing (SR) LSP, and users access the Internet through the SR LSP.
Figure 2-29 Basic VPN iterated to an SR LSP
SRGB SRGB SRGB SRGB

[16000-65535] [26000-65535] [36000-65535] [16000-65535]
PE1 P1 Segment P2 PE2 Loopback
Routing X.X.X.X
Prefix SID=100
CE1 CE2
BGP
26100 36100
Label Z Label Z Label Z
The network shown in Figure 2-29 consists of inconsecutive L3VPN subnets with a backbone
network in between. PEs establish an SR LSP to forward L3VPN packets. PEs run BGP to
learn VPN routes. The deployment is as follows:
An IS-IS neighbor relationship is established between each pair of directly connected
devices on the public network to implement route reachability.
A BGP peer relationship is established between the two PEs to learn peer VPN routes of
each other.
The PEs establish an IS-IS SR LSP to assign public network labels and compute a label
switched path.
BGP is used to assign a private network label, for example, label Z, to a VPN instance.
VPN routes are iterated to the SR LSP.
PE1 receives an IP packet, adds the private network label and SR public network label to
the packet, and forwards the packet along the label switched path.
HVPN
On a growing network with increasing types of services, PEs encounter scalability problems,
such as insufficient access or routing capabilities, which reduces network performance and
scalability. In this situation, VPNs cannot be deployed in a large scale. In Figure 2, on a

hierarchical VPN (HVPN), PEs play different roles and provide various functions. These PEs
form a hierarchical architecture to provide functions that are provided by one PE on a
non-hierarchical VPN. HVPNs lower the performance requirements for PEs.
Figure 2-30 HVPN
SRGB SRGB
[16000-65535] Lv Lu [16000-65535]
L4 L3
UPE SPE NPE
Payload Payload
SRGB
Payload [16000-65535] Payload
CE2
CE1
VPN1 VPN1
Site 1 Site 2

BGP peer relationships are established between the UPE and SPE and between the SPE
and NPE. A segment routing LSP is established between the UPE and NPE.
The SPE iterates a VPNv4 routes to the SR LSP.
The process of forwarding HVPN packets that CE1 sends to CE2 is as follows:
1. CE1 sends a VPN packet to the NPE.
2. After receiving the packet, the NPE searches its VPN forwarding table for an LSP to
forward the packet based on the destination address of the packet. Then, the NPE adds an
inner label L4 and an outer label Lv to the packet and sends the packet to the SPE over
the corresponding LSP. The label stack is L4/Lv.
3. After receiving the packet, the SPE replaces the outer label Lv with Lu and the inner
label L2 with L3. Then, the SPE sends the packet to the NPE over the same LSP.
4. After receiving the packet, the NPE removes the outer label Lu, searches for a VPN
instance corresponding to the packet based on the inner label L3, and removes the inner
label L3 after the VPN instance is found. Then, the NPE searches the VPN forwarding
table of this VPN instance for the outbound interface of the packet based on the
destination address of the packet. The NPE sends the packet through this outbound
interface to CE2. The packet sent by the NPE is a pure IP packet with no label.
VPN FRR
In Figure 2-31, PE1 adds the optimal route advertised by PE3 and less optimal route
advertised by PE4 into a forwarding entry. The optimal route is used to guide traffic
forwarding, and the less optimal route is used as a backup route.

Figure 2-31 VPN FRR networking
PE1 P1 P3 PE3
LSP1
LSP2
CE1 CE2
LSP3
PE2 P2 P4 PE4
Table 2-13 Typical fault-triggered switching scenarios
Faulty Point Protection Switching

P1-to-P3 link failure PE1 does not support BFD for SR-BE and
cannot detect an LSP Down event. As a
result, PE2 cannot perform VPN FRR
switching to switch traffic to PE4 along
LSP3 over a path in Figure 2-31.
After IS-IS FRR is configured, P1 performs
FRR switching to switch traffic to LSP2
over the path PE1->P1->P2->P4->P3->PE3,
shown in Figure 2-31.
After IS-IS FRR is configured, SR-BE LSP
hard convergence is performed on the P
node. Traffic switches to LSP2 over the
converged path
PE1->P1->P2->P4->P3->PE3, shown in
Figure 2-31.
PE3 node failure If PE3 fails, traffic on LSP1 cannot be
switched to an FRR backup path, and LSP2
cannot converge. PE1 uses IS-IS protocol
packets to detect the PE3 fault and performs
path convergence. Then the LSP goes
Down, and BGP switches traffic to LSP3
along the path
PE1->CE1->PE2->P2->P4->PE4, shown in
Figure 2-31.

L2VPN Iterated to SR LSPs
VPLS Iterated to an SR LSP

Figure 2-32 shows a typical VPLS networking mode. In this networking, users located in
various geographical regions communicate with each other through different PEs. From the
perspective of users, a VPLS network is a Layer 2 switched network that allows them to
communicate with each other in a way similar to communication over a LAN. The VPLS
service can be iterated to a segment routing (SR) LSP. Sites in each VPN establish virtual
connections, and public network SR LSPs are established to forward Layer 2 packets.
Figure 2-32 VPLS iterated to an SR LSP
The process of iterating VPLS services to an SR LSP is as follows:

CE1 sends a packet with Layer 2 encapsulation to PE1.
PE1 establishes an E2E SR LSP to PE2.
An LSP policy is configured on PE1 to select the SR LSP, and the VSI forwarding
entries are associated with the SR forwarding entries.
PE1 receives the packet, searches for a VSI entry, and selects an LSP and a PW based on
the entry. PE1 adds double labels (outer LSP label and inner VC label) to the packet
based on the selected LSP and PW, performs Layer 2 encapsulation, and forwards the
packet to PE2.
Upon receipt of the packet, PE2 decapsulates the packet by removing Layer 2
encapsulation information and two MPLS labels.
PE2 forwards the original packet to CE2.

The process of iterating HVPLS services to an SR LSP is similar to that of iterating VLL and
VPLS services to an SR LSP. The process is not described.
EVPN Iterated to an SR LSP

Ethernet virtual private network (EVPN) is a Layer 2 interworking VPN technique. EVPN
uses a mechanism similar to BGP/MPLS IP VPN. EVPN extends the BGP protocol and uses
extended reachability information to move the process of learning and advertising MAC
addresses between Layer 2 networks at various sites from the data plane to the control plane.
Compared with VPLS, EVPN tackles the load imbalance and high network resource
consumption problems occurring on VPLS networks.
Figure 2-33 Unicast traffic transmission
Public Label
Private Label
EVPN1 L2 Payload L2 Payload L2 Payload

EVPN1
Site1 CE1 PE1 PE2 CE2 Site2
In Figure 2-33, after the PEs learn the MAC addresses of VPN sites and establish a public
network SR LSP, the PEs can transmit unicast packets to the other site. The packet
transmission process is as follows:
1. CE1 sends unicast packets based on Layer 2 forwarding to PE2.
2. After PE1 receives the packets, PE1 encapsulates a private network label carried in a
MAC entry and a public network SR label in sequence and sends the packets to PE1.
3. After PE1 receives the encapsulated unicast packets, PE1 performs decapsulation,
removes the private network label, and searches the private network MAC table for a
matching outbound interface.
2.3.6 TI-LFA FRR

Topology-independent loop-free alternate (TI-LFA) fast reroute (FRR) protects links and
nodes on segment routing tunnels. If a link or node fails, TI-LFA FRR rapidly switches traffic
to a backup path, minimizing traffic loss.
Related Concepts
Table 2-14 TI-LFA FRR related concepts
Concep Definition
t
P Space The P space contains a set of nodes reachable to the root node on links, not the
protected link, along the SPF tree that originates from the protected link's
source node functioning as the root node.
Extende The extended P space contains nodes reachable to the root nodes on links, not

Concep Definition
t
dP the protected link, along the SPF trees originating from the root nodes that are
space neighbors of protected link's source node.
Q Space The Q space contains nodes reachable to the root node on links , not the
protected link, along the reverse SPF tree originating from the protected link's
destination node functioning as the root node.
PQ node A PQ node resides in both the extended P space and Q space. The PQ node
functions as the destination node of a protected tunnel.
LFA The loop-free alternate (LFA) algorithm computes a standby link. A root node
that can provide a standby link runs the Shortest Path First (SPF) to compute
the shortest path to a destination node. The root node then uses the inequalities
defined in RFC 5286 to compute a loop-free standby link with the smallest
cost. For more information about LFA, see IS-IS Auto FRR.
RLFA Remote LFA (RLFA) computes a PQ node based on a protected path and
establishes a tunnel between the source and PQ nodes to provide next hop
protection. If the protected link fails, traffic automatically switches to the
backup path, which improves network reliability. For more information about
RLFA, see IS-IS Auto FRR.
TI-LFA In some LFA or RLFA scenarios, the P space and Q space do not share nodes
or have directly connected neighbors. Consequently, no backup path can be
calculated, which does not meet reliability requirements. In this situation,
TI-LFA can be used. The TI-LFA algorithm computes the P space and Q space
based on a protected path, a shortest path tree (also called a post-convergence
tree), and a repair list. The algorithm establishes a segment routing tunnel
between the source node and PQ node to provide backup next hop protection. If
the protected link fails, traffic automatically switches to the backup path, which
improves network reliability.
Background
Conventional LFA requires that at least one neighbor be a loop-free next hop to a destination.
Remote LFA (RLFA) requires that there be at least one node that connects to the source and
destination nodes along links without passing through any faulty node. Unlike LFA or RLFA,
TI-LFA uses an explicit path to represent a backup path, which poses no requirements on
topology constraints and provides more reliable FRR.
In Figure 2-34, If the P node (Device A) and Q node (Device D) do not intersect, RLFA
requirements fail to be fulfilled, and RLFA cannot compute a backup path. If a fault occurs on
the link between Device B and Device E, Device B forwards data packets to Device C.
Device C is not the Q node and doe not have the destination IP address directly to the
destination IP address. In this situation, Device C has to recompute a path. The cost of the link
between Device C and Device D is 1000. Device C considers that the optimal path to Device
F passes through Device B. Device C loops the packet to Device B, leading to a loop and
resulting in a forwarding failure.

Figure 2-34 RLFA networking
Device A 1 Device B 2 Device C

P
Cost: 10 space
Cost: 10 3
Cost: 1000
Q
Cost: 10 space
Device F Device E Device D
Faulty
Path before the fault
point
Path after the fault
TI-LFA can be used to solve this problem. In Figure 2-35, if a fault occurs on the link between
Figure 2-35 B and Figure 2-35 E, Figure 2-35 B enables TI-LFA FRR backup entries and adds
new path information (node label of Figure 2-35 C and link label for the C-D link) to the
packets to ensure that the data packets can be forwarded along the backup path.
Figure 2-35 TI-LFA networking
103 New path

16001 information
106 106
IP head IP head Node
Payload Payload SID: 103
Device A 1 Device B 2 Device C
P
Cost: 10 space
Cost: 10 Cost: 1000

3
Adjacency
4 SID: 16001
Node Q
SID: 106 Cost: 10 space
Device F Device E Device D
Faulty
Path before the fault
point
Path after the fault
Benefits
Segment routing-based TI-LFA FRR has the following advantages:

1. Meets basic requirements of IP FRR rapid convergence.

2. Theoretically supports all protection scenarios.
3. Uses an algorithm with moderate complexity.
4. Selects a backup path over a converged route and has no intermediate state, compared
with the other FRR techniques.
TI-LFA FRR Principles
Figure 2-36 Typical TI-LFA networking
PE3
10 P5
40
39 P4
20
P1 40
P3
15
10
20
P2
PE1
40 10
PE2
Faulty Point
In Figure 2-36, PE1 is a source node, P1 is a faulty node, and PE3 is a destination node. Link
costs are marked.
TI-LFA traffic protection involves link and node protection.
Link protection: protects traffic passing through a specific link.
Link protection: protects traffic passing through a specific node. Node protection takes
precedence over link protection.
Implementation
In the following example, the process of node protection is as follows. In Figure 2-36, traffic
travels along a path PE1->P1->P5->PE3. If P1 fails, TI-LFA computes the P space, the Q
space, and the SPF tree (also called the post-convergence tree), and a repair list. Traffic is
forwarded along the backup path to the destination PE3, which implements rapid protection to
prevent traffic loss.
TI-LFA FRR computation is as follows:
1. Computes the P space. It contains the set of nodes reachable to the root node on links,
not the protected link, along the SPF tree that originates from the protected link's source
node functioning as the root node.

2. Computes the space Q. It contains the set of nodes reachable to the root node on links,
not the protected link, along the reverse SPF tree that originates from the protected link's
destination node functioning as the root node.
3. Computes the post-convergence SPF tree. It excludes the primary next hop.
4. Computes a repair list, as shown in Table 2-15.
Table 2-15 Repair lists in various scenarios
Usage Backup Outbound Interface Repair List

Scenario
Figure 2-37 If the next hop neighbor of the The repair list is empty.
post-convergence tree is a PQ node and
the directly connected neighbor is the
PQ node, the backup outbound
interface is directly connected to the
neighbor interface.
Figure 2-38 If the P space and Q space do not share The repair list is a single PQ
nodes along the post-convergence tree, node. For example, P3's node
the next-hop outbound interface label.
functions as a backup outbound
interface.
Figure 2-39 If the P space and Q space do not share The repair list is a P space's
nodes along the post-convergence tree, node label, plus the Q node's
and the P node and Q node have link label. For example, P2's
directly connected neighbors, the node label is added to the
post-convergence next-hop outbound P2-to-P3 link label.
interface functions as a backup
outbound interface.
Figure 2-40 In some scenarios, if the P space and Q The repair list is a P node
space do not share nodes or have label plus a link label on the
directly connected neighbors, the P-to-Q link. For example,
post-convergence next-hop outbound P2's node label is added to
interface functions as a backup link labels of the P2-to-p3
outbound interface. and P3-to-P4 links.
Figure 2-41 The source node is in the P space, the The repair list is the strict
destination node is in the Q space. The explicit path from the source
other nodes on the post-convergence node to the destination node
tree are not in the P or Q space. In this along the post-convergence
situation, no repair node is available, tree. The backup label stack
and the post-convergence next-hop contains link labels, not node
outbound interface functions as a labels.
backup outbound interface.

Figure 2-37 LFA scenario
PE3
Q space
P5 P4
P1
P3
P2
PE1
P space
PE2
Figure 2-38 RLFA scenario
PE3
Q space
P5 P4
P1
P3
P2
PE1
P space
PE2

Figure 2-39 DLFA scenario
PE3
Q space
P5 P4
P1
P3
P2
PE1 P space
PE2
Figure 2-40 TI-LFA scenario
PE3
Q space
P5 P4
P1
P3
P2
PE1
P space
PE2

Figure 2-41 Other scenario
Q space
PE3
P5 P4
P1
P3
PE1
P2
P space
PE2
Rules for selecting a SID on a repair node are as follows:

A node SID advertised by the repair node is preferentially selected.
The smallest prefix SID of a single source on a repair node is preferentially selected.
A non-multiple-source prefix on a repair node is preferentially selected.
A node that does not support segment routing or a node that does not advertise a prefix
or node SID cannot function as a repair node.
TI-LFA FRR Backup Path Forwarding

After a TI-LFA backup path is computed, if the primary path fails, traffic switches to the
backup path, preventing packet loss.
In Figure 2-42, Device F is a P node, and Device H is a Q node. The primary next-hop B fails,
which triggers FRR switching. Traffic switches to the backup path.

Figure 2-42 TI-LFA FRR backup path forwarding
Prefix
SID=100
Device A Device B Device C
SRGB
Label 720 [600-700]
Label 130
Label 240 Label 610
Label 310 IP head
Payload
IP head
Payload Device E
SRGB
Device D [500-600]
SRGB
Label 510
[700-800]
Label 120 IP head
Label 130 Payload
Label 240
130 240
Label 310
IP head
Payload Device F Label 240 Device G Device H
SRGB Label 310 Label 310 SRGB
[100-200] IP head IP head [300-400]
Node SID=20 Payload Payload
Faulty
point
Table 2-16 TI-LFA FRR backup path forwarding process
Device TI-LFA FRR Backup Path Forwarding Process

Device Device A encapsulates a label stack to a packet based on the repair list from
A outer to inner: Node label of the P node (Device F) = Start label in next-hop
Device D's SRGB + Label offset of the P node =720 P-to-Q link labels of 130
and 240 Destination node label = Start label of the Q node's SRGB + Label
offset of the destination node (Device C) = 310
Device Upon receipt of the packet, Device D searches the label forwarding table based
D on the outgoing label and finds a matching entry with the outgoing label of 120
and next hop at Device F. Device D swaps the outgoing label for 120 and
forwards the packet to Device F.
Device F Upon receipt of the packet, Device F searches the label forwarding table based
on the outgoing label. Device F is the egress so that it removes the label. It
finds a matching entry with a routed path label of 130, the outgoing label as
empty, and the next hop at Device G. Device F removes label 130 and forwards
the packet to Device G.
Device Upon receipt of the packet, Device G searches the label forwarding table based
G on the outgoing label, removes label 240, and forwards the packet to Device H.
Device Upon receipt of the packet, Device H searches the label forwarding table based
H on the outgoing label and finds a matching entry with the outgoing label of 510

Device TI-LFA FRR Backup Path Forwarding Process

and the next hop at Device E. Device H swaps the outer label for 510 and
forwards the packet to Device E. Device E forwards the packet to Device C.
The packet travels along the shortest path.
TI-LFA FRR Protection Usage Scenarios
Table 2-17 TI-LFA FRR protection usage scenarios
TI-LFA FRR Description Deployment

Protection
TI-LFA FRR Traffic is transmitted over 1. Establish an IS-IS neighbor
protects IP an IP routed primary path, relationship between each pair of
forwarding. and a TI-LFA FRR backup
path is computed. directly connected nodes on a
network. Enable segment routing
on all nodes. Set a prefix SID on
the P node.
2. Enable TI-LFA FRR on the source
node.
TI-LFA FRR Traffic is transmitted over a 1. Establish an IS-IS neighbor
protects traffic on a primary segment routing relationship between each pair of
segment routing tunnel, and a TI-LFA FRR
tunnel. backup path is computed. directly connected nodes on a
network. Enable segment routing
on all nodes. Set a prefix SID on
each of the P and destination
nodes.
2. Enable TI-LFA FRR on the source
node.
Anti-micro-loop In Figure 2-43, if Device B Configure the anti-micro-loop
switchover fails, traffic is switched to a switchover function on the source
TI-LFA FRR backup path. node.
After Device A completes The delayed route switchover must
route convergence, traffic meet the following conditions:
is switched from the
The interface directly connected to
TI-LFA FRR backup path
to a converged path. If the local interface fails, or local
Devices D and F do not BFD goes Down.
complete route No network topology change
convergence, they transmit occurs during the delay time.
traffic over the path A backup next hop for a route is
established before available.
convergence is performed.
The primary next hop of the route
As a result, a loop emerges
between Devices A and F is the faulty interface.
and is broken after route The primary and backup next hops

TI-LFA FRR Description Deployment

Protection
convergence finishes on are different after the path
Devices D and F. convergence is complete.
To prevent the During the delay of the
loop-induced problem, the multi-source route convergence,
implementation is the route source change event
modified. After Device B occurs, and the delay stops.
fails, traffic is switched to
the TI-LFA backup path.
Device A delays
convergence. After Devices
F and D finish path
convergence, Device A
starts path convergence.
After path convergence is
complete, traffic is
switched from the TI-LFA
backup path to the
converged path.
Figure 2-43 Anti-micro-loop switchover
Device A Device B Device C
Device D Device E
Device F Device G Device H
The path before Backup path

convergence
The path after Faulty point
convergence

2.3.7 SR OAM
SR Operation, Administration, and Maintenance (OAM) monitors LSP connectivity and
rapidly detects faults. SR OAM is implemented using ping and tracert.
SR-TE Ping
Segment routing traffic engineering (SR-TE) is an MPLS TE tunneling technology extended
from IGP to control the packet transmission path on a network based on the MPLS label stack
of the ingress. An MPLS label is the identifier of a routing segment. Each routing segment
instead of each LSP must be assigned an MPLS label.
An SR-TE tunnel can be established in either of the following modes:
Automatic creation by the forwarder: In this mode, the controller completes path
computation and label stack generation.
Manual tunnel configuration: In this mode, the delegated controller completes path
computation and maintenance.
On the network shown in Figure 2-44, PE1, P1, and P2 all support SR. An SR-TE tunnel is
established between PE1 and PE2. The devices assign labels as follows:
PE1 assigns label 9001 to P1.
P1 assigns label 9002 to P2.
P2 assigns label 9005 to PE2.
Figure 2-44 SR-TE ping and tracert
9005
P2: IP header PE2:
9002 payload 9005
9002
9005
IP header P1 P2 IP header
payload payload
IP header IP header
payload payload
P1:
9001
CE1 PE1 PE2 CE2
SR-TE tunnel
The process of initiating an SR-TE ping test from PE1 is as follows:

1. PE1 initiates a ping test and checks whether the specified tunnel type is SR-TE.
If the specified tunnel type is not SR-TE, PE1 reports an error message indicating a
tunnel type mismatch and stops the ping test.
If the specified tunnel type is SR-TE, the following operations are performed:

2. PE1 constructs an MPLS Echo Request packet encapsulating label information about the
entire tunnel and carrying destination address 127.0.0.0/8 in the IP header of the packet.
3. PE1 forwards the packet to P1. P1 removes the outer label of the received packet and
forwards the packet to P2.
4. P2 removes the outer label of the received packet and forwards the packet to PE2 for
processing.
5. PE2 returns an MPLS Echo Reply packet to PE1.
On the network shown in Figure 2-44, the process of initiating an SR-TE tracert test from PE1
is as follows:
1. PE1 initiates a tracert test and checks whether the specified tunnel type is SR-TE.
If the specified tunnel type is not SR-TE, PE1 reports an error message indicating a
tunnel type mismatch and stops the tracert test.
If the specified tunnel type is SR-TE, the following operations are performed:
2. PE1 constructs an MPLS Echo Request packet encapsulating label information about the
entire tunnel and carrying destination address 127.0.0.0/8 in the IP header of the packet.
3. PE1 forwards the packet to P1. After receiving the packet, P1 determines whether the
TTL-1 value in the outer label is 0.
If the TTL-1 value is 0, an MPLS TTL timeout occurs. P1 sends the packet to the
Rx/Tx module for processing and returns an MPLS Echo Reply packet to PE1.
If the TTL-1 value is greater than 0, P1 removes the outer MPLS label of the packet,
buffers the TTL-1 value, copies the value to the new outer MPLS label, searches the
forwarding table for the outbound interface, and forwards the packet to P2.
4. Similar to P1, P2 also determines whether the TTL-1 value in the outer label of the
received packet is 0.
If the TTL-1 value is 0, an MPLS TTL timeout occurs. P2 sends the packet to the
Rx/Tx module for processing and returns an MPLS Echo Reply packet to P1.
If the TTL-1 value is greater than 0, P2 removes the outer MPLS label of the packet,
buffers the TTL-1 value, copies the value to the new outer MPLS label, searches the
forwarding table for the outbound interface, and forwards the packet to PE2.
5. P2 forwards the packet to PE2, and PE2 returns an MPLS Echo Reply packet to PE1.
2.3.8 Applications
2.3.9 Acronyms and Abbreviations
Terms
Term Definition
SR-BE Segment Routing Best Effort (SR-BE) uses an IGP to run the
shortest path algorithm to compute an optimal SR LSP.
SR-TE Segment Routing Traffic Engineering (SR-TE) runs the SR
protocol and uses TE constraints to create a tunnel.

Acronyms and Abbreviations

Acronym and Full Name
Abbreviation
BGP-LS BGP Link-State

FRR fast re-route
NETCONF Network Configuration Protocol
PCE path computation element
PCEP Path Computation Element Communication Protocol
SID segment ID
SR segment routing
SRGB segment routing global block
TE traffic engineering
TI-LFA FRR Topology-Independent Loop-free Alternate FRR


NE40E Feature Description - Segment Routing

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

NE40E Feature Description - Segment Routing

Hochgeladen von

Copyright:

Verfügbare Formate

HUAWEI NE40E Universal Service Router

Feature Description - Segment

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2017-07-30) Huawei Proprietary and Confidential i

1 About This Document .................................................................................................................. 1

Issue 01 (2017-07-30) Huawei Proprietary and Confidential ii

1 About This Document

Product Name Version

NE40E Series V800R009C10

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 1

To further improve device security, periodically change the password.

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 2

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 3

About This Chapter

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 4

Figure 2-1 Service-driven network

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 5

MPLS TE is a connection-oriented technique. To maintain connections, nodes need to

2.2 Feature Updates

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 6

Table 2-1 Segment category

Label Generati Function Example

Figure 2-2 Adjacency SID

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 7

Figure 2-3 Prefix SID + Node SID

101 102 103

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 8

Figure 2-4 Prefix segment-based forwarding paths

100 100 100

Figure 2-5 Adjacency segment-based forwarding path

Adjacency Segment + Node Segment

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 9

Figure 2-6 Adjacency segment + node segment-based forwarding path

Label Conflicts and Handling Rules

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 10

Figure 2-7 Prefix label-based LSP establishment and data forwarding

SRGB SRGB SRGB SRGB

Table 2-2 LSP creation process

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 11

1 D An SRGB and a prefix SID are configured on a loopback interface of D. D

Table 2-3 Packet forwarding process

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 12

PHP, MPLS QoS, and TTL

Table 2-4 PHP, MPLS QoS, and TTL

Label Type Description MPLS EXP TTL Scenario

explicit-null PHP is not The MPLS The TTL Label resources

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 13

Label Type Description MPLS EXP TTL Scenario

IS-IS SID TLV Extensions

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 14

Figure 2-8 Prefix-SID Sub-TLV format

Table 2-5 Meanings of fields in the Prefix-SID Sub-TLV

Field Name Length Description

Figure 2-9 Flags field

The meaning of each flag is as follows:

Issue 01 (2017-07-30) Huawei Proprietary and Confidential 15

Field Name Length Description

Figure 2-10 Adj-SID Sub-TLV format

Table 2-6 Meanings of fields in the Adj-SID Sub-TLV