SDN Workshop

Contact: training@apnic.net

Issue Date: [Date]

Revision: [xx]

WSDN01_v0.1
Segment Routing
SDN Workshop

Issue Date: [Date]

Revision: [xx]

WSDN01_v0.1
Overview
• In a nutshell
• Introduction to MPLS
• Segment Routing Introduction
• Architecture
• MPLS data plane
• IPv6 data plane
• BGP EPE
• LDP inter-working

3
In a nutshell

4
 SDN architectural framework
Application Application Service
Plane
Northbound Interfaces REST/RESTCONF/NETCONF/XMPP

Network Services Abstraction Layer

East/West-
Topology Discovery Traffic Engineering Resource bound
Control & Management Management
interfaces –
Plane Route selection & Configuration
BGP
failover
(controller)

Open
Southbound Interfaces BGP-LS i2RS PCE-P ForCES IPFIX SNMP Netconf
Flow

BGP RIBs PCC SNMP OpenFlow YANG

MIBs

Data Segment RSVP-

Device & Resource Abstraction
Layer (DAL)
Plane Routing TE

Network Devices – IP/MPLS/Transport

Note: designations of north-bound and south-bound are relative to the control plane (“controller”)

5
Segment routing: in a nutshell…

What? The source determines the path a packet should take

By encoding the path within the packet as a sequence

How? of segments or instructions.

To reduce network state and allow centralised computation

Why? of paths

6
MPLS
Introduction

7
Introduction
• MPLS: Multi-Protocol Label Switching
• Tunneling mechanism that supports a number of types of
payloads (hence “multi”)
• Concept of Forwarding Equivalence Class (FEC): groups of
packets that need to be forwarded in an identical manner.
– Each FEC is assigned a label, a 20-bit opaque value

• Packets are classified into FECs at network ingress and an

MPLS label corresponding to the FEC is added to the
packet
• Intermediate hops swap the MPLS label and forward the
packet onwards to their next-hops
8
MPLS label stack entry

Payload

Transport

IP MPLS Shim Header

Data Link Layer

encapsulation

LER LSR

9
MPLS label operations
• PUSH:
– Adds a new label to the label stack (which may be empty)

• SWAP:
– Acts on the top (outer) label
– Replaces the top label value with another label value

• POP:
– Removes the top label, exposing either another label or the payload
of the MPLS packet

10
MPLS tables
• NHLFE (Next Hop Label Forwarding Entry):
– Used for forwarding labeled packets
– Contains next-hop, label operation, link-layer encapsulation
information

• ILM (Incoming Label Map):

– Mapping between incoming labels and NHLFEs

• FEC to NHLFE map (FTN):

– Used for forwarding unlabeled packets
– Maps each FEC to a set of NHLFEs

11
MPLS node types

LSR LSR LSR

iLER eLER

Ingress Label Edge Egress Label Edge

Router (iLER) Router (eLER)
MPLS router that MPLS router that
pushes MPLS label LSR LSR LSR pops MPLS label

Label Switch Router

(LSR)
MPLS router that
Label Switch Path swaps MPLS label
Path taken by MPLS
packets from iLER to eLER

12
MPLS VPN node types

P P P

PE PE

Provider Edge Provider Edge

VPN LER VPN LER

P P P

Provider Router (P)

LSR in an MPLS VPN
network
Label Switch Path
Path taken by MPLS
packets from PE to PE

13
BGP/MPLS: service (VPN) label
exchange

192.168.1.1 192.168.1.2 192.168.1.3

P1 P2 P3

BGP-MPLS
CE1 PE1 FEC: VPN-X PE2 CE2
Label: 1234

192.168.1.11 192.168.2.22

P4 P5 Metric: 100
P6

192.168.1.4 192.168.1.5 192.168.1.6

All IGP metrics are equal to 10

unless otherwise indicated

14
LDP: building the ILM
ILM
ILM In- Out- Intf
label label
In- Out- Intf
ILM
label label 300 200 To-P3
In-label Out-label Interface
400 300 To-P2
200 100 To-PE2
192.168.1.1 192.168.1.2 192.168.1.3

ILM
P1 P2 P3 In-label Out-label Interface

100 - Local
LDP LDP
FEC: PE2 FEC: PE2
Label: 300 Label: 200
LDP
CE1 PE1 LDP
FEC: PE2 PE2 CE2
FEC: PE2
Label: 400 LDP Label: 100
192.168.1.11 FEC: PE2 192.168.2.22
Label: 300

FTN P4 P5 Metric: 100

P6
FEC Out- Intf
label
192.168.1.4 192.168.1.5 192.168.1.6
PE-2 400 To-P1

ILM
All IGP metrics are equal to 10
In- Out- Intf
label label unless otherwise indicated
500 300 To-P2

15
LDP: traffic forwarding
Swap 400 Swap 300 Swap 200
for 300 for 200 for 100
300 200
1234 1234
192.168.1.1 192.168.1.2 192.168.1.3
Payload Payload
400 100
1234 P1 P2 P3 1234
Payload Payload

Payload Payload

CE1 PE1 PUSH 1234, 400 POP 100, 1234 PE2 CE2

192.168.1.11 192.168.2.22

P4 P5 Metric: 100
P6

192.168.1.4 192.168.1.5 192.168.1.6

Packet destined
to PE2 arrives at
PE1 All IGP metrics are equal to 10
unless otherwise indicated

16
LDP: building the ILM (with PHP)
ILM
ILM In- Out- Intf
label label
In- Out- Intf
ILM
label label 300 200 To-P3
In-label Out-label Interface
400 300 To-P2
200 - To-PE2
192.168.1.1 192.168.1.2 192.168.1.3

P1 P2 P3

LDP LDP
FEC: PE2 FEC: PE2
Label: 300 Label: 200
LDP
CE1 PE1 LDP
FEC: PE2 PE2 CE2
FEC: PE2
Label: 400 LDP Label: 3
(implicit null)
192.168.1.11 FEC: PE2 192.168.2.22
Label: 300

FTN P4 P5 Metric: 100

P6
FEC Out- Intf
label
192.168.1.4 192.168.1.5 192.168.1.6
PE-2 400 To-P1
PHP: Penultimate Hop Pop
ILM
All IGP metrics are equal to 10
In- Out- Intf
label label unless otherwise indicated
500 300 To-P2

17
LDP: traffic forwarding (with PHP)
Swap 400 Swap 300
for 300 for 200 Pop 200
300 200
1234 1234
192.168.1.1 192.168.1.2 192.168.1.3
Payload Payload
400
1234 P1 P2 P3 1234
Payload Payload

Payload Payload

CE1 PE1 PUSH 1234, 400 POP 1234 PE2 CE2

192.168.1.11 192.168.2.22

P4 P5 Metric: 100
P6

192.168.1.4 192.168.1.5 192.168.1.6

Packet destined
to PE2 arrives at
PE1 All IGP metrics are equal to 10
unless otherwise indicated

18
LDP: observations
• LDP forwarding follows the IGP shortest paths
• All nodes install an ILM entry for every LDP destination
• A single LDP label (associated with the destination) is
required to transport packets
• Labels are assigned by the downstream routers i.e. the
label a router uses for ILM lookup is that assigned by the
router itself
• LDP label changes at each hop as labels are locally-
significant

19
RSVP-TE: signaling an LSP (1)

RSVP-TE
Msg: PATH
192.168.1.1 Dest: PE2 192.168.1.2 192.168.1.3

RSVP-TE
Msg: PATH P1 P2 P3
Dest: PE2

