Segment Routing

A tutorial
•  Paresh Khatri
•  DD-02-2016

1 © Nokia 2016 Public

Agenda

1.  Introduction
2.  Use cases and applicability
3.  Deployment options
4.  IGP extensions for segment routing (if time permits)

2 © Nokia 2016 Public

introduction

3 © Nokia 2016 Public

MPLS: a historical perspective (1)

•  Two main protocols: LDP or RSVP-TE

-  LDP for scale and simplicity – extensions
for fast re-route (loop-free alternates
[LFAs])
-  RSVP-TE for TE and FRR for some time •  Issues:
-  TE solutions don’t scale when we
•  To scale MPLS we enabled:
want more granularity/dynamicity,
-  LDPoRSVP RLFA too complex (dynamic T-LDP
-  Seamless MPLS: LBL-BGP with LDP signaling)

•  Traffic engineering: RSVP-TE based

•  Services through:
-  BGP/IGP shortcuts, PW (T-LDP/BGP),
VPLS (LDP/BGP), VPRN (BGP), MVPN
(BGP/mLDP/P2MP RSVP)

4 © Nokia 2016 Public

MPLS: a historical perspective (2)
LDP RSVP-TE
Overview Multipoint to point Point to point
Operation Simple LSP per destination/TE-
path
Dependencies Relies on IGP Relies on IGP TE

LBL allocation Local significant per Local significant per

node (interface) node (interface)

Traffic Engineering No Yes

Scaling 1 LBL per node Nx(N-1)

(interface)
Fast Reroute LFA, LFA Policies, Link/Node protection
RLFA - <100% (detour/facility) – 100%
coverage coverage

Multicast mLDP P2MP RSVP

IPv6 Extensions required Extensions required

5 © Nokia 2016 Public

What problem are we trying to solve ?

SCALE RSVP-TE

•  Increasing network growth with traffic •  Pros:

engineering (TE) requirement -  Source Routed protocol ; iLER has full
•  RSVP-TE is the only widely-spread control to setup LSP to destination
solution to provide TE -  Presence of strong FRR and TE capabilities
•  No LDP TE present •  Cons:
•  LDP Fast ReRoute (FRR) can be used in -  Soft-state ; refresh mechanism required :
some parts of the network but is topology refresh reduction (RFC2961) ; aggregates
messages but not # soft-states
dependent
-  Mid-point state presence in network (when
FRR) ; consumes CPU cycles and memory
6 © Nokia 2016 Public
Objective of Segment Routing

The primary objective for Segment Routing (SR) is

source routing: the ability for a node to specify a unicast
forwarding path, other than the normal shortest path,
that a particular packet will traverse.

7 © Nokia 2016 Public

IETF SPRING working group

•  SPRING (Source Packet Routing in Networking) Working Group addresses the following:

-  IGP-based MPLS tunnels without the addition of any other signaling protocol
•  The ability to tunnel services (VPN, VPLS, VPWS) from ingress PE to egress PE with or without
an explicit path, and without requiring forwarding plane or control plane state in intermediate
nodes.

-  Fast Reroute
•  Any topology, pre-computation and setup of backup path without any additional signaling.
•  Support of shared-risk constraints, support of link/node protection, support of micro-loop
avoidance.

8 © Nokia 2016 Public

IETF SPRING working group

•  SPRING (Source Packet Routing in Networking) Working Group addresses the following:

-  Traffic Engineering
•  The soft-state nature of RSVP-TE exposes it to scaling issues; particularly in the context of SDN
where traffic differentiation may be done at a finer granularity.
•  Should include loose/strict options, distributed and centralised models, disjointness, ECMP-
awareness, limited (preferably zero) per-service state on midpoint and tail-end routers.

-  All of this should allow incremental and selective deployment with minimal disruption

9 © Nokia 2016 Public

Introduction to Segment Routing

•  Segment Routing provides a tunneling mechanism that enables source routing.

•  Paths are encoded as sequences of topological sub-paths called segments, which are
advertised by link-state routing protocols (IS-IS and OSPF).

Segment Segment Segment Segment

Segment Segment Segment
R1 R2 R3 R4

Segment Segment

Segment
R5 R6

Segment Segment

10 © Nokia 2016 Public

Encoding Segment Routing tunnels

•  A Segment Routing (SR) tunnel, containing a single segment or a segment list, is

encoded as:
-  A single MPLS label or an ordered list of hops represented by a stack of MPLS labels (no change to
the MPLS data-plane).
-  A single IPv6 address, or an ordered list of hops represented by a number of IPv6 addresses in the
IPv6 Extension header (Segment Routing Header).
•  The segment list can represent either a topological path (node, link) or a service.
1001

The segments can be thought as a set of instructions from 1007

the ingress PE such as “go to node D using the shortest 1003
path”, “go to node D using link/node/explicit-route L” 1001
Packet

11 © Nokia 2016
Operations on segments

•  Three distinct operations:

-  PUSH: the insertion of a segment at the head of the Segment list.

-  NEXT: the active segment is completed; the next segment becomes active.

-  CONTINUE: the active segment is not completed and hence remains active.

12 © Nokia 2016 Public

Segment routing with MPLS data plane (1)

•  MPLS instantiation of Segment Routing aligns with the MPLS architecture defined in RFC
3031
•  For each segment, IGP advertises an identifier referred to as a Segment ID (SID). A SID
is a 32-bit entity; with the MPLS label being encoded as the 20 right-most bits of the
segment

13 © Nokia 2016
Segment routing with MPLS data plane (2)

•  When Segment Routing is instantiated over the MPLS data-plane, the following actions
apply :
-  A list of segments is represented as a stack of labels
-  The active segment is the top label
-  The CONTINUE operation is implemented as a SWAP operation
-  The NEXT operation is implemented as a POP operation
-  The PUSH operation is implemented as a PUSH operation

14 © Nokia 2016
Types of segments

Prefix Segment Adjacency Segment BGP Prefix Segment BGP Peer Segment
•  Globally unique – •  Locally unique – each •  Example Prefix Segment •  EPE ; Egress Peering
allocated from SRGB SR router in the in DC environment Engineering
domain can use the •  DC GW representation
•  Typically multi-hop •  Influence how to control
same space traffic to adjacent AS
•  ECMP-aware shortest- •  Signaled by BGP (in DC)
path IGP route to a •  Typically single-hop •  Signaled by BGP-LS (w/
related prefix •  Signaled by IGP EPE controller)
•  Indexing or absolute
SID
DC CORE/
•  Signaled by IGP
WAN
AS2
CORE/
WAN
AS1 CORE/
WAN
AS3
15 © Nokia 2016 Public
Segment identifiers – prefix segments

•  Prefix Segment (Prefix-SID)

-  Globally unique within the IGP/SR domain – allocated from the SR Global Block (SRGB)*
-  Represents the ECMP-aware shortest-path IGP route to the related prefix
-  Typically a multi-hop path
-  Includes “P” flag to allow neighbours to perform the “NEXT” (pop) operation whilst processing the
segment (analogous to Penultimate Hop Popping in MPLS).
-  Two options exist; Indexing or Absolute-SID (described in later slides)

* In an MPLS architecture, SRGB is the set of local labels reserved for global segments.

16 © Nokia 2016 Public

Segment identifiers – node segments

•  Node Segment ID (Node-SID)

