Presentation is loading. Please wait.

Presentation is loading. Please wait.

Segment Routing IETF 87 Clarence Filsfils – 1 C. Filsfils, S. Previdi, A. Bashandy, B. Decraene, S. Litkowski, M. Horneffer, I. Milojevic,

Similar presentations


Presentation on theme: "Segment Routing IETF 87 Clarence Filsfils – 1 C. Filsfils, S. Previdi, A. Bashandy, B. Decraene, S. Litkowski, M. Horneffer, I. Milojevic,"— Presentation transcript:

1 Segment Routing IETF 87 Clarence Filsfils – cf@cisco.com 1 C. Filsfils, S. Previdi, A. Bashandy, B. Decraene, S. Litkowski, M. Horneffer, I. Milojevic, R. Shakir, S. Ytti, W. Henderickx, J. Tantsura, Ericsson, E. Crabbe, H. Gredler, and a few other contributors…

2 Technology Generality of a segment, – Intra and inter domain – Forwarding construct – Service construct – virtualization – Abstract Routing Model (draft-filsfils-rtgwg-segment-routing), see nanog video – SR is not a label-in-IGP solution. Label-in-IGP is a subset of SR ! Agnostic Control Plane Clear instantiation in two dataplanes – MPLS – IPv6 2

3 Productization Wide and rapid industry adoption Committed deployments received from operators within 5 months of first review – MPLS – And IPv6 3

4 The last 9 months Oct: first SR presentation to operators – Lead Operator group formed, see co-authors, weekly meeting since then – Commitment to velocity, transparency and multi-vendor agreement Feb: initial implementation released as per commitment Mar: MPLS WC and IPv6 conference Mar: first draft submitted to IETF-86 – Multi-vendor technology agreement and interoperability plans (cisco, Alcatel and Ericsson) – draft-gredler-... co-authors want more details as draft. We commit to detailed drafts by end of May May – Team shares 6 detailed drafts with draft-gredler-... co-authors and seek merge agreement June – Merge agreement on a subset of SR: MPLS/SR instantiation, use-cases, FRR, ISIS and OSPF: great collaborative work The point: – Detailed and thoughtful work – Velocity – Collaborative – Commitments met 4

5 Next few months - IETF 5 TopicIETF ReferenceWG Abstract Routing Model draft-filsfils-rtgwg-segment-routingRTGWG MPLS Instantiation New draft to be submitted (based on section 5 of draft-filsfils-rtgwg-segment-routing) MPLS IPv6 Instantiation New draft to be submittedIPv6 Use Casesdraft-filsfils-rtgwg-segment-routing-use-casesRTGWG Perf Eng. LSP with SR draft-shakir-rtgwg-sr-performance-engineered-lspsRTGWG ISIS SR Extensions draft-previdi-isis-segment-routing-extensionsISIS OSPF SR Extensions draft-psenak-ospf-segment-routing-extensionsOSPF FRR SRdraft-francois-sr-frrRTGWG PCEP SR Extensions draft-sivabalan-pce-segment-routingPCEP

6 Positive collaboration and consensus 6

7 Progress Agreement between draft-sr and draft-gredler co-authors on a subset of SR: – ISIS, OSPF: merge already submitted – MPLS/SR, FRR and use-case: work in progress Disagreement on IPv6/SR, should not be an issue – We thus accepted to organize the documents such that those that only want to support the MPLS instantiation can do so – We believe that there is a clear demand (e.g. as confirmed by feedback in the room), we are committed to a positive collaboration process – For IPv6, together with operators (Comcast, Rogers…), Martha Steenstrup and academia, we will submit the IPv6/SR draft proposal for the next IETF and will work with the community to improve it as required 7

8 Visually Abstract Routing Model MPLS/SRIPv6/SR ISIS/SR, OSPF/SR Non-SDN use-case SDN use-case FRR SR PCEP SR A valid subset for one deployment to restrict to Significant operator interest for the superset, hence desire to work with the IETF community to standardize the related technology. 8

9 Next IETF While a new WG might be formed, we would like to be able to present and review our proposal in their home WG’s – ISIS – OSPF – MPLS – 6man – PCEP – RTGWG Significant operator support and vendor consensus 9

10 draft-filsfils-rtgwg-segment-routing-use-cases-00 SectionsPresentations today 2. IGP-based MPLS TunnelingMartin, Victor 3. FRRBruno 4.1.1 Disjointness in dual-plane networks Martin 4.1.2. CoS-based Traffic EngineeringMartin 4.4. Deterministic non-ECMP PathRob 5.2. SDN /SR use-caseVictor 6.4. Leveraging SR benefits for LDP- based traffic Bruno 7. OAMRudiger 10 There is a lot of requirements, and SR meets all of them, despite their variety, with few extensions to core protocols. No new protocol is added.

11 Some questions from the BoF intro IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable – Security issued solved: SR is a tunnel+source-route solution, see abstract routing draft and v6 doc How much data plane variety is needed? MPLS? IPv6? IPv4? – MPLS is clear – IPv6 is clear What are the inherent costs in supporting more than one data plane? – IPv6 only requires a new type of an existing extension header – Implementation is leveraging leancore optimizations that have been pervasive in the industry for the last 2 to 3 years What management/control architecture do we want? – Operator presentations are clear: SR supports distributed, hybrid and centralized. Different use-cases select the appropriate model. – Straightforward as SR-CP only requires small extensions to well-established core protocols – Remember that PCE is useful for non-SDN use cases as well…. As defined at the IETF originally. So clearly PCE is in. What does a label represent? – Label-in-IGP is a subset of SR. SR is a wider and more generic solution. 11