RSVP-TE
CE1 PE1 Msg: PATH PE2 CE2
RSVP-TE
Dest: PE2 Msg: PATH
192.168.1.11 Dest: PE2
192.168.2.22

P4 P5 P6 RSVP-TE
Metric: 100 Msg: PATH
Dest: PE2
192.168.1.4 192.168.1.5 192.168.1.6

All IGP metrics are equal to 10

unless otherwise indicated

20
RSVP-TE: signaling an LSP (2)
ILM
ILM In- Out- Intf
label label
In- Out- Intf
label label 666 777 To-P5
555 666 To-P2

192.168.1.1 192.168.1.2 192.168.1.3

ILM
P1 P2 P3 In-label Out-label Interface

999 POP Local

RSVP-TE
Msg: RESV
Label: 666 ILM
CE1 PE1 RSVP-TE
In- Out- Intf PE2 CE2
Msg: RESV
label label
Label: 555
RSVP-TE 888 999 To-PE2
192.168.1.11 Msg: RESV 192.168.2.22
Label: 777

FTN P4 P5 Metric: 100

P6 RSVP-TE
Msg: RESV
FEC Out- Intf
Label: 999
label
192.168.1.4 192.168.1.5 RSVP-TE 192.168.1.6
LSP1 555 To-P1 Msg: RESV
Label: 888

ILM
All IGP metrics are equal to 10
In- Out- Intf
label label unless otherwise indicated
777 888 To-P6

21
RSVP-TE: traffic forwarding
Swap 555 Swap 666
for 666 for 777
666
1234
192.168.1.1 192.168.1.2 192.168.1.3
Payload
555
1234 P1 P2 P3
Payload

Payload Payload
777
PUSH 1234,
CE1 PE1 555
1234 POP PE2 CE2
888 999,1234
Payload
192.168.1.11
1234
192.168.2.22
Payload
999
P4 P5 Metric: 100
P6 1234
Payload
192.168.1.4 192.168.1.5 192.168.1.6
Packet mapped
to LSP1 Swap 777 Swap 888
for 888 for 999 All IGP metrics are equal to 10
unless otherwise indicated

22
RSVP-TE: observations
• RSVP-TE allows the construction of arbitrary paths based
on traffic-engineering requirements i.e. longer IGP paths
may end up being preferred
• For two nodes to communicate, RSVP-TE LSPs need to be
signaled in both directions.
• RSVP-TE maintains soft-state which needs to be refreshed
periodically
• RSVP-TE label changes at each hop as labels are locally-
significant

23
MPLS label distribution protocols
Attribute LDP RSVP-TE BGP
Relative Complexity Low High Medium
Application Shortest-path routing Traffic engineering Scaling (seamless
MPLS)
Label allocation (unicast) Multipoint-to-point Point-to-point Point-to-point
Label significance Local Local Local
Multicast mLDP extensions p2mp LSPs N/A
Traffic-engineering No Yes No
Fast Reroute (FRR) Yes (xLFA extensions) Yes Yes (BGP PIC)
FRR coverage Usually <100% via 100% via link and Limited to BGP PIC
xLFA but not node protection
guaranteed
Scaling O(n) O(n^2) O(n)
One LSP per Full-mesh required for One LSP per
destination complete coverage destination
IGP interaction Dependent Required for TE N/A
extensions

24
Challenges
• How do we achieved fine-grained traffic-engineering at
scale ?
– RSVP-TE faces scaling challenges due to it’s connected-oriented
meshing requirement
– LDP does not have traffic-engineering capabilities

• We need a mechanism that marries the best of RSVP-TE

with the best of LDP

25
Segment
Routing
introduction

26
Standardisation
• Defined by the SPRING (Source Packet Routing in
Networking) in working group of the IETF
• The ability for a node to specify a forwarding path, other
than the normal shortest path, that a particular packet will
traverse, benefits a number of network functions:
– Some types of network virtualization, including multi-topology
networks and the partitioning of network resources for VPNs
– Network, link, path, and node protection such as fast reroute
– Network programmability
– OAM techniques
– Simplification and reduction of network signaling components
– Load balancing and traffic engineering

27
Requirements

• MUST allow incremental and selective deployment without

requiring a flag day or massive upgrade of all network
elements
• MUST allow putting policy state in the packet header and
not in the intermediate nodes along the path i.e. there
should be no policy state in mid-points and tail-ends.

28
Source Routing
• Segment Routing leverages the concept of Source Routing,
where the source of the packet includes routing information
within the data packet itself.
• Contrast this with hop-by-hop destination-based routing,
where each intermediate point makes a determination of
how a packet needs to be forwarded
• Supported data planes:
– MPLS – without any modification (this section focusses chiefly on the
MPLS data plane)
– IPv6 – with the use of a new IPv6 Routing Header type

29
How it works
• The source determines the path a packet should take and
encodes it within the packet as a sequence of segments or
instructions.
• For routing purposes, segments are topological
instructions:
– node: take shortest path to the node
– adjacency: send packet over the specified adjacency regardless of
IGP metric

• Intermediate hops inspect the segment list and route as per

the instructions implied by it; no per-path state is kept

30
Use case: IGP-based MPLS tunneling

PE1 installs prefix Z in VRF

for VPN-X and resolves next-
hop to PE2 via an IGP-based P1 P2
MPLS tunnel to PE2
Route to Z
MP-BGP: VPN-X, route to Z,
label LZ, next-hop PE2
A CE1 PE1 PE2 CE2 Z

VPN-X P3 P4 VPN-X

31
Use case: Fast Reroute (FRR)
• Support of FRR on any topology
• Precomputation and setup of backup path without any
additional signaling (other than the regular IGP/BGP
protocols)
• Support of shared risk constraints
• Support of node and link protection
• Support of micro-loop avoidance

32
Use case: traffic engineering
• Loose or strict options
• Bandwidth admission control
• Distributed vs. centralized model
• Disjointness in dual-plane networks
• Egress peer engineering
• Load balancing among non-parallel links (i.e., links connected to
different adjacent neighbors).
• Limiting (scalable, preferably zero) per-service state and signaling on
midpoint and tail-end routers.
• ECMP-awareness

33
 • Routing:
– Traffic-engineered. The link from PE5 to
PE6 has a link-metric of 100 . How do we
Sneak preview: force traffic over this link ?

SR-TE example
• Segments Identifiers:
– Node and Adjacency segments

34
Objectives Objectives:

• All traffic from PE1 to

PE2 should traverse
P2 but avoid the P2-
P3 link

P1 P2 P3

CE1 PE1 PE2 CE2

P4 P5 Metric: 100
P6

All IGP metrics are equal to 10

unless otherwise indicated

35
Traffic forwarding
Node P2
Node P5
P5-P6 link
Node P2 Node PE2
Node P5 VPN X
P5-P6 link Payload
Node PE2
VPN X P1 P2 P3
Payload Node P5
P5-P6 link
Payload Payload
PE2 PE2

CE1 PE1 VPN X VPN X PE2 CE2

PE2
Payload Payload
VPN X
Payload

P4 P5 Metric: 100
P6

All IGP metrics are equal to 10

unless otherwise indicated

36
Architecture

37
Introduction
• Segment Routing (SR) allows a node to steer a packet
through an ordered list of instructions, called segments.
• Segments can represent any type of instruction:
– Topological
– Service
– Application
– Etc.
• Semantics of a segment can be local to an SR node or
global within the SR domain
• Allows steering of flows without requiring per-flow state at
intermediate points in the network

38
Terminology (1)
Segment
an instruction a node executes on an incoming packet. For example:
• 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

Global Segment
The related instruction is supported by all SR-capable routers in the
domain