-  A special prefix segment used to identify a specific router (loopback/system address).
-  Identified by “N” flag being set in advertised segment (Prefix-SID Sub-TLV).
-  Represents the ECMP-aware shortest-path IGP route to the specified node.

17 © Nokia 2016 Public

Segment identifiers – anycast segments

•  Anycast Segment ID (Anycast-SID)

-  A prefix segment specifying a set of routers
-  Represents the ECMP-aware shortest-path IGP route to the closest node of the “anycast set”.
-  Potentially useful for coarse traffic engineering (i.e. route via plane A of dual-plane network, route
via Region B of multi-region network) or node redundancy (i.e. traffic re-routes to shortest path
towards any other router that is part of the “anycast set”).

18 © Nokia 2016 Public

Example: SR tunnel with prefix-SID (node-SID)

•  PE2 advertises Node Segment into IGP (Prefix-SID Sub-TLV Extension to IS-IS/OSPF)
•  All routers in SR domain install the node segment to PE2 in the MPLS data-plane.
-  No RSVP and/or LDP control plane required.
-  When applied to MPLS, a Segment is essentially an LSP.
PHP based on p-bit setting of
Prefix-SID advertised by PE2

SWAP SWAP
FEC PE2 800 to 800 800 to 800 POP 800
PUSH 800
Node-SID 100 Node-SID 200 Node-SID 300 Node-SID 400

PE1 P1 P2 P3 PE2

Node-SID
800

19 © Nokia 2016 Public

Example: SR tunnel with prefix-SID (node-SID)

•  For traffic from PE1 to PE2, PE1 pushes on node segment {800} and uses shortest IGP
path to reach PE2.
•  Active segment is the top of the stack for MPLS:
-  P1 and P2 implement CONTINUE (swap) action in MPLS data-plane
-  P3 implements NEXT (pop) action (based on P-bit in Prefix-SID not PHP based on p-bit setting
being set). of Prefix-SID advertised by
SWAP SWAP PE2
FEC PE2
800 to 800 800 to 800 POP 800
PUSH 800
Node-SID 100 Node-SID 200 Node-SID 300 Node-SID 400

PE1 P1 P2 P3 PE2
800 800 800 Packet
Packet Node-SID
Packet Packet
800

•  No state held in network with the exception of segment list for tunnel held at PE1.

20 © Nokia 2016 Public

Prefix segment identifiers – absolute SIDs

•  The use of absolute SID values requires a single consistent SRGB on all SR routers
throughout the IGP domain.
•  Example: Node-SID Node-SID
200 300
-  PE2 advertises MP-BGP label
910 for VPN prefix Z. Node-SID
P1 P2
Node-SID
-  To forward traffic to VPN prefix 100
MP-BGP
600
Z, and again assuming Label 910
preferred (non-ECMP) path A CE1 PE1 PE2 CE2 Z
from PE1 to PE2 is PE1-P3-P4- Packet

PE2, PE1 pushes label 910

P3 P4
onto bottom of stack, and label 600 600
600 (Node-SID for PE2) on top 910 Node-SID 600 Node-SID 910
of stack. Packet 400 910 500 Packet

-  Label (SID) does not change Packet

hop by hop.
21 © Nokia 2016 Public
Prefix SID indexing

•  Why ?
-  SR domain can be multi-vendor w/ possibility that each vendor uses a different MPLS label range
-  Prefix SID must be globally unique within SR domain

•  How ?
-  Indexing mechanism is required for prefix SIDs. All routers within the SR domain are expected to
configure and advertise the same prefix SID index range for a given IGP instance.
-  The label value used by each router to represent a prefix ‘Z’ (= label programmed in ILM) can be
local to that router by the use of an offset label, referred to as a start label :
Local Label (for Prefix SID) = (local) start-label + {Prefix SID index}

22 © Nokia 2016 Public

Example: Prefix SID indexing

•  For example, assume the SRGB is {1000, 1999}, and the SID Index Range is {1,100}.
•  Each SR router in the domain defines a start point in the SRGB (start-label), and an offset
label called an SID index.
Node-SID 200 Node-SID 300
-  SR routers sum {start-label + SID Start-Label 1050 Start-Label 1040
index} to obtain a local label for a
Prefix SID. P1 P2
Node-SID 100 Node-SID 600
-  Assuming PE2 advertises Start-Label 1060 MP-BGP Start-Label 1010
Label 910
loopback 192.0.2.2/32 with a prefix
A CE1 PE1 PE2 CE2 Z
index of 2:
-  PE2’s SID is {1010+2}= 1012
Packet
1032

910 P3 P4
-  P4’s SID is {1020+2}= 1022 Packet

Node-SID 400 Node-SID 500

-  P3’s SID is {1030+2}=1032 etc. Start-Label 1030 Start-Label 1020
-  PE2 advertises MP-BGP label 910 1022 1012

for VPN prefix Z. 910 910

Packet Packet

23 © Nokia 2016 Public

Segment identifiers – adjacency segments

•  Adjacency Segment ID (Adj-SID)

-  A segment identifying an adjacency or set of adjacencies that must be in the IGP.
-  Segment Identifier (SID) is local to the router that advertises it (every SR router in the domain can
use the same segment space).
-  If:
•  AB is the Node-SID of node N, and...
•  ABC is an Adj-SID at node N to an adjacency over link L, then....
•  A packet with segment list {AB, ABC} will be forwarded along the shortest-path to node N, then switched by N
towards link L without any consideration of shortest-path routing.
-  If the Adj-SID identifies a set of adjacencies, node N can load-balance the traffic over the members
of that set.

24 © Nokia 2016 Public

Segment identifiers – adjacency segments

•  All SR routers advertise Adjacency segment(s) into IGP (Adjacency-SID Sub-

TLV Extension to IS-IS/OSPF).
•  Adjacency segments may be of local or global significance, but only the
advertising SR router installs the adjacency segment into the MPLS data-
plane
-  From a data-path perspective, it is analogous to a label-swap to implicit-null.
•  Provides for end-to-end source-routing capability where the Adjacency
segments may determine the explicit hop-by-hop path through the network.
•  Beware however, label stack depth has implications on hardware.

25 © Nokia 2016 Public

Example: SR tunnel with adjacency segments
POP 1001
1007 POP 1007
1003 1003

1001 1001

1001 Packet Packet

1007 Node-SID 200 Node-SID 300 Node-SID 400

1003 Adj-SID 1001
1001
1001 P1 P2 P3
Packet 1007 Adj-SID
1007
1003
PE1 PE2

Node-SID 1001 Node-SID 800

100
P4 P5 P6 Adj-SID 1001
Adj-SID 1003

Node-SID 600 Node-SID 700

Node-SID 500
POP 1003 POP 1001
1001 Packet

Packet
26 © Nokia 2016 Public
Example: SR tunnel with node and adjacency segments

•  A combination of node and adjacency segments is also possible.

•  This provides the ability to exercise ECMP paths to the next specified node segment, but
enforce the use of a particular link (or links) from that node.

27 © Nokia 2016 Public

Example: SR tunnel with node and adjacency segments

300

1003 POP {300, 1003}

•  In this example, PE1 800 800
wants to traverse the link Packet Packet

P2-P5 on the way to PE2, 300

Node-SID 200 Node-SID 300 Node-SID 400
as it is under-utilised. 1003

