Cisco Connect Montreal 2017 - Segment Routing - Technology Deep-dive and Advanced Use Cases

© 2016 Cisco and/or its affiliates. All rights reserved. 2

CiscoConnect

Segment Routing: Technology Deep-Dive and Advanced Use CasesThierry CoutureConsulting Systems [email protected]

November 2017

© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public

Agenda• Introduction• Quick Segment Routing Recap• SRv6• SR Traffic Engineering (SR-TE)• Conclusion


Ground Rules• Assumptions:

• Working knowledge of networking • Working knowledge of IP• Working knowledge of MPLS• Working knowledge of Traffic Engineering• Working knowledge of IPv6

• Out of scope:• Segment Routing transition and migration mechanisms (SR/LDP Interop, SRMS, Inter-

AS, vpnv4/rt5 stitching, etc.)• SR Configuration (RTFM)• Services Overlay (L3VPN, EVPN, etc.)

4

Introduction


Breaking News:

The Internet is GROWING(and dad doesn’t want to pay for it anymore!)

6


Segment Routing is Really About SimplificationDescription “Classic” Network SR/EVPN

Management Plane

CLI, SNMP, SSH, Telnet, Syslog, NetFlow, BMP, RCMD, Netconf, E-OAM, MPLS-OAM, YANG(IETF/OpenConfig), gRPC, GPB, PCEP, etc.

NC/YANG, SR-OAM, SR Traffic Matrix, Telemetry

Service Plane L2VPN, L3VPN, BGP-VPLS, LDP-VPLS, EVPN,L2TPv3, GRE, PPP, OTV, LISP, NSH, etc.

EVPN(+ L3VPN)

Control Plane OSPFv2 (IPv4), OSPFv3 (IPv6), ISIS, LDP, T-LDP, RSVP-TE, BGP, Controller, etc.

IGP(incl. FRR)

BGP

Forwarding Plane

IP, MPLS, IPv6, VXLAN, PBB, LISP, GRE, MPLSoGRE, etc.

SRMPLS/IPv6

7

Simplification is really about saving XYZ…

8

Segment Routing 101


Segment Routing• Source Routing

• The source (?) chooses a path and encodes it in the packet header as an ordered list of segments

• The rest of the network executes the encoded instructions• Reduce state, reduce lookups, reduce…

• Segment: an identifier for any type of instruction• Segment identifies network points and/or vectors (forwarding)• Segment identifies services• Segments can be combined (“stacked”)

10


Segment Routing – Forwarding Plane• MPLS: an ordered list of segments is represented as a stack of labels

• Segment ID → Label

• Basic building blocks distributed by the IGP or BGP

• Push, Continue, Next –> Push, Swap, Pop

• IPv6: an ordered list of segments is encoded in a routing extension header• More details later…

11


IGP Prefix Segment• Shortest-path to the

IGP prefix• Equal Cost Multipath

(ECMP)-aware

• Global Segment

• Label = 16000 + Index• Index of NodeX = X is

used for illustrative purposes

• Distributed by ISIS/OSPF

• Prefix != Route Entry

• NOT Dynamically allocated

12

DC (BGP-SR)

10

11

12

13

14

2 4

6 5

7

WAN (IGP-SR)

3

1

PEER

16005


IGP Adjacency Segment• “Pop and Forward on

the IGP adjacency”

• Local Segment• Dynamically allocated

• Value “30X0Y” used for illustration• X is the “from”• Y is the “to”

• Advertised as a label value

• Distributed by ISIS/OSPF

13

DC (BGP-SR)

10

11

12

13

14

2 4

6 5

7

WAN (IGP-SR)

3

1

PEER

30204


Segment Routing - Control Plane• IGP

• ISIS• TLV

• OSPF• Opaque LSA (type 10)

• BGP• BGP-LU

• Controller Based• From closed loop automated control to “management-plane-ish”

14

© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 15

MPLS Control and Forwarding Operation with Segment Routing

PE1 PE2

IGPPE1 PE2

Services

IPv4 IPv6 IPv4 VPN

IPv6 VPN VPWS VPLS

Packet Transport LDP

MPLS Forwarding

RSVP BGPStatic IS-IS OSPF

No changes to control or forwarding plane

