Segment Routing IETF 87 Clarence Filsfils cfcisco com

Segment Routing IETF 87 Clarence Filsfils – cf@cisco. com 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… 1

Technology • Generality of a segment, – – – Intra and inter domain Forwarding construct Service construct virtualization Abstract Routing Model (draft-fils-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 – IPv 6 2

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

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 IPv 6 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

Next few months - IETF Topic IETF Reference WG Abstract Routing Model draft-fils-rtgwg-segment-routing RTGWG MPLS Instantiation New draft to be submitted (based on section 5 of draft-fils-rtgwg-segment-routing) MPLS IPv 6 Instantiation New draft to be submitted IPv 6 Use Cases draft-fils-rtgwg-segment-routing-use-cases RTGWG Perf Eng. LSP with SR draft-shakir-rtgwg-sr-performance-engineered-lsps RTGWG ISIS SR Extensions draft-previdi-isis-segment-routing-extensions ISIS OSPF SR Extensions draft-psenak-ospf-segment-routing-extensions OSPF FRR SR draft-francois-sr-frr RTGWG PCEP SR Extensions draft-sivabalan-pce-segment-routing PCEP 5

• Positive collaboration and consensus 6

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 IPv 6/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 IPv 6, together with operators (Comcast, Rogers…), Martha Steenstrup and academia, we will submit the IPv 6/SR draft proposal for the next IETF and will work with the community to improve it as required 7

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

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 – 6 man – PCEP – RTGWG • Significant operator support and vendor consensus 9

draft-fils-rtgwg-segment-routing-use-cases-00 Sections Presentations today 2. IGP-based MPLS Tunneling Martin, Victor 3. FRR Bruno 4. 1. 1 Disjointness in dual-plane networks Martin 4. 1. 2. Co. S-based Traffic Engineering Martin 4. 4. Deterministic non-ECMP Path Rob 5. 2. SDN /SR use-case Victor 6. 4. Leveraging SR benefits for LDPbased traffic Bruno 7. OAM Rudiger 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. 10

Some questions from the Bo. F 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 v 6 doc How much data plane variety is needed? MPLS? IPv 6? IPv 4? – MPLS is clear – IPv 6 is clear • What are the inherent costs in supporting more than one data plane? – IPv 6 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

Some questions from the Bo. F 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 IPv 6 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 IPv 6, a new type of a routing extension header is required. This is a straightforward DP extension – IPv 6 is a clear mandate for the IETF and the IPv 6/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

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

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

Annex 15

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

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

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

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

IGP Prefix Segment B C D A Z N O P 65 A packet injected anywhere with active segment 65 will reach Z via ecmp-aware shortest-path • 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 draft-previdi-isis-segment-routing-extensions-00 • IPv 4 and IPv 6 draft-psenak-ospf-segment-routing-extensions-00 20

IGP Adjacency Segment A B C D 9003 M N O Z 65 P A packet injected at node C with active segment 9003 is forced through datalink CO • 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 • IPv 4 and IPv 6 draft-previdi-isis-segment-routing-extensions-00 draft-psenak-ospf-segment-routing-extensions-0021

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

Combining Segments {72, 78, 65} 72 A 72 B C D 78 M N O Z 65 P 65 • 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 23

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

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

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 IPv 4 and IPv 6 • No changes in the operations of the MPLS dataplane • SR can co-exist and interwork with other MPLS controlplane protocols (LDP, RSVP) 26

IPv 6 dataplane (without any MPLS dataplane) • All the SR ISIS/OSPF Control Plane is dataplane agnostic and hence applies directly to IPv 6 • Remaining work: detailing the IPv 6 tunneling and new Routing Extension type header – High-level description provided at March IPv 6 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

Annex 28