800 300 P1 P2 P3
•  PE1 therefore imposes Packet 300 Adj-SID 1003
the segment list {300, 800
1003, 800} representing PE1 PE2
the the Node-SID for P2, Node-SID 800 Node-
the Adj-SID for link P2- 100
P6
SID 800
P4 P5
P5, and finally the Node-
Node-SID 700
SID for PE2. Node-SID 500 Node-SID 600
SWAP 800 POP 800
800 Packet

Packet
28 © Nokia 2016 Public
Comparison with LDP and RSVP-TE
LDP RSVP-TE SR
Overview Multipoint to point Point to point Multipoint to point
Operation Simple LSP per destination/TE- Simple
path
Dependencies Relies on IGP Relies on IGP TE Relies on IGP + offline TE

LBL allocation Local significant per Local significant per Global

node (interface) node (interface)

Traffic Engineering No Yes yes

Scaling 1 LBL per node Nx(N-1) 1 LBL per node/ local

(interface) interface
Fast Reroute LFA, LFA Policies, Link/Node protection LFA, LFA Policies, RLFA/DLFA
RLFA - <100% (detour/facility) – 100% - can get to 100% coverage
coverage coverage (better than LDP with RLFA)

Multicast mLDP P2MP RSVP TBD

IPv6 Extensions required Extensions required Native

29 © Nokia 2016 Public

use cases and
applicability

30 © Nokia 2016 Public

Use case 1: Shortest path routing (1)

•  All nodes advertise a unique node segment into the IGP.

•  For traffic from PE1 to PE2,
PE1 pushes on segment list SWAP 800 SWAP 800 POP 800
{800} and uses shortest IGP Node-SID 200 Node-SID 300 Node-SID 400
800 800
path to reach PE2 (PE1-P1- 800
800 P1 P2 P3
P2-P3-PE2)
Packet
-  P1 and P2 install ILM
CONTINUE entry {label=800,
PE1
NHLFE=label 800, Next- PE2
Hop=shortest path to PE2}
Node-SID Node-SID
-  P3 installs ILM CONTINUE 100
P6 800
or NEXT entry {label=800, P4 P5
POP, Next-Hop=shortest Node-SID 700
Node-SID 500 Node-SID 600
path to PE2}

31 © Nokia 2016 Public

Use case 1: Shortest path routing (2)

•  If PE1 has ECMP=>2, and

equal-cost paths to the SR SWAP 800 SWAP 800 POP 800
tunnel tail-end exist, all Node-SID 200 Node-SID 300 Node-SID 400
800 800
equal-cost paths can be 800
800 P1 P2 P3
exercised:
Packet
-  Based on hash output, flows
m routed PE1-P1-P2-P3-PE2
PE1
with segment list {800} PE2
ECMP
-  Based on hash output, flows Node-SID Node-SID
n routed PE1-P4-P5-P6-PE2 100
P6 800
with segment list {800} 800 P4 P5
800 Node-SID 600 800 Node-SID 700
Node-SID 500

32 © Nokia 2016 Public

Use case 2: Source-routing with node-SID
SWAP 300-300
300
POP 300
600 600

•  Adj-SID provides the capability to 800

Packet
800

Packet
explicit-route on a hop-by-hop 300 P1 Node-SID 300 Node-SID 400
basis, but has the potential to 600

create a deep label stack-depth if 800 300 P1 P2 P3

all hops are explicitly listed. Packet 300
600
•  Assume we have a requirement
PE1 PE2
to engineer traffic away from the
P2-P3 link (due to high utilisation Node-SID Node-SID
100 800
or link degradation) to some P4 P5 P6
other under-utilised link(s). 800 Node-SID 700
Node-SID 500 Node-SID 600
Packet
800
•  Traffic from PE2 to PE1 can be re-routed away from this link using Packet POP
segment list {300, 600, 800} constructed purely from Node-SIDs.
POP 600
•  Alternative option if link utilisation permits is simply {600, 800}.
33 © Nokia 2016 Public
Use case 3: Disjointness (1)

•  Disjointness describes two (or more) services that must be completely disjoint of each
other. They should not share common network infrastructure – i.e. if one fails, the other
must always be active.
•  Many networks employ the ‘dual-plane’ design, where inter-plane links are configured
such that the route to a destination stays on that plane during a single failure scenario.
•  Disjointness can broadly be achieved using Anycast segments.

34 © Nokia 2016 Public

Use case 3: Disjointness (2)

•  Assume service 1 between PE1 and PE3 must be disjoint from service 2 between PE2
and PE4: Red Plane
Anycast SID 902
-  Service 1 at PE1 has
Node-SID
segment list {902, 300}
P5 P6 300
including Anycast SID 902
and traverses the red plane Node-SID
100 PE3
before reaching PE3. P1 P2
Service 1
PE1
-  Service 2 at PE2 has PE4
segment list {901, 400} P7 P8
including Anycast SID 901 Node-SID
Service 2 PE2
and traverses the blue plane P3 400
P4
before reaching PE4. Node-SID
200
Blue Plane
Anycast SID 901

35 © Nokia 2016 Public

Use case 4: Egress peer engineering (EPE) (1)

EPE Controller

•  Egress Peer Engineering defines

three BGP Peering SIDs, that allow
for programming of source-routed R7
BGP-LS
inter-domain paths; PeerNodeSID, AS 200
FlowSpec
PeerAdjSID, and PeerSetSID.
EBGP R8
•  R1 is an EPE-enabled egress router R2 AS 100 R1
and allocates the following:
-  PeerNode segment for each of its Node-SID EBG
R9 AS 300
mult P
defined peers (R7, R8, and R9) 100 ihop

-  PeerAdj segment for each recursive

interface to a multi-hop peer (R9)
-  PeerSet segment to a set of peers (R7
and R8) (AS300)
36 © Nokia 2016
Use case 4: Egress peer engineering (EPE) (2)

•  BGP-LS session established EPE Controller

between EPE-enabled border router

(R1) and the EPE controller:
R7
-  R1 advertises PeerNode, PeerAdj, and BGP-LS AS 200
FlowSpec
PeerSet SIDs using SR extensions to
EBGP R8
BGP-LS, and programmes FIB AS 100 R1
R2
accordingly.
EB
•  EPE Controller programmes source- Node-
SID 100
mult GP
ihop
R9 AS 300

routes from ingress routers to EBGP

peers using FlowSpec/OpenFlow;
i.e.
-  80% traffic to AS 300 with segment list {100, 1005} Incoming Label Operation Outgoing Interface
1001 POP Link to R7

-  20% traffic to AS 200 with segment list {100, 1006} 1002 POP Link to R8
1003 POP Upper link to R9
-  Prefix <NLRI/Length> segment list {100, 1003} 1004 POP Lower link to R9

-  Prefix <NLRI/Length> segment list {100, 1004} 1005 POP Load-balance on any link to R9
1006 POP Load-balance on any link to R7 or R8

37 © Nokia 2016
Use case 5: Adjacency segment load-balancing (1)

•  In this example, two adjacencies exist between P1-P2.

•  Assuming capacity-based metrics are in use, the 10G link between P1 and P2 is
unused for shortest path forwarding.

SWAP 800-800 No load-balancing

800 800 POP 800 on P1-P2 links
Packet Packet Packet

10G
PE1 P1 P2 PE2
40G
800 Node-SID Node-SID
Node-SID Node-SID
300 800
100 200 800

38 © Nokia 2016
Use case 5: Adjacency segment load-balancing (2)