IGP or BGP label distribution for IPv4 and IPv6. Forwarding plane remains the same

MP-BGP


router ospf 1router-id 1.1.1.1segment-routing mpls

area 0interface Loopback0passive enableprefix-sid absolute 16001

!!

!

OSPF Configuration Example

Prefix-SID for loopback0

Enable SR on all areas

SID index 11.1.1.11.1.1.2

1.1.1.5 1.1.1.3DR

1.1.1.4

16


MPLS LFIB with Segment Routing• LFIB populated by IGP’s (ISIS /

OSPF), BGP, Controller, etc.• Forwarding table remains constant

(Nodes + Adjacencies) regardless of number of paths

• Other protocols (LDP, RSVP, BGP) can still program LFIB

17

PE

PE

PE

PE

PE

PE

PE

PE

P

In Label

Out Label

Out Interface

L1 L1 Intf1L2 L2 Intf1… … …L8 L8 Intf4L9 L9 Intf2L10 Pop Intf2… … …Ln Pop Intf5

Node-SID

Adjacency-SID

Forwarding table remains constant


Multi-Domain Topology• SR Path Computation

Element (PCE)

• PCE collects via BGP-LS• IGP segments• BGP segments• Topology

18

DC (BGP-SR)

10

11

12

13

14

2 4

6 5

7

WAN (IGP-SR)

3

1

PEER

Low Lat, Low BW

BGP-LS

BGP-LS

BGP-LSSR PCE


End-to-End Policy, Unified Data Plane• Construct a path by

combining segments to form an end-to-end path:• 16001 (Prefix-SID)• 16002 (Prefix-SID)• 30204 (Adj-SID)• 40407 (Peer-SID)

• Per-application flow engineering

• Millions of flows• No signaling• No midpoint state• No reclassification at

boundaries

19

PCEP, Netconf, BGP

SR PCE

Low-Latency to 7for application …

DC (BGP-SR)

10

11

12

13

14

2 4

6 5

7

WAN (IGP-SR)

3

1

PEER

Low LatLow BW

50

Default ISIS cost metric: 10

16001

1600116002

3020440407

{16001,16002,30204,40407 }


Industry at large backs up SR

Strong customer adoption

WEB, SP, Enterprise

StandardizationIETF

Multi-vendor ConsensusInterop testings

De-Facto SDNArchitecture


Segment Routing Standardization• IETF standardization in SPRING working

group• Protocol extensions progressing in

multiple groups• IS-IS• OSPF• PCE• IDR• 6MAN• BESS

• Broad vendor support• Strong customer adoption

• WEB, SP, Enterprise

21

Sample IETF DocumentsProblem Statement and Requirements

(RFC 7855)

Segment Routing Architecture(draft-ietf-spring-segment-routing)

IPv6 SPRING Use Cases (draft-ietf-spring-ipv6-use-cases)

Segment Routing with MPLS data plane(draft-ietf-spring-segment-routing-mpls)

Topology Independent Fast Reroute using Segment Routing(draft-bashandy-rtgwg-segment-routing-ti-lfa)

IS-IS Extensions for Segment Routing(draft-ietf-isis-segment-routing-extensions)

OSPF Extensions for Segment Routing(draft-ietf-ospf-segment-routing-extensions)

PCEP Extensions for Segment Routing(draft-ietf-pce-segment-routing)

Close to 40 IETF drafts in progress


Segment Routing Product Support• Platforms:

• IOS-XR (ASR9000, CRS-1/CRS-3, NCS5000, NCS5500, NCS6000)• IOS-XE (ASR1000, CSR1000v, ASR902, ASR903, ASR920, ISR4400)• NX-OS (N3K, N9K)• Open Source (FD.io/VPP, Linux Kernel, ODL, ONOS, OpenWRT)• PCE (WAN Automation Engine, XTC)

22

SRv6


IPv6 adoption is a reality

% website reachability by country

Source: 6lab.cisco.com – World maps – 11-June-2017

Global IPv6 traffic grew 243% in 2015

Globally IPv6 traffic will grow 16-fold from 2015 to

2020

IPv6 will be 34% of total Internet traffic in 2020


IPv6 Provides E2E Reachability

Support 5G growthIPv6 addresses summarization

5G

5G

5G

IoT services