39
Terminology (2)
Local Segment
The related instruction is only supported by the router originating it

Segment Identifier (SID)

identifier for a segment. Current options include:
• An absolute MPLS label value
• An index value in an MPLS label space
• An IPv6 address

40
Terminology (3)
Segment List
an ordered list of SIDs encoding the ordered set of instructions to be
applied to a packet as it traverses an SR domain. In an MPLS data plane,
the Segment List is instantiated as a stack of labels. In an IPv6 data
plane, it is instantiated as an ordered list of IPv6 addresses.

Segment Routing Domain (SR Domain)

the set of nodes participating in the source-based routing model

41
Terminology (4)
SR Global Block (SRGB)
set of local MPLS labels reserved for global segments.

Segment List Depth

The number of segments in a segment list

42
Segment list (1)
• An ordered list of SIDs encoding the ordered set of
instructions to be applied to a packet as it traverses an SR
domain. In an MPLS data plane, the Segment List is
instantiated as a stack of labels. In an IPv6 data plane, it is
instantiated as an ordered list of IPv6 addresses.
• The Active Segment that must be used by the receiving
router to process the packet is:
– The top label in the MPLS dataplane
– The destination address of a packet with a Segment Routing Header
(SRH) in the IPv6 dataplane

43
Segment list (2)
• The segment list imposed by the SR node at the edge of
the SR domain can be computed either:
– locally by an operator
– provisioned via NETCONF
– provisioned via PCE-P

44
IGP segments
IGP Segments
Segments identifying information
advertised by an IGP

IGP-Adjacency Segments
IGP-Prefix Segments Local (Adjacency-SID)
Segment representing an IGP
Global (Prefix-SID)
adjacency
Segment representing an IGP Semantics:
prefix • SR header operation: NEXT
• Next-hop: related egress
interface

IGP-Anycast Segments IGP-Node Segments Remote-Binding Segment

Global (Anycast-SID) Global (Node-SID) Global (Binding-SID)
Segment representing an anycast Advertised by a Mapping Server for
Segment identifying a specific router
prefix prefixes attached to non-SR routers

45
Node SIDs
• Node SIDs are used to identify nodes as destinations
• Globally significant, by default
• Nodes-SIDs are essentially instructions to forward a packet
via the shortest ECMP-aware IGP path to the destination
node
• Advertised by the link-state IGP (OSPF, IS-IS)
• Need to be manually configured

46
Anycast SIDs
• A SID that is advertised by all the members of an Anycast
set
• All routers in the set advertise the same Anycast prefix and
SID value
• Globally significant, by default
• Anycast-SIDs are essentially instructions to forward a
packet via the shortest ECMP-aware IGP path to the
topologically closest member of the Anycast set
• Advertised by the link-state IGP (OSPF, IS-IS)

47
Adjacency SIDs
• Nodes allocate one Adj-SID for each of its adjacencies

• Nodes may allocate multiple Adj-SIDs to the same adjacency

• A node may allocate the same Adj-SID to multiple adjacencies:

– Packets containing such an Adj-SID are then hashed across the different
adjacencies

• Locally significant, by default, and is installed only in the FIB of the

originating router

• Adj-SIDs are essentially instructions to forward a packet out a specific

interface regardless of IGP link metric

• Advertised by the link-state IGP (OSPF, IS-IS)

48
BGP peering segments
An ingress border router of an
AS can steer a flow along a
selected AS, towards a
BGP Peering Segments
selected egress border router • Segments identifying by a BGP EPE (Egress
of the AS and through a Peer Engineering)-enabled node.
specific peer by using BGP • Enable the expression of source-routed inter-
Egress Peer Engineering domain paths
capabilities

Peer Node Segments Peer Adjacency Segments Peer Set Segments

Local (PeerNode-SID) Local (PeerAdj-SID) Local (PeerSet-SID)
Segment representing a BGP Segment representing an adjacency Segment representing a set of BGP
peering node to a BGP peering node peering nodes

Semantics: Semantics: Semantics:

• SR header operation: NEXT • SR header operation: NEXT • SR header operation: NEXT
• Next-hop: connected peering • Next-hop: peer connected • Next-hop: load-balance across
node to which the segment is through the interface to which the any connected interface to any
related segment is related peer in the related group

49
Segment operations
Operation Segment MPLS data IPv6 data plane
Routing plane
semantic
PUSH Insertion of a PUSHing a new Setting of the first
segment at the top label on to the segment in the
of the segment list label stack IPv6 Segment
Routing Header
NEXT Signals completion POPping of the top Activation of the
of active segment label in the label next segment in
and activation of stack the IPv6 Segment
the next segment Routing Header
in the segment list segment list
CONTINUE Signals that the SWAP of the top Standard IPv6
currently active label forwarding based
segment is not yet on destination
complete and address
needs to remain
active

50
MPLS data plane

51
MPLS data plane
• A segment is encoded as an MPLS label
• An ordered list of segments is encoded as a stack of labels
• The active segment is the one on the top of the label stack
i.e. top MPLS label
• There is zero change to the operation of the standard
MPLS data plane

52
SR Global Block (SRGB)
• Set of local MPLS labels
reserved for global 1048575

segments.
• Network operation is

…
greatly simplified if all
32767
nodes in the SR domain
SRGB
are configured with the 16384

same SRGB.
0

• In this example, SRGB MPLS Label Space

range is 16483-32767

53
 • Segment Identifiers:
– Node-SIDs
Label – Allocated as absolute globally-
advertisement significant MPLS label values
with common
SRGB • SRGB:
– Identical SRGB configured on all
nodes

54
SID advertisements (1)
Association of
SID to prefix
advertised by IGP

192.168.1.1 192.168.1.2 192.168.1.3

SID: 101 SID: 102 SID: 103
SRGB: 100-199 SRGB: 100-199 SRGB: 100-199

P1 P2 P3

ILM ILM (no-PHP) ILM

In-label Out-label Interface In-label Out-label Interface In-label Out-label Interface

103 103 To-P2 103 103 To-P3 103 - Local

ILM (with PHP)

In-label Out-label Interface

103 - To-P3

Identical SRGB on all nodes

55
SID advertisements (2)
Association of
SID to prefix
advertised by IGP

192.168.1.1 192.168.1.2 192.168.1.3

SID: 101 SID: 102 SID: 103
SRGB: 100-199 SRGB: 100-199 SRGB: 100-199

P1 P2 P3

ILM (no-PHP) ILM ILM (no-PHP)

In-label Out-label Interface In-label Out-label Interface In-label Out-label Interface

102 102 To-P2 102 - Local 102 102 To-P2

ILM (with PHP) ILM (with PHP)

In-label Out-label Interface In-label Out-label Interface

102 - To-P2 102 - To-P2

Identical SRGB on all nodes

56
SID advertisements (3)
Association of
SID to prefix
advertised by IGP

192.168.1.1 192.168.1.2 192.168.1.3

SID: 101 SID: 102 SID: 103
SRGB: 100-199 SRGB: 100-199 SRGB: 100-199

P1 P2 P3

ILM ILM (no-PHP) ILM

In-label Out-label Interface In-label Out-label Interface In-label Out-label Interface

101 - Local 101 101 To-P1 101 101 To-P2

ILM (with PHP)

In-label Out-label Interface

101 - To-P1

Identical SRGB on all nodes

57
Dealing with different SRGBs
• If nodes in the same SR
domain have different 1048575

SRGBs, absolute label

values can not be used

…
• In such a case, a globally
32767
unique index is used
SRGB
instead. 16384
Index
• The local label at a given 0
used as
offset

