Segment Routing

Yatish Kumar
CTO - Corsa
 Overlay Underlay Network
1 Core nodes do not run overlay protocols
2 Edge nodes do not hand off underlay connectivity between domains

1
Core

Node
2

Customer Edge
 Provider Edge
 Core
 Core
 Provider Edge


Node Node Node Node Node
 Segment routing Boot Sequence
ISIS or OSPF
1. Who is directly connected to me ?
ISIS or OSPF
1. Who is directly connected to me ?
ISIS or OSPF
1. Who is directly connected to me ?

35

Core

Node
30 31 42 50

Provider Edge
 Core
 Core
 Provider Edge


Node Node Node Node

https://en.wikipedia.org/wiki/Link-state_routing_protocol
 Segment Routing Boot Sequence
ISIS or OSPF ISIS or OSPF
1. Who is directly connected to me ? 1. Who is directly connected to me ?
2. Hey everyone ! Here are my 2. Hey everyone ! Here are my ISIS or OSPF
neighbours neighbours 1. Who is directly connected to me ?
2. Hey everyone ! Here are my
neighbours
35
30 31 35 42 50
30 x 30 31 35 42 50
Core

31 x x 30 x
35 x
Node
31 x x
30 31 42 50
42 x 35 x
50 42 x
50
Provider Edge
 Core
 30 31 35 42 50 Core
 Provider Edge

Node Node 30 x Node Node
31 x x
35 x
42 x
50

https://en.wikipedia.org/wiki/Link-state_routing_protocol
 But… Wait…Rewind to Step 1.
While OSPF was natively built to route IP and is itself a Layer 3 protocol that runs on top of IP,
IS-IS is an OSI Layer 2 protocol.[3] It is at the same layer as Connectionless Network Protocol
(CLNP). The widespread adoption of IP may have contributed to OSPF's popularity. IS-IS does not use IP to carry routing
information messages. OSPF version 2, on the other hand, was designed for IPv4. IS-IS is neutral regarding the type of network
addresses for which it can route. This allowed IS-IS to be easily used to support IPv6. To operate with IPv6 networks, the OSPF
protocol was rewritten in OSPF v3 (as specified in RFC 2740).

ISIS or OSPF
Whilst deciding how to use
1. Who is directly connected to me ?
segment routing, it is important
to keep In mind which protocol
is better suited to the networking
use case.

Core
 Core
 Are links = ethernet cables

Node Node Are links = ethernet circuits
Are links = point to point IP
connections

https://en.wikipedia.org/wiki/IS-IS
 Deconstruction Of Routing
IS-IS is a link-state routing protocol, operating by reliably flooding link state information throughout a network of
routers. Each IS-IS router independently builds a database of the network's topology, aggregating the flooded network
information.

Like the OSPF protocol, IS-IS uses Dijkstra's algorithm for computing the best path through the network.
Packets (datagrams) are then forwarded, based on the computed ideal path, through the network to the
destination.

HOLD IT ! Path selection and Topology Discovery do not have to

be joined at the hip. That just happens to be what we did in the
past.

So ISIS-SR isn’t really about picking a routing stack just yet.

 Deconstruction Of Routing
While OSPF was natively built to route IP and is itself a Layer 3 protocol that runs on top of IP

BGP - LU - Method for distributing labels

BGP - LS - Method for exporting topology
BGP -Prefix Segment in large-scale data centers
draft-ietf-spring-segment-routing-msdc-04. Food for thought on WAN / AS
BPG - EPE https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-03

But … if we only want to do topology distribution over IP.

What about BGP ?

 Ok. Back to our example.
1. We can discover neighbours
2. Each node can compute a topology map

Next step how do we route a packet ?

 Dijkstra Shortest Path Routing
Provide end to end MPLS
connections using inner label
We choose to do for handoff to the overlay
Dijkstra. We aren’t services
forced to.

That Matters 50 50
35
Inner Inner
Core

Node
Inner 30 31 42 50 Inner

50
Provider Edge
 Core
 Core
 Provider Edge

Inner
Node Node Node Node

Perform Hop by Hop Routing using MPLS outer labels.

Segment routing in a nutshell
Packet Loosely Steered
Using
PCE or Policy at the edge
35
35 50 50
50 Inner 35 Inner 50
Inner Inner
Core

Node
Inner 30 31 42 50

Provider Edge
 Core
 Core
 Provider Edge