Support container adoption formicro-services

Next-Gen Data Center

Micro-services

Source Address

Destination Address

IPv6

Metro/Core Network

IP

4G

xDSLFTTH

Cable

LegacyDC


Opportunity for further simplification

• Multiplicity of protocols and states hinder network economics

IPv6 for reach

Additional Protocol just for tenant IDUDP+VxLAN Overlay

Additional Protocol and StateNSH for NFV

RSVP for FRR/TE States scaling problem (k*N^2)


SRv6 – Segment Routing & IPv6• Simplicity

• Protocol elimination

• SLA• FRR and TE

• Overlay• NFV• SDN

• SR is de-facto SDN architecture

• 5G Slicing

27

IPv6 for reach

SRv6 for anything else

SR Header


IPv6 Header• Next Header (NH)

• Indicates what comes next

29


NH = IPv4 4


NH = IPv6 41


NH = TCP 6


NH = UDP 17


NH = Routing Extension• Generic routing extension header

• Defined in RFC 2460• Next Header: UDP, TCP, IPv6…• Hdr Ext Len: Any IPv6 device can skip this header• Segments Left: Ignore extension header if equal to 0

• Routing Type field:• 0 Source Route (deprecated since 2007)• 1 Nimrod (deprecated since 2009)• 2 Mobility (RFC 6275)• 3 RPL Source Route (RFC 6554)• 4 Segment Routing

34

43


NH = SRv6• NH = 43, Type = 4

35

4

RFC

246

0SR

spe

cific

43

TAG


SRH• SRH contains

• the list of segments• Segments left (SL)• Flags• TLV

• Active segment is in the IPv6 DA

• Next segment is at index SL-1

• The last segment is at index 0 • Reversed order

36

4

43

Active Segment

Last Segment

See IETF draft-ietf-6man-segment-routing-header, currently revision -06

TAG

SRH Processing


Source Node

• Source node is SR-capable

• SR Header (SRH) is created with• Segment list in reversed order of the path

• Segment List [ 0 ] is the LAST segment• Segment List [ 𝑛 − 1 ] is the FIRST segment

• Segments Left is set to 𝑛 − 1• First Segment is set to 𝑛 − 1

• IP DA is set to the first segment

• Packet is send according to the IP DA• Normal IPv6 forwarding

Version Traffic ClassNext = 43 Hop LimitPayload Length

Source Address = A1::Destination Address = A2::

Segment List [ 0 ] = A4::Segment List [ 1 ] = A3::

Next Header Len= 6 Type = 4 SL = 2First = 2 Flags TAG

IPv6

Hdr

Segment List [ 2 ] = A2::

SR H

dr

Payload

Flow LabelFlow Label

4A4::

1A1::

SR HdrIPv6 Hdr SA = A1::, DA = A2::

( A4::, A3::, A2:: ) SL=2Payload

2A2::

3A3::

38


Non-SR Transit Node

• Plain IPv6 forwarding

• Solely based on IPv6 DA

• No SRH inspection or update

39


( A4::, A3::, A2:: ) SL=2Payload

4A4::

1A1::

2A2::

3A3::


SR Segment Endpoints• SR Endpoints: SR-capable nodes whose

address is in the IP DA

• SR Endpoints inspect the SRH and do:• IF Segments Left > 0, THEN

• Decrement Segments Left ( -1 )• Update DA with Segment List [ Segments Left ]• Forward according to the new IP DA

40


( A4::, A3::, A2:: ) SL=1Payload





IPv6

Hdr


SR H

dr

Payload


4A4::

AA1::

2A2::

3A3::


SR Segment Endpoints

• SR Endpoints: SR-capable nodes whose address is in the IP DA

• SR Endpoints inspect the SRH and do:• IF Segments Left > 0, THEN

• Decrement Segments Left ( -1 )• Update DA with Segment List [ Segments Left ]• Forward according to the new IP DA

• ELSE (Segments Left = 0)• Remove the IP and SR header• Process the payload:

• Inner IP: Lookup DA and forward • TCP / UDP: Send to socket• …

41

Standard IPv6 processingThe final destination does

not have to be SR-capable.


( A4::, A3::, A2:: ) SL=0Payload





IPv6

Hdr


SR H

dr

Payload


4A4::

