Segment RoutingYatish Kumar CTO - Corsa

Overlay Underlay Network

CoreNode

CoreNode

CoreNode

Provider EdgeNode

Provider EdgeNode

Customer EdgeNode

Core nodes do not run overlay protocols Edge nodes do not hand off underlay connectivity between domains

1

2

1

2

Segment routing Boot Sequence

31

35

42

CoreNode

CoreNode

CoreNode

Provider EdgeNode

50

Provider EdgeNode

30

ISIS or OSPF 1. Who is directly connected to me ?

https://en.wikipedia.org/wiki/Link-state_routing_protocol

ISIS or OSPF 1. Who is directly connected to me ?

ISIS or OSPF 1. Who is directly connected to me ?

Segment Routing Boot Sequence

31

35

42

CoreNode

CoreNode

CoreNode

Provider EdgeNode

50

Provider EdgeNode

30

ISIS or OSPF 1. Who is directly connected to me ? 2. Hey everyone ! Here are my

neighbours

https://en.wikipedia.org/wiki/Link-state_routing_protocol

ISIS or OSPF 1. Who is directly connected to me ? 2. Hey everyone ! Here are my

neighbours ISIS or OSPF 1. Who is directly connected to me ? 2. Hey everyone ! Here are my

neighbours

30 31 35 42 5030 x31 x x35 x42 x50

30 31 35 42 5030 x31 x x35 x42 x50

30 31 35 42 5030 x31 x x35 x42 x50

But… Wait…Rewind to Step 1.

CoreNode

CoreNode

ISIS or OSPF 1. Who is directly connected to me ?

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).

https://en.wikipedia.org/wiki/IS-IS

Whilst deciding how to use segment routing, it is important to keep In mind which protocol

is better suited to the networking use case.

Are links = ethernet cables Are links = ethernet circuits Are links = point to point IP

connections

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

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

What about BGP ?

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

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

31

35

42

CoreNode

CoreNode

CoreNode

Provider EdgeNode

50

Provider EdgeNode

30

Provide end to end MPLS connections using inner label

for handoff to the overlay services

Perform Hop by Hop Routing using MPLS outer labels.

Inner

Inner50

Inner50

Inner

Inner50

We choose to do Dijkstra. We aren’t

forced to.

That Matters

Segment routing in a nutshell

31

35

42

CoreNode

CoreNode

CoreNode

Provider EdgeNode

50

Provider EdgeNode

30Inner

Inner5035

Inner50

Inner50

Packet Loosely Steered Using

PCE or Policy at the edge

Inner5035

Edge Steering

31

35

42

CoreNode

CoreNode

CoreNode

Provider EdgeNode

50

Provider EdgeNode

30Inner

Inner2050

Inner20501

2Inner2050

20359002

Inner2050

20359002

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 Readinghttps://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 ImplicationsReferences

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, <http://www.rfc-editor.org/info/rfc3107>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.

12.2. Informative References

[I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- segment-routing-header-02 (work in progress), September 2016.

[I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Psenak, P., Filsfils, C., Gredler, H., Chen, M., and j. jefftant@gmail.com, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment- routing-ext-00 (work in progress), November 2016.

[I-D.ietf-idr-bgpls-segment-routing-epe] Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., and M. Chen, "Segment Routing BGP Egress Peer Engineering BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing- epe-06 (work in progress), November 2016.

[I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 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.

[I-D.ietf-spring-segment-routing-central-epe] Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Peer Engineering", draft- ietf-spring-segment-routing-central-epe-03 (work in progress), November 2016.

[I-D.ietf-spring-segment-routing-msdc] Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. Lapukhov, "BGP-Prefix Segment in large-scale data centers", draft-ietf-spring-segment-routing-msdc-02 (work in progress), October 2016.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.