segment routing

Segment Routing PONC – 2015, Herndon VA

draft-previdi-filsfils-isis-segment-routing-02

Craig Hill Distinguished SE U.S. Federal CCIE #1628 – [email protected]

Cisco Confidential 2 © 2013-2014 Cisco and/or its affiliates. All rights reserved.

§  Balance of distributed intelligence and centralized optimization and programming §  simplify the operation of MPLS (lower opex) §  enable application-based service creation (new revenue) §  enable scalable/reactive network programmability (SDN) §  allow for better utilization of the installed infrastructure (lower capex) §  apply to OTT, SP, Large Entreprises across WAN, DC, Access.

Segment Routing


Segment Routing •  Simple to deploy and operate

–  Leverage existing MPLS forwarding, HW, and services –  straight-forward ISIS/OSPF extension to distribute labels –  LDP/RSVP not required –  exponentially less state in the routing elements for TE –  agnostic control-plane also applicable to IPv6

•  Provide for optimum scalability, resiliency and virtualization •  Tighter integration with application

–  simpler network, highly programmable –  highly responsive

The state is no longer in the network but in the packet


Segment • Nodal segment

–  a path (any path definition) to a node –  represented by a unique global label within the ISIS domain (operator

configurable)

•  Adjacency segment –  a hop over an adjacent datalink to a neighbor –  represented by a unique local label of the advertising node (system configured)

•  Flooded and automatically computed by ISIS –  SR subTLV for TLV 22 and 135


§  Simple extension to let IGP install segments in the MPLS dataplane

§  Excellent Scale: a node installs N+A FIB entries §  N node segments and A adjacency segments

IGP Segments

A B C

M N O

Z

D

P

Node segment to C

Node segment to Z

Adj Segment

Node segment to C


Node Segment

•  Z advertises a global node segment 16065 with its loopback –  simple ISIS sub-TLV extension >  default SRGB [16000, 23999] at all nodes is a request from all lead operators for operational

simplicity. The protocol and implementation allows for different SRGB at every node

•  All remote nodes install in their FIB the node segment 16065 to Z

A B C

Z

D

16065

FEC Z push 16065

swap 16065 to 16065

swap 16065 to 16065

pop 16065

A packet injected anywhere with top segment 16065 will

reach Z via shortest-path

Packet to Z

Packet to Z

16065 Packet to

Z

16065 Packet to

Z

16065 Packet to

Z


Node Segment

• ECMP – A node segment to 16078 distributes traffic across all ECMP paths to O

A B C

M N O

Z

D

P

16078


Adjacency Segment

•  C allocates a local segment 29003 and maps it to the instruction “complete the segment and forward along the interface CO”

•  C advertises the adjacency segment in ISIS –  simple sub-TLV extension

•  C is the only node to install the adjacency segment in FIB

A B C

M N O

Z

D

P

Pop 29003

A packet injected at node C with segment

29003 is forced through datalink CO


Label advertisement within ISIS

•  Simple extension –  One single 4-byte Segment sub-TLV

•  Nodal segment: sub-TLV attached to leaf TLV –  leaf is loopback

•  Adjacency segment: sub-TLV attached to adjacency TLV

B C

O

D

C’s linkstate LSP advertises Leaf C/C with global nodal label 67 Adjacency CB with local label 9001 Adjacency CD with local label 9002 Adjacency CP with local label 9003


Explicit path as Segment List

•  ECMP –  Node segment

•  Per-flow state only at head-end –  not at midpoints

•  Source Routing –  the path state is in the packet

header

A B C

M N O

Z

D

P

16078

Packet to Z 16065 16078

Packet to Z 16065

Packet to Z

Packet to Z 16065

Packet to Z 16065 16078 16072

Packet to Z 16065 16078 16072

16072 16072

16065

16065


Cisco Confidential 16 © 2014 Cisco and/or its affiliates. All rights reserved.

Verifying MPLS Forwarding RP/0/0/CPU0:xrvr-3#show mpls forwarding Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 16001 16001 No ID Gi0/0/0/0 10.0.0.1 0 16002 Exp-Null-v4 No ID Gi0/0/0/0 10.0.0.1 0 16004 Pop No ID Gi0/0/0/1 10.0.0.6 0 16005 16005 No ID Gi0/0/0/1 10.0.0.6 0 16010 16010 No ID Gi0/0/0/0 10.0.0.1 0 16010 No ID Gi0/0/0/1 10.0.0.6 0 24000 Pop No ID Gi0/0/0/0 10.0.0.1 0 24001 Pop No ID Gi0/0/0/1 10.0.0.6 0

Remote prefix-SID

Neighbor prefix-SID PHP on

Remote prefix-SIDs ECMP

R3 R2

R4 R5

Gi0/0/0/0

Gi0/0/0/1

R1

R10 Rn advertises prefix-SID 16000+n

Local Label == Outgoing Label

Neighbor prefix-SID Explicit-Null

Use-Cases and Benefits


IPv4 MPLS Transport with IP FRR