1A1::

2A2::

3A3::

SR for AnythingNetwork as a Computer


Network instruction

• 128-bit SRv6 SID• Locator: routed to the node performing the function• Function: any possible function (optional argument)

either local to NPU or app in VM/Container• Flexible bit-length selection

43

Locator FunctionLocator Function(arg)


Network ProgramNext Segment

Locator 1 Function 1






44


Network Program

Next Segment





Locator2 Function2


45


Network Program

Next Segment







46


Argument shared between functions

Locator1 Function1 Argument1



Metadata TLV

“Global”Argument


SR Header

Metadata TLV

Segments Left





SID Function – Anything!• SID functions are locally defined on their parent node

• They can do anything…

• An SR header contains a network program

49

SR H

dr Segment List [ 0 ]Segment List [ 1 ]


Segment List [ 2 ]

TLVs

Function 1

Function 2 ArgsFunction 3 Args

Global arguments

Use-Cases


Integrated NFV

• A3::A32 means• App in Container 32• @ node A3::/64

• Stateless • NSH creates per-chain state

in the fabric• SR does not

• App is SR aware or not

51

IPv6 ( A1::0, A3::A32 )

payloadIPv6 ( T1::0, V2::0 )

SRH { A3::A32, A4::0, A5::A76, A2::C4 }

1

2

4

V/64

3

T/64

4

App 32Container

Server 3

5 App 76VM

Server 5

IPv6 ( T1::0, V2::0 )payload

App 32Container3


Integrated NFV

• Integrated with underlay SLA

52

1

2

4

V/64

3

T/64

4

5 App 76VM

Server 5

3 App 32Container

Server 3IPv6 ( A1::0, A4::0 )


SRH { A3::A32, A4::0, A5::A76, A2::C4 }


Integrated NFV

• A5::A76 means– App in VM 76– @ node A5::/64

• Stateless – NSH creates per-chain state

in the fabric– SR does not

• App is SR aware or not

1

2

4

V/64

3

T/64

4

5 App 76VM

Server 5

3 App 32Container

Server 3IPv6 ( A1::0, A5::A76 )


SRH { A3::A32, A4::0, A5::A76, A2::C4 }


Integrated NFV

• Integrated with Overlay

54

1

2

4

V/64

3

T/64

4

5 App 76VM

Server 5

3 App 32Container

Server 3IPv6 ( A1::0, A2::C4 )


SRH { A3::A32, A4::0, A5::A76, A2::C4 }

IPv6 ( T1::0, V2::0 )payload


More use-cases• 6CN: enhancing IP to search for Content • 6LB: enhancing load-balancers • Video Pipeline• 5G Slicing• 5G Ultra-Low Latency

55


SRv6 status• Cisco HW

• ASR9k - XR • ASR1k – XE• Nexus9K – NX in planning

• Open-Source• Linux 4.10 • FD.IO

56


Network Programming• An SRv6 segment is a function at a node

• An SRv6 segment list is a network program

• The network acts as a large computer

• Integrated use-cases well beyond underlay (TE, FRR)• NFV• Container networking• Efficient content management: Spray, 6CN, 6LB• Video pipeline

• Simplification: IPv6+SRv6 only !

57

SR H

dr Segment List [ 0 ]Segment List [ 1 ]


Segment List [ 2 ]

TLVs

Function 1

Function 2 ArgsFunction 3 Args

Global arguments

SR Traffic Engineering


Motivations for SR-TE• RSVP-TE combined FRR and TE – aaarrgghhhhh…• Legacy solutions challenging at scale

• Core states in k*n^2• No inter-domain (or very difficult)

• Legacy solutions feature complex configuration• Tunnel interfaces and/or per-device flow state

• Legacy solutions offer complex and fragile steering• PBR, autoroute, per-flow state• Granularity tradeoffs with scale

59


SR-TE• In SR, FRR is taken care of via TI-LFA, it is not a TE function…

• Simple, Automated and Scalable• No core state: state in the packet header• No tunnel interface: “SR Policy”

• Prescriptive hop by hop, or use wormholes, your choice…• Static

• Headend configuration• Dynamic

• No headend a-priori configuration: on-demand policy instantiation• No headend a-priori steering: on-demand steering