•  Adj-SID TLV provides the capability to load-balance across multiple adjacencies.

-  P1 advertises individual 200 Weighted load-balancing on P1-P2 links

Adj-SIDs for the 10G link 1003 POP 200, 1003
(1001) with weight 1, and 800 800 POP 800 PE1
40G link (1002) with weight Packet Packet Packet
4.
-  P1 also advertises an Adj- 10G
PE1 P1 P2 PE2
SID for the adjacency set 40G

(1003) 800 Node-SID 200 Node-SID 300 Node-SID 800

800
-  PE1 pushes segment list
{200, 1003, 800}. Node-SID
200 gets the traffic to P1, Link Adj-SID Adj-Set Weight
while Adj-SID 1003 load- 10G 1001 1003 1
balances the traffic to P2 on
40G 1002 1003 4
a weighted 4:1 basis.
39 © Nokia 2016
Both 1003 - -
Use case 6: Distributed cspf-based traffic engineering (1)

•  Traffic Engineering information made available to CSPF for RSVP-TE based LSPs
can also be made available to SR tunnels
-  Includes available link bandwidth, admin-groups, shared-risk link groups (SRLGs) etc.
•  In the example topology,
Node-SID 100 Node-SID 200 Node-SID 300 Node-SID 800
assume that link P1-P2 is in
SRLG 1
SRLG 1. PE1 P1 P2 PE2
-  The SRLG information is
flooded into IS-IS (RFC 4874)
or OSPF (RFC 4203).

P3 P4

Node-SID 500 Node-SID 600

40 © Nokia 2016
Use case 6: Distributed cspf-based traffic engineering (2)

•  If PE1 computes a CSPF to PE2

for a path that should avoid
SRLG 1, it first prunes the links Node-SID 100 Node-SID 200 Node-SID 300 Node-SID 800

signalled as belonging to that SRLG 1

P2 PE2
PE1 P1
SRLG (i.e. link P1-P2) from the
topology.
•  From the remaining topology, it
computes a path – in this simple
case, the path PE1-P1-P3-P4-P2-
PE2. P3 P4
•  PE1 therefore imposes the Node-SID 600
Node-SID 500
segment list {200, 500, 600, 300,
800}, or even {500, 600, 800}.
41 © Nokia 2016
Use case 7: Seamless MPLS and segment routing (1)
End-to-end scaling integrating SR/LDP/RSVP-TE
•  SR can be seen as alternative for LDP and RSVP-TE. This means that the same scaling
requirements will remain in case of an E2E MPLS coverage in a multi-area/instance
domain.
•  Seamless MPLS could be used to cross area or AS boundary, similar to what is available
today with LDP and/or RSVP-TE. This approach has some clear advantages:
-  Smooth migration with existing MPLS domains
-  BGP is a field-proven scalable protocol
-  Non-SR nodes can still connect to a SR MPLS domain

42 © Nokia 2016 Public

Use case 7: Seamless MPLS and segment routing (2)
End-to-end scaling integrating SR/LDP/RSVP-TE

BGP in the Core,

advertising BGP
BGP peering, LBL routes Regions/area can still
advertising BGP (RFC3107) with RR run LDP/RSVP, which
LBL routes allows for smooth
(RFC3107) migration… SR in the
future
RR

BGP BGP BGP BGP

PE1 ABR1 ABR3 PE3
Aggregation-1 Core Aggregation-2
Access-1 Access-2
Segment Routing Segment Segment Routing
RSVP/LDP RSVP/LDP
Routing
PE2 ABR1 ABR4 PE4
BGP BGP BGP BGP

43 © Nokia 2016 Public

Use case 8: Service creation with a path computation element (PCE)
Co-routed service node provisioning
PCE OSS/BSS

Step 1 OSS provisions diverse services on

PE’s
1
2 a.  Type of service: VPWS
b.  Local attachment circuits (SAPs)
c.  Tunnel endpoints: Remote and
Local
d.  Tunnel type: Segment Routing,
RSVP
P5 P6 e.  Path constraints: Bandwidth, Co-
Step 2 routed
a.  PE makesservice diversity, bi- request
path computation
PE3 directionality
P1 P2 (PCReq), or path computation
status report (PCRpt) to the PCE
PE1 server
b.  Note: Requires further extension to
PE4 PCEP to signal path diversity with
P7 P8 other services.
PE2
P3 P4
44 © Nokia 2016
Use case 8: Service creation with a path computation element (PCE)
(cont.)
Co-routed service node provisioning
PCE OSS/BSS

1 Step 3 a.  PCE computes and downloads the

3 2 paths for the tunnel set.
b.  PE’s bind service to paths

P5 P6 Step 4 a.  PCE monitors LSP stats and re-

optimises tunnels as required,
downloading new paths to PE
P1 PE3
P2 routers (same PLSP-ID)
PE1 b.  PE performs make-before-break
and moves to the new path.
PE4
P7 P8
PE2
P3 P4
45 © Nokia 2016
Use case 9: Service creation with a path computation element (PCE)
Global bandwidth optimisation
Flow Mapper PCE OSS/BSS
Step 1 OSS provisions parallel infrastructure
tunnels between a pair of PE nodes
a.  Type of service: VPRN, VPLS
1 VPWS
2 b.  Local attachment circuits (SAPs)
c.  Tunnel endpoints: Remote and
Local
d.  Tunnel type: Segment Routing,
RSVP
e.  Path constraints: min/max
P5 P6 Step 2 bandwidth,
a.  PE diversity,
makes path admin-group
computation request
(PCReq), or path computation
P1 PE3 status report (PCRpt) to the PCE
P2
server with path diversity constraints
PE1 among the parallel set of tunnels.
b.  This may use the SVEC object of
PE4
P7 P8 PCEP (per RFC 5440) to perform a
set of dependent path computation
PE2 requests.
P3 P4
46 © Nokia 2016
Use case 9: Service creation with a path computation element (PCE)
Global bandwidth optimisation
Flow Mapper PCE OSS/BSS

Step 3 a.  PCE computes and downloads the

path.
4 1 b.  PE node informs the external flow
3 2
mapper of the set of LSP-ID values
created between endpoints.

Step 4 a.  External flow mapper pushes down

the mapping of flow/prefix/
destination to the set of parallel
P5 P6 tunnels using OpenFlow or XMPP.
b.  PE instantiates the ACLs to map
PE3 each flow to the designated LSP-ID.
P1 P2
PE1 Step 5 a.  External flow mapper pushes down
the mapping of flow/prefix/
PE4 destination to the set of parallel
P7 P8 tunnels using OpenFlow or XMPP.
b.  PE instantiates the ACLs to map
PE2 each flow to the designated LSP-ID.
P3 P4
47 © Nokia 2016
deployment options

48 © Nokia 2016 Public

Deployment options

Two broad categories

•  Greenfields: •  Existing networks:
-  Relatively straightforward -  Similar to greenfields with added
-  Requires “new” software with segment considerations:
routing capabilities •  Ability to introduce without disruption to existing
services
-  Opportunity to bypass LDP or RSVP-TE
•  Co-existence with LDP and/or RSVP-TE where
altogether
deployed; “ships in the night” operation required
-  Care needs to be taken to ensure that all •  Option to only build new services with segment
service types, resiliency mechanisms and routed tunnels, leaving existing services on
traffic-engineering capabilities can be existing tunnels
supported over segment routed tunnels •  Migration to an SR-only network