node is found by adding MPLS Label Space

the globally-unique index

to the node’s SRGB.

58
Using index values
Example: index value of 100

1048575 1048575
Node A Node B

…
131071
…

SRGB
65536
32767

SRGB
16384

0 0
MPLS Label Space MPLS Label Space

Absolute label value Absolute label value

= 16384+100 = 16484 = 65536+100 = 65636

59
 • Segment Identifiers:
– Node-SIDs
– Allocated as globally-unique index
Label index values
advertisement
with SRGB • SRGB:
– Different SRGB configured on all
nodes

60
SID advertisements (1)
Association of
SID to prefix
advertised by IGP

192.168.1.1 192.168.1.2 192.168.1.3

Label index: 1 Label index: 2 Label index: 3
SRGB: 100-199 SRGB: 200-299 SRGB: 300-399

P1 P2 P3

ILM ILM (no-PHP) ILM

In-label Out-label Interface In-label Out-label Interface In-label Out-label Interface

103 203 To-P2 203 303 To-P3 303 - Local

ILM (with PHP)

In-label Out-label Interface

203 - To-P3

Identical SRGB on all nodes

61
SID advertisements (2)
Association of
SID to prefix
advertised by IGP

192.168.1.1 192.168.1.2 192.168.1.3

Label index: 1 Label index: 2 Label index: 3
SRGB: 100-199 SRGB: 200-299 SRGB: 300-399

P1 P2 P3

ILM (no-PHP) ILM ILM (no-PHP)

In-label Out-label Interface In-label Out-label Interface In-label Out-label Interface

102 202 To-P2 202 - Local 302 202 To-P2

ILM (with PHP) ILM (with PHP)

In-label Out-label Interface In-label Out-label Interface

102 - To-P2 302 - To-P2

Identical SRGB on all nodes

62
SID advertisements (3)
Association of
SID to prefix
advertised by IGP

192.168.1.1 192.168.1.2 192.168.1.3

Label index: 1 Label index: 2 Label index: 3
SRGB: 100-199 SRGB: 200-299 SRGB: 300-399

P1 P2 P3

ILM ILM (no-PHP) ILM

In-label Out-label Interface In-label Out-label Interface In-label Out-label Interface

101 - Local 201 101 To-P1 301 201 To-P2

ILM (with PHP)

In-label Out-label Interface

201 - To-P1

Identical SRGB on all nodes

63
BGP/MPLS VPN • Routing:
(common to all subsequent – BGP/MPLS VPN label advertisement
use cases)

64
Example: service label exchange
All subsequent examples use
the service label value of 1234

192.168.1.1 192.168.1.2 192.168.1.3

P1 P2 P3

BGP-MPLS
CE1 PE1 FEC: VPN-X PE2 CE2
Label: 1234

192.168.1.11 192.168.2.22

P4 P5 Metric: 100
P6

192.168.1.4 192.168.1.5 192.168.1.6

All IGP metrics are equal to 10

unless otherwise indicated

65
 • Routing:
– ECMP-aware shortest path routing

Use case 1:
• Segment Identifiers:
ECMP-aware – Node-SIDs only
– Allocated as absolute globally-
shortest path significant MPLS label values
routing
• SRGB:
– Identical SRGB configured on all nodes

66
 Objectives Objectives:

• Deliver traffic between

PE1 and PE2 via the
192.168.1.1
SID: 101
192.168.1.2 192.168.1.3 shortest IGP path
SID: 102 SID: 103
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499

P1 P2 P3

CE1 PE1 PE2 CE2

192.168.1.11 192.168.2.22
SID: 111 SID: 222
SRGB: 100-499 SRGB: 100-499

P4 P5 Metric: 100
P6
Use case 1

Routing Shortest-path 192.168.1.4 192.168.1.5 192.168.1.6

SID: 104 SID: 105 SID: 106
SIDs Node SRGB: 100-499 SRGB: 100-499 SRGB: 100-499

Label Value Absolute

SRGB Common

67
 Building the ILM
ILM
ILM
In- Out- Intf
In- Out- Intf
label label
label label
In-label Out-label Interface
222 222 To-P2
222 222 To-P3 ILM
192.168.1.1 192.168.1.2 192.168.1.3 222 222 To-PE2
SID: 101 SID: 102 SID: 103
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499
ILM
In- Out- Intf
label label
P1 P2 P3
222 222 To-P1

ILM
CE1 PE1 In- Out- Intf PE2 CE2
label label

192.168.1.11 222 222 To-PE2 192.168.2.22

SID: 111 SID: 222
SRGB: 100-499 SRGB: 100-499

P4 P5 Metric: 100
P6
Use case 1

Routing Shortest-path 192.168.1.4 192.168.1.5 192.168.1.6 Association of

SID: 104 SID: 105 SID: 106
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499 SID to prefix
SIDs Node
advertised by IGP
Label Value Absolute ILM ILM
All IGP metrics are equal to 10
SRGB Common In- Out- Intf In- Out- Intf
label label label label unless otherwise indicated
222 222 To-P5 222 222 To-P2 Identical SRGB on all nodes

68
 Traffic forwarding
Swap 222 Swap 222 Swap 222
for 222 for 222 for 222
222 222
192.168.1.1 1234 192.168.1.2 1234 192.168.1.3
SID: 101 SID: 102 SID: 103
Payload Payload
222
222
P1 P2 P3 1234
1234
Payload
Payload

Payload Payload

CE1 PE1 PUSH 1234, POP 222, PE2 CE2

222 1234

192.168.1.11 192.168.2.22
SID: 111 SID: 222

P4 P5 Metric: 100
P6
Use case 1

Routing Shortest-path
192.168.1.4 192.168.1.5 192.168.1.6
SIDs Node SID: 104 SID: 105 SID: 106
Label Value Absolute
All IGP metrics are equal to 10
SRGB Common
unless otherwise indicated

69
 • Routing:
– ECMP-aware shortest path routing

Use case 2:
• Segment Identifiers:
ECMP-aware – Node-SIDs only
– Allocated as index values
shortest path
routing
• SRGB:
– Different SRGB configured on different
nodes

70
 Objectives Objectives:

• Deliver traffic between

PE1 and PE2 via the
192.168.1.1
SID index: 1
192.168.1.2 192.168.1.3 shortest IGP path
SID index: 2 SID index: 3
SRGB: 200-299 SRGB: 300-399 SRGB: 400-499

P1 P2 P3

CE1 PE1 PE2 CE2

192.168.1.11
SID index: 11
SRGB: 100-199

P4 P5 Metric: 100
P6
Use case 2

Routing Shortest-path 192.168.1.4 192.168.1.5 192.168.1.6

SID index: 4 SID index: 5 SID index: 6
SIDs Node SRGB: 500-599 SRGB: 600-699 SRGB: 700-799

Label Value Index

All IGP metrics are equal to 10
SRGB Different
unless otherwise indicated

71
 Building the ILM
ILM
ILM
In- Out- Intf
In- Out- Intf
label label
label label
In-label Out-label Interface
222 322 To-P2
322 422 To-P3 ILM
192.168.1.1 192.168.1.2 192.168.1.3 422 822 To-PE2
SID index: 1 SID index: 2 SID index: 3
SRGB: 200-299 SRGB: 300-399 SRGB: 400-499
ILM
In- Out- Intf
label label
P1 P2 P3
122 222 To-P1

ILM
CE1 PE1 In- Out- Intf PE2 CE2
label label

192.168.1.11 722 822 To-PE2 192.168.2.22

SID index: 11 SID index: 22
SRGB: 100-199 SRGB: 800-899