• Multi-Domain• XTC for compute• Binding SID (BSID) for scale

• Lots of Functionality• Designed with lead operators along their use-cases

60


IETF key document for SR-TE

See IETF draft-filsfils-spring-segment-routing-policy, currently revision -00

(Traffic Protection)

BRKR


Topology Independent LFA (TI-LFA) – Benefits• Based on Loop Free Alternates

• For every point in a forwarding graph, we pre-compute a loop-free option• Meant to cover the gap between failure and routing re-convergence

• 100%-coverage 50-msec link, node, and SRLG protection• Simple to operate and understand

• automatically computed by the IGP

• Prevents transient congestion and suboptimal routing• leverages the post-convergence path, planned to carry the traffic

• Incremental deployment• also protects LDP and unlabeled traffic

63BRKR


TI-LFA – Zero-Segment Example• TI-LFA for link R1R2 on R1• Calculate post-convergence SPT

• SPT with link R1R2 removed from topology

• Derive SID-list to steer traffic on post-convergence path à empty SID-list

• R1 will steer the traffic towards LFA R5

64

1000

Default metric: 10

A

55

4

Packet to Z

Packet to Zprefix-SID(Z)

1 2

Z

3



TI-LFA – Single-Segment Example• TI-LFA for link R1R2 on R1• Calculate post-convergence

SPT• Derive SID-list to steer traffic

on post-convergence path à<Prefix-SID(R4)>• Also known as “PQ-node”

• R1 will push the prefix-SID of R4 on the backup path

65


prefix-SID(R4)

Default metric:10

5

21

A Z

3


Packet to Z

4


4


TI-LFA – Double-Segment Example• TI-LFA for link R1R2 on R1• Calculate post-convergence SPT• Derive SID-list to steer traffic on

post-convergence path à<Prefix-SID(R4), Adj-SID(R4-R3)• Also known as “P- and Q-node”

• R1 will push the prefix-SID of R4 and the adj-SID of R4-R3 link on the backup path

66

Default metric: 10

5

21

A Z

R3R4 34


Packet to Z


adj-SID(R4-R3)prefix-SID(R4)


adj-SID(R4-R3)

1000


SR Policy


SRTE DB• A headend can learn an attached domain topology via its

IGP or a BGP-LS session • A headend can learn a non-attached domain topology via a

BGP-LS session• A headend collects all these topologies in the SR-TE

database (SRTE-DB).• The SRTE-DB is multi-domain capable

68


SR Policy Identification• An SR Policy describes an optimization objective between a head end and an

end-point

• An SR Policy is uniquely identified by a tuple(head-end, color, end-point)

Head-end: where the SR Policy is instantiated (implemented)Color: an arbitrary numerical value to differentiate multiple SRTE Policies between the

same pair of nodesEnd-point: the destination of the SR Policy

2 3

7 6

4

1

5

SR Policy

(1, green, 4)Head-end: 1Color: greenEnd-point: 4

69


SR Policy Color• Each SR Policy has a color

• Color is used to indicate a certain treatment (policy) provided by an SR Policy

• Only one SR Policy with a given color C can exist between a given node pair (head-end (H), end-point (E))• In other words: each SR Policy triplet (H, C, E) is unique

• Example:• High-BW=“blue”, Low-latency=“green”• steer traffic to 1.1.1.0/24 via Node4

into High-BW SR Policy (1, blue, 4)• steer traffic to 2.2.2.0/24 via Node4

into LL SR Policy (1, green, 4)

2 3

7 6

4

1

5

(1, green, 4)

(1, blue, 4)

1.1.1.0/242.2.2.0/24

Low-latency

High-BW

70


SR Policy – Candidate Paths• An SR Policy contains

multiple candidate paths• An SR Policy instantiates

one single path in RIB/FIB• i.e. the selected path

among the candidate paths. • A candidate path is either

dynamic or explicit• A candidate path may have one or

more weighted SID-lists• Traffic steered onto an SR Policy

Path is load-shared over all SID-lists of that path

71

SR Policy

Cpathn

Preferencen

...

Cpath1

Binding-SIDn

Preference1

Binding-SID1

SID-list1m

...

Weight1m

SID-list11

Weight11

SID-listnk

...

Weightnk

SID-listn1

Weightn1