49 © Nokia 2016 Public

Segment routing and LDP inter-operability

•  If an MPLS Control Plane Client (i.e. LDP, RSVP, BGP, SR) installs forwarding entries into
the MPLS data-plane, those entries need to be unique in order to function as “Ships in the
Night”.
•  It’s also likely that these control planes can and will co-exist. For example, LDP and SR
could co-exist, where:
-  LDP and SR are present on all routers in the network.
Preference for LDP or SR for service tunnels is a local
matter at the head-end. SR can also be used to
enhance FRR coverage.
-  SR is only present in parts of the network. LDP and SR
can be interworked to provide an end-to-end tunnel
and/or an FRR tunnel due to the presence of an SR
Mapping Server (SRMS).

50 © Nokia 2016 Public

Segment routing and LDP inter-operability
Scenario 1: Ships-in-the-night co-existence
•  Co-existence of LDP-based and SR-based services in the same network

•  Requirements:
-  Service 1 to be tunneled MP-BGP
Label 910
via LDP PE1 PE3 LDP-only
R router
-  Service 1 to be tunneled Service 1 SR-
via SR Node-SID
R only
Node-SID
101 P1 P2 P3 103
router

-  Penultimate Hop R LDP+SR

router
Popping (PHP) to be Service 2 Node-SID
102 Service
used for both services PE2 PE4
Node-SID 202 MP-BGP Node-SID 204
Label 860

51 © Nokia 2016 Public

Segment routing and LDP inter-operability
Scenario 1: Ships-in-the-night co-existence (cont.)

•  Outcome: MP-BGP
Label 910
-  Service 1 is tunneled
from PE1 to PE3 through 423

a continuous LDP LSP 910

700 819 910
910
traversing P1, P2 and P3. PE1 Packet
910 Packet
PE3 LDP-only
Packet Packet R router
-  Service 2 is tunneled Service 1 SR-
from PE2 to PE4 through Node-SID
R only
Node-SID
a continuous SR node 101 P1 P2 P3 103
router
LDP+SR
R
segment traversing P1, Service 2 Node-SID
router

102
P2 and P3. Service

PE2 204 204

PE4
204 860 860 860

Node-SID 202 860 Packet Packet Packet Node-SID 204

Packet

MP-BGP
Label 860
52 © Nokia 2016 Public
Segment routing and LDP inter-operability
Scenario 1: Ships-in-the-night co-existence (cont.)
•  Possible to have multiple entries in
MP-BGP
the MPLS data plane for the same Label 910
prefix.
423 Loopback:
700 819 910 192.0.2.203/32
910
910 910 Packet
PE1 Packet
Packet
PE3 R LDP-only
Node P1’s MPLS forwarding table Packet router

Service 1 SR-
FEC Incomin Outgoing Next-
g Label Label Hop
R only
Node-SID Node-SID
101 P1 P2 P3 103
router
192.0.2.203/32 (LDP) 423 700 P2 LDP+SR
R router
192.0.2.203/32 (SR) 204 204 4
Service 2 Node-SID
102 Service

PE2 204 204

PE4
204 860 860 860

Node-SID 202 860 Packet Packet Packet Node-SID 204

Packet

MP-BGP
Label 860
53 © Nokia 2016 Public
Segment routing and LDP inter-operability
Scenario 2: Migration from LDP to SR
•  Stage 1:
-  All routers initially run only LDP. All
services are tunneled from the ingress
PE to the egress PEs over a continuous
LDP LSP.
PE1 PE3

P5 P6 P7

PE2 R LDP-only
router
PE4
SR-
R only
router
LDP+SR
R router

Service

54 © Nokia 2016 Public

Segment routing and LDP inter-operability
Scenario 2: Migration from LDP to SR (cont.)
•  Stage 2:
-  All the routers are upgraded to SR. They
are configured with the SRGB range
[100, 300]. PE1, PE2, PE3, PE4, P5, P6 Node-SID 101 Node-SID 103
and P7 are configured with the node
segments 101, 102, 103, 104, 105, 106 PE1 PE3
Node-SID
and 107, respectively . 106

-  Service traffic is still tunneled over LDP Node-SID

P5 P6 P7 Node-SID
105 107
LSPs. For example, PE1 has an SR
node segment to PE3 and an LDP LSP
to PE3 but the LDP IP2MPLS PE2 R LDP-only
PE4
router
encapsulation is preferred, by default or
by via configuration. Node-SID 102
R
SR-
only
Node-SID 104
router
LDP+SR
R router

Service

55 © Nokia 2016 Public

Segment routing and LDP inter-operability
Scenario 2: Migration from LDP to SR (cont.)
•  Stage 3:
-  Local policy at PE1 is configured to
prefer SR encapsulation over LDP.
Node-SID 103
-  The service from PE1 to any other PE is Node-SID 101

now riding over SR. All other service PE1 PE3

traffic is still transported over LDP LSPs. Node-SID
106

Node-SID Node-SID
105 P5 P6 P7 107

PE2 R LDP-only
router
PE4
Node-SID 102 SR- Node-SID 104
R only
router
LDP+SR
R router

Service

56 © Nokia 2016 Public

Segment routing and LDP inter-operability
Scenario 2: Migration from LDP to SR (cont.)
•  Stage 4:
-  Gradually, all edge routers are configured
to prefer SR over LDP encapsulation.
Node-SID 103
-  All the service traffic is now transported Node-SID 101

over SR. PE1 PE3

-  LDP is still operational and services Node-SID
106
could be reverted to LDP should there be
Node-SID Node-SID
any issues. 105 P5 P6 P7 107

PE2 R LDP-only
router
PE4
Node-SID 102 SR- Node-SID 104
R only
router
LDP+SR
R router

Service

57 © Nokia 2016 Public

Segment routing and LDP inter-operability
Scenario 2: Migration from LDP to SR (cont.)
•  Stage 5:
-  After a period of smooth operation, LDP
can be de-configured from all routers.
Node-SID 103
-  All routers now solely run SR Node-SID 101

PE1 PE3
Node-SID
106

Node-SID Node-SID
105 P5 P6 P7 107

PE2 R LDP-only
router
PE4
Node-SID 102 SR- Node-SID 104
R only
router
LDP+SR
R router

Service

58 © Nokia 2016 Public

Segment routing and LDP inter-operability
Scenario 3: Mix of SR-only and LDP-only routers (SR and LDP inter-
working)
•  One or more SRMS are used to advertise Node-SIDs on behalf of non-SR routers.
For example, R4 advertises Node-SIDs 201, and 202, respectively for the LDP-only
routers A, and B.
Swap Node-SID
-  A forwards to R1 using Swap LDP FEC B
to Node-SID 202 202 to LDP FEC
conventional LDP. R1 does not B
have a LDP label binding for its Node-SID 102 Node-SID 103
Node-SID 101
next-hop R2, but does have an SR
Node-SID, so it swaps its local A R1 R2 R3 B
LDP-label for FEC B to Node-SID
LDP binding to Mapping Server
202 and forwards to R2. B Next-Hop=R1 (SRMS)
-  R3 knows that B is not SR-capable R4 R5 Node Node Segment
(as B did not advertise SR R LDP-only
A 201
router Node-SID 104 Node-SID 105
capability in ISIS/OSPF), so R3 B 202
swaps Node-SID 202 for LDP FEC R
SR-
only
B. router
LDP+SR
R router