P4 P5 Metric: 100
P6
Use case 2

Routing Shortest-path 192.168.1.4 192.168.1.5 192.168.1.6 Association of

SID index: 4 SID index: 5 SID index: 6
SRGB: 500-599 SRGB: 600-699 SRGB: 700-799 SID to prefix
SIDs Node
advertised by IGP
Label Value Index ILM ILM
All IGP metrics are equal to 10
SRGB Different In- Out- Intf In- Out- Intf
label label label label unless otherwise indicated
522 622 To-P5 622 322 To-P2

72
 Traffic forwarding
Swap 222 Swap 322 Swap 422
for 322 for 422 for 822
322 422
192.168.1.1 1234 192.168.1.2 1234 192.168.1.3
SID index: 1 SID index: 2 SID index: 3
Payload Payload
822
222
P1 P2 P3 1234
1234
Payload
Payload

Payload Payload

CE1 PE1 PUSH 1234, POP 822, PE2 CE2

222 1234

192.168.1.11 192.168.2.22
SID index: 11 SID index: 22

P4 P5 Metric: 100
P6
Use case 2

Routing Shortest-path
192.168.1.4 192.168.1.5 192.168.1.6
SIDs Node SID index: 4 SID index: 5 SID index: 6
Label Value Index
All IGP metrics are equal to 10
SRGB Different
unless otherwise indicated

73
 • Routing:
– Traffic-engineered

• Segment Identifiers:
Use case 3: – Node-SIDs only
– Allocated as absolute globally-
SR-TE significant MPLS label values

• SRGB:
– Identical SRGB configured on all nodes

74
 Objectives Objectives:

• All traffic from PE1 to

PE2 should traverse
192.168.1.1
SID: 101
192.168.1.2 192.168.1.3 P2 but avoid the P2-
SID: 102 SID: 103
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499 P3 link

P1 P2 P3

CE1 PE1 PE2 CE2

192.168.1.11 192.168.2.22
SID: 111 SID: 222
SRGB: 100-499 SRGB: 100-499

P4 P5 P6
Use case 3

Routing Traffic-engineered 192.168.1.4 192.168.1.5 192.168.1.6

SID: 104 SID: 105 SID: 106
SIDs Node SRGB: 100-499 SRGB: 100-499 SRGB: 100-499

Label Value Absolute

All IGP metrics are equal to 10
SRGB Common
unless otherwise indicated

75
 Building the ILM
In-label Out-label Interface
ILM ILM
222 222 To-PE2
ILM In- Out- Intf
label label 111 111 To-P2
In- Out- Intf
label label 105 105 To-P5 101 101 To-P2
102 102 To-P2 192.168.1.1 192.168.1.2 192.168.1.3
SID: 101 SID: 103 102 102 To-P2
SID: 102
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499 103 - Local

104 104 To-P2

P1 P2 P3 105 105 To-P2

106 106 To-PE2

ILM
CE1 PE1 Association of In- Out- Intf PE2 CE2
SID to prefix label label
advertised by IGP 222 222 To-PE2
192.168.1.11 192.168.2.22
SID: 111 SID: 222
SRGB: 100-499 SRGB: 100-499

P4 P5 P6
Use case 3

Routing Traffic-engineered 192.168.1.4 192.168.1.5 192.168.1.6 Association of

SID: 104 SID: 105 SID: 106
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499 SID to prefix
SIDs Node
advertised by IGP
Label Value Absolute ILM
All IGP metrics are equal to 10
SRGB Common In- Out- Intf
label label unless otherwise indicated
222 222 To-P6

76
 Traffic forwarding
102
Swap 102
for 102 105 Pop 102
222
102 192.168.1.1 1234 192.168.1.2 192.168.1.3
105 SID: 101 SID: 102 SID: 103
Payload
222
1234 P1 P2 P3
POP 222,
Payload 1234

Payload 105 Payload

222 222
PUSH 1234,
CE1 PE1 222, 105, 102 1234 1234 PE2 CE2
222
Payload Payload
1234
192.168.1.11 192.168.2.22
SID: 111
Payload SID: 222

P4 P5 P6 Swap 222
Pop 105 for 222
Use case 3

Routing Traffic-engineered
192.168.1.4 192.168.1.5 192.168.1.6
SIDs Node SID: 104 SID: 105 SID: 106
Label Value Absolute
All IGP metrics are equal to 10
SRGB Common
unless otherwise indicated

77
 • Routing:
– Traffic-engineered. Difference from use case
3 is the link-metric of 100 from PE5 to PE6.
How do we force traffic over this link ?

Use case 4: • Segment Identifiers:

– Node-SIDs and Adj-SIDs
SR-TE – Node-SIDs allocated as absolute globally-
significant MPLS label values

• SRGB:
– Identical SRGB configured on all nodes

78
 Objectives Objectives:

• All traffic from PE1 to

PE2 should traverse
192.168.1.1
SID: 101
192.168.1.2 192.168.1.3 P2 but avoid the P2-
SID: 102 SID: 103
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499 P3 link

P1 P2 P3

CE1 PE1 PE2 CE2

192.168.1.11
SID: 111
SRGB: 100-499

P4 P5 Metric: 100
P6
Use case 4

Routing Traffic-engineered 192.168.1.4 192.168.1.5 192.168.1.6

SID: 104 SID: 105 SID: 106
SIDs Node, Adjacency SRGB: 100-499 SRGB: 100-499 SRGB: 100-499

Label Value Absolute

All IGP metrics are equal to 10
SRGB Common
unless otherwise indicated

79
 Building the ILM
In-label Out-label Interface
ILM ILM
222 222 To-PE2
ILM In- Out- Intf
label label 111 111 To-P2
In- Out- Intf
label label 105 105 To-P5 101 101 To-P2
102 102 To-P2 192.168.1.1 192.168.1.2 192.168.1.3
SID: 101 SID: 103 102 102 To-P2
SID: 102
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499 103 - Local

104 104 To-P2

P1 P2 P3 105 105 To-P2

106 106 To-PE2

ILM
CE1 PE1 Association of In- Out- Intf PE2 CE2
SID to prefix label label
advertised by IGP 222 222 To-PE2
192.168.1.11 192.168.2.22
SID: 111 SID: 222
SRGB: 100-499 SRGB: 100-499

P4 P5 Metric: 100
P6
Use case 4

Routing Traffic-engineered 192.168.1.4 192.168.1.5 192.168.1.6 Association of

SID: 104 SID: 105 SID: 106
SRGB: 100-499 SRGB: 100-499 SRGB: 100-499 SID to prefix
SIDs Node, Adjacency
ILM
advertised by IGP
Label Value Absolute In- Out- Intf
label label
All IGP metrics are equal to 10
SRGB Common
222 222 To-P2 unless otherwise indicated
106 106 To-P2

1001 - To-P6

80
 Traffic forwarding
102
105
Swap 102
for 1022 1001 Pop 102
102 222
105 192.168.1.1 1234 192.168.1.2 192.168.1.3
SID: 101 SID: 102 SID: 103
1001 Payload
222
1234 P1 P2 P3
POP 222,
Payload 105 1234

Payload 1001 Payload

222 222
PUSH 1234,
CE1 PE1 222, 1001, 1234 1234 PE2 CE2
222
105, 102 Payload Payload
1234
192.168.1.11 192.168.2.22
SID: 111
Payload SID: 222

P4 Pop 105, P5 Metric: 100