Candidate Paths (Cont.)• A head-end may be informed about a path for a policy <color, end-

point> by various means including: local configuration (CLI), netconf, PCEP, or BGP

netconfCLI

PCEPBGP

SRTE

72


• A new SAFI is defined: SR Policy SAFI• Codepoint value 73, recently assigned by IANA

• The NLRI identifies the SR Policy• Distinguisher: BGP-specific mechanism to allow to distribute multiple paths for the

same SR Policy and avoid BGP-based path selection• Recommendation: path selection should be done by SR-TE as part of the SR Policy behavior

• Policy Color: identifies the color of the policy• Endpoint: identifies the endpoint of a policy

SAFI and NLRI

73

+-----------------------------------------------+| Distinguisher (4 octets) |+-----------------------------------------------+| Policy Color (4 octets) |+-----------------------------------------------+| Endpoint (4 or 16 octets) |+-----------------------------------------------+

See IETF draft-previdi-idr-segment-routing-te-policy, currently revision -07


Path’s source does not influence selection

Provided by e.g. local configuration

Provided by e.g. BGP SR-TE

Selection depends on validity and best (highest preference value)

SR Policy( Head, Color, End )

SID-list11<16003,

16004>Weight 1

SID-list12<16004>Weight 4

Cpath1

Pref 110

SID-list21<16004>Cpath2

Pref 100

VALI

DVA

LID

VALI

D✔ Cpath3

Pref 200

SID-list31<16005,

16004>


Path’s source does not influence selection

Provided by e.g. local configuration

Provided by e.g. BGP SR-TE

Selection depends on validity and best (highest preference value)

SR Policy( Head, Color, End )

SID-list11<16003,

16004>Weight 1

SID-list12<16004>Weight 4

Cpath1

Pref 110

SID-list21<16004>Cpath2

Pref 100

VALI

DVA

LID

INVA

LID

✔

Cpath3

Pref 200

SID-list31<16005,

16004>

BRKRST-3122


BSID of a policy

• The BSID of an SR Policy refers to its selected path

76

SR Policy

Pathn

Preferencen

...

Path1

Binding-SIDn

Best Pref

Binding-SID

SID-listm

...

Weightm

SID-list1Weight1

SID-listk

...

Weightk

SID-list1Weight1


Policy – FIB entry

2 3

6 5

41

20

Default link metric: 10

10GE

40GE

SR PolicySID-list:{16003,

16004}

Selected Path

BSID:40104

In Out Out_intf Fraction

40104 {16003, 16004} To Node2 100%

Forwarding table on Node1

Dynamic PathHeadend Computation


Prefer SR-native Algorithm2

4

1 5 3

67

8 9

Classic Circuit Algo is not optimum!SID List: {4, 5, 7, 3}

Poor/no ECMP, big SR list ATM optimized

SR-native is optimumShortest SID list with Max ECMP

SID List: {7, 3}IP-optimized

2

4

1 5 3

67

8 9


segment-routingtraffic-engpolicy POLICY1color 20 end-point ipv4 1.1.1.3binding-sid mpls 1000candidate-pathspreference 100dynamic mplsmetrictype temargin absolute 5sid-limit 6

80

Min-Metric with Marginand max SID list

2 3

4

1T:15

6

5

T:15

T:5I:30

T:8

Default IGP link metric: I:10Default TE link metric: T:10

Min-Metric(1 to 3, TE) = SID-list <16005, 16004, 16003>Cumulated TE metric = 23

Min-Metric(1 to 3, TE, m=5, s<=6) = SID-list <16005, 16003>Max Cumulated TE metric = 25 < 23+ 5


segment-routingtraffic-engpolicy POLICY1color 20 end-point ipv4 1.1.1.3binding-sid mpls 1000candidate-pathspreference 100dynamic mplsmetrictype latency

Nod

e1

2 3

4

1


T:15

5

T:15

I:30T:8SID-list: {16005, 16004, 16003}

6

Low-Latency

• Min-metric on TE metric where propagation latency is encoded in TE metric• same with margin and Max-SID• same with latency metric automatically measured by a node for its attached links and

distributed in the IGP

81


segment-routingtraffic-engaffinity bit-map Plane1 0x00000001Plane2 0x00000002

