Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
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. [email protected], "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>.