P6 Swap 222
for 222
Use case 4 1001
Routing Traffic-engineered
192.168.1.4 192.168.1.5 192.168.1.6
SIDs Node, Adjacency SID: 104 SID: 105 SID: 106
Label Value Absolute
All IGP metrics are equal to 10
SRGB Common
unless otherwise indicated

81
 • Routing:
– Traffic-engineered

• Segment Identifiers:
Use case 5: – Node-SIDs and Anycast-SIDs
– Allocated as absolute globally-
SR-TE significant MPLS label values

• SRGB:
– Identical SRGB configured on all nodes

82
 Anycast segments
All routers in the anycast set
Anycast-SID allows ECMP- Anycast Group A
advertise the same anycast prefix
192.168.2.1
aware shortest-path forwarding SID: 100 with the same SID value
to the closest node of the
anycast set
A1 A3
192.168.1.11 192.168.1.13
SID: 111 SID: 113
SRGB: 100-499 R1 R3 SRGB: 100-499

A2 A4
PE1 PE3

PE2 PE4
B1 B3

192.168.1.12 192.168.1.14
SID: 112 R2 R4 SID: 114
SRGB: 100-499 SRGB: 100-499

Use case 5 B2 B4
Routing Traffic-engineered

SIDs Node, Anycast Anycast Group B All IGP metrics are equal to 10
192.168.2.2 unless otherwise indicated
Label Value Absolute SID: 200
SRGB Common Identical SRGB on all nodes

83
 Objectives Objectives:

Anycast Group A
192.168.2.1
• All traffic from PE1 to
SID: 100 PE3 should traverse
the top plane
A1 A3
192.168.1.11 192.168.1.13
SID: 111 SID: 113
SRGB: 100-499 R1 R3 SRGB: 100-499

A2 A4
PE1 PE3

PE2 PE4
B1 B3

192.168.1.12 192.168.1.14
SID: 112 R2 R4 SID: 114
SRGB: 100-499 SRGB: 100-499

Use case 5 B2 B4
Routing Traffic-engineered

SIDs Node, Anycast Anycast Group B All IGP metrics are equal to 10
192.168.2.2 unless otherwise indicated
Label Value Absolute SID: 200
SRGB Common Identical SRGB on all nodes

84
 Traffic forwarding
100 113 PE1 forces packets destined
113 Swap
Pop 1234 113 for PE3 to go via Anycast
100 100 113 for
Swap 1234 Payload 113 1234 Group A
113 Swap
100 for Payload 113 for
1234 Payload 113
100 113
Payload A1 A3 1234
192.168.1.11 Payload 192.168.1.13
SID: 111 SID: 113
SRGB: 100-499 R1 R3 SRGB: 100-499

PUSH POP
1234, A2 A4 113,
113, PE1 PE3 1234
100

PE2 PE4
B1 B3

192.168.1.12 192.168.1.14
SID: 112 R2 R4 SID: 114
SRGB: 100-499 SRGB: 100-499

Use case 5 B2 B4
Routing Traffic-engineered

SIDs Node, Anycast Anycast Group B All IGP metrics are equal to 10
192.168.2.2 unless otherwise indicated
Label Value Absolute SID: 200
SRGB Common Identical SRGB on all nodes

85
IPv6 data plane

86
IPv6 data plane
• Requires a new type of Routing Header
• A segment is encoded as an IPv6 address (prefix-SID is the
prefix itself). SRv6 Segment (abbreviated as SRv6-SID) is an
128-bit value
• An ordered list of segments is encoded as an ordered list of IPv6
addresses in the routing header
• The active segment is indicated by the Destination Address (DA)
of the packet. The DA of the packet changes at each segment
completion. The final DA of the packet is encoded as the last
segment of the path
• The next active segment is indicated by a pointer in the new
routing header

87
Segment Routing Header (SRH)
32 bits

next header hdr ext len routing type segments left

last entry flags tag
next header:
- Header immediately
following the SRH
segment list[0] (128 bits IPv6 address)
segments left:
- index of the next
segment to inspect

last entry:
- index of last element of
the segment list

flags:
- P: protected, set when
packet has been
rerouted through an FRR
segment list[n] (128 bits IPv6 address) mechanism
- O: set for OAM packets
- A: alert for presence
of TLV objects
- H: HMAC is present if
optional TLVs set

88
Segment Routing Header (SRH)
• The SRH is added to the packet at its source, either:
– At the node originating the packet (host, server)
– At the ingress mode of an SR domain where the ingress node
receives an IPv6 packet and encapsulates it into an outer IPv6
header followed by a Segment Routing Header
– The source address of the packet is the ingress node
– The destination address is set as the first segment of the path
– The last segment of the path is the egress node of the SR domain

89
Creating the SRH
• The source SR node does the following:

Set SA = address of source SR node/SR-domain ingress node

Set DA = value of the first segment
Set first element of segment list = last segment
Set second element of segment list = penultimate segment
<and so on – segment list is encoded in the reverse order of the path>

Set Segments Left = n-1

where n = number of elements in the Segment List

Set Last Entry field = n-1

where n = number of elements in the Segment List

90
Handling the SRH
• At each segment of the SRH, the following operations take
place:

IF SegmentsLeft > 0 THEN

decrement SL
update the IPv6 DA with SRH[SL]
FIB lookup on updated DA
forward according to the matched entry
ELSE
drop the packet

91
BGP Egress Peer
Engineering
(EPE)

92
BGP Egress Peer Engineering

• Problem statement (RFC7855):

– A centralised controller should be able to instruct an ingress PE

router or a content source within the domain to use a specific egress
PE and a specific interface/neighbor to reach a particular destination

93
SR BGP-EPE
• Segment Routing enables a centralised (SDN) controller to
program any egress peer selection policy at ingress border
routers or at hosts within the domain:
– Solution is called BGP Egress Peer Engineering (BGP-EPE)

– Centralised controller is called the BGP-EPE controller

– Egress border router where the BGP-EPE traffic steering functionality

is implemented is called a BGP-EPE-enabled border router

– The policy programmed at an ingress border router is called a BGP-

EPE policy

94
BGP peering segments
An ingress border router of an
AS can steer a flow along a
selected AS, towards a
BGP Peering Segments
selected egress border router • Segments identifying by a BGP EPE (Egress
of the AS and through a Peer Engineering)-enabled node.
specific peer by using BGP • Enable the expression of source-routed inter-
Egress Peer Engineering domain paths
capabilities

Peer Node Segments Peer Adjacency Segments Peer Set Segments

Local (PeerNode-SID) Local (PeerAdj-SID) Local (PeerSet-SID)
Segment representing a BGP Segment representing an adjacency Segment representing a set of BGP
peering node to a BGP peering node peering nodes

Semantics: Semantics: Semantics:

• SR header operation: NEXT • SR header operation: NEXT • SR header operation: NEXT
• Next-hop: connected peering • Next-hop: peer connected • Next-hop: load-balance across
node to which the segment is through the interface to which the any connected interface to any
related segment is related peer in the related group

95
 • Routing:
– Traffic-engineered

Use case: • Segment Identifiers:

– BGP-Peering segments
BGP-EPE
• SRGB:
– Identical SRGB configured on all
nodes

96
BGP-EPE network
BGP EPE
Controller

Node-
SID: 32 B D G

AS2
L/8
A AS4
AS1 K/8
Node-
SID: 16 Node- C E
SID: 64

AS3 K

97
 BGP-EPE Segments
BGP-LS NLRIs
corresponding to
the BGP-EPE BGP EPE
segments Controller

Node-
SID: 32 B D G

AS2
L/8
A AS4
AS1 K/8
Node-
SID: 16 Node- C E
SID: 64