Node Node Node Node
 Edge Steering
2035
2035 9002
2050
9002 2050
Inner
2050 Inner 35 2050
1 Inner
Inner
Core
 2
Node
Inner 30 31 42 50

Provider Edge
 Core
 Core
 Provider Edge


Node Node Node Node
Summary of Label Based Instructions
• Fully routed default behaviour …. Minimal label stack. Resilience

• Loosely routed behaviour …..…. Easy to express policy. Resilience

• Selected edge behaviour ……… ECMP equivalent. Preferred path

• Quickly adapting to most 2nd order routing concepts.

• e.g. support for anycast.

 Summary
• Segment routing is true L3 MPLS. Including topology discovery and route selection.

• Segment routing eliminates state from the network and puts it in the packet. ( No LSP tables )

• Segment routing provides incremental control over traffic steering. Excellent for traffic engineering and
centralized path computation. Only the edge nodes need to be integrated with the PCE engine.

• Segment routing binds well to IP signalling and legacy MPLS LSRs. Incremental upgrades to a network
like LHCONE are possible. Both eBGP/multi-domain and IGP related.

• Segment routing supports multiple paths through the network. Excellent for maximizing network utilization.

• IETF is porting almost all routing concepts in order to grow, and enhance migration to segment routing.

• Segment routing separates the control and data plane. Very few simple “label based instructions” for
generalized steering capability. Many possible control / signalling planes ( IP / ISIS / BGP / SDN ) can be
attached.
 Good Reading
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-04

Good Slides
https://www.nanog.org/sites/default/files/meetings/NANOG64/1030/20150603_Slabakov_Source_Routing_2_0__v1.pdf
 Good Reading - BGP Implications
References
12.2. Informative References

12.1. Normative References

[I-D.ietf-6man-segment-routing-header]
[I-D.ietf-spring-segment-routing-central-epe]

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev,

Requirement Levels", BCP 14, RFC 2119,

J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
"Segment Routing Centralized BGP Peer Engineering", draft-

DOI 10.17487/RFC2119, March 1997,

"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
ietf-spring-segment-routing-central-epe-03 (work in

<http://www.rfc-editor.org/info/rfc2119>.
segment-routing-header-02 (work in progress), September
progress), November 2016.

2016.

[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in

[I-D.ietf-spring-segment-routing-msdc]

BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,

[I-D.ietf-idr-bgp-ls-segment-routing-ext]
Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P.

<http://www.rfc-editor.org/info/rfc3107>.
Previdi, S., Psenak, P., Filsfils, C., Gredler, H., Chen,
Lapukhov, "BGP-Prefix Segment in large-scale data

M., and j. jefftant@gmail.com, "BGP Link-State extensions

centers", draft-ietf-spring-segment-routing-msdc-02 (work

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
for Segment Routing", draft-ietf-idr-bgp-ls-segment-
in progress), October 2016.

Border Gateway Protocol 4 (BGP-4)", RFC 4271,

routing-ext-00 (work in progress), November 2016.

DOI 10.17487/RFC4271, January 2006,

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,

<http://www.rfc-editor.org/info/rfc4271>.
[I-D.ietf-idr-bgpls-segment-routing-epe]
"Multiprotocol Extensions for BGP-4", RFC 4760,

Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J.,
DOI 10.17487/RFC4760, January 2007,

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private

and M. Chen, "Segment Routing BGP Egress Peer Engineering
<http://www.rfc-editor.org/info/rfc4760>.

Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February

BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing-

2006, <http://www.rfc-editor.org/info/rfc4364>.
epe-06 (work in progress), November 2016.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and

S. Ray, "North-Bound Distribution of Link-State and

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
[I-D.ietf-ospf-segment-routing-extensions]
Traffic Engineering (TE) Information Using BGP", RFC 7752,

Patel, "Revised Error Handling for BGP UPDATE Messages",

Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
DOI 10.17487/RFC7752, March 2016,

RFC 7606, DOI 10.17487/RFC7606, August 2015,

Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
<http://www.rfc-editor.org/info/rfc7752>.

<http://www.rfc-editor.org/info/rfc7606>.
Extensions for Segment Routing", draft-ietf-ospf-segment-

routing-extensions-10 (work in progress), October 2016.

[I-D.ietf-spring-segment-routing]

Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,

and R. Shakir, "Segment Routing Architecture", draft-ietf-

spring-segment-routing-10 (work in progress), November

2016.