59 © Nokia 2016 Public Service

Segment routing and LDP inter-working
Scenario 4: Using SR to provide LDP fast reroute LDP
FEC
Incoming
Label
Outgoing
Label
Outgoing
Next-Hop
Advertised Advertised
B R1
•  A similar methodology to by R2 by R1

LDP-SR interworking can be C

Advertised
by R2
Advertised
by R3
R3
A
used to provide FRR
coverage:
Node-SID 101 Node-SID 102 Node-SID 103
-  Potential for increased LDP-only
coverage where SR is present B R1 10 R2 10 R3 C R router

only in parts of the network. 10 R

SR-
only
10 1
-  Full coverage if SR is present 0
router
LDP+SR
R
on all routers in the network R4 10 R5 10 R6 30 R7 router

(in which case no Mapping Service 1

(A-B)
Server is required). Node-SID 104 Node-SID 105 Node-SID 106 Node-SID 107 Service 2
(A-B)
Mapping Server
(SRMS)

Node Node Segment

A 201
B 202

60 © Nokia 2016 Public C 203

Segment routing and LDP inter-working
Scenario 4: Using SR to provide LDP fast reroute (cont.)
LDP
FEC
Incoming
Label
Outgoing
Label
Outgoing
Next-Hop
Advertised Advertised
B R1
by R2 by R1
•  In the example shown, LDP is used
Advertised Advertised
throughout the network, and SR has only C
by R2 by R3
R3
A
partial coverage (routers R1-R7).
-  R4 is SRMS and advertises Node-SID 102 Node-SID 103
Node-SID 101
Node-SID 201, 202, 203 LDP-only
B R1 10 R2 10 R3 C R
respectively for the LDP-only router

routers A, B, and C. 10 R
SR-
only
10 1
-  Router A has services to B 0
router
LDP+SR
R
and C. LDP is the preferred R4 10 R5 10 R6 30 R7 router

transport protocol and is used Service 1

(A-B)
by the head-end, router A Node-SID 104 Node-SID 105 Node-SID 106 Node-SID 107 Service 2
(A-B)
(local decision). Mapping Server
(SRMS)
-  Objective is to protect link R2-
Node Node Segment
R1 for service A, and link R2-
A 201
R3 for service B.
B 202

61 © Nokia 2016 Public C 203

Segment routing and LDP inter-working
Scenario 4: Using SR to provide LDP fast reroute (cont.)
Backup
•  Protecting service 1 Dest.
Incoming
Label
Outgoing Label
Outgoing
Next-Hop
Outgoing
Backup Outgoing
Next-Hop
Label
-  Objective is to protect link R2- Advertised by Advertised by 202
Repair tunnel:
B R1 Node-SID R4
R1 with an LFA for B (Service R2 R1 (B N-SID)
Next-Hop R5
1).
Node Node Segment
-  Routers R1-R7 advertise A 201
Node-SID and Adjacency- A
B 202
SIDs for its IGP adjacencies. C 203
R4 is acting as Mapping Node-SID 101 Node-SID 102 Node-SID 103
Server for A, B, and C. LDP-only
B R1 10 R2 10 R3 C R router
-  In steady-state, LDP is used
SR-
as the preferred transport 10 R only
10 1 router
tunnel for Service 1 (A-R2- 0
R LDP+SR
R6 R7 router
R1-B). R4 10 R5 10 30
Service 1
(A-B)
Node-SID 104 Node-SID 105 Node-SID 106 Node-SID 107 Service 2
(A-B)

62 © Nokia 2016 Public

Segment routing and LDP inter-working
Scenario 4: Using SR to provide LDP fast reroute (cont.)
Backup
•  Protecting service 1 (cont.) Dest.
Incoming
Label
Outgoing Label
Outgoing
Next-Hop
Outgoing
Backup Outgoing
Next-Hop
Label
-  Upon failure of link R2-R1, R2 Advertised by Advertised by 202
Repair tunnel:
B R1 Node-SID R4
swaps the incoming top (LDP) R2 R1 (B N-SID)
Next-Hop R5
label with the Node-SID for B
(202). R2 then sends the Node Node Segment
A 201
packet into a repair tunnel to A
B 202
R4.
C 203
•  R2 forwards the label stack Node-SID 101 Node-SID 102 Node-SID 103
{104, 202} to R5.
LDP-only
B R1 10 R2 10 R3 C R router
•  R5 pops Node-SID 104 (PHP)
Packet 104
and forwards the packet to R4. 10 R
SR-
202 only
10 1
•  R4 swaps label 202 for 202 router
0 Packet
and forwards to R1. R1’s Next- 202 R7 R LDP+SR
router
R4 10 R5 R6 30
Hop to B is not SR-capable, so Packet
10
Service 1
R1 swaps 202 for the LDP (A-B)
label announced by it’s Next- Node-SID 104 Node-SID 105 Node-SID 106 Node-SID 107 Service 2
(A-B)
Hop (in this case, implicit-null). 202

63 © Nokia 2016 Public

Packet
Segment routing and LDP inter-working
Scenario 4: Using SR to provide LDP fast reroute (cont.)
Backup
Incoming Outgoing Outgoing Backup Outgoing
•  Protecting service 2 Dest.
Label Label Next-Hop
Outgoing
Label
Next-Hop

-  Objective is to protect link R2- Advertised Advertised 203

Repair tunnel to
C R3 R6: {106, 1009}
R3 with an LFA for C (Service by R2 by R3 (C N-SID)
Next-Hop R5
2).
Node Node Segment
-  In steady-state, LDP is used A A 201
as the preferred transport B 202
tunnel for Service 2 (A-R2- C 203
Node-SID 101 Node-SID 102 Node-SID 103
R3-C).
B R1 10 R2 10 R3 C LDP-only
R router

10
10 1 SR-
R only
0 router
Node-SID R6 R7
R4 10 R5 10 30 R LDP+SR
104 router

Service 1
Node-SID 105 Node-SID 106 Node-SID 107 (A-B)
Service 2
(A-B)

64 © Nokia 2016 Public

Segment routing and LDP inter-working
Scenario 4: Using SR to provide LDP fast reroute (cont.)
Backup
Incoming Outgoing Outgoing Backup Outgoing
•  Protecting service 2 (cont.) Dest.
Label Label Next-Hop
Outgoing
Label
Next-Hop

-  Upon failure of link R2-R3, R2 swaps the Advertised Advertised 203

Repair tunnel to
C R3 R6: {106, 1009}
incoming top (LDP) label with the Node-SID by R2 by R3 (C N-SID)
Next-Hop R5
for C (203). R2 then sends the packet into a
repair tunnel to R6 with Node-SID 106 A
Node Node Segment
A 201
followed by Adj-SID 1009.
B 202
•  R2 forwards the label stack
C 203
{106, 1009, 203} to R5. Node-SID 101 Node-SID 102 Node-SID 103

•  R5 pops 106 (PHP) and B R1 10106 R2 10 R3 C LDP-only

forwards the packet to R6. 1009 R router

•  R6 pops Adj-SID 1009 and 203 Packet

10
10 1 SR-
R
forwards the packet to R7. Packet
0
only
router
Node-SID 203
•  R7 swaps 203 for 203 and R4 10 R5 R6 30 R7 LDP+SR
104 10 Packet R router
forwards to R3.
Service 1
•  R3’s Next-Hop to C is not SR-capable, so R3 Node-SID 105 Node-SID 106 Node-SID 107 (A-B)