!policy POLICY1color 20 end-point ipv4 1.1.1.3binding-sid mpls 1000candidate-pathspreference 100affinityexclude-any Plane2

dynamic mplsmetrictype igp

Nod

e1

Plane Affinity

• Min-Metric on IGP metric with exclusion of a TE-affinity “Plane2”• all the links part of plane 2 are set with TE-affinity “Plane2”

82

1 2

11 12

313 14

21 22

23 24

Plane1Plane2

SID-list:{ 16014, 16003 }


segment-routingtraffic-engpolicy POLICY1color 20 end-point ipv4 1.1.1.7candidate-pathspreference 100dynamic mplsmetrictype igpassociation group 1 type node

policy POLICY2color 30 end-point ipv4 1.1.1.7candidate-pathspreference 100dynamic mplsmetrictype igpassociation group 1 type node

Nod

e1

2 3

5 6

4 71

I:100

Default IGP link metric: I:10

I:100SID-list: {16002, 30203, 16007}

SID-list: {16005, 16007}

Service Disjointness from same headend• The headend computes two disjoint paths

83

I:20

On-demand SR PolicyIntra-Domain


On-Demand SR Policy• A service head-end automatically instantiates an SR Policy to a BGP

next-hop when required (on-demand), automatically steering the BGP traffic into this SR Policy

• Color community is used as SLA indicator• Reminder: an SR policy is defined (endpoint, color)

85

BGP Next-hop

BGP Color Community


Different VPNs need different underlay SLA

2

6

1 CE

5

4IGP: 50

Default IGP cost: 10Default TE cost: 10

IGP cost 30

TE: 15

2

6

1 CE

5

4

TE cost 20

Basic VPN should use lowest cost underlay path

Premium VPN should use lowest latency path

IGP: 50

TE: 15

Objective: operationalize this service for simplicity, scale

and performance


2

6

1 CE

5

4I: 50

T: 15

On-demand SR Policy work-flow

➊ BGP: 20/8 via CE

20/8

RR➋ BGP: 20/8 via PE4VPN-LABEL: 99999Low-latency (color 20)

➌ BGP: 20/8 via PE4VPN-LABEL: 99999Low-latency (color 20)

router bgp 1neighbor 1.1.1.10address-family vpnv4 unicast

!segment-routingtraffic-engon-demand color 20metrictype te

➍ PE4 with Low-latency (color 20)?➎ use templatecolor 20➏à SID-list<16002, 30204>

➎

Default IGP cost: I:10Default TE cost: T:10

no route-policy required!

SR Policy template Low-latency (color 20)

87


2

6

1 CE

5

4I: 50

T: 15

Automated performant steering

➊ BGP: 20/8 via CE

20/8

RR➋ BGP: 20/8 via PE4VPN-LABEL: 99999Low-latency (color 20)

➌ BGP: 20/8 via PE4VPN-LABEL: 99999Low-latency (color 20)

➍ PE4 with Low-latency (color 20)?➎ use templatecolor 20➏à SID-list<16002, 30204>

FIB table at PE1

SRTE: 4001: Push <16002, 30204>

➐ instantiate SR Policy BSID 4001

Low Latency to PE4

➑ forward 20/8via BSID 4001

➑➐

BGP: 20/8 via 4001

Default IGP cost: I:10Default TE cost: T:10

Automatically, the service route resolves on the Binding SID (4001) of

the SR Policy it requires

Simplicity and Performance

No complex PBR to configure, no PBR performance tax

88


Benefits• SLA-aware BGP service• No a-priori full-mesh of SR policy configuration

• 3 to 4 common optimization templates are used throughout the network• color => optimization objective

• No complex steering configuration• Automated steering of BGP routes on the right SLA path• Data plane performant• BGP PIC FRR data plane protection is preserved• BGP NHT fast control plane convergence is preserved

89

XTC and SR policy


XR Transport Controller (XTC)• XTC is an IOS XR multi-domain, stateful SR PCE*

• IOS XR: XTC functionality is available on any physical or virtual IOS XR node, activated with a single configuration command

• SR: Stateful with native SR-optimized computation algorithms – same as the head end!

• Multi-domain: Real-time reactive feed via BGP-LS/ISIS/OSPF from multiple domains; computes inter-area/domain/AS paths