•  IPv4 over MPLS: the obvious way it should have been done –  Just the IGP to operate –  Sub50msec FRR integrated and automated

•  Seamless migration –  SR/LDP interworking

A B

M N

PE2 PE1

All VPN services ride on the prefix segment to PE2

Any service resolving on IGP IPv4 Prefix SID

-  Internet

-  VPNv4 -  6PE -  PW


SDN WAN Orchestration Platform

•  Application platform for placing traffic demands and paths across an IP/MPLS WAN

•  North-Bound API: Java/REST

•  South-Bound (Bi-Directional): BGP-LS (update link-state TO controller), stateful PCEP (programs network elements FROM controller), Netc/YANG

•  Intelligent collector, planner, and optimizer engine and can leverage “what if” exercises for load placement

•  Multi-vendor enabled & extensible

•  Leverages OpenDaylight Infrastructure with “WAN Orchestration” applications (uses REST to controller)

Collector Programming

Application Engine

WAN

Databases

MATE Apps

Client Apps

Cross Domain Orchestration

APIs

IP/MPLS Segment Routing Multi-

Layer

SDN WAN

BGP-LS PCEP


Centralized Traffic Engineering

2G from A to Z please

Link CD is full, I cannot use the shortest-path 65 straight to Z

16065

FULL

16065


Centralized Traffic Engineering

Path ABCOPZ is ok. I account the BW. Then I steer the traffic on this path

FULL 16066

16065 16068

• Highly programmable and responsive to rapid changes –  perfect support for centralized optimization efficiency, if required

Tunnel AZ onto {66, 68, 65}


Disjoint TE Service •  A to Z any plane

–  IGP shortest-path –  PrefixSID of Z (65)

•  A to Z via blue plane –  SRTE policy pushes one additional

segment “Blue Anycast” (111)

•  Benefits –  ECMP –  No hop-by-hop signalling load and delay –  No midpoint state

Beta Available

16065 pkt

16065 pkt

16111


Latency TE Service

•  Data from Tokyo to Brussels –  IGP shortest-path via US, higher and cheaper capacity –  PrefixSID of Brussels

•  Voice from Tokyo to Brussels –  SRTE policy pushes one additional segment “Russia Anycast” –  Low-latency path

•  Benefits –  ECMP –  Availability of the anycast segment against node failure –  No hop-by-hop signalling load and delay –  No midpoint state

Node segment to Brussels Node segment to Russia

Brussels pkt

Data

Brussels pkt

Russia

Voice


§  SR flows can be auto-routed over existing RSVP-TE tunnels

SR and RSVP co-existence Service A over SR

FCS in June

SR only

SR and RSVP-TE

RSVP-TE only


Topology-Independent LFA

• 100%-coverage • 50-msec • Link and Node protection • Automated and Simple to operate and understand • Prevents transient congestion and suboptimal routing –  leverages the post-convergence path, planned to carry the traffic

•  Incremental deployment –  applicable to primary IP, LDP and SR traffic

Beta available

Industry Acceptance & Standardization


§  Fundamental to the velocity and success

§  Significant commitment §  technical transparency §  multi-vendor commitment §  beta and poc

§  Many more operators now involved

§  Deployments in a few months

Strong Operator Partnership


IETF

• Working-Group is created • Use-Case is WG status • Architecture is WG status • Protocol Extension is WG status • ~ 25 drafts maintained by SR team Over 50% are WG status Over 75% have a Cisco implementation

www.segment-routing.net


Segment Routing Header

•  Segment Routing introduces a new Routing Header Type: –  The Segment Routing Header (SRH) –  Contains the list of segments the packet should

traverse –  VERY close to what already specified in RFC2460 –  Changes are introduced for: > Better flexibility > Addressing security concerns raised by RFC5095

•  Two SR-IPv6 drafts: –  draft-previdi-6man-segment-routing-header –  draft-martin-spring-segment-routing-ipv6-use-cases

S. Previdi, Ed. C. Filsfils Cisco Systems, Inc. B. Field Comcast I. Leung Rogers Communications March 5, 2014

IPv6 Segment Routing Header (SRH)

draft-previdi-6man-segment-routing-header-00

J. Brzozowski J. Leddy Comcast I. Leung Rogers Communications S. Previdi M. Townsley C. Martin C. Filsfils R. Maglione Cisco Systems March 5, 2014

IPv6 Segment Routing Use Cases

draft-martin-spring-segment-routing-ipv6-use-cases-00

Conclusion


§  Leverage MPLS dataplane and services §  Drastically improve MPLS control-plane while enabling new services

§  Simplicity, Scale, Functionality, Centralized Optimization and Programmability

§  Strong operator adoption and tight involvement

§  Innovation and Standardization

§  Aggressive productization by Cisco

§  PoC and Beta code available

Segment Routing


§  http://www.segment-routing.net/

Stay Informed


Get involved

• All of these use-cases are either FCS or beta available • Leverage dcloud.cisco.com virtual labs • Get involved and provide ideas and requirements • SR is operator driven • Your help is key

Thank you.

segment routing

Technology