12 Some questions from the BoF intro The choice of data planes will be limited to those for which use cases exist – Comcast, and others, are in the room and will comment on their use-case – There is clear IPv6 requirement A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices – This sentence is handcrafted to MPLS – For IPv6, a new type of a routing extension header is required. This is a straightforward DP extension – IPv6 is a clear mandate for the IETF and the IPv6/SR use-cases are clear. The proposed charter – This is overly restricted on a subset of SR (label in IGP). SR is a more generic solution. 12

13 Conclusion Multi-vendor/operator constructive collaboration Many requirements/use-cases supported by small extensions to well-established core protocols – ISIS, OSPF – LFA – PCEP – MPLS – IPv6 Significant industry interest and contribution to SR – The generality of a segment and the abstract routing model is key – The instantiation in IPv6 is key – Routed and hosted applications, service chaining, virtualization Your feedback and contribution are welcome! 13

14 SR documentation http://www.segment-routing.net/ – Conferences – IETF links – … 14

15 Annex 15

16 Abstract Routing Model draft-filsfils-rtgwg-segment-routing-00 16

17 SR Objectives Tackling issues reported by operators for years – IGP-based FRR for any topology – Simpler to operate, more scalable explicit routing Supporting “SDN”-based services – Provide a more responsive and scalable interaction between WAN orchestration, the applications and the network Evolution, no revolution – Must be simple to operate – Must support incremental deployment 17

18 Segment Routing A 32-bit segment can represent any instruction – Service – Context – IGP-based forwarding construct – Locator Ordered list of segments – An ordered chain of topological and service instructions Per-flow state only at ingress SR edge node – Ingress edge node pushes the segment list on the packet 18

19 IGP Segments Prefix Segment – Steers traffic along ECMP-aware shortest-path to the related IGP Prefix – Global segment within the SR IGP domain – Node Segment: a prefix segment allocated to a prefix that identifies a specific node (e.g. the prefix is its loopback) Adjacency Segment – Steers traffic onto an adjacency or a set of adjacencies – Local segment related to a specific SR node SR Global Block – A subset of the Segment space – All the global segments must be allocated from SRGB – Operator manages SRGB like an IP address block: it ensures unique allocation of a global segment within the SR domain 19

20 IGP Prefix Segment Z advertises its global prefix segment 65 with his loopback address Z/32 – simple ISIS sub-TLV extension – simple OSPF Opaque sub-TLV extension All remote nodes install the prefix segment to Z in the SR dataplane along the shortest path to Z/32 IPv4 and IPv6 A packet injected anywhere with active segment 65 will reach Z via ecmp-aware shortest-path A B C N O Z D P 65 draft-previdi-isis-segment-routing-extensions-00 draft-psenak-ospf-segment-routing-extensions-00 20

21 IGP Adjacency Segment C allocates a local segment 9003 for its adjacency CO C advertises the adjacency segment in the IGP – Simple ISIS sub-TLV extension – simple OSPF Opaque sub-TLV extension C is the only node to install the adjacency segment in SR dataplane IPv4 and IPv6 AB C M N O Z D P 9003 A packet injected at node C with active segment 9003 is forced through datalink CO 65 draft-previdi-isis-segment-routing-extensions-00 draft-psenak-ospf-segment-routing-extensions-00 21

22 Combining Segments Source Routing ABCOPZ is expressed as {72, 9003, 65} ABC M N O Z D P 9003 72 65 22

23 Combining Segments Prefix Segment is at the heart of the proposal – ecmp multi-hop shortest-path – in most topologies, any path can be expressed as list of prefix segments ABC M N O Z D P 78 72 65 {72, 78, 65} 23

24 Combining Segments Service Segments can be part of the source route ABC M N O Z D P 78 72 65 {72, 78, 9450, 65} 9450: FW service offered by O 24

25 SR Control-Plane Lightweight extension to ISIS/OSPF IPv4 and IPv6 Agnostic to the dataplane – works with any dataplane that supports the encoding of a list of segments on the packet 25

26 MPLS dataplane The 20 right-most bits of the segment are encoded as a label A list of segments is represented as a stack of labels The active segment is the top label The IGP Prefix segment stays on the top of the stack thanks to a SWAP operation where the ingress and egress label values are the same Transports IPv4 and IPv6 No changes in the operations of the MPLS dataplane SR can co-exist and interwork with other MPLS control- plane protocols (LDP, RSVP) 26

27 IPv6 dataplane (without any MPLS dataplane) All the SR ISIS/OSPF Control Plane is dataplane agnostic and hence applies directly to IPv6 Remaining work: detailing the IPv6 tunneling and new Routing Extension type header – High-level description provided at March IPv6 Conference – Detailed Draft should be available soon We are working on this in close collaboration with Comcast and other SP/Entreprise operators and academia Any contribution is welcome 27

28 Annex 28


Download ppt "Segment Routing IETF 87 Clarence Filsfils – 1 C. Filsfils, S. Previdi, A. Bashandy, B. Decraene, S. Litkowski, M. Horneffer, I. Milojevic,"

Similar presentations


Ads by Google