• Stateful: takes control of SRTE Policies, updates them when required

• XTC is fundamentally distributed• Not a single all-overseeing entity, but distributed across the network; RR-alike

deployment* Path Computation Element

91


XTC consolidates the topologies• XTC combines the different

topologies to compute paths across entire topology

Domain1 Domain2

A BR1 BR3

BR2 BR4

Domain3

Z

BR5

BR6

BGP-LS

Peer

ing

links

Domain1 Domain2

A BR1 BR3

BR2 BR4

Domain3

Z

BR5

BR6

XTC

92


Domain1 Domain2

PCEP

XTC

Request/Reply/Report workflow• u Node1 is configured to instantiate a

low-latency SR Policy to Node3, e.g. by Network Service Orchestrator (NSO)

• Since the end-point Node3 is in a remote domain, Node1 cannot compute the dynamic path locally and must use XTC 2

6 7

5 7

I:100

I:1003

8

4

I:100

I:100➊ low-latency to 3 ?

A single centralized XTC node to

simplify illustration

1


93


Domain1 Domain2

PCEP

Request/Reply/Report workflow (Cont.)• v Node1 sends a PCEP Path

Computation Request (PCReq) to XTC, requesting path “to Node3” with “Optimize TE metric”

• w XTC stores the request and computes a TE metric shortest-path from Node1 to Node2, say the resulting SID list is <30102, 30203>

• x PCE sends “SID list <30102, 30203>” to Node1 in PCEP Path Computation Reply (PCRepl)

1 2

6 7

5 7

I:100

I:1003

8

4

I:100

I:100➊

➋ PCReq “to 3”, “TE metric”

➍ PCRepl“SID-list <30102, 30203>”

➌à SID-list <30102, 30203>

XTC


94


Request/Reply/Report workflow (Cont.)• y Node1 allocates a BSID 4001 and

activates the SR Policy path to Node3 via <30102, 30203>

• and z sends Path Computation Report (PCRpt) to XTC, delegating the SR Policy to XTC and including BSID

Domain1 Domain2

1 2

6 7

5 7

I:100

I:1003

8

4

I:100

I:100

➋

➍

➌

➎ SID-list: <30102, 30203>

FIB table at Node1SRTE: 4001: Push <30102, 30203>

➏ PCRept“BSID 4001”, “delegate”

PCEP

XTC

➊


BSID

95


XTC – High Availability (HA)• XTC leverages the well-known standardized PCE HA

• Head-end sends PCEP Report for its SR Policies to all connected XTC nodes

• Head-end delegates control to its primary XTC• Delegate flag (D) is set in PCRept to primary XTC

• Upon failure of the primary XTC, head-end re-delegates control to another XTC

96

Conclusion


SR TE• Simple, Automated and Scalable

– No core state: state in the packet header– No tunnel interface: “SR Policy”– No headend a-priori configuration: on-demand policy instantiation– No headend a-priori steering: on-demand steering

• Multi-Domain – XTC

• Lots of Functionality– Designed with lead operators along their use-cases

98

Conclusion


Segment Routing is Really About SimplificationDescription “Classic” Network SR/EVPN

Management Plane

CLI, SNMP, SSH, Telnet, Syslog, NetFlow, BMP, RCMD, Netconf, E-OAM, MPLS-OAM, YANG(IETF/OpenConfig), gRPC, GPB, PCEP, etc.

NC/YANG, SR-OAM, SR Traffic Matrix, Telemetry

Service Plane L2VPN, L3VPN, BGP-VPLS, LDP-VPLS, EVPN,L2TPv3, GRE, PPP, OTV, LISP, NSH, etc.

EVPN(+ L3VPN)

Control Plane OSPF, ISIS, LDP, T-LDP, RSVP-TE, BGP, etc. ISIS(incl. FRR)

BGP

Forwarding Plane

IP, MPLS, IPv6, VXLAN, PBB, LISP, GRE, MPLSoGRE, etc.

SRMPLS

100

Simplification is Really about Saving XYZ…


Stay Up-To-Date on SR

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

https://www.linkedin.com/groups/8266623

https://twitter.com/SegmentRouting

https://www.facebook.com/SegmentRouting/ amzn.com/B01I58LSUO

101

Thank you