swaps 203 for the LDP label announced by it’s 1009

203
Service 2
(A-B)
Next-Hop (in this case, implicit-null). 203
Packet
65 © Nokia 2016 Public Packet
igp extensions for
segment routing

66 © Nokia 2016 Public

Router information
Segment routing capability
•  IS-IS and OSPF both have “Router Information” extensions to advertise optional
capabilities:
-  Opaque “Router Information” LSA in OSPF (RFC 4970) carrying Router Informational Capability
TLV.
-  Capability TLV (TLV-242) in IS-IS (RFC 4971) with optional Sub-TLVs.
•  Intended to indicate capabilities such as Graceful Restart, TE, OSPF stub, IS-IS mesh
group, etc.
•  Flooding scope:
-  IS-IS: across domain, and may be leaked between levels (indicated by “S” flag).
-  OSPF: link-scoped (type 9), area-scoped (type 10), or AS-scoped (type 11).

67 © Nokia 2016 Public

Router information
Segment routing capability
•  Extended to indicate support for IS-IS SR-Capabilities Sub-TLV
Segment Routing: I flag: IPv4 capable
I V V flag: IPv6 capable
-  SR-Capabilities Sub-TLV (IS-IS) or
SID/Label Range TLV (OSPF)
•  Used to indicate label range and start Type Length Flags Range
number. Range (cont.) SID/Label Sub-TLV (variable)
-  SR-Algorithm Sub-TLV used to
advertise algorithms used for path OSPF SID/Label Range TLV
calculation (SPF, CSPF etc).
Type Length
•  Currently only SPF (value 0) defined.
Range Size Reserved
Sub-TLVs (variable)

(Carries a SID/Label Sub-TLV to represent first

SID/Label from the advertised range).

68 © Nokia 2016 Public

IS-IS extensions RNPE VL

Prefix-SID sub-TLV
Type Length Flags Algorithm
•  Introduction of Prefix-SID SUB- SID/Index/Label (variable)
TLV, which may be present in
either: Flag Meaning
-  TLV-135 (IPv4), TLV-235 (MT-IPv4) Re-advertisement flag. If set, the prefix to which this Prefix-SID is
R-flag attached has been propagated by the router either from another
-  TLV-236 (IPv6), TLV-237 (MT-IPv6) level (L2 to L1 or vice-versa) or from redistribution.

•  SID/Index/Label contains either: Node-SID flag. If set, the Prefix-SID refers to the router identified
by the prefix (router loopback/system address). The prefix to
N-flag
-  A 32-bit index defining the offset in which the SID is attached must have a prefix length of /32 (IPv4)
or /128 (IPv6)
the SID/Label space advertised by
No-PHP flag. If set, the penultimate hop must not pop the Prefix-
this router P-flag
SID before delivering the packet to the advertising router.

-  A 24-bit label, where the 20 Explicit-Null flag. If set, any upstream neighbour of the Prefix-SID
E-flag originator must replace the Prefix-SID with a Prefix-SID having
rightmost bits are used for an Explicit-Null value before forwarding the packet.
encoding the label value Value flag. If set, the Prefix-SID carries an absolute value
V-flag
-  A variable length SID (i.e. An IPv6 (instead of an index)

address SID) L-flag

Local flag. If set, the value/index carried by the Prefix-SID has
local significance.

69 © Nokia 2016 Public

IS-IS extensions FBVL S
Adjacency-SID sub-TLV
Type Length Flags Weight
•  May be present in one of the IS-Neighbour
SID/Index/Label (variable)
TLVs.
•  Weight field is used for the purpose of load- Flag Meaning
balancing across a number of adjacencies. Address-Family flag. If unset the Adj-SID refers to an adjacency
with IPv4 encapsulation. If set, the Adj-SID refers to an
F-flag
•  Multiple Adj-SIDs can be allocated to a adjacency with IPv6 encapsulation.

single Adjacency, or the same Adj-SID can Backup flag. If set, the Adj-SID refers to an adjacency that is
being protected (using Fast Reroute techniques). This allows a
B-flag
be allocated to multiple adjacencies. head-end SR router to select only links that are protected
throughout the domain if the SLA for the SR tunnel dictates this.
-  Used for load-balancing
V-flag Value flag. If set, the Adj=SID carries a value (default is set).
•  SID/Index/Label contains either:
-  A 32-bit index defining the offset in the SID/ L-flag
Local flag. If set, the value/index carried by the Prefix-SID has
local significance.
Label space advertised by this router
Set Flag. When set, indicates that the Adj-SID refers to a set of
-  A 24-bit label, where the 20 rightmost bits are S-flag adjacencies (and therefore may be assigned to other
adjacencies as well).
used for encoding the label value
-  A variable length SID (i.e. An IPv6 address SID)
70 © Nokia 2016 Public
IS-IS extensions
FM
SID/label binding TLV
•  May be originated by any router in Type Length Flags Weight

an SR domain to advertise a SID/ Range Prefix Length FEC Prefix

Label to FEC binding along with a FEC Prefix (continued, variable)
‘next-hop style’ anchor. Sub-TLVs (variable)
-  Allows to advertise bindings from
external protocols.
Flag Meaning
-  Can support more than one ‘next-hop’
Address-Family flag. If unset the Prefix FEC carries an IPv4
anchor to create a path description F-flag
prefix. If set, the Prefix FEC carries an IPv6 prefix.
analogous to an RSVP Explicit-Route Mirror Context flag. Set if the advertised SID/path corresponds to
Object (ERO). M-flag
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

71 © Nokia 2016 Public

IS-IS extensions
FM
SID/label binding TLV (cont.)
•  Sub-TLVs field may contain: Type Length Flags Weight

-  SID/Label sub-TLV containing a SID/ Range Prefix Length FEC Prefix

MPLS label. FEC Prefix (continued, variable)
-  ERO Metric sub-TLV used to compare Sub-TLVs (variable)
the cost of a given source/destination
path.
-  IPv4 or IPv6 ERO sub-TLV and Flag Meaning

backup ERO sub-TLV, containing a list Weight

Represents the weight of the path for the purpose of load-
balancing.
of strict or loose hops from source to
Provides a compression scheme allowing a router to advertise a
destination for primary and backup Range contiguous set of prefixes and their corresponding contiguous
paths. SID/label block.

-  Unnumbered Interface ID ERO sub- Prefix

Length
Contains the length of the prefix in bits.

TLV, containing interface index +

The FEC at the tail-end of the advertised path. The FEC Prefix
router-Id to disambiguate from other FEC does not need to correspond to a routable prefix of the
unnumbered interfaces. Prefix originating node.

72 © Nokia 2016 Public

OSPF extensions
Extended prefix opaque LSA OSPF Extended Prefix Opaque LSA
LS Age Options
•  Introduction of new Extended Prefix Opaque Type (7) Instance
Opaque LSA defined to advertise Advertising Router
additional prefix attributes. LS Sequence Number
-  Format of TLVs within the body of the LSA is LS Checksum Length
the same format as used by TE-Extensions
to OSPF. TLVs (variable)

-  Extended Prefix TLV used to advertise