C’s ILM
AS3 K
In Op Out intf
Label
F
1012 Pop Link to D
1022 Pop Link to E
1032 Pop Upper link to F
Peer Node Segments Peer Adj Segments Peer Set Segments 1042 Pop Lower link to F
BGP Peering D 1012 Upper link to F 1032 E, F 1060 1052 Pop Load balance on any
segments E 1022 Lower link to F 1042 link to F
allocated by PE C
F 1052 1060 Pop Load balance on any
link to E or F

98
 BGP-LS advertisements
BGP-LS NLRIs
corresponding to
the BGP-EPE BGP EPE
segments Controller

Peer Node SID to D

Descriptors:
Node: BGP-router-ID(C), AS1
Peer: BGP-router-ID(D), AS2
Link: IP address of C’s link to D, IP
address of D’s link to C

Attributes: C’s ILM

PeerNode SID: 1012
In Op Out intf
Label
1012 Pop Link to D
1022 Pop Link to E
1032 Pop Upper link to F
Peer Node Segments Peer Adj Segments Peer Set Segments 1042 Pop Lower link to F
BGP Peering D 1012 Upper link to F 1032 E, F 1060 1052 Pop Load balance on any
segments E 1022 Lower link to F 1042 link to F
allocated by PE C
F 1052 1060 Pop Load balance on any
link to E or F

99
SR BGP-EPE input policy

• The BGP-EPE policy can be usually expressed at the

ingress border router via a two-entry segment list where:
– The first elements is the IGP prefix SID of the selected egress border
router AND
– The second element is a BGP Peering SID at the selected egress
border router

• Note that BGP-EPE functionality is only required on the

BGP-EPE-enabled egress border router; the ingress border
router simply needs to support SR-TE

100
 Input policy programming
Input policy configured with SR-TE tunnel
+steering policy via PCE-P/Netconf BGP EPE
Controller

Node-
SID: 32 B D G

AS2
L/8
A AS4
AS1 K/8
Node-
SID: 16 Node- C E
SID: 64

C’s ILM
AS3 K
In Op Out intf
Label
F
1012 Pop Link to D
1022 Pop Link to E
1032 Pop Upper link to F
Example input policy: route all traffic to L/8 via egress border router C’s 1042 Pop Lower link to F
lower link to peer F
1052 Pop Load balance on any
SR-TE tunnel TE1: push {1042, 64} link to F
ip route L/8 next-hop TE1 1060 Pop Load balance on any
link to E or F

101
 Traffic flow
BGP EPE
Controller

PUSH 64 Node-
1042,
SID: 32 B D G
64
1042
Payload
AS2
L/8
A AS4
AS1 K/8
Node-
SID: 16 Node- C E
SID: 64

Pop 64,
AS3 K
1042
Payload F

102
Interworking
with LDP

103
Distributing SR labels in LDP

• A node that has both Segment Routing and LDP capability

and active LDP neighbors is required to:

– create LDP bindings for each Prefix-SID and Node-SID learned in the
SR domain

– Stitch the incoming LDP label to the outgoing SR label

104
Segment Routing Mapping Server (1)
• Segment Routing Mapping Server (SRMS):
– SR-capable router that advertises mappings between prefixes and
labels for prefixes that it does now own itself.
– That is, the SRMS advertises prefix-to-SID mappings on behalf of
non-SR-capable routers.
– Control-plane function only; the SRMS is not in the data path and can
be located anywhere
– Multiple SRMSs can be used for redundancy
– Requires the use of SR IGP extensions

105
Segment Routing Mapping Server (2)

• A node that has both Segment Routing and LDP capability

and active LDP neighbors is required to:

– create LDP bindings for each Prefix-SID and Node-SID learned in the
SR domain

– Stitch the incoming SR label to the outgoing LDP label

106
 • Routing:
– Traffic-engineered

• Segment Identifiers:
Use case: – Node-SIDs
– Allocated as absolute globally-
SR-TE significant MPLS label values

• SRGB:
– Identical SRGB configured on all nodes

107
Mixed-LDP/SR network
SID: 102
SRGB: 100-200

PE2 PE4

SR-only

PE1 P5 P6 P7 P8 PE3 SR & LDP

SID: 101 SID: 105 SID: 106

SRGB: 100-200 SRGB: 100-200 SRGB: 100-200 LDP-only

SR domain LDP domain

Contiguous MPLS tunnels must be built:

Requirement: • from PE1 to PE3
• from PE3 to PE1

108
 LDP to SR direction: label distribution
ILM
SID: 102 In-label Out-Label Intf
SRGB: 100-200
801 701 To-P7

Association of PE2 PE4

SID to prefix
advertised by IGP LDP FECs
advertised

PE1 P5 P6 P7 P8 PE3
SID: 106
SID: 101 SID: 105 SRGB: LDP FECs
SRGB: SRGB: 100-200 advertised
100-200 100-200 SR-only

SR domain LDP domain

SR & LDP

LDP labels
allocated by P7 ILM LDP-only

P7 creates LDP FEC Label In-label Out-Label Intf

bindings for all SR PE1 701 701 101 To-P6
Prefix-SIDs and PE2 702 702 102 To-P6
Node-SIDs
P5 705 705 105 To-P6

P6 706 706 106 To-P6

109
 LDP to SR direction: traffic flow
SID: 102
SRGB: 100-200

PE2 101 PE4

Swap Swap 701
101 for 1234 for 101
Swap 801 PUSH 1234,
Swap 101 for 701 801
101 for Payload
101

POP 101,
1234
PE1 P5 P6 P7 P8 PE3
101 SID: 106 701 801
SID: 101 SID: 105 101 SRGB:
SRGB: 1234 SRGB: 100-200 1234
100-200 100-200 1234 1234 SR-only
Payload Payload Payload Payload
SR domain LDP domain
SR & LDP

LDP-only

110
SR to LDP direction: label distribution
ILM ILM
In-label Out-Label Intf In-label Out-Label Intf
SID: 102
SRGB: 100-200 103 103 To-P7 803 303 To-PE3

Configured as SR
PE2 Mapping Server PE4
(SRMS)

PE1 P5 P6 P7 P8 PE3
SID: 106
SID: 101 SID: 105 SRGB: LDP LDP
SRGB: SRGB: 100-200 FEC: PE3 FEC: PE3
100-200 100-200 SR-only
Label: 803 Label: 303

SR domain LDP domain

SR & LDP

SIDs advertised
by P5 ILM LDP-only

Local policy is FEC Label In-label Out-Label Intf

configured on P5 to P8 108 103 803 To-P8
advertise SIDs for PE3 103
LDP-only nodes
PE4 104

111
 SR to LDP direction: traffic flow
SID: 102
SRGB: 100-200

PE2 103 PE4

Swap Swap 103
103 for 1234 for 803
Swap 803 POP 803,
Swap 103 for 303 1234
103 for Payload
103

PUSH
1234, 103
PE1 P5 P6 P7 P8 PE3
103 SID: 106 803 303
SID: 101 SID: 105 103 SRGB:
SRGB: 1234 SRGB: 100-200 1234
100-200 100-200 1234 1234 SR-only
Payload Payload Payload Payload
SR domain LDP domain
SR & LDP

LDP-only

112
IGP extensions

113
OSPFv2: SR capabilities
• An OSPFv2 router’s SR capabilities are advertised in the Router
Information Opaque LSA (RFC7770)
SR-Algorithm TLV SID/Label Range TLV
Used within the Router Information Opaque Used within the Router Information Opaque
LSA to advertise the supported algorithms LSA to advertise the SRGB
32 bits 32 bits

type length type length

Algorithm 1 Algorithm … Algorithm n range size reserved
Sub-TLVs (variable)
algorithm: range size: size of SRGB
- 0: SPF sub-TLV: SID/Label sub-TLV indicating first
- 1: Strict SPF SID/Label in the range

SID/Label Sub-TLV
Used to advertise the SID or label value
32 bits

type length
SID/Label

114
OSPFv2: Extended Prefix Opaque LSA

Extended Prefix Opaque LSA

used to advertise additional prefix attributes beyond what
is possible with the fixed-format LSAs defined in RFC2328.
Opaque type:
- 7 (OSPFv2 Extended Prefix
Opaque LSA)
LS age Options LS type
opaque type opaque ID LS Type:
Advertising router - 10: area-local scope
LS sequence number - 11: AS-wide scope
LS checksum length
TLV:
TLVs - E.g. OSPF2 Extended Prefix TLV

115
OSPFv2: Extended Prefix TLV

Extended Prefix TLV

• TLV of the OSPF Extended Prefix Opaque LSA
(RFC7684) route type:
• Used to advertise various additional attributes of - 1: intra-area
the prefix - 2: inter-area
- 5: AS-external
32 bits - 7: NSSA-external
type length
AF:
route type Prefix Length AF flags - Address-family: only 1Pv4 unicast
address prefix (variable) is supported
sub-TLVs (variable)
algorithm:
- 0: SPF
- 1: Strict SPF

sub-TLVs:
- E.g. OSPF2 Prefix-SID sub-TLV

116
OSPFv2: Prefix SID sub-TLV

flags:
Prefix-SID sub-TLV - NP: No-PHP
Sub-TLV of the OSPF Extended Prefix TLV (RFC7684) - M: Mapping Server
- E-Flag: Explicit-Null
32 bits - V: if set, SID is an absolute value
- L: set for local significance
type length
flags reserved MT-ID algorithm MT:
SID/Index/Label (variable) - Multi-Topology ID

algorithm:
Flags - 0: SPF
- 1: Strict SPF
NP M E V L

117
OSPFv2: Extended Prefix Range TLV

Extended Prefix Range TLV

• TLV of the OSPF Extended Prefix Opaque LSA
(RFC7684)
• Used to advertise prefixes to SID/Label mappings flags:
as part of Segment Routing Mapping Server - IA: set for inter-area type
(SRMS) function
Range size:
32 bits - Size of advertised range
type length
sub-TLVs:
Prefix Length AF range size - e.g. Prefix-SID sub-TLV signifying
flags reserved start of the SID range
address prefix (variable)
sub-TLVs (variable)

Flags
IA

118
OSPFv2: Extended Link Opaque LSA

Extended Link Opaque LSA

used to advertise additional link attributes beyond what is
possible with the fixed-format LSAs defined in RFC2328.
Opaque type:
32 bits - 8 (OSPFv2 Extended Link Opaque
LS age Options LS type LSA)
opaque type opaque ID
LS Type:
Advertising router - 10: area-local scope
LS sequence number - 11: AS-wide scope
LS checksum length
TLV:
TLVs - E.g. OSPF2 Extended Link TLV

119
OSPFv2: Extended Link TLV

Extended Link TLV

• TLV of the OSPF Extended Link Opaque LSA
(RFC7684)
• Used to advertise various additional attributes of
the link
32 bits

type length link type, link ID, link data:

link type reserved - Identical to LSA type-1 values
link ID
link data sub-TLVs:
sub-TLVs (variable) - E.g. OSPF2 Prefix-SID sub-TLV

120
OSPFv2: Adjacency SID sub-TLV

Adjacency-SID sub-TLV flags:

Sub-TLV of the OSPF Extended Link TLV (RFC7684) - B: Adjacency is eligible for protection
- V: if set, SID is an absolute value
32 bits - L: set for local significance
- G: refers to a group of adjacencies
type length - P: Adj-SID is persistently allocated
flags reserved MT-ID weight
SID/Index/Label (variable) MT:
- Multi-Topology ID

weight:
Flags - used for load-balancing purposes

B V L G P

121
ISIS: SR capabilities
• An ISIS router’s SR capabilities are advertised in the IS-IS Router
Capability TLV-242

SR-Algorithm sub-TLV SR-capabilities sub-TLV

Used to advertise the supported algorithms Used to advertise the SRGB
32 bits 32 bits

type length type length flags

Algorithm 1 Algorithm 2 Algorithm … Algorithm n range
SID/Label Sub-TLV
algorithm: range size: size of SRGB
- 0: SPF sub-TLV: SID/Label sub-TLV indicating first
- 1: Strict SPF SID/Label in the range

SID/Label Sub-TLV
Used to advertise the SID or label value
32 bits
type length
SID/Label

122
IS-IS: Prefix SID sub-TLV

Prefix-SID sub-TLV
• Carries an IGP-Prefix-SID
flags:
• Can be present in TLV-135,235,236,237,Binding- - R: Re-advertisement flag, prefix
TLV has been propagated from another
level
32 bits
- N: set for Node-SID
type length flags algorithm - P: no PHP if set
SID/Index/Label (variable) - E-Flag: Explicit-Null
- V: if set, SID is an absolute value
- L: set for local significance

Flags algorithm:
R N P E V L - 0: SPF
- 1: Strict SPF

• TLV-135 (Extended IPv4 reachability) defined in [RFC5305 ].

• TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120 ].
• TLV-236 (IPv6 IP Reachability) defined in [RFC5308 ].
• TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120 ].

123
IS-IS: SID/Label Binding TLV

Prefix-SID sub-TLV
• Used to advertise prefixes to SID/Label mappings
flags:
as part of Segment Routing Mapping Server - F: if set, IPv6 encap. Else, IPv4
(SRMS) function - M: set for a mirrored context
- S: set to allow flooding across
32 bits
entire domain
type length flags reserved - D: set when TLV is leaked from L2
range to L1
prefix length prefix
- A: attached flag
prefix (continued, variable)
sub-TLVs(variable) range:
- allows advertising a range of
prefixes and their labels
Flags
F M S D A sub-TLVs:
- e.g. Prefix-SID sub-TLV signifying
start of the SID range

124
IS-IS: Adjacency SID sub-TLV

Adjacency-SID sub-TLV
• Carries an IGP-Adj-SID
flags:
• Can be present in TLV-22, 23, 222, 223, 141
- F: if set, IPv6 encap. Else, IPv4
- B: Adjacency is eligible for
32 bits protection
- V: if set, SID is an absolute value
type length flags weight - L: set for local significance
SID/Index/Label (variable) - S: refers to a set of adjacencies
- P: Adj-SID is persistently
allocated
Flags weight:
F B V L S P - used for load-balancing purposes

• TLV-22 (Extended IS reachability)[RFC5305]

• TLV-222 (Multitopology IS)[RFC5120]
• TLV-23 (IS Neighbor Attribute)[RFC5311]
• TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311]
• TLV-141 (inter-AS reachability information)[RFC5316]

125
References

126
References
• RFC7855 - Source Packet Routing in Networking (SPRING) Problem Statement and
Requirements
• draft-ietf-spring-segment-routing-12
• draft-ietf-spring-segment-routing-mpls-10
• draft-ietf-spring-segment-routing-central-epe-06
• draft-ietf-6man-segment-routing-header-06
• draft-ietf-ospf-segment-routing-extensions-17
• draft-ietf-isis-segment-routing-extensions-13
• draft-ietf-spring-segment-routing-ldp-interop-08

127
Thank You !
End of session

Issue Date: [Date]

Revision: [xx]

WSDN01_v0.1