Segment Routing Fundamentals26

SEGMENT ROUTING
FUNDAMENTALS
BY AMIT TYAGI
© 2018 Juniper Networks 1

Juniper Business Use Only
Agenda
• What is Segment Routing? 003
• SRGB and SRLB 016
• Introduction to Different SIDS 022
• Provisioning LSPs using different SIDs 087
• Traffic engineering with SPRING 135
• Static LSP & static segments 187
• Basics of LFA and TI-LFA 212
• SR-TE Telemetry 243
• Segment Routing OAM: MPLS Ping and Traceroute for SPRING 277
• Reference 346
Not Covered: SRv6, PCEP, and concepts of NorthStar. How to make setup…
WHAT IS SEGMENT ROUTING?

Main Terminology
Segment: An instruction a node executes on the incoming packet (e.g., forward packet according to shortest path to destination,
or, forward packet through a specific interface, or, deliver the packet to a given application/service instance).
Local Segment: Only originating node understands associated instruction.
Global Segment: Any node in SR domain understands associated instruction and Each node in SR domain installs the
associated instruction in its forwarding table.
Segment list: It is an ordered list of segments, which is actually encoded as the stack of labels in the MPLS architecture.
SID: A segment identifier. Note that the term SID is commonly used in place of the term "Segment"
Segment Routing domain (SR domain): An SR domain is defined as a single administrative domain for global SID
assignment. It may be comprised of a single AS or multiple ASes under consolidated global SID administration.
SR Local Block (SRLB): Local property of an SR node. Defines a list of label blocks represented by a pair of lower-
bound/upper-bound labels, reserved for local SIDs. If a node participates in multiple SR domains, there is one SRLB for each SR
domain.
SR Global Block (SRGB): The set of local labels reserved for globally unique segments in the SR domain. If a node participates
in multiple SR domains, there is one SRGB for each SR domain.
Segment Routing or Source Packet Routing in Networking
Segment Routing (SR) is a source routing paradigm based on the “Source Packet Routing in Networking (SPRING)” architecture.
It provides a new approach to achieve traffic engineering (TE) and resilience in today’s networks.
In SR, Each end-to-end unidirectional forwarding path is modeled as a sequence of forwarding instructions, called “segments”.
Routing is done based on segments. Segments indicates the exact path that packet must follow in the network or we can say
segments are the instructions for the packet to reach its destination. A segment is encoded as an MPLS label (distributed by
IGP). The ingress router of the forwarding path constructs the list of segments and attaches it to each packet. Each transit router
along the path in turn processes the current segment and applies the corresponding forwarding instruction to the packet. In this
paradigm, the ingress router has the full control of steering the packet over this desired path.
SR is a flexible, scalable way of doing source routing. The source chooses a path and encodes it in the packet header as an
ordered list of segments. Segments are identifier for any type of instruction. Each segment is identified by the segment ID (SID)
consisting of a flat unsigned 32-bit integer.
With segment routing, the network no longer needs to maintain a per-application and per-flow state. Instead, it obeys the
forwarding instructions provided in the packet. Per-flow state is maintained only on the ingress node of the SR domain.

Segment Routing or Source Packet Routing in Networking Cont…
SR network is divided into “segments” where each node and link could be assigned a segment identifier, or a SID, which gets
advertised by each node using standard routing protocol extensions (ISIS/OSPF/BGP).
When SR uses MPLS forwarding plane as data plane, each segment is assigned a unique label. The label also serves as the
segment identifier (SID) for the segment, and hence is called a SID label. Therefore, each forwarding path is instantiated as a
label-switched path, called SR LSP.
Segment Segment Segment
On ingress router, an SR LSP is represented
by a stack of SID labels. The ingress router Segment Segment
R1 R2 R3 R4
applies the label stack to a packet to steer
the traffic based on labels. Each transit
router in turn performs label switching based
on the top SID label, i.e. the current segment.
The packet is thus forwarded hop by hop to the Segment Segment
egress router.
Segment
R5 R6
Segment Segment
Segment Routing Provisioning:
In general, the provisioning of SR in an MPLS network involves three main tasks, i.e. segment provisioning, segment
information distribution, and SR LSP provisioning.
1. Segment Provisioning: Segment provisioning is performed on a per-router basis. For a given segment on a router, a SID
label is allocated from a desired label pool, which may be a dynamic label pool for an adj-SID label, or the SRGB for a prefix-
SID or node-SID. A route for the SID label is then installed in the mpls.0 table.
2. Segment Information Distribution: After segments are provisioned on a router, the router may advertise segment
information (including SID labels) through ISIS/OSPF SR extensions to other routers in the network. The information may
also further be distributed to a controller. The information allows ingress routers and the controller to translate an end-to-
end forwarding path from an IP address list to a segment list (i.e. a stack of SID labels). The ingress routers and the controller
can then use the segment lists to set up an SR LSP. Also, each prefix or node segment advertised will provide neighbor
routers with the outgoing SID label for their SID label routes of that segment.
3. Segment Routing LSP Provisioning: SR LSPs are provisioned on ingress routers. The provisioning may be dynamic or
static. In dynamic provisioning, an SR LSP may be created on a controller, and downloaded to an ingress router in an ERO
via PCEP SR extensions, or in a BGP SR policy via BGP SR extensions (RLI 29611). The PCEP ERO or BGP SR policy will
contain the segment list of the SR LSP.

SPRING is a Packet forwarding technology where the source node defines the path for traffic and encodes it in the packet header
as an ordered list of segments, which is then sent through specific nodes and forwarding paths called segments. the rest of the
network executes these encoded instructions. An SR path is not dependent on hop-by-hop signaling. SR, like MPLS, uses label
switching to forward packets, but in SR terminology the labels are called segments.
SR Path
Node Segment LSP Segment Adj Adj
Segment Segment
LSP Label
Node Label =302 Adjacency Label =718
=183
R6 R8
302
183
555 R2 R4 R12
718
Pay Load
R1 (Ingress) R14 (Egress)

R9 R11
Adjacency Label =555

Suppose you wish the traffic to be routed as follows:
1. From R1, follow the shortest IGP path to R6.
2. At R6, launch the traffic into the traffic-engineered LSP X. This LSP follows the path R6, R8, R9, R11.
3. From R11, you want the traffic to use the link to R12.
4. From R12, you want the traffic to use the link to R14.
Each of the four stages in this path has a corresponding segment. An MPLS label is associated with each segment, namely:
• For stage one, the Node Segment is used associated with R6 – in the example the label is 302. This label tells R2 and R4 to
forward the packet towards R6 using the shortest IGP path.
• For stage two, the Binding Segment is used associated with TE LSP X. In the example, the label is 183. This label tells R6
to launch the packet onto the LSP
• For stage three, the Adjacency Segment is used associated with the link from R11 to R12. In the example, the label is 555.
• For stage four, the Adjacency Segment is used associated with the link from R12 to R14. In the example, the label is 718.
Once you enabled the SR then local router will advertise its SR capability in SR-Capabilities Sub-TLV (2) inside Router Capability
(242) TLV. For more details on this and other basic TLVs associated with SR, please visit “
https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-25.txt”.
root@R1> show isis database R1.00-00 extensive

. . .
R1.00-00 Sequence: 0xa80, Checksum: 0x1990, Lifetime: 1089 secs
. . .
TLVs:
. . .
Router Capability: Router ID 192.168.1.1, Flags: 0x00
SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 1000, SID-Label: 1000
SPRING Algorithm - Algo: 0
. . .
root@R1>
I-Flag: MPLS IPv4 flag. If set, then the router is capable of processing SR MPLS encapsulated IPv4 packets on all
interfaces.
V-Flag: MPLS IPv6 flag. If set, then the router is capable of processing SR MPLS encapsulated IPv6 packets on all
interfaces.
Rest of the Flags are not defined

Segment Features
• A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels.
• A segment can have a local semantic to a segment routing node or to a global node within a segment routing
domain. Segment routing enforces a flow through any topological path and service chain while maintaining
per-flow state only at the ingress node to the segment routing domain.
• Upon completion of a segment, the related label is popped from the stack.
• A segment is stateless. Device only needs to know its own Block and adjacencies to generate a SID.
• No negotiations while assigning labels.
• Segment routing can be directly applied to the MPLS architecture with no change on the forwarding plane.

Segment Routing Advantages
Simple: Segment Routing provides complete control over the forwarding paths by combining simple network
instructions. It does not require any additional protocol. Indeed in some cases it removes unnecessary
protocols simplifying your network.
Scalable: Segment routing does not require any path signaling. Hence, per-flow state only needs to be
maintained at the ingress node of the SR domain increasing your network flexibility while reducing cost.
Seamless deployment: Segment Routing runs natively on an MPLS or IPv6 data plane. A simple software
upgrade will enable your hardware to run it. Also, Segment Routing can coexist with your existing LDP
network, making the migration painless.
Traffic Engineering: Segment Routing can be used to steer traffic along any arbitrary path in the network.
This allows operators to enforce low-latency and/or disjoint paths, regardless of the normal forwarding paths.
Failure Protection: The Segment Routing-based fast-reroute solution, TI-LFA, can provide per-destination
sub-50msec protection upon any single link, node or SRLG failure regardless the topology.
Programmable: Can be configured via external controller via PCEP or other means.
Comparison of SR with LDP and RSVP
Benefit Segment Routing LDP RSVP-TE
Operational Very simple Simple Complex

Simplicity
Fast Reroute Yes, 100% coverage, Yes, <100% with LDP [r]LFA Yes, 100% with RSVP bypasses,
with minimal traffic Yes, 100% with LDP TI-FRR at much larger tromboning inevitable
tromboning during the expense of yet another during FRR in ring topologies
FRR in ring topologies stateful protocol (RSVP) Yes, 100% with RSVP detours,
minimal tromboning in ring
topologies at the expense of much
more state
Number of IGP IGP+LDP IGP+RSVP

Protocols to IGP+LDP+RSVP (in case of
test/configure/tune TI-FRR)
/maintain
SDN Supported Not supported Only RSVP-TE supports SDN use
cases

Comparison of SR with LDP and RSVP Cont…
Benefit Segment Routing LDP RSVP-TE
TE Yes, simple TE is not supported Complex
ECMP for TE Takes advantage of and Need to be specifically Need to be specifically configured
automatically load- configured (one LDP session (at least one RSVP LSP per ECMP
shares per ECMP link) to be able to link) to be able to take advantage of
take advantage of ECMP ECMP
TE scalability High: A minimal state TE is not supported Low: In addition to IGP state,
(IGP state) in RSVP needs to create & maintain
the core network is ingress RSVP-TE LSP in edge
required. nodes and core noes need to keep
IGP state + TE state in state of transit RSVP-TE LSPs
the edge/source node
is required

R3 - lo0.0- Note: In NorthStar Controller Junos VM you will see two tables. The Ist one
192.168.1.3/32
SL: 3000 ge-0/0/1
is lsdist.0 and the IInd is lsdist.1. lsdist.1 table you will see only
ge-0/0/0
1.1.1.46/30 Index: 103 1.1.1.50/30 when you discover topology using ISIS. lsdist table => Link State
Base Anycast SID:

lo0.0: 192.168.1.101/32
distribution table
• lsdist.0 - You need to Populate NTAD with TED using import policy
Topology “set protocols mpls traffic-engineering database
import policy TE” for this table to get created. It stores the
network topology from TED having link that have RSVP enables.
Northstar lsdist.0 normally contains the normal ted database entries. It can
JVM
192.168.1.10 em2
have TED route entries learned from OSPF/ISIS and BGP-LS.
AS200 172.16.18.199/24
• lsdist.1 - Need to enable “set protocols mpls traffic-
engineering database import igp-topology” for this table to
get created. Stores the network topology from TED including links that
do not have RSVP enabled. lsdist.1 contain pure IGP topology
eth2 ge-0/0/9 ge-0/0/4 Anycast SID: ge-0/0/4
database entries. lsdist.0 is super set of lsdist.1.
172.16.18.1/24 172.16.18.11/24 1.1.1.45/3 lo0.0: 192.168.1.101/32 1.1.1.49/30
R1 - lo0.0- ge-0/0/0 ge-0/0/0 R4-RR - lo0.0- ge-0/0/1 ge-0/0/1 R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0-
Northstar 192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
PCS SL: 1000 Prefix SID: SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 SL: 8000
Index: 101 10.10.10.1/32 Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106 Index: 108
ge-0/0/1 ge-0/0/3 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
ge-0/0/5 ge-0/0/6
1.1.1.54/30 1.1.1.57/30
Segment Routing
AS100
ge-0/0/4 ge-0/0/4
1.1.1.53/30 1.1.1.58/30
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1
1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
R2 - lo0.0- R5 - lo0.0- ge-0/0/1 ge-0/0/1 R7-RR - lo0.0- R9 - lo0.0-
192.168.1.2/32 192.168.1.5/32 192.168.1.7/32 192.168.1.9/32
SL: 2000 ge-0/0/0 ge-0/0/0 SL: 5000 SL: 7000 ge-0/0/0 ge-0/0/0 SL: 9000
Index: 102 1.1.1.9/30 1.1.1.10/30 Index: 105 ge-0/0/2 ge-0/0/2 Index: 107 1.1.1.37/30 1.1.1.38/30 Index: 109

SRGB AND SRLB

SRGB - Segment Routing Global Block
Every node in the segment routing domain allocate labels from MPLS label manager when user configures “set protocols
isis source-packet-routing srgb start-label <start-label 16..1048575> index-range <index-range
16..1048575>”. These labels allocated based on the availability of dynamic label range managed by the MPLS label manager.
There is no predictability of the label range being allocated to the IGP for segment routing across the IGP domain.
The Segment Routing Global Block (SRGB) represents the local label space that nodes use to refer to global segments. SRGB is
encoded as a base (start label) and a range (number of labels)
SRGB block range is configured using above command highlighted in green. Default value for index-range is 4096.
With the above CLI configuration, Labels advertised in the segment routing would be more predictable and deterministic across
the segment routing domain. SRGB can be same or different across the nodes.
For example, user configured the index-range 1000 and start-label 1000, SRGB start label is 1000 and end label is 1999 (start
label 1000 + index-range 1000 - 1 = end label of SRGB block).
root@R1> show configuration protocols isis source-packet-routing

srgb start-label 1000 index-range 1000;
node-segment ipv4-index 101;
root@R1>

SRGB - Segment Routing Global Block Cont…
After commit of SRGB label range command, MPLS label manager try to reserve the SRGB label range, by parsing the SRGB
configuration. MPLS label manager will do due diligence like SRGB range doesn’t conflict with other statistically configured range
etc and allocate the SRGB block once the initial check succeed. “show isis overview” will show allocation of the SRGB if
successfully reserved the label range.
“show mpls label usage” shows the available label space resource in RPD and the applications that use the label space in
RPD. There are four different label spaces currently used in MPLS namely LSI, dynamic, block, and static. Each label space has a
fixed number and cannot grow beyond the fixed value.
root@R1> show isis overview root@R1> show mpls label usage

Instance: master . . .
Router ID: 192.168.1.1 Effective Ranges
Hostname: R1 Range name Shared with Start End
. . . Dynamic 16 999
Source Packet Routing (SPRING): Enabled Dynamic 2000 999999
SRGB Config Range : Static 1000000 1048575
SRGB Start-Label : 1000, SRGB Index-Range : 1000 SRGB 1000 1999 ISIS <<<
SRGB Block Allocation: Success SRGB
SRGB Start Index : 1000, SRGB Size : 1000, Label-Range: [ 1000, 1999 ] Configured Ranges
Node Segments: Enabled Range name Shared with Start End
Ipv4 Index : 101 Dynamic 16 999
. . . Dynamic 2000 999999
root@R1> Static 1000000 1048575
SRGB 1000 1999 ISIS <<<
SRGB
root@R1>
SRGB - Segment Routing Global Block Cont…
Failed to allocate SRGB label range: In the case where MPLS label manager is not able to successfully allocate SRGB label
range during the IGP task initialization, it will log a syslog message. We need to ensure that the labels in the SRGB label range is
not used by any other applications. Failed to allocate SRGB label range due to label within the SRGB label range might be because
the label range is already allocated to the other applications, then a syslog error message RPD_ISIS_SRGBALLOCATIONFAIL is
logged to indicate that the label manager is not able to allocate the requested SRGB label range as a label within the SRGB label
range is used by other application. There will not be any commit failure, in case label reservation failed. Operator must manually
free the label (manually/ any other mean like restart routing) which is being used by anther application. “show isis
overview” command will show failure in case of label block is not reserved due to any reason.
Change of SRGB configuration value: Change in the existing SRGB label range configuration value, MPLS label manager
will try to reserve the modified SRGB label range during the commit process.
Case where SRGB label range successfully modified and reserved by the MPLS label manager, IGP shall detect the modified range
configuration and IGP will update the existing label route install in the mpls.0 and inet.3 table with new SRGB range label
values. This will lead to the traffic distribution for brief period of time.
Case where modified SRGB label range is not successfully reserve by the MPLS label manger (due to label being used by other
application), IGP shall hold the old SRGB label range and display old SRGB range in the “show isis overview”. Old SRGB
label will be remain as it is in forwarding tables.

SRLB - Segment Routing Local Block
SRLB (Segment Routing Local Block): Defines a list of label blocks reserved for local SIDs. Local SIDs are used, e.g., for
Adjacency-SIDs. Adjacency-SIDs labels are allocated using dynamic pool and Static Adjacency labels (and other SIDs that
requires manual configuration) are allocated from the static pool. Currently static SRLB configuration is not supported in Junos.
You can configure labels range for static SIDs using command “set protocols mpls label-range static-label-
range <range-start 16..1048575> <range-end 16..1048575>”
root@R1> show mpls label usage

Label space Total Available Applications
LSI 998984 998972 (100.00%) BGP/LDP VPLS with no-tunnel-services, BGP L3VPN with vrf-table-label
Block 998984 998972 (100.00%) BGP/LDP VPLS with tunnel-services, BGP L2VPN
Dynamic 998984 998972 (100.00%) RSVP, LDP, PW, L3VPN, RSVP-P2MP, LDP-P2MP, MVPN, EVPN, BGP
Static 48576 48576 (100.00%) Static LSP, Static PW
Effective Ranges
Range name Shared with Start End
Dynamic 16 999
Dynamic 2000 999999
Static 1000000 1048575
SRGB 1000 1999 ISIS <<< SRGB
Configured Ranges
Range name Shared with Start End
Dynamic 16 999
Dynamic 2000 999999
Static 1000000 1048575
SRGB 1000 1999 ISIS <<< SRGB
root@R1>

Finding labels used by different-2 protocols from RPD debug shell
With the “dbgsh” you can get the all the labels used by each protocols in the RPD. The syntax is given below:
dbgsh [-d daemon-name] [-l logical-system-name] command [argument...]
To get all the labels allocated by RPD for a specific protocol or all the protocols.
root@R1> start shell command "dbgsh call mpls_label_debug_dump_app_labels 4" root@R1> start shell command "dbgsh call mpls_label_debug_dump_all_app_labels"
call mpls_label_debug_dump_app_labels 4 call mpls_label_debug_dump_all_app_labels
======= Label usage debug begin =======
============================= =============================
Labels used by application ISIS Labels used by application RSVP
============================= =============================
16, 18, 19,
=============================
root@R1> start shell command "dbgsh call mpls_label_debug_dump_app_labels 6" Labels used by application LDP
call mpls_label_debug_dump_app_labels 6 =============================
============================= . . .
Labels used by application BGP =============================
============================= Labels used by application ISIS
17, =============================
16, 18, 19,
root@R1>
=============================
Labels used by application VRF
=============================
=============================
Labels used by application BGP
=============================
17,
. . .
Juniper Business Use root@R1>
Only
INTRODUCTION TO DIFFERENT SIDS

Different Types of SIDs - IGP and BGP SID SIDs
1. Adjacency Segments (Adj-SID): A strict-forwarded 1–hop tunnel that carries packets over a specific link between two
nodes, irrespective of the link cost. Adjacency segments represent an IGP adjacency between two routers hence they are locally
unique. A node advertises it for every adjacency. IGP Adjacency Segment Identifier (Adj-SID) is a local label allocated from
SRLB. It is attached to a unidirectional adjacency or a set of unidirectional adjacencies. Ingress routers can steer a packet
through a desired set of nodes and links by prepending the packet with an appropriate combination (stack) of labels.
2. Node Segments (Node-SID) and Prefix Segment (Prefix-SID): A Loose Multi-hop tunnel, Prefix SID is a loose multi-
hop tunnel using ECMP aware shortest path links between two specific nodes or to a specific prefix hence they are globally
unique. Prefix segments contain one or more router hops. Prefix Segment Identifier (Prefix-SID) is a Global Segment,
advertised by ISIS or OSPF and associated with a prefix, commonly with a loopback IP address. Prefix SID associated with the
loopback address is known as Node SID and N flag is set for it. Operator assigns a domain wide unique Prefix-SID to prefixes
in the domain. The domain wide uniqueness is a property. In the MPLS data plane, Prefix-SIDs are allocated from SRGB.
BGP prefix SID: There is one more type of prefix SID exists, and we call it BGP prefix SID. The BGP Prefix-SID is an
identifier of the BGP prefix segment. BGP-Prefix Segment is a BGP prefix with a Prefix-SID attached. It is used in seamless SR
across multiple ASes. A BGP Prefix-SID is always a global SID within the SR domain and identifies an instruction to forward
the packet over the Equal-Cost Multi-Path (ECMP) best-path computed by BGP to the related prefix. To support segment
routing, Border Gateway Protocol (BGP) requires the ability to advertise a segment identifier (SID) for a BGP prefix. When
BGP nodes communicate with neighbor nodes in a network, the BGP Update, message sent to neighbor nodes, includes the
Prefix-SID in Labeled Unicast NLRI and a prefix SID index in a new attribute called Prefix SID attribute.

Different Types of SIDs - IGP and BGP SID SIDs Cont…
To support forwarding paths for traffic engineering, the forwarding path may need to be different from the optimal path.
Hence, each BGP node assigns a local label to the neighbors and advertises the local label as adjacency SID through BGP-link
state updates.
A BGP Prefix-SID will be global across ASes when the interconnected ASes are part of the same SR domain. Alternatively,
when interconnecting ASes, the ASBRs of each domain will have to handle the advertisement of unique SIDs. BGP Prefix-SID
is yet to be supported by Junos and NorthStar.
3. Anycast Segment (Anycast-SID): IGP Anycast Segment Identifier (Anycast SID) is a special type of IGP Prefix Segment
which is represent the IGP least cost path between any router and a specified prefix. However, the specified prefix can be
advertised from multiple points in the network. An IGP-Anycast Segment specifies a set of routers. An "Anycast Segment" or
"Anycast SID“ enforces the ECMP-aware shortest-path forwarding towards the closest node of the anycast set.
4. Binding Segment (Binding-SID): Represents a tunnel (SR/LDP/RSVP) or in another words it represents a set of labels.
a. It can be used in LSP stitching or it can also be used to stitch or nest various domains. It has local significance to the
ingress node of the corresponding SID. It is used for Interop, a type of local SID. It can alias an entire LSP to one label. As
soon as router get Binding SID label It normally pushes additional stack of labels corresponding to the LSP.
b. The binding segment also used in local segment identification of an SR-TE policy. Normally each SR-TE policy is
associated with a binding segment ID (BSID).
Different Types of SIDs - BGP SIDs for EPE Solutions
Certain segments are defined by a BGP-EPE capable node and corresponding to its attached peers. These segments are called
BGP peering segments or BGP Peering SIDs. They enable the expression of source-routed inter-domain paths.
An ingress border router of an AS may compose a list of segments to steer a flow along a selected path within the AS, towards a
selected egress border router of the peer AS and through a specific local ASBR router. At minimum, a BGP Egress Peering
Engineering policy applied at an ingress EPE involves two segments: the Node SID of the chosen egress EPE and then the BGP
Peering Segment for the chosen egress EPE peer or peering interface.
5. BGP Segments - Peering Adjacency Segment (PeerAdj SID): Only used for Egress Peer Engineering
A Peer Adjacency Segment is a segment describing a link, including the SID (PeerAdj SID) allocated to it.
6. BGP Segments - Peering Node Segment (PeerNode SID): Only used for Egress Peer Engineering
A Peer Node Segment is a segment describing a peer, including the SID (PeerNode SID) allocated to it.
7. BGP Segments - Peering Set Segment (PeerSet SID): Only used for Egress Peer Engineering
A Peer Set Segment is a segment describing links or nodes that are part of the set, including the SID (PeerSet SID) allocated to
the set.

Different Types of SIDs - Multicast Support
Multicast Solution in SR: Variant of the SR Policy (covered later) for constructing a P2MP segment to support Point-to-
Multipoint service delivery. We call it an SR Replication Policy. A Point-to-Multipoint (P2MP) segment connects a Root node to a
set of Leaf nodes in a Segment Routing Domain. There are two types of a P2MP segment: Spray and Tree SID.
8. Spray SID: Spray P2MP segment enables a Root node to directly replicate a packet using a SR path to each Leaf node. A SR
Replication policy for a Spray P2MP segment is instantiated only at the Root node. There are no Replication nodes in these
segments.
9. Tree SID: For a Tree SID P2MP segment, a controller computes a tree from a Root node to a set of Leaf nodes via a set of
Replication nodes. A packet is replicated at the Root node and on Replication nodes towards each Leaf node. A SR Replication
policy instantiated on the Root node takes a packet from the Root node to Replication nodes towards the Leaf node. A
Replication node MAY also be a Leaf node. The SR Replication policy instantiated at the Replication nodes take the packet
down further to other Replication nodes or Leaf nodes.
Spray-SID and Tree-SID and along with BIER (Bit Index Explicit Replication) are still in discussion phase (No RLI yet). Currently
Spray-SID and Tree-SID are not available in Junos or NorthStar.
For further information on Spray and Tree SID please visit “https://tools.ietf.org/html/draft-voyer-spring-sr-p2mp-policy-02”
Spray-SID and Tree-SID are not covered in this document.

Adjacency SID
Adjacency-SID sub-TLV’s are present within the IS extended neighbor TLV and carry the locally significant label allocated to this
segment. Below is the format of the TLV. Single Adj-SID may be associated with a Multiple IS-neighbor for load balancing
purpose. Adjacency-SID carried in Adj-SID (31) sub-TLV of Extended IS Reachability (22) TLV. Below is Adjacency Segment
Identifier (Adj-SID) Sub-TLV format:
https://tools.ietf.org/id/draft-ietf-isis-segment-routing-extensions-20.html
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 F-flag: Address family flag. Set for IPv6, unset for IPv4.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B-Flag: Set when protection is enabled for adj-sid.
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V-Flag: Set when adj-sid contains label value. Set by default.
where: L-Flag: It is set when value is of local significance: By default it is set.
S-Flag: It indicates adj-sid refers to set of adjacencies.

Type: TBD, suggested value 31;
Length: variable; Other bits: MUST be zero when originated and ignored when received.
Flags: 1 octet field of flags;
Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|B|V|L|S| |
+-+-+-+-+-+-+-+-+

Adjacency SID Cont…
Each router in the topology advertises a label associated with each of its IGP adjacencies (one each for IPv4 and IPv6) with
neighboring routers. Such Adjacency Segments have strict forwarding semantics. This means that in the data plane, when a
packet arrives with that adjacency label, the router pops it and sends it onto the associated link.
The minimum configuration to invoke Adjacency Segments: “set protocols isis source-packet-routing”
root@R1> show isis adjacency extensive
R4
Interface: ge-0/0/0.0, Level: 2, State: Up, Expires in 25 secs
Priority: 0, Up/Down transitions: 1, Last transition: 00:02:15 ago
Circuit type: 2, Speaks: IP, IPv6
Topologies: Unicast
Restart capable: Yes, Adjacency advertisement: Advertise
IP addresses: 1.1.1.2 . . .
Level 2 IPv4 Adj-SID: 28 R3
State: Up Interface: ge-0/0/4.0, Level: 2, State: Up, Expires in 26 secs
Priority: 0, Up/Down transitions: 1, Last transition: 00:02:40 ago
R2 Circuit type: 2, Speaks: IP, IPv6
Interface: ge-0/0/1.0, Level: 2, State: Up, Expires in 21 secs Topologies: Unicast
Priority: 0, Up/Down transitions: 1, Last transition: 00:01:44 ago Restart capable: Yes, Adjacency advertisement: Advertise
Circuit type: 2, Speaks: IP, IPv6 IP addresses: 1.1.1.46
Topologies: Unicast Level 2 IPv4 Adj-SID: 27
Restart capable: Yes, Adjacency advertisement: Advertise State: Up
IP addresses: 1.1.1.6 . . .
Level 2 IPv4 Adj-SID: 29 root@R1>
State: Up
. . .
Note: For LAN Segment, each router advertises a set of Adj-SIDs for each of its neighbors
Adjacency SID Cont…
root@R1> show isis database R1.00-00 extensive root@R1> show route table mpls.0
. . .
R1.00-00 Sequence: 0xa94, Checksum: 0x1eb5, Lifetime: 951 secs mpls.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
IPV4 Index: 101 + = Active Route, - = Last Active, * = Both
Node Segment Blocks Advertised: . . .
Start Index : 0, Size : 1000, Label-Range: [ 1000, 1999 ] 27 *[L-ISIS/14] 00:08:20, metric 0 <<< L-ISIS stands for labeled IS-IS.
IS neighbor: R2.00 Metric: 10 > to 1.1.1.46 via ge-0/0/4.0, Pop
Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00 27(S=0) *[L-ISIS/14] 00:08:05, metric 0
P2P IPv4 Adj-SID: 29, Weight: 0, Flags: --VL-- > to 1.1.1.46 via ge-0/0/4.0, Pop
IS neighbor: R3.00 Metric: 10 28 *[L-ISIS/14] 00:08:14, metric 0
Two-way fragment: R3.00-00, Two-way first fragment: R3.00-00 > to 1.1.1.2 via ge-0/0/0.0, Pop
P2P IPv4 Adj-SID: 27, Weight: 0, Flags: --VL-- 28(S=0) *[L-ISIS/14] 00:08:05, metric 0
IS neighbor: R4.00 Metric: 10 > to 1.1.1.2 via ge-0/0/0.0, Pop
Two-way fragment: R4.00-00, Two-way first fragment: R4.00-00 29 *[L-ISIS/14] 00:08:14, metric 0
P2P IPv4 Adj-SID: 28, Weight: 0, Flags: --VL-- > to 1.1.1.6 via ge-0/0/1.0, Pop
. . . 29(S=0) *[L-ISIS/14] 00:03:52, metric 0
TLVs: > to 1.1.1.6 via ge-0/0/1.0, Pop
. . . . . .
Extended IS Reachability TLV, Type: 22, Length: 217 root@R1>
IS extended neighbor: R3.00, Metric: default 10 SubTLV len: 81
. . .
P2P IPV4 Adj-SID - Flags:0x70(F:0,B:1,V:1,L:1,S:0,P:0), Weight:0, Label: 27 Note: All the Adj SID labels advertised by any router in the SR network
P2P IPv4 Adj-SID: 27, Weight: 0, Flags: -BVL-- will have POP action in their mpls.0 table.
. . .
. . .
P2P IPV4 Adj-SID - Flags:0x70(F:0,B:1,V:1,L:1,S:0,P:0), Weight:0, Label: 28
P2P IPv4 Adj-SID: 28, Weight: 0, Flags: -BVL--
. . .
Extended IS Reachability TLV, Type: 22, Length: 92
. . .
. . .
root@R1>
Adjacency SID - Forwarding Rule
Adjacency SID Working - Will be acting as strict hope tunnel. Won’t follow IGP shortest path. Max label stack depth can be 5.
b
c c
d d d
Pay Load Pay Load Pay Load Pay Load
SID: a SID: b SID: c SID: d

R1 SID: w
R2 SID: x
R3 SID: y
R4 SID: z
R4

Adjacency SID - Unprotected and Protected Adjacency Segments
You can have some traffic that you want to benefit from fast protection, but other traffic may not need such protection. In order to
distinguish between these traffic types, you can arrange for separate adjacency labels to be allocated.
set protocols isis interface ge-0/0/1.0 link-protection <<< No protection without this, No programming in PFE Until LFA kicks in
set protocols isis interface ge-0/0/1.0 level 2 ipv4-adjacency-segment protected dynamic (or label <label_from_static_range>)
set protocols isis interface ge-0/0/1.0 level 2 ipv4-adjacency-segment unprotected dynamic (or label <label_from_static_range>)
Note: Please use “show mpls label usage” to know the static label range
The dynamic keyword triggers the router to automatically allocate a label value. The preceding two commands result in two
adjacency labels to be allocated to ge-0/0/1 as follows: root@R1> show isis database R1.00-00 extensive | no-more
. . .
R1.00-00 Sequence: 0xa87, Checksum: 0x8d29, Lifetime: 950 secs
IPV4 Index: 101
• IPv4 traffic, protection required Node Segment Blocks Advertised:
• IPv4 traffic, no protection required Start Index : 0, Size : 1000, Label-Range: [ 1000, 1999 ]
IS neighbor: R2.00 Metric: 10
Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00
root@R1> show isis adjacency R2 extensive | no-more
P2P IPv4 Adj-SID: 178, Weight: 0, Flags: --VL--
R2
. . .
Interface: ge-0/0/1.0, Level: 2, State: Up, Expires in 19 secs
TLVs:
Priority: 0, Up/Down transitions: 1, Last transition: 3w2d 22:31:06 ago
. . .
Circuit type: 2, Speaks: IP, IPv6
Topologies: Unicast
. . .
Restart capable: Yes, Adjacency advertisement: Advertise
IP addresses: 1.1.1.6
Level 2 IPv4 protected Adj-SID: 177, Flags: -BVL-- <<< Protected SID
Level 2 IPv4 unprotected Adj-SID: 178, Flags: --VL-- <<< Unprotected SID
State: Up
. . .
root@R1>
root@R1>
Adjacency SID - Unprotected and Protected Adjacency Segments Cont…
root@R1> show route label 177
Relevent Config:
mpls.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
protocols {
isis { 177 *[L-ISIS/14] 00:08:15, metric 0
> to 1.1.1.6 via ge-0/0/1.0, Pop
backup-spf-options { <<< Need to enable TI-LFA, By default to 1.1.1.2 via ge-0/0/0.0, Swap 4102 << 4102 label used by R4 for R2’s Node SID
use-post-convergence-lfa; TI-LFA provides link 177(S=0) *[L-ISIS/14] 00:00:34, metric 0
protection > to 1.1.1.6 via ge-0/0/1.0, Pop
use-source-packet-routing; to 1.1.1.2 via ge-0/0/0.0, Swap 4102
}
interface ge-0/0/1.0 { root@R1> show route label 178
point-to-point; mpls.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
level 2 { + = Active Route, - = Last Active, * = Both
post-convergence-lfa;
metric 1000; 178 *[L-ISIS/14] 00:20:37, metric 0
ipv4-adjacency-segment { > to 1.1.1.6 via ge-0/0/1.0, Pop
protected dynamic; 178(S=0) *[L-ISIS/14] 00:01:01, metric 0
> to 1.1.1.6 via ge-0/0/1.0, Pop
unprotected dynamic;
} root@R1> show route label 177 extensive
}
} mpls.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
} 177 (1 entry, 1 announced)
} . . .
Next hop: 1.1.1.6 via ge-0/0/1.0 weight 0x1, selected
Label operation: Pop
. . .
N0te: Adj-SID with backup flags are advertised in the IGP Next hop: 1.1.1.2 via ge-0/0/0.0 weight 0xf000
domain. You can map the interested traffic to the protected label Label operation: Swap 4102
. . .
(or unprotected label). Mapping can be done by provisioning LSP 177(S=0) (1 entry, 1 announced)
. . .
by external controller (NorthStar) or by statically provisioning of Next hop: 1.1.1.6 via ge-0/0/1.0 weight 0x1, selected
LSP. Label operation: Pop
. . .
Next hop: 1.1.1.2 via ge-0/0/0.0 weight 0xf000
Label operation: Swap 4102
. . .
root@R1>
Adjacency SID - Unprotected and Protected Adjacency Segments Cont…
root@R1> show route forwarding-table label 177 root@R1> show route forwarding-table label 178
Routing table: default.mpls Routing table: default.mpls
MPLS: MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif Destination Type RtRef Next hop Type Index NhRef Netif
177 user 0 ulst 1048578 2 178 user 0 1.1.1.6 Pop 525 3 ge-0/0/1.0
1.1.1.6 Pop 525 3 ge-0/0/1.0 178(S=0) user 0 1.1.1.6 Pop 526 3 ge-0/0/1.0
1.1.1.2 Swap 4102 524 4 ge-0/0/0.0 . . .
177(S=0) user 0 ulst 1048579 2 root@R1>
1.1.1.6 Pop 526 3 ge-0/0/1.0
1.1.1.2 Swap 4102 524 4 ge-0/0/0.0
. . .
root@R1> start shell command "cprod -A fpc0 -c \"show nhdb id 1048578 recursive\""
1048578(Unilist, IPv4, ifl:0:-, pfe-id:0)

525(Unicast, MPLS->IPv4, ifl:326:ge-0/0/1.0, pfe-id:0)
524(Unicast, MPLS, ifl:324:ge-0/0/0.0, pfe-id:0)
root@R1> start shell command "cprod -A fpc0 -c \"show nhdb id 1048578 extensive\""
ID Type Interface Next Hop Addr Protocol Encap MTU Flags PFE internal Flags
----- -------- ------------- --------------- ---------- ------------ ---- ------------------ ------------------
1048578 Unilist ge-0/0/1.0 - IPv4 Ethernet 0 0x0000000000000000 0x0000000000000000
. . .
Weight Info (Selector's view): Current Weight = 1, Target_id = 0
Idx Balance Weight Orig-Weight Ifl Session Install
----- ------- ------- ----------- ------ ------- -------
0 ** 1 1 326 358 Yes
1 ** 61440 61440 324 361 No
. . .
ECMP : NO
525 Unicast ge-0/0/1.0 - MPLS->IPv4 Ethernet 1500 0x0000000000200001 0x0000000000000002

524 Unicast ge-0/0/0.0 - MPLS Ethernet 1500 0x0000000000000001 0x0000000000000002
Weight Info: Current Weight = 1

ID Balance Orig-Balance Weight Orig-Weight State Install Flags
----- ------- --------- ------ ----------- -------- ----------- -----
525 0 0 1 1 Active Installed 0x00
524 0 0 61440 61440 Standby Installed 0x00
Routing-table id: 0
. . .
root@R1>
Adjacency SID Set - For loadbalancing across multiple links
It’s possible to assign a common label to multiple adjacencies on a node for load balancing purpose. This is known as an
Adjacency Set (Adj-Set) for short. In the below example, when data-plane packets arrive at local router with a top label value of
1000000, the label is popped, and the packets are load-balanced on links ge-0/0/0 and ge-0/0/1 in a 1:3 ratio.
set protocols isis interface-group group-1 interface ge-0/0/0.0 weight 1

set protocols isis interface-group group-1 interface ge-0/0/1.0 weight 3
set protocols isis interface-group group-1 level 2 ipv4-adjacency-segment protected label 1000000 <<< Any Label from static range
root@R1> show route label 1000000 extensive table mpls.0

1000000 (1 entry, 1 announced)
TSI:
KRT in-kernel 1000000/52 -> {list:Pop , Pop }
*L-ISIS Preference: 14
. . .
Next hop: 1.1.1.2 via ge-0/0/0.0 weight 0x1 balance 25%, selected
. . .
Next hop: 1.1.1.6 via ge-0/0/1.0 weight 0x1 balance 75%
. . .
TLVs:
. . .
. . .
root@R1>
Extended IS Reachability TLV, Type: 22, Length: 205
. . .
P2P IPV4 Adj-SID - Flags:0x7c(F:0,B:1,V:1,L:1,S:1,P:1), Weight:3, Label: 1000000
P2P IPv4 Adj-SID: 1000000, Weight: 3, Flags: -BVLSP
. . .
© 2018 Juniper Networks root@R1> 34
Prefix and Node SID
The Prefix SID’s or Node SID (Prefix SID with N flag) assigned within ISIS segment routing configuration are included within the
IPv4 and IPv6 prefix TLV’s to advertise the global SID used to reach this device. The is Prefix-SID (also Node-SID) carried in
Prefix-SID (3) TLV of Extended IP Reachability (135) TLV. Below is the format of the Sub-TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Algorithm: The router may use various algorithms when calculating
| Type | Length | Flags | Algorithm | reachability to other nodes or to prefixes attached to these nodes. Juniper
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ supports SPF. Please see below link for more details for Algorithm and flags
| SID/Index/Label (variable) | details.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
https://tools.ietf.org/id/draft-ietf-isis-segment-routing-extensions-20.html
where:
Type: TBD, suggested value 3;

Length: variable;
Flags: 1 octet field of flags (on next slide):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|N|P|E|V|L| |
+-+-+-+-+-+-+-+-+
IS-IS SPRING Install route in inet.3 table advertised as part of the Node SID configured. Protocols like BGP, in L3VPN and
L2VPN applications etc, resolve its protocol next-hop in the table inet.3/inet6.3 only.
Prefix and Node SID Cont…
R-Flag: Re-advertisement flag. If set, then the prefix to which this Prefix-SID is attached, has been propagated by the router either from
another level (i.e., from level-1 to level-2 or the opposite) or from redistribution (e.g.: from another protocol).
N-Flag: Node-SID flag. If set, then the Prefix-SID refers to the router identified by the prefix. Typically, the N-Flag is set on Prefix-SIDs
attached to a router loopback address. The N-Flag is set when the Prefix-SID is a Node-SID.
P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT pop the Prefix-SID before delivering the packet to the node that
advertised the Prefix-SID.
E-Flag: Explicit-Null Flag. If set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with a Prefix-SID having
an Explicit-NULL value (0 for IPv4 and 2 for IPv6) before forwarding the packet. In other words, To disable penultimate-hop-popping
(PHP) and add explicit-Null label, explicit-null option needs to be specified.
V-Flag: Value flag. If set, then the Prefix-SID carries a value (instead of an index). By default the flag is UNSET.
L-Flag: Local Flag. If set, then the value/index carried by the Prefix-SID has local significance. By default the flag is UNSET.
Other bits: MUST be zero when originated and ignored when received.
N Flag will be clear in case of Anycast SID or Prifix SID advertisement: If a node SID is advertised across levels then it becomes prefix SID
and it ceases to exists as Node SID in the other level. R-bit is set to indicate re-advertised. When R-bit is set, N-bit is ignored.

Prefix Segment Index can be provisioned via policy for each prefix, along with the option to mark it as a Node Segment. IGP
advertises the Start Label and Node Segment Index in the domain. Remote routers calculate the label to reach the local router.
The process is shown on next page.
Prefix SID Config: Node SID Config (Without Policy):

protocols { protocols {
isis { isis {
export ISIS-Export; source-packet-routing {
} srgb start-label 1000 index-range 1000;
} node-segment ipv4-index 101;
policy-options { }
policy-statement ISIS-Export { interface lo0.1 {
term Prifix-SID { passive;
from { }
protocol direct; }
route-filter 10.10.10.1/32 exact; }
} ^^^^^^^^^^^ Since the SID is allocated per prefix, the from clause will have
then { restriction to use only route-filter with exact match.
prefix-segment index 599; <<< Index needs to be within the SRGB range, It would become Node-SID, If we put “node-segment” keyword after “index 599”.
accept;
}
}
}
}
Note: Please use “show mpls label usage” to know the SRGB range
root@R1> show isis database R1.00-00 extensive root@R1> show isis overview | no-more
. . . Instance: master
R1.00-00 Sequence: 0xa95, Checksum: 0x1cb6, Lifetime: 716 secs Router ID: 192.168.1.1
IPV4 Index: 101 Hostname: R1
Node Segment Blocks Advertised: Sysid: 0000.0000.0001
Start Index : 0, Size : 1000, Label-Range: [ 1000, 1999 ] Areaid: 49.0001
. . . . . .
TLVs: IPv4 is enabled, IPv6 is enabled, SPRING based MPLS is enabled
. . . . . .
Hostname: R1 Source Packet Routing (SPRING): Enabled
Router Capability: Router ID 192.168.1.1, Flags: 0x00 SRGB Config Range:
SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 1000, SID-Label: 1000 SRGB Start-Label : 1000, SRGB Index-Range : 1000
SPRING Algorithm - Algo: 0 SRGB Block Allocation: Success
. . . SRGB Start Index : 1000, SRGB Size : 1000, Label-Range: [ 1000, 1999 ]
IP extended prefix: 192.168.1.1/32 metric 0 up Node Segments: Enabled
8 bytes of subtlvs Ipv4 Index : 101
Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 101 Post Convergence Backup: Enable d
IP extended prefix: 10.10.10.1/32 metric 10 up Max labels: 3, Max spf: 100, Max Ecmp Backup: 1
8 bytes of subtlvs Level 1
Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 599 . . .
. . . Source Packet Routing is enabled
root@R1> Level 2
. . .
Source Packet Routing is enabled
root@R1>
Note: Node Index can not be same on any two routers. It must be different on
all the router. We can configure same start label and range on all the routers.
Prefix and Node SID - Forwarding Rules
Prefix/Node SID Working – It follows IGP shortest path. Formula to calculate the label for remote Router is:
Downstream Neighbor's Expected Node SID from local Router = Start-label of downstream neighbor router’s label range + Node index advertised by Destination Router
Case 1: When SRGB is different on all the routers: Results in different labels by each router to the destination. We have used
different SRGB on all the routers in throughout this presentation.
w+e = L Label L used by R2 x+e = M Label M used by y+e = N Label N used by R4
Pay Load for R5’s Node SID Pay Load R3 for R5’s Node Pay Loadfor R5’s Node SID Pay Load
SID
R1 R2 R3 R4 R5
Start Label: v Start Label: w Start Label: x Start Label: y Start Label: z
Index: a Index: b Index: c Index: d Index: e
Case 2: When SRGB is same on all the routers: Results in same labels used by each router to reach to the destination. In SR-
MPLS, using identical SRGBs on all nodes within the SR domain is strongly recommended. Doing so eases operations and
troubleshooting as the same label represents the same global segment at each node.
w+e = L Label L used by R2 w+e = L Label L used by R3 w+e = L Label L used by R4
Pay Loadfor R5’s Node SID Pay Load for R5’s Node SID Pay Loadfor R5’s Node SID Pay Load
R1 R2 R3 R4 R5
Start Label: w Start Label: w Start Label: w Start Label: w Start Label: w
Index: a Index: b Index: c Index: d Index: e

root@R1> show route 192.168.1.9 table inet.0
inet.0: 43 destinations, 53 routes (43 active, 0 holddown, 0 hidden)

R3 - lo0.0- + = Active Route, - = Last Active, * = Both
192.168.1.3/32
ge-0/0/0 SL: 3000 ge-0/0/1 192.168.1.9/32 *[L-ISIS/14] 00:07:30, metric 40
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
> to 1.1.1.2 via ge-0/0/0.0, Push 4109
label used by R1 for to 1.1.1.6 via ge-0/0/1.0, Push 2109
R9’s Node Segment: to 1.1.1.46 via ge-0/0/4.0, Push 3109
3109 [IS-IS/18] 00:07:30, metric 40
Swapped with 6109 > to 1.1.1.2 via ge-0/0/0.0
to 1.1.1.6 via ge-0/0/1.0
Example: When to 1.1.1.46 via ge-0/0/4.0
SRGB is different root@R1> traceroute 192.168.1.9 <<< Tracing R9’s loopback from R1
traceroute to 192.168.1.9 (192.168.1.9), 30 hops max, 40 byte packets
on all the routers. 1 1.1.1.2 (1.1.1.2) 6.429 ms 2.794 ms 3.494 ms
MPLS Label=4109 CoS=0 TTL=1 S=1 <<< R4’s First label + R9’s Index
2 1.1.1.14 (1.1.1.14) 10.993 ms 3.894 ms 4.224 ms
Diagram is 3 1.1.1.34 (1.1.1.34) 11.629 ms 44.870 ms 5.151 ms
showing the label 4 192.168.1.9 (192.168.1.9) 6.876 ms 7.165 ms 7.063 ms
used by routers for ge-0/0/4

1.1.1.45/3
ge-0/0/4
1.1.1.49/30
root@R1>
R9’s Node SID. R1 - lo0.0- ge-0/0/0

192.168.1.1/32 1.1.1.1/30
ge-0/0/0 R4-RR - lo0.0- ge-0/0/1
1.1.1.2/30 192.168.1.4/32 1.1.1.13/30
ge-0/0/1 R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0-
1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 SL: 8000
Index: 101 Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106 Index: 108
Also routers are ge-0/0/1
1.1.1.5/30
ge-0/0/3
1.1.1.21/30
ge-0/0/3
1.1.1.33/30
ge-0/0/1
1.1.1.41/30
showing action label used by R1 for R9’s
Node Segment: 1109
label used by R1 for R9’s
Node Segment: 4109
Node Segment: 6109
Node Segment: 8109
programmed for Swapped with ECMP
(4109, 2109, 3109)
Swapped with ECMP
(6109, 6109, 5109)
Swapped with ECMP
(7109, 8109)
POP
these labels.
Segment Routing
AS100
label used by R1 for label used by R1 for label used by R1 for

R9’s Node Segment: R9’s Node Segment: R9’s Node Segment:
2109 5109 7109
Swapped with 5109
ge-0/0/1 Swapped
ge-0/0/3with 7109ae0 ae0 POP
ge-0/0/3 ge-0/0/1
1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 192.168.1.5/32 192.168.1.7/32 192.168.1.9/32


R3 - lo0.0- + = Active Route, - = Last Active, * = Both
192.168.1.3/32
ge-0/0/0 SL: 1000 ge-0/0/1 192.168.1.9/32 *[L-ISIS/14] 00:02:10, metric 40
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
> to 1.1.1.2 via ge-0/0/0.0, Push 1109
label used by R1 for to 1.1.1.6 via ge-0/0/1.0, Push 1109
R9’s Node Segment: to 1.1.1.46 via ge-0/0/4.0, Push 1109
1109 [IS-IS/18] 00:02:10, metric 40
Swapped with 1109 > to 1.1.1.2 via ge-0/0/0.0
to 1.1.1.6 via ge-0/0/1.0
Example: When to 1.1.1.46 via ge-0/0/4.0
SRGB is same on root@R1> traceroute 192.168.1.9 <<< Tracing R9’s loopback from R1
all the routers. 1 1.1.1.2 (1.1.1.2) 6.429 ms 2.794 ms 3.494 ms
2 1.1.1.14 (1.1.1.14) 10.993 ms 3.894 ms 4.224 ms
Diagram is 3 1.1.1.34 (1.1.1.34) 11.629 ms 44.870 ms 5.151 ms
showing the label 4 192.168.1.9 (192.168.1.9) 6.876 ms 7.165 ms 7.063 ms
used by routers for ge-0/0/4

1.1.1.45/3
ge-0/0/4
1.1.1.49/30
root@R1>
R9’s Node SID. R1 - lo0.0- ge-0/0/0

192.168.1.1/32 1.1.1.1/30
ge-0/0/0 R4-RR - lo0.0- ge-0/0/1
1.1.1.2/30 192.168.1.4/32 1.1.1.13/30
ge-0/0/1 R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0-
1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 SL: 1000 ge-0/0/2 ge-0/0/2 SL: 1000 SL: 1000
Also routers are ge-0/0/1
1.1.1.5/30
ge-0/0/3
1.1.1.21/30
ge-0/0/3
1.1.1.33/30
ge-0/0/1
1.1.1.41/30
showing action label used by R1 for R9’s
Node Segment: 1109
Node Segment: 1109
Node Segment: 1109
Node Segment: 1109
programmed for Swapped with ECMP
(1109, 1109, 1109)
Swapped with ECMP
(1109, 1109, 1109)
Swapped with ECMP
(1109, 1109)
POP
these labels.
Segment Routing
AS100
label used by R1 for label used by R1 for label used by R1 for

R9’s Node Segment: R9’s Node Segment: R9’s Node Segment:
1109 1109 1109
Swapped with 1109
ge-0/0/1 Swapped
ge-0/0/3with 1109ae0 ae0 POP
ge-0/0/3 ge-0/0/1
1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 192.168.1.5/32 192.168.1.7/32 192.168.1.9/32

Prefix-SID/Node-SID Example
root@R9> traceroute 192.168.1.1 no-resolve <<< Tracing R1’s loopback from R9
root@R9> show route table inet.3
1 1.1.1.37 (1.1.1.37) 11.273 ms 7.053 ms 6.765 ms
2 1.1.1.33 (1.1.1.33) 36.310 ms 28.697 ms 14.451 ms
3 1.1.1.50 (1.1.1.50) 9.042 ms 17.376 ms 11.216 ms
10.10.10.1/32 *[L-ISIS/14] 00:01:46, metric 50
to 1.1.1.37 via ge-0/0/0.0, Push 7599 <<< Prefix MPLS Label=3101 CoS=0 TTL=1 S=1 <<< R3’s First label + R1’s Index
4 192.168.1.1 (192.168.1.1) 20.233 ms 17.574 ms 53.986 ms
SID
> to 1.1.1.41 via ge-0/0/1.0, Push 8599
192.168.1.1/32 *[L-ISIS/14] 00:01:46, metric 40 root@R9> traceroute 10.10.10.1 no-resolve <<< Tracing Prefix SID on R1 from R9
to 1.1.1.37 via ge-0/0/0.0, Push 7101 <<< Node
SID 1 1.1.1.37 3.177 ms 3.002 ms 3.008 ms
MPLS Label=7599 CoS=0 TTL=1 S=1 <<< R7’s First label + Prefix SID Index on R1
> to 1.1.1.41 via ge-0/0/1.0, Push 8101
2 1.1.1.33 4.683 ms 3.998 ms 3.528 ms
192.168.1.2/32 *[L-ISIS/14] 00:02:04, metric 30
> to 1.1.1.37 via ge-0/0/0.0, Push 7102
3 1.1.1.50 5.661 ms 49.206 ms 7.702 ms
192.168.1.3/32 *[L-ISIS/14] 00:01:46, metric 30
to 1.1.1.37 via ge-0/0/0.0, Push 7103
4 10.10.10.1 7.811 ms 9.425 ms 8.956 ms
> to 1.1.1.41 via ge-0/0/1.0, Push 8103
192.168.1.4/32 *[L-ISIS/14] 00:01:46, metric 30
to 1.1.1.37 via ge-0/0/0.0, Push 7104 root@R9>
> to 1.1.1.41 via ge-0/0/1.0, Push 8104 Note: The current ISIS implementation supports setting the Explicit null flag in
192.168.1.5/32 *[L-ISIS/14] 00:02:04, metric 20
> to 1.1.1.37 via ge-0/0/0.0, Push 7105 all prefix-sids (with or without N flag set). On setting Explicit-NULL flag, any
192.168.1.6/32 *[L-ISIS/14] 00:01:46, metric 20 upstream neighbor of the Prefix-SID originator must replace the Prefix-SID with
to 1.1.1.37 via ge-0/0/0.0, Push 7106
> to 1.1.1.41 via ge-0/0/1.0, Push 8106 a Prefix-SID having an Explicit NULL value (0 for IPv4 and 2 for IPv6) before
192.168.1.7/32 *[L-ISIS/14] 00:08:01, metric 10 forwarding the packet.
> to 1.1.1.37 via ge-0/0/0.0
192.168.1.8/32 *[L-ISIS/14] 00:08:01, metric 10
> to 1.1.1.41 via ge-0/0/1.0 set protocols isis source-packet-routing explicit-null
192.168.1.101/32 *[L-ISIS/14] 00:01:46, metric 30
to 1.1.1.37 via ge-0/0/0.0, Push 7499
> to 1.1.1.41 via ge-0/0/1.0, Push 8499 With the above command set, all prefix-sids (with or without N flag set) are
originated with P and E flag set. Hence all the penultimate routers should either
root@R9>
push 0 or 2 based on V4 or V6 packet.
Tracing R9’s Prefix-SID/Node-SID from R1 across the network
root@R1> traceroute 192.168.1.9 source 192.168.1.1 no-resolve <<< Tracing R9’s loopback from R1
traceroute to 192.168.1.9 (192.168.1.9) from 192.168.1.1, 30 hops max, 40 byte packets
1 1.1.1.2 1.034 ms 0.663 ms 0.638 ms
2 1.1.1.14 0.806 ms 0.688 ms 0.676 ms
3 1.1.1.30 0.806 ms 0.631 ms 1.654 ms
MPLS Label= 8109 CoS=0 TTL=1 S=1 <<< R8’s First label + R9’s Index
4 192.168.1.9 8.588 ms 2.218 ms 1.994 ms
root@R1> show route 192.168.1.9/32 table inet.0 | no-more

192.168.1.9/32 *[ L-ISIS/14] 03:24:37, metric 40

> to 1.1.1.2 via ge-0/0/0.0, Push 4109 <<< 4109 (4000 + 109) label is used by R4 for R9 Node segment
to 1.1.1.6 via ge-0/0/1.0, Push 2109 <<< 2109 (2000 + 109) label is used by R2 for R9 Node segment
to 1.1.1.46 via ge-0/0/4.0, Push 3109 <<< 3109 (3000 + 109) label is used by R3 for R9 Node segment
[IS-IS/18] 03:24:37, metric 40
> to 1.1.1.2 via ge-0/0/0.0
to 1.1.1.6 via ge-0/0/1.0
to 1.1.1.46 via ge-0/0/4.0
root@R1> show route forwarding-table destination 192.168.1.9/32

Routing table: default.inet
. . .
Destination Type RtRef Next hop Type Index NhRef Netif
192.168.1.9/32 user 1 ulst 1048592 3
1.1.1.2 Push 4109 694 2 ge-0/0/0.0 <<< Traceroute is taking this path. This NH is R4, Need to go on R4 Now.
1.1.1.6 Push 2109 695 2 ge-0/0/1.0
1.1.1.46 Push 3109 683 2 ge-0/0/4.0
. . .
root@R1>`

Tracing R9’s Prefix-SID/Node-SID from R1 across the network Cont…
. . .
192.168.1.9/32 user 1 1.1.1.14 Push 6109 626 3 ge-0/0/1.0
. . .

4109 *[L-ISIS/14] 03:25:36, metric 30

> to 1.1.1.14 via ge-0/0/1.0, Swap 6109 <<< 6109 (6000 + 109) label is used by R6 for R9 Node segment, Traceroute is taking this path. This NH is R6, Need to go on R6
Now.
to 1.1.1.18 via ge-0/0/2.0, Swap 6109 <<< 6109 (6000 + 109) label is used by R6 for R9 Node segment, Using Second Link
to 1.1.1.22 via ge-0/0/3.0, Swap 5109 <<< 5109 (5000 + 109) label is used by R5 for R9 Node segment
root@R4>

. . .
192.168.1.9/32 user 0 1.1.1.30 Push 8109 609 2 ge-0/0/0.0
. . .

6109 *[L-ISIS/14] 03:28:15, metric 20

to 1.1.1.30 via ge-0/0/0.0, Swap 8109 <<< 8109 (8000 + 109) label is used by R8 for R9 Node segment, Traceroute is taking this path. This NH is R8, Need to go on R8
Now.
> to 1.1.1.34 via ge-0/0/3.0, Swap 7109 <<< 7109 (7000 + 109) label is used by R7 for R9 Node segment
root@R6>
Tracing R9’s Prefix-SID/Node-SID from R1 across the network Cont…
. . .
192.168.1.9/32 user 0 1.1.1.42 ucst 626 2 ge-0/0/1.0
. . .

8109 *[L-ISIS/14] 03:32:53, metric 10

> to 1.1.1.42 via ge-0/0/1.0, Pop <<< 8109 label is popped and IPv4 packet is forwarded to R9.
8109(S=0) *[L-ISIS/14] 00:03:28, metric 10
> to 1.1.1.42 via ge-0/0/1.0, Pop
root@R8>

Tracing Prefix-SID/Node-SID - Enabling UHP
root@R1> show route 3.3.3.8/30 extensive
root@R1> show route receive-protocol bgp 192.168.1.9
3.3.3.8/30 (1 entry, 1 announced)
Prefix Nexthop MED Lclpref AS path
TSI:
* 3.3.3.8/30 192.168.1.9 100 I
. . .
. . .
Path 3.3.3.8
from 192.168.1.9
Vector len 4. Val: 0
*BGP Preference: 170/-101
. . .
192.168.1.9/32 *[L-ISIS/14] 00:21:46, metric 40
Next hop: 1.1.1.2 via ge-0/0/0.0, selected
> to 1.1.1.2 via ge-0/0/0.0, Push 4109
Label operation: Push 4109
to 1.1.1.6 via ge-0/0/1.0, Push 2109
. . .
to 1.1.1.46 via ge-0/0/4.0, Push 3109
[IS-IS/18] 00:21:46, metric 40
Protocol next hop: 192.168.1.9
> to 1.1.1.2 via ge-0/0/0.0
. . .
to 1.1.1.6 via ge-0/0/1.0
root@R1> show spring-traffic-engineering lsp detail
to 1.1.1.46 via ge-0/0/4.0
Name: R1-to-R9
Tunnel-source: Path computation element protocol(PCEP)
To: 192.168.1.9
State: Up
192.168.1.9/32 *[SPRING-TE/6] 00:00:54, metric 1, metric2 0
Outgoing interface: ge-0/0/0.0
> to 1.1.1.2 via ge-0/0/0.0, Push 4109
Auto-translate status: Disabled Auto-translate result: N/A
[L-ISIS/14] 00:35:47, metric 40
BFD status: N/A BFD name: N/A
> to 1.1.1.2 via ge-0/0/0.0, Push 4109
SR-ERO hop count: 2
to 1.1.1.6 via ge-0/0/1.0, Push 2109
Hop 1 (Strict):
to 1.1.1.46 via ge-0/0/4.0, Push 3109
NAI: IPv4 Adjacency ID, 1.1.1.1 -> 1.1.1.2 <<< NAI (Node or Adjacency identifier)
SID type: 20-bit label, Value: 18
root@R1>
Hop 2 (Strict):
NAI: IPv4 Node ID, Node address: 192.168.1.9
Total displayed LSPs: 1 (Up: 1, Down: 0)

Tracing Prefix-SID/Node-SID - Enabling UHP Cont…
root@R1> traceroute 3.3.3.10 root@R6> show route label 6109
1 1.1.1.2 (1.1.1.2) 9.238 ms 8.040 ms 5.395 ms mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
MPLS Label=4109 CoS=0 TTL=1 S=1 <<< R4’s First label + R9’s Index + = Active Route, - = Last Active, * = Both
2 1.1.1.14 (1.1.1.14) 6.314 ms 32.598 ms 6.829 ms
MPLS Label=6109 CoS=0 TTL=1 S=1 <<< R6’s First label + R1’s Index 6109 *[L-ISIS/14] 1d 23:15:23, metric 20
3 1.1.1.34 (1.1.1.34) 28.810 ms 7.628 ms 11.992 ms to 1.1.1.30 via ge-0/0/0.0, Swap 8109
MPLS Label=7109 CoS=0 TTL=1 S=1 <<< R7’s First label + R1’s Index > to 1.1.1.34 via ge-0/0/3.0, Swap 7109
4 3.3.3.10 (3.3.3.10) 11.670 ms 14.965 ms 20.195 ms
root@R6>
root@R1>
root@R1> show route label 18 table mpls.0 <<< Label 18 is not in trace; it is there in LSP
label stack to make LSP get resolve in mpls.0. mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
mpls.0: 42 destinations, 42 routes (42 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
7109 *[L-ISIS/14] 00:29:34, metric 10
18 *[L-ISIS/14] 1w2d 03:07:40, metric 0 > to 1.1.1.38 via ge-0/0/0.0, Swap 0 <<< IPv4 explicit null label.
> to 1.1.1.2 via ge-0/0/0.0, Pop 7109(S=0) *[L-ISIS/14] 00:07:08, metric 10
18(S=0) *[L-ISIS/14] 00:06:21, metric 0 > to 1.1.1.38 via ge-0/0/0.0, Pop
> to 1.1.1.2 via ge-0/0/0.0, Pop
root@R7>
root@R1>
root@R9> show route label 0 <<< IPv4 explicit null label.
0 *[MPLS/0] 3d 11:49:26, metric 1
4109 *[L-ISIS/14] 1d 23:15:16, metric 30 to table inet.0
> to 1.1.1.14 via ge-0/0/1.0, Swap 6109 0(S=0) *[MPLS/0] 3d 11:49:26, metric 1
to 1.1.1.18 via ge-0/0/2.0, Swap 6109 to table mpls.0
to 1.1.1.22 via ge-0/0/3.0, Swap 5109
root@R9>
root@R4>

BGP-Prefix SID
A BGP-Prefix Segment is a BGP prefix with a Prefix-SID attached. A BGP Prefix-SID is always a global SID within the SR domain
and identifies an instruction to forward the packet over the Equal-Cost Multi-Path (ECMP) best-path computed by BGP to the
related prefix. The BGP Prefix-SID is the identifier of the BGP prefix segment. You can view the specification on BGP-Prefix SID
at https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-27.
A new BGP attribute known as the BGP Prefix-SID attribute is introduced and some rules defined to originate, receive and handle
error conditions for the attribute (Please see draft for further info on error conditions). The BGP Prefix-SID attribute can be
attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast. One known use-case is the applicability of BGP Prefix-
SID in large-scale data centers. A BGP Prefix-SID will be global across ASes when the interconnected ASes are part of the same
SR domain. Alternatively, when interconnecting ASes, the ASBRs of each domain will have to handle the advertisement of unique
SIDs.
A BGP Prefix-SID can be attached to a BGP prefix and this implies that each prefix is advertised individually, reducing the ability
to pack BGP advertisements. BGP Prefix-SID is mostly used in large scale data centers (DC) having close archetecture where
normally all routers within a Tier, are connected via EBGP to other Tier routers. and normally Tier 3 or top of rack (TOR) will
have individual AS per node, Tier 2 nodes can be grouped to multiple ASes and all Tier 1 nodes will be in a single AS.
This network design provides means for moving traffic between hosts with reasonable efficiency since there all servers are same
number of hops away and there are multiple ECMP paths to interconnect them. Each node advertises its loopback interface via
BGP to its neighbors. BGP Prefix SID would be supported from 19.4 onwards.

BGP-Prefix SID Attribute
The BGP Prefix-SID attribute is an optional, transitive BGP path attribute. The attribute type code 40 has been assigned by IANA.
The BGP Prefix-SID attribute is defined here to be a set of elements encoded as a set of TLVs. All BGP Prefix-SID attribute TLVs
will start with a 1-octet type and a 2-octet length. The following TLVs are defined in the draft:
1. Label-Index TLV
2. Originator SRGB TLV
The Label-Index and Originator SRGB TLVs are used only when SR is applied to the MPLS dataplane. In Junos, by default
“advertise-srgb” knob will be disabled and SRGB range will not be sent. Only if this knob is enabled the SRGB TLV will be
sent along with prefix SID TLV.
For future extensibility, unknown TLVs MUST be ignored and propagated unmodified. Definitions of the TLVs are on next slides.
A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered as "invalid" by the receiving speaker.
Please see “https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-27#section-7” for more details.

BGP-Prefix SID Attribute Cont…
1. Label-Index TLV: The Label-Index TLV MUST be present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled
Unicast prefixes. It MUST be ignored when received for other BGP AFI/SAFI combinations. The Label-Index TLV has the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Label Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Type is 1; Length: is 7, the total length in octets of the value portion of the TLV.
RESERVED: 8-bit field. MUST be clear on transmission and MUST be ignored on reception.
Flags: 16 bits of flags. None are defined as of now. The flag field MUST be clear on transmission and MUST be ignored on
reception.
Label Index: 32-bit value representing the index value in the SRGB space.

BGP-Prefix SID Attribute Cont…
2. Originator SRGB TLV: The Originator SRGB TLV is an optional TLV (advertised only when knob “advertise-srgb” is
configured) and has the following format:
0 1 2 3 Where:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | a. Type is 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+ b. Length is the total length in octets of the value portion of the TLV: 2 +
(non-zero multiple of 6).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRGB 1 (6 octets) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c. Flags: 16 bits of flags. None are defined as of now. Flags MUST be clear
| | on transmission and MUST be ignored on reception.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d. SRGB: 3 octets specifying the first label in the range followed by 3 octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRGB n (6 octets) | specifying the number of labels in the range. Note that the SRGB field
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAY appear multiple times. If the SRGB field appears multiple times,
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the SRGB consists of multiple ranges that are concatenated.
The Originator SRGB TLV contains the SRGB of the node originating the prefix to which the BGP Prefix-SID is attached. The
Originator SRGB TLV MUST NOT be changed during the propagation of the BGP update. It is used to build segment routing
policies when different SRGBs are used in the fabric, for example large scale datacenters.

BGP-Prefix SID - Example Diagram for understanding
Tier 1 R09 R10 AS300 R11 R12
Tier 2 R05 AS100 R06 R07 AS200 R08
R01 R02 R03 R04

Tier 3
AS10 AS20 AS30 AS40
Since R03 is originating router

of the prefix, the R07 and R08 Advertised Prefix
will do PHP (implicit-Null)
10.10.10.10/32
while sending traffic to this
Server A Server B prefix. Server Y Server Z
BGP-Prefix SID - Working explanation using Example Diagram
Consider a prefix ‘10.10.10.10/32’ in server Y is configured to have a Prefix Segment Index ‘10’ on router R03 who exports the
route into BGP. If all the routers are capable to support the processing of Prefix Segment Index and a common global segment
routing global block ‘1000’ is defined on all routers, then R03 will allocate a label which is derived as 1010 (1000+10) for
‘10.10.10.10/32’. Prefix Segment Index ‘10’ information will be propagated (in Label-Index TLV 0f BGP Prefix-SID attribute) to
upstream routers all the way to R01 and these routers will drive the same label 1010 to reach the prefix ‘10.10.10.10/32’. The
process of calculating the label in BGP Prefix SID is same as described in IGP Prefix SID section. Each router will store this in
forwarding table as follows:
Incoming label/IP destination Outgoing Label Outgoing interface
1010 1010 ECMP(OutIntf)

10.10.10.10/32 1010 ECMP(OutIntf)
Where OutIntf represents the outgoing interface to reach the destination. This may have multiple interfaces if there are
multiple ECMP paths to reach the destination.
Similarly, each router’s locally originated prefixes like the loopback addresses will also be assigned a unique Prefix Segment
Index say R01 allocate 1, R02 allocate 2 and Rx allocate ‘x’. The corresponding label will be created by adding this to ‘1000+x’.
Prefix Segment Index information is propagated (in Label-Index TLV 0f BGP Prefix-SID attribute) to all routers. All routers
will calculate the Prefix SIDs to reach the loopbacks of other routers and they would have the label entries and the
corresponding out label along with the outgoing interface to reach all other routers.
BGP-Prefix SID - Working explanation using Example Diagram Cont…
Now the controller can ask the application on the server to assign a stack of label to incoming packet based on the network state information
available to it and steer the packet through any path it deems best or necessary.
Say, if controller comes to know that the path via R10 and R07 is congested, it can insert a top label stack of 1009 or 1011 or 1012 {SRGB
1000 + (9 for R09, 11 for R11 and 12 for R12)} in the incoming packet of R1 for any new flows. This will ensure the path taken by that flow
will go through R09 or R11 or R12 and not R10 even if ECMP may say otherwise. As the packet reaches R09, the top label 1009 will be
popped and forwarded based on next label 1003 which would indicate path to reach the destination prefix.
One more use case requirement is to support redistribution of IGP assigned Prefix Segment Index into BGP. If the IGP has already allocated
a Prefix Segment Index and installed the route, then BGP just need to redistribute the prefix and send the prefix along with the Prefix
Segment Index information.
Note: JUNOS implementation supports capability to specify one or more global Prefix Segment SRGB blocks in protocol MPLS. This allows
configuration of a start and end value for the Prefix Segment SRGB block. The same capability will be reused by BGP to determine its range
of SRGB blocks. You can use the below commands to define the range in MPLS and use them in BGP.
set protocols mpls label-range srgb-label-range <range-start> <range-end>

set protocols bgp group <Group-Name> advertise-srbg <<< Currently this will be applicable only for labeled-unicast address family.
set protocols bgp source-packet-routing srgb start-label <start-label> index-range <index-range>
This SRGB range within BGP will be the first preference for BGP LU SID allocation and only if not specifically configured under BGP or if
there is a conflict with existing SRBG ranges configured globally or inside other protocols, then the globally allocated SRGB range will be
used.
BGP-Prefix SID - Configuration
policy-options {
policy-statement <Policy-Name> {
term 1 {
from {
route-filter <IP_Address> exact; <<< Since the SID is allocated per prefix, the from clause will have restriction to use only route-filter with exact match
}
then {
prefix-segment index <Prefix_Segment_Index>; <<< Index needs to be within the SRGB range. Just Like IGP Prefix SID.
accept;
}
} Note: Typically, a prefix needs to be assigned a prefix segment index on the device on which the prefix has been
term 2 { originated (i.e. a local/direct route has been exported in BGP using an export-policy). On upstream routers where this
from { prefix is re-advertised this need not be re-assigned again. The prefix segment index value assigned by the originating
protocol <IGP_Protocol>; device shall be retained in the re-advertisements. However, if ever needed the operator may choose to re-assign a
} different prefix segment index with the same prefix on an upstream router using an appropriate export policy term.
then {
prefix-segment reuse-allocated-sid; <<< This knob will be used to get the IGP allocated SID into BGP along with the prefix being exported to BGP.
accept; However the reverse that is from BGP to IGP will not be applicable.
}
}
}
}
protocols {
bgp {
group <Group-Name> {
advertise-prefix-sid; <<< For external BGP peers, by default the prefix SID is not advertised. A new knob “advertise-prefix-sid” is introduced in order to
export <Policy-Name>; override this default behavior and advertise prefix SID to eBGP peers.
}
}
}

BGP-Prefix SID - Use Case Descriptions
eBGP: For general use case descriptions, eBGP is assumed to be used for BGP connections wherein each router will be in a
separate AS.
RFC 8277 mentions that if the nexthop is unchanged, then the label should also remain unchanged. If the nexthop is changed,
then the label must be assigned at the new nexthop. The same will be hold good in case of propagation of prefix-sid.
In JUNOS by default the nexthop is changed at each hop to self for labeled unicast NLRI, unless specified to keep the nexthop
unchanged.
iBGP: The operation would be like the described in above, the only difference being eBGP path propagation replaced by iBGP
path reflection with nexthop set to self.
If the nexthop is not changed on RR, then there should be no change in label propagated as per RFC8277. In this case Upstream
router will not act on the prefix-sid attribute, rather propagate the label and nexthop unchanged to its upstream router.

Anycast SID
Anycast segments represent a shared prefix across nodes that could be used for simple, stateless load-sharing and redundancy.
Anycast SID is also a type of prefix SID. One application of Prefix SIDs is to achieve anycast operation. You can ascribe the same
IP address, and associated Anycast-SID, to multiple nodes. If in the data plane a packet arrives at a node with the anycast label on
top, the node forwards the packet towards the nearest member of the group. Like Prefix and Node SID, Anycast-SID also carried
in Prefix-SID (3) sub-TLV of Extended IP Reachability (135) TLV.
Anycast segments represent a shared prefix across nodes that could be used for simple load-sharing and redundancy.
Note:
• Anycast prefix-sids are also generated when a prefix is re-advertised across levels.
• R-bit is set to indicate re-advertised.
• When R-bit is set, N-bit is ignored.

Anycast SID Config
Anycast Config of R3 Anycast Config of R4
interfaces { interfaces {
lo0 { lo0 {
unit 0 { unit 0 {
family inet { family inet {
address 192.168.1.3/32; address 192.168.1.4/32;
address 192.168.1.101/32; address 192.168.1.101/32;
} }
} }
} }
} }
isis { isis {
export ISIS-Export; export ISIS-Export;
} }
} }
policy-options { policy-options {
policy-statement ISIS-Export { policy-statement ISIS-Export {
term Anycast { term Anycast {
from { from {
protocol direct; protocol direct;
interface lo0.0; interface lo0.0;
route-filter 192.168.1.101/32 exact; route-filter 192.168.1.101/32 exact;
} }
then { then {
prefix-segment index 499; prefix-segment index 499;
accept; accept;
} }
} }
} }
} }

Anycast SID Cont…
. . .
R3.00-00 Sequence: 0xa9a, Checksum: 0xefe3, Lifetime: 794 secs
IPV4 Index: 103
R9 has two ECMP paths to this anycast SID. One path is
Node Segment Blocks Advertised: through R7 and the other path is through R8.
Start Index : 0, Size : 1000, Label-Range: [ 3000, 3999 ]
. . .
TLVs: root@R9> show route label 9499 table mpls.0
. . . mpls.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
IP extended prefix: 192.168.1.101/32 metric 0 up + = Active Route, - = Last Active, * = Both
8 bytes of subtlvs
Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 499 9499 *[L-ISIS/14] 03:46:22, metric 30
IP address: 192.168.1.101 > to 1.1.1.37 via ge-0/0/0.0, Swap 7499
. . . to 1.1.1.41 via ge-0/0/1.0, Swap 8499
root@R3>
root@R9> traceroute 192.168.1.101 no-resolve
root@R4> show isis database R4.00-00 extensive traceroute to 192.168.1.101 (192.168.1.101), 30 hops max, 52 byte packets
. . . 1 1.1.1.37 5.149 ms 7.593 ms 3.724 ms
R4.00-00 Sequence: 0xa99, Checksum: 0x8f45, Lifetime: 482 secs MPLS Label=7499 CoS=0 TTL=1 S=1
IPV4 Index: 104 2 1.1.1.25 28.463 ms 25.228 ms 6.538 ms
Node Segment Blocks Advertised: MPLS Label=5499 CoS=0 TTL=1 S=1
Start Index : 0, Size : 1000, Label-Range: [ 4000, 4999 ] 3 192.168.1.101 8.616 ms 5.791 ms 5.560 ms
. . .
TLVs: root@R9>
. . .
IP extended prefix: 192.168.1.101/32 metric 0 up root@R5> show route label 5499 table mpls.0
8 bytes of subtlvs
Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 499 mpls.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden)
IP address: 192.168.1.101 + = Active Route, - = Last Active, * = Both
. . .
root@R4> 5499 *[L-ISIS/14] 03:49:55, metric 10
> to 1.1.1.21 via ge-0/0/3.0, Pop
5499(S=0) *[L-ISIS/14] 00:10:29, metric 10
> to 1.1.1.21 via ge-0/0/3.0, Pop <<< Going to R4
root@R5>
Anycast SID - Traffic engineering with anycast prefix segments
11
21
1.1.1.1/32 13 1.1.1.2/32
23
12
22
14
24
51 53
31 33
99
88
41 43
1.1.1.4/32 52 54
32 34
1.1.1.5/32
42 44
1.1.1.3/32
• Shortest paths from 88 to 99 is 4X ECMP southern route (using node-sid for 99)
• Traffic engineered 8X ECMP northern route can be achieved with two label stack: Anycast prefix-sid advertised by 21,22,23, and 24, plus node-sid for 99
• Equivalent traffic engineering using RSVP-TE requires 8 separate LSPs with state on each router for each LSP.
Binding SID
Binding SID is similar to an adjacency SID but instead of representing a link it represents a tunnel (SR/LDP/RSVP or any other
encapsulation) or in other words, stack of labels. In order to provide greater scalability, network opacity, and service
independence, SR utilizes a Binding SID (BSID). Normally BSID is bound to an SR Policy, instantiation of which may involve a
list of SIDs. Any packets received with an active segment equal to BSID are steered onto the bound SR Policy.
A BSID may be either a local or a global SID. If local, a BSID SHOULD be allocated from the SRLB. If global, a BSID MUST be
allocated from the SRGB.
The use of Binding SID is to stitch or nest various domains. It has local significance to the ingress node of the corresponding SID.
To implement interoperability of segment routing with LDP using ISIS, a server-client configuration is required under protocols
ISIS and LDP, respectively, and routes from the inet.3 or inet.0 routing tables are used for stitching of segment routing LSP
with an LDP LSP and vice-versa.
20
30 30
Binding SID in the packet 1000 40 40 40
Label from other protocol 2000 2000 2000 2000 2000
Pay Load Pay Load Pay Load Pay Load Pay Load Pay Load
100 200 300 400 500

10 80 20 70 30 60 40 50
BSID: 1000 representing a tunnel having label stack of 10 (Top), 20, 30, 40 (Bottom)
Note: Label Stack can be formed using Node SIDs or mix of Node and any other SID.
Binding SID Cont…
Anycast-SID carried in SID/Label (3) sub-TLV of SID/Label Binding (149) TLV. Below is the format of the TLV:
Where:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Type: TBD, suggested value 149
| Type | Length | Flags | Weight | • Length: variable.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • 1 octet of flags
| Range | Prefix Length | FEC Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • 1 octet of RESERVED
// FEC Prefix (continued, variable) // • 2 octets of Range, Please see the draft for more details. Default is 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • 1 octet of Prefix Length
| SubTLVs (variable) | • 0-16 octets of Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• sub-TLVs, where each sub-TLV consists of a sequence of:
Flags: Explanation is on next page. • 1 octet of sub-TLV type

• 1 octet of length of the value field of the sub-TLV
0 1 2 3 4 5 6 7 • 0-243 octets of value. The SID/Label sub-TLV contains a SID or
+-+-+-+-+-+-+-+-+
a MPLS Label.
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-22
Algorithm: Juniper supports SPF.
The 'Range' field provides the ability to specify a range of addresses and their associated Prefix SIDs. Default is one.
Weight: 1 octet. The value represents the weight of the SID for the purpose of load balancing.
Binding SID Cont…
F-Flag: Address Family flag. If unset, then the Prefix carries an IPv4 Prefix. If set, then the Prefix carries an IPv6 Prefix.
M-Flag: Mirror Context flag. Set if the advertised SID corresponds to a mirrored context. Mirroring allows an SR router to
advertise a backup path for a service (edge) segment, allowing for local (next-hop) repair using context-based switching. See RFC
8402 for more details.
S-Flag: Set Flag. If set, the SID/Label Binding TLV SHOULD be flooded across the entire routing domain. If the S flag is not set,
the SID/ Label Binding TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
D-Flag: When the SID/Label Binding TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be
clear. SID/Label Binding TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping
across levels.
A-Flag: Attached flag. The originator of the SID/Label Binding TLV MAY set the A bit in order to signal that the prefixes and
SIDs advertised in the SID/Label Binding TLV are directly connected to their originators. If the Binding TLV is leaked to other
areas/levels the A-flag MUST be cleared.
Other bits: MUST be zero when originated and ignored when received.

Binding SID - Segment Routing and LDP interworking
SR requires all routers to be reachable by a SID. Today due to migration, some of the router might be running only SR and some
of them might be running only LDP. To have end to end connectivity, we need interworking between SR and LDP. This is
achieved using Mapping server and mapping clients in the network.
Mapping Server: The SR mapping server is just a control plane function. It advertises prefix SIDs on behalf of the non-SR-
capable routers. This results in additional IS-IS TLVs that SR speakers will consume, and non-speakers ignore. SR routers will
install prefix SIDs learned from mapping servers, much as they install native prefix SIDs, into inet.3.
Like all proxies, the Mapping Server must be highly available, and its disseminated information must remain consistent – high
availability is achieved by configuring more than one router as Mapping Server. Complex tie-breaking rules exist if mapping
inconsistencies occur. Each Mapping Server mapping carries a preference. Mappings from the Mapping Server with the highest
preference are selected. If multiple Mapping Servers have equal preference but advertise conflicting information, SR label
collision rules come into effect. See “https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05” for more details.
Mapping Client: For a mapping server to hold any sway, there must exist a mapping client. Different from most protocols, SR
mapping clients and servers don’t form a distinct control plane relationship with each other. Instead, clients simply use the
advertised mappings. A Mapping Server can simultaneously be both a server, as well as a client. Routers bordering both domains
are responsible for stitching the segments routed with LDP. The border router speaks both SR and LDP; on receiving a mapping,
it creates a label swap entry for an incoming node SID to be switched with the LDP learned entry for the same FEC in the mpls.0
table.

Binding SID - Segment Routing and LDP interworking Cont…
Mapping Server Functionality:
• Enable SR-capable nodes to interwork with (non-SR capable) LDP nodes. A Mapping Server is required for SR/LDP
interworking.
• Mapping server advertises Prefix-to-SID mappings in IGP on behalf of other non-SR-capable nodes. Prefix-to-SID mappings
are configured on the Mapping Server.
• Remember that any SR-capable router can act as a Segment routing mapping server (SRMS) – its topological placement is
irrelevant. Position of mapping server is comparable to a BGP Route reflector. Mapping server is a control plane mechanism
and it doesn’t have to be in the data path.
Mapping Client Functionality:
• Receive and parse Prefix-to-SID mappings from Mapping Server(s).
• Use remotely learnt and locally configured mapping entries to construct a valid and consistent Active SID Mapping policy.
• IGP instance uses the Active SID Mapping policy to (re-)calculate the prefix-SID of some or all prefixes.

Binding SID - Segment Routing and LDP interworking Cont…
I used slightly modified topology for the Binding SID given on next page. Below is the Relevent configuration of mapping server
on R1 and Mapping client on R6.
Mapping Server Config (R1): Mapping Client Config (R6):
routing-options { protocols {
source-packet-routing { isis {
mapping-server-entry mapserver { source-packet-routing {
prefix-segment 192.168.1.8/32 index 108; ldp-stitching;
prefix-segment 192.168.1.9/32 index 109; }
} }
} ldp {
} sr-mapping-client;
protocols { }
isis { }
source-packet-routing {
mapping-server mapserver;
}
}
}
Note: Segment routing can also use RSVP tunnels to stretch over. The following configuration
enables L-ISIS to use the RSVP-LSP as shortcuts. We will have one example of SR-RSVP
interworking in SR OAM section.
set protocols isis traffic-engineering family inet-mpls shortcuts

R3 - lo0.0-
192.168.1.3/32
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
Northstar
JVM
192.168.1.10 em2
AS200 172.16.18.199/24
eth2 ge-0/0/9 ge-0/0/4 ge-0/0/4

172.16.18.1/24 172.16.18.11/24 1.1.1.45/3 1.1.1.49/30
R1 - lo0.0- ge-0/0/0 ge-0/0/0 R4-RR - lo0.0- ge-0/0/1 ge-0/0/1 R6 - lo0.0- ge-0/0/0 ge-0/0/0
Northstar 192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 R8 - lo0.0-
PCS SL: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 192.168.1.8/32
Index: 101 Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106
ge-0/0/1 ge-0/0/1
1.1.1.5/30 1.1.1.41/30
Mapping Server Mapping Client

R8’s Index: 108
R8’s Index: 109
Segment Routing LDP

AS100 AS100
ge-0/0/1 ge-0/0/1
1.1.1.6/30 1.1.1.42/30
R2 - lo0.0-
192.168.1.2/32 R9 - lo0.0-
SL: 2000 192.168.1.9/32
Index: 102

Binding SID - Segment Routing and LDP interworking Verification
First let's enable Mapping Client on R6, It will allocate LDP labels corresponding to the node SIDs of R1, R2, R3, and R4. It
advertises them to its LDP neighbors (R8 in the example network). R6 is doing label swap, Swapping the LDP label 32 with
root@R6> show ldp database
Node-SID associated with R2.
Input label database, 192.168.1.6:0--192.168.1.8:0
Labels received: 9 root@R6> show route label 32 table mpls.0
Label Prefix
57 10.10.10.1/32 mpls.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden)
55 192.168.1.1/32 + = Active Route, - = Last Active, * = Both
56 192.168.1.2/32
48 192.168.1.3/32 32 *[LDP/9] 00:02:48, metric 1
49 192.168.1.4/32 > to 1.1.1.13 via ge-0/0/1.0, Swap 4102
45 192.168.1.6/32 to 1.1.1.17 via ge-0/0/2.0, Swap 4102
3 192.168.1.8/32 to 1.1.1.50 via ge-0/0/3.0, Swap 3102
44 192.168.1.9/32
50 192.168.1.101/32 root@R6>
Output label database, 192.168.1.6:0--192.168.1.8:0

Labels advertised: 9
Label Prefix R8 and R9 now have label bindings for SR speakers.
33 10.10.10.1/32
31 192.168.1.1/32
root@R9> show ldp database | match "Input label|192.168.1.2"
32 192.168.1.2/32 <<< Lets have R2’s binding for our example
Input label database, 192.168.1.9:0--192.168.1.8:0
17 192.168.1.3/32
56 192.168.1.2/32
21 192.168.1.4/32
. . .
3 192.168.1.6/32
23 192.168.1.8/32
25 192.168.1.9/32
18 192.168.1.101/32
root@R6>
192.168.1.2/32 *[LDP/9] 00:03:42, metric 1
> to 1.1.1.41 via ge-0/0/1.0, Push 56
root@R9>
Till now SR speakers (R1, R2, R3 and R4) Does not have label bindings for the LDP speaker routers.
root@R2>
We need to enable mapping server on any of the SR speaker to have those bindings. In our lab we have enabled it on R1. Once we
enable mapping server on R1 we can see the bindings on SR speakers.
root@R2> show route 192.168.1.8 table inet.3 Node SID information for LDP Speakers is originated by mapping
inet.3: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden) server (R1).
192.168.1.8/32 *[L-ISIS/14] 00:12:00, metric 40 root@R2> show isis database R1.00-00 extensive
> to 1.1.1.5 via ge-0/0/1.0, Push 1108 . . .
R1.00-00 Sequence: 0x2b58, Checksum: 0x966c, Lifetime: 1144 secs
root@R2> show route 192.168.1.9 table inet.3 . . .
TLVs:
inet.3: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden) . . .
+ = Active Route, - = Last Active, * = Both Label binding: 192.168.1.8/32, Flags: 0x00(F:0,M:0,S:0,D:0,A:0), Range 1
Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 108
192.168.1.9/32 *[L-ISIS/14] 00:12:03, metric 50 Label binding: 192.168.1.9/32, Flags: 0x00(F:0,M:0,S:0,D:0,A:0), Range 1
> to 1.1.1.5 via ge-0/0/1.0, Push 1108 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 109
. . .
root@R2> root@R2>

But till now R6 hasn’t install entries in the mpls.0 table to stitch incoming SR labels corresponding to LDP Speakers to the
corresponding LDP label values.
Final Verification: Traceroute from R2  R9 and R9  R2.
root@R6> show route label 6108 table mpls.0
root@R2> traceroute 192.168.1.9
root@R6> 1 1.1.1.5 (1.1.1.5) 6.535 ms 0.974 ms 0.611 ms
MPLS Label=1109 CoS=0 TTL=1 S=1
2 1.1.1.2 (1.1.1.2) 2.630 ms 2.839 ms 2.071 ms
Once we enable “source-packet-routing ldp-stitching” MPLS Label=4109 CoS=0 TTL=1 S=1
3 1.1.1.14 (1.1.1.14) 0.867 ms 3.065 ms 0.801 ms
knob on mapping client, The mappings gets installed on R6. MPLS Label=6109 CoS=0 TTL=1 S=1
4 1.1.1.30 (1.1.1.30) 0.862 ms 0.866 ms 0.650 ms
root@R6> show route label 6108 table mpls.0 5 192.168.1.9 (192.168.1.9) 0.817 ms 1.003 ms 0.687 ms
mpls.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden) root@R2>

6108 *[L-ISIS/14] 00:23:55, metric 10 <<< 6108 is a Binding SID traceroute to 192.168.1.2 (192.168.1.2), 30 hops max, 40 byte packets
> to 1.1.1.30 via ge-0/0/0.0, Pop Representing LDP Labels 1 1.1.1.41 (1.1.1.41) 1.328 ms 0.680 ms 0.579 ms
6108(S=0) *[L-ISIS/14] 00:09:16, metric 10 MPLS Label=56 CoS=0 TTL=1 S=1
> to 1.1.1.30 via ge-0/0/0.0, Pop 2 1.1.1.29 (1.1.1.29) 0.831 ms 0.874 ms 0.688 ms
root@R6> show route label 6109 table mpls.0 3 1.1.1.13 (1.1.1.13) 0.866 ms 0.784 ms 0.718 ms
mpls.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden) 4 one.one.one.one (1.1.1.1) 2.043 ms 2.453 ms 2.438 ms
+ = Active Route, - = Last Active, * = Both MPLS Label=1102 CoS=0 TTL=1 S=1
5 192.168.1.2 (192.168.1.2) 0.870 ms 1.066 ms 0.681 ms
6109 *[L-ISIS/14] 00:23:59, metric 20 <<< 6109 is a Binding SID
> to 1.1.1.30 via ge-0/0/0.0, Swap 44 Representing LDP Labels root@R9>
root@R6>
PeerNode SID, PeerAdj SID, PeerSet SID (BGP Peering SIDs)
These SIDs are used in SR-based Egress Peer Engineering.
The SR-based Egress Peer Engineering (EPE) solution allows a centralized (SDN) controller to program any egress peer policy at
ingress border routers or at hosts within the domain. This can override network-derived best-path with a controlled-derived path.
Let's say a router X is connected with n no of EBGP peers (may be located in different ASes) and router X is also connected to a
controller. The EPE information essentially are the SID labels that would be advertised by router X in BGP-LS updates to
controller. These SID labels are only local significance to router X and its EBGP peers are not even aware of those labels.
A BGP EPE enabled Egress PE node MAY advertise SIDs corresponding to its attached peers. These SIDs are called BGP peering
segments or BGP Peering SIDs. In case of EBGP, they enable the expression of source routed inter-domain paths.
An ingress border router of an AS may compose a list of SIDs to steer a flow along a selected path within the AS, towards a
selected egress border router of the AS, and to a specific EBGP peer.
At minimum, a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node SID of the chosen egress PE and then the
BGP Peering SID for the chosen egress PE peer or peering interface.
Each BGP session MUST be described by a Peer Node SID. The description of the BGP session MAY be augmented by additional
Peer Adjacency SIDs. Finally, multiple Peer Node SIDs or Peer Adjacency SIDs MAY be part of the same group/set in order to
group EPE resources under a common Peer-Set SID.
PeerNode SID, PeerAdj SID, PeerSet SID (BGP Peering SIDs) Cont…
EBGP allocates those SID labels and programs the forwarding place to steer traffic based on incoming label in the packet. router
X will pop the label and forward the packet appropriately. Below is the explanation of these SIDs
• PeerAdj SID: A Peer Adjacency Segment is a segment describing a link that connects a BGP EPE peer and it is relevant only
for multi-hop E-BGP peer when it can be reached via multiple links. Note that the link can be P2P or a LAN. The label
assigned to PeerAdj SID can be used by ingress router to steer traffic to a specific link. PeerAdj SD is relevant only for multi-
hop E-BGP peers. Thus, for single hop E-BGP peers there is one to one mapping for peer and link, so PeerAdj SID is not
needed.
• PeerNode SID: A Peer Node Segment is a segment describing a BGP EPE peer or we can say that it is used to describe BGP-
LS-EPE session. The label assigned to PeerNode SID can be used by ingress router to steer traffic to a specific peer. PeerNode
SID MUST be present for both single-hop and multi-hop E-BGP peers.
• PeerSet SID: A Peer Set Segment is a segment describing a link or a node or a combination of both that is part of the set.
This can be seen as a mechanism to create group of PeerNode SID and PeerAdj SID. The label assigned to PeerAdj SID can be
used by ingress router to steer traffic to any member in the group. Each of the Peer-Node-SID Peer-Adj-SID MAY use the
same PeerSet SID. The packet can be sent to any member in the set and hence in the forwarding plane it would be represented
as ECMP next-hops.
In case of EBGP, these enable the expression of source-routed inter-domain paths.

ASBR B
0
10
=
S ID
de PeerSet SID = 600
N o
IP er
200 Pe IP
ASBR C
PeerNode SID = 200
ASBR A
Pee rAdj S
Pee ode SI = 500
Pee
rN
rAd
j SI
D = 00
D=
ID
400
3
ASBR D

The following BGP Peering SIDs need to be instantiated on a BGP router for each of its BGP peer sessions that
are enabled for EPE:
• One or more Peer-Adj-SID MAY be instantiated corresponding to the underlying link(s) to the directly
connected BGP peer session.
• One Peer-Node-SID MUST be instantiated to describe the BGP peer session. Each EPE BGP session
MUST be described by a Peer Node SID because it describes the BGP peer configured to do egress traffic
engineering.
• A Peer-Set-SID MAY be instantiated and additionally associated and shared between one or more Peer-
Node-SIDs or Peer-Adj-SIDs.
A BGP router SHOULD NOT instantiate a BGP Peering SID for those sessions to peer nodes which are not in
the forwarding path since the purpose of BGP Peering SID is to steer traffic to that specific peers.

PeerNode SID, PeerAdj SID and PeerSet SID are part of the BGP-LS Link attributes in the BGP update message. BGP-LS Link
attributes is advertised with the BGP-LS NLRI in the update message. Please visit “
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19” for more info. Peer-Node-SID, Peer-Adj-SID, and Peer-
Set-SID all have same format defined below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Flags: 1 octet field of flags(on next slide):
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7
| Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V|L|B|P| Rsvd |
| SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Code Point (Type) Description Length
1101 Peer Node Segment Identifier (Peer-Node-SID) Variable
1102 Peer Adjacency Segment Identifier (Peer-Adj-SID) Variable
1103 Peer Set Segment Identifier (Peer-Set-SID) Variable

V-Flag: Value flag. If set, then the SID carries a label value. By default the flag is SET.
L-Flag: Local Flag. If set, then the value/index carried by the SID has local significance. By default the flag is SET.
B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection.
P-Flag: Persistent Flag: If set, the SID is persistently allocated, i.e., As per the draft, the SID value should remain consistent
across router restart and session/interface flap.
Rsvd bits: Reserved for future use and MUST be zero when originated and ignored when received.
Weight: 1 octet. The value represents the weight of the SID for the purpose of load balancing. The default value is 0.
SID/Index/Label: According to the TLV length and to the V and L flags settings, it contains either:
• A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V and L flags MUST be
SET.
• A 4 octet index defining the offset in the SRGB (Segment Routing Global Block) as defined in RFC 8402 advertised by this
router.

BGP-LS NLRI for BGP: Protocol-ID : BGP codepoint 7 - The use of a new Protocol-ID allows separation
and differentiation between the BGP-LS NLRI carrying BGP information from the
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NLRI carrying IGP link-state information.
+-+-+-+-+-+-+-+-+
| Protocol-ID | Identifier: Default Layer 3 Routing topology set to 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) | Note: Below is the links for further reading…
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors // https://tools.ietf.org/html/rfc7752
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10
// Remote Node Descriptors //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19
// Link Descriptors //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We have used the topology on the next page to show BGP SIDs.
Local Node Descriptors (256) TLV: Local Node Descriptors TLV contains Node Descriptors for the node anchoring the local end of the link. Local
Node Descriptors TLV has Two sub-TLVs: a. Autonomous system (512) sub-TLV containing the local end AS no and b. BGP Router-ID (516) sub-TLV
containing local router’s router ID.
Remote Node Descriptors (257) TLV: Remote Node Descriptors TLV contains Node Descriptors for the node anchoring the remote end of the link.
Remote Node Descriptors TLV has Two sub-TLVs: a. Autonomous system (512) sub-TLV containing the remote end AS no and b. BGP Router-ID (516)
sub-TLV containing remote EBGP peer router ID.
Link Descriptors TLV: The Link Descriptor TLVs uniquely identify a link among multiple parallel links between a pair of anchor routers. Link
Descriptors TLV has Two sub-TLVs: a. IPv4 interface address (259) sub-TLV containing the local end IP address and b. IPv4 neighbor address (260)
sub-TLV containing remote end IP address.
R3 - lo0.0-
CE7
192.168.1.3/32 Advertised Prefix
lo0.0 -
ge-0/0/0 SL: 3000 ge-0/0/1 101.101.101.1/30
192.168.2.7/32
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology ge-0/0/0
3.3.3.17/30
ge-0/0/1
3.3.3.21/30
EBG
P -LS
Northstar
AS 300
JVM
192.168.1.10 em2
AS200 172.16.18.199/24
Multihop EBGP
Peer Node SID
1010001
ge-0/0/4 ge-0/0/5
3.3.3.18/30 3.3.3.22/30 Peer Set SID
eth2 ge-0/0/9 ge-0/0/4 ge-0/0/4 Peer Adj SID Peer Adj SID 1010100
172.16.18.1/24 172.16.18.11/24 1.1.1.45/3 1.1.1.49/30 1010010 1010011 Configured on R8
R1 - lo0.0- ge-0/0/0 ge-0/0/0 R4-RR - lo0.0- ge-0/0/1 ge-0/0/1 R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0- ge-0/0/2 ge-0/0/0
CE4
Northstar 192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32 3.3.3.2/30 3.3.3.1/30
lo0.0 -
PCS SL: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 SL: 8000 Peer Node SID
192.168.2.4/32
Index: 101 Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106 Index: 108 1010002
ge-0/0/1 ge-0/0/3 ge-0/0/3 ge-0/0/1 ge-0/0/3 Advertised Prefix
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30 3.3.3.6/30 102.102.102.1/30
ge-0/0/5 ge-0/0/6 Peer Node SID
1.1.1.54/30 1.1.1.57/30 1010003
ge-0/0/0
CE5 - AS 400
Segment Routing 3.3.3.5/30
lo0.0 -
AS100
192.168.2.5/32
Advertised Prefix
103.103.103.1/30
ge-0/0/4 ge-0/0/4
1.1.1.53/30 1.1.1.58/30
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1
1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 192.168.1.5/32 192.168.1.7/32 192.168.1.9/32

BGP Peering SIDs Configuration on ASBR
Relevent Config on R8 (Acting as ASBR): . . .
egress-te-adj-segment R8-CE7-ge-0/0/5 { <<< PeerAdj SID
label 1010011;
protocols { next-hop 3.3.3.21;
bgp { egress-te-backup-segment { <<< FRR for AdjSID
egress-te-sid-stats; label 1010010;
egress-te-set-segment Peer-Set-CE7-CE4 { <<< PeerSet SID }
label 1010100; You can use the PeerSet SID for the PeerAdj SIDs as well }
} }
group Peer-AS300 { }
type external; group Peer-AS400 {
peer-as 300; type external;
neighbor 3.3.3.1 { peer-as 400;
local-address 3.3.3.2; neighbor 3.3.3.5 {
egress-te-node-segment { <<< PeerNode SID local-address 3.3.3.6;
label 1010002; egress-te-node-segment { <<< PeerNode SID
egress-te-set { label 1010003;
Peer-Set-CE7-CE4; }
weight 1; }
} }
} group Northstar-R8 {
} type external;
} local-address 192.168.1.8;
group Peer-AS300-Multihop { family inet {
type external; labeled-unicast;
peer-as 300; }
neighbor 192.168.2.7 { family traffic-engineering {
multihop; unicast;
local-address 192.168.1.8; }
egress-te-node-segment { <<< PeerNode SID export TE;
label 1010001; peer-as 200;
egress-te-set { neighbor 192.168.1.10 {
Peer-Set-CE7-CE4; multihop {
weight 2; ttl 10;
} }
} }
egress-te-adj-segment R8-CE7-ge-0/0/4 { <<< PeerAdj SID }
label 1010010; }
next-hop 3.3.3.17; }
egress-te-backup-segment {
label 1010011;
}
}
. . . Juniper Business Use Only
BGP Peering SIDs Verification
root@R8> show ted link topology-id bgp-ls-epe detail <<< Shows display BGP EPE information
192.168.1.8->192.168.2.4, Local: 3.3.3.2, Remote: 3.3.3.1
Local interface index: 0, Remote interface index: 0
Local bgp peer as: 100, Remote bgp peer as: 300
LocalPath: 0, AvailBW: 0bps
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
SID: 1010002 Type: Node-SID Flags: 0xc0 Weight: 1
SID: 1010100 Type: Set-SID Flags: 0xc0 Weight: 0
192.168.1.8->192.168.2.7, Local: 192.168.1.8, Remote: 192.168.2.7
SID: 1010010 Type: Adj-SID Flags: 0xc0 Weight: 0
192.168.1.8->192.168.2.7, Local: 192.168.1.8, Remote: 192.168.2.7
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps . . .
SID: 1010011 Type: Adj-SID Flags: 0xc0 Weight: 0 192.168.1.8->192.168.2.5, Local: 3.3.3.6, Remote: 3.3.3.5
192.168.1.8->192.168.2.7, Local: 192.168.1.8, Remote: 192.168.2.7 Local interface index: 0, Remote interface index: 0
Local interface index: 0, Remote interface index: 0 Local bgp peer as: 100, Remote bgp peer as: 400
Local bgp peer as: 100, Remote bgp peer as: 300 LocalPath: 0, AvailBW: 0bps
LocalPath: 0, AvailBW: 0bps localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps SID: 1010003 Type: Node-SID Flags: 0xc0 Weight: 0
SID: 1010001 Type: Node-SID Flags: 0xc0 Weight: 2
SID: 1010100 Type: Set-SID Flags: 0xc0 Weight: 0 root@R8>
. . .
BGP Peering SIDs Verification Cont…
. . .
root@R8> show ted database topology-id bgp-ls-epe extensive <<< Shows BGP EPE information To: 192.168.2.7, Local: 192.168.1.8, Remote: 192.168.2.7
NodeID: 192.168.2.4 Local interface index: 345, Remote interface index: 0
Type: Rtr, Age: 5139 secs, LinkIn: 1, LinkOut: 0 Local bgp peer as: 100, Remote bgp peer as: 300
Protocol: BGP-LS-EPE(0) Interface Switching Capability Descriptor(1):
NodeID: 192.168.2.5 Switching type: Packet
Type: Rtr, Age: 5134 secs, LinkIn: 1, LinkOut: 0 Encoding type: Packet
Protocol: BGP-LS-EPE(0) Maximum LSP BW [priority] bps:
NodeID: 192.168.2.7 [0] 0bps [1] 0bps [2] 0bps [3] 0bps
Type: Rtr, Age: 5137 secs, LinkIn: 3, LinkOut: 0 [4] 0bps [5] 0bps [6] 0bps [7] 0bps
Protocol: BGP-LS-EPE(0) BGP-Peer-SID:
NodeID: 192.168.1.8 SID: 1010011, Type: Adj-SID, Flags: 0xc0, Weight: 0
Type: Rtr, Age: 5139 secs, LinkIn: 0, LinkOut: 5 To: 192.168.2.7, Local: 192.168.1.8, Remote: 192.168.2.7
Protocol: BGP-LS-EPE(0) Local interface index: 0, Remote interface index: 0
To: 192.168.2.4, Local: 3.3.3.2, Remote: 3.3.3.1 Local bgp peer as: 100, Remote bgp peer as: 300
Local interface index: 0, Remote interface index: 0 Interface Switching Capability Descriptor(1):
Local bgp peer as: 100, Remote bgp peer as: 300 Switching type: Packet
Interface Switching Capability Descriptor(1): Encoding type: Packet
Switching type: Packet Maximum LSP BW [priority] bps:
Encoding type: Packet [0] 0bps [1] 0bps [2] 0bps [3] 0bps
Maximum LSP BW [priority] bps: [4] 0bps [5] 0bps [6] 0bps [7] 0bps
[0] 0bps [1] 0bps [2] 0bps [3] 0bps BGP-Peer-SID:
[4] 0bps [5] 0bps [6] 0bps [7] 0bps SID: 1010001, Type: Node-SID, Flags: 0xc0, Weight: 2
BGP-Peer-SID: SID: 1010100, Type: Set-SID, Flags: 0xc0, Weight: 0
SID: 1010002, Type: Node-SID, Flags: 0xc0, Weight: 1 To: 192.168.2.5, Local: 3.3.3.6, Remote: 3.3.3.5
SID: 1010100, Type: Set-SID, Flags: 0xc0, Weight: 0 Local interface index: 0, Remote interface index: 0
To: 192.168.2.7, Local: 192.168.1.8, Remote: 192.168.2.7 Local bgp peer as: 100, Remote bgp peer as: 400
Local interface index: 343, Remote interface index: 0 Interface Switching Capability Descriptor(1):
Local bgp peer as: 100, Remote bgp peer as: 300 Switching type: Packet
Interface Switching Capability Descriptor(1): Encoding type: Packet
Switching type: Packet Maximum LSP BW [priority] bps:
Encoding type: Packet [0] 0bps [1] 0bps [2] 0bps [3] 0bps
Maximum LSP BW [priority] bps: [4] 0bps [5] 0bps [6] 0bps [7] 0bps
[0] 0bps [1] 0bps [2] 0bps [3] 0bps BGP-Peer-SID:
[4] 0bps [5] 0bps [6] 0bps [7] 0bps SID: 1010003, Type: Node-SID, Flags: 0xc0, Weight: 0
BGP-Peer-SID:
SID: 1010010, Type: Adj-SID, Flags: 0xc0, Weight: 0 root@R8>
. 2018
© . . Juniper Networks 81
root@R8> show route table lsdist.0 advertising-protocol bgp 192.168.1.10 active-path te-link-local-node-ip 192.168.1.8 extensive
^^^ Gives same results "show route advertising-protocol bgp 192.168.1.10 protocol bgp-ls-epe extensive"
lsdist.0: 53 destinations, 53 routes (53 active, 0 holddown, 0 hidden)
* LINK { Local { AS:100 IPv4:192.168.1.8 }.{ IfIndex:343 } Remote { AS:300 IPv4:192.168.2.7 }.{ IfIndex:0 } BGP-LS-EPE:0 }/1216 (1 entry, 1 announced)
BGP group Northstar-R8 type External
Nexthop: Self
AS path: [100] I
Label: 1010010, Flags: 0xc0, Weight: 0 <<< PeerAdj SID associated with Router R8’s interface ge-0/0/4
Nexthop: Self
AS path: [100] I
* LINK { Local { AS:100 IPv4:192.168.1.8 }.{ IPv4:3.3.3.2 } Remote { AS:300 IPv4:192.168.2.4 }.{ IPv4:3.3.3.1 } BGP-LS-EPE:0 }/1216 (1 entry, 1 announced)
Nexthop: Self
AS path: [100] I
Label: 1010002, Flags: 0xc0, Weight: 1 <<< PeerNode SID associated with Router R8’s neighbor CE4. Configured Weight is 1
Label: 1010100, Flags: 0xc0, Weight: 0 <<< PeerSet SID associated with Router R8’s neighbors CE4 and CE7
Nexthop: Self
AS path: [100] I
Label: 1010003, Flags: 0xc0, Weight: 0 <<< PeerNode SID associated with Router R8’s neighbor CE5
Nexthop: Self
AS path: [100] I
root@R8>
root@R8> show route table lsdist.0 advertising-protocol bgp 192.168.1.10 active-path te-link-remote-node-ip 192.168.2.7 extensive

Nexthop: Self
AS path: [100] I
Nexthop: Self
AS path: [100] I
Nexthop: Self
AS path: [100] I
root@R8>

root@R8> show route table lsdist.0 advertising-protocol bgp 192.168.1.10 active-path te-link-local-ip 3.3.3.2 extensive

Nexthop: Self
AS path: [100] I
Label: 1010100, Flags: 0xc0, Weight: 0
root@R8> show route table lsdist.0 advertising-protocol bgp 192.168.1.10 active-path te-link-remote-ip 3.3.3.1 extensive

Nexthop: Self
AS path: [100] I
Label: 1010002, Flags: 0xc0, Weight: 1 <<< PeerNode SID associated with Router R8’s neighbor PCE4. Configured Weight is 1
root@R8> show route table lsdist.0 advertising-protocol bgp 192.168.1.10 active-path te-link-local-ip 3.3.3.6 extensive

Nexthop: Self
AS path: [100] I
root@R8> show route table lsdist.0 advertising-protocol bgp 192.168.1.10 active-path te-link-remote-ip 3.3.3.5 extensive

Nexthop: Self
AS path: [100] I
root@R8>

root@R8> show route label 1010001 root@R8> show route label 1010011
mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden) mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both + = Active Route, - = Last Active, * = Both
1010001 *[BGP-LS-EPE/170] 01:01:27, metric2 0, from 192.168.2.7, peer-as 300 1010011 *[BGP-LS-EPE/170] 02:11:54, from 3.3.3.21
> to 3.3.3.17 via ge-0/0/4.0, Pop > to 3.3.3.21 via ge-0/0/5.0, Pop
to 3.3.3.21 via ge-0/0/5.0, Pop to 3.3.3.17 via ge-0/0/4.0, Pop <<< Backup
root@R8> show route label 1010002 root@R8> show route label 1010100
1010002 *[BGP-LS-EPE/170] 02:11:42, peer-as 300 1010100 *[BGP-LS-EPE/170] 02:11:58, metric2 0

> to 3.3.3.1 via ge-0/0/2.0, Pop to 3.3.3.17 via ge-0/0/4.0, Pop
to 3.3.3.21 via ge-0/0/5.0, Pop
root@R8> show route label 1010003 > to 3.3.3.1 via ge-0/0/2.0, Pop
mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden) root@R8>

1010003 *[BGP-LS-EPE/170] 02:11:41, peer-as 400

> to 3.3.3.5 via ge-0/0/3.0, Pop

1010010 *[BGP-LS-EPE/170] 02:11:48, from 3.3.3.17

> to 3.3.3.17 via ge-0/0/4.0, Pop
to 3.3.3.21 via ge-0/0/5.0, Pop <<< Backup
root@R8>

root@R8> show route label 1010010 extensive root@R8> show route label 1010011 extensive
1010010 (1 entry, 1 announced) 1010011 (1 entry, 1 announced)
TSI: TSI:
KRT in-kernel 1010010/52 -> {list:Pop , Pop Flags acct} KRT in-kernel 1010011/52 -> {list:Pop , Pop Flags acct}
Stats ID Group: Kernel ID = 4, Stats IDs = { 268435461 } Stats ID Group: Kernel ID = 5, Stats IDs = { 268435462 }
*BGP-LS-EPE Preference: 170 *BGP-LS-EPE Preference: 170
. . . . . .
Source: 3.3.3.17 Source: 3.3.3.21
Next hop: ELNH Address 0xba27250 weight 0x1, selected Next hop: ELNH Address 0xba28ff0 weight 0x1, selected
. . . . . .
Next hop: 3.3.3.17 via ge-0/0/4.0 Next hop: 3.3.3.21 via ge-0/0/5.0
Label operation: Pop Label operation: Pop
. . . . . .
Next hop: ELNH Address 0xba29bf0 weight 0x4000 <<< Next hop: ELNH Address 0xba272b0 weight 0x4000 <<< Bac
Backup . . .
. . . Next hop: 3.3.3.17 via ge-0/0/4.0
Next hop: 3.3.3.21 via ge-0/0/5.0 Label operation: Pop
Label operation: Pop . . .
. . . root@R8>
root@R8>

PROVISIONING LSPS USING DIFFERENT SIDS

Provisioning LSP Using Adjacency SID

Provisioning LSP Using Adjacency SID Cont…

Provisioning LSP Using Adjacency SID: Verification on Router
root@R1> show spring-traffic-engineering overview root@R1> show isis adjacency extensive R4
Overview of SPRING-TE: R4
Route preference: 8 Interface: ge-0/0/0.0, Level: 2, State: Up, Expires in 25 secs
Number of LSPs: 1 (Up: 1, Down: 0) . . .
Number of LSPs with ldp-tunneling config: 0 IP addresses: 1.1.1.2
External controllers: Level 2 IPv4 Adj-SID: 29
pccd State: Up
. . .
root@R1> show spring-traffic-engineering lsp detail root@R1>
Name: R1_to_R9_Using_AdjSID
Tunnel-source: Path computation element protocol(PCEP) root@R4> show isis adjacency extensive R5
To: 192.168.1.9 R5
State: Up Interface: ge-0/0/3.0, Level: 2, State: Up, Expires in 25 secs
Outgoing interface: ge-0/0/0.0 . . .
Auto-translate status: Disabled Auto-translate result: N/A IP addresses: 1.1.1.22
BFD status: N/A BFD name: N/A Level 2 IPv4 Adj-SID: 17
SR-ERO hop count: 4 State: Up
Hop 1 (Strict): . . .
NAI: IPv4 Adjacency ID, 1.1.1.1 -> 1.1.1.2 root@R4>
Hop 2 (Strict): root@R5> show isis adjacency extensive R7
NAI: IPv4 Adjacency ID, 1.1.1.21 -> 1.1.1.22 R7
SID type: 20-bit label, Value: 17 Interface: ae0.0, Level: 2, State: Up, Expires in 19 secs
Hop 3 (Strict): . . .
NAI: IPv4 Adjacency ID, 1.1.1.25 -> 1.1.1.26 IP addresses: 1.1.1.26
SID type: 20-bit label, Value: 18 Level 2 IPv4 Adj-SID: 18
Hop 4 (Strict): State: Up
NAI: IPv4 Adjacency ID, 1.1.1.37 -> 1.1.1.38
SID type: 20-bit label, Value: 17 root@R5>
root@R7> show isis adjacency extensive R9
R9
Total displayed LSPs: 1 (Up: 1, Down: 0) Interface: ge-0/0/0.0, Level: 2, State: Up, Expires in 22 secs
. . .
root@R1> IP addresses: 1.1.1.38
Level 2 IPv4 Adj-SID: 17
State: Up
Provisioning LSP Using Adjacency SID: Verification on Router Cont…
root@R1> show path-computation-client status root@R1> show path-computation-client lsp extensive
General
Session Type Provisioning Status Uptime LSP Name : R1_to_R9_Using_AdjSID
Northstar-1 Stateful Active On Up 1234473 PathName : -
From : 192.168.1.1 To : 192.168.1.9 State : Up
LSP Summary Active Path : -
Total number of LSPs : 1 Link Protection none
Static LSPs : 0 LSP Type : ext-provised
Externally controlled LSPs : 0 P2mp tree : NULL
Externally provisioned LSPs : 1/16000 (current/limit) Path cspf status : external_cspf
Orphaned LSPs : 0 Template : NULL
PLSP-ID : 25
Northstar-1 (main) LSP-ID : 0
Delegated : 0 RSVP Error : 0x0
Externally provisioned : 1 Priorities : 0
Bandwidth : 0
root@R1> Requested AutoBw : 0
Controller : Northstar-1
Record Route : NULL
From PCE ERO (received) : NULL
From RPD ERO (reported) : NULL
Configured ERO on PCC : NULL
Last Rpt/Pcreqest received from RPD at : 03:18:42.000
Last Update sent to PCE at : 16:00:00.000
Last PcUpdate/PcCreate received from PCE at : 03:18:42.000
Last error sent to PCE at : 16:00:00.000
Last 5 reasons to send Report/Pcrequest : , , , ,
root@R1>

Provisioning LSP Using Node SID

Provisioning LSP Using Node SID Cont…

Provisioning LSP Using Node SID Cont…

Provisioning LSP Using Node SID: Verification on Router
root@R1> show spring-traffic-engineering overview root@R1> show route label 29
Overview of SPRING-TE:
Route preference: 8 mpls.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
Number of LSPs: 1 (Up: 1, Down: 0) + = Active Route, - = Last Active, * = Both
Number of LSPs with ldp-tunneling config: 0
External controllers: 29 *[L-ISIS/14] 1d 03:52:41, metric 0
pccd > to 1.1.1.2 via ge-0/0/0.0, Pop
29(S=0) *[L-ISIS/14] 00:11:46, metric 0
root@R1> show spring-traffic-engineering lsp detail > to 1.1.1.2 via ge-0/0/0.0, Pop
Name: R1_to_R9_Using_NodeSID
Tunnel-source: Path computation element protocol(PCEP) root@R1>
To: 192.168.1.9
State: Up root@R4> show route label 4109
Auto-translate status: Disabled Auto-translate result: mpls.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
N/A + = Active Route, - = Last Active, * = Both
SR-ERO hop count: 2 4109 *[L-ISIS/14] 2w0d 06:52:55, metric 30
Hop 1 (Strict): > to 1.1.1.14 via ge-0/0/1.0, Swap 6109
NAI: IPv4 Adjacency ID, 1.1.1.1 -> 1.1.1.2 to 1.1.1.18 via ge-0/0/2.0, Swap 6109
SID type: 20-bit label, Value: 29 to 1.1.1.22 via ge-0/0/3.0, Swap 5109
Hop 2 (Strict):
NAI: IPv4 Node ID, Node address: 192.168.1.9 root@R4>
root@R1>

Provisioning LSP Using Node SID: Verification on Router Cont…
General
Session Type Provisioning Status Uptime LSP Name : R1_to_R9_Using_NodeSID
From : 192.168.1.1 To : 192.168.1.9 State : Up
PLSP-ID : 24
Requested AutoBw : 0
root@R1> Controller : Northstar-1
Record Route : NULL
Intended
Bandwidth : 0
Metric : 0
Actual
Bandwidth : 0
Metric : 0
root@R1>

Provisioning LSP Using Prefix SID
Prefix SID config on R1:
interfaces {
ge-0/0/6 {
gigether-options {
loopback;
}
unit 0 {
family inet {
address 10.10.10.1/32;
}
}
}
}
policy-options {
policy-statement ISIS-Export {
term Prifix-SID {
from {
protocol direct;
route-filter 10.10.10.1/32 exact;
}
then {
prefix-segment index 599;
accept;
}
}
}
}
protocols {
isis {
export ISIS-Export;
}
}

Provisioning LSP Using Prefix SID Cont…
Prefix SID

Provisioning LSP Using Prefix SID Cont…
Note: Configured Prefix SID on interface ge-0/0/6

is getting resolved as Node SID of R1. Not sure
when this would be fixed. Currently we do not see
the prefix SID in the label stack, we see Node SID
of the router in the label stack. The expected label
stack would have been 25-6104-4599-1102
Provisioning LSP Using Prefix SID: Verification on Router
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
pccd 25 *[L-ISIS/14] 2w6d 11:31:37, metric 0
> to 1.1.1.29 via ge-0/0/0.0, Pop
root@R8> show spring-traffic-engineering lsp detail 25(S=0) *[L-ISIS/14] 00:07:03, metric 0
Name: R8_to_R2_Using_Prefix_SID > to 1.1.1.29 via ge-0/0/0.0, Pop
To: 192.168.1.2
State: Up
root@R8>
Auto-translate status: Disabled Auto-translate result: N/A root@R6> show route label 6104
SR-ERO hop count: 4 mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
Hop 1 (Strict): + = Active Route, - = Last Active, * = Both
6104 *[L-ISIS/14] 2w6d 10:04:40, metric 10
Hop 2 (Strict):
NAI: IPv4 Node ID, Node address: 192.168.1.4 to 1.1.1.13 via ge-0/0/1.0, Pop
SID type: 20-bit label, Value: 6104 > to 1.1.1.17 via ge-0/0/2.0, Pop
Hop 3 (Strict): 6104(S=0) *[L-ISIS/14] 00:02:28, metric 10
NAI: IPv4 Node ID, Node address: 192.168.1.1 to 1.1.1.13 via ge-0/0/1.0, Pop
SID type: 20-bit label, Value: 4101 > to 1.1.1.17 via ge-0/0/2.0, Pop
Hop 4 (Strict):
root@R6>
root@R8>

Provisioning LSP Using Prefix SID: Verification on Router Cont…

4101 *[L-ISIS/14] 2w6d 11:33:28, metric 10

> to 1.1.1.1 via ge-0/0/0.0, Pop
4101(S=0) *[L-ISIS/14] 00:12:25, metric 10
> to 1.1.1.1 via ge-0/0/0.0, Pop
root@R4>

1102 *[L-ISIS/14] 1w0d 08:36:15, metric 10

> to 1.1.1.6 via ge-0/0/1.0, Pop
1102(S=0) *[L-ISIS/14] 00:02:06, metric 10
> to 1.1.1.6 via ge-0/0/1.0, Pop
root@R1>

Provisioning LSP Using Prefix SID: Verification on Router Cont…
General
Session Type Provisioning Status Uptime LSP Name : R8_to_R2_Using_Prefix_SID
From : 192.168.1.8 To : 192.168.1.2 State : Up
PLSP-ID : 14
root@R8> Controller : Northstar-1
Record Route : NULL
Intended
Bandwidth : 0
Metric : 0
Actual
Bandwidth : 0
Metric : 0
root@R8>

Provisioning LSP Using Anycast SID
Not supported by Northstar as of now. Still in planning stage.

Provisioning LSP Using Binding SID
Note:
1. Currently Binding SID is supported,

with the following caveat:
you must have a binding SID LSP in

each direction, each with the same
name and they MUST NOT have
dash in them.
2. Binding SID via PCEP should be

supported from Junos 19.4 and
NorthStar 5.2. RLI 41718 is tracking
it and it should be released soon.
NorthStar creates a privateForwardingAdjacency from a pair of Binding Sid SR
LSPs of the same name from A->Z and Z->A. We want to create end to end LSP
from R2 to R9 which should use privateForwardingAdjacency. We need to
create privateForwardingAdjacency using Netconf from R1 toR8 and vice versa.
Once these privateForwardingAdjacency would be up then we can use it as a
hop in an LSP R2-to-R9.
Let’s create privateForwardingAdjacency from R1 toR8 and vice versa and then
© we
2018will
Juniper Networks
create end
to end LSP from R2 to R9. 104
Provisioning LSP Using Binding SID Cont…





privateForwardingAdjacency link should be up in the link tab

Let's create LSP R2-to-R9 that will
use this privateForwardingAdjacency.



Provisioning LSP Using Binding SID: Verification on Router
Provisioned privateForwardingAdjacency on R1 Provisioned privateForwardingAdjacency on R8
root@R1> show configuration protocols source-packet-routing root@R8> show configuration protocols source-packet-routing
lsp-external-controller pccd; lsp-external-controller pccd;
maximum-segment-list-depth 5; maximum-segment-list-depth 5;
segment-list R1_to_R8_Private_Forwarding_Adjacency { segment-list R1_to_R8_Private_Forwarding_Adjacency {
segment1 { segment1 {
label 29; label 25;
ip-address 1.1.1.2; ip-address 1.1.1.29;
} }
segment2 label 4106; segment2 label 6104;
segment3 label 6108; segment3 label 4101;
} }
source-routing-path R1_to_R8_Private_Forwarding_Adjacency { source-routing-path R1_to_R8_Private_Forwarding_Adjacency {
to 192.168.1.8; to 192.168.1.1;
binding-sid 1000001; binding-sid 1000001;
metric 1; metric 1;
primary { primary {
R1_to_R8_Private_Forwarding_Adjacency; R1_to_R8_Private_Forwarding_Adjacency;
} }
} }
root@R1> root@R8>

Provisioning LSP Using Binding SID: Verification on Router Cont…
Provisioned LSP on R2 using privateForwardingAdjacency on R1
root@R2> show configuration protocols source-packet-routing
lsp-external-controller pccd;
maximum-segment-list-depth 5;
segment-list R2_to_R9_Using_Binding_SID {
segment1 label 27;
segment2 label 1000001;
segment3 label 24;
}
source-routing-path R2_to_R9_Using_Binding_SID {
to 192.168.1.9;
metric 1;
primary {
R2_to_R9_Using_Binding_SID;
}
}
root@R2>

Provisioned privateForwardingAdjacency on R1 root@R1> show route label 29

Name: R1_to_R8_Private_Forwarding_Adjacency
29 *[L-ISIS/14] 1w0d 23:47:29, metric 0
Tunnel-source: Static configuration
> to 1.1.1.2 via ge-0/0/0.0, Pop
To: 192.168.1.8
29(S=0) *[L-ISIS/14] 00:13:48, metric 0
State: Up
> to 1.1.1.2 via ge-0/0/0.0, Pop
Path: R1_to_R8_Private_Forwarding_Adjacency
root@R1>
SR-ERO hop count: 3
Hop 1 (Strict):
Hop 2 (Strict):
4106 *[L-ISIS/14] 3w0d 02:45:51, metric 10
NAI: None
> to 1.1.1.14 via ge-0/0/1.0, Pop
to 1.1.1.18 via ge-0/0/2.0, Pop
Hop 3 (Strict):
4106(S=0) *[L-ISIS/14] 00:03:22, metric 10
NAI: None
> to 1.1.1.14 via ge-0/0/1.0, Pop
to 1.1.1.18 via ge-0/0/2.0, Pop
root@R4>
root@R1>
6108 *[L-ISIS/14] 3w0d 02:45:57, metric 10

> to 1.1.1.30 via ge-0/0/0.0, Pop
6108(S=0) *[L-ISIS/14] 00:10:31, metric 10
> to 1.1.1.30 via ge-0/0/0.0, Pop

Provisioned privateForwardingAdjacency on R8 root@R8> show route label 25

Name: R1_to_R8_Private_Forwarding_Adjacency
25 *[L-ISIS/14] 3w0d 02:53:24, metric 0
> to 1.1.1.29 via ge-0/0/0.0, Pop
To: 192.168.1.1
25(S=0) *[L-ISIS/14] 00:11:54, metric 0
State: Up
> to 1.1.1.29 via ge-0/0/0.0, Pop
Path: R1_to_R8_Private_Forwarding_Adjacency
root@R8>
SR-ERO hop count: 3
Hop 1 (Strict):
Hop 2 (Strict):
6104 *[L-ISIS/14] 3w0d 02:53:29, metric 10
NAI: None
to 1.1.1.13 via ge-0/0/1.0, Pop
> to 1.1.1.17 via ge-0/0/2.0, Pop
Hop 3 (Strict):
6104(S=0) *[L-ISIS/14] 00:06:31, metric 10
NAI: None
to 1.1.1.13 via ge-0/0/1.0, Pop
> to 1.1.1.17 via ge-0/0/2.0, Pop
root@R6>
root@R8>
4101 *[L-ISIS/14] 3w0d 02:53:43, metric 10

> to 1.1.1.1 via ge-0/0/0.0, Pop
4101(S=0) *[L-ISIS/14] 00:11:20, metric 10
> to 1.1.1.1 via ge-0/0/0.0, Pop

Provisioned LSP on R2 using privateForwardingAdjacency on R1 root@R2> show route label 27

root@R2> show spring-traffic-engineering overview
27 *[L-ISIS/14] 3w0d 03:03:13, metric 0
Route preference: 8
> to 1.1.1.5 via ge-0/0/1.0, Pop
Number of LSPs: 1 (Up: 1, Down: 0)
27(S=0) *[L-ISIS/14] 00:10:10, metric 0
> to 1.1.1.5 via ge-0/0/1.0, Pop
External controllers:
pccd
root@R2>
root@R1> show route label 1000001 <<< Binding SID
Name: R2_to_R9_Using_Binding_SID
To: 192.168.1.9
State: Up
Path: R2_to_R9_Using_Binding_SID
1000001 *[SPRING-TE/8] 01:26:13, metric 1
Outgoing interface: NA
> to 1.1.1.2 via ge-0/0/0.0, Swap 6108, Push 4106(top)
root@R1>
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
Hop 2 (Strict):
NAI: None
24 *[L-ISIS/14] 3w0d 03:05:11, metric 0
Hop 3 (Strict):
> to 1.1.1.42 via ge-0/0/1.0, Pop
NAI: None
24(S=0) *[L-ISIS/14] 00:09:41, metric 0
> to 1.1.1.42 via ge-0/0/1.0, Pop
root@R8>
root@R2>

General
Session Type Provisioning Status Uptime LSP Name : R2_to_R9_Using_Binding_SID
Northstar-1 Stateful Active On Up 1826018 PathName : R2_to_R9_Using_Binding_SID
From : 0.0.0.0 To : 192.168.1.9 State : Up
PLSP-ID : 15
root@R2> Controller : -
Record Route : NULL
Intended
Bandwidth : 0
Metric : 0
Actual
Bandwidth : 0
Metric : 0
root@R2>

root@R2> show route receive-protocol bgp 192.168.1.9

Prefix Nexthop MED Lclpref AS path
* 3.3.3.8/30 192.168.1.9 100 I
. . .
root@R2> show route 192.168.1.9
192.168.1.9/32 *[L-ISIS/14] 3w0d 04:24:15, metric 30

> to 1.1.1.10 via ge-0/0/0.0, Push 5109
[IS-IS/18] 3w0d 04:24:15, metric 30
> to 1.1.1.10 via ge-0/0/0.0


> to 1.1.1.5 via ge-0/0/1.0, Push 24, Push 1000001(top)
[L-ISIS/14] 3w0d 03:18:13, metric 30
> to 1.1.1.10 via ge-0/0/0.0, Push 5109
root@R2> show route 3.3.3.8/30

3.3.3.8/30 *[BGP/170] 00:07:32, localpref 100, from 192.168.1.9

AS path: I, validation-state: unverified
> to 1.1.1.5 via ge-0/0/1.0, Push 24, Push 1000001(top)
root@R2>

root@R1> show route label 1000001 <<< Binding SID root@R2> traceroute 3.3.3.10
mpls.0: 27 destinations, 28 routes (27 active, 1 holddown, 0 hidden) 1 1.1.1.5 (1.1.1.5) 60.015 ms 6.679 ms 15.064 ms
+ = Active Route, - = Last Active, * = Both MPLS Label=1000001 CoS=0 TTL=1 S=0
1000001 *[SPRING-TE/8] 01:26:13, metric 1 2 1.1.1.2 (1.1.1.2) 9.534 ms 20.978 ms 11.680 ms
> to 1.1.1.2 via ge-0/0/0.0, Swap 6108, Push 4106(top) MPLS Label=4106 CoS=0 TTL=1 S=0 BSID is getting swapped with th
MPLS Label=6108 CoS=0 TTL=1 S=0 label stack of 6108, 4106
root@R1> MPLS Label=24 CoS=0 TTL=2 S=1
3 1.1.1.14 (1.1.1.14) 10.004 ms 8.040 ms 14.160 ms
root@R2> show route 3.3.3.8/30 extensive MPLS Label=6108 CoS=0 TTL=1 S=0
inet.0: 38 destinations, 49 routes (38 active, 0 holddown, 0 hidden) 4 1.1.1.30 (1.1.1.30) 189.512 ms 73.754 ms 53.054 ms
3.3.3.8/30 (1 entry, 1 announced) MPLS Label=24 CoS=0 TTL=1 S=1
TSI: 5 3.3.3.10 (3.3.3.10) 23.284 ms 29.416 ms 17.951 ms
KRT in-kernel 3.3.3.8/30 -> {indirect(1048583)}
*BGP Preference: 170/-101 root@R2>
. . .
Source: 192.168.1.9
. . .
Label operation: Push 24, Push 1000001(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 24: None; Label 1000001: None;
. . .
Protocol next hop: 192.168.1.9
. . .
Indirect next hops: 1
Protocol next hop: 192.168.1.9 Metric: 0
. . .
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 1.1.1.5 via ge-0/0/1.0
. . .
Indirect nexthops: 1
Protocol Nexthop: 27 Metric: 0 Push 24, Push 1000001(top)
. . .
root@R2>
Provisioning LSP Using BGP SIDs
Nodes CE4, CE5 and CE7 are EBGP
peers of R8 and they are getting
discovered through EBGP-LS session
from R8 to NorthStar.

Provisioning LSP Using BGP SIDs Cont…
We can see the BGP Peer ADJ SID and BGP Peer
Node SID getting discovered in the link tab.
However We do not see BGP Peer Set SID (in our
case it is 1010100) getting discovered as it is still
not supported by NorthStar.

Provisioning LSP Using BGP PeerAdj SID

Provisioning LSP Using BGP PeerAdj SID Cont…

Provisioning LSP Using BGP PeerAdj SID Cont…

Provisioning LSP Using BGP PeerAdj SID: Verification on Router
External controllers: 18 *[L-ISIS/14] 06:45:05, metric 0
pccd > to 1.1.1.2 via ge-0/0/0.0, Pop
18(S=0) *[L-ISIS/14] 00:03:17, metric 0
Name: R1_to_CE4_Using_BGP_Adj_SID
To: 192.168.2.4
SR-ERO hop count: 3 4108 *[L-ISIS/14] 06:45:45, metric 20
Hop 2 (Strict): root@R4> show route forwarding-table label 4108
NAI: IPv4 Node ID, Node address: 192.168.1.8 Routing table: default.mpls
SID type: 20-bit label, Value: 4108 MPLS:
Hop 3 (Strict): Destination Type RtRef Next hop Type Index NhRef Netif
NAI: IPv4 Adjacency ID, 3.3.3.2 -> 192.168.2.4 4108 user 0 1.1.1.14 Swap 6108 603 2 ge-0/0/1.0
SID type: 20-bit label, Value: 1010002 . . .
root@R4>
root@R1>
Provisioning LSP Using BGP PeerAdj SID: Verification on Router
root@R6> show route label 6108 root@R1> show path-computation-client lsp extensive
General
mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 LSP Name : R1_to_CE4_Using_BGP_Adj_SID
PathName : -
hidden) From : 192.168.1.1 To : 192.168.2.4 State : Up
+ = Active Route, - = Last Active, * = Both Active Path : -
Link Protection none
6108 *[L-ISIS/14] 06:47:07, metric 10 LSP Type : ext-provised
> to 1.1.1.30 via ge-0/0/0.0, Pop P2mp tree : NULL
6108(S=0) *[L-ISIS/14] 00:03:42, metric 10 Path cspf status : external_cspf
> to 1.1.1.30 via ge-0/0/0.0, Pop Template : NULL
PLSP-ID : 5
LSP-ID : 0
root@R6> RSVP Error : 0x0
Priorities : 0
root@R8> show route label 1010002 Requested AutoBw : 0
mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 Record Route : NULL
hidden) From PCE ERO (received) : NULL
+ = Active Route, - = Last Active, * = Both Configured ERO on PCC : NULL
Intended
1010002 *[BGP-LS-EPE/170] 06:48:18, peer-as 300 Bandwidth : 0
> to 3.3.3.1 via ge-0/0/2.0, Pop Metric : 0
Actual
root@R8> Bandwidth : 0
Metric : 0
root@R1>

Provisioning LSP Using BGP PeerNode SID

Provisioning LSP Using BGP PeerNode SID Cont…

Provisioning LSP Using BGP PeerNode SID Cont…

Provisioning LSP Using BGP PeerNode SID: Verification on Router
External controllers: 18 *[L-ISIS/14] 07:10:17, metric 0
pccd > to 1.1.1.2 via ge-0/0/0.0, Pop
18(S=0) *[L-ISIS/14] 00:02:27, metric 0
Name: R1_to_CE4_Using_BGP_Node_SID
To: 192.168.2.7
SR-ERO hop count: 3 4108 *[L-ISIS/14] 07:10:43, metric 20
Hop 2 (Strict): root@R4> show route forwarding-table label 4108
NAI: IPv4 Node ID, Node address: 192.168.1.8 Routing table: default.mpls
SID type: 20-bit label, Value: 4108 MPLS:
Hop 3 (Strict): Destination Type RtRef Next hop Type Index NhRef Netif
NAI: IPv4 Adjacency ID, 192.168.1.8 -> 192.168.2.7 4108 user 0 1.1.1.14 Swap 6108 603 2 ge-0/0/1.0
SID type: 20-bit label, Value: 1010001 . . .
root@R4>
root@R1>
Provisioning LSP Using BGP PeerNode SID: Verification on Router
root@R6> show route label 6108 root@R1> show path-computation-client lsp extensive
General
mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden) LSP Name : R1_to_CE4_Using_BGP_Node_SID
+ = Active Route, - = Last Active, * = Both PathName : -
From : 192.168.1.1 To : 192.168.2.7 State : Up
6108 *[L-ISIS/14] 07:14:27, metric 10 Active Path : -
> to 1.1.1.30 via ge-0/0/0.0, Pop Link Protection none
6108(S=0) *[L-ISIS/14] 00:06:09, metric 10 LSP Type : ext-provised
> to 1.1.1.30 via ge-0/0/0.0, Pop P2mp tree : NULL
Path cspf status : external_cspf
root@R6> Template : NULL
PLSP-ID : 6
root@R8> show route label 1010001 LSP-ID : 0
RSVP Error : 0x0
mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden) Priorities : 0
+ = Active Route, - = Last Active, * = Both Requested AutoBw : 0
1010001 *[BGP-LS-EPE/170] 07:15:01, metric2 0, from 192.168.2.7, peer-as 300 Record Route : NULL
> to 3.3.3.17 via ge-0/0/4.0, Pop From PCE ERO (received) : NULL
to 3.3.3.21 via ge-0/0/5.0, Pop From RPD ERO (reported) : NULL
root@R8> show route forwarding-table label 1010001 Intended
Routing table: default.mpls Bandwidth : 0
MPLS: Metric : 0
Destination Type RtRef Next hop Type Index NhRef Netif Actual
1010001 user 0 ulst 1048575 2 Bandwidth : 0
3.3.3.17 Pop 615 2 ge-0/0/4.0 Metric : 0
3.3.3.21 Pop 616 2 ge-0/0/5.0 Last Rpt/Pcreqest received from RPD at : 00:10:21.000
. . . Last Update sent to PCE at : 00:10:21.000
root@R8> Last PcUpdate/PcCreate received from PCE at : 00:10:21.000
root@R1>

Provisioning LSP Using BGP SIDs - PeerSet SID
Not supported by NorthStar as of now. It is not being discussed in NorthStar developers as of now because of lack of use cases.
However once it would be implemented, Its provisioning from NorthStar should be similar to the provisioning of BGP Peer Node
SID.

TRAFFIC ENGINEERING WITH SPRING

Traffic engineering with SPRING (SPRING-TE)
Segment Routing Traffic engineering helps us make LSPs similar to how we create them using RSVP. Only difference is that the
LSP BW control needs to be done through controller. SPRING-TE provides the ability to create source routed LSPs, enabling
network applications that need traffic engineering.
The SR-TE next-hop is a list or lists of segment identifiers SIDs. These segment list or lists represent paths in the network that
the customer wants incoming traffic take. The incoming traffic may be labeled or IP traffic and the forwarding operation at the
ingress may be a label swap or a destination-based lookup to steer the traffic onto these SR-TE paths in the forwarding path.
SPRING-TE solution has the following components:
1. Use of IGP for advertising link characteristics: This part is the same as RSVP-TE.
2. Constrained Shortest Path Computation on the ingress or the controller.
3. Use of IGP for advertising labels for links: The ingress router (or external controller) constructs an LSP by stacking the labels
of the links that it wants to traverse.
The per-link IGP advertisement is combined with label stacking to create source routed LSP’s on the ingress. The transit routers
do not know the end-to-end LSP’s.

Traffic engineering with SPRING (SPRING-TE) Cont…
Config to enable SR-TE on Router:
protocols {
mpls {
lsp-external-controller pccd; <<< Enable PCEP based SR LSPs
}
lsp-external-controller pccd; <<< ‘pccd’ is the only one we support.
}
pcep {
pce Northstar-1 {
spring-capability;
}
}
}
Default value of SPRING-TE preference is 8. By default, SPRING TE is less preferred than RSVP and more preferred then
LDP. Since a SPRING TE LSP must be explicitly provisioned, we make it preferred over LDP.
You can use the below commands to see the SR-TE LSPs status.
show spring-traffic-engineering lsp name <name> (detail)

Traffic engineering with SPRING implementation options
Three ways to construct SR-TE LSP in Junos.
1. Static via CLI and NetConf (Static LSPs are Covered later in this presentation)
Interested table to look for: inet.3, inetcolor.0, inet6color.0.
2. BGP based SR-TE (Covered from next to next slide onwards)
Interested table to look for: inetcolor.0, inet6color.0, bgp.inetsrte.0, bgp.inet6srte.0.
3. PCEP based SR-TE - PCEP provisioned LSPs using PCCD (On next slide)
Interested table to look for: inet.3.

Traffic engineering with SPRING implementation through PCEP
SR-TE LSP based on Adj-SID (Provisioned through PCEP): SR-TE LSP based on NodeSID (Provisioned through PCEP):
root@R1> show spring-traffic-engineering lsp root@R1> show spring-traffic-engineering lsp
To State LSPname To State LSPname
192.168.1.9 Up AdjacencySID_R1_R9 192.168.1.9 Up NodeSID_R1_R9
Total displayed LSPs: 1 (Up: 1, Down: 0) Total displayed LSPs: 1 (Up: 1, Down: 0)
root@R1> show spring-traffic-engineering lsp name AdjacencySID_R1_R9 detail root@R1> show spring-traffic-engineering lsp name NodeSID_R1_R9 detail
Name: AdjacencySID_R1_R9 Name: NodeSID_R1_R9
To: 192.168.1.9 To: 192.168.1.9
State: Up, Outgoing interface: ge-0/0/4.0 State: Up, Outgoing interface: ge-0/0/1.0
SR-ERO hop count: 4 SR-ERO hop count: 2
Hop 1 (Strict): Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 1.1.1.45 -> 1.1.1.46 NAI: IPv4 Adjacency ID, 1.1.1.5 -> 1.1.1.6
SID type: 20-bit label, Value: 16 SID type: 20-bit label, Value: 17
Hop 2 (Strict): Hop 2 (Strict):
NAI: IPv4 Adjacency ID, 1.1.1.50 -> 1.1.1.49 NAI: IPv4 Node ID, Node address: 192.168.1.9
SID type: 20-bit label, Value: 17 SID type: 20-bit label, Value: 2109
Hop 3 (Strict):
SID type: 20-bit label, Value: 17 Total displayed LSPs: 1 (Up: 1, Down: 0)
Hop 4 (Strict):
root@R1>

BGP SR-TE
• This feature enables BGP to support a segment routing policy for traffic engineering at ingress routers.
• The controller can specify a segment routing policy consisting of multiple segment-lists to steer labeled or
IP traffic. Currently NorthStar doesn’t support these policies and it can’t provision it on the ingress router.
• The segment routing policy adds an ordered list of segments to the header of a packet for traffic steering.
• BGP installs the candidate routes of the segment routing policy into routing tables bgp.inetsrte.0 or
bgp.inet6srte.0. The table bgp.inetsrte.0 (or bgp.inet6srte.0) was earlier called
bgp.inetcolor.0 (or bgp.inet6color.0) in earlier releases.
• BGP selects one route from the candidate routes for a particular segment routing traffic engineering policy
and installs it in the routing tables inetcolor.0 or inet6color.0.
• This feature supports both statically configured as well as BGP-installed segment routing traffic
engineering policies in the forwarding table at ingress routers.

BGP SR-TE Policy Introduction
Controller can install SR policy via BGP to steer labeled or IP traffic. BGP SR-TE install pre-computed Traffic Engineered Tunnels at head end of a core
network. Below is the SR-TE definition as per the draft. You can view the draft at “https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07”
• The SR-TE tunnel is termed as SR-TE policy in the drafts. “SR-TE Policies” identified by <Endpoint, Color> (Color is just a 32-bit integer value
representing TE path From headend to the endpoint). You can consider color as a tag that separates multiple TE paths going to same endpoint. The
policies can be injected statically, dynamically (BGP) via controller. The SR-TE policies just looks like the routes and <Endpoint, Color> as their prefix
and next hop as bunch of SID list. Below is the format of the policy:
SR policy NAME <headend, color, endpoint>

Candidate-path PATH1 <protocol, origin, discriminator> <<< Can come from one external controller.
Preference 200
BSID 100
Weight W1, SID-List1: <SID11...SID1i>
Weight W2, SID-List2: <SID21...SID2j>
Candidate-path PATH2 <protocol, origin, discriminator> <<< Can come from another external controller.
Preference 100
BSID 100
Weight W3, SID-List3: <SID31...SID3i>
Weight W4, SID-List4: <SID41...SID4j>
• SR policy is associated with one or more candidate paths. Paths are represented as a list of SIDs (Adjacency, Anycast, etc.). Each candidate path is
associated with a Segment-List (SID-List), or a set of SID-Lists with weights. Each SR-TE Policy may have multiple such lists – equivalent to
multipath. The SR-TE tunnel specifies one or more arbitrary paths through the network in the form of one or more lists of segment identifiers (SIDs)
Note: We actually advertise SR-TE paths from the external controller (or configure them statically). If you look carefully the above definition is saying that
SR policy can be a collection of paths and these paths can come from different-different controllers (or via static configuration). Hence, we can not
generate SR-TE policy if we go by the definition in the draft, as paths from multiple controllers are involved. If we look in to Junos CLI then you will realize
that a SR-TE policy represents a SR-TE path.
BGP SR-TE Policy Introduction Cont…
• Binding SID - BSID is optional in SR-TE policy.
• Each SR policy may be defined with a Binding SID.
• Binding SID of a SR policy represents its active candidate paths. Binding SID label mapped to outgoing SR-TE path(s).
• Use BGP as a transport protocol.
• BGP sends NLRI with the tuple <Distinguisher, Endpoint, Color> to carry SR-TE policies. Distinguisher is a 32-bit field. If multiple
controllers are advertising same policy, then we use distinguisher to distinguish among them.
• If Multiple controllers are sending same NLRI with same distinguisher, then both routes will be installed as same entries in
bgp.inetsrte.0 but only one of the entry will be installed in inetcolor.0 table.
• If Multiple controllers are sending same NLRI with different distinguishers, then both routes will be installed as separate entries
in both bgp.inetsrte.0 and inetcolor.0 tables.
• Need to enable “family [inet|inet6] segment-routing-te” to exchange the SR-TE NLRI.
• Color: Color is just a 32-bit integer value representing TE path From headend to the endpoint. In RSVP, We identify multiple LSPs
going from Node A and Node B by LSP names. In SR-TE we use color for the same purpose. Color identifies the complete path. Color is
marking (distinguish) of paths having same endpoint. The <color-value> can take values in [0 to 232-1].

BGP SR-TE Policy Introduction Cont…
Color SR Policies vs Noncolor Color SR Policies:
1. Color Policy:
• A SR Policy is identified by its tuple (headend, color, end-point). At a given head-end node, a SR policy is uniquely
identified by its tuple (color, end-point).
• Headend – node where the SR policy is instantiated.

SR Policy 1: (R1, Green, R2)
• Color – numerical value that associates the SR policy with an intent.
• End-point – destination of the SR policy.

R3 R4
2. Non-Color Policy: Non-color LSP does not have color in it.
R1 R2
and its ingress routes is installed in the inet.3 table. IP traffic
Headend End-point
can be mapped to it based on destination. Labeled traffic can
be mapped to it by its binding-SID label. Non-Color LSP is similar R5 R6
to the one provisioned through the PCEP.
You can configure color/non-color statically or you can use BGP to configure them.
SR Policy 1: (R1, Blue, R2)
BGP SR-TE Policy standards
The SR-TE policies with a new SAFI value 73 in the BGP UPDATE are encoded along with the Tunnel Encapsulation attribute defined in “
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-12” (Format of the policy is defined below). The NLRI consists of a 3-value tuple,
namely <Distinguisher, Endpoint address, Color>. The Distinguisher is used to differentiate the originators of the same SR-TE policy,
namely <Endpoint address, Color>. A Preference sub-TLV (optional) is defined in the Tunnel Encapsulation attribute to select one from
different instances of the same NLRI value. Where:
+------------------+ • NLRI Length: 1 octet of length expressed in bits . The Length field indicates the length, in bits,
| NLRI Length | 1 octet
+------------------+
of the address prefix. A length of zero indicates a prefix that matches all (as specified by the
| Distinguisher | 4 octets address family) addresses (with prefix, itself, of zero octets).
+------------------+
| Policy Color | 4 octets • Distinguisher: 4-octet value uniquely identifying the policy in the context of <color, endpoint>
+------------------+
| Endpoint | 4 or 16 octets
tuple. The distinguisher has no semantic value and is solely used by the SR Policy originator to
+------------------+ make unique (from an NLRI perspective) multiple occurrences of the same SR Policy.
• Policy Color: 4-octet value identifying (with the endpoint) the policy. The color is used to
match the color of the destination prefixes to steer traffic into the SR Policy
• Endpoint: identifies the endpoint of a policy. The Endpoint may represent a single node or a set
of nodes (e.g., an anycast address or a summary address). The Endpoint is an IPv4 (4-octet)
address or an IPv6 (16-octet) address according to the AFI of the NLRI.
The color and endpoint are used to automate the steering of BGP Payload prefixes on SR policy. The NLRI containing the SR Policy is
carried in a BGP UPDATE message with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. NLRIs can have the same color and
endpoint but should have different distinguishers to have a differentiation between two policies.
BGP SR-TE Policy standards - Tunnel Encapsulation attribute
The content of the SR Policy is encoded in the Tunnel Encapsulation Attribute using a new Tunnel-Type TLV (codepoint is 15).
Tunnel Encapsulation attribute: The Tunnel Encapsulation attribute is an optional transitive BGP Path attribute. IANA has
assigned the value 23 as the type code of the attribute. The attribute is composed of a set of Type-Length-Value (TLV) encodings.
Each TLV contains information corresponding to a particular tunnel type. A TLV is structured as shown in below figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
• Tunnel Type (2 octets): Identifies a type of tunnel. The value is 15 (SR-TE policy). Please visit “
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml” for more details.
• Length (2 octets): the total number of octets of the value field.

BGP SR-TE Policy standards - Tunnel Encapsulation attribute Cont…
• Value (variable): comprised of multiple sub-TLVs. Each sub-TLV consists of three fields: 1-octet type, 1-octet or 2-octet length field
(depending on the type), and zero or more octets of value. Some of the important sub-TLVs are shown below. For complete list and
details of the sub-TLVs, Please visit “https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml” and “
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07” for details.
1. Encapsulation Sub-TLVs for Particular Tunnel Types (Type = 1): Defines Tunnel Encapsulation sub-TLVs for the following
tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC2784],
[RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]).
2. Color Sub-TLVs (Type = 4): The color sub-TLV MAY be encoded as a way to color the corresponding tunnel TLV. The value field
of the sub-TLV contains an extended community that is defined below: The Color Extended Community is an opaque extended
community with the following encoding:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | 0x0b | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the high-order octet of the extended type field is 0x03, which indicates it is transitive. The value of the low-order octet
of the extended type field for this community is 0x0b. The color value is user defined and configured locally on the routers. The
same Color Extended Community can then be attached to the UPDATE messages that contain payload prefixes. This way, the BGP
speaker can express the fact that it expects the packets corresponding to these payload prefixes to be received with a particular
tunnel encapsulation header.
3. Remote Endpoint Sub-TLV (Type = 6): The Remote Endpoint sub-TLV is a sub-TLV whose value field contains three sub-
fields: Where:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
a. A four-octet Autonomous System (AS) number sub-field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (IPv4 or IPv6)
| Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~ b. A two-octet Address Family sub-field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| | c. An address sub-field, whose length depends upon the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family.
4. MPLS Label Stack Sub-TLV (Type = 10): This sub-TLV allows an MPLS label stack (RFC 3032) to be associated with a
particular tunnel.
The value field of this sub-TLV is a sequence of MPLS label stack entries. The first entry in the sequence is the "topmost" label, the
final entry in the sequence is the "bottommost" label. This label stack is pushed onto a packet.
Each label stack entry has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Preference Sub-TLV (Type = 12): The Preference sub-TLV does not have any effect on the BGP bestpath selection or
propagation procedures. The contents of this sub-TLV are used by the Segment routing Policy. The preference of the candidate path
is used to select the best candidate path for an SR Policy. The default preference is 100. The Preference sub-TLV has the format
shown below: Where:
0 1 2 3 Type is 12; Length is 6; Flags: 1 octet of flags. Still not defined, Should set
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
to zero.
| Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (4 octets) |
RESERVED: 1 octet of reserved bits. Should set to zero; Preference: a 4-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ octet value.
6. Binding SID Sub-TLV (Type = 13): The Binding SID sub-TLV is not used by BGP. The contents of this sub-TLV are used by the
Segment routing Policy. The Binding SID sub-TLV is optional. The Binding
Where: sub-TLV has the format shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type is 13; Length specifies the length of the value field not including
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type and Length fields. Can be 2 or 6 or 18.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding SID (variable, optional) | Flags:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S-Flag: This flag encodes the "Specified-BSID-only" behavior.

Flags: I-Flag: This flag encodes the "Drop Upon Invalid" behavior.
Unused bits in the Flag octet SHOULD be set to zero.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I| | RESERVED: 1 octet of reserved bits. Should be set to zero.
+-+-+-+-+-+-+-+-+
Binding SID: if length is 2, then no Binding SID is present.
If length is 6 then the Binding SID contains a 4-octet SID. Below format is used to encode the SID. TC, S, TTL (Total of 12bits) are
RESERVED and SHOULD be set to Zero and MUST be ignored. If length is 18 then the Binding SID contains a 16-octet IPv6 SID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Segment List Sub-TLV (Type = 128): The Segment List sub-TLV encodes a single explicit path towards the endpoint as
described. The Segment List sub-TLV includes the elements of the paths (i.e., segments) as well as an optional Weight sub-TLV.
The Segment List sub-TLV may exceed 255 bytes length due to large number of segments. Therefore a 2-octet length is required.
The Segment List sub-TLV is optional and MAY appear multiple times in the SR Policy. The ordering of Segment List sub-TLVs,
each sub-TLV encoding a Segment List, does not matter.
The Segment List sub-TLV contains zero or more Segment sub-TLVs and MAY contain a Weight sub-TLV.

The Segment List sub-TLV has the following format: Where:
0 1 2 3 Type is 128; Length is the total length (not including the Type and Length
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ fields) of the sub-TLVs encoded within the Segment List sub-TLV.
| Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// sub-TLVs // RESERVED: 1 octet of reserved bits. Should set to zero; Preference: a 4-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ octet value.
sub-TLVs:
• An optional single Weight sub-TLV.
• Zero or more Segment sub-TLVs.
i. Weight sub-TLV (Type = 9): The Weight sub-TLV specifies the weight associated to a given segment list. The Weight sub-
TLV is optional. The Weight sub-TLV has the following format:
0 1 2 3
Where:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type is 9; Length is 6 and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | RESERVED: 1 octet of reserved bits. Should set to zero;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preference: a 4-octet value.

ii. Segment Sub-TLV (Type = 9): The Segment sub-TLV describes a single segment in a segment list (i.e., a single element of
the explicit path). Multiple Segment sub-TLVs constitute an explicit path of the SR Policy. The Segment sub-TLV is optional
and MAY appear multiple times in the Segment List sub-TLV.
[I-D.ietf-spring-segment-routing-policy] defines several types of Segments:
Type 1 : SID only, in the form of MPLS Label <<< Type 1 is supported.
Type 2 : SID only, in the form of IPv6 address
Type 3 : IPv4 Node Address with optional SID
Type 4 : IPv6 Node Address with optional SID for SR MPLS
Type 5 : IPv4 Address + index with optional SID
Type 6 : IPv4 Local and Remote addresses with optional SID
Type 7 : IPv6 Address + index for local and remote pair with optional SID for SR MPLS
Type 8 : IPv6 Local and Remote addresses with optional SID for SR MPLS
Type 9 : IPv6 Node Address with optional SID for SRv6
Type 10 : IPv6 Address + index for local and remote pair with optional SID for SRv6
Type 11 : IPv6 Local and Remote addresses for SRv6

Type 1: SID only, in the form of MPLS Label: The Type-1 Segment Sub-TLV encodes a single SID in the form of an
MPLS label. The format is as follows: Where:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type is 1; Length is 6 and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RESERVED: 1 octet of reserved bits. Should set to
| Label | TC |S| TTL | zero; Preference: a 4-octet value.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: 20 bits of label value; TC: 3 bits of traffic class;

Flags: S: 1 bit of bottom-of-stack. The S bit SHOULD be zero
upon transmission; TTL: 1 octet of TTL.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|A| |
+-+-+-+-+-+-+-+-+
V-Flag: This flag is used by SR Policy for the purpose of "SID verification" as described in Section 5.1 in “
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-03#section-5.1”. V-Flag is applicable to all Segment
Types.
A-Flag: This flag indicates the presence of SR Algorithm id in the "SR Algorithm" field applicable to various Segment
Types. SR Algorithm is used by SR Policy as described in section 4 in “
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-03#section-5.1”. This Flag is not used.
Unused bits in the Flag octet SHOULD be set to zero upon transmission and MUST be ignored upon receipt.
BGP SR-TE - Policy Route Installation
static
SPRING-TE inet.3 bgp.inetsrte.0
SR-TE Can leak route 1. BGP installs the update with distinguisher
Policies using RIB Groups for BGP best path election.
PCEP inetcolor.0 BGP Controller

2. Installs the BGP Update
update with SR-TE
BSID without NLRI
BGP SR-TE through PCEP is supported distinguisher
in the draft but currently NorthStar after BGP
does not support BGP SR-TE through best path
PCEP. Not Sure if it would be mpls.0
supported in NorthStar in future.
selection. RPD
Note:
• inetcolor.0 function is same as inet.3. It is a resolving RIB. It is a SR-TE table. Routes of this table will not get installed in forwarding table.
• bgp.inetsrte.0 is used for best path selection based on distinguisher and route import/export/re-advertisement (on RR) etc, It is not used for
route resolution.
BGP SR-TE - Policy Route Installation Cont…
SR-TE policy installation in RIBs - Once an SR-TE policy is considered Acceptable, the following procedures apply:
• The SR-TE policy is installed in the bgp.inetsrte.0 (bgp.inet6srte.0) RIB. Entries with same <Endpoint address,
Color> value but different Distinguisher are installed as separate entries in the bgp.inetsrte.0 RIB. Note that SR-TE
policies with Invalid segment lists are also installed here.
• Valid policies are subsequently installed (without distinguisher) into the resolution RIBS, namely inetcolor.0
(inet6color.0) RIBs as secondary routes with only <Endpoint address, Color > as the key. The following considerations
apply when deciding to install the secondary routes in the resolution RIBs:
• If the number of segment lists (paths) exceed the maximum path limit configured using the existing configuration knob, “
chassis maximum-ecmp” or an internal limit of 8, whichever is minimum, the SR-TE policy is installed in
inet[6]color.0 (inet6color.0) with a pruned set of segment lists.
• If the number of segments of any of the segment lists exceed the configured value in maximum-segment-routing-depth
“set protocols source-packet-routing maximum-segment-list-depth <depth 0-5>”, (default value is 5)
then those segment lists are pruned before installing the SR-TE policy into inetcolor.0 (inet6color.0). This
configuration is applied only after the Routing Process Daemon is restarted.

BGP SR-TE - Policy Route Installation Cont…
• Policies with different distinguisher values in bgp.inetsrte.0 (bgp.inet6srte.0) are installed as different paths of
the same entry in the inetcolor.0 RIB with one of the paths selected as the best using traditional BGP best-path
procedures.
• If all segment lists are either Invalid or pruned out, then the SR-TE policy is not added to the resolution RIBs. This is
because the invalidations arising out of limitations or configuration are not expected to change due to future network
events. Note that, the SR-TE policy entry with the received segment lists is still maintained in the bgp.inetsrte.0
(bgp.inet6srte.0) RIB with appropriate reason codes for debug and re-advertisement purposes.
• If any of the segment lists of the received SR-TE policy is Invalid as per the above tests, then that segment list is pruned
when installing the policy to the resolution RIBs (and therefore will not be considered when creating forwarding entries).
• When an SR-TE policy is added as secondary routes to the resolution RIBs, namely inetcolor.0 (inet6color.0), an
attempt is made to resolve the top label of each segment list. If any one of the segment lists resolved, the SR-TE policy is made
Active in this RIB.
• The Weight sub-TLV in the Tunnel Encapsulation attribute is applied as balance parameters for each SR-TE Segment list TLV
specified in the update. If the Weight sub-TLV is not present, they are treated as equal cost paths.

BGP SR-TE - Traffic Steering in SR-TE policy for labelled traffic
Color is just a 32-bit integer Anycast IP
value representing TE path
Anycast IP 30.30.30.30
From headend to the SID = 30 Top label
10.10.10.10
endpoint 1010  10.10.10.10
SID = 10 Endpoint IP
Servers DCR1 Used for resolution
60.60.60.60
Headend SID = 60 Label Swap
DCR3 at DCR1/DCR2
Endpoint
1030 SR-TE
d 1050 Label Stack 1
abelle
L affic 100
1060 (Weight = x)
Tr hing
tc P DCR4 Binding SID 1040 SR-TE
ma en LS Endpoint
e 1050 Label Stack 2
Gr
Endpoint IP 1060 (Weight = y)
Anycast IP
Forwarding
50.50.50.50 70.70.70.70
SID = 50 SID = 70
DCR2
Controller Headend Anycast IP
Top label
20.20.20.20 Anycast IP
1020  20.20.20.20
SID = 20 40.40.40.40 Used for resolution
© 2018 Juniper Networks
SID = 40 156
BGP SR-TE - Traffic Steering in SR-TE policy for labelled traffic Cont…
a) A colored SR LSP, because it has the notion of “color”, may have a binding SID, for which a route will be installed in the
mpls.0 table. This binding SID label is used to map labeled traffic to the SR LSP. Colored LSP is resolved in inetcolor.0
table if we configure the “extended-nexthop-color” knob. inetcolor.0 table uses the <Endpoint address, Color> as the
lookup key. Forwarding entry for the prefix is installed in inet.0 but the label for next-hop creation is taken from
inetcolor.0 table.
bgp.inetsrte.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10-192.168.1.9-100<sr>/96 <<< 10 is Distinguisher, 100 is color, and <sr> is a tag value to identify the address family (SR-TE).
*[BGP/170] 00:05:00, localpref 100 “10-192.168.1.9-100<sr>/96” is complete BGP SR-TE policy route.
AS path: 500 I, validation-state: unverified
> to 5.5.5.2 via ge-0/0/7.0
20-192.168.1.9-100<sr>/96
*[BGP/170] 00:05:00, localpref 100
> to 6.6.6.2 via ge-0/0/8.0
inetcolor.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)

192.168.1.9-100<c>/64 <<< Distinguisher (10) is dropped as soon as route moves to inetcolor.0. 100 is s color,
*[BGP/170] 00:05:04, localpref 100, from 5.5.5.2 and <c> is a tag value to identify the address family (Color).
> to 1.1.1.6 via ge-0/0/1.0, Push 17, Push 18, Push 28(top)
to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top) b) A non-colored SR LSP does not have a color. An
to 1.1.1.2 via ge-0/0/0.0, Push 24, Push 19, Push 18(top)
[BGP/170] 00:05:04, localpref 100, from 6.6.6.2 ingress route (for its destination) is installed in the
inet.3 table. The route has a protocol of SPRING-
to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top)
TE, and by default, a preference of 8 and a metric of 1.
A non-colored SR LSP may have a binding–SID label. 157
BGP SR-TE - Traffic Steering in SR-TE policy for IP traffic
Color is just a 32-bit integer {Nexthop address, Color attribute} <==>
Anycast IP
value representing TE path SR-TE: {Endpoint, Color}
Anycast IP 30.30.30.30
From headend to the SID = 30 Top label
10.10.10.10
endpoint 1010  10.10.10.10
SID = 10 Endpoint IP
Servers DCR1 Used for resolution
60.60.60.60
Headend SID = 60 60.60.60.60-red
DCR3 at DCR1/DCR2
Endpoint
1030 SR-TE
r affic 1050 Label Stack 1
T g
IP tchin 1.1.1.1/24
1060 (Weight = x)
m d LSP
a
DCR4 Payload 1040 SR-TE
Re Endpoint Prefix 1050 Label Stack 2
Endpoint IP 1060 (Weight = y)
Anycast IP
Forwarding
50.50.50.50 70.70.70.70
SID = 70 (inet.0)
SID = 50
DCR2
Controller Headend Anycast IP
Note: Payload prefixes Top label
20.20.20.20 Anycast IP
are advertised by 1020  20.20.20.20
SID = 20 40.40.40.40 endpoint to the headend Used for resolution
SID = 40 158
BGP SR-TE - Traffic Steering in SR-TE policy for IP traffic Cont…
inet-unicast and inet6-unicast prefixes with color community attached (we call them payload prefixes) may steer
traffic over SR-TE policies. By default this resolution is disabled. We use color community to do lookup in inetcolor.0. We
don’t do the lookup in inet.3. Based on color value and endpoint (next-hop) payload prefix will choose the path. Endpoint may
be aware of the color as it may need to attach the color community to the prefixes that will be advertised to headend. Headend
then send traffic to these prefixes to different tunnels according to color. With “extended-nexthop-color”, Payload prefixes
will start getting resolved in inetcolor.0 (or inet[6]color.0). By default color lookup is disabled and payload prefixes gets
resolve in inet.3.
If “extended-nexthop-color” is not enabled for a address family, then traffic destined for these prefixes are steered over
IGP/MPLS routes (i.e. resolution uses routes present in inet.3 and inet.0). In this case, the color communities attached to
these prefixes are effectively ignored (although they are maintained as attributes). In summary:
• If the “extended-nexthop-color” knob is disabled, then color community attached prefixes resolve over default resolution
RIBs for inet.3 or inet6.3.
• If the “extended-nexthop-color” knob is enabled then prefixes with color community attached resolve over inetcolor.0
or inet[6]color.0 using the <Nexthop address, color> tuple as the key.

BGP SR-TE – SR-TE Policy Traffic Steering at Ingress Router
Two types of traffic can come on headend (DCR1/DCR2).
1. Labelled traffic (Traffic to Binding SID in the policy advertised by Controller): One Binding SID may be associated
with each SR-TE policy. In the previous example we have Binding SID as 1000001. This BSID gets installed in mpls.0 and this
route has the NH as the top label (27) and the label list.
So if there is an incoming traffic from customer. The Binding SID gets pop and labels (28 (top), 18, 17) gets pushed to the
packet.
2. Unlabeled plane IP Traffic (Traffic to Payload prefix advertised by Endpoint router): The Endpoint router usually
advertise the route with color community attached to it. In this case you have an option to do a resolution in inetcolor.0
instead of inet.3. Here endpoint is the next hop. The tuple <endpoint, color> is used for the lookup the color route. SR-TE
itself resolves over the top label and payload prefix itself is resolved over the inetcolor.0 SR-TE route. In this case only label
push operation is carried out.
Note: Top Label may resolve in multiple paths which may have weight attached to it. In this case you can have hierarchical ECMP.

BGP SR-TE - Traffic Steering - How does an SR-TE Policy look?
192.168.1.9-100<c>/64 (2 entries, 1 announced) <<< For Ipv6 the tag would be <c6>.
SRTE Policy Path:
Path preference: 0
Binding-SID: 1000001 <<< BSID 1000001 is bound to the policy and forwarding route is installed in mpls.0, This route will point to the tunnel with push 28 (top), 18, 17.
Segment list:
Weight: 20 <<< Weight is an absolute number for loadbalance, which gives percentage of the balance with respect to the sum of weights of all paths.
Label: 27 ttl: Local-ttl-policy <<< Top label represents the first hop and it has to be resolved in mpls.0, In this case it is resolving in a label stack
Label: 28 ttl: Local-ttl-policy consisting 28 (top), 18, 17. Top label decides on how to forward the traffic to SR-TE policy. Top label can mean
Label: 18 ttl: Local-ttl-policy any operation (push / swap / pop, none). Pop means immediate hop and then remaining labels can be pushed as
Label: 17 ttl: Local-ttl-policy shown in this example. BSID (or complete SR-TE Policy or we can say segment list) resolves over Top label as it
Segment list: points to the next hop.
Weight: 30
Label: 28 ttl: Local-ttl-policy <<< Top label representing this segment. The hop labels in these segment list can be any SID, The only requirement is
Label: 16 ttl: Local-ttl-policy that these labels should be present in mpls.0 (with normal next hop types) in the respective routers.
Label: 6109 ttl: Local-ttl-policy
Segment list:
Weight: 50
Label: 1104 ttl: Local-ttl-policy <<< Top label representing this segment. The hop labels in these segment list can be any SID, The only requirement is
Label: 18 ttl: Local-ttl-policy that these labels should be present in mpls.0 (with normal next hop types) in the respective routers.
. . .
Protocol next hop: 27 <<< 27 represents the first hop. It may be a Strict or loose hope (Adj or Node SID). We don’t have swap operation
Label operation: Push 17, Push 18, Push 28(top) for it means we are going to pop the 27 and push 28 (top), 18, 17.
. . .
SRTE Policy State:
SR Preference/Override: 0/100
BSID: 1000001 <<< BSID 1000001 is bound to the policy and forwarding route is installed in mpls.0, This route will point to the tunnel with push 28 (top), 18, 17.
Localpref: 100
Router ID: 192.168.1.100
Note: Weight is an absolute number, which gives percentage of the balance with respect to the sum of weights of all paths.
Default weight of 1 is considered for that segment list. If one of the path goes away 100% of traffic will be put on the other path.
sr_sl1: weight = 1 # Balance sr_sl1: 1/3 * 100 = 33%

© 2018 Juniper Networks sr_sl2: weight = 2 # Balance sr_sl2: 2/3 * 100 = 67% 161
BGP SR-TE - SR-TE Policy Forwarding entries with Binding-SID
If a Binding-SID TLV is present, a cross-connect entry is installed in mpls.0 table with the Binding-SID label as the incoming
label and the SR-TE segment lists as the nexthops. The inetcolor.0 (inet6color.0) RIB is specified as the resolution table.
• If the none of the top labels of the segment lists in the resolving SR-TE policy can be resolved via mpls.0, the SR-TE policy is
considered un-resolved and the corresponding Binding-SID cross-connect entry in mpls.0 remains Inactive.
If some of the segment lists of the SR-TE policy are resolved, i.e. the top label of these segment lists have resolution, then the
Binding-SID cross-connect is made active, but the forwarding entry shall contain only the resolving segment lists. The
remaining segment lists from the resolving SR-TE policy from inetcolor.0 (inet6color.0) are not installed.
• The route entries in inetcolor.0 (inet6color.0) table are only used to resolve forwarding-nexthops for binding-SID or
“payload-prefix + color” in SR-TE policy; the route entries themselves will not be installed to kernel and forwarding-plane, this
behavior is similar to routes in inet.3 and inet6.3 tables.

BGP SR-TE - SR-TE Policy Forwarding entries with Binding-SID Cont…
Let's say the BGP speaker in DCR1 receives an update from the controller with the following information:
Binding SID sub-TLV 1000001 <<< Binding-label 1000001 as the incoming label
SID_list_1::segment-list {27, 28, 18, 17} <<< Top Label of the segment list “SID_list_1” is 27 and it is resolved in mpls.0 to obtain the forwarding next-hop(s).
SID_list_1::weight 20
SID_list_2::segment-list {28, 16, 6109} <<< Top Label of the segment list “SID_list_2” is 28 and it is resolved in mpls.0 to obtain the forwarding next-hop(s).
SID_list_2::segment-list {1104, 18, 19, 24} <<< Top Label of the segment list “SID_list_2” is 1104 and it is resolved in mpls.0 to obtain the forwarding next-hop(s).
Endpoint address 192.168.1.9

Color 100
Let's say that the top labels in this case resolve over IGP paths with the following nexthops:
27 : via ge-0/0/1.0, 1.1.1.5 <<< The top label of SID_list_1 is directly connected. In this case, the BSID route entry in mpls.0 is depicted as follows.
28 : via ge-0/0/4.0, 1.1.1.45 <<< The top label of SID_list_2 is directly connected.
1104: via ge-0/0/0.0, 1.1.1.1 <<< The top label of SID_list_3 is directly connected.
1000001
Protocol next hop: 27

Label operation: Swap 17, Push 18, Push 28(top)
Balance: 20%

Label operation: Swap 6109, Push 16(top)
Balance: 30%

Balance: 50%
BGP SR-TE - SR-TE Policy Forwarding entries with Payload Prefix
In this scenario, [inet|inet6]-unicast prefixes (payload prefixes) sent by the originating BGP speaker is appended with a
color community. The receiving BGP speaker, and also the SR-TE tunnel head-end in this example, on receipt of this prefix, shall
use the next-hop in the BGP UPDATE and the color community to select the SR-TE tunnel installed previously in the
inet[6]color.0 table. The tuple <Nexthop address, color> is used as a key to select the SR-TE tunnel in inet[6]color.0
with a matching endpoint. The IP traffic towards the payload prefix thus gets steered over the selected SR-TE tunnel.
If the payload prefixes (i.e. [inet|inet6]-unicast prefixes), are configured for resolution over SR-TE policies, then the
following apply:
• If the matching SR-TE policy is inactive, then the payload prefix routes in inet.0 (inet6.0) RIBs cannot resolve over that
SR-TE policy and the payload prefix remains Inactive. No forwarding entry is created.
• If the payload prefix resolves over an Active SR-TE policy (i.e. some of its segment lists resolve), then the route entry
corresponding to the payload prefix becomes Active and is installed in the FIB. Only those segment lists that are resolved are
considered as paths for this forwarding entry.
• The top label from each segment list is used for resolution and is replaced with the label resolved from mpls.0. If the top label
in mpls.0 has a pop and forward action, then the top label does not appear in the label stack.

BGP SR-TE - SR-TE Policy Forwarding entries with Payload Prefix Cont
• The forwarding entry is created with the default BGP preference value of 170.
• If the BGP speaker receives a payload prefix with multiple color communities attached, only the first community in the update
shall be used for resolution. (Note: The draft does not specify any special handling of this case).
• If the BGP speaker receives a payload prefix with color communities, with unsupported steering options, namely CO = 01 or CO
= 10, it shall be treated in the same manner as if the CO = 00, i.e. an attempt is made to resolve the payload prefix over a
matching SR policy and failing that, it shall resolve over IGP paths.
• Considering the same SR Policy example as in the previous section for steering of a payload prefix 3.3.3.8/30 case we get the
following. (Note here that the bottom label is pushed instead of being swapped as in the case of the Binding-SID route
example).
3.3.3.8/30
Protocol next hop: 192.168.1.9-100<c>
Communities: color:2:100
Label operation: Push 17, Push 18, Push 28(top)

Balance: 20%

Balance: 30%

Balance: 50%

BGP SR-TE - Fallback mechanism
Fallback mechanism when SR-TE Policy for a steering route is not available:
In the scenario where a BGP speaker receives payload prefixes with color community but do not find entries with <Endpoint
Address, Color> in the resolution RIBs, it may be desirable to resolve these payload prefixes via inet.3 routes as a backup, i.e.
without considering the color.
We can implement this using existing rib-group commands to install secondary routes from inet.3 and inet6.3 into
inetcolor.0 (inet6color.0). When installing, these routes are created with a prefix length that masks out the color value.
We consider these routes to have indeterminate color in these RIBs.
This mechanism is not supported for RSVP learned routes.
Since the resolution RIBs use a 32-bit color value as part of the least matching prefix lookup, masking it out will yield entries with
prefix lengths of 32 for inetcolor.0 and 128 for inet6color.0. A single least prefix match lookup in inetcolor.0
(inet6color.0) will match these entries as fallback paths when a fully specified SR-TE policy is not present.
4.4.4.4/32  4.4.4.4-0<c>/32 <<< This results in a route with color masked out, i.e. something like 4.4.4.4<c>/32
Non colored routes are those routes who uses the same SR-TE tunnels but for inet.3 routes. You uses SR-TE policies for the
no-colored route by using above rib-group method.

BGP SR-TE - Attaching color community to routes
How to attach color community to payload prefix?
set policy-options community <name> members color:<color-mode>:<color-value>
• The above policy action allows us to attach an extended color community to NLRI exported by BGP. Refer “
https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-06” for more details.
• The <color-mode> can take values in [1..3], representing the "C" and "O" bits.
This color-only steering variation is governed by two new flags "C" and "O" defined in the color extended community. The Color-Only flags
"CO" are set to 00 by default.
• When 00 or 11, the BGP destination is preferably steered onto a valid SR Policy (N, C) where N is an IPv4/6 endpoint address and C is a
color value else it is steered on the IGP path to the next-hop N.
• When 01, the BGP destination is preferably steered onto a valid SR Policy (N, C) else onto a valid SR Policy (null endpoint, C) else on the
IGP path to the next-hop N. The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set to the 0 value). We are yet to support this
mode.
• When 10, the BGP destination is preferably steered onto a valid SR Policy (N, C) else onto a valid SR Policy (null endpoint, C) else on any
valid SR Policy (any endpoint, C) else on the IGP path to the next-hop N. The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set
to the 0 value). We are yet to support this mode.

BGP SR-TE - Best path selection
Best path selection of SR-TE policies:
As per draft, SR-TE policies should be protocol independent selection. For a given SR-TE Policy (identified by <Endpoint,
Color>), different protocols such as BGP or Static may install multiple SR Paths in the inet[6]color.0 tables. Both BGP and
SPRING-TE install to inetcolor.0.
For a given SR-TE Policy (identified by <Endpoint, Color>), different protocols such as BGP or Static may install multiple SR
paths in the inet[6]color.0 tables. Also in the case of BGP, SR-TE NLRI routes with different distinguishers in
bgp.inet[6]color.0 when imported to inet[6]color.0 will create multiple SR Paths as well.
One of the candidate SR Paths in the inetcolor.0 (or inet[6]color.0) table is selected active. Only the Binding-SID of the
active SR path (if available) is considered for installation in mpls.0 for labeled traffic steering. Also in the case of payload
prefixes, unlabeled traffic is steered onto the active SR Path only.

BGP SR-TE - Best path selection Cont…
The selection of the active SR Path proceeds as follows:
1. First a “sr-preference-override” value is assigned to each SR Policy. This value is set to a default of 100 for all protocols
that install SR Paths in the inet[6]color.0 tables. A higher value of “sr-preference-override” is preferred. Since
this is usually kept equal for all protocols, the selection typically proceeds to the next step.
set protocols bgp sr-preference-override <sr-preference-override>

set protocols source-packet-routing static-sr-preference-override <sr-preference-override>
2. Next the Preference-TLV (Configurable for SPRING-TE) carried in BGP or sr-preference configured for Static is compared.
Again the higher value is preferred. If these values are not available in the update or configured, a default value of 100 is
assumed.
3. Next the default JUNOS preference values for the installing protocol, namely 8 for Static SR-TE policies and 170 for BGP SR-
TE (180 for SPRING-TE) policies are compared. Here the lower of the two is preferred. However this value can be modified by
configuring a global preference value for Static SR-TE policies or a per policy preference value. The implication here is that
there is never a tie between SR Paths installed by two different protocols. These can be set using the existing “preference”
knob for each protocol. It is highly recommended to configure separate values for different protocols.
4. The current JUNOS best-path procedures for the individual protocol apply (e.g: BGP best-path). Note that Step 3 ensures that
SR Paths from different protocols don’t end up here.
When a new update is received for the same <Endpoint address, Color> tuple, but with different Distinguisher value, these are
treated as different occurrences of the same NLRI. Both candidate SR paths are installed in the resolution RIBs (namely
inetcolor.0 or inet6color.0) if found valid. Since the distinguisher is dropped from the prefix in the resolution tables, one
of these entries is selected as the active SR policy. The selection proceeds as follows:
• The two candidate SR paths are treated as imported from different protocol instances and as per the draft, the Preference sub-
TLV is compared. The SR path with the higher value is preferred.
• If the Preference sub-TLV is not present in one or either policy, then the default value of 100 is assumed for comparison (Refer
Section 3 of “https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-06”). If the above comparison results in
equal preference, then the rest of JUNOS best path selection applies. Since in this example, both candidate SR paths are BGP,
the best-path is the BGP best-path selection.
Note that each SR-TE policy entry may itself have multiple Segment List sub-TLVs and the corresponding forwarding entry may
be a multipath, but the two SR-TE policy entries are not merged in any way.

If BGP receives an update for different SR-TE NLRI, with same Binding-SID then In this case, the newly arrived SR-TE policy is
added to both the bgp.inetsrte.0 (bgp.inet6srte.0) and inetcolor.0 (inet6color.0) tables.
After the selection process in the inetcolor.0 (inet6color.0) tables, if the Binding-SID corresponding to the active SR Path
is already bound to a different SR Policy (i.e. different <Endpoint, Color>), then the Binding-SID is deemed unavailable.
In this case, the BGP speaker shall generate a SYSLOG and not install the Binding-SID for the new SR Policy into mpls.0.
If the SR Policy is selected active in inetcolor.0 (inet6color.0), no attempt is made to install the Binding-SID of a less
preferred SR Policy. It is up to the controller to re-advertise a preferred SR-Policy with the desired Binding-SID value.

BGP SR-TE - Mandatory conditions
• Remote endpoint TLV(optional) and Tunnel endpoint should have the same IP.
• Extended community of RT (Route Target) or NO_ADVERTISE should be present else BGP will reject that
route.
• Route is accepted if RT is present but only moved to inetcolor.0 if RT community contains Router ID of
the receiving router.
• Advertisement should contain AS_PATH.
• Color community should be present.

R3 - lo0.0-
17 192.168.1.3/32 16 Reminder:
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30 Formula to calculate the Node label for remote Router:
Topology Downstream Neighbor's Expected Node SID from local Router =
Start-label of downstream neighbor router’s label range

+
09
61
Northstar
Node index advertised by Destination Router
61
0
Controller
9
,
16
192.168.1.10 em2
AS200 172.16.18.199/24
28 17
ge-0/0/9 ge-0/0/4 ge-0/0/4

172.16.18.11/24 1.1.1.45/3 18 19, 24 20
1.1.1.49/30
24
BGP SR-TE
Port 1 ge-0/0/6 R1 - lo0.0- ge-0/0/0 18, 1 9, ge-0/0/0 R4-RR - lo0.0- ge-0/0/1 ge-0/0/1 R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0-
5.5.5.2/30 5.5.5.1/30 192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
Controller 1 SL: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 SL: 8000
29 19 19 24 25
AS500 Index: 101 Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106 Index: 108
EBGP; family Loose Hop
Advertised Policy segment-routing-te ge-0/0/1 ge-0/0/3 16 18 ge-0/0/3 ge-0/0/1
10-192.168.1.9-100<sr>/96 1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 Can take 8109 1.1.1.41/30
ge-0/0/7
6.6.6.1/30
27 17 16 24
EBGP; family
3.3
segment-routing-te .3.
8/
30
,C
olo Loose Hop
Port 1 28, 18, 17 r1 IPv4 IPv4
BGP SR-TE 00 Can take 7109
6.6.6.2/30 Segment Routing
Controller 2 CE5
AS100 ge-0/0/1
AS600
3.3.3.9/30
Advertised Policy
20-192.168.1.9-100<sr>/96
27 17 16 25
Three Segments of a Single LSP path
(R1-R9) in the Topology: ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1
1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
Advertised Subnet
R2 - lo0.0- R5 - lo0.0- ge-0/0/1 ge-0/0/1 R7-RR - lo0.0- R9 - lo0.0- ge-0/0/3
1. Blue LSP: (R1-R2-R5-R7-R9) 192.168.1.2/32 28 16 192.168.1.5/32 17 192.168.1.7/32 17 IPv4 24 192.168.1.9/32 3.3.3.10/30 from R9 to R1
2. Red LSP: (R1-R3-R6-R8-R9) 18 18
3. Green LSP: (R1-R4-R6-R8-R9) Index: 102 1.1.1.9/30 1.1.1.10/30 Index: 105 ge-0/0/2 ge-0/0/2 Index: 107 1.1.1.37/30 1.1.1.38/30 Index: 109
18, 17 IPv4
BGP SR-TE - Controller configs and Config for advertise Payload Prefix
BGP Config with the BGP Controller: Payload Prefix advertisement on Endpoint Router (R9):
protocols { policy-options {
bgp { policy-statement Ingress_Route {
group Controller-1 { term Ingress_Route {
type external; from {
neighbor 5.5.5.2 { protocol direct;
family inet { route-filter 3.3.3.8/30 exact; <<< Payload Prefix
segment-routing-te; <<< Enables SR-TE Policy SAFI and NRLI }
} then {
peer-as 500; community add Color;
local-as 100; next-hop 192.168.1.9;
} accept;
} }
group Controller-2 { }
type external; }
neighbor 6.6.6.2 { community Color members color:2:100;
family inet { }
segment-routing-te; <<< Enables SR-TE Policy SAFI and NRLI protocols {
} bgp {
peer-as 600; group R1-R9 {
local-as 100; type internal;
} local-address 192.168.1.9;
} family inet {
} unicast {
} extended-nexthop-color; <<< Optional, Used for lookup in
} inetcolor.0 table (color resolution)
}
neighbor 192.168.1.1 {
export Ingress_Route;
}
}
}
}

BGP SR-TE - Lab Verification
root@R1> show bgp summary
Threading mode: BGP I/O
Groups: 6 Peers: 6 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
. . .
bgp.inetsrte.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
5.5.5.2 500 72 73 0 0 33:21 Establ <<< Towards BGP Controller 1, Receiving BGP Policy
bgp.inetsrte.0: 1/1/1/0
6.6.6.2 600 72 73 0 0 33:21 Establ <<< Towards BGP Controller 2, Receiving BGP Policy
bgp.inetsrte.0: 1/1/1/0
. . .
192.168.1.9 100 76 75 0 0 33:23 Establ <<< Towards R9, Receiving Payload Prefix
inet.0: 1/1/1/0
. . .
root@R1> show bgp neighbor 5.5.5.2 root@R1> show bgp neighbor 6.6.6.2
Peer: 5.5.5.2+61031 AS 500 Local: 5.5.5.1+179 AS 100 Peer: 6.6.6.2+55269 AS 600 Local: 6.6.6.1+179 AS 100
Group: Controller-1 Routing-Instance: master Group: Controller-2 Routing-Instance: master
. . . . . .
Address families configured: inet-segment-routing-te Address families configured: inet-segment-routing-te
. . . . . .
NLRI for restart configured on peer: inet-segment-routing-te NLRI for restart configured on peer: inet-segment-routing-te
NLRI advertised by peer: inet-segment-routing-te NLRI advertised by peer: inet-segment-routing-te
NLRI for this session: inet-segment-routing-te NLRI for this session: inet-segment-routing-te
. . . . . .
Table bgp.inetsrte.0 Table bgp.inetsrte.0
. . . . . .
Active prefixes: 1 Active prefixes: 1
Received prefixes: 1 Received prefixes: 1
Accepted prefixes: 1 Accepted prefixes: 1
. . . . . .
root@R1> root@R1>

BGP SR-TE - Lab Verification Cont…
root@R1> show route receive-protocol bgp 5.5.5.2 root@R1> show route table bgp.inetsrte.0
. . .
mpls.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden) bgp.inetsrte.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path + = Active Route, - = Last Active, * = Both
* 1000001
. . . 10-192.168.1.9-100<sr>/96
bgp.inetsrte.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) *[BGP/170] 00:05:00, localpref 100
Prefix Nexthop MED Lclpref AS path AS path: 500 I, validation-state: unverified
10-192.168.1.9-100<sr>/96 > to 5.5.5.2 via ge-0/0/7.0
* 5.5.5.2 500 I 20-192.168.1.9-100<sr>/96
*[BGP/170] 00:05:00, localpref 100
inetcolor.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden) AS path: 600 I, validation-state: unverified
Prefix Nexthop MED Lclpref AS path > to 6.6.6.2 via ge-0/0/8.0
192.168.1.9-100<c>/64 <<< Distinguisher (10) is dropped as soon as route moves to inetcolor.0.
* 5.5.5.2 500 I root@R1> show route match-prefix 192.168.1.9-100<c>/64 table inetcolor.0
root@R1> show route receive-protocol bgp 6.6.6.2 inetcolor.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)
. . . + = Active Route, - = Last Active, * = Both
192.168.1.9-100<c>/64 <<< Distinguisher is dropped as soon as route moves to inetcolor.0.
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) *[BGP/170] 00:05:04, localpref 100, from 5.5.5.2
. . . AS path: 500 I, validation-state: unverified
bgp.inetsrte.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) > to 1.1.1.6 via ge-0/0/1.0, Push 17, Push 18, Push 28(top)
Prefix Nexthop MED Lclpref AS path to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top)
20-192.168.1.9-100<sr>/96 to 1.1.1.2 via ge-0/0/0.0, Push 24, Push 19, Push 18(top)
* 6.6.6.2 600 I [BGP/170] 00:05:04, localpref 100, from 6.6.6.2
inetcolor.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden) > to 1.1.1.6 via ge-0/0/1.0, Push 17, Push 18, Push 28(top)
Prefix Nexthop MED Lclpref AS path to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top)
192.168.1.9-100<c>/64 <<< Distinguisher (20) is dropped as soon as route moves to inetcolor.0. to 1.1.1.2 via ge-0/0/0.0, Push 24, Push 19, Push 18(top)
6.6.6.2 600 I
root@R1>
root@R1>

root@R1> show route label 1000001 table mpls.0 <<< Next-hop is picked from inetcolor.0 table Why the Binding SID is not getting swap with the top label?

Let's take example of segment-list (27 (top), 28, 18, 17 (bottom)). BSID
label indicates the destination of the incoming packet and in the
1000001 *[BGP/170] 00:04:52, localpref 100, from 5.5.5.2 incoming packet BSID is the topmost label, so BSID is supposed to be
> to 1.1.1.6 via ge-0/0/1.0, Swap 17, Push 18, Push 28(top) swapped with the destination label, Label 17 which is the innermost
to 1.1.1.46 via ge-0/0/4.0, Swap 6109, Push 16(top) label of stack. Also as you know top label (27) is representing
to 1.1.1.2 via ge-0/0/0.0, Swap 24, Push 19, Push 18(top)
immediate next hop it does not appear in the label stack on the packet
root@R1> show route receive-protocol bgp 192.168.1.9 and that is why it is not listed in the command.
Prefix Nexthop MED Lclpref AS path Opposite to this is payload prefixes which has all push operation as
* 3.3.3.8/30 192.168.1.9 100 I there is no label swap.
. . .
root@R1> show route 3.3.3.8/30 <<< Next-hop is picked from inetcolor.0 table root@R1> show route 192.168.1.9/32 table inet.0
If next-hop is not found in inetcolor.0 or
inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden) inet6color.0 then route inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both remains hidden + = Active Route, - = Last Active, * = Both
3.3.3.8/30 *[BGP/170] 00:04:52, localpref 100, from 192.168.1.9 192.168.1.9/32 *[L-ISIS/14] 1w2d 10:16:15, metric 40
AS path: I, validation-state: unverified > to 1.1.1.2 via ge-0/0/0.0, Push 4109
> to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top) to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.6 via ge-0/0/1.0, Push 17, Push 18, Push 28(top) to 1.1.1.46 via ge-0/0/4.0, Push 3109
to 1.1.1.2 via ge-0/0/0.0, Push 24, Push 19, Push 18(top) [IS-IS/18] 1w2d 10:16:15, metric 40
> to 1.1.1.2 via ge-0/0/0.0
root@R1> to 1.1.1.6 via ge-0/0/1.0
to 1.1.1.46 via ge-0/0/4.
root@R1>

root@R1> show route forwarding-table label 1000001 root@R1> start shell command "cprod -A fpc0 -c \"show nhdb id 1048589 recursive\""
Routing table: default.mpls
MPLS: 1048589(Unilist, IPv4, ifl:0:-, pfe-id:0)
Destination Type RtRef Next hop Type Index NhRef Netif 525(Compst, MPLS, ifl:0:-, pfe-id:0, comp-fn:Chain)
1000001 user 0 ulst 1048589 2 1048574(Indirect, MPLS, ifl:326:ge-0/0/1.0, pfe-id:0, i-ifl:0:-)
comp 525 2 651(Unicast, MPLS, ifl:326:ge-0/0/1.0, pfe-id:0)
comp 526 2 526(Compst, MPLS, ifl:0:-, pfe-id:0, comp-fn:Chain)
comp 527 2 1048585(Indirect, MPLS, ifl:336:ge-0/0/4.0, pfe-id:0, i-ifl:0:-)
. . . 685(Unicast, IPv4, ifl:336:ge-0/0/4.0, pfe-id:0)
root@R1> show route forwarding-table destination 3.3.3.8/30 527(Compst, MPLS, ifl:0:-, pfe-id:0, comp-fn:Chain)
Routing table: default.inet 1048586(Indirect, MPLS, ifl:324:ge-0/0/0.0, pfe-id:0, i-ifl:0:-)
Internet: 686(Unicast, IPv4, ifl:324:ge-0/0/0.0, pfe-id:0)
Enabled protocols: Bridging,
Destination Type RtRef Next hop Type Index NhRef Netif root@R1> start shell command "cprod -A fpc0 -c \"show nhdb id 528 recursive\""
3.3.3.8/30 user 0 comp 528 2
. . . 528(Compst, IPv4, ifl:0:-, pfe-id:0, comp-fn:Chain)
root@R1> 1048588(Indirect, IPv4, ifl:0:-, pfe-id:0, i-ifl:0:-)
512(Compst, IPv4->MPLS, ifl:0:-, pfe-id:0, comp-fn:Chain)
685(Unicast, IPv4, ifl:336:ge-0/0/4.0, pfe-id:0)
651(Unicast, MPLS, ifl:326:ge-0/0/1.0, pfe-id:0)
686(Unicast, IPv4, ifl:324:ge-0/0/0.0, pfe-id:0)
root@R1>

root@R1> show route receive-protocol bgp 5.5.5.2 extensive . . .
. . . inetcolor.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)
* 1000001 (1 entry, 1 announced) * 192.168.1.9-100<c>/64 (2 entries, 1 announced)
. . . Accepted
bgp.inetsrte.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) SR Policy Color: 100
SR Policy Endpoint: 192.168.1.9
* 10-192.168.1.9-100<sr>/96 (1 entry, 0 announced) SRTE Policy State
Accepted SR Preference/Override: 0/100
SR Policy Distinguisher: 10 BSID: 1000001
SR Policy Color: 100 Nexthop: 5.5.5.2
SR Policy Endpoint: 192.168.1.9 AS path: 500 I
Nexthop: 5.5.5.2 Communities: target:192.168.1.1:1 color:0:0
AS path: 500 I SRTE Policy State
Communities: target:192.168.1.1:1 color:0:0 Path preference: 0
SRTE Policy Path: Binding-SID: 1000001
Path preference: 0 Segment list:
Binding-SID: 1000001 Weight: 20
Segment list: Label: 27 ttl: Local-ttl-policy
Weight: 20 Label: 28 ttl: Local-ttl-policy
Label: 27 ttl: Local-ttl-policy Label: 18 ttl: Local-ttl-policy
Label: 18 ttl: Local-ttl-policy Segment list:
Label: 17 ttl: Local-ttl-policy Weight: 30
Label: 24 ttl: Local-ttl-policy root@R1>

. . . inetcolor.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)
192.168.1.9-100<c>/64 (2 entries, 1 announced)
. . . Accepted
bgp.inetsrte.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) SR Policy Color: 100
SR Policy Endpoint: 192.168.1.9
* 20-192.168.1.9-100<sr>/96 (1 entry, 0 announced) SRTE Policy State
Accepted SR Preference/Override: 0/100
SR Policy Distinguisher: 20 BSID: 1000001
SR Policy Color: 100 Nexthop: 6.6.6.2
SR Policy Endpoint: 192.168.1.9 AS path: 600 I
Nexthop: 6.6.6.2 Communities: target:192.168.1.1:1 color:0:0
AS path: 600 I SRTE Policy State
Communities: target:192.168.1.1:1 color:0:0 Path preference: 0
SRTE Policy State Binding-SID: 1000001
Path preference: 0 Segment list:
Binding-SID: 1000001 Weight: 20
Label: 24 ttl: Local-ttl-policy root@R1>

. . .
root@R1> show route table bgp.inetsrte.0 extensive
20-192.168.1.9-100<sr>/96 (1 entry, 0 announced)
bgp.inetsrte.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
SRTE Policy State
10-192.168.1.9-100<sr>/96 (1 entry, 0 announced)
Path preference: 0
Binding-SID: 1000001
SRTE Policy State
Segment list:
Path preference: 0
Weight: 20
Segment list:
Weight: 20
Segment list:
Weight: 30
Segment list:
Weight: 30
Segment list:
Weight: 50
Segment list:
Weight: 50
Next hop type: Fictitious, Next hop index: 0
. . .
Next hop: 6.6.6.2
Next hop type: Fictitious, Next hop index: 0
State: <Active Ext>
. . .
. . .
Next hop: 5.5.5.2
Task: BGP_600.6.6.6.2
State: <Active Ext>
AS path: 600 I
. . .
Communities: target:192.168.1.1:1 color:0:0
Task: BGP_500.5.5.5.2
Accepted
AS path: 500 I
Localpref: 100
Communities: target:192.168.1.1:1 color:0:0
Router ID: 192.168.1.200
Accepted
Localpref: 100
root@R1>
Router ID: 192.168.1.100
BGP SR-TE - Lab Verification Cont… . . .
root@R1> show route match-prefix 192.168.1.9-100<c>/64 table inetcolor.0 extensive
. . .
Balance: 30%
. . .
192.168.1.9-100<c>/64 (2 entries, 1 announced)
SRTE Policy State
. . .
Path preference: 0
Balance: 50%
. . .
Segment list:
SRTE Policy State
Weight: 20
BSID: 1000001
Localpref: 100
Router ID: 192.168.1.100
Composite next hops: 3
Segment list:
Protocol next hop: 27 Metric: 0
Weight: 30
. . .
Segment list:
Next hop: 1.1.1.6 via ge-0/0/1.0
Weight: 50
. . .
. . .
Next hop type: Indirect, Next hop index: 0
. . .
Next hop: 1.1.1.46 via ge-0/0/4.0
Source: 5.5.5.2
. . .
. . .
. . .
. . .
Balance: 20%
Next hop: 1.1.1.2 via ge-0/0/0.0
. . .

. . .
Balance: 30%
. . .
. . .
BGP Preference: 170/-101
SRTE Policy State
. . .
Path preference: 0
Balance: 50%
. . .
Segment list:
SRTE Policy State
Weight: 20
BSID: 1000001
Localpref: 100
Router ID: 192.168.1.200
Segment list:
Weight: 30
. . .
Segment list:
Next hop: 1.1.1.6 via ge-0/0/1.0
Weight: 50
. . .
. . .
Next hop type: Indirect, Next hop index: 0
. . .
Next hop: 1.1.1.46 via ge-0/0/4.0
Source: 6.6.6.2
. . .
. . .
. . .
. . .
Balance: 20%
Next hop: 1.1.1.2 via ge-0/0/0.0
. . .
root@R1>
First Label representing first hop should be resolved in
BGP SR-TE - Lab Verification Cont… the mpls.0. Otherwise policy will not be active.
root@R1> show route label 1000001 table mpls.0 extensive <<< Next-hop is picked from
inetcolor.0 table mpls.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden)
1000001 (1 entry, 1 announced) <<< BSID (or complete SR-TE Policy) resolves over Top label as it
TSI: points to the next hop. 27 *[L-ISIS/14] 1w4d 09:40:46, metric 0
KRT in-kernel 1000001/52 -> {list:composite(512), composite(513), composite(524)} > to 1.1.1.6 via ge-0/0/1.0, Pop
*BGP Preference: 170/-101 27(S=0) *[L-ISIS/14] 00:08:51, metric 0
Next hop type: Indirect, Next hop index: 0 > to 1.1.1.6 via ge-0/0/1.0, Pop
. . .
Source: 5.5.5.2 root@R1>
. . .
. . .
Localpref: 100
Router ID: 192.168.1.100
. . .
Balance: 20%
. . .
. . .
. . .
Balance: 30%
Next hop: 1.1.1.6 via ge-0/0/1.0
. . .
. . .
. . .
. . .
Balance: 50%
. . .
Next hop: 1.1.1.46 via ge-0/0/4.0
. . .
. . .
Next hop: 1.1.1.2 via ge-0/0/0.0
. . .
root@R1>
Next hop: 1.1.1.46 via ge-0/0/4.0
Next hop: ELNH Address 0xba2d610 weight 0x1 balance 20%
inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden) Next hop type: Chain, Next hop index: 526
* 3.3.3.8/30 (1 entry, 1 announced) . . .
Accepted Label operation: Push 17, Push 18, Push 28(top)
Nexthop: 192.168.1.9 . . .
Localpref: 100 Next hop: 1.1.1.6 via ge-0/0/1.0
AS path: I . . .
Communities: color:2:100 Next hop: ELNH Address 0xba2ac70 weight 0x1 balance 50%
. . . Next hop type: Chain, Next hop index: 527
root@R1> show route 3.3.3.8/30 extensive <<< Next-hop is picked from inetcolor.0 table . . .
inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden) . . .
3.3.3.8/30 (1 entry, 1 announced) Next hop: 1.1.1.2 via ge-0/0/0.0
TSI: . . .
KRT in-kernel 3.3.3.8/30 -> {composite(528)} Protocol next hop: 192.168.1.9-100<c>
Page 0 idx 0, (group Northstar type External) Type 1 val 0xbaa47fc (adv_entry) . . .
Advertised metrics: Communities: color:2:100
Flags: Nexthop Change Accepted
Nexthop: Not advertised Localpref: 100
AS path: [100] I Router ID: 192.168.1.9
Communities: color:2:100 Composite next hops: 1
Label: Protocol next hop: 192.168.1.9-100<c> Metric: 10
Path 3.3.3.8 Composite next hop: 0xcfa6820 528 INH Session ID: 0x0
from 192.168.1.9 Indirect next hop: 0xccdf740 1048589 INH Session ID: 0x0
Vector len 4. Val: 0 Indirect path forwarding next hops (Merged): 3
*BGP Preference: 170/-101 Next hop type: List
Next hop type: Indirect, Next hop index: 0 Next hop: 1.1.1.46 via ge-0/0/4.0
. . . Label operation: Push 6109, Push 16(top)
Source: 192.168.1.9 Next hop: 1.1.1.6 via ge-0/0/1.0
. . . Label operation: Push 17, Push 18, Push 28(top)
Next hop: ELNH Address 0xba250f0 weight 0x1 balance 30%, selected Next hop: 1.1.1.2 via ge-0/0/0.0
Next hop type: Chain, Next hop index: 525 Label operation: Push 24, Push 19, Push 18(top)
. . . 192.168.1.9-100
. . . root@R1>
root@R1> show route forwarding-table label 1000001 extensive root@R1> show route forwarding-table destination 3.3.3.8 extensive
Routing table: default.mpls [Index 0] Routing table: default.inet [Index 0]
MPLS: Internet:
Enabled protocols: Bridging,
Destination: 1000001
Route type: user Destination: 3.3.3.8/30
Route reference: 0 Route interface-index: 0 Route type: user
Multicast RPF nh index: 0 Route reference: 0 Route interface-index: 0
P2mpidx: 0 Multicast RPF nh index: 0
Flags: sent to PFE, rt nh decoupled P2mpidx: 0
Next-hop type: unilist Index: 1048589 Reference: 2 Flags: sent to PFE
Nexthop: Nexthop:
Next-hop type: composite Index: 525 Reference: 2 Next-hop type: composite Index: 528 Reference: 2
Load Balance Label: Swap 17, Push 18, Push 28(top), None Next-hop type: indirect Index: 1048588 Reference: 2
Next-hop type: indirect Index: 1048574 Reference: 2 Next-hop type: unilist Index: 1048587 Reference: 2
Weight: 0x1 Nexthop:
Nexthop: 1.1.1.6 Next-hop type: composite Index: 512 Reference: 2
Next-hop type: unicast Index: 651 Reference: 3 Load Balance Label: Push 6109, Push 16(top), None
Next-hop interface: ge-0/0/1.0 Weight: 0x1 Nexthop: 1.1.1.46
Nexthop: Next-hop type: unicast Index: 685 Reference: 3
Next-hop type: composite Index: 526 Reference: 2 Next-hop interface: ge-0/0/4.0 Weight: 0x1
Load Balance Label: Swap 6109, Push 16(top), None Nexthop:
Next-hop type: indirect Index: 1048585 Reference: 2 Next-hop type: composite Index: 513 Reference: 2
Weight: 0x1 Load Balance Label: Push 17, Push 18, Push 28(top), None
Nexthop: 1.1.1.46 Nexthop: 1.1.1.6
Next-hop type: unicast Index: 685 Reference: 3 Next-hop type: unicast Index: 651 Reference: 3
Next-hop interface: ge-0/0/4.0 Weight: 0x1 Next-hop interface: ge-0/0/1.0 Weight: 0x1
Nexthop: Nexthop:
Next-hop type: composite Index: 527 Reference: 2 Next-hop type: composite Index: 524 Reference: 2
Load Balance Label: Swap 24, Push 19, Push 18(top), None Load Balance Label: Push 24, Push 19, Push 18(top), None
Next-hop type: indirect Index: 1048586 Reference: 2 Nexthop: 1.1.1.2
Weight: 0x1 Next-hop type: unicast Index: 686 Reference: 3
Nexthop: 1.1.1.2 Next-hop interface: ge-0/0/0.0 Weight: 0x1
Next-hop type: unicast Index: 686 Reference: 3 . . .
Next-hop interface: ge-0/0/0.0 Weight: 0x1 root@R1>
. . .
root@R1>
STATIC LSP & STATIC SEGMENTS

Static Colored LSP
In static provisioning, a colored SR LSP is created on ingress routers by configuration. A static SR LSP configured as below is called a “colored” SR LSP,
because it has the notion of “color”, which aligns with BGP SR policy. Like a BGP SR policy, its ingress route is installed in resolution RIB inetcolor.0 or
inet6color.0 with <destination IP address, color> as key. IP traffic is mapped to the SR LSP by the resolver based on destination and color. Tunnels are
distinguished using color.
protocols {
segment-list <segment_list_name> { <<< A segment list must have >= 1 hop.
<hop_1_name> label <sid_label>;
<hop_2_name> label <sid_label>;
. . .
<hop_n_name> label <sid_label>;
}
source-routing-path <lsp_name> {
to <address>; <<< DA will be reflected in inet.3 table, unless the “no-ingress” knob is configured.
color <value>; Color LSP and lookup will happen in inetcolor.0 by configuring “extended-nexthop-color” knob.
no-ingress; <<< Disables the ingress route installation (e.g. in the case where it is used purely for LSP stitching)
binding-sid <label>; <<< Binding SID is an incoming label for the incoming labelled traffic or Binding SID can be
preference <value>; used if you are using this LSP for stitching. A route for the binding-sid label is installed in mpls.0.
metric <value>;
primary {
<segment_list_1> weight <weight_1>; <<< Weight for WECMP
}
. . .
primary {
<segment_list_n> weight <weight_n>; <<< A colored static SR LSP may have maximum 8 primary paths. ECMP, if all the primary paths have equal weight.
} WECMP, if the primary paths have different weights. Require per-packet load balancing policy.
secondary { <<< The secondary path comes in to the picture when all the primary path goes down. The secondary path has a
<segment_list>; nexthop weight of 0xff. Require per-packet load balancing policy to download secondary path to PFE.
}
}
}
}

Static Non-Colored LSP
In static provisioning, a non-colored SR LSP is created on ingress routers by configuration. For a segment-list to be used by a non-colored static SR LSP, its
1st hop must specify the immediate nexthop IP address in order to resolve an outgoing interface. RLI 37610 changes this behavior (through inherit-
label-nexthops knob) and we can configure SID label (outgoing interface resolved in the mpls.0 table) as first hop as well. The 2nd to Nth hops must
specify SID labels. Since the color is not defined, route is programmed in inet.3 and it can compete with RSVP/LDP based on the preference value set in
“set protocols source-path-routing preference”. Static non-colored LSP is similar to the LSP provisioned through PCEP.
protocols {
segment-list <segment_list_name> { <<< A segment list must have >= 1 hop.
<hop_1_name> ip_address <address> | label <sid_label>; <<< Hop 1 can be a loose hop
<hop_2_name> label <sid_label>; <<< Hop 2 to Hop n can only be a strict hop as we have already defined labels
. . .
<hop_n_name> label <sid_label>;
}
source-routing-path <lsp_name> { <<< The “color” knob is not applicable and should not be configured.
to <address>; <<< Destination address will be reflected in inet.3 table, unless the “no-ingress” knob is configured.
no-ingress; <<< Disables the ingress route installation (e.g. in the case where it is used purely for LSP stitching)
binding-sid <label>; <<< Binding SID is an incoming label for the incoming labelled traffic or Binding SID can be
preference <value>; used if you are using this LSP for stitching. A route for the binding-sid label is installed in mpls.0.
metric <value>;
primary {
<segment_list_1> weight <weight_1>; <<< Weight for WECMP
}
. . .
primary {
<segment_list_n> weight <weight_n>; <<< A non-colored static SR LSP may have maximum 8 primary paths. ECMP, if all the primary paths have equal
} weight. WECMP, if the primary paths have different weights. Require per-packet load balancing policy.
secondary { <<< The secondary path comes in to the picture when all the primary path goes down. The secondary path has a
<segment_list>; nexthop weight of 0xff. Require per-packet load balancing policy to download secondary path to PFE.
}
}
inherit-label-nexthops; <<< Optional knob, If you want to configure first hop as label in the segment list.
}
}
Static Non-Colored LSP Cont…
In this presentation, we have taken example of non-colored LSP having label as first hop (through “inherit-label-nexthops” knob).
Ingress route in inet.3 allows services to be mapped to a non-colored static SR LSP as a transport tunnel, in the same manner as traditional RSVP and LDP
LSPs. All Tunnels to same destination are combined and placed as nexthops to the destination. Tunnels are distinguished using names.
A non-colored SR LSP may have a binding-SID label to achieve SR LSP stitching. The transit routes of the binding-SID label have a protocol of SPRING-TE,
and by default, a preference of 8 and a metric of 1.
Ingress route (in inet.0):

Endpoint route (in inet.3):

[L-ISIS/14] 1w1d 08:49:30, metric 40
> to 1.1.1.2 via ge-0/0/0.0, Push 4109 Binding-SID route (in mpls.0):
to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.46 via ge-0/0/4.0, Push 3109
1000001 *[SPRING-TE/6] 00:24:20, metric 30, metric2 0
> to 1.1.1.6 via ge-0/0/1.0, Swap 17, Push 18, Push 28(top)
to 1.1.1.46 via ge-0/0/4.0, Swap 6109, Push 16(top)

Static Non-Colored LSP: inherit-label-nexthops knob
The newly added knob “inherit-label-nexthops” is an optional knob. It inherits label nexthops for first hop in this segment
list.
If the “inherit-label-nexthops” knob is turned ON under “source-packet-routing” hierarchy then if any of the
underlying segment list doesn’t have this knob ON and if that has both ip and label configured; this global knob will decide the
resolution type. If the underlying segment list has also the knob; the one there will take effect than the global knob. If different
segment lists of a tunnel have different first hop resolution type; then the commit will be failed.
If the knob is not present; the default behavior will be to use the ip-address if the first hop has both ip and label specified.
• 1st hop only ip-address: ip-direct will be the mode of segment list resolution.
• 1st hop only label: label resolution will be the mode of segment list resolution.
• Both ip-address and label: Without “inherit-label-nexthops”, ip-direct will be the mode of segment list resolution.
• Both ip-address and label: With “inherit-label-nexthops”, label resolution will be the mode of segment list resolution.

Static Non-Colored LSP: inherit-label-nexthops knob Cont…
IP-direct will be the type of the segment list. Label resolution will be the type of the segment list.
source-packet-routing { source-packet-routing {
segment-list path-1 { segment-list path-2 {
hop-1 ip-address 3.3.3.3; hop-1 label 1000011;
hop-2 label 1000012; hop-2 label 1000012;
} }
} }
} }
IP-direct will be the type of the segment list. Label resolution will be the type of the segment list.
source-packet-routing { source-packet-routing {
segment-list path-3 { segment-list path-3 {
hop1 { inherit-label-nexthops;
label 1000011; hop1 {
ip-address 3.3.3.3; label 1000011;
} ip-address 3.3.3.3;
hop-2 label 1000012; }
} hop-4 label 1000014;
} }
} }
}
Static LSP - Traffic steering in the LSP through CBF and PBF
A static colored SR LSP may have a binding SID, for which a route will be installed in the mpls.0 table. This binding SID label is
used to map labeled traffic to the SR LSP. Traffic may also be mapped to a static colored SR LSP by using class-based forwarding
(CBF) or routing policies with an “install-nexthop” action.
Class Based Forwarding (CBF) example: Policy Based Forwarding (PBF) example:
class-of-service { policy-options {
forwarding-policy { policy-statement <policy-name> {
next-hop-map <map_name> { term <term-name> {
forwarding-class <class_name> { from {
lsp-next-hop <sr_lsp_ame>; <matching condition>
} }
} then {
} install-nexthop (except | lsp <sr-lsp-name> | lsp-regex <sr-lsp-regular-expression>);
} }
policy-options { }
policy-statement <policy-name> { }
term <term-name> { }
from { routing-options {
<matching condition> forwarding-table {
} export <policy-name>;
then <map_name>; }
} }
}
}
routing-options {
forwarding-table {
export <policy-name>;
}
}

Static LSP - Installing multiple segment list next-hops
To install multiple segment list next-hops, you need to configure the below policy:
policy-options {
policy-statement mpath {
then multipath-resolve;
}
}
routing-options {
resolution {
rib inet.0 {
inet-import mpath; <<< For Non-color LSPs
inetcolor-import mpath; <<< For color LSPs
}
}
}
Other variants:
set policy-options policy-statement mpath then multipath-resolve

set routing-options resolution rib inet.0 inet-import mpath
set routing-options resolution rib inet.0 inetcolor-import mpath
set routing-options resolution rib inet6.0 inet6-import mpath
set routing-options resolution rib inet6.0 inet6color-import mpath
set routing-options resolution rib l2circuit.0 inet-import mpath
set routing-options resolution rib bgp.l3vpn.0 inet-import mpath
set routing-options resolution rib bgp.l3vpn-inet6.0 inet6-import mpath
set routing-options resolution rib bgp.l2vpn.0 inet-import mpath
set routing-options resolution rib mpls.0 inet-import mpath
set routing-options resolution rib mpls.0 inet6-import mpath
Static Colored/Non-Colored LSP Configuration
Colored LSP Example: Non-Colored LSP Example: Ingress Route advertisement on Egress Router:
protocols { protocols { policy-options {
source-packet-routing { source-packet-routing { policy-statement Ingress_Route {
lsp-external-controller pccd; lsp-external-controller pccd; term Ingress_Route {
preference 6; preference 6; from {
sr-preference-override 100; sr-preference-override 100; protocol direct;
maximum-segment-list-depth 5; maximum-segment-list-depth 5; route-filter 3.3.3.8/30 exact;
segment-list R1-R2-R5-R7-R9 { segment-list R1-R2-R5-R7-R9 { }
R1-R2-Adj-SID label 27; R1-R2-Adj-SID label 27; <<< It can be 1.1.1.6 if we dont use then {
R2-R5-Adj-SID label 28; R2-R5-Adj-SID label 28; inherit-label-nexthops community add Color; <<< Remove community
R5-R7-Adj-SID label 18; R5-R7-Adj-SID label 18; next-hop 192.168.1.9; for Non-color LSP
R7-R9-Adj-SID label 17; R7-R9-Adj-SID label 17; accept;
} } }
segment-list R1-R3-R6-R8-R9 { segment-list R1-R3-R6-R8-R9 { }
R1-R3-Adj-SID label 28; R1-R3-Adj-SID label 28; <<< It can be 1.1.1.46 if we dont use }
R3-R6-Adj-SID label 16; R3-R6-Adj-SID label 16; inherit-label-nexthops community Color members color:2:100; <<< Remove
Node-SID-of-R9-at-R6 label 6109; <<< Loose Node-SID-of-R9-at-R6 label 6109; <<< Loose Hop community
Hop } } for Non-color LSP
} segment-list R1-R4-R6-R8-R9 { protocols {
segment-list R1-R4-R6-R8-R9 { Node-SID-of-R4-at-R1 label 1104; <<< Loose Hop; bgp {
Node-SID-of-R4-at-R1 label 1104; <<< Loose It can group R1-R9 {
Hop R4-R6-Adj-SID-Link-1 label 18; be 1.1.1.2 if we type internal;
R4-R6-Adj-SID-Link-1 label 18; R6-R8-Adj-SID label 19; dont use local-address 192.168.1.9;
R6-R8-Adj-SID label 19; R8-R9-Adj-SID label 24; inherit- family inet {
R8-R9-Adj-SID label 24; } label- unicast {
} source-routing-path R1-R9-LSP { nexthops extended-nexthop-color; <<< Used for
source-routing-path R1-R9-LSP { to 192.168.1.9; lookup in
to 192.168.1.9; binding-sid 1000001; } inetcolor.0 table
color 100; metric 30; }
binding-sid 1000001; primary { neighbor 192.168.1.1 {
metric 30; R1-R2-R5-R7-R9 weight 20; export Ingress_Route;
primary { R1-R3-R6-R8-R9 weight 30; }
R1-R2-R5-R7-R9 weight 20; R1-R4-R6-R8-R9 weight 50; }
R1-R3-R6-R8-R9 weight 30; } }
R1-R4-R6-R8-R9 weight 50; } }
} inherit-label-nexthops;
} }
} }
}

Static Colored LSP - Traceroute Example of all three segments
Only segment 1 is active: Only segment 3 is active:
1 1.1.1.6 (1.1.1.6) 4.293 ms 9.628 ms 4.479 ms
1 1.1.1.2 (1.1.1.2) 6.591 ms 37.017 ms 9.435 ms
2 1.1.1.10 (1.1.1.10) 6.393 ms 7.177 ms 5.431 ms
2 1.1.1.18 (1.1.1.18) 13.620 ms 17.250 ms 7.560 ms
3 1.1.1.26 (1.1.1.26) 6.466 ms 31.924 ms 83.799 ms
3 1.1.1.30 (1.1.1.30) 17.215 ms 12.156 ms 9.625 ms
4 3.3.3.10 (3.3.3.10) 17.574 ms 21.026 ms 11.214 ms
4 3.3.3.10 (3.3.3.10) 18.196 ms 31.568 ms 48.029 ms
root@R1>
Only segment 2 is active: root@R1>

1 1.1.1.46 (1.1.1.46) 23.130 ms 4.306 ms 8.516 ms
2 1.1.1.49 (1.1.1.49) 10.430 ms 15.007 ms 3.985 ms
3 1.1.1.34 (1.1.1.34) 7.878 ms 19.184 ms 7.228 ms
4 3.3.3.10 (3.3.3.10) 8.208 ms 15.638 ms 26.114 ms
root@R1>
Note: The traceroute outputs
are same for Non-Colored LSPs
Static Colored LSP command outputs
root@R1> show spring-traffic-engineering lsp detail . . .
Name: R1-R9-LSP Path: R1-R4-R6-R8-R9
Tunnel-source: Static configuration Outgoing interface: NA
To: 192.168.1.9-100<c> <<< In Non-Color LSP, Color “100<c>” is not present. Auto-translate status: Disabled Auto-translate result: N/A
State: Up BFD status: N/A BFD name: N/A
Path: R1-R2-R5-R7-R9 SR-ERO hop count: 4
Outgoing interface: NA Hop 1 (Strict):
Auto-translate status: Disabled Auto-translate result: N/A NAI: None
BFD status: N/A BFD name: N/A SID type: 20-bit label, Value: 1104
SR-ERO hop count: 4 Hop 2 (Strict):
Hop 1 (Strict): NAI: None
NAI: None SID type: 20-bit label, Value: 18
SID type: 20-bit label, Value: 27 Hop 3 (Strict):
Hop 4 (Strict):
NAI: None Total displayed LSPs: 1 (Up: 1, Down: 0)
Path: R1-R3-R6-R8-R9 root@R1>
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
Hop 2 (Strict):
NAI: None
Hop 3 (Strict):
NAI: None
. 2018
Static Colored LSP command outputs Cont…
root@R1> show route label 1000001 table mpls.0 root@R1> show route 192.168.1.9/32
mpls.0: 48 destinations, 49 routes (48 active, 0 holddown, 0 hidden) inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)
1000001 *[SPRING-TE/6] 00:02:26, metric 30, metric2 0 192.168.1.9/32 *[L-ISIS/14] 1w1d 03:43:26, metric 40
> to 1.1.1.6 via ge-0/0/1.0, Swap 17, Push 18, Push 28(top) > to 1.1.1.2 via ge-0/0/0.0, Push 4109
to 1.1.1.46 via ge-0/0/4.0, Swap 6109, Push 16(top) to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.2 via ge-0/0/0.0, Swap 24, Push 19, Push 18(top) to 1.1.1.46 via ge-0/0/4.0, Push 3109
[IS-IS/18] 1w1d 03:43:26, metric 40
root@R1> show route 3.3.3.8/30 > to 1.1.1.2 via ge-0/0/0.0
to 1.1.1.6 via ge-0/0/1.0
inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden) to 1.1.1.46 via ge-0/0/4.0
3.3.3.8/30 *[BGP/170] 00:02:26, localpref 100, from 192.168.1.9 + = Active Route, - = Last Active, * = Both
> to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top) 192.168.1.9/32 *[L-ISIS/14] 1w1d 03:43:26, metric 40
to 1.1.1.6 via ge-0/0/1.0, Push 17, Push 18, Push 28(top) > to 1.1.1.2 via ge-0/0/0.0, Push 4109
to 1.1.1.2 via ge-0/0/0.0, Push 24, Push 19, Push 18(top) to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.46 via ge-0/0/4.0, Push 3109
root@R1>
root@R1> show route match-prefix 192.168.1.9-100<c>/64 table inetcolor.0

192.168.1.9-100<c>/64
*[SPRING-TE/6] 00:02:26, metric 30, metric2 0
root@R1>

Static Colored LSP command outputs Cont…
root@R1> show route match-prefix 192.168.1.9-100<c>/64 table inetcolor.0 extensive . . .
SRTE Policy State
inetcolor.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) SR Preference/Override: 100/100
192.168.1.9-100<c>/64 (1 entry, 1 announced) BSID: 1000001
*SPRING-TE Preference: 6 Composite next hops: 3
. . . Protocol next hop: 27 Metric: 0
Protocol next hop: 27 . . .
Label operation: Push 17, Push 18, Push 28(top) Load balance label: Label 17: None; Label 18: None;
Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Label 28: None;
Load balance label: Label 17: None; Label 18: None; Label 28: None; . . .
Balance: 20% Indirect path forwarding next hops: 1
. . . Next hop type: Router
Protocol next hop: 28 Next hop: 1.1.1.6 via ge-0/0/1.0
Label operation: Push 6109, Push 16(top) . . .
Label TTL action: prop-ttl, prop-ttl(top) Protocol next hop: 28 Metric: 0
Load balance label: Label 6109: None; Label 16: None; . . .
Balance: 30% Load balance label: Label 6109: None; Label 16: None;
. . . . . .
Protocol next hop: 1104 Indirect path forwarding next hops: 1
Label operation: Push 24, Push 19, Push 18(top) Next hop type: Router
Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Next hop: 1.1.1.46 via ge-0/0/4.0
Balance: 50% Protocol next hop: 1104 Metric: 10
. . . . . .
Load balance label: Label 24: None; Label 19: None;
Label 18: None;
. . .
Next hop: 1.1.1.2 via ge-0/0/0.0
. . .
root@R1>

Static Non-Colored LSP command outputs
Name: R1-R9-LSP Path: R1-R4-R6-R8-R9
Tunnel-source: Static configuration Outgoing interface: NA
To: 192.168.1.9 <<< Only Difference is that color is not present. Auto-translate status: Disabled Auto-translate result: N/A
State: Up BFD status: N/A BFD name: N/A
Path: R1-R2-R5-R7-R9 SR-ERO hop count: 4
Outgoing interface: NA Hop 1 (Strict):
Auto-translate status: Disabled Auto-translate result: N/A NAI: None
BFD status: N/A BFD name: N/A SID type: 20-bit label, Value: 1104
SR-ERO hop count: 4 Hop 2 (Strict):
Hop 4 (Strict):
NAI: None Total displayed LSPs: 1 (Up: 1, Down: 0)
Path: R1-R3-R6-R8-R9 root@R1>
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
Hop 2 (Strict):
NAI: None
Hop 3 (Strict):
NAI: None
. 2018
Static Non-Colored LSP command outputs Cont…
root@R1> show route label 1000001 table mpls.0 root@R1> show route 192.168.1.9/32
mpls.0: 48 destinations, 49 routes (48 active, 0 holddown, 0 hidden) inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)
1000001 *[SPRING-TE/6] 00:05:08, metric 30, metric2 0 192.168.1.9/32 *[L-ISIS/14] 1w1d 03:43:26, metric 40
> to 1.1.1.6 via ge-0/0/1.0, Swap 17, Push 18, Push 28(top) > to 1.1.1.2 via ge-0/0/0.0, Push 4109
to 1.1.1.46 via ge-0/0/4.0, Swap 6109, Push 16(top) to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.2 via ge-0/0/0.0, Swap 24, Push 19, Push 18(top) to 1.1.1.46 via ge-0/0/4.0, Push 3109
[IS-IS/18] 1w1d 03:43:26, metric 40
root@R1> show route 3.3.3.8/30 > to 1.1.1.2 via ge-0/0/0.0
to 1.1.1.6 via ge-0/0/1.0
inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden) to 1.1.1.46 via ge-0/0/4.0
3.3.3.8/30 *[BGP/170] 00:05:39, localpref 100, from 192.168.1.9 + = Active Route, - = Last Active, * = Both
> to 1.1.1.2 via ge-0/0/0.0, Push 24, Push 19, Push 18(top) 192.168.1.9/32 *[SPRING-TE/6] 00:06:27, metric 30, metric2 0
to 1.1.1.6 via ge-0/0/1.0, Push 17, Push 18, Push 28(top) > to 1.1.1.6 via ge-0/0/1.0, Push 17, Push 18, Push 28(top)
to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top) to 1.1.1.46 via ge-0/0/4.0, Push 6109, Push 16(top)
root@R1> to 1.1.1.2 via ge-0/0/0.0, Push 24, Push 19, Push 18(top)
[L-ISIS/14] 1w1d 08:32:33, metric 40
> to 1.1.1.2 via ge-0/0/0.0, Push 4109
to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.46 via ge-0/0/4.0, Push 3109
root@R1>
Note: Destination address is resolving in inet.3 for the non-

colored LSP.

Static Non-Colored LSP command outputs Cont…
root@R1> show route 192.168.1.9 table inet.3 extensive . . .
Indirect next hops: 3
inet.3: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden) Protocol next hop: 27 Metric: 0
192.168.1.9/32 (2 entries, 1 announced) . . .
*SPRING-TE Preference: 6 Load balance label: Label 17: None; Label 18: None; Label 28: None;
. . . . . .
Protocol next hop: 27 Indirect path forwarding next hops: 1
Label operation: Push 17, Push 18, Push 28(top) Next hop type: Router
Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Next hop: 1.1.1.6 via ge-0/0/1.0
Balance: 20% Protocol next hop: 28 Metric: 0
. . . . . .
Protocol next hop: 28 Load balance label: Label 6109: None; Label 16: None;
Label operation: Push 6109, Push 16(top) . . .
Label TTL action: prop-ttl, prop-ttl(top) Indirect path forwarding next hops: 1
Load balance label: Label 6109: None; Label 16: None; Next hop type: Router
Balance: 30% Next hop: 1.1.1.46 via ge-0/0/4.0
. . . . . .
Protocol next hop: 1104 Protocol next hop: 1104 Metric: 10
Label operation: Push 24, Push 19, Push 18(top) . . .
Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Load balance label: Label 24: None; Label 19: None; Label 18: None;
Balance: 50% Indirect path forwarding next hops: 1
. . . Next hop type: Router
Next hop: 1.1.1.2 via ge-0/0/0.0
. . .
root@R1>

Static LSP (auto-translate)
• RLI 39603 provides JUNOS with the ability to segment-list configuration of an SR-TE LSP can accept IP address for all its hops
along the path. You may use the “auto-translate” option and describe the path as a series of IP hops, like an RSVP-TE path,
and Junos will translate the SIDs. This has a nice advantage of removing the need to statically configure adjacency SIDs as well,
ensuring a controller, who may have calculated the path, is not required to change the path in the event of a link transitioning
down.
• Each IP address can be either loopback IP address of a node or a link IP address. The type of IP address (node or link) should be
provided through configuration. The configured IP addresses of the hops will be automatically translated to corresponding
labels(SIDs) using the Translation Service. IP address (ER) list should be translated to a list of corresponding SIDs. For this
purpose, SR-TE will consult TED to retrieve SIDs corresponding to the IP addresses of the hops. Each IP address will be looked
up in IGP instance of TED to try and get the corresponding SID.
• A loopback IP address will translate to its corresponding Prefix SID whereas a link IP address will translate to its corresponding
Adjacency SID. For a link IP address translating to multiple Adjacency SIDs, a protected SID will be chosen by default, if
available. The choice of adjacency SID can be further controlled by configuration knob.
• Translation Service need not do anything explicit to handle traffic load balancing (ECMP) between two nodes. A Node/Prefix
Sid (returned from Translation) being programmed along with a route should take care of ECMP.
• SR-TE will have a retry timer per lsp to retry any translation that fails.

Static LSP (auto-translate) Cont...
• A “auto-translate” knob is added under segment-list. If configured, this knob indicates that the SR LSP requires translation
service. Note that this knob has to be enabled for a segment-list to accept IP address for any of its hops other than the 1st hop.
When “auto-translate” is enabled, all of the hops must have an IP address configured. For a segment-list with “auto-
translate” enabled, if a hop has both IP address and label configured, then the configured label will be retained.
• Since IGP instance of TED will be used for translation, “isis traffic-engineering igp-topology” must be enabled for
successful Translation.
• “protected” or “unprotected” option can be configured to choose a protected or unprotected adjacency SID for the links of
the LSP. “mandatory” option if configured, causes translation to fail if the specified type of adjacency-SID cannot be found for
a link.
• <hop-name> under segment-list will accept a new “label-type node” attribute to indicate that the IP address is a node’s
address (e.g., loopback address). A hop with label-type “node” will translate to a Prefix-SID. The Prefix-SID can further be a
Node-SID or an Anycast-SID depending on the type of hop IP address. Absence of “node” attribute indicates that the IP address
corresponds to a link.
• Translation service keeps track of the node reached at each hop. A link address is translated into a label only if the preceding
node advertises an Adj-SID for the address in question. Otherwise, translation will fail. Beyond this, there is no validation done
on the specified ERO.

Static (auto-translate) - Non-Colored LSP Config Example
protocols { . . . . . .
source-packet-routing { segment-list R1-R3-R6-R8-R9 { R8-Loopback {
lsp-external-controller pccd; R1-R3-IP-Add ip-address 1.1.1.46; ip-address 192.168.1.8;
preference 6; R6-Loopback { label-type {
sr-preference-override 100; ip-address 192.168.1.6; node;
maximum-segment-list-depth 5; label-type { }
segment-list R1-R2-R5-R7-R9 { node; }
R2-Loopback { } R9-Loopback {
ip-address 192.168.1.2; } ip-address 192.168.1.9;
label-type { R6-R8-IP-Add ip-address 1.1.1.30; label-type {
node; R9-Loopback { node;
} ip-address 192.168.1.9; }
} label-type { }
R2-R5-IP-Add ip-address 1.1.1.10; node; inherit-label-nexthops;
R7-Loopback { } auto-translate;
ip-address 192.168.1.7; } }
label-type { inherit-label-nexthops; source-routing-path R1-R9-LSP {
node; auto-translate; to 192.168.1.9;
} } binding-sid 1000001;
} segment-list R1-R4-R6-R8-R9 { metric 30;
R7-R9-IP-Add ip-address 1.1.1.38; R4-Loopback { primary {
inherit-label-nexthops; ip-address 192.168.1.4; R1-R2-R5-R7-R9 weight 20;
auto-translate; label-type { R1-R3-R6-R8-R9 weight 30;
} node; R1-R4-R6-R8-R9 weight 50;
. . . } }
} }
R6-Loopback { }
ip-address 192.168.1.6; }
label-type {
node;
}
Note: Same type of config is also applicable for Colored
} LSP with relevent changes. You can use Prefix SID,
. . . Binding SID or Anycast SID as well. We can also define
only first and last hops in the path and intermediate hopes
can be loose. In that way the resulting label stack would be
© 2018 Juniper Networks two labels deep (reduction in label stack). 205
Static (auto-translate) - Non-Colored LSP Traceroute Output
Only segment 1 is active: Only segment 3 is active:
1 1.1.1.6 (1.1.1.6) 48.169 ms 8.313 ms 10.971 ms
1 1.1.1.2 (1.1.1.2) 36.586 ms 18.024 ms 4.075 ms
2 1.1.1.10 (1.1.1.10) 14.579 ms 35.312 ms 33.686 ms
2 1.1.1.14 (1.1.1.14) 12.135 ms 201.122 ms 16.833 ms
3 1.1.1.26 (1.1.1.26) 18.508 ms 62.581 ms 29.586 ms
3 1.1.1.30 (1.1.1.30) 9.348 ms 25.558 ms 22.986 ms
4 3.3.3.10 (3.3.3.10) 17.599 ms 33.398 ms 10.521 ms
4 3.3.3.10 (3.3.3.10) 32.892 ms 15.297 ms 21.988 ms
root@R1>
Only segment 2 is active: root@R1>

1 1.1.1.46 (1.1.1.46) 6.550 ms 4.893 ms 5.227 ms
2 1.1.1.49 (1.1.1.49) 5.301 ms 4.356 ms 11.380 ms
3 1.1.1.30 (1.1.1.30) 32.446 ms 6.837 ms 15.224 ms
4 3.3.3.10 (3.3.3.10) 80.182 ms 59.999 ms 21.406 ms
root@R1>

Name: R1-R9-LSP Hop 3 (Strict):
Tunnel-source: Static configuration NAI: IPv4 Adjacency ID, 0.0.0.0 -> 1.1.1.30
To: 192.168.1.9 <<< Only Difference is that color is not present. SID type: 20-bit label, Value: 19
State: Up Hop 4 (Loose):
Path: R1-R2-R5-R7-R9 NAI: IPv4 Node ID, Node address: 192.168.1.9
Outgoing interface: NA SID type: 20-bit label, Value: 8109
Auto-translate status: Enabled Auto-translate result: Success Path: R1-R4-R6-R8-R9
BFD status: N/A BFD name: N/A Outgoing interface: NA
SR-ERO hop count: 4 Auto-translate status: Enabled Auto-translate result: Success
Hop 1 (Loose): BFD status: N/A BFD name: N/A
NAI: IPv4 Node ID, Node address: 192.168.1.2 SR-ERO hop count: 4
SID type: 20-bit label, Value: 1102 Hop 1 (Loose):
Hop 2 (Strict): NAI: IPv4 Node ID, Node address: 192.168.1.4
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 1.1.1.10 SID type: 20-bit label, Value: 1104
Hop 3 (Loose): NAI: IPv4 Node ID, Node address: 192.168.1.6
NAI: IPv4 Node ID, Node address: 192.168.1.7 SID type: 20-bit label, Value: 4106
Hop 4 (Strict): NAI: IPv4 Node ID, Node address: 192.168.1.8
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 1.1.1.38 SID type: 20-bit label, Value: 6108
Path: R1-R3-R6-R8-R9 NAI: IPv4 Node ID, Node address: 192.168.1.9
Outgoing interface: NA SID type: 20-bit label, Value: 8109
Auto-translate status: Enabled Auto-translate result: Success
SR-ERO hop count: 4 Total displayed LSPs: 1 (Up: 1, Down: 0)
Hop 1 (Strict):
Hop 2 (Loose):
. . .


1000001 *[SPRING-TE/6] 00:10:22, metric 30, metric2 0

> to 1.1.1.46 via ge-0/0/4.0, Swap 8109, Push 19, Push 3106(top)
to 1.1.1.2 via ge-0/0/0.0, Swap 8109, Push 6108, Push
4106(top)


> to 1.1.1.2 via ge-0/0/0.0, Push 8109, Push 6108, Push
4106(top)
root@R1>


192.168.1.9/32 *[L-ISIS/14] 11:39:53, metric 40

> to 1.1.1.2 via ge-0/0/0.0, Push 4109
to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.46 via ge-0/0/4.0, Push 3109
[IS-IS/18] 11:39:53, metric 40
> to 1.1.1.2 via ge-0/0/0.0
to 1.1.1.6 via ge-0/0/1.0
to 1.1.1.46 via ge-0/0/4.0


to 1.1.1.2 via ge-0/0/0.0, Push 8109, Push 6108, Push
4106(top)
[L-ISIS/14] 11:39:53, metric 40
> to 1.1.1.2 via ge-0/0/0.0, Push 4109
to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.46 via ge-0/0/4.0, Push 3109
root@R1>
Note: Destination address is resolving in inet.3 for the non-colored LSP.

root@R1> show route 192.168.1.9 table inet.3 extensive

192.168.1.9/32 (2 entries, 1 announced)
*SPRING-TE Preference: 6
. . .
. . .
Balance: 30%
. . .
. . .
Balance: 20%
. . .
. . .
Balance: 50%
. . . . . .
Indirect next hops: 3 Indirect path forwarding next hops: 1
Next hop: 1.1.1.6 via ge-0/0/1.0
Label operation: Push 8109, Push 19, Push . . .
3106(top) Protocol next hop: 1104 Metric: 10
. . . Label operation: Push 8109, Push 6108, Push 4106(top)
Indirect path forwarding next hops: 1 . . .
Next hop type: Router Indirect path forwarding next hops: 1
Next hop: 1.1.1.46 via ge-0/0/4.0 Next hop type: Router
Next hop: 1.1.1.2 via ge-0/0/0.0
. . .
. . .
Protocol next hop: 1102 Metric: 10 root@R1>
© 2018
. . . Juniper Networks 210
Static Segments
From MPLS data plane’s perspective, SID labels of adjacency, prefix, and node segments are no different than traditional MPLS
cross-connects. It introduces a new “segment” knob at the “protocols mpls label-switched-path” hierarchy for static
segment LSP configuration.
1000002 *[MPLS/6] 00:00:10, metric 1
> to 1.1.1.2 via ge-0/0/0.0, Pop
protocols {
1000002(S=0) *[MPLS/6] 00:00:10, metric 1
mpls { > to 1.1.1.2 via ge-0/0/0.0, Pop
static-label-switched-path abc { 1000003 *[MPLS/6] 00:00:10, metric 1
segment { > to 1.1.1.2 via ge-0/0/0.0, Swap 1000004
<sid-label>;
description <description>;
next-hop <ip_address | interface_name>; <<< Next-hop is the immediate nexthop IP address, or the name of a P2P interface.
pop | swap <outgoing-label>; <<< label operation of “pop” (and forward) applies to adjacency segment. Label operation of “swap”
} (and forward) applies to a prefix or node segment.
}
}
}
A static segment LSP is identified by a unique name. Its type is segment, and it has a SID label. A transit route for the sid-label
is installed in mpls.0.The SID label must fall in the JUNOS static label pool, which has a default range of [1000000, 1048575],
and can be configured by using the “set protocols mpls label-range static-label-range [x, y]” knob. The
segment also has a label operation of “pop” (i.e. pop-and-forward) or “swap” (i.e. swap-and-forward), applying to adjacency
segment and prefix/node segment, respectively. In both cases, the segment has a next-hop which specifies the remote IP
address or the name of an outgoing interface. Internally, the IP address is used to resolve the outgoing interface. An interface
name is only acceptable for a point-to-point interface. You can use “show mpls static-lsp segment (extensive)” and
“show mpls static-lsp statistics segment” to check status of the static segment.
BASICS OF LFA AND TI-LFA

Loop-Free Alternates (LFA) Basics
Loop Free Alternates (LFA) is a technology by which a neighbor can be used as a backup next hop to provide a local repair path
for the traffic to flow temporarily in case of failures in the primary next hop (node or link). For this, the basic requirement is that
the selected backup neighbor provides a loop free path with respect to primary next hop towards a destination, originating a set
of interior gateway protocol (IGP) prefixes.
Loop-Free Alternate (LFA) Fast Reroute (FRR) allows link state protocols to quickly switch (within 50 ms) to a backup path
when a primary path fails. Without LFA FRR, link state protocols has to re-run SPF to find a new path when the primary path
fails. With LFA FRR, link state protocols pre-computes a backup path and installs the backup next hop in the forwarding table.
Let’s say there is a router X with four neighbors (A, B, C, D). Router X acting as a potential (future) PLR, performs five SPF
calculations:
• One primary SPF calculation, using the local node (Router X) as the root of the SPF tree. Routers always perform this type of
SPF calculations, regardless of whether LFA is enabled, to determine primary next hops due to normal IGP operation.
• Four backup SPF calculations (to discover Extended P-space), with each calculation using a different direct IGP neighbor
node (A, B, C, D) as the root of the SPF tree. Routers perform this type of SPF calculation to determine backup next-hops
only if the LFA feature is enabled.

Loop-Free Alternates (LFA) Basics Cont…
The backup next hop is considered loop-free if the result of a backup SPF calculation does not point back to the node which
performs the local repair. In other words, the following conditions are checked to determine if the backup next hop is loop-free:
PLR = S
Distance (N, D) < Distance (S, N) + Distance (S, D) <<< For Link Protection
D
For Node protection, below is one more condition should be true in addtion to the first one. is
t
E
an
S,
ce
=
=
e
Distance (N, D) < Distance (N, E) + Distance (E, D) <<< For Node Protection
nc
Distance = S,D S,
N
ta
is
D
Where:
Distance = N,E
• S = Router performing the local repair or Computing Router
Primary Potential
• D = Destination under consideration
• NH = E Backup = N
N = Neighbor node that can be used as a potential backup next hop
D
• E = Node Being protected or Primary Next-hop is
,D
t an
N
ce
=
=
ce
Note: For an alternate next-hop N to protect against node failure of a primary NH E,
n
D
ta
neighbor E for destination D, N must be loop-free with respect to both E and D.
is
D
In other words, N’s path to D must not go through E.
Destination = D
The traffic redirected by PLR traverses nodes that have an old (pre-failure) view of the network, since global convergence still
didn’t happen on them. Therefore, these nodes may still believe the shortest path to the destination is via failed link or node.
Thus, the challenge is how to ensure that in such transient state loop doesn’t occur.
If link protection condition (Distance (N, D) > Distance (S, N) + Distance (S, D)) is not true, then there would be a loop and
backup path will not install. Because in case of primary NH link failure, potential backup router will send the traffic back to the
PLR causing loop.
If node protection condition (Distance (N, D) > Distance (N, E) + Distance (E, D)) is not true, then there would be a blackhole of
traffic and backup path will not install. Because in case of primary NH neighbor router failure, potential backup router will try to
send the traffic to the primary NH neighbor router causing blackhole of traffic.
Multiple LFA may exist for a specific destination. Tie breakers are used to pick one, mostly :
• Prefer best protection type (node > link)
• Prefer shortest path (lowest metric)

Link Protection: Distance (N, D = 8) < Distance (S, N = 9) + Distance (S, D = 9), Protected path will traverse Node E, hence only link protection.
Node Protection: Distance (N, D = 6) < Distance (N, E = 3) + Distance (E, D = 4), Protected path will note traverse Node E, hence node protection.
PLR = S PLR = S
Link Protection Node Protection
Example D Example D
is is
5
5
ta ta
=
=
nc nc
ce
ce
e e
an
n
= =
ta
Distance = 9 9 Distance = 9 9
t
is
is
Primary Backup Primary Backup
D
D
Path Path Path Path
Distance = 3 Distance = 3
Primary Potential Primary Potential
NH = E Backup = N NH = E Backup = N
D D
is is
8
6
t an t an
=
=
ce c
e
e
e
nc
nc
= =
ta
ta
4 4
is
is
D
D
Destination = D Destination = D
Loop-Free Alternates (LFA) Types - Pure IGP LFAs
There are many types of LFA flavors:
1. Per-link (Pure IGP LFA - Not supported by Junos - Not covered in this document): All prefixes originally reachable over a
failed link use the same backup next hop. This type of protection is sometimes also called Per-Next-Hop LFA.
Main characteristic of per-link LFA: Failure of the primary link causes redirection of all traffic originally flowing via this link
over a single backup link. If a single backup link that satisfies loop-free criteria for all the destination prefixes cannot be
found, the backup next hop is not used at all. Per-link LFA is not available in Junos.
Additionally, per-link LFA does not provide protection against node failure (just link failure)
2. Per-prefix (Pure IGP LFA - Not covered in this document): Prefixes originally reachable over a failed link or node may use a
different backup next hop on a per-prefix basis. Junos offers two configuration options:
node-link-protection: Installs, if possible, loop-free backup next hops, which fulfill both node protection (backup path
avoids neighbor node used as primary next hop) and link protection (backup path avoids original link used to reach primary
next hop) criteria.
link-protection: Installs, if possible, loop-free backup next hops, which fulfill at least the link protection (backup path
avoids original link used to reach primary next hop)

Loop-Free Alternates (LFA) Types - rLFA
3. LFA with LDP backup tunnels (Remote LFA) (Configuration and command outputs are not covered in this document):
Simple LFA (or Pure IGP LFAs) doesn’t always provide full coverage and its very topology dependent. Reason is simple i.e. in
many cases backup next hop best path goes through the router calculating the backup next hop. This problem can be solved if
we can find a router which is more than one hop away from the calculating router, from which traffic will be forwarded to the
destination without traversing the failed link and somehow, we tunnel the packet to that router.
rLFA used in MPLS enabled network. Remote LFA provides a mechanism where if direct LFA path is not available, traffic can
be tunneled (LDP) to a remote PQ-Node. Traffic sent to the PQ-Node does not traverse protected links, because this is the
definition of P-space. Next, the PQ-Node sends the traffic to the destination. Again, based on the definition of Q-space, this
traffic does not traverse the protected link. This way we can still deliver traffic to end destination within 50 millisecond
turnaround time. The disadvantage is that you need to enable LDP on all the routers. Also PQ-Node protects only the link and
not the node.
This kind of multi-hop repair paths are more complicated than single hop repair paths as computations are needed to
determine if a path exists (to begin with) and then a mechanism to send the packet to that hop.
Note: rLFA is also topology dependent but it provides far greater coverage compared to normal pure IGP LFA.

Loop-Free Alternates (LFA) Types - rLFA Cont…
rLFA introduces the concepts of P-space, Extended P-space, Q-space, and PQ-Node which must be interpreted in the context
of a given PLR (S-Node) and a given protected link. These definitions are very important to understand w.r.t TI-LFA as well.
P-space: This is a set of routers reachable from a PLR router using a shortest path and without traversing the protected
resource (link, adjacency or node). In the case of ECMP, this requirement applies to all the equal-cost shortest paths from S
to a node in the P-space. None of these paths can traverse the protected link; otherwise, the node is not in the P-space.
Extended P-space: The union of P-space computed for PLR router as well as P-spaces computed for each direct neighbor of
S, excluding primary next-hop router. Point behind Extended P-Space is that it helps to increase the coverage.
Q-space: This is a set of routers that can reach the primary next hop of PLR using a shortest path and without traversing the
protected resource (link, adjacency or node). In the case of ECMP, this requirement applies to all the equal-cost shortest
paths from a node in the Q-space to E.
PQ-Node: This is a node that is a member of both the P-space (or extended P-space) and the Q-space. The PQ-Node does not
need to be directly connected to PLR or its primary next hop. Any router which is a PQ-Node can be a rLFA candidate. The
candidate router (PQ-Node) to whom PLR can send the packet, will forward the packet to the destination without traversing
through protected link. In case of multiple PQ-Nodes, S-Node will select the PQ-Node which is nearest to it.
There are various ways to tunnel the traffic to PQ-Node, like IPinIP, GRE and LDP etc. However, the most common form of
implementation is LDP tunnel.
Loop-Free Alternates (LFA) - Plane LFA does not give full coverage
Note: For R3, “Distance(N, D) < Distance(N, S) + Distance(S, D)” is false hence R2 (In plane LFA) can not send traffic to R3.
Q Space
Q Space Q Space
Q Space
E-Node R1 R6 Destination E-Node R1 R6 Destination
M: 1 M: 1
NH
NH
ary
ary
M:
M:
1
1
im
im
M:
M:
1
1
Pr
Pr
Source Source
S-Node S-Node
PQ-Node
R2 Q
Q Space
Space R5 R2 Q Space
Q Space R5
aaccee
SSpp
M:
M:
Al
Al
1
1
ddPP
te
ter
M:
M:
1
1
rn
na
ddee
ate
te
tteenn
NH
NH
EExx
M: 2 M: 2
R3 R4 PQ-Node R3 R4 PQ-Node
P
P Space
Space Extended
Extended P
P Space
Space
Loop-Free Alternates (LFA) - coverage enhancement using rLFA
In the figure, two PQ-Node exists, first one is R4 and the other
Q
Q Space
Space is R5. rLFA selects the backup next hop (PQ-Node) closest to
E-Node R1 R6 Destination the source, in this case R4.
M: 1
NH
ary
M:
1
im
M:
1
Pr
Source
S-Node
R5 is PQ-Node as this node falls in
R2 Q
Q Space
Space R5
extended P space as well as Q space.
aaccee
SSpp
M:
Al
1
ddPP
ter
M:
1
na
ddee
te
tteenn
NH
EExx
M: 2 R4 is also a PQ-Node as this node falls in P space as well

R3 P R4
P Space
Space as Q space. R2 will select R4 as its PQ-Node as it is nearest.
also
also Extended
Extended P
P Space
Space
Loop-Free Alternates (LFA) - coverage enhancement using rLFA Cont…
How does R2 send packets to destination R6 in case of primary
Q
Q Space
Space NH failure?
E-Node R1 R6 Destination
M: 1 Simply forwarding packets destined to R6 in the direction of
R3 would cause a loop. In order for the protecting node to
NH
know what label a PQ-Node will use to forward the traffic to

ary
destination (D), it has to establish Targeted LDP session with a
M:
1
im
M:
PQ-Node to get the FEC to label mappings. R2 automatically

Ta
Pay Load
1
Pr
rg
Source establishes a targeted multihop LDP session to the PQ-Node

ete
S-Node (R4). Over this LDP session, the PQ-Node (R4) sends IPv4
LDd
FECs, including the FEC for R6 loopback (label Y).

R2 Q
Q Space
Space R5
P Se
In this case a stack consisting of two LDP labels is used by R2

ssi
aaccee
LDP-X LDP-Z
(S). Outer LDP label X (mapped to R4’s loopback), is the label
on
Pay Load
SSpp
LDP-Y
M:
Al
to reach R4 and inner LDP label Y (mapped to R6’s loopback

1
Pay Load
ddPP
La
ter
M:
1
and received via targeted LDP session), is label to reach R6 (D)

be
na
LDP-Y
ddee
te
from R4.
tteenn
Y
NH
Pay Load
EExx
M: 2 This brings up the point that “Targeted LDP sessions” should

R3 P R4 PQ-Node be enabled on the all the nodes for Remote LFA.
P Space
Space
also
also Extended
Extended P
P Space
Space
Loop-Free Alternates (LFA) - rLFA does not provide 100% c0verage
Does Remote LFA provide 100% coverage?
Q
Q Space
Space
E-Node R1 R6 Destination Not necessarily. For instance, if we increase the cost between
M: 1 R6 (D) and R5 then R4 and R5 will not fall in PQ space. If PQ-
Node is not available in this topology (No overlap of P space or
NH
extended P space with Q space) then rLFA can not provide

ary
protection. Some of the shortcomings of rLFA is given below:
M:
1
im
M:
7
Pr
Source • rLFA provides better coverage than vanilla IGP LFA, but it
S-Node does not provide 100% coverage.
R2 R5
• rLFA doesn't provide coverage in the space where there is
no overlap between P & Q Space.
aaccee
SSpp
M:
Al
1
ddPP
ter
M:
1
na
ddee
te
tteenn
NH
EExx
M: 2
R3 P R4
P Space
Space
also
also Extended
Extended P
P Space
Space
Loop-Free Alternates (LFA) - TI-FRR provides 100% coverage
4. LFA with RSVP-TE backup tunnels (Topology-
Independent Fast Re-Route [TI-FRR]) (Not covered
E-Node R1 R6 Destination in this document):
M: 1
The goal is to provide 100% coverage in the topology and
NH
rLFA does not pr9ovide 100% coverage in all the

ary
topologies. So what can be done to have 100% coverage?
M:
1
im
M:
The answer is our plain old RSVP-TE tunnels. Juniper’s
7
Pr
Source implementation tries to find if there is a valid LFA, if there

S-Node isn’t, then it can create a dynamic RSVP tunnel to the
primary next hop R1 (obviously not through primary link)
R2 R5
and once the traffic reaches R1 then from there traffic
traverses towards the destination.
el
M:
Al
When TI-FRR is enabled, backup LFA or rLFA next hops

nn 1
ter
M:
Tu
1
are no longer used. All backup next hops point to bypass

na
VP
te
RSVP-TE tunnels.
RS
NH
M: 2 TI-FRR is completely topology independent.

R3 R4

Loop-Free Alternates (LFA) - TI-LFA for SR
5. LFA with SPRING backup tunnels (Topology-Independent LFA [TI-LFA]): The basic idea with SPRING protection
is very simple: instead of redirecting the traffic around failure over some temporary path, and then, after global convergence
happens, redirecting that same traffic again using a newly calculated global path, you make the backup path, right from the
beginning, equal to the shortest post-convergence path.
In SPRING the backup path is enforced by using appropriate label stack pushed by PLR on the top of the redirected packet.
In both cases (RSVP 1:1 and SPRING) the shortest post-convergence backup path can be created (enforced) in any arbitrary
topology–it is topology independent.
TI-LFA Provides sub-50ms protection to the network and it is topology independent. TI-LFA provides protection against link
failure, node failure, and failures of fate-sharing groups. By default TI-LFA provides only link protection.
We have established two things with rLFA so far:
I. rLFA requires targeted LDP sessions.
II. We still don’t have 100% coverage (except RSVP-TE backup tunnels - TI-FRR).
Any Prefix (Node, Anycast) SID is always subject to protection, while Adj-SID, depending if advertised with ‘B’ flag set or
unset, might, or might not be subject to protection.

Loop-Free Alternates (LFA) - TI-LFA for SR - Benefits
Let’s discuses the advantages of TI-LFA.
a. No Need of Targeted LDP sessions. In case of TI-LFA, Source already knows the Node SID of the PQ-Node and
destination. It will use Node-SID to get to the PQ-Node. TI-LFA calculates the PQ-Node similar to Remote LFA.
b. Double Segment Protection: TI-LFA can provide coverage by steering packets from P-Space to Q-Space nodes. TI-LFA
provides 100% coverage on all failure types (link, node and SRLG).
c. Path Optimality: When calculating the backup path, TI-LFA temporarily removes the protected resource (link or node)
from the topology database and runs standard SPF. Therefore, the backup path calculated by TI-LFA has, among all
the paths that skip the protected resource, the lowest total metric to the final destination. This is called the shortest
post-convergence path.
TI-LFA’s always prefers the post-convergence path from a PLR point of view. In this way TI-LFA will always prefer the
best path available post failure. Post-convergence path is better than having an intermediate path, then converge again
back to post-convergence path.
d. If available, then uses ECMP-aware shortest paths (using node segment IDs).
Lets discuess point a and point b in some more details.

Loop-Free Alternates (LFA) - TI-LFA for SR Cont…
a. No Need of Targeted LDP sessions.
Q
Q Space
Space
E-Node R1 R6 Destination Let’s take the same example that we provided for
M: 1 rLFA (Slide 222) and see how SR improves the
behavior here.
NH
ary
The first improvement SR brings here is that there
M:
1
im
M:
Pay Load isn’t a need for targeted LDP sessions anymore. In
1
Pr
Source the case of SR, R2 (S) will stack two labels, first is
S-Node the bottom Node-SID label of R6 (D) i.e NS: R6 and
top label as Node-SID label of R4 i.e. NS: R4. As you
R2 Q
Q Space
Space R5
can see SR brings simplicity by getting rid of
Targeted LDP sessions.
aaccee
NS: R4 NS: R6
Pay Load
SSpp
NS: R6
M:
Al
1
Pay Load
ddPP
ter
M:
1
na
NS: R6
ddee
te
tteenn
NH
Pay Load
EExx
M: 2
R3 P R4 PQ-Node
P Space
Space
also
also Extended
Extended P
P Space
Space
Loop-Free Alternates (LFA) - TI-LFA for SR Cont…
b. Double Segment Protection.
Q
Q Space
Space
E-Node R1 R6 Destination As we saw earlier that in the case where there is no
M: 1 overlap between P and Q space then rLFA doesn’t
provide coverage. TI-LFA can provide coverage in
NH
these kind of situations by steering the packets from

ary
P-Space to Q-Space nodes.
M:
1
im
M:
Pay Load
7
Pr
Source Assume that the adjacency SID is “AS: R5-R6 Link”

S-Node for R5-R6 link. Then R2 (S) can form a three label
stack with first two top labels are used to steer the
R2 NS: R5 AS: R5- R5
packets from P space to Q space nodes and third
AS: R5- R6 Link
label is the is used to reach the destination.
aaccee
R6 Link NS: R6
NS: R5 Pay Load
SSpp
NS: R6
M:
Al
AS: R5-
1
Pay Load
ddPP
ter
M:
R6 Link
1
na
NS: R6
ddee
te
tteenn
NH
Pay Load
EExx
M: 2
R3 P R4
P Space
Space
also
also Extended
Extended P
P Space
Space
Loop-Free Alternates (LFA) - TI-LFA Failure scenarios
Depending on the backup path calculation results, one of the following options are possible:
Option 1: The repair node is a direct neighbor: When the repair node (backup next hop) is a direct neighbor, the outgoing interface is set to that
neighbor and the repair label list is empty (there is no repair label). This is comparable to the plain per-prefix LFA local repair.
Option 2: The repair node is a PQ-Node: When the repair node (remote backup next hop) is a PQ-Node, the repair label list comprises a single Node
Segment ID to the repair node (PQ-Node). This is comparable to the rLFA architecture.
Option 3: The repair is a Q-node, direct neighbor of the P-node: rLFA can not provide backup path in this scenario. When the repair node (a Q-
node, used as remote backup next hop) is directly connected to the P-node (Look at the previous slide), the repair label list comprises two segments: a
Node Segment ID to the P-node, and an Adjacency Segment ID from that P-node to the repair node (Q-node). This protection method is called Direct LFA
(DLFA) and it requires the advertisement of a label (Adjacency Segment ID) for each IGP adjacency.
Option 4: Connecting distant (non directly connected) P-nodes and Q-nodes: rLFA can not provide backup path in this scenario. In some cases,
there might not be any adjacent P-nodes and Q-nodes. However, the PLR can perform additional computations to compute a list of segments (combination
of Node and Adjacency Segment IDs) that represent a loop-free path from P to Q. The computation in this option is CPU intensive.
Option 5: No Q Space available in topology: rLFA can not provide backup path in this scenario. In some cases, there might not any Q Space
available. In this case, PLR can perform additional computations to compute a list of segments (combination Adjacency Segment IDs) that represent a
loop-free path from PLR to merge point.
We have used next page topology for the TI-LFA to explore all the above scenarios.

R3 - lo0.0-
192.168.1.3/32
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30
Base
Topology
M: 2000 Segment Routing M: 1000
ge-0/0/4 ge-0/0/4
1.1.1.45/3 M: 1100 1.1.1.49/30
192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 M: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 M: 1000 SL: 8000
ge-0/0/1 ge-0/0/3 M: 1000 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
ge-0/0/5 ge-0/0/6
1.1.1.54/30 1.1.1.57/30
M: 1000 M: 2000 M: 1000 M: 1000
ge-0/0/4 ge-0/0/4
1.1.1.53/30 1.1.1.58/30
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1
1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 M: 2000 192.168.1.5/32 192.168.1.7/32 M: 1000 192.168.1.9/32
M: 0500 SL: 7000 SL: 9000
SL: 2000 ge-0/0/0 ge-0/0/0 SL: 5000 ge-0/0/0 ge-0/0/0

Loop-Free Alternates (LFA) - TI-LFA Config and commands
Difference between Normal LFA (Per-
prefix LFA) and TI-LFA with an example:
In this particular case, to reach R9 from R1, the TI-LFA Basic Config: Yellow Highlighted are optional.
shortest path is via R4, with total path cost
4000. The legacy LFA backup next hop is R3, protocols {
isis {
with path cost from R3 to R9 equal to 3000. backup-spf-options {
use-post-convergence-lfa maximum-backup-paths <1-8>; <<< Enables TI-LFA.
Legacy LFA does not select R2 as the backup use-source-packet-routing; <<< Enables SPRING-based LFA protection for
} normal IPv4 or IPv6 IS-IS prefixes and primary IS-IS
next hop, since the path cost from R2 to R9 is interface ge-0/0/0.0 { source packet. Enables use of node segments for LFA
higher (3500) than from R3 to R9 (3000). TI- point-to-point;
level 2 {
LFA, on the other hand, takes into account total post-convergence-lfa node-protection; <<< Enable Interface for TI-LFA by using
metric 1000; “post-convergence-lfa” knob. Use of
post-convergence cost (from the source R1) of } “node-protection” is optional. TI-LFA
the backup path. Via R3 the total path cost is }
} by default provides Link protection. We
need to use this knob to have node-protection.
5000, while via R2 it’s only 4500. Therefore, }
the choice for TI-LFA backup next hop is R2.

We can check whether TI-LFA is enabled on the interface with below command:
This example makes us clear on why TI-LFA is
root@R8> show isis interface ge-* extensive | match "ge-|Protection"
much batter compared to Normal LFA (Per- ge-0/0/0.0
Post convergence Protection:Enabled, Fate sharing: No, Srlg: No, Node cost: 0
prefix LFA). Earlier explanation draws ge-0/0/1.0
advantages of TI-LFA compared to rLFA. Post convergence Protection:Enabled, Fate sharing: No, Srlg: No, Node cost: 0
root@R8>

TI-LFA can provide strict or loose node protection:
If you look at the routers R4 and R6 and two links between them and if we enable node protection between them, there is no
backup next hop to reach to R8 from R1.
M: 1100
192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 M: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 M: 1000 SL: 8000
M: 1000
Therefore, it would be beneficial to fall back to link protection, where node protection is not possible. In legacy rLFA
configurations, you could use the “node-link-degradation” knob to enable such behavior.
TI-LFA uses a different approach, namely you can use strict or loose node protection. With strict node protection mode, the
protected node is completely removed from LSDB during SPF calculations to determine the backup next hop. With loose node
protection mode, instead of completely removing the protected node from the LSDB, the cost of all the links (other than the
primary link, for which the backup path is being calculated) to the protected node will be increased by the configured node
protection cost value. Thus, the use of the protected node will be strongly (if configured node protection cost value is high)
discouraged, but the protected node will be still considered as a backup, even if there is no other option. Therefore, it can be used
as a fallback to link protection, if node protection is not possible.

• Strict Node Protection: In strict node protection mode, the protected node is completely removed from LSDB during SPF
calculations to determine the backup next hop. Configuring “node-protection cost” to be equal to the maximum IGP
link metric (IS-IS: 16777215, OSPF: 65535) keeps the strict node protection behavior in place.
set protocols isis interface <Interface> level 2 post-convergence-lfa node-protection cost

16777215
• Loose Node Protection: In loose node protection mode, instead of completely removing the protected node from the
LSDB, the cost of all the links (other than the primary link, for which the backup path is being calculated) to the protected
node will be increased by the configured node protection cost value. You need to configure “node-protection cost” to be
smaller (at least by 1) than the maximum IGP link metric (IS-IS: 16777215, OSPF: 65535) to enable loose node-protection
behavior.
set protocols isis interface <Interface> level 2 post-convergence-lfa node-protection cost

16777214
How is the label stack for backup path actually determined? Let’s have four scenarios.

R3 - lo0.0-
192.168.1.3/32
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
Scenario 1
& M: 2000
P-Space
Extended P-Space
M: 1000
Scenario 2
Source ge-0/0/4
1.1.1.45/3
ge-0/0/4
1.1.1.49/30
M: 1100
192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 M: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 M: 1000 SL: 8000
ge-0/0/1 ge-0/0/3 M: 1000 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
M: 1000 M: 2000 M: 1000 M: 1000
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1

Destinatio
1.1.1.6/30
R2 - lo0.0-
1.1.1.22/30 1.1.1.25/30 1.1.1.26/30
R5 - lo0.0- ge-0/0/1
1.1.1.34/30
ge-0/0/1 R7-RR - lo0.0-
1.1.1.42/30
R9 - lo0.0-
n
192.168.1.2/32 M: 2000 192.168.1.5/32 192.168.1.7/32 M: 1000 192.168.1.9/32
M: 0500 SL: 7000 SL: 9000
SL: 2000 ge-0/0/0 ge-0/0/0 SL: 5000 ge-0/0/0 ge-0/0/0

Loop-Free Alternates (LFA) - TI-LFA Failure scenarios 1 and 2 root@R1> show route 192.168.1.9 table inet.0 extensive <<< inet.0 will also have backup
path calculated
1. Scenarios 1: Destination node falls in P-Space: inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)
192.168.1.9/32 (1 entry, 1 announced)
. . .
KRT in-kernel 192.168.1.9/32 -> {Push 4109}
If the TI-LFA (post-convergence) backup path towards the . . .
destination traverses only nodes found in the P-space, the *L-ISIS Preference: 14
Level: 2
calculation of extended P-space and Q-space are not . . .
required. There won’t be any extra label push. Next hop: 1.1.1.2 via ge-0/0/0.0 weight 0x1, selected
Label operation: Push 4109 <<< 4109 is a label used by R4 for R9's Node segment
. . .
As per P-space definition, traffic from such node can reach Next hop: 1.1.1.6 via ge-0/0/1.0 weight 0xf000
Label operation: Push 2109 <<< 2109 is a label used by R2 for R9's Node segment
other nodes in P-space (including destination node) . . .
root@R1> show route forwarding-table destination 192.168.1.9
without crossing the link under protection – and still using Routing table: default.inet
the old (pre-failure) IGP database. So, no special attention . . .
is required regarding loop prevention. In other words, you 192.168.1.9/32 user 1 1.1.1.2 Push 4109 721 4 ge-0/0/0.0
don’t need the list of explicit next hops for TI-LFA backup . . .
root@R1>
path. You can simply redirect the traffic!
Note: Without load balance policy, backup NH will not install in the forwarding
2. Scenarios 2: Destination node falls in extended P-Space: table and PFE. Once you apply the policy you will see the backup NH in the
forwarding table and PFE.
If the TI-LFA (post-convergence) backup path towards the
root@R1> show route forwarding-table destination 192.168.1.9
destination traverses only nodes found in the extended P- Routing table: default.inet
space, the calculation of Q-space is not required. In this . . .
case also there won’t be any extra label push. Rest all 192.168.1.9/32 user 1 ulst 1048584 5
details are same as scenario 1. 1.1.1.2 Push 4109 721 2 ge-0/0/0.0
1.1.1.6 Push 2109 695 2 ge-0/0/1.0
. . .
Loop-Free Alternates (LFA) - TI-LFA Failure scenarios 1 and 2 Cont…
root@R1> start shell command "cprod -A fpc0 -c \"show nhdb id 1048584 recursive\""

721(Unicast, IPv4->MPLS, ifl:320:ge-0/0/0.0, pfe-id:0)
695(Unicast, IPv4->MPLS, ifl:327:ge-0/0/1.0, pfe-id:0)
root@R1> start shell command "cprod -A fpc0 -c \"show nhdb id 1048584 extensive\""
ID Type Interface Next Hop Addr Protocol Encap MTU Flags PFE internal Flags
----- -------- ------------- --------------- ---------- ------------ ---- ------------------ ------------------
1048584 Unilist ge-0/0/0.0 - IPv4 Ethernet 0 0x0000000000000000 0x0000000000000000
. . .
Selector ( ):
ID:6(1), Ref:8, Type:1 (Compact), subtype:0, Symmetric-LB: Off, Target_id:0
Key:FRR:Y, Balances:N, Locality:N/unicast, Type:Unicast, Size:2, flags:0x14, dist-mode-default
Weight Info (Selector's view): Current Weight = 1, Target_id = 0

Idx Balance Weight Orig-Weight Ifl Session Install
----- ------- ------- ----------- ------ ------- -------
0 ** 1 1 320 333 Yes
1 ** 61440 61440 327 336 No
. . .
ECMP : NO
721 Unicast ge-0/0/0.0 - IPv4->MPLS Ethernet 1500 0x0000000000000001 0x0000000000000002

695 Unicast ge-0/0/1.0 - IPv4->MPLS Ethernet 1500 0x0000000000000001 0x0000000000000002
Weight Info: Current Weight = 1

ID Balance Orig-Balance Weight Orig-Weight State Install Flags
----- ------- --------- ------ ----------- -------- ----------- -----
721 0 0 1 1 Active Installed 0x00
695 0 0 61440 61440 Standby Installed 0x00
. . .
root@R1>

R3 - lo0.0-
192.168.1.3/32
ge-0/0/0
1.1.1.46/30
SL: 3000 ge-0/0/1
Index: 103 1.1.1.50/30 TI-LFA installs the post-convergence path
Topology as backup repair path. TI-LFA follows an
algorithm which inserts the PQ node
Scenario 3 before the destination node in its stack. By
M: 4000 M: 1000 this way we can avoid sub-optimal backup
path and have the post-convergence route
installed in the FIB as backup repair path.
Destinatio
Source ge-0/0/4 ge-0/0/4
1.1.1.45/3
ge-0/0/0 R4-RR - lo0.0-
n 1.1.1.49/30
R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0-
R1 - lo0.0- ge-0/0/0
192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 M: 1000 SL: 4000 SL: 6000 M: 1000 SL: 8000
Index: 101 Index: 104 Index: 106 Index: 108
ge-0/0/1 ge-0/0/3 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
M: 1000 P-Space M: 2000 M: 1000

Q-Space M: 1000
PQ-Node
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1

1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 M: 2000 192.168.1.5/32 192.168.1.7/32 M: 1000 192.168.1.9/32
M: 4000 SL: 7000 SL: 9000
SL: 2000 ge-0/0/0 ge-0/0/0 SL: 5000 ge-0/0/0 ge-0/0/0
© 2018 Juniper Networks Extended P-Space

237
Loop-Free Alternates (LFA) - TI-LFA Failure scenario 3
root@R1> show isis overview
3. Scenarios 3: Destination node doesn't Instance: master
Router ID: 192.168.1.1
fall in P-space or extended P-Space but Hostname: R1
Sysid: 0000.0000.0001
we can find PQ-Node: Areaid: 49.0001
. . .
Post Convergence Backup: Enabled <<< TI-LFA is enabled.
It means that neither PLR nor PLR’s Max labels: 5, Max spf: 100, Max Ecmp Backup: 2 <<< Router is configured to install 2 backup paths.
. . .
direct neighbors can reach destination root@R1> show route 192.168.1.6 table inet.0 extensive
without crossing the protected links. inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)
Therefore, simple redirection, would + = Active Route, - = Last Active, * = Both
be looped back towards PLR. We need 192.168.1.6/32 (1 entry, 1 announced)
. . .
to calculate the Q space and then to KRT in-kernel 192.168.1.6/32 -> {list:Push 3106, Push 7106, Push 4107(top), Push 7106, Push 2107(top)}
. . .
find PQ-Nodes. It is enough to force *L-ISIS Preference: 14
the traffic to some PQ-Node, since . . .
Level: 2
from PQ-Node, based on Q-space Next hop: 1.1.1.46 via ge-0/0/4.0 weight 0x1, selected
definition, the shortest path towards . . .
the destination doesn’t use link under Next hop: 1.1.1.2 via ge-0/0/0.0 weight 0xf000
Label operation: Push 7106, Push 4107(top) <<< 7106 is a label used by R7 for R6's Node segment
protection. In this case we need to . . . 4107 is a label used by R4 for R7's Node segment
push two labels in the backup path, Label operation: Push 7106, Push 2107(top) <<< 7106 is a label used by R7 for R6's Node segment
. . . 2107 is a label used by R2 for R7's Node segment
top label to reach the PQ-Node and root@R1>
bottom label to reach the primary
next-hop node (E-node). Note: Router 7 is the PQ-Node (2107 and 4107 labels). Traffic first goes to R7 and
then it goes to R6 (primary next-hop node or E-node).
R3 - lo0.0-
192.168.1.3/32
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
Scenario 4
M: 2000 M: 1000
Destinatio
Source ge-0/0/4 ge-0/0/4
1.1.1.45/3
ge-0/0/0 R4-RR - lo0.0-
n 1.1.1.49/30
R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0-
R1 - lo0.0- ge-0/0/0
192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 M: 1000 SL: 4000 SL: 6000 M: 1000 SL: 8000
Index: 101 Index: 104 Index: 106 Index: 108
ge-0/0/1 ge-0/0/3 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
M: 1000 P-Space M: 2000 M: 1000 Q-Space M: 1000
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1

1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 M: 2000 192.168.1.5/32 192.168.1.7/32 M: 1000 192.168.1.9/32
M: 9000 SL: 7000 SL: 9000
SL: 2000 ge-0/0/0 ge-0/0/0 SL: 5000 ge-0/0/0 ge-0/0/0

Loop-Free Alternates (LFA) - TI-LFA Failure scenario 4
root@R1> show route 192.168.1.6 table inet.0 extensive
4. Scenarios 4: Destination node doesn't fall in P-space or inet.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)
extended P-Space and we can’t find PQ-Node, But we have 192.168.1.6/32 (1 entry, 1 announced)
one adjacent (directly connected) P-node and Q-node, R5 . . .
KRT in-kernel 192.168.1.6/32 -> {list:Push 3106, Push 7106, Push 18, Push 4105(top), Push 7106,
and R7 in our case. (R-LFA can not provide protection in Push 18, Push 2105(top)}
. . .
this Scenarios): *L-ISIS Preference: 14
Level: 2
. . .
Next hop: 1.1.1.46 via ge-0/0/4.0 weight 0x1, selected
This time, there is no overlap between P-space (or . . .
extended P-space) and Q-space. Consequently, there is no Next hop: 1.1.1.2 via ge-0/0/0.0 weight 0xf000
PQ-Node. The way traffic can be forwarded in such a . . .
scenario is as follows: . . .

. . .
I. Send the packet over the shortest path towards the P- TLVs:
. . .
node, which has the Q-node as a direct neighbor. IS extended neighbor: R7.00, Metric: default 9000 SubTLV len: 81
IP address: 1.1.1.25
Neighbor's IP address: 1.1.1.26
. . .
II. Next, from such node, use Q-node as a strict next hop P2P IPV4 Adj-SID - Flags:0x70(F:0,B:1,V:1,L:1,S:0,P:0), Weight:0, Label: 19
(Use Adj SID). That is, send the traffic over a direct link . . .
root@R1>
towards Q-node. Note:
7106 is a label used by R7 for R6’s Node segment, 19 is the Adj label assigned by R5 to R5-R7 adjacency and 4105
III.Next, from Q-node, send the packet over shortest path is a label used by R4 for R5's Node segment.
towards destination. 7106 is a label used by R7 for R6’s Node segment, 19 is the Adj label assigned by R5 to R5-R7 adjacency and 2105 is
a label used by R2 for R5's Node segment.
R3 - lo0.0-
192.168.1.3/32
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
Scenario 5
M: 2000 M: 1000
Destinatio
ge-0/0/4 Source ge-0/0/4
1.1.1.45/3
ge-0/0/0 R4-RR - lo0.0- ge-0/0/1
M: 0500 1.1.1.49/30 n ge-0/0/0 R8 - lo0.0-
R1 - lo0.0- ge-0/0/0 ge-0/0/1 R6 - lo0.0- ge-0/0/0
192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
SL: 1000 M: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 M: 0500 SL: 8000
ge-0/0/1 ge-0/0/3 M: 1000 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
ge-0/0/5 ge-0/0/6
1.1.1.54/30 1.1.1.57/30
, 17
, 18
top)
M: 1000 P-Space M: 2000 M: 0010 M: 0010 M: 0010 M: 1000 IPv4

19 (
No Q-Space
is available.
ge-0/0/4 ge-0/0/4
1.1.1.53/30 1.1.1.58/30
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1
1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 M: 2000 192.168.1.5/32 192.168.1.7/32 M: 1000 192.168.1.9/32
18, 17 M: 0500
SL: 2000 ge-0/0/0 ge-0/0/0 SL: 5000 SL: 7000 ge-0/0/0 17 ge-0/0/0 SL: 9000

Loop-Free Alternates (LFA) - TI-LFA Failure scenario 5 root@R4> show route 192.168.1.8 extensive

5. Scenarios 5: Destination node doesn't fall in P-space or extended P-
Space and we can’t find PQ-Node, also there is no adjacent (directly 192.168.1.8/32 (1 entry, 1 announced)
. . .
connected) P-node and Q-node (R-LFA can not provide protection in KRT in-kernel 192.168.1.8/32 -> {Push 6108}
this Scenarios): . . .
*L-ISIS Preference: 14
Level: 2
In this case Junos put stack of adjacency label to reach the primary . . .
next-hop node (E-node). Next hop: 1.1.1.14 via ge-1/0/0.0 weight 0x1, selected
. . .
Therefore in summary, if the metrics are not very helpful, TI-LFA Next hop: 1.1.1.22 via ge-0/0/3.0 weight 0xf000
repair path consists of as many segments as the number of hops from . . .
point of local repair to the destination. root@R4> show isis database R5.00-00 extensive
. . .
Note: TI-LFA draft doesn’t provide any hints on how to determine IP address: 1.1.1.25
required loop free label stacks for more advanced backup scenarios Neighbor's IP address: 1.1.1.26
. . .
likes this. It is up to the software vendor to develop algorithms P2P IPV4 Adj-SID - Flags:0x70(F:0,B:1,V:1,L:1,S:0,P:0), Weight:0, Label: 19
allowing for calculation of the label stack with minimal depth, while P2P IPv4 Adj-SID: 19, Weight: 0, Flags: -BVL--
. . .
still fulfilling the loop-free requirement. root@R4> show isis database R7.00-00 extensive
. . .
. . . IP address: 1.1.1.37
IP address: 1.1.1.42 . . .
. . .
. . .
root@R4>
. . .
Note: 19 is the adjacency label advertised by R5 on R5-R7 link. 18 is the adjacency label advertised by R7 on R7-
root@R4>
R9 link. 17 is the adjacency label advertised by R9 on R9-R8 link.
SR-TE TELEMETRY

R3 - lo0.0-
16 192.168.1.3/32 17
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
Northstar
Controller
192.168.1.10 em2
AS200 172.16.18.199/24
27 18
ge-0/0/9 ge-0/0/4 ge-0/0/4

172.16.18.11/24 1.1.1.45/3 17 16
1.1.1.49/30
Spirent 1 Port 1 ge-0/0/6 R1 - lo0.0- ge-0/0/0 ge-0/0/0 R4-RR - lo0.0- ge-0/0/1 ge-0/0/1 R6 - lo0.0- ge-0/0/0 ge-0/0/0 R8 - lo0.0-
Sending 10 5.5.5.2/30 5.5.5.1/30 192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
MB Traffic SL: 1000 28 19 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 20 17 SL: 8000
towards R1 Index: 101 Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106 Index: 108
ge-0/0/1 ge-0/0/3 17 16 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
ge-0/0/7
6.6.6.1/30
39 18 19 16
Spirent 1 Port 1
Sending 10 6.6.6.2/30 Segment Routing
CE5
MB Traffic AS100 ge-0/0/1
towards R1 3.3.3.9/30
34 18 18 28
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1

1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
Advertised Subnet
R2 - lo0.0- R5 - lo0.0- ge-0/0/1 ge-0/0/1 R7-RR - lo0.0- R9 - lo0.0- ge-0/0/3
17 192.168.1.5/32 24 192.168.1.9/32 3.3.3.10/30 from R9 to R1
192.168.1.2/32 27 192.168.1.7/32 17
16 16

SR-TE Telemetry
In Source Routing network, there are multiple types of traffic statistics requirements. Traffic Statistics need to be reported
periodically in an Open Config compliant format. Apart from many things we achieve LSP optimization based on telemetry data
(based on link utilization). Below is the config to enable it on Junos Side.
protocols {
isis {
sensor-based-stats {
per-interface-per-member-link ingress egress;
per-sid ingress egress;
} . . .
} sensor IFD {
} server-name Northstar-Server;
source-packet-routing { export-name Northstar-Profile;
telemetry { resource /junos/system/linecard/interface/;
statistics; } ^^^^^^^^^^^ This sensor is used only for LSP optimization.
} sensor IFL {
} server-name Northstar-Server;
} export-name Northstar-Profile;
services { resource /junos/system/linecard/interface/logical/usage/;
analytics { } ^^^^^^^^^^^ This sensor is used only for LSP optimization.
streaming-server Northstar-Server { sensor SR-TE {
remote-address 172.16.18.1; <<< Collector IP (PCS Server IP). server-name Northstar-Server;
remote-port 3000; <<< Use this port. 2000 or other ports in many docs export-name Northstar-Profile;
} like 2001 or 2002 does not work. resource /junos/services/segment-routing/traffic-engineering/ingress/usage/;
export-profile Northstar-Profile { } ^^^^^^^^^^^ This sensor is used only for SR-TE Color LSPs, Not for Adj and Node SID
local-address 172.16.18.11; <<< Local Router IP connecting to Server. LSPs
reporting-rate 2; <<< Data push frequency. sensor SR-TE-SID {
format gpb; server-name Northstar-Server;
transport udp; export-name Northstar-Profile;
} resource /junos/services/segment-routing/sid/usage/;
. . . } ^^^^^^^^^^^ This sensor is used for Adj and Node SID traffic on Node.
} It is not used for LSP optimization.
}
SR-TE Telemetry Sensors Support
As of today, NorthStar consume data from the following sensors:
/junos/system/linecard/interface/
/junos/system/linecard/interface/logical/usage/
/junos/services/label-switched-path/usage/
/junos/services/segment-routing/sid/usage/
/junos/services/segment-routing/traffic-engineering/ingress/usage/
/junos/services/segment-routing/traffic-engineering/tunnel/ingress/usage/

SR-TE Telemetry - Verification - Common Outputs
root@R1> show route receive-protocol bgp 192.168.1.9 root@R1> show spring-traffic-engineering lsp name R1-to-R9-LSP-AdjSID detail
Name: R1-to-R9-LSP-AdjSID
inet.0: 43 destinations, 44 routes (43 active, 0 holddown, 0 hidden) Tunnel-source: Path computation element protocol(PCEP)
Prefix Nexthop MED Lclpref AS path To: 192.168.1.9
* 3.3.3.8/30 192.168.1.9 100 I State: Up
. . . Telemetry statistics:
root@R1> show route 3.3.3.8 Sensor-name: ingress-R1-to-R9-LSP-AdjSID, Id: 3758096392
inet.0: 43 destinations, 44 routes (43 active, 0 holddown, 0 hidden) Auto-translate status: Disabled Auto-translate result: N/A
+ = Active Route, - = Last Active, * = Both Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A
3.3.3.8/30 *[BGP/170] 00:24:58, localpref 100, from 192.168.1.9 SR-ERO hop count: 4
AS path: I, validation-state: unverified Hop 1 (Strict):
> to 1.1.1.2 via ge-0/0/0.0, Push 16, Push 20, Push 17(top) NAI: IPv4 Adjacency ID, 1.1.1.1 -> 1.1.1.2
root@R1> traceroute 3.3.3.10 Hop 2 (Strict):
traceroute to 3.3.3.10 (3.3.3.10), 30 hops max, 52 byte packets NAI: IPv4 Adjacency ID, 1.1.1.17 -> 1.1.1.18
1 1.1.1.2 (1.1.1.2) 4.714 ms 3.400 ms 7.303 ms SID type: 20-bit label, Value: 17
MPLS Label=17 CoS=0 TTL=1 S=0 <<< AdjSID advertised by R4 on R4-R6 Link (ge-0/0/2) Hop 3 (Strict):
MPLS Label=20 CoS=0 TTL=1 S=0 <<< AdjSID advertised by R6 on R6-R8 Link NAI: IPv4 Adjacency ID, 1.1.1.29 -> 1.1.1.30
MPLS Label=16 CoS=0 TTL=1 S=1 <<< AdjSID advertised by R8 on R8-R9 Link SID type: 20-bit label, Value: 20
2 1.1.1.18 (1.1.1.18) 8.235 ms 5.653 ms 4.123 ms Hop 4 (Strict):
MPLS Label=20 CoS=0 TTL=1 S=0 <<< AdjSID advertised by R6 on R6-R8 Link NAI: IPv4 Adjacency ID, 1.1.1.41 -> 1.1.1.42
MPLS Label=16 CoS=0 TTL=2 S=1 <<< AdjSID advertised by R8 on R8-R9 Link SID type: 20-bit label, Value: 16
3 1.1.1.30 (1.1.1.30) 12.048 ms 5.723 ms 19.267 ms
MPLS Label=16 CoS=0 TTL=1 S=1 <<< AdjSID advertised by R8 on R8-R9 Link
4 3.3.3.10 (3.3.3.10) 7.300 ms 7.178 ms 6.032 ms Total displayed LSPs: 1 (Up: 1, Down: 0)
root@R1> root@R1>
The LSP is going from R1->R4->R6->R8->R9. Let's check

various sensors data in all these Routers.

SR-TE Telemetry - Verification - Common Outputs Cont…
root@R1> show agent sensors | no-more
Sensor Information :
Name : IFD
Resource : /junos/system/linecard/interface/
Version : 1.1
root@R1> show isis spring sensor info <<< Lists all sensor (non-jvision) added by isis-spring in PFE sensors info
Sensor-id : 76932
They are not for exporting data; they are used for debugging only.
Subscription-ID : 562949953498244
@IS-IS SENSOR INFORMATION
Parent-Sensor-Name : Not applicable
Per-interface-per-member-link Ingress Sensor:
Component(s) : PFE
---------------------------------------------
Sensor-name Sensor-id
Server Information :
aggr_ingress_intf_sensor 3221225507
Name : Northstar-Server
Per-interface-per-member-link Egress Sensor:
Scope-id : 0
--------------------------------------------
Remote-Address : 172.16.18.1
Remote-port : 3000 . . .
lo0.0 3221225518
Transport-protocol : UDP 1108 3221225683
ge-0/0/0.0 3221225645
ge-0/0/1.0 3221225647 1109 3221225684
Profile Information : 1499 3221225678
ge-0/0/4.0 3221225649
ge-0/0/5.0 3221225651
Name : Northstar-Profile IPv4/IPv6 Per-sid Egress Sensor:
Reporting-interval : 2 --------------------------------
Per-sid Ingress Sensor:
Payload-size : 5000 Sensor-name Sensor-id
-----------------------
Address : 172.16.18.11 L-ISIS-192.168.1.2 3221225674
Port : 1000 L-ISIS-192.168.1.3 3221225679
27 3221225676
Timestamp : 1 L-ISIS-192.168.1.4 3221225690
28 3221225691
Format : GPB L-ISIS-192.168.1.5 3221225666
39 3221225675
DSCP : 0 L-ISIS-192.168.1.6 3221225685
1102 3221225673
Forwarding-class : 0 L-ISIS-192.168.1.7 3221225686
1103 3221225677
Loss-priority : low L-ISIS-192.168.1.8 3221225687
1104 3221225689
. . . L-ISIS-192.168.1.9 3221225688
1105 3221225657
1106 3221225681 L-ISIS-192.168.1.101 3221225680
1107 3221225682
. . . root@R1>
. . .
Name : IFL
Resource : /junos/system/linecard/interface/logical/usage/
Version : 1.1
Sensor-id : 76940
Component(s) : PFE
Scope-id : 0
Remote-port : 3000
Transport-protocol : UDP
Profile Information :
Name : Northstar-Profile
Reporting-interval : 2
Payload-size : 5000
Address : 172.16.18.11
Port : 1000
Timestamp : 1
Format : GPB
DSCP : 0
Forwarding-class : 0
Loss-priority : low
. . .

. . .
Name : SR-TE
Resource : /junos/services/segment-routing/traffic-engineering/ingress/usage/
Version : 1.0
Sensor-id : 85573317
Component(s) : PFE
Scope-id : 0
Remote-port : 3000
Name : Northstar-Profile
Payload-size : 5000
Address : 172.16.18.11
Port : 1000
Timestamp : 1
Format : GPB
DSCP : 0
Forwarding-class : 0
Loss-priority : low
. . .

. . .
Name : SR-TE-SID
Resource : /junos/services/segment-routing/sid/usage/
Version : 1.0
Sensor-id : 3964114175
Component(s) : PFE
Scope-id : 0
Remote-port : 3000
Below sensor IDs in PFE are same in all routers.
Name : Northstar-Profile root@R1> start shell command "cprod -A fpc0 -c \"show agent sensors\""
Payload-size : 5000
Address : 172.16.18.11 Jvision ID Name
Port : 1000 ---------- --------------------------------
Timestamp : 1 76932 IFD 5000(0)
Format : GPB 76940 IFL 5000(685)
DSCP : 0 85573317 SR-TE 5000(0)
Forwarding-class : 0 539528113 sensor_1002 0(0)
Loss-priority : low 539528114 sensor_1001 0(0)
2277069355 __default_fabric_sensor__ 5000(82)
root@R1> 3964114175 SR-TE-SID 5000(0)
. . .
root@R1>
SR-TE Telemetry - Sensors Stats Verification on R1
root@R1> show isis spring interface traffic-statistics | no-more <<< Display the traffic statistics of an IS-IS SPRING link. SPRING traffic is measured
Interface Output-bytes Output-packets to recalculate the actual available bandwidth to RSVP for traffic engineering.
ge-0/0/0.0 0 0 <<< Egress
ge-0/0/1.0 0 0
ge-0/0/4.0 0 0
ge-0/0/5.0 0 0
ge-0/0/9.0 0 0
lo0.0 0 0
root@R1> start shell command "cprod -A fpc0 -c \"show agent sensors id 76932\""
ID: 76932 Type: 1 Name: (IFD)

Sensor Data: 0(0) bytes
---------------------------
ID: 85573317 Type: 2 Name: (SR-TE)

---------------------------
ID: 3964114175 Type: 2 Name: (SR-TE-SID)

---------------------------
root@R1>
Note: Since First top label (28) advertised by R1 on R1-R4 link will not be in label
stack, You will not see the stats (sensor id 3964114175) for this label in the outputs.
SR-TE Telemetry - Sensors Stats Verification on R1 Cont…
root@R1> start shell command "cprod -A fpc0 -c \"show agent sensors id 76940\"" . . .
Export: Interval = 2000 msecs, Payload-size = 5000 bytes, Server =
ID: 76940 Type: 1 Name: (IFL) Src: 172.16.18.11:1000, Dst: 172.16.18.1:3000(VRF 0) , Qos = TOS:0x0,
Sensor Data: 715(687) bytes Hint:0x40000010, FC:0 PLP:0
Jvision Header: system: R1:172.16.18.11, slot: 0, time: May 30 16:04:39.336, Filter: none
sequence_number: 7004, sensor_name: Accounting:
IFL:/junos/system/linecard/interface/logical/usage/:/junos/system/linecard/inter 7005 total successful reaps, 0 failed/aborted reap(s).
face/logical/usage/:PFE, version: 1.1 1 reaps in latest reporting interval.
1 packets in latest reporting interval.
===================================================== 10 instances in latest reporting interval.
Interface = ge-0/0/0.0 (550) <<< Egress Interface 7005 total packets sent.
Init time: May 30 12:03:32 2019 7005 wraps, 1 reap(s) on average to wrap.
Last 10 wraps (UTC):
Ingress Statistics . . .
------------------ root@R1>
Packets: 8931
Bytes: 849960
Unicast Packets : 8931
Multicast Packets: 0
Egress Statistics <<< Egress traffic stats

-----------------
Packets: 10251608
Bytes: 7698957608
Operational Status
------------------
Status: up
. . .

root@R4> show isis spring interface traffic-statistics
Interface Output-bytes Output-packets
ge-0/0/0.0 60 1 <<< Ingress
ge-0/0/1.0 52 1
ge-0/0/2.0 20787232 27245 <<< Egress
ge-0/0/3.0 60 1
lo0.0 0 0

---------------------------

---------------------------
root@R4>

root@R4> start shell command "cprod -A fpc0 -c \"show agent sensors id 76940\"" =====================================================
Interface = ge-0/0/2.0 (552) <<< Egress Interface
ID: 76940 Type: 1 Name: (IFL) Init time: May 30 12:03:31 2019
Jvision Header: system: R4:172.16.18.14, slot: 0, time: May 30 16:04:40.122, Ingress Statistics
sequence_number: 6978, sensor_name: ------------------
IFL:/junos/system/linecard/interface/logical/usage/:/junos/system/linecard/inter Packets: 8620
face/logical/usage/:PFE, version: 1.1 Bytes: 762214
===================================================== Multicast Packets: 0
Interface = ge-0/0/0.0 (550) <<< Ingress Interface
Init time: May 30 12:03:31 2019 Egress Statistics <<< Egress traffic stats
-----------------
Ingress Statistics <<< Ingress traffic stats Packets: 6827824
------------------ Bytes: 5182305834
Packets: 10262282 Unicast Packets : 6827824
Bytes: 7823617546 Multicast Packets: 0
Multicast Packets: 0 Operational Status
------------------
Egress Statistics Status: up
----------------- . . .
Packets: 1091 Export: Interval = 2000 msecs, Payload-size = 5000 bytes, Server =
Bytes: 75665 Src: 172.16.18.14:1000, Dst: 172.16.18.1:3000(VRF 0) , Qos = TOS:0x0,
Unicast Packets : 1091 Hint:0x40000010, FC:0 PLP:0
Multicast Packets: 0 Filter: none
Accounting:
Operational Status 6979 total successful reaps, 0 failed/aborted reap(s).
------------------ 1 reaps in latest reporting interval.
Status: up 1 packets in latest reporting interval.
. . . 5 instances in latest reporting interval.
6979 total packets sent.
6979 wraps, 1 reap(s) on average to wrap.
. . .
root@R4>

Jvision Header: system: R4:172.16.18.14, slot: 0, time: May 30 16:04:54.323, sequence_number: 5952, sensor_name: SR-TE-SID:/junos/services/segment-
routing/sid/usage/:/junos/services/segment-routing/sid/usage/:PFE, version: 1.0
------------------------------------------------------------------------------------
Packets Bytes Packet Rate Byte Rate Inst Counter-Name SID Name
--------------- --------------- ----------- ------------ ---- ------------- --------
3424491 2613117908 0 0 0 oc-47 16
6881938 5250901918 0 0 0 oc-49 17 <<<17 is R4’s AdjSID label advertised on R4-R6 Link (ge-0/0/2).
12 2100 0 0 0 oc-57 4101
------------------------------------------------------------------------------
Total 3 records.
------------------------------------------------------------------------------
Export: Interval = 2000 msecs, Payload-size = 5000 bytes, Server = Src: 172.16.18.14:1000, Dst: 172.16.18.1:3000(VRF 0) , Qos = TOS:0x0, Hint:0x40000010,
FC:0 PLP:0
Filter: none
Accounting:
6986 total successful reaps, 0 failed/aborted reap(s).
1 reaps in latest reporting interval.
3 instances in latest reporting interval.
. . .
root@R4>

ge-0/0/0.0 20884616 27302 <<< Egress
ge-0/0/1.0 0 0
ge-0/0/2.0 135 2 <<< Ingress
ge-0/0/3.0 60 1
ge-0/0/4.0 60 1
lo0.0 0 0
root@R6>

---------------------------

---------------------------
root@R6>

Jvision Header: system: R6:172.16.18.16, slot: 0, time: May 30 16:04:38.558, Ingress Statistics <<< Ingress traffic stats
Init time: May 30 12:03:32 2019 Egress Statistics
-----------------
Ingress Statistics Packets: 2130
------------------ Bytes: 131343
------------------
Egress Statistics <<< Egress traffic stats Status: up
----------------- . . .
Unicast Packets : 12684472 Hint:0x40000010, FC:0 PLP:0
Multicast Packets: 0 Filter: none
Accounting:
Operational Status 6957 total successful reaps, 0 failed/aborted reap(s).
------------------ 1 reaps in latest reporting interval.
Status: up 1 packets in latest reporting interval.
. . . 6 instances in latest reporting interval.
. . .
root@R6>

------------------------------------------------------------------------------------
--------------- --------------- ----------- ------------ ---- ------------- --------
2133 140052 0 0 0 oc-55 6104
6243516 4761410768 0 0 0 oc-60 19
1060 69447 0 0 0 oc-63 6107
462324 40638435 0 0 0 oc-68 6101
2132 141008 0 0 0 oc-72 6109
2141 141934 0 0 0 oc-75 6108
12736624 9744071242 0 0 0 oc-77 20 <<<20 is R6’s AdjSID label advertised on R6-R8 Link.
------------------------------------------------------------------------------
Total 7 records.
------------------------------------------------------------------------------
FC:0 PLP:0
Filter: none
Accounting:
. . .
root@R6>

ge-0/0/0.0 131 2 <<< Ingress
ge-0/0/1.0 20480446 26842 <<< Egress
lo0.0 0 0

---------------------------

---------------------------
root@R8>

Jvision Header: system: R8:172.16.18.18, slot: 0, time: May 30 16:04:39.705, Ingress Statistics
Init time: May 30 12:03:32 2019 Egress Statistics <<< Egress traffic stats
-----------------
Ingress Statistics <<< Ingress traffic stats Packets: 12682907
------------------ Bytes: 9525523788
------------------
Egress Statistics Status: up
----------------- . . .
Hint:0x40000010, FC:0 PLP:0
Operational Status Filter: none
------------------ Accounting:
Status: up 6987 total successful reaps, 0 failed/aborted reap(s).
. . . 1 reaps in latest reporting interval.
. . .
root@R8>

------------------------------------------------------------------------------------
--------------- --------------- ----------- ------------ ---- ------------- --------
12736941 9718934988 0 0 0 oc-38 16 <<< 16 is R8’s AdjSID label advertised on R8-R9 Link. This is bottom label in stack and it is popped by R8.
------------------------------------------------------------------------------
Total 1 records.
------------------------------------------------------------------------------
FC:0 PLP:0
Filter: none
Accounting:
. . .
root@R8>

root@R9> show isis spring interface traffic-statistics <<< LSP endpoint router hence no Egress Interfaces stats are highlighted.
ge-0/0/0.0 131 2
ge-0/0/1.0 60 1 <<< Ingress
lo0.0 0 0

---------------------------

---------------------------
root@R9>

root@R9> start shell command "cprod -A fpc0 -c \"show agent sensors id 76940\"" . . .
Export: Interval = 2000 msecs, Payload-size = 5000 bytes, Server =
ID: 76940 Type: 1 Name: (IFL) Src: 172.16.18.19:1000, Dst: 172.16.18.1:3000(VRF 0) , Qos = TOS:0x0,
Sensor Data: 505(477) bytes Hint:0x40000010, FC:0 PLP:0
Jvision Header: system: R9:172.16.18.19, slot: 0, time: May 30 16:04:39.137, Filter: none
sequence_number: 6985, sensor_name: Accounting:
IFL:/junos/system/linecard/interface/logical/usage/:/junos/system/linecard/inter 6986 total successful reaps, 0 failed/aborted reap(s).
face/logical/usage/:PFE, version: 1.1 1 reaps in latest reporting interval.
. . . 1 packets in latest reporting interval.
===================================================== 6 instances in latest reporting interval.
Interface = ge-0/0/1.0 (551) <<< Ingress Interface 6986 total packets sent.
Init time: May 30 12:03:32 2019 6986 wraps, 1 reap(s) on average to wrap.
Ingress Statistics <<< Ingress traffic stats . . .
------------------ root@R9>
Packets: 12690944
Bytes: 9527093942
Egress Statistics
-----------------
Packets: 1065
Bytes: 67346
Operational Status
------------------
Status: up
. . .


------------------------------------------------------------------------------------
--------------- --------------- ----------- ------------ ---- ------------- --------
1065 71606 0 0 0 oc-58 9108
------------------------------------------------------------------------------
Total 1 records.
------------------------------------------------------------------------------
FC:0 PLP:0
Filter: none
Accounting:
. . .
root@R9>
Note: Since R9 is Egress router, The bottom label (16) is popped on R8 and
hence the traffic will come as plane IPv4 on R9, hence no label on R9.
SR-TE Telemetry - SR LSP Optimization Using Telemetry
Two Spirent traffic generators are connected on ge-0/0/7 and ge-0/0/8 interfaces of R1. Traffic is coming with destination
address field having IP 3.3.3.10 and it is riding the LSP “R1-to-R9-LSP-AdjSID”. As previously stated, we are doing LSP
optimization based on link utilization. root@R1> show spring-traffic-engineering lsp name R1-to-R9-LSP-AdjSID detail
Interface: ge-0/0/7, Enabled, Link is Up
To: 192.168.1.9
Encapsulation: Ethernet, Speed: 1000mbps
State: Up
Traffic statistics: Current delta
Telemetry statistics:
Input bytes: 19824714 (0 bps) [9908652]
Sensor-name: ingress-R1-to-R9-LSP-AdjSID, Id: 3758096392
. . .
Interface: ge-0/0/8, Enabled, Link is Up
Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A
Encapsulation: Ethernet, Speed: 1000mbps
Traffic statistics: Current delta
SR-ERO hop count: 4
Input bytes: 64484824 (0 bps) [9920548]
Hop 1 (Strict):
. . .
Hop 2 (Strict):
We have configured analytics on NorthStar. Config is on next slide. NAI: IPv4 Adjacency ID, 1.1.1.17 -> 1.1.1.18
Hop 3 (Strict):
Hop 4 (Strict):
root@R1>

SR-TE Telemetry - SR LSP Optimization Using Telemetry Cont…
Note: Due to aggressive reroute interval, the LSP is getting optimized

every min. We have configured link utilization to 1% of link total BW.
Since the total BW of the link is 1 Gb, The link utilization would come
around 10Mb. We are sending 20Mbps, Hence LSP will get optimize
every configured reroute interval (1 min).

Note: Provision is rescheduled before the expiration of the configured

1 min reroute interval. LSP will reroute after expiration of 1 mins.

PCS Server Logs “/opt/northstar/logs/pcs.log” confirms that optimization of LSP is based on link utilization.
2019 May 30 10:47:17.929284 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x000060b2 R1-to-R9-LSP-AdjSID@192.168.1.1 (172.16.18.11),
from=192.168.1.1 to=192.168.1.9 lsp add/update event lsp_state=ACTIVE admin_state=UP, delegated=true, setup_type=RSVP, path_type=primary path, priority=0/0 bw=0
metric=0, admin group bits exclude=0 include_any=0 include_all=0, control_type=PCE initiated, sr_ERO=192.168.1.1--1.1.1.2--1.1.1.18--1.1.1.30--1.1.1.42 (full
ERO=(1.1.1.1,1.1.1.2,28), (1.1.1.17,1.1.1.18,17), (1.1.1.29,1.1.1.30,20), (1.1.1.41,1.1.1.42,16))
2019 May 30 10:47:17.929291 pcs-q-pod13 PCServer [NorthStar][PCServer][tunnelEvent] msg=0x00004027 LSP action, STATE_CHANGE id=3706722085 event=PCEP LSP event
2019 May 30 10:47:17.929295 pcs-q-pod13 PCServer [NorthStar][PCServer][tunnelEvent] msg=0x0000400a R1-to-R9-LSP-AdjSID@192.168.1.1 to=192.168.1.9 bw=1 pri=7
pre=7 type=R,SR,!PCCROUTED,A2Z,LSPTYPE=PCE_INITIATED,TUNNELID=8 path= current_path=1.1.1.2-1.1.1.18-1.1.1.30-1.1.1.42 op_state=ACTIVE ns_lsp_id =25
LSP Optimization Starting here due to link utilization violation.

2019 May 30 10:48:12.453820 pcs-q-pod13 PCServer [NorthStar][PCServer][Route] msg=0x00003006 Rerouting R1-to-R9-LSP-AdjSID@R1
2019 May 30 10:48:12.454945 pcs-q-pod13 PCServer [NorthStar][PCServer][tunnelEvent] msg=0x00004027 LSP action, STATE_CHANGE id=3706722140 event=reprovision
scheduled:link utilization violation delay=0 minutes controller_state=Provision_Rescheduled
pre=7 type=R,SR,!PCCROUTED,A2Z,LSPTYPE=PCE_INITIATED,TUNNELID=8 path= op_state=ACTIVE ns_lsp_id =25 CONTROLLER_STATE=Provision_Rescheduled
. . .
2019 May 30 10:48:17.881763 pcs-q-pod13 PCServer [Debug][PCServer] checking LSPs for reprovisioning
2019 May 30 10:48:17.881808 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x00006015 R1-to-R9-LSP-AdjSID@R1 needs reprovisioned.
livestatus=0x00002401 provisionstatus=0x00000208
2019 May 30 10:48:17.881828 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x00006004 -- reprovision R1-to-R9-LSP-AdjSID@R1 , Re-provisioning
triggered
2019 May 30 10:48:17.881832 pcs-q-pod13 PCServer [NorthStar][PCServer][tunnelEvent] msg=0x00004027 LSP action, UPDATE id=3706722145 event=Placed setup order in
provisioning queue controller_state=Provision_Rescheduled(now)
pre=7 type=R,SR,!PCCROUTED,A2Z,LSPTYPE=PCE_INITIATED,TUNNELID=8 path= op_state=ACTIVE ns_lsp_id =25 CONTROLLER_STATE=Provision_Rescheduled(now)
2019 May 30 10:48:17.885148 pcs-q-pod13 PCServer [Debug][PCServer] checking Demands for reprovisioning
2019 May 30 10:48:17.885155 pcs-q-pod13 PCServer [Debug][PCServer] New LSP request request_id 176320255 for R1-to-R9-LSP-AdjSID@R1
2019 May 30 10:48:17.885233 pcs-q-pod13 PCServer [Debug][PCServer] LSP R1-to-R9-LSP-AdjSID HOP[0] Link:: 1.1.1.46
2019 May 30 10:48:17.888232 pcs-q-pod13 PCServer [Debug][PCServer] LSP R1-to-R9-LSP-AdjSID HOP[1] Link: 1.1.1.49
. . .

. . .
2019 May 30 10:48:17.888297 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x00006083 Provisioning modify order on R1-to-R9-LSP-
AdjSID@0000.0000.0001 pathname=
. . .
2019 May 30 10:48:17.888307 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x000060c2 [->TopoServer] PCEP push lsp configlet, action=MODIFY
2019 May 30 10:48:17.888324 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x00006066 action=MODIFY {"lsps":[{"request-id":176320255,"name":"R1-
to-R9-LSP-AdjSID","from":"192.168.1.1","node_id_int":1,"to":"192.168.1.9","remote_node_id_int":10,"management-ip":"10.49.231.31","path-setup-
type":"segment","pcc":"172.16.18.11","bandwidth":"1","local-protection":false,"type":"primary","path-attributes" : {"admin-group" : {"exclude" : 0,"include-all" :
0,"include-any" : 0},"setup-priority" : 7,"reservation-priority" : 7,"sr-ero":[{"sid":27,"local-ipv4-address":"1.1.1.45","remote-ipv4-address":"1.1.1.46"},
{"sid":17,"local-ipv4-address":"1.1.1.50","remote-ipv4-address":"1.1.1.49"},{"sid":19,"local-ipv4-address":"1.1.1.33","remote-ipv4-address":"1.1.1.34"},
{"sid":17,"local-ipv4-address":"1.1.1.37","remote-ipv4-address":"1.1.1.38"}],"footer" : "none"}}]}
2019 May 30 10:48:17.888332 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x00006067 provisioning order sent
2019 May 30 10:48:17.888336 pcs-q-pod13 PCServer [NorthStar][PCServer][tunnelEvent] msg=0x00004027 LSP action, UPDATE id=176320255 event=Provisioning
Order(MODIFY) sent request_id=176320255 controller_state=PENDING
CONTROLLER_STATE=PENDING
. . .
2019 May 30 10:48:17.908690 pcs-q-pod13 PCServer [NorthStar][PCServer][<-TopoServer] msg=0x00006055 R1-to-R9-LSP-AdjSID@172.16.18.11, PCE LSP respond message
request_id=176320255 resp_code=0 PCE_ERR_NONE
2019 May 30 10:48:17.908852 pcs-q-pod13 PCServer [NorthStar][PCServer][tunnelEvent] msg=0x00004027 LSP action, STATE_CHANGE id=176320255 event=PCE response
request_id=176320255 resp_code=PCE_ERR_NONE controller_state=PCC_PENDING
CONTROLLER_STATE=PCC_PENDING
. . .
2019 May 30 10:48:17.938743 pcs-q-pod13 PCServer [NorthStar][PCServer][LSPProvisioning] msg=0x000060b2 R1-to-R9-LSP-AdjSID@192.168.1.1 (172.16.18.11),
from=192.168.1.1 to=192.168.1.9 lsp add/update event lsp_state=ACTIVE admin_state=UP, delegated=true, setup_type=RSVP, path_type=primary path, priority=0/0 bw=0
metric=0, admin group bits exclude=0 include_any=0 include_all=0, control_type=PCE initiated, sr_ERO=192.168.1.1--1.1.1.46--1.1.1.49--1.1.1.34--1.1.1.38 (full
ERO=(1.1.1.45,1.1.1.46,27), (1.1.1.50,1.1.1.49,17), (1.1.1.33,1.1.1.34,19), (1.1.1.37,1.1.1.38,17))
2019 May 30 10:48:17.938748 pcs-q-pod13 PCServer [NorthStar][PCServer][tunnelEvent] msg=0x00004027 LSP action, STATE_CHANGE id=3706722145 event=PCEP LSP event

SR-TE Telemetry - Checking Link Utilization

SR-TE Telemetry - Checking SID Utilization

SR-TE Telemetry - Checking LSP Utilization

SR-TE Telemetry - Checking LSP Utilization
No per SR policy ingress statistics available in

NorthStar version 4.3. As per Engineering SR LSP
Stats will be supported from NorthStar version 5.0
onwards.

SEGMENT ROUTING OAM:
MPLS PING AND TRACEROUTE FOR SPRING

Why IP Ping Does not Work For LSP Paths?
Why define new methods for failure detection in MPLS, instead of just using IP ping for the traffic using the LSP? For example, to check the
health of the LSP set up by the LDP from R1 to R5 in below diagram (there is no LDP between R2-R6 and R5-R6), why not simply send
periodic IP ping traffic to R5’s loopback address? The answer is: because such an approach may not detect all failures. Let's see three
different scenarios to make the point clear.
R1 R2 R3 R4 R5
Label advertised Label advertised Label advertised Label advertised
from R2 to R1 for from R3 to R2 for from R4 to R3 for from R5 to R4 for
R5’s loopback R5’s loopback R5’s loopback R5’s loopback
L2 L3 L4 L5
R6
First scenarios: Imagine all the links are having equal metrics. Now let's assume that LSP endpoint IP address (R5’s loopback) is not
resolving on the LDP LSP on R1. As long as IGP connectivity is there, IP ping probes destined to R5’s loopback will follow the IGP path and
they will traverse via R1  R2  R6  R5 and not the LDP LSP path. The probes will return success, but have we validated the LSP? No.
Second scenarios: Now assume there are having 10 RSVP LSP going from R1 to R5 and on R1 we have ECMP enabled. The LSP endpoint
IP (R5’s loopback) is resolving over 10 LSPs at R1. Let’s say we want to trace first LSP. In case of normal IPv4 ping (or IPv4 trace) probes,
the first ping can go to first LSP and the second probe can go to any other LSP, but each time probes will return success. Again you see we
are not be able to trace the RSVP LSP using simple IPv4 probes.

Why IP Ping Does not Work For LSP Paths? Cont…
Third scenarios: This time, to check the health of the LSP set up by the LDP from R1 to R5 in below diagram, we will send
periodic IP ping traffic to R5’s loopback address and ensure that this traffic is forwarded over the LSP. Again such an approach
may not detect all failures.
R1 R2 R3 R4 R5
L2 L3 L4 L5
Now imagine a probe traveling on the LSP with label L2 on the hop between R1 and R2. Now assume that at node R2, the
forwarding state is such that the label is popped instead of being swapped to L3. This could happen, for example, because of a
corruption in the forwarding state entry, but may also be the result of a legal protocol operation, when LDP-independent control
is used. In any case, when the traffic arrives at R2, the label is popped. The packet continues its journey to R5 as a pure IP packet
and the failure in the LSP is not detected.
Therefore, what is needed is a way to do two things:
a. Validate the forwarding of traffic in the data plane and
b. Verify the data-plane state against the control-plane state.

How LSP Ping Works?
Similar to normal ping, LSP Ping uses probe packets, called MPLS echo requests, and expects to receive back acknowledgments,
called MPLS echo replies. Complete details of the procedure and packets are provided in RFC 8029.
The idea behind LSP Ping is simple. Verify that a packet that belongs to a particular forwarding equivalence class (FEC) actually
ends its MPLS path on the LSR that is the egress for that FEC. In the topology example of third scenario, the FEC is R5’s
loopback address. In the failure scenario, when the label is popped at R2, the MPLS path ends on router R2 instead of router R5.
Because R2 is not the egress for the FEC, the check fails, and the error is detected. From this description, several requirements
become apparent regarding the probes and their handling:
a. The probes must follow exactly the same path as the data packets.
To ensure that the probes follow the same path as the data packets, they are forwarded using the same label stack as the data
forwarded over the LSP they are testing.

How LSP Ping Works?
b. The probes must be delivered to the control plane of the LSR on which they ended their MPLS path for verification.
To allow delivery of the probe to the control plane of the egress LSR, the router-alert option is set in the IP header. Due to
PHP R4 will POP the label and native IPv4 packet will be send to R5. R5 will see the router-alert option in IP packet and it
will send the probe packet to its control plane. An interesting challenge arises with regards to the IP destination address. The
problem is that the address of the LSR, which is the egress of the LSP, may not always be known. For example, LDP may
advertise a label binding for an arbitrary FEC that is not necessarily associated with any address on the router. For this
reason, the destination address is a random address in the 127/8 range. The 127/8 address prevents the IP packet from being
forwarded over IP to its destination if the LSP is broken. If any transit router (let’s say R2) wants to forward the IP packet
after Popping of label, then it can not forward that packet to anywhere as 127/8 range is not routable range and it belongs to
the host. R2 will punt the packet to control plane so that correct error code can be sent to the ingress router.
c. The probes must contain enough information about the FEC to allow the receiving LSR to determine if it is indeed the correct
egress.
To facilitate the check that the egress LSR must perform, the probe contains information about the FEC under test. This
information is carried in the payload of the UDP packet and is encoded as a set of TLVs. The information is different based on
the type of FEC. Please see RFC 8287 for more details on the different types of TLVs.
To inform the originator of the probe of the result of the FEC test, the receiver must know its address. Therefore, the source
address of the MPLS echo request probe is set to a routable address on the originator of the probe.
How LSP Ping Works? Cont…
An LSR receiving an MPLS echo request validates it and sends a reply using an MPLS echo reply packet. The reply is also a UDP
packet, sent to the source address of the MPLS echo request and forwarded in accordance with the route that is available for its
destination address. Thus, the reply packet may travel as pure IP or it may be encapsulated in an LSP, if the path to the
destination is through an LSP. The reply contains status information, such as success or failure and the reason for the failure.
When the originator of the echo request receives this reply, it matches it against the outstanding requests and reports the
appropriate status for the LSP under test.

How LSP Traceroute Works?
An MPLS echo request test a particular LSP. The LSP to be tested is identified by the FEC stack TLV in MPLS echo request. In Traceroute,
An MPLS echo request must have a Target FEC Stack TLV that describes the FEC Stack being tested. An MPLS echo request indicates which
FEC is under test with the FEC Stack TLV. Loosely speaking FEC is an identification of the MPLS session (e.g RSVP soft state) uniquely on a
router. For example, if an LSR R1 has an LDP mapping for R5’s loopback (say, label L2), then to verify that label L2 does indeed reach
egress LSR R5 that announced this prefix via LDP, R2 can send an MPLS echo request having a FEC stack TLV carrying one LDP IPv4
prefix sub-TLV in it, with prefix R5’s loopback, and send the echo request with a label of L2.
The Target FEC Stack TLV is a list of sub-TLVs. Type of sub-TLV in FEC stack TLV will be determined by the MPLS protocol used, see RFC
8029. Each sub-TLV in the Target FEC Stack TLV indicates one entry in the label stack (no of MPLS labels that ingress router put in to the
packet). The first entry in the list corresponds to the top label in the label stack, and so on. Ingress router requests a transit router to
validate the target FEC stack TLV representing the MPLS session on that transit router.
Sub-TLVs inside FEC stack TLV have different-different information (information describing LSP) for different-different protocols. Below
are some of the common type of sub-TLVs that are carried in FEC stack TLV for the MPLS protocols:
Sub-TLV Type Value Field Description
1 LDP IPv4 prefix The LDP IPv4 prefix is a FEC whereby LDP has advertised an IPv4 prefix.
RSVP IPv4 LSP is a FEC that a traffic engineering (TE) tunnel maps. Carries RSVP LSP details
3 RSVP IPv4 LSP
(i.e. Tunnel endpoint address, Tunnel IDs, LSP ID etc.)
16 Nil FEC For labels which does not have explicit FEC associated.
34 IPv4 IGP-Prefix Segment ID Carries IPv4 prefix to which the Segment ID is assigned. Normally Egress router’s loopback IP.
36 IGP-Adjacency Segment ID Carries local and Remote Interface, Local and Remote Router ID for the segment.
How LSP Traceroute Works? Cont…
With the LSP Trace, the idea is not just to report the hops in the path, but also determine if there is a mismatch between the
forwarding and control planes. To accomplish this, three conditions must be satisfied:
a. The MPLS echo request probe must be processed by each hop in the path. Ingress router achieve it by setting TTL value. So in
case of MPLS ping (or trace probe), router alert bit is also set in IPv4 header of the probe so that an egress router can send
the probe packet to its control plane when it receive the native IPv4 packet from PHP router.
b. To identify which LSP to test and validate. Ingress router achieve it by putting “FEC stack TLV” in MPLS echo request.
c. To identify whether MPLS trace probe packet has been received on the expected interface or not, Every transit node should
validate “Downstream Mapping TLV”. If this validation fails, then control plane and data plane are not in sync and that
router will report the error back to Ingress node.
Let's explain the process by using LDP LSP example. To trace the path of an LDP LSP, an MPLS echo request is sent from the
head end, including the Target FEC stack TLV containing LDP IPv4 prefix sub-TLV, encapsulated with the correct label stack for
the LSP, in this case the LDP label. To ensure that the echo request is received by each hop in the path, several such echo
requests are sent, with increasing TTL values, just like a normal traceroute.
To allow the transit LSR to check the control plane against the data plane, the LSR must know whether it is a correct recipient of
the probe. Therefore, the MPLS echo request packet contains, in addition to the FEC stack TLV for the FEC under test, the list of
acceptable recipients of the packet.
This list is encoded in the “Downstream Mapping TLV” and contains identifying information (such as the router ID, label and
interface) of all the possible downstream neighbors for the FEC, from the point of view of the upstream LSR. The LSR processing
the echo request determines if it is a valid recipient of the traffic if it is listed in the Downstream Mapping TLV, with the correct
label and interface information. In short “Downstream Mapping TLV” is used by transit routers to identify whether they are
receiving the MPLS request packet on correct interface or not. If the check fails, it informs the head end of the failure in the echo
reply, thus pinpointing the location of the problem. If the check succeeds, the LSR extracts all its valid downstream neighbors
and labels for the FEC under test and sends this information in the echo reply, encoded in a (per-neighbor) Downstream
Mapping TLV. This TLV is sent in the next echo request that will be sent with a TTL greater by 1, and therefore will reach its
downstream neighbors.
The Downstream Mapping TLV is an optional TLV that indicates who the downstream LSR is, which downstream or outgoing
label is used, by which protocol the label was assigned, and some Multipath information. Downstream Mapping TLV is not used
if the replying LSR is the egress LSR for the FEC.

Why do we do validation through DDMT TLV when we are doing validation through FEC stack TLV? In short why we need two types of
validation in MPLS LSP Trace: Lets understand with two example.
First Case: Assume that there is LDP enabled on all the routers.
R1 R2 R3 R4 R5
L2 L3 L4 L5
Label advertised Label advertised
from R6 to R4 for from R5 to R6 for
R5’s loopback R5’s loopback
L6 L7
R6
R1 to R5 path through R2, R3 and R4 is having lower metric compared to the other path through R2, R6. MPLS LSP Trace is expected to
traverse R1 to R5 through R2, R3 and R4. R2 is expected to send the MPLS trace probe to R3 but if it sends the probe packet incorrectly to
R6 (due to incorrect programming on R2). R6 looks in to the probe packet. First, FEC Stack validation will happen on R6 and it will be
successful. Remember in LDP case the FEC Stack TLV will contain the LDP IPv4 prefix associated with the R5 (in this case R5’s loopback)
and R6 can validate it without any issue. let’s assume that incorrect programming on R2 happens somewhere between Probe 1 and Probe 2.
Now DDMT TLV validation will happen and this DDMT TLV validation will fail on R6 as in this case, DDMT TLV will have info related to
the R2-R3 link. R6 will look in to the DDMT TLV and it will identify that it is not the correct recipient of the Probe. R6 will return the
proper error code to R1. Hence LSP trace will be not succeed.
Second Case: Assume that there is LDP enabled on all the routers except R6.
R1 R2 R3 R4 R5
L2 L3 L4 L5
R6
MPLS LSP Trace is expected to traverse R1 to R5 through R2, R3 and R4. R2 is expected to send the MPLS trace probe to R3 but if it send
the probe packet incorrectly to R6 (due to incorrect programming on R2). R6 looks in to the probe packet. First, FEC Stack validation will
happen on R6 and it will fail as R6 does not understand the LDP FEC Stack TLV. Hence the first validation itself will fail. R6 will return the
proper error code to R1. LSP trace will be not succeed.

R1 R2 R3 R4 R5
L2 L3 L4 L5
MPLS Echo request
FEC-Stack - R5’s loopback This process is for an LDP-signaled LSP between R1 and R5. R1 sends an
DDMT TLV having IP L2 TTL = 1
address of R2’s interface MPLS echo request with a TTL value equal to 1. The request contains an
connecting to R1, Label L2
LDP IPv4 prefix sub-TLV for FEC R5 and a Downstream Mapping TLV
MPLS Echo Reply: OK
DDMT TLV having IP address of R3’s
listing neighbor R2, as well as the label used by R2, L2. When the TTL
interface connecting to R2, Label L3 expires at R2, the echo request is delivered to the control plane of router
MPLS Echo request
R2 for processing, along with the label stack with which the packet
FEC-Stack - R5’s loopback
DDMT TLV from Previous L2 TTL = 2
arrived. LSR R2 checks if it is one of the routers in the Downstream
Echo reply containing Mapping TLV. R2 also validate the FEC listed in FEC Stack TLV. Because
label L3
the check is positive, R2 builds a new Downstream Mapping TLV, listing
MPLS Echo Reply: OK
DDMT TLV having IP address of R4’s all its valid downstream neighbors for LDP FEC R5 (in this case, router
interface connecting to R3, Label L4
R3 with label L3) and sends it back to the head end in the echo reply.
This DDMT TLV received by R2 is included in the next echo request

probe sent by the head end, which is sent with TTL equal to 2 and will
expire at R3. When this probe is processed at R3, the same process will be
applied and so on (the rest of the steps are not shown in the figure). In
this manner, the path of the LSP can be traced and at the same time the
location of any failure can be reported.
How Hierarchical LSP Traceroute Works?
LDP (or L-ISIS) Tunnel RSVP Tunnel
over RSVP Tunnel
R1 R2 R3 R4 R5
Hierarchical Tracing: Lets assume that there is a RSVP signaled LSP from R2 to R4 and that the LDP signaled LSP for R1’s loopback is
tunneled over it. When R1 traces the path towards R5, it does so using the LDP IPv4 prefix sub-TLV inside Target FEC stack TLV in the
echo request. Router R2 can successfully perform the FEC validation, but router R3, which is a pure RSVP node with no knowledge of the
LDP tunnel, cannot do the same.
Rather than returning a failure, routers in the path informs the head end that a different sub-TLV type (RSVP IPv4 Session Query sub-TLV)
needs to be used in the FEC stack TLV when sending the next probe, by encoding this information “FEC stack change sub-TLV” and RSVP
label in the Downstream Mapping TLV putting all the details of the new RSVP FEC. Also protocol field of Label stack sub-TLV in DDMT
TLV of the echo reply would indicate that the upstream label would belong to RSVP-TE. In the example above, router R2, which is the RSVP
tunnel head end, informs router R1 that for the next echo-request packet an RSVP sub-TLV rather than the LDP sub-TLV should be used
and the validation of the echo request can be successfully completed.
RSVP validation happens on the R3 and R4. MPLS probes originated at the R1 contains RSVP IPv4 Session Query sub-TLV (3) to describe
RSVP hops and below RSVP IPv4 Session Query sub-TLV (3) these probes also has LDP IPv4 prefix sub-TLV. At the RSVP endpoint, R4
validates RSVP IPv4 Session Query sub-TLV in DDMT TLV. R4 is egress for the RSVP tunnel, it returns label 3 (in DDMT TLV) in Echo
reply. We are still having validation pending for the LDP IPv4 prefix sub-TLV as well on R4, R1 sends one more Echo request with same
TTL to R4 again containing LDP IPv4 prefix sub-TLV in DDMT TLV. R4 validates this LDP IPv4 prefix TLV and again returns label 3 in
DDMT TLV in echo reply. Label 3 for the validation of LDP IPv4 prefix sub-TLV also because in data plane packet is forwarded based on
RSVP PHP label. Lab Example of hierarchical tracing provided later in the presentation.
LSP Ping and Traceroute Example
From our base topology:
R1 - lo0.0- ge-0/0/0 ge-0/0/0 R4 - lo0.0- ge-0/0/3 ge-0/0/3 R5 - lo0.0- ae0 ae0 R7 - lo0.0- ge-0/0/0 ge-0/0/0 R9 - lo0.0-
192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.21/30 1.1.1.22/30 192.168.1.5/32 1.1.1.25/30 1.1.1.26/30 192.168.1.7/32 1.1.1.37/30 1.1.1.38/30 192.168.1.9/32
SL: 1000 L.Out L.In SL: 4000 L.Out L.In SL: 5000 L.Out L.In SL: 7000 L.Out SL: 9000
Index: 101 26 26 Index: 104 22 22 Index: 105 23 23 Index: 107 3 Index: 109
root@R1> ping mpls ldp 192.168.1.9 source 192.168.1.1 detail root@R1> traceroute mpls ldp 192.168.1.9 source 192.168.1.1 no-resolve
Request for seq 1, to interface 334, label 26, packet size 80 Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16
Reply for seq 1, return code: Egress-ok, time: 5.279 ms source 192.168.1.1
Local transmit time: 2019-06-01 15:42:07 UTC 335.281 ms
Remote receive time: 2019-06-01 15:42:07 UTC 340.560 ms ttl Label Protocol Address Previous Hop Probe Status
Request for seq 2, to interface 334, label 26, packet size 80 1 26 LDP 1.1.1.2 (null) Success
Reply for seq 2, return code: Egress-ok, time: 5.836 ms FEC-Stack-Sent: LDP
Local transmit time: 2019-06-01 15:42:08 UTC 336.311 ms ttl Label Protocol Address Previous Hop Probe Status
Remote receive time: 2019-06-01 15:42:08 UTC 342.147 ms 2 22 LDP 1.1.1.22 1.1.1.2 Success
Request for seq 3, to interface 334, label 26, packet size 80 FEC-Stack-Sent: LDP
Reply for seq 3, return code: Egress-ok, time: 5.039 ms ttl Label Protocol Address Previous Hop Probe Status
Local transmit time: 2019-06-01 15:42:09 UTC 334.265 ms 3 23 LDP 1.1.1.26 1.1.1.22 Success
Remote receive time: 2019-06-01 15:42:09 UTC 339.304 ms FEC-Stack-Sent: LDP
Request for seq 4, to interface 334, label 26, packet size 80 ttl Label Protocol Address Previous Hop Probe Status
Reply for seq 4, return code: Egress-ok, time: 9.988 ms 4 3 LDP 1.1.1.38 1.1.1.26 Egress
Local transmit time: 2019-06-01 15:42:10 UTC 329.478 ms FEC-Stack-Sent: LDP
Remote receive time: 2019-06-01 15:42:10 UTC 339.466 ms
Request for seq 5, to interface 334, label 26, packet size 80 Path 1 via ge-0/0/0.0 destination 127.0.0.64
Reply for seq 5, return code: Egress-ok, time: 5.631 ms
Remote receive time: 2019-06-01 15:42:11 UTC 334.048 ms root@R1>
--- lsping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss Note: Label and Probe status are extracted from the received echo reply packet from
each hop. Success means transit router and Egress is self explanatory.
root@R1>

MPLS Echo Packet details
An MPLS echo request/reply is a (possibly labeled) IPv4 or IPv6 UDP packet; the contents of the UDP packet have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version Number: 1
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply Mode | Return Code | Return Subcode| Flags: Three flags are defined: the R, T, and V bits; the rest MUST be set to zero.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1. The V (Validate FEC Stack) flag is set to 1 if the sender wants the receiver to
| Sequence Number | perform FEC Stack validation; if V is 0, the choice is left to the receiver.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. The T (Respond Only If TTL Expired) flag MUST be set only in the echo
| TimeStamp Sent (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
request packet by the sender. If the T flag is set to 1 in an incoming echo
| TimeStamp Received (seconds) | request, and the TTL of the incoming MPLS label is more than 1, then the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ receiving node MUST drop the incoming echo request and MUST NOT send
| TimeStamp Received (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ any echo reply to the sender. This flag MUST NOT be set in the echo reply
| TLVs ... | packet. If this flag is set in an echo reply packet, then it MUST be ignored.
. .
. .
. . 3. The R (Validate Reverse Path) When this flag is set in the echo request, the
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Responder SHOULD return reverse-path FEC information.
The Message Type: Can be either MPLS Echo Request (Type 1) or MPLS Echo Reply (Type 2).
Reply Mode: The Address Type indicates if the interface is numbered or unnumbered. For IPv4 Numbered, the type is 1.

MPLS Echo Packet details Cont… TLV Type # Value Field
Reply Mode: can take one of the below values. 1 Target FEC Stack
2 Downstream Mapping (Deprecated)
Value Meaning 3 Pad
4 Unassigned
1 Do not reply 5 Vendor Enterprise Number
2 Reply via an IPv4/IPv6 UDP packet 6 Unassigned
3 Reply via an IPv4/IPv6 UDP packet with Router Alert 7 Interface and Label Stack
4 Reply via application-level control channel 8 Unassigned
9 Errored TLVs
Return Code: Provided in the Downstream Detailed Mapping TLV definition. 10 Reply TOS Byte
20 Downstream Detailed Mapping
Sender's Handle: The Sender Handle field is added by the sender in the echo request. The recipient puts the same value back in the echo reply. The
sender handle is relevant only to the sender, which uses the value to match the echo reply against the echo request. The value remains the same for all
counts of a single ping.
Sequence Number: The Sequence Number is assigned by the sender of the MPLS echo request and can be (for example) used to detect missed
replies.
Time Stamp: The Time Stamp Sent is the time of day (according to the sender's clock) in 64-bit NTP timestamp format when the MPLS echo request
is sent. The Time Stamp Received in an echo reply is the time of day (according to the receiver's clock) in 64-bit NTP timestamp format in which the
corresponding echo request was received.
TLV Types: The mentioned TLV types in the green area are defined. If Trace is successful, then we normally see Target FEC Stack TLV (1) and
Downstream Detailed Mapping (20).

MPLS Echo Packet details Cont…
Target FEC Stack TLV: A Target FEC Stack is a list of sub-TLVs. The number of elements is Sub-Type Value Field
determined by looking at the sub-TLV length fields. Note that this TLV defines a stack of FECs, the
1 LDP IPv4 prefix
first FEC element corresponding to the top of the label stack, etc. Below we have explained sub- 2 LDP IPv6 prefix
TLVs you will see normally in SR OAM. 3 RSVP IPv4 LSP
4 RSVP IPv6 LSP
5 Unassigned
1. NIL FEC sub-TLV: The Nil FEC Stack is defined to allow a Target FEC Stack sub-TLV to be
6 VPN IPv4 prefix
added to the Target FEC Stack to account for labels which does not have any explicit FEC 7 VPN IPv6 prefix
associated with them so that proper validation can still be performed. In case of SR NIL FEC 8 L2 VPN endpoint
will also be used for any SR-TE tunnel (BGP-SR-TE tunnel and PCEP tunnel) that consists of 9 "FEC 128" Pseudowire - IPv4 (deprecated)
10 "FEC 128" Pseudowire - IPv4
segment identifiers for which there are no sub-TLVs defined in Target FEC stack.
11 "FEC 129" Pseudowire - IPv4
12 BGP labeled IPv4 prefix
There is no Target FEC stack TLV defined for Static SR paths (Static SR paths which does not 13 BGP labeled IPv6 prefix
have L-ISIS learned labels or the labels which are nor present in TED). So NIL FEC defined in 14 Generic IPv4 prefix
15 Generic IPv6 prefix
LSP ping RFCs (RFC 4379 or RFC 8029) will be used as the FEC in Target FEC stack for static 16 Nil FEC (labels with no explicit FEC associated)
segment identifiers. Routers do not attempt validation for the NIL FEC so there are no errors 24 "FEC 128" Pseudowire - IPv6
returned during LSP traceroute or LSP ping - yet all the paths to the egress are covered for LSP 25 "FEC 129" Pseudowire - IPv6
traceroute. 34 IPv4 IGP-Prefix Segment ID
35 IPv6 IGP-Prefix Segment ID
36 IGP-Adjacency Segment ID
It is possible that LSP ping echo request packets are mis-forwarded and end on a router that is
not actually the egress. Since NIL FEC does not have any information for validation,
responding router may return success especially when the packet reaches the router with no
NIL FEC TLV Format:
label or just explicit-null label. To avoid this a vendor private TLV will be supported in juniper
routers. This TLV contains correct egress router ID. Any Juniper router that becomes the 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
egress for an LSP ping packet performs validation using this TLV. If the egress address in the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | MBZ |
TLV is any of its addresses router returns Egress Success. Otherwise it returns an appropriate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
return
© 2018 Juniper code indicating an error.
Networks 293
In SPRING-TE, FEC validation is supported only for IGP segment identifiers (OSPF and ISIS) and not for protocols such as LDP, RSVP etc. When LSP
echo request packets are generated FECs are carried in the Target FEC Stack TLV for IGP segment identifiers. LSP Ping/Traceroute MPLS echo
request packets are sent with FECs corresponding to all segments imposed in the label stack. In other words, Once the router know the label, It
consults the TED database and if it is able to find an entry in the TED database, then it creates the FEC (i.e IPv4 IGP-Prefix Segment ID sub-TLV) for
the label. If the router doesn’t find the label in TED database then it simply put NIL FEC. In case of LDP and RSVP their label would not be their in
TED database hence we would put NIL FEC for them (In case of SR LSP riding an RSVP or LDP tunnel). NIL FEC means that the local router doesn’t
understand the label and downstream routers should not do any validation for this FEC and simply ignore it.
2. IPv4 IGP-Prefix Segment ID sub-TLV: Used in LSP Ping and L-ISIS Trace.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Prefix: This field carries the IPv4 Prefix to which the Segment ID is assigned. In case of an Anycast Segment ID, this field will carry the IPv4
Anycast address.
Prefix Length: The Prefix Length field is one octet. It gives the length of the prefix in bits (values can be 1-32).
Protocol: This field is set to 1, if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2, if the responder MUST
perform Egress FEC validation using the Intermediate System to Intermediate System (IS-IS) as the IGP protocol. Set to 0, if the responder can use
any IGP protocol for Egress FEC validation.
Reserved:
© 2018 The
Juniper Networks Reserved field MUST be set to 0 when sent and MUST be ignored on receipt. 294
3. IGP-Adjacency Segment ID sub-TLV: Used in SPRING-TE trace. This sub-TLV is applicable for any IGP-Adjacency.
0 1 2 3 Adj. Type (Adjacency Type): Set to 1 when the Adjacency Segment is a

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parallel Adjacency. Set to 4 when the Adjacency Segment is IPv4 based and is not
| Adj. Type | Protocol | Reserved | a Parallel Adjacency. Set to 6 when the Adjacency Segment is IPv6 based and is
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ not a Parallel Adjacency. Set to 0 when the Adjacency Segment is over an
~ ~
| Local Interface ID (4 or 16 octets) | unnumbered interface.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Remote Interface ID (4 or 16 octets) | Protocol: Set to 1 if the responder MUST perform FEC validation using OSPF as
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the IGP protocol. Set to 2 if the responder MUST perform Egress FEC validation
~ ~
| Advertising Node Identifier (4 or 6 octets) |
using IS-IS as the IGP protocol. Set to 0 if the responder can use any IGP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ protocol for Egress FEC validation.
~ ~
| Receiving Node Identifier (4 or 6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: MUST be set to 0 on send and MUST be ignored on receipt.
Local Interface ID: Local link address (IPv4 or IPv6) that is assigned by the local LSR for a link to which the Adjacency Segment ID is bound.
Remote Interface ID: Remote (downstream neighbor) link address (IPv4 or IPv6) that is assigned by the remote LSR for a link on which the
Adjacency Segment ID is bound.
Advertising Node Identifier: This specifies the Advertising Node Identifier. If Protocol field is set to 1 (OSPF protocol), then it is a 32-bit OSPF
Router ID. If the Protocol field is set to 2 (ISIS protocol), then it is a 48-bit IS-IS System ID. If the Protocol field is set to 0, then is should be zero.
Receiving Node Identifier: This specifies the downstream node identifier. If Protocol field is set to 1 (OSPF protocol), then it is a 32-bit OSPF
Router ID. If the Protocol field is set to 2 (ISIS protocol), then it is a 48-bit IS-IS System ID. If the Protocol field is set to 0, then is should be zero.
Downstream Detailed Mapping TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Transmission Unit (MTU): The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to
the downstream LSR.
Address Type: The Address Type indicates if the interface is numbered or unnumbered. For IPv4 Numbered, the type is 1.
DS Flags: Two flags are defined currently, I and N. Flag I indicate that the replying router SHOULD include an Interface and Label Stack Object in
the echo reply message. Flag N is for Non-IP Packet.
Downstream Address and Downstream Interface Address: In case of Numbered Interfaces both are set to the interface address of the
downstream LSR.

Return code: The Return Code is set to zero by the sender of an echo request. The receiver of said echo request can set it in the corresponding echo reply
that it generates to one of the values specified below other then 14.
Value Meaning
0 No Return Code
1 Malformed echo request received
2 One or more of the TLVs was not understood
3 Replying router is an egress for the FEC at stack-depth <RSC>
4 Replying router has no mapping for the FEC at stack-depth <RSC>
5 Downstream Mapping Mismatch
6 Upstream Interface Index Unknown
7 Reserved
8 Label switched at stack-depth <RSC>
9 Label switched but no MPLS forwarding at stack-depth <RSC>
10 Mapping for this FEC is not the given label at stack-depth <RSC>
11 No label entry at stack-depth <RSC>
12 Protocol not associated with interface at FEC stack-depth <RSC>
13 Premature termination of ping due to label stack shrinking to a single label
14 See DDMAP TLV for meaning of Return Code and Return Subcode
15 Label switched with FEC change
Return Subcode (RSC): contains the point in the label stack where processing was terminated. If the RSC is 0, no labels were processed. Otherwise,
the packet was label switched at depth RSC.

Sub-TLV Length: Total length in octets of the sub-TLVs associated with this TLV. Protocol field codes in Label stack sub-TLV
Sub-TLVs: This section defines the sub-TLVs that MAY be included as part of the Downstream Detailed Value Meaning
Mapping TLV.
0 Unknown
Sub-Type Value Field 1 Static
2 BGP
1 Multipath data 3 LDP
2 Label stack 4 RSVP-TE
3 FEC stack change 5 OSPF
6 ISIS
Multipath data TLV: The multipath data sub-TLV includes Multipath Information. 7-250 Unassigned
251-254Experimental use
Label stack TLV: The Label Stack sub-TLV contains the set of labels in the label stack as it would have 255 Reserved
appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are
explicitly included. The number of label/protocol pairs present in the sub-TLV is determined based on the
sub-TLV data length. When the Downstream Detailed Mapping TLV is sent in the echo reply, this sub-TLV
MUST be included. This TLV defines protocol associated with the label.
FEC stack change TLV: A router MUST include the FEC stack change sub-TLV when the downstream
node in the echo reply has a different FEC Stack than the FEC Stack received in the echo request. One or
more FEC stack change sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The operation
associated with the FEC stack change can be pop or push.

SR OAM (L-ISIS)
Unlike LDP or RSVP which are the other well-known MPLS control plane protocols, segment assignment in Segment Routing
architecture is not hop-by-hop basis. This nature of Segment Routing raises additional consideration for fault detection and
isolation in Segment Routing network.
The basic idea is to verify the segment-routed MPLS path by sending the “MPLS echo request” packet with entire label-stack
along the same data path as the data traffic. An MPLS echo request carries Forwarding Equivalence Class (FEC) of the segment-
routing path is being verified. This echo request is forwarded just like any other packet based on the label-stack.
In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control
plane of the end node, which then verifies whether it is indeed an Egress for the FEC.
In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit node along the MPLS path, which
performs various checks (Control Plane and Data Plane both) that it is indeed a transit node for this path; this transit node also
returns further information that helps check the control plane against the data plane, i.e., that forwarding matches what the
segment-routing protocols determined as the path.
SR LSP ping/traceroute utility can be used for SR-LDP stitching and SR over RSVP scenarios.

SR OAM (L-ISIS) Cont…
We also use a vendor private TLV in MPLS Echo request packets. This TLV contains correct egress router ID. Any Juniper router
that becomes the egress for an LSP ping packet performs validation using this TLV. If the egress address in the TLV belongs to
one of the addresses of the egress router then egress router returns Egress Success. Otherwise it returns an appropriate return
code indicating an error.
Below are the ping and traceroute commands supported by Junos:
ping mpls segment-routing isis (or ospf) <FEC> source <Source_IP> (detail)
ping mpls segment-routing isis (or ospf) <FEC> source <Source_IP> stitched-protocol ldp (detail) <<< In case of SR->LDP stitching
ping mpls segment-routing isis (or ospf) <FEC> source <Source_IP> stitched-protocol isis (detail) <<< In case of LDP->SR stitching
traceroute mpls segment-routing isis (or ospf) <FEC> source <Source_IP> (detail)
Let’s try to traceroute R9 from R1. root@R1> show route 192.168.1.9 table inet.0

192.168.1.9/32 *[L-ISIS/14] 4d 03:57:01, metric 40

> to 1.1.1.2 via ge-0/0/0.0, Push 4109
to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.46 via ge-0/0/4.0, Push 3109
[IS-IS/18] 4d 03:57:01, metric 40
> to 1.1.1.2 via ge-0/0/0.0
to 1.1.1.6 via ge-0/0/1.0
to 1.1.1.46 via ge-0/0/4.0
root@R1>
SR OAM (L-ISIS) Example
root@R1> traceroute mpls segment-routing isis 192.168.1.9 source 192.168.1.1
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16
source 192.168.1.1
ttl Label Protocol Address Previous Hop Probe Status

1 4109 ISIS 1.1.1.2 (null) Success <<< Success means transit router validating itself successfully.
FEC-Stack-Sent: ISIS
2 6109 ISIS 1.1.1.14 1.1.1.2 Success <<< Success means transit router validating itself successfully.
3 7109 ISIS 1.1.1.34 1.1.1.14 Success <<< Success means transit router validating itself successfully.
4 3 ISIS 1.1.1.38 1.1.1.34 Egress <<< Egress is self explanatory.
. . .
Path 1 via ge-0/0/0.0 destination 127.0.0.64 <<< Diff 127 range IP for each path
ttl Label Protocol Address Previous Hop Probe Status 1 3109 ISIS 1.1.1.46 (null) Success
1 2109 ISIS 1.1.1.6 (null) Success FEC-Stack-Sent: ISIS
FEC-Stack-Sent: ISIS ttl Label Protocol Address Previous Hop Probe Status
ttl Label Protocol Address Previous Hop Probe Status 2 6109 ISIS 1.1.1.49 1.1.1.46 Success
2 5109 ISIS 1.1.1.10 1.1.1.6 Success FEC-Stack-Sent: ISIS
ttl Label Protocol Address Previous Hop Probe Status 3 7109 ISIS 1.1.1.34 1.1.1.49 Success
3 7109 ISIS 1.1.1.26 1.1.1.10 Success FEC-Stack-Sent: ISIS
ttl Label Protocol Address Previous Hop Probe Status 4 3 ISIS 1.1.1.38 1.1.1.34 Egress
4 3 ISIS 1.1.1.38 1.1.1.26 Egress FEC-Stack-Sent: ISIS
. . .
root@R1>
SR OAM (L-ISIS) Example Explanation for first Path
R1 - lo0.0- R4- lo0.0- R6 - lo0.0- R7 - lo0.0- R9 - lo0.0-
192.168.1.1/32 L.Out: 4109 L.In: 4109 192.168.1.4/32 L.Out: 6109 L.In: 6109 192.168.1.6/32 L.Out: 7109 L.In: 7109 192.168.1.7/32 L.Out: 3 IPv4 192.168.1.9/32
SL: 1000 ge-0/0/0 ge-0/0/0 SL: 4000 ge-0/0/0 ge-0/0/0 SL: 6000 ge-0/0/0 ge-0/0/0 SL: 7000 ge-0/0/0 ge-0/0/0 SL: 9000
Index: 101 1.1.1.1/30 1.1.1.2/30 Index: 104 1.1.1.13/30 1.1.1.14/30 Index: 106 1.1.1.33/30 1.1.1.34/30 Index: 107 1.1.1.37/30 1.1.1.38/30 Index: 109
MPLS Echo Request: Probe

1
IGP IPv4 prefix sub-TLV for

192.168.1.9 4109 TTL = 1
Downstream Detailed
Mapping TLV
IP 1.1.1.2, label 4109
MPLS Echo Reply: Probe 1

R4 is transit.
Downstream Detailed Mapping TLV
IP 1.1.1.14, label 6109

SR OAM (L-ISIS) Example Explanation for first Path Cont…

2

192.168.1.9 4109 TTL = 2
Downstream Detailed
Mapping TLV
IP 1.1.1.14, label 6109

R6 is transit.
IP 1.1.1.34, label 7109


3

192.168.1.9 4109 TTL = 1
Downstream Detailed
Mapping TLV
IP 1.1.1.34, label 7109

R7 is transit.
IP 1.1.1.38, label 3


4

192.168.1.9 4109 TTL = 1
Downstream Detailed
Mapping TLV
IP 1.1.1.38, label 3

R9 is Egress


1 MPLS Echo Request: Probe
IGP IPv4 prefix sub-TLV for 3 MPLS Echo Request: Probe
192.168.1.9 4109 TTL = 1 IGP IPv4 prefix sub-TLV for 4
192.168.1.9 4109 TTL = 2 IGP IPv4 prefix sub-TLV for
Downstream Detailed 192.168.1.9 4109 TTL = 1 IGP IPv4 prefix sub-TLV for
Mapping TLV Downstream Detailed 192.168.1.9 4109 TTL = 1
IP 1.1.1.2, label 4109 Mapping TLV Downstream Detailed
MPLS Echo Reply: Probe 1 IP 1.1.1.34, label 7109 Mapping TLV
R4 is transit. MPLS Echo Reply: Probe 2 IP 1.1.1.38, label 3
Downstream Detailed Mapping TLV R6 is transit. MPLS Echo Reply: Probe 3
IP 1.1.1.14, label 6109 Downstream Detailed Mapping TLV R7 is transit.
IP 1.1.1.34, label 7109 Downstream Detailed Mapping TLV
R9 is Egress
IP 1.1.1.38, label 3

R3 - lo0.0-
192.168.1.3/32 Let's take SR and RSVP Interworking as an
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30 example (Hierarchical LSP Traceroute) to
Topology show some more details of the functionality
of the L-ISIS ping and traceroute. SR over
-A l
R8 e
LDP also has same behavior.
o- n n
- t Tu
R1 VP
Northstar
RS
JVM RSVP
AS100
Note: Configured “set protocols isis
192.168.1.10 em2
AS200 172.16.18.199/24 traffic-engineering family inet-
mpls shortcuts” on R1. Now labelled
Two RSVP LSPs from R1 to R8 creating
ISIS traffic is riding on RSVP LSP.
ge-0/0/9 ECMP NH for destination 192.168.1.5 on R1
eth2 ge-0/0/4 ge-0/0/4
172.16.18.1/24 172.16.18.11/24 1.1.1.45/3 1.1.1.49/30
Northstar 192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
PCS SL: 1000 SL: 4000 ge-0/0/2 ge-0/0/2 SL: 6000 SL: 8000
Index: 101 RSVP Tunnel Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106 Index: 108
ge-0/0/1 R1-to-R8-B ge-0/0/1
1.1.1.5/30 1.1.1.41/30
SR traceroute originated
from R2 and going to R5
Segment Routing
AS100
ge-0/0/1 ae0 ae0 ge-0/0/1

1.1.1.6/30 1.1.1.25/30 1.1.1.26/30 1.1.1.42/30
R2 - lo0.0- R5 - lo0.0-ge-0/0/1 ge-0/0/1 R7-RR - lo0.0- R9 - lo0.0-
192.168.1.2/32 192.168.1.5/32 192.168.1.7/32 192.168.1.9/32
SL: 2000 SL: 5000 SL: 7000 ge-0/0/0 ge-0/0/0 SL: 9000
Index: 102 Index: 105 ge-0/0/2 ge-0/0/2 Index: 107 1.1.1.37/30 1.1.1.38/30 Index: 109

SR OAM (L-ISIS) - Verification through SR-RSVP Interworking
Hierarchical LSP Traceroute Example: L-ISIS riding on RSVP LSP
root@R1> show mpls lsp extensive root@R1> show route 192.168.1.5 table inet.0 extensive
Ingress LSP: 2 sessions
192.168.1.8 192.168.1.5/32 (1 entry, 1 announced)
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R8-A *L-ISIS Preference: 14
ActivePath: R1-R3-R6-R8 (primary) Level: 2
. . . . . .
*Primary R1-R3-R6-R8 State: Up Next hop: 1.1.1.46 via ge-0/0/4.0 weight 0x1
. . . Label operation: Push 8105, Push 21(top) <<< RSVP LSP Label is getting
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) . . . pushed over L-ISIS label
1.1.1.46 S 1.1.1.49 S 1.1.1.30 S Next hop: 1.1.1.2 via ge-0/0/0.0 weight 0x1, selected
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): Label operation: Push 8105, Push 23(top) <<< RSVP LSP Label is getting
1.1.1.46(Label=21) 1.1.1.49(Label=29) 1.1.1.30(Label=3) . . . pushed over L-ISIS label
. . . root@R1> show route forwarding-table destination 192.168.1.5
192.168.1.8 Internet:
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R8-B Enabled protocols: Bridging,
ActivePath: R1-R4-R6-R8 (primary) Destination Type RtRef Next hop Type Index NhRef Netif
. . . 192.168.1.5/32 user 0 ulst 1048578 16
*Primary R1-R4-R6-R8 State: Up Push 8105, Push 20(top) 661 2 ge-0/0/4.0
. . . Push 8105, Push 23(top) 661 2 ge-0/0/0.0
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) . . .
1.1.1.2 S 1.1.1.14 S 1.1.1.30 S root@R1>
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
1.1.1.2(Label=23) 1.1.1.14(Label=26) 1.1.1.30(Label=3)
. . .
root@R1>

SR OAM (L-ISIS) - Verification through SR-RSVP Interworking Cont…
root@R2> show route 192.168.1.5 root@R2> ping mpls segment-routing isis 192.168.1.5 source 192.168.1.2 detail
Request for seq 1, to interface 329, label 1105, packet size 80
Local transmit time: 2019-05-22 06:45:06 PDT 845.721 ms
+ = Active Route, - = Last Active, * = Both Remote receive time: 2019-05-22 06:45:06 PDT 849.797 ms
192.168.1.5/32 *[L-ISIS/14] 00:28:42, metric 70 Reply for seq 2, return code: Egress-ok, time: 2.643 ms
> to 1.1.1.5 via ge-0/0/1.0, Push 1105 Local transmit time: 2019-05-22 06:45:07 PDT 841.066 ms
[IS-IS/18] 00:28:42, metric 70 Remote receive time: 2019-05-22 06:45:07 PDT 843.709 ms
> to 1.1.1.5 via ge-0/0/1.0
Local transmit time: 2019-05-22 06:45:08 PDT 838.731 ms
inet.3: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) Remote receive time: 2019-05-22 06:45:08 PDT 842.885 ms
+ = Active Route, - = Last Active, * = Both Request for seq 4, to interface 329, label 1105, packet size 80
192.168.1.5/32 *[L-ISIS/14] 00:28:42, metric 70 Local transmit time: 2019-05-22 06:45:09 PDT 841.775 ms
Remote receive time: 2019-05-22 06:45:09 PDT 843.179 ms
> to 1.1.1.5 via ge-0/0/1.0, Push 1105
root@R2> traceroute 192.168.1.5 source 192.168.1.2 <<< Normal trace provides only data plane verification. Local transmit time: 2019-05-22 06:45:10 PDT 836.750 ms
traceroute to 192.168.1.5 (192.168.1.5) from 192.168.1.2, 30 hops max, 52 byte packets Remote receive time: 2019-05-22 06:45:10 PDT 843.794 ms
1 1.1.1.5 (1.1.1.5) 13.059 ms 4.652 ms 8.869 ms
MPLS Label=1105 CoS=0 TTL=1 S=1 --- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
2 1.1.1.2 (1.1.1.2) 5.939 ms 1.1.1.46 (1.1.1.46) 7.436 ms 5.459 ms
MPLS Label=21 CoS=0 TTL=1 S=0 <<< First packet went to First LSP due to ECMP root@R2>
3 1.1.1.49 (1.1.1.49) 7.190 ms 4.889 ms 1.1.1.14 (1.1.1.14) 8.053 ms
MPLS Label=26 CoS=0 TTL=1 S=0 <<< First packet went to Second LSP due to ECMP
4 1.1.1.30 (1.1.1.30) 52.594 ms 17.566 ms 6.356 ms
5 1.1.1.42 (1.1.1.42) 8.915 ms 8.844 ms 12.125 ms
6 1.1.1.37 (1.1.1.37) 10.813 ms 13.894 ms 11.044 ms
7 192.168.1.5 (192.168.1.5) 10.581 ms 19.309 ms 17.183 ms
root@R2>

root@R2> traceroute mpls segment-routing isis 192.168.1.5 source 192.168.1.2 <<< MPLS traces verifies the data-plane state against the control-plane state.. Identifies the protocols encountered in
transit. MPLS traces Identifies mis programming of labels in transit.
source 192.168.1.2

1 1105 ISIS 1.1.1.5 (null) Success
FEC-Stack-Sent: ISIS FEC-Change-Recieved: PUSH-RSVP PUSH-RSVP <<< Detailed Downstream Mapping TLV of the reply packet is having return code of 15 (Label switched with FEC
ttl Label Protocol Address Previous Hop Probe Status change) it means that RSVP LSP is starting from here.
2 21 RSVP-TE 1.1.1.46 1.1.1.5 Success <<< RSVP tunnel starts from this hop and RSVP labels validations is happening from here.
FEC-Stack-Sent: RSVP,ISIS
3 29 RSVP-TE 1.1.1.49 1.1.1.46 Success
4 3 RSVP-TE 1.1.1.30 1.1.1.49 Egress <<< RSVP tunnel ends here. Outer tunnel (RSVP) validation happening.
FEC-Stack-Sent: RSVP,ISIS FEC-Change-Recieved: POP-RSVP <<< Detailed Downstream Mapping of the reply packet is having return code of 15 (Label switched with FEC change)
ttl Label Protocol Address Previous Hop Probe Status It means that RSVP LSP is ending here.
4 3 RSVP-TE 1.1.1.30 1.1.1.49 Success <<< This probe is also going to R8 as ISIS validation need to be done on this router. ISIS validation resumes from
FEC-Stack-Sent: ISIS here. You are seeing label 3 here as ISIS packet in data plane is being forwarded based on RSVP PHP label.
ttl Label Protocol Address Previous Hop Probe Status Detailed Downstream Mapping TLV returns label 3 due to RSVP PHP.
5 9105 ISIS 1.1.1.42 1.1.1.30 Success
6 7105 ISIS 1.1.1.37 1.1.1.42 Success
ttl Label Protocol Address Previous Hop Probe Status Note: In case of L-ISIS over RSVP, there are two
7 3 ISIS 1.1.1.25 1.1.1.37 Egress
FEC-Stack-Sent: ISIS probes with TTL 4. In case of L-ISIS over LDP, The
first probe packet with TTL 4 will not be present
Path 1 via ge-0/0/1.0 destination 127.0.0.64 <<< Following First LSP R1-to-R8-A, First Iteration takes first LSP
because R8 advertises the label for destination
. . . 192.168.1.5. R8 is not PHP for it. There would be
only one probe packet to R8 and in its reply, R8
would declare itself as transit.
. . .

2 23 RSVP-TE 1.1.1.2 1.1.1.5 Success <<< RSVP tunnel starts from this hop and RSVP labels validations is happening from here.
3 26 RSVP-TE 1.1.1.14 1.1.1.2 Success
4 3 RSVP-TE 1.1.1.30 1.1.1.14 Egress <<< RSVP tunnel ends here. Outer tunnel (RSVP) validation happening.
FEC-Stack-Sent: RSVP,ISIS FEC-Change-Recieved: POP-RSVP <<< Detailed Downstream Mapping of the reply packet is having return code of 15 (Label switched with FEC change)
ttl Label Protocol Address Previous Hop Probe Status It means that RSVP LSP is ending here.
4 3 RSVP-TE 1.1.1.30 1.1.1.14 Success <<< This probe is also going to R8 as ISIS validation need to be done on this router. ISIS validation resumes from
FEC-Stack-Sent: ISIS here. You are seeing label 3 here as ISIS packet in data plane is being forwarded based on RSVP PHP label.
ttl Label Protocol Address Previous Hop Probe Status Detailed Downstream Mapping TLV returns label 3 due to RSVP PHP.
5 9105 ISIS 1.1.1.42 1.1.1.30 Success
6 7105 ISIS 1.1.1.37 1.1.1.42 Success
7 3 ISIS 1.1.1.25 1.1.1.37 Egress
Path 2 via ge-0/0/1.0 destination 127.0.0.66 <<< Following Second LSP R1-to-R8-B, Second Iteration takes second LSP
root@R2>

root@R2> traceroute mpls segment-routing isis 192.168.1.5 source 192.168.1.1 detail
source 192.168.1.2
. . . . . .
Label Stack: MTU: 1514
Hop 1.1.1.5 Depth 1
Label 1 Value 29 Protocol RSVP-TE . . .
Probe status: Success
FEC-Stack-Sent: RSVP,ISIS Label Stack:
Parent: (null)
Label 1 Value 9105 Protocol ISIS
. . .
Hop 1.1.1.30 Depth 4 FEC-Stack-Sent: ISIS
MTU: Unknown <<< First Packet MTU is unknown as we print MTU
Probe status: Egress
. . . from reply packet and since it is first probe,
Parent: 1.1.1.49 Hop 1.1.1.37 Depth 6
Label Stack: we are yet to receive any reply.
Return code: Egress-ok at stack-depth 1 Probe status: Success
. . . Parent: 1.1.1.42
MTU: 1514 Return code: Label switched at stack-depth 1
FEC-Change-Recieved: PUSH-RSVP PUSH-RSVP
. . . . . .
Hop 1.1.1.46 Depth 2
Parent: 1.1.1.5
FEC-Change-Recieved: POP-RSVP Label 1 Value 7105 Protocol ISIS
Return code: Label switched at stack-depth 2
. . .
MTU: 1514
Probe status: Success Hop 1.1.1.25 Depth 7
. . .
Parent: 1.1.1.49 Probe status: Egress
Label Stack:
Return code: Label switched at stack-depth 1 Parent: 1.1.1.37
Label 1 Value 21 Protocol RSVP-TE
. . . Return code: Egress-ok at stack-depth 1
MTU: 1514 . . .
. . . MTU: 1514
Label Stack: . . .
Label 1 Value 3 Protocol RSVP-TE Label Stack:
FEC-Stack-Sent: ISIS Label 1 Value 3 Protocol ISIS
Parent: 1.1.1.46
. . .
MTU: 1514
Parent: 1.1.1.30 Path 1 via ge-0/0/1.0 destination 127.0.0.64
. . .
Return code: Label switched at stack-depth 1 . . .
. . .
. . . . . .
Hop 1.1.1.2 Depth 2
Parent: 1.1.1.5
FEC-Change-Recieved: POP-RSVP Label 1 Value 7105 Protocol ISIS
. . .
MTU: 1514
Probe status: Success Hop 1.1.1.25 Depth 7
. . .
Parent: 1.1.1.14 Probe status: Egress
Label Stack:
Return code: Label switched at stack-depth 1 Parent: 1.1.1.37
MTU: 1514 . . .
. . . MTU: 1514
Label Stack: . . .
Label 1 Value 3 Protocol RSVP-TE Label Stack:
FEC-Stack-Sent: ISIS Label 1 Value 3 Protocol ISIS
Parent: 1.1.1.2
. . .
MTU: 1514
Parent: 1.1.1.30 Path 2 via ge-0/0/1.0 destination 127.0.0.65
. . .
Label Stack:
. . .
MTU: 1514 root@R2>
. . .
Label Stack:
Probe status: Egress
Parent: 1.1.1.14
Return code: Egress-ok at stack-depth 1
. . .
MTU: 1514
Parent: 1.1.1.42
. . .
. . .
SR OAM (SPRING-TE Tunnels)
The basic idea is to verify the segment-routed MPLS path by sending the “MPLS echo request” packet with entire label-stack
along the same data path as the data traffic. An MPLS echo request carries Forwarding Equivalence Class (FEC) of the segment-
routing path is being verified. This echo request is forwarded just like any other packet based on the label-stack.
In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control
plane of the end node, which then verifies whether it is indeed an Egress for the FEC.
In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit node along the MPLS path, which
performs various checks that it is indeed a transit node for this path; this transit node also returns further information that helps
check the control plane against the data plane, i.e., that forwarding matches what the segment-routing protocols determined as
the path.
Note: SPRING-TE OAM supports Ping and Traceroute for all types of SR-TE tunnels including static SR tunnels, BGP-SR-TE
tunnels, PCEP tunnels.

SR OAM (SPRING-TE Tunnels) - Trace Functionality Explanation
From our base topology:
FEC1 is associated with the Label stack and associated FECs received by the Routers from R2
R2-R1 Adj SID Segment
FEC1
(label 20) “IGP Adj
1103 FEC2
segment ID subTLV”
1105 FEC3 FEC2
1109 FEC4 1105, 1 FEC3
Pay Load 1109, 0 FEC4 FEC3
Pay Load 1109, 1 FEC4
FEC1 Pay Load
1103 FEC2 1103, 1 FEC2
1105 FEC3 1105, 0 FEC3 1105, 1 FEC3 1105, 2 FEC3 1105, 3 FEC3
1109 FEC4 1109, 0 FEC4 1109, 0 FEC4 1109, 0 FEC4 1109, 0 FEC4 1109, 1 FEC4 1109, 2 FEC4
Pay Load Pay Load Pay Load Pay Load Pay Load Pay Load Pay Load Pay Load
R2 R1 R3 R6 R4 R5 R7 R9
SL: 1000 SL: 1000 SL: 1000 SL: 1000 SL: 1000 SL: 1000 SL: 1000 SL: 1000
Index: 102 Index: 101 Index: 103 Index: 106 Index: 104 Index: 105 Index: 107 Index: 109
Segment 1: Label 1103 Segment 2: Label 1105 Segment 3: Label 1109

Explanation with an example: There is a SR-TE path from R2 to R9. The path label stack is “20 (Top), 1103, 1105, 1109 (Bottom)”. The
label in the trace packet (or any other packet traversing the path) would be “1103, 1105, 1109”. Top label 20 is associated with the R2-R1
adjacency segment. mpls.0 table on R2 will have POP action for label 20, hence this label will not be seen in the actual packet stack that
would be traversing the path. Label 20 has to be there in SR-TE tunnel label stack so that path can be resolved in mpls.0 table on R2. The
1103 label will take the packet from R2 to R3. The next label in the stack 1105 will take the packet from R3 to the R5. The bottom label 1109
will take the packet from R5 to the destination R9. Please note that ingress R2 adds FECs for each label in the label-stack of the path and the
same need to be validated by nodes who advertised that labels. Hence FEC1 would be there in the first trace probe send by R2 for validation
of adjacency SID of R2-R1 link. FEC2 needs validation from R2 to R3. FEC3 needs validation from R3 to R5. FEC4 needs validation from R5
to R9.
Two very important key points to keep in mind when you are going through the step by step procedure starting on next slide.
a. If any transit router (R1, R4 and R7 in the example) in path returns label 3 (Implicit Null label) in the DDMT TLV of Echo response
message for a segment, then ingress router sets the TTL 1 for the next label representing next segment. For the previous segment
(segment for which router returned label 3), ingress router sets the TTL of label representing that segment to 255. The exception is the
PHP router of the path (R7), in which case the TTL of the existing label will be increased by 1 so that R2 can reach the last hop of the
path (R9). If transit router returns label other then Implicit Null label, then TTL of existing label will increase by 1 in the next Echo
request.
b. If any transit router (R1, R3 and R5 in the example) in path reports itself as egress router for the FEC associated with its segment in the
DDMT TLV of the Echo response, then ingress router should remove that FEC from the FEC stack and send one more echo request with
the same TTL value and same DDMT TLV (as with the previous Echo request request) to the same node (which reported itself as egress)
for tracing the next segment. Egress router of the path (R9 in the example) will also report itself as egress router but MPLS reply from
egress
© 2018 router of path will complete the LSP trace.
Juniper Networks
316
Below are the procedures performed by ingress router to perform MPLS traceroute for SR-TE path from R2 to R9.
1. Probe 1 from R2 to R1: Ingress R2 sends MPLS LSP Echo Request with label stack of ((1103,1), (1105,0), (1109,0)) to R1 along
with associated FECs of these respective labels. Please note that FEC associated with the top label of SR-TE path stack (20)
would also be present for the validation of adjacency SID of R2-R1 link. This FEC would be the first FEC in the FEC stack as it
belongs to the top label of path stack (20). For the verification on R1, the Label in the DDMT TLV of echo request will be 1103
along with the R1’s interface IP connecting to R2.
2. Probe 1 reply from R1 to R2: Since R1 receives MPLS LSP Echo Request with TTL as 1 for outer most label (1103), R1 validates
the outermost FEC and by looking at the FEC, R1 knows that it’s the egress router for the FEC associated with the R2-R1
adjacency segment. After FEC validation, R1 will validate DDMT TLV info and determine that MPLS echo request is received
on the correct interface. R1 sends echo response to R2 with return code as the egress for outermost FEC associated with the
R2-R1 adjacency segment.
3. Probe 2 from R2 to R1: R2 receives echo response with return code as egress from R1. Now Ingress LSR (R2) must start
tracing the next segment (if exists; in our case first segment) by removing the outermost FEC associated with R2-R1 adjacency
segment from the FEC stack and send one more echo request with the same TTL value to the same node (R1) for tracing the
next segment (first) in the label stack. R2 sends MPLS LSP Echo Request with label stack of ((1103,1), (1105,0), (1109,0)) to R1
along with associated FECs of respective labels “1103, 1105, 1109”. For the verification on R1, the Label in the DDMT TLV of
echo request will be 1103 along with the R1’s interface IP connecting to R2.

4. Probe 2 reply from R1 to R2: Since R1 receives MPLS LSP Echo Request with TTL as 1 for outer most label (1103), R1
validates the outermost FEC and by looking at the FEC, R1 knows that it’s the PHP router for the FEC associated with Node-
Sid of R3. After FEC validation, R1 will validate DDMT TLV info and determine that MPLS echo request is received on the
correct interface. R1 send echo response (with label 3 along with the R3’s interface IP connecting to R1 in its DDMT TLV) to
R2.
5. Probe 3 from R2 to R3: R2 looks at the echo response from R1 and it sees Implicit Null label value in DDMT TLV. Now
Ingress LSR (R2) must set the TTL value of next-label (1105) in label-stack to 1. All Outer-label TTL will be set to 255 and all
the other Inner-label TTL will be set to 0. R2 should send the next MPLS LSP Echo Request with label stack ((1103,255),
(1105,1), (1109,0)). For the verification on R3, the Label in the DDMT TLV of echo request will be 3 along with the R3’s
interface IP connecting to R1.
6. Probe 3 reply from R3 to R2: R1 being PHP POPs the outermost label (1103) from the label stack and forwards the rest of
packet to R3 with label stack ((1105,1), (1109,0)). R3 receives MPLS LSP Echo Request with TTL as 1 for outer most label
(1105). R3 validates the outermost FEC and by looking at the FEC, R3 knows that it’s the egress router for the FEC associated
with Node-Sid of R3. After FEC validation, R3 will validate DDMT TLV info and determine that MPLS echo request is
received on the correct interface. R3 sends echo response to R2 with return code as the egress for outermost FEC associated
with Node-Sid of R3.

tracing the next segment (if exists; in our case second segment) by removing the outermost FEC associated with Node-Sid of
R3 from the FEC stack and send one more echo request with the same TTL value to the same node (R3) for tracing the next
segment (second) in the label stack. LSP echo request is sent by R2 with the label stack as ((1103,255), (1105,1), (1109,0)). For
the verification on R3, the Label in the DDMT TLV of echo request will be 3 along with the R3’s interface IP connecting to R1.
8. Probe 4 reply from R3 to R2: R1 being PHP POPs the first label from the label stack forwards the packet to R3. Once R3
receives this request with the label stack ((1105,1), (1109,0)), R3 validates the outermost FEC and by looking at the FEC, R3
knows that it’s the transit router for the FEC associated with Node-Sid of R5. After FEC validation, R3 will validate DDMT
TLV info and determine that MPLS echo request is received on the correct interface. R3 send echo response (with label 1105
along with the R6’s interface IP connecting to R3 in its DDMT TLV) to R2.
9. Probe 5 from R2 to R6: Since 1105 is not the Implicit Null label hence TTL of the same label 1105 will be incremented in the
next ECHO request. R2 send the next MPLS LSP Echo request with label stack ((1103,255), (1105,2), (1109,0)) to R6. For the
verification on R6, the Label in the DDMT TLV of echo request will be 1105 along with the R6’s interface IP connecting to R3.
10. Probe 5 reply from R6 to R2: R1 being PHP POPs the first label from the label stack and R3 forwards the packet to R6. Once
R6 receives this request with the label stack ((1105,1), (1109,0)), R6 validates the outermost FEC and by looking at the FEC,
R6 knows that it’s the transit router for the FEC associated with Node-Sid of R5. After FEC validation, R6 will validate DDMT
TLV info and determine that MPLS echo request is received on the correct interface. R6 send echo response (with label 1105
along with the R4’s interface IP connecting to R6 in its DDMT TLV) to R2.
11. Probe 6 from R2 to R4: Again returned label (1105) in DDMT TLV of echo response packet is not an Implicit Null label hence
TTL of the same label will be incremented in the next ECHO request. R2 send the next MPLS LSP Echo request with label
stack ((1103,255), (1105,3), (1109,0)) to R4. For the verification on R4, the Label in the DDMT TLV of echo request will be
1105 along with the R4’s interface IP connecting to R6.
12. Probe 6 reply from R4 to R2: R1 being PHP POPs the first label from the label stack and R3 and R6 forwards the packet to
R4. Once R4 receives this request with the label stack ((1105,1), (1109,0)), R4 validates the outermost FEC and by looking at
the FEC, R4 knows that it’s the PHP router for the FEC associated with Node-Sid of R5. After FEC validation, R4 will validate
DDMT TLV info and determine that MPLS echo request is received on the correct interface. R4 send echo response (with
label 3 along with the R5’s interface IP connecting to R4 in its DDMT TLV) to R2.
13. Probe 7 from R2 to R5: R2 looks at the echo response from R4 it sees Implicit Null label value in DDMT TLV. Now Ingress
LSR (R2) must set the TTL value of next-label (1109) in label-stack to 1. All Outer-label TTL will be set to 255 and all the
other Inner-label TTL will be set to 0. R2 send the next MPLS LSP Echo request with label stack ((1103,255), (1105,255),
(1109,1)). For the verification on R5, the Label in the DDMT TLV of echo request will be 3 along with the R5’s interface IP
connecting to R4.

14. Probe 7 reply from R5 to R2: R1 and R4 being PHP POPs the first (1103) and second (1105) label respectively. R5 receives
MPLS LSP Echo Request with TTL as 1 for outer most label (1109). R5 validates the outermost FEC and by looking at the
FEC, R5 knows that it’s the egress router for the FEC associated with Node-Sid of R5. After FEC validation, R5 will validate
DDMT TLV info and determine that MPLS echo request is received on the correct interface. R5 sends echo response to R2
with return code as the egress for outermost FEC associated with Node-Sid of R5.
tracing the next segment (if exists; in our case third segment) by removing the outermost FEC associated with Node-Sid of R5
from the FEC stack and send one more echo request with the same TTL value to the same node (R5) for tracing the next
segment (third) in the label stack. LSP echo request is sent by R2 with the label stack as ((1103,255), (1105,255), (1109,1)).
For the verification on R5, the Label in the DDMT TLV of echo request will be 3 along with the R5’s interface IP connecting to
R4.
16. Probe 8 reply from R5 to R2: R1 and R4 being PHP POPs the first (1103) and second (1105) label respectively. Once R5
receives this request with the label stack (1109,1)), R5 validates the outermost FEC and by looking at the, FEC R5 knows that
it’s the transit router for the FEC associated with Node-Sid of R9. After FEC validation, R5 will validate DDMT TLV info and
determine that MPLS echo request is received on the correct interface. R5 send echo response (with label 1109 along with the
R7’s interface IP connecting to R5 in its DDMT TLV) to R2.

17. Probe 9 from R2 to R7: Since 1109 is not the Implicit Null label hence TTL of the same label 1109 will be incremented in the
next ECHO request. R2 send the next MPLS LSP Echo request with label stack ((1103,255), (1105,255), (1109,2)) to R7. For
the verification on R7, the Label in the DDMT TLV of echo request will be 1109 along with the R7’s interface IP connecting to
R5.
18. Probe 9 reply from R7 to R2: R1 and R4 being PHP POPs the first (1103) and second (1105) label respectively. R5 forwards
the packet to R7. Once R7 receives this request with the label stack (1109,1), R7 validates the outermost FEC and by looking
at the FEC, R7 knows that it’s the PHP router for the FEC associated with Node-Sid of R9. After FEC validation, R7 will
validate DDMT TLV info and determine that MPLS echo request is received on the correct interface. R7 send echo response
(with label 3 along with the R9’s interface IP connecting to R7 in its DDMT TLV) to R2.
19. Probe 10 from R2 to R9: R2 looks at the echo response from R7 it sees an Implicit Null label value in DDMT TLV. Now
Ingress LSR (R2) must set the TTL value of next-label in label-stack to 1. Since 1109 is the bottom label for the last segment
and no next label exists, the TTL of the existing label (1109) has to be increased by 3 so that we can reach R9 to complete the
FEC validation of third segment. All Outer-label TTL will be set to 255 and all the other Inner-label TTL (in our case now they
are none) will be set to 0. R2 send the next MPLS LSP Echo Request with label stack ((1103,255), (1105,255), (1109,3)). For
the verification on R9, the Label in the DDMT TLV of echo request will be 3 along with the R9’s interface IP connecting to R7.

20.Probe 10 reply from R9 to R2: R1, R4 and R7 being PHP POPs the first (1103), second (1105) and third label (1109)
respectively from the label stack. R9 validates the outermost FEC and by looking at the FEC, R9 knows that it’s the egress
router for the FEC associated with Node-Sid of R9. After FEC validation, R9 will validate DDMT TLV info and determine that
MPLS echo request is received on the correct interface. R9 sends echo response to R2 with return code as the egress for
outermost FEC associated with Node-Sid of R9.
21. R2 receives an echo reply with return code as egress for the last FEC in the FEC stack TLV and conclude that R9 is the Egress
for the SR-TE path. The end of a tunnel is detected from the Return Code when it indicates that the responding LSR R9 is an
egress for the stack at depth 1. R2 completes the trace with the validation of the last FEC in the FEC stack.

Name: R2-R9-LSP
To: 192.168.1.9
State: Up
Telemetry statistics:
Sensor-name: ingress-R2-R9-LSP, Id: 3758096389
Path: R2-R1-R3-R6-R4-R5-R7-R9
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 20 <<< Label 20 will not be present in the packets traversing the LSP. Label 20 is having POP action on R2 and it is only required to resolve the LSP in mpls.0
Hop 2 (Strict):
NAI: None
Hop 3 (Strict):
NAI: None
Hop 4 (Strict):
NAI: None
root@R2>

root@R2> traceroute mpls segment-routing spring-te source-routing-path R2-R9-LSP source 192.168.1.2 tunnel-source static
Probe options: retries 3, exp 7
source 192.168.1.2

1 1103 ISIS 1.1.1.5 (null) Egress <<< Label 1103 is sent in Probe 1 to R1 (Step 1). It will be printed only after getting probe reply from R1 (Step 2) means R1 should validate FEC1 first.
FEC-Stack-Sent: ISIS,ISIS,ISIS,ISIS FEC-Change-Recieved: POP-ISIS <<< First FEC associated with the R2-R1 adjacency segment (label 20) got validated. It is removed from FEC stack by Ingress R2.
1 1103 ISIS 1.1.1.5 (null) Success <<< Label 1103 is sent in Probe 2 to R1 (Step 3). It will be printed only after getting probe reply from R1 (Step 4) means R1 should validate FEC2 first.
FEC-Stack-Sent: ISIS,ISIS,ISIS
1 3 ISIS 1.1.1.46 1.1.1.5 Egress <<< Label 3 is sent in Probe 3 to R3 (Step 5). It will be printed only after getting probe reply from R3 (Step 6) means R3 should validate FEC2 first.
FEC-Stack-Sent: ISIS,ISIS,ISIS FEC-Change-Recieved: POP-ISIS <<< Second FEC associated with the Node SID of R3 (label 1103) got validated. It is removed from FEC stack by Ingress R2.
1 3 ISIS 1.1.1.46 1.1.1.5 Success <<< Label 3 is sent in Probe 4 to R3 (Step 7). It will be printed only after getting probe reply from R3 (Step 8) means R3 should validate FEC3 first.
FEC-Stack-Sent: ISIS,ISIS
FEC-Stack-Sent: ISIS,ISIS FEC-Change-Recieved: POP-ISIS <<< Third FEC associated with the Node SID of R5 (label 1105) got validated. It is removed from FEC stack by Ingress R2.
FEC-Stack-Sent: ISIS <<< Forth FEC associated with the Node SID of R9 (label 1109) got validated. Trace completed with the validation of last FEC associated with the Egress.
Path 1 via ge-0/0/1.0 destination 127.0.0.64
root@R2>

TTL Considerations for the Traceroute for source-routed LSP
When tracing an LSP, the TTL is incremented by one in order to trace the path sequentially along the LSP. However, when a
source-routed SR-TE tunnel has to be traced, there are as many TTLs as there are labels in the stack. The LSR that initiates the
traceroute SHOULD start by setting the TTL to 1 for the tunnel in the LSP's label stack it wants to start the tracing from, the TTL
of all outer labels in the stack to the max value, and the TTL of all the inner labels in the stack to zero. Thus, a typical start to the
traceroute would have a TTL of 1 for the outermost label and all the inner labels would have a TTL of 0. If the FEC Stack TLV is
included, it should contain only those for the inner-stacked tunnels. The Return Code/Subcode and FEC Stack Change TLV
should be used to diagnose the tunnel. When the tracing of a tunnel in the stack is complete, then the next tunnel in the stack
should be traced. The end of a tunnel can be detected from the Return Code when it indicates that the responding LSR is an
egress for the stack at depth 1. Thus, the traceroute procedures can be recursively applied to traceroute a SR-TE tunnel.

R3 - lo0.0-
192.168.1.3/32
ge-0/0/0 SL: 3000 ge-0/0/1
1.1.1.46/30 Index: 103 1.1.1.50/30
Topology
Northstar
JVM
192.168.1.10 em2
AS200 172.16.18.199/24
eth2 ge-0/0/9 ge-0/0/4 ge-0/0/4

172.16.18.1/24 172.16.18.11/24 1.1.1.45/3 6109 1.1.1.49/30
4109
Northstar 192.168.1.1/32 1.1.1.1/30 1.1.1.2/30 192.168.1.4/32 1.1.1.13/30 1.1.1.14/30 192.168.1.6/32 1.1.1.29/30 1.1.1.30/30 192.168.1.8/32
PCS SL: 1000 SL: 4000 17, 18
ge-0/0/2 ge-0/0/2 SL: 6000 SL: 8000
Index: 101 16, 17, 18 Index: 104 1.1.1.17/30 1.1.1.18/30 Index: 106 Index: 108
ge-0/0/1 ge-0/0/3 ge-0/0/3 ge-0/0/1
1.1.1.5/30 1.1.1.21/30 1.1.1.33/30 1.1.1.41/30
7109
18
Segment Routing
AS100
PCEP Provisioned PCEP Provisioned
Node SID LSP Adj SID LSP
ge-0/0/1 ge-0/0/3 ae0 ae0 ge-0/0/3 ge-0/0/1

1.1.1.6/30 1.1.1.22/30 1.1.1.25/30 1.1.1.26/30 1.1.1.34/30 1.1.1.42/30
192.168.1.2/32 192.168.1.5/32 192.168.1.7/32 192.168.1.9/32
SL: 2000 ge-0/0/0 ge-0/0/0 SL: 5000 SL: 7000 ge-0/0/0 IPv4 ge-0/0/0 SL: 9000
IPv4
SR OAM (SPRING-TE Tunnels) - Adj SID LSP Example
root@R1> show spring-traffic-engineering lsp detail root@R1> show route 192.168.1.9
Tunnel-source: Path computation element protocol(PCEP) inet.0: 43 destinations, 44 routes (43 active, 0 holddown, 0 hidden)
To: 192.168.1.9 + = Active Route, - = Last Active, * = Both
State: Up
Telemetry statistics: 192.168.1.9/32 *[L-ISIS/14] 4d 11:47:05, metric 40
Sensor-name: ingress-R1-to-R9-LSP-AdjSID, Id: 3758096388 > to 1.1.1.2 via ge-0/0/0.0, Push 4109
Outgoing interface: NA to 1.1.1.6 via ge-0/0/1.0, Push 2109
Auto-translate status: Disabled Auto-translate result: N/A to 1.1.1.46 via ge-0/0/4.0, Push 3109
Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A [IS-IS/18] 4d 11:47:05, metric 40
BFD status: N/A BFD name: N/A > to 1.1.1.2 via ge-0/0/0.0
SR-ERO hop count: 4 to 1.1.1.6 via ge-0/0/1.0
Hop 1 (Strict): to 1.1.1.46 via ge-0/0/4.0
SID type: 20-bit label, Value: 62 inet.3: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
Hop 2 (Strict): + = Active Route, - = Last Active, * = Both
SID type: 20-bit label, Value: 16 192.168.1.9/32 *[SPRING-TE/6] 00:00:11, metric 1, metric2 0
Hop 3 (Strict): > to 1.1.1.2 via ge-0/0/0.0, Push 18, Push 17, Push 16(top)
NAI: IPv4 Adjacency ID, 1.1.1.33 -> 1.1.1.34 [L-ISIS/14] 4d 11:47:05, metric 40
SID type: 20-bit label, Value: 17 > to 1.1.1.2 via ge-0/0/0.0, Push 4109
Hop 4 (Strict): to 1.1.1.6 via ge-0/0/1.0, Push 2109
NAI: IPv4 Adjacency ID, 1.1.1.37 -> 1.1.1.38 to 1.1.1.46 via ge-0/0/4.0, Push 3109
root@R1>
root@R1>

SR OAM (SPRING-TE Tunnels) - Adj SID LSP Example Cont…
root@R1> ping mpls segment-routing spring-te source-routing-path R1-to-R9-LSP-AdjSID source 192.168.1.1 tunnel-source pcep detail
Request for seq 1, to interface 325, labels <18, 17, 16>, packet size 88 <<< Ping only gives the LSP label stack info in case of Adj SID LSP.
Request for seq 2, to interface 325, labels <18, 17, 16>, packet size 88

root@R1>

root@R1> traceroute mpls segment-routing spring-te source-routing-path R1-to-R9-LSP-AdjSID source 192.168.1.1 tunnel-source pcep
source 192.168.1.1

1 16 ISIS 1.1.1.2 (null) Egress <<< R4 is the egress for the first IGP Adj segment ID sub-TLV (label 62). TTL 1 is for the label 16.
FEC-Stack-Sent: ISIS,ISIS,ISIS,ISIS FEC-Change-Recieved: POP-ISIS
1 16 ISIS 1.1.1.2 (null) Success <<< R4 is the transit for the second IGP Adj segment ID sub-TLV (label 16). TTL 1 is for the label 16.
FEC-Stack-Sent: ISIS,ISIS,ISIS
1 3 ISIS 1.1.1.18 1.1.1.2 Egress <<< R6 is the egress for the second IGP Adj segment ID sub-TLV (label 16). TTL 1 is for the label 17.
FEC-Stack-Sent: ISIS,ISIS,ISIS FEC-Change-Recieved: POP-ISIS
1 3 ISIS 1.1.1.18 1.1.1.2 Success <<< R6 is the transit for the third IGP Adj segment ID sub-TLV (label 17). TTL 1 is for the label 17.
1 3 ISIS 1.1.1.34 1.1.1.18 Egress <<< R7 is the egress for the third IGP Adj segment ID sub-TLV (label 17). TTL 1 is for the label 18.
FEC-Stack-Sent: ISIS,ISIS FEC-Change-Recieved: POP-ISIS
1 3 ISIS 1.1.1.34 1.1.1.18 Success <<< R7 is the transit for the fourth IGP Adj segment ID sub-TLV (label 18). TTL 1 is for the label 18.
2 3 ISIS 1.1.1.38 1.1.1.34 Egress <<< R4 is the egress for the fourth IGP Adj segment ID sub-TLV (label 18). TTL 2 is for the label 18.
root@R1>
Note: There is no label assigned for the first IGP Adj segment ID sub-TLV (associated with label 62) when we send the trace packet. Hence the first router just process the IGP Adj segment ID sub-TLV and declare that it is
the egress for the first IGP Adj segment ID sub-TLV. For the second IGP Adj segment ID sub-TLV we have label 16, for the third one we have 17 and for forth one we have 18.

root@R1> traceroute mpls segment-routing spring-te source-routing-path R1-to-R9-LSP-AdjSID source 192.168.1.1 tunnel-source pcep detail
source 192.168.1.1
. . . . . .
Hop 1.1.1.2 Depth 1 Hop 1.1.1.18 Depth 1 Label Stack:
Probe status: Egress Probe status: Egress Label 1 Value 3 Protocol ISIS
Parent: (null) Parent: 1.1.1.2 FEC-Stack-Sent: ISIS,ISIS
Return code: Egress-ok at stack-depth 1 Return code: Egress-ok at stack-depth 1 FEC-Change-Recieved: POP-ISIS
. . . . . .
MTU: Unknown <<< First Packet MTU is unknown as we print MTU MTU: 1514 Hop 1.1.1.34 Depth 1
. . . from reply packet and since it is first probe, . . . Probe status: Success
Label Stack: we are yet to receive any reply. Label Stack: Parent: 1.1.1.18
Label 1 Value 16 Protocol ISIS Label 1 Value 3 Protocol ISIS Return code: Label switched at stack-depth 1
Label 2 Value 17 Protocol Unknown FEC-Stack-Sent: ISIS,ISIS,ISIS . . .
Label 3 Value 18 Protocol Unknown FEC-Change-Recieved: POP-ISIS MTU: 1514
FEC-Stack-Sent: ISIS,ISIS,ISIS,ISIS . . .
FEC-Change-Recieved: POP-ISIS Hop 1.1.1.18 Depth 1 Label Stack:
Probe status: Success Label 1 Value 3 Protocol ISIS
Hop 1.1.1.2 Depth 1 Parent: 1.1.1.2 FEC-Stack-Sent: ISIS
Probe status: Success Return code: Label switched at stack-depth 1
Parent: (null) . . . Hop 1.1.1.38 Depth 2
Return code: Label switched at stack-depth 1 MTU: 1514 Probe status: Egress
. . . . . . Parent: 1.1.1.34
MTU: Unknown Label Stack: Return code: Egress-ok at stack-depth 1
. . . Label 1 Value 3 Protocol ISIS . . .
Label Stack: FEC-Stack-Sent: ISIS,ISIS MTU: 1514
Label 1 Value 16 Protocol ISIS . . .
Label 2 Value 17 Protocol Unknown Hop 1.1.1.34 Depth 1 Label Stack:
Label 3 Value 18 Protocol Unknown Probe status: Egress Label 1 Value 3 Protocol ISIS
FEC-Stack-Sent: ISIS,ISIS,ISIS Parent: 1.1.1.18 FEC-Stack-Sent: ISIS
. . .
MTU: 1514 Path 1 via ge-0/0/0.0 destination 127.0.0.64
. . .
root@R1>
SR OAM (SPRING-TE Tunnels) - Adj SID LSP Trace Explanation
192.168.1.1/32 62 16, 17, 18 192.168.1.4/32 16 17, 18 192.168.1.6/32 17 18 192.168.1.7/32 18 IPv4 192.168.1.9/32
1
Adj Segment sub-TLV R1-R4

Adj Segment sub-TLV R4-R6 16 TTL = 1
Downstream Detailed
Mapping TLV
IP 1.1.1.2, label 16

R4 is Egress

2

16 TTL = 1
17 TTL = 0
18 TTL = 0
Downstream Detailed
Mapping TLV
IP 1.1.1.2, label 16

R4 is transit.
IP 1.1.1.18, label 3
Note: Each Adj Segment is represented by IGP Adj segment ID sub-TLV (FEC). Apart from other fields this TLV represents local interface, Remote Interface, Local Router ID, Remote Router ID.
© 2018
Each Juniper
Adj SID Networks
label would be represented by one Adj segment ID sub-TLV. We have Juniper
four labels (62, 332
Business Use16, 17, 18) in our LSP. That is why Probe 1 is having 4 Adj segment ID sub-TLV TLVs.
Only
192.168.1.1/32 62 16, 17, 18 192.168.1.4/32 16 17, 18 192.168.1.6/32 17 18 192.168.1.7/32 18 IPv4 192.168.1.9/32

3

16 TTL = 255
17 TTL = 1
18 TTL = 0
Downstream Detailed
Mapping TLV
IP 1.1.1.18, label 3

R6 is Egress

4

18 TTL = 0
Downstream Detailed
Mapping TLV
IP 1.1.1.18, label 3

R6 is transit.
IP 1.1.1.34, label 3
© 2018
Each Juniper
Adj SID Networks
Only
192.168.1.1/32 62 16, 17, 18 192.168.1.4/32 16 17, 18 192.168.1.6/32 17 18 192.168.1.7/32 18 IPv4 192.168.1.9/32

5

18 TTL = 1
Downstream Detailed
Mapping TLV
IP 1.1.1.34, label 3

R7 is Egress

6
16 TTL = 255
17 TTL = 255
18 TTL = 1
Downstream Detailed
Mapping TLV
IP 1.1.1.34, label 3

R7 is transit.
IP 1.1.1.38, label 3
© 2018
Each Juniper
Adj SID Networks
Only
192.168.1.1/32 62 16, 17, 18 192.168.1.4/32 16 17, 18 192.168.1.6/32 17 18 192.168.1.7/32 18 IPv4 192.168.1.9/32

7
16 TTL = 255
17 TTL = 255
18 TTL = 2
Downstream Detailed
Mapping TLV
IP 1.1.1.38, label 3

R9 is Egress
© 2018
Each Juniper
Adj SID Networks
Only
192.168.1.1/32 62 16, 17, 18 192.168.1.4/32 16 17, 18 192.168.1.6/32 17 18 192.168.1.7/32 18 IPv4 192.168.1.9/32
3
Adj Segment sub-TLV R1-R4 MPLS Echo Request: Probe
Adj Segment sub-TLV R4-R6 16 TTL = 1 5
Adj Segment sub-TLV R6-R7 17 TTL = 0 16 TTL = 255
Adj Segment sub-TLV R6-R7 7
Adj Segment sub-TLV R7-R9 18 TTL = 0 17 TTL = 1 Adj Segment sub-TLV R6-R7 16 TTL = 255
18 TTL = 0 Adj Segment sub-TLV R7-R9 17 TTL = 255 16 TTL = 255
18 TTL = 1 Adj Segment sub-TLV R7-R9
Downstream Detailed Downstream Detailed 17 TTL = 255
Mapping TLV Downstream Detailed 18 TTL = 2
Mapping TLV Downstream Detailed
IP 1.1.1.2, label 16 Mapping TLV
IP 1.1.1.34, label 3
IP 1.1.1.38, label 3
R4 is Egress MPLS Echo Reply: Probe 3
R9 is Egress
2
4
16 TTL = 1
Adj Segment sub-TLV R6-R7 6
17 TTL = 0 Adj Segment sub-TLV R6-R7 16 TTL = 255
18 TTL = 0 Adj Segment sub-TLV R7-R9 17 TTL = 1 16 TTL = 255
18 TTL = 0 17 TTL = 255
Downstream Detailed
Downstream Detailed 18 TTL = 1
Mapping TLV
IP 1.1.1.18, label 3
IP 1.1.1.34, label 3
R4 is transit. MPLS Echo Reply: Probe 4
Downstream Detailed Mapping TLV R6 is transit. MPLS Echo Reply: Probe 6
IP 1.1.1.18, label 3 Downstream Detailed Mapping TLV R7 is transit.
IP 1.1.1.38, label 3
© 2018
Each Juniper
Adj SID Networks
Only
SR OAM (SPRING-TE Tunnels) - Node SID LSP Example
root@R1> show spring-traffic-engineering lsp detail root@R1> show route 192.168.1.9
Name: R1-to-R9-LSP-NodeSID
Tunnel-source: Path computation element protocol(PCEP) inet.0: 43 destinations, 44 routes (43 active, 0 holddown, 0 hidden)
To: 192.168.1.9 + = Active Route, - = Last Active, * = Both
State: Up
Telemetry statistics: 192.168.1.9/32 *[IS-IS/18] 4d 11:47:05, metric 40
Sensor-name: ingress-R1-to-R9-LSP-NodeSID, Id: 3758096389 > to 1.1.1.2 via ge-0/0/0.0
Outgoing interface: NA to 1.1.1.6 via ge-0/0/1.0
Auto-translate status: Disabled Auto-translate result: N/A to 1.1.1.46 via ge-0/0/4.0
BFD status: N/A BFD name: N/A inet.3: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
SR-ERO hop count: 2 + = Active Route, - = Last Active, * = Both
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 1.1.1.1 -> 1.1.1.2 192.168.1.9/32 *[SPRING-TE/6] 00:00:11, metric 1, metric2 0
SID type: 20-bit label, Value: 62 > to 1.1.1.2 via ge-0/0/0.0, Push 4109
Hop 2 (Strict): [L-ISIS/14] 4d 11:47:05, metric 40
NAI: IPv4 Node ID, Node address: 192.168.1.9 > to 1.1.1.2 via ge-0/0/0.0, Push 4109
SID type: 20-bit label, Value: 4109 to 1.1.1.6 via ge-0/0/1.0, Push 2109
to 1.1.1.46 via ge-0/0/4.0, Push 3109
Total displayed LSPs: 1 (Up: 1, Down: 0) root@R1>
root@R1>

SR OAM (SPRING-TE Tunnels) - Node SID LSP Example Cont…
root@R1> ping mpls segment-routing spring-te source-routing-path R1-to-R9-LSP-NodeSID source 192.168.1.1 tunnel-source pcep detail

root@R1>

root@R1> traceroute mpls segment-routing spring-te source-routing-path R1-to-R9-LSP-NodeSID source 192.168.1.1 tunnel-source pcep
source 192.168.1.1

1 4109 ISIS 1.1.1.2 (null) Egress <<< R4 is the egress for the first IGP Adj segment ID sub-TLV (label 62). TTL 1 is for the label 16.
FEC-Stack-Sent: ISIS,SPRING-TE FEC-Change-Recieved: POP-ISIS
1 4109 ISIS 1.1.1.2 (null) Success <<< R4 is the transit for the second Node SID label 4109. TTL 1 is for the label 4109.
FEC-Stack-Sent: SPRING-TE
2 6109 ISIS 1.1.1.14 1.1.1.2 Success <<< R6 is the transit for the sapped Node SID label 6109. TTL 2 is for the label 4109.
3 7109 ISIS 1.1.1.34 1.1.1.14 Success <<< R7 is the transit for the sapped Node SID label 7109. TTL 3 is for the label 4109.
4 3 ISIS 1.1.1.38 1.1.1.34 Egress <<< R9 is the egress for the sapped PHP label 3. TTL 4 is for the label 4109.
root@R1>
Note: There is no label assigned for the first IGP Adj segment ID sub-TLV (associated with label 62) when we send the trace packet. Hence the first router just process the IGP Adj segment ID sub-TLV and declare that it is
the egress for the first IGP Adj segment ID sub-TLV. For the second IGP Adj segment ID sub-TLV we have label 16, for the third one we have 17 and for forth one we have 18.

root@R1> traceroute mpls segment-routing spring-te source-routing-path R1-to-R9-LSP-NodeSID source 192.168.1.1 tunnel-source pcep detail
source 192.168.1.1
. . . . . .
Hop 1.1.1.2 Depth 1 MTU: 1514
Probe status: Egress . . .
Parent: (null) Label Stack:
Return code: Egress-ok at stack-depth 1 Label 1 Value 6109 Protocol ISIS
. . . FEC-Stack-Sent: SPRING-TE
MTU: Unknown <<< First Packet MTU is unknown as we print MTU
. . . from reply packet and since it is first probe, Hop 1.1.1.34 Depth 3
Label Stack: we are yet to receive any reply. Probe status: Success
Label 1 Value 4109 Protocol ISIS Parent: 1.1.1.14
FEC-Stack-Sent: ISIS,SPRING-TE Return code: Label switched at stack-depth 1
FEC-Change-Recieved: POP-ISIS . . .
MTU: 1514
Hop 1.1.1.2 Depth 1 . . .
Probe status: Success Label Stack:
Parent: (null) Label 1 Value 7109 Protocol ISIS
Return code: Label switched at stack-depth 1 FEC-Stack-Sent: SPRING-TE
. . .
MTU: Unknown Hop 1.1.1.38 Depth 4
. . . Probe status: Egress
Label Stack: Parent: 1.1.1.34
Label 1 Value 4109 Protocol ISIS Return code: Egress-ok at stack-depth 1
FEC-Stack-Sent: SPRING-TE . . .
. . . MTU: 1514
Hop 1.1.1.14 Depth 2 . . .
Probe status: Success Label Stack:
Parent: 1.1.1.2 Label 1 Value 3 Protocol ISIS
Return code: Label switched at stack-depth 1 FEC-Stack-Sent: SPRING-TE
. . .
root@R1>
SR OAM (SPRING-TE Tunnels) - Node SID LSP Trace Explanation

1

NIL FEC, as label 4109 is
4109 TTL = 1
not in present TED database
Downstream Detailed
Mapping TLV
IP 1.1.1.2, label 4109

R4 is Egress

2

not in present TED database 4109 TTL = 1
Downstream Detailed
Mapping TLV
IP 1.1.1.2, label 4109

R4 is transit.
IP 1.1.1.14, label 6109
© 2018
Each Juniper
Adj Networks
SID label would be represented by one Adj segment ID sub-TLV. We have one Adj SID labels (62) in our LSP. That is why Probe 1 is having 1 Adj segment ID sub-TLV TLVs. 341

3

Downstream Detailed
Mapping TLV
IP 1.1.1.14, label 6109

R6 is transit.
IP 1.1.1.34, label 7109
© 2018
Each Juniper
Adj Networks

4

Downstream Detailed
Mapping TLV
IP 1.1.1.34, label 7109

R7 is transit.
IP 1.1.1.38, label 3
© 2018
Each Juniper
Adj Networks

5

Downstream Detailed
Mapping TLV
IP 1.1.1.38, label 3

R9 is Egress
© 2018
Each Juniper
Adj Networks

1
4109 TTL = 1 NIL FEC, as label 4109 is 5
not in present TED database
not in present TED database 4109 TTL = 2 NIL FEC, as label 4109 is
not in present TED database 4109 TTL = 3 NIL FEC, as label 4109 is
Downstream Detailed
Downstream Detailed not in present TED database 4109 TTL = 4
Mapping TLV
IP 1.1.1.2, label 4109
MPLS Echo Reply: Probe 1 MPLS Echo Reply: Probe 3 IP 1.1.1.38, label 3
R4 is Egress R6 is transit. MPLS Echo Reply: Probe 4
Downstream Detailed Mapping TLV R7 is transit.
R9 is Egress
IP 1.1.1.38, label 3

2

not in present TED database 4109 TTL = 1 Note: We put NIL FEC for the Node SID LSP trace as we calculate the Node SID locally and it is not present in the TED database. We
put NIL FEC for all the labels which are not present in the TED database.
Downstream Detailed
Mapping TLV
IP 1.1.1.2, label 4109 However, We should not put NIL FEC in Node SID LSP trace because it is an unreliable tracing as there would not be any validation for
the FECs.
R4 is transit. Engineering confirmed that they are changing this behavior and from 19.3R1 onwards there would be “IGP IPv4 prefix sub-TLV” sub-
IP 1.1.1.14, label 6109 TLV in place of NIL FEC so that Node SID LSP tracing can be reliable.
For now, One option is to keep the start label same on all the routers and this way all the Node SID labels would be present in the TED
databases of all the routers. Then you will see “IGP IPv4 prefix sub-TLV” sub-TLV in place of NIL FEC sub-TLV in Node SID LSP trace.
© 2018
Each Juniper
Adj Networks
REFERENCES

References
RLIs:
RLI 27278 - BGP-LU Prefix SID Support - Software Functional Specification by Sanoj K Vivekanandan
RLI 27279 - Configurable SRGB for Spring Protocol ISIS - Software Functional Specification by Parag Kaneriya
RLI 27281 - MPLS Ping and Traceroute for SPRING - Software Functional Specification by Arunkumar P, Sunil Kumar, Deepti Rathi
RLI 29611 - BGP SR-TE - Software Functional Specification by S. Kolenchery, Bharat R, Salih KA, A. Nesari, J. Chen, S. Gandiboyina, S. Hegde - v1.47
RLI 31511 - Static Segment Routing LSP - Software Functional Specification by Yimin Shen
RLI 33744 - IS-IS TI-LFA - Software Functional Specification by Shelesh Bansal
RLI 33753 - BGP EPE (Peer sid + BGP LS & J-vision extensions) - Software Functional Specification by Mukul Srivastava
RLI 36838 - Static SR LSP with Label Stack (aka. Non-Colored Static SR LSP) by Yimin Shen
RLI 36966 - BGP SR-TE - Color mode support - Software Functional Specification by Vijay Kestur
RLI 37610 - First hop label support for non-colored SR-TE LSPs AND Install keyword support - Software Functional Specification by Salih K A
RLI 38689 - Color-only policy-based Routing Requirements for DT and proposed Solution_v5 - Download it
RLI 39603 - Segment Routing segment list path ERO support using IP address by Jayesh J
RLI 40089 - MPLS Ping and Traceroute phase II - (Support for SR-TE paths) by Sunil Kumar, Arunkumar P, Deepti Rathi
RFCs and Drafts:
RFC 5286 - Basic Specification for IP Fast Reroute - Loop Free Alternates
RFC 7752 - North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
RFC 8029 - Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures
RFC 8287 - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with
MPLS Data Planes
RFC 8402 - Segment Routing Architecture
BGP-LS extensions for Segment Routing BGP Egress Peer Engineering - draft-ietf-idr-bgpls-segment-routing-epe-17
Segment
© 2018 Routing Centralized BGP Egress Peer Engineering - draft-ietf-spring-segment-routing-central-epe-10
Juniper Networks 347
References Cont…
TOIs:
BGP SEGMENT routing Traffic Engineering by Santosh Kolenchery

SPRING - JTAC Primer by Ishan Sawhney
Introduction to Source Packet Routing (SPRING) in Junos by Jose Cid
Source Packet Routing (SPRING) in Junos - v5 by Martin Ehlers
Docs:
Fundamentals of Egress Peering Engineering - Application Note

Segment Routing - Reachability, Protection, Traffic Engineering by Anurag Khare
Books:
Day One - Configuring Segment Routing with Junos

Day One - Inside Segment Routing book Configs by By Anurag Khare and Colby Barth
MPLS in the SDN Era - Interoperable Scenarios to Make Networks Scale to New Services - (Chapter 18 for LFA)
Links:
https://packetpushers.net/ip-frr-micro-loops-part-2/
https://packetpushers.net/yet-another-blog-about-segment-routing-part2-ti-lfa/
http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4/


Segment Routing Fundamentals26

Uploaded by

Copyright:

Available Formats

You might also like

Segment Routing Fundamentals26

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Segment Routing Fundamentals26

Uploaded by

Copyright:

Available Formats

SEGMENT ROUTING

© 2018 Juniper Networks 1

• SRGB and SRLB 016

• Introduction to Different SIDS 022

• Provisioning LSPs using different SIDs 087

• Traffic engineering with SPRING 135

• Static LSP & static segments 187

• Basics of LFA and TI-LFA 212

• SR-TE Telemetry 243

© 2018 Juniper Networks 3

Local Segment: Only originating node understands associated instruction.

© 2018 Juniper Networks 5

© 2018 Juniper Networks 7

R1 (Ingress) R14 (Egress)

Adjacency Label =555

1. From R1, follow the shortest IGP path to R6.

root@R1> show isis database R1.00-00 extensive

Rest of the Flags are not defined

© 2018 Juniper Networks 10

• No negotiations while assigning labels.

© 2018 Juniper Networks 11

Operational Very simple Simple Complex

Number of IGP IGP+LDP IGP+RSVP

© 2018 Juniper Networks 13

TE Yes, simple TE is not supported Complex

© 2018 Juniper Networks 14

Base Anycast SID:

© 2018 Juniper Networks 15

© 2018 Juniper Networks 16

root@R1> show configuration protocols isis source-packet-routing

© 2018 Juniper Networks 17

root@R1> show isis overview root@R1> show mpls label usage

© 2018 Juniper Networks 19

root@R1> show mpls label usage

© 2018 Juniper Networks 20

dbgsh [-d daemon-name] [-l logical-system-name] command [argument...]

© 2018 Juniper Networks 22

© 2018 Juniper Networks 23

© 2018 Juniper Networks 25

Spray-SID and Tree-SID are not covered in this document.

© 2018 Juniper Networks 26

where: L-Flag: It is set when value is of local significance: By default it is set.

S-Flag: It indicates adj-sid refers to set of adjacencies.

© 2018 Juniper Networks 27

SID: a SID: b SID: c SID: d

© 2018 Juniper Networks 30

1048578(Unilist, IPv4, ifl:0:-, pfe-id:0)

525 Unicast ge-0/0/1.0 - MPLS->IPv4 Ethernet 1500 0x0000000000200001 0x0000000000000002

Weight Info: Current Weight = 1

set protocols isis interface-group group-1 interface ge-0/0/0.0 weight 1

root@R1> show route label 1000000 extensive table mpls.0

mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)

Type: TBD, suggested value 3;

© 2018 Juniper Networks 36

Prefix SID Config: Node SID Config (Without Policy):

© 2018 Juniper Networks 39

inet.0: 43 destinations, 53 routes (43 active, 0 holddown, 0 hidden)

used by routers for ge-0/0/4

R9’s Node SID. R1 - lo0.0- ge-0/0/0