additional attributes associated with the
prefix.
OSPF Extended Prefix TLV
Field Description
Type Length
Route Type 0=unspecified, 1=intra-area, 2=inter-area, 5=external, 7=NSSA
external Route Type Prefix Length AF Reserved
Prefix Length Address Prefix (variable)
Length of the prefix

AF 0=IPv4 unicast Sub-TLVs (variable)

Address Prefix Prefix encoded as an even multiple of 32-bit words

73 © Nokia 2016 Public

OSPF extensions N P ME V L

Prefix-SID sub-TLV Type Length

Flags Reserved MT-ID Algorithm
•  The Prefix SID Sub-TLV is a Sub-TLV of the Range Size Reserved
OSPF Extended Prefix TLV. SID/Index/Label (variable)
•  Support for Multi-Topology with MT-ID field. Flag Meaning

•  Algorithm specifies algorithm the Prefix-SID Node-SID flag. If set, the Prefix-SID refers to the router identified
by the prefix (router loopback/system address). The prefix to
is associated with: N-flag
which the SID is attached must have a prefix length of /32 (IPv4)
or /128 (IPv6)
•  May also be carried in SR-Algorithm TLV of No-PHP flag. If set, the penultimate hop must not pop the Prefix-
P-flag
Router Information Opaque LSA. SID before delivering the packet to the advertising router.

•  Currently only IGP-based SPF defined M-flag

Mapping Server Flag. If set, the SID is advertised from the
Segment Routing Mapping Server.
(value 0).
Explicit-Null flag. If set, any upstream neighbour of the Prefix-SID
E-flag originator must replace the Prefix-SID with a Prefix-SID having
an Explicit-Null value before forwarding the packet.

Value flag. If set, the Prefix-SID carries an absolute value

V-flag
(instead of an index)

Local flag. If set, the value/index carried by the Prefix-SID has

L-flag
local significance.

74 © Nokia 2016 Public

OSPF extensions N P ME V L

Prefix-SID sub-TLV (cont.) Type Length

Flags Reserved MT-ID Algorithm
•  Range allows for distribution of a contiguous Range Size Reserved
prefix block and corresponding contiguous SID/Index/Label (variable)
SID/label block. Range size >1 represents
Flag Meaning
the number of addresses mapped into a
Node-SID flag. If set, the Prefix-SID refers to the router identified
Prefix-SID N-flag
by the prefix (router loopback/system address). The prefix to
which the SID is attached must have a prefix length of /32 (IPv4)
•  SID/Index/Label value contains either: or /128 (IPv6)

No-PHP flag. If set, the penultimate hop must not pop the Prefix-
–  A 32-bit index defining the offset in the SID/ P-flag
SID before delivering the packet to the advertising router.
Label space advertised by this router
Mapping Server Flag. If set, the SID is advertised from the
M-flag
–  A 24-bit label, where the 20 rightmost bits Segment Routing Mapping Server.

are used for encoding the label value Explicit-Null flag. If set, any upstream neighbour of the Prefix-SID
E-flag originator must replace the Prefix-SID with a Prefix-SID having
an Explicit-Null value before forwarding the packet.

Value flag. If set, the Prefix-SID carries an absolute value

V-flag
(instead of an index)

Local flag. If set, the value/index carried by the Prefix-SID has

L-flag
local significance.

75 © Nokia 2016 Public

OSPF extensions
SID/label binding sub-TLV M

•  The SID/Label binding Sub-TLV is a Type Length

Sub-TLV of the OSPF Extended Flags Reserved MT-ID Weight
Prefix LSA. Range Size Reserved
Sub-TLVs (variable)
•  It may be originated by any router in
an SR domain to advertise a SID/
Label to FEC binding along with at Flag Meaning
least one ‘next-hop style’ anchor. Mirror Context flag. Set if the advertised SID/path corresponds to
M-flag
a mirrored context.
-  Allows to advertise bindings from
external protocols
-  Can support more than one ‘next-hop’
anchor to create a path description
analogous to an RSVP ERO.

76 © Nokia 2016 Public

OSPF extensions
SID/label binding sub-TLV (cont.) M

•  Sub-TLVs field may contain: Type Length

-  SID/Label sub-TLV containing a SID/ Flags Reserved MT-ID Weight

Range Size Reserved
MPLS label.
Sub-TLVs (variable)
-  ERO Metric sub-TLV used to compare
the cost of a given source/destination
path.
Flag Meaning
-  IPv4 or IPv6 ERO sub-TLV and
MT-ID Support of Multi-Topology OSPF
backup ERO sub-TLV, containing a list
of strict or loose hops from source to Represents the weight of the path for the purpose of load-
Weight
destination for primary and backup balancing.

paths. Provides a compression scheme allowing a router to advertise a

Range contiguous set of prefixes and their corresponding contiguous
-  Unnumbered Interface ID ERO sub- Size SID/label block. Value >1 represents the number of addresses
mapped to the Prefix-SID
TLV, containing interface index +
router-Id to disambiguate from other
unnumbered interfaces.
77 © Nokia 2016 Public
OSPF extensions OSPF Extended Link Opaque LSA
Extended link opaque LSA LS Age Options
Opaque Type (8) Instance
•  New Opaque LSA defined to advertise
Advertising Router
additional link attributes.
LS Sequence Number
•  Format of TLVs within the body of the LSA is LS Checksum Length
the same format as used by TE-Extensions
to OSPF. TLVs (variable)

-  Extended Link TLV used to advertise additional

attributes associated with the prefix (one for
each Extended Link Opaque LSA).
OSPF Extended Link TLV
Field Description Type Length
1=Point-to-Point connection to another router,
Link Type
2=Connection to a transit network, 3=Connection to a sub
Link Type Reserved
network, 4=Virtual link Link ID
Link ID
1=Point-to-Point connection to another router, Link Data
2=Connection to a transit network, 3=Connection to a sub
network, 4=Virtual link
Sub-TLVs (variable)
Value depends on link’s type field. See RFC 2328 Section
Link Data
A.4.2

78 © Nokia 2016 Public

OSPF extensions BVL S

Adjacency-SID sub-TLV Type Length

Flags Reserved MT-ID Weight
•  Adj-SID is an optional Sub-TLV of the Extended Link TLV
SID/Index/Label (variable)
and may appear multiple times in the Extended Link TLV.
•  Support for Multi-Topology with MT-ID field.
•  Weight field is used for the purpose of load-balancing
Flag Meaning
across a number of adjacencies.
Backup flag. If set, the Adj-SID refers to an
•  Multiple Adj-SIDs can be allocated to a single Adjacency, adjacency that is being protected (using Fast
Reroute techniques). This allows a head-end SR
or the same Adj-SID can be allocated to multiple B-flag
router to select only links that are protected
adjacencies. throughout the domain if the SLA for the SR tunnel
dictates this.
-  Used for load-balancing
Value flag. If set, the Adj=SID carries an absolute
•  SID/Index/Label contains either: V-flag
value (default is set).
-  A 32-bit index defining the offset in the SID/Label space Local flag. If set, the value/index carried by the
advertised by this router L-flag
Prefix-SID has local significance. If not set, the
value/index carried by this sub-TLV has global
-  A 24-bit label, where the 20 rightmost bits are used for encoding significance
the label value
Set Flag. When set, indicates that the Adj-SID refers
S-flag to a set of adjacencies (and therefore may be
assigned to other adjacencies as well).

79 © Nokia 2016 Public