segment routing on demand sr next hop - cisco.com · segment routing on demand sr next hop bertrand...

Segment Routing On Demand SR Next Hop

Bertrand Duvivier Principal Engineer

CKN, March 29th 2016

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

(from next slide)


Network Bandwidth demand in SP’s

Network 1 1.66 2.76 4.57 7.59 12.60 20.92 34.73 57.66 95.71 Compute 1 1.50 2.25 3.38 5.06 7.59 1.139 1.709 2.563 38.44

Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 Year 9 Year 10

http://www.ieee802.org/3/ad_hoc/bwa/BWA_Report.pdf

Compute demand double every 24

months

Network demand double every 18

months


•  Bigger routers: •  100G •  Multi-Chassis •  Hardware bandwidth double every 3-4 years

•  More routers: •  Limited amount of router per IGP domain •  Resulting in insertion of additional domain’s •  Example: MAN between WAN, DC and

Access

•  Seamless services: DC, WAN, MAN, Aggregation, Access

Impact on network design

Access

Access

DC

DC

MAN WAN

NY region


METRO architecture changes

P P

PE PE

P P

Leaf

CDN

PE PE Access

WAN WAN

Man Fabric

DC

DCI DCI

Leaf Leaf Leaf

NfV

DC

Peering

Access Peering


MAN fabric & traffic flows

•  CLOS architecture (2, 3 or 4 layers)

•  100G

•  Large ECMP

•  Heavy use of CDN !  To reduce North-South traffic (between

Access domain’s and WAN domains) !  Increasing East/West traffic (between DC’s

and Access’s domains)

•  Still need for end-end reachability.

•  Still need to engineer traffic end-end.

P P

Leaf

CDN

PE PE

WAN

DC

DCI DCI

Leaf Leaf Leaf

NfV

DC

Access Peering

East-West

Nor

th-S

outh


Why Traffic Engineering ?

•  High bandwidth paths

•  Low Latency paths

•  Disjoint paths

•  Avoid resources o  avoid low bandwidth links o  avoid high utilized links

•  Optimize Network Capacity

•  Ad-hoc o  Calendaring


Distributed or Centralized computing ? Policy Single-Domain Multi-Domain

Reachability IGP’s Centralized

Low Latency Distributed or Centralized Centralized

Disjoint from same node Distributed or Centralized Centralized

Disjoint from different node Centralized Centralized

Avoiding resources Distributed or Centralized Centralized

Capacity optimization Centralized Low Priority

Others… TBD Centralized


•  On Demand Next Hop •  BGP SR-TE dynamic •  HA with IOS-XR PCE SR controller

Segment Routing Traffic Engineering: Keep it simple via innovation…


DC WAN Access

Unicast-SID 17001 Anycast-SID 18001 Unicast-SID 16001

BGP Route Reflector

Tail-f NSO controller

Unicast-SID 17002 Anycast-SID 18001



ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

BGP Link State

Hint: 1. PCE collect topology and SID via BGP LS

On demand SR Next Hop


XML YANG: -  PW-123 from ToR1 to AC1

Hint: 1.  PCE collect topology and SID via BGP LS 2.  NSO to configure service

DC WAN Access

Unicast SID 17001 Anycast SID 18001 Unicast-SID 16001

BGP Route Reflector


Unicast SID 17002 Anycast SID 18001



ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

XML YANG: -  PW-123 from AC1 to ToR1



DC WAN Access


BGP Route Reflector





ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

Hint: 1.  PCE collect topology and SID via BGP LS 2.  NSO to configure service 3.  ToR1 check if he has LSP to AC1

Yes -> use it No -> next slide

Do I have LSP to AC1 ?



DC WAN Access


BGP Route Reflector





ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

Hint: 1.  PCE collect topology and SID via BGP LS 2.  NSO to configure service 3.  ToR1 check if he has LSP to AC1 4.  ToR1 request LSP to PCE PCEP request

- Could you provide me the ERO to reach AC1 ?

PCEP reply -  ERO is: 18001,18002,16001

1 2

3



Hint: 1.  PCE collect topology and SID via BGP LS 2.  NSO to configure service 3.  ToR1 check if he has LSP to AC1 4.  ToR1 request LSP to PCE 5.  ToR1 report service state to NSO

DC WAN Access

Unicast-SID 17001 Anycast-SID 18001 Unicast-SID 16001

BGP Route Reflector





ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

XML YANG notification: -  PW-123 is UP


Ethernet PW 16001 18002 18001 Ethernet PW 16001 18002 Ethernet PW 16001

Ethernet Ethernet


XML YANG: -  PW-123 from ToR1 to AC1 -  Policy: Low Latency

Hint: 1.  PCE collect topology and SID via BGP LS 2.  NSO to configure service

DC WAN Access


BGP Route Reflector





ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

XML YANG: -  PW-123 from AC1 to ToR1 -  Policy: Low Latency

ODN with policy


DC WAN Access


BGP Route Reflector





ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

Hint: 1.  PCE collect topology and SID via BGP LS 2.  NSO to configure service 3.  ToR1 check if he has LSP to AC1 4.  ToR1 request LSP to PCE

PCEP request -  Could you provide me the ERO

to reach AC1 ? -  Policies are Low Latency

PCEP reply -  ERO is: 17001,17003,16001

1 2

3

ODN with policy


Hint: 1.  CPE send BGP update for prefix X and

add LL community ex: 100:333

NLRI: X Community: LL

Technical name: BGP SR-TE dynamic

DC WAN Access






ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

CPE2

BGP Route Reflector

CPE1

On demand steering for BGP services



add LL community 2.  AC1 PE announce VPN prefix X with LL

community


DC WAN Access






ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

CPE2

BGP Route Reflector

NLRI: VPN_X Community: LL

CPE1




add LL community 2.  AC1 PE announce VPN prefix X with LL

community 3.  On demand Next Hop LL to PCE controller 4.  Install explicit path for prefix X in VRF


DC WAN Access






ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

PCE controller

AC2

CPE2

BGP Route Reflector

CPE1

PCEP request -  Could you provide me the ERO

to reach AC1 ? -  Policy is Low Latency

PCEP reply -  ERO is: 17001,17003,16001

1

2

3



ODN HA model Hint: 1. Collect topology and SID via BGP LS

Hint: •  NSO and provisioning centralized and part

of NMS/OSS •  PCE and RR function could be distributed

•  Scale sessions •  Full HA

•  BGP and PCE are Statefull: Client and Controller states are always synchronized.

IOS-XR PCE SR controller

Coming soon

DC WAN Access





ToR1

ToR2

ABR1

ABR2

ABR3

ABR4

AC1

Unicast-SID 16002

Unicast-SID 16001

Unicast-SID 16002

AC2

CPE2 CPE1


PCE RR

PCE RR

PCE RR

PCE RR


PCE

21 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Cisco Confidential 21 © 2013 Cisco and/or its affiliates. All rights reserved.

Platform’s supporting SR

ASR1000 / ISR400 / cBR8

ASR9000 NCS6000 CRS-3 / CRS-X

ASR900

NCS5000

NCS5500

NEXUS 9000

FD.io

CSR1000v

IOS classic IOS XR NexOS

Linux

XRV-9000

Thank you.

Kris Michielsen

Segment Routing On-Demand Next-Hop (ODN) Demonstration


Demo – Objective • Trigger automatic SRTE Policies for traffic to VPN destinations – Policies that meet customer / application SLA (e.g. latency optimized,

disjointness) – Without any pre-configured TE tunnel at ingress PE – With automatic steering and without typical PBR performance tax


Demo – Objective • Trigger automatic SRTE Policies for traffic to VPN destinations – Policies that meet customer / application SLA (e.g. latency optimized,

disjointness) – Without any pre-configured TE tunnel at ingress PE – With automatic steering and without typical PBR performance tax

•  Inter-domain SRTE policies computed by centralized SR stateful PCE – SR PCE running on an IOS XR device


Reference Topology

Router-id of NodeX: 1.1.1.X Prefix-SID index of NodeX: X Link address XY: 99.X.Y.X/24 with X<Y Adj-SID XY: 240XY

Default IGP Metric: I:10 Default TE Metric: T:10 TE Metric used to express latency

Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30


Reference Topology

Router-id of NodeX: 1.1.1.X Prefix-SID index of NodeX: X Link address XY: 99.X.Y.X/24 with X<Y Adj-SID XY: 240XY

Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11 1.1.1.3 16003

1.1.1.7 16007

1.1.1.22 16022

1.1.1.23 16023

1.1.1.10

1.1.1.5 16005

1.1.1.9 16009

Domain 1 IS-IS / SR

Domain 2 IS-IS / SR

T:30

T:30

1.1.1.11

Default IGP Metric: I:10 Default TE Metric: T:10 TE Metric used to express latency

SR: Segment Routing


Demo Components

Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

Domain 1 IS-IS / SR

Domain 2 IS-IS / SR

SR PCE

PCC PCC

PCC PCC

T:30

T:30

SR: Segment Routing PCE: Path Computation Element PCC: Path Computation Client


Demo Components

Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11 BGP-LS

Domain 1 IS-IS / SR

Domain 2 IS-IS / SR

T:30

T:30

SR PCE

SR: Segment Routing PCE: Path Computation Element BGP-LS: BGP Link-state


Demo Components

Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11 PCEP

PCEP

PCEP

PCEP

Domain 1 IS-IS / SR

Domain 2 IS-IS / SR

T:30

T:30

SR PCE

SR: Segment Routing PCE: Path Computation Element PCEP: PCE Protocol


Demo Components

Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11 RR

BGP

BGP

BGP

BGP 1.1.1.2 1.1.1.21

Domain 1 IS-IS / SR

Domain 2 IS-IS / SR

T:30

T:30

RR: Route Reflector


Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30

Dynamic VPN instantiation of SRTE policies • CE21 advertises prefixes to PE

BGP: 1.1.1.21/32, via 21


Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30

Dynamic VPN instantiation of SRTE policies • CE21 advertises prefixes to PE • PE22 checks its policy and finds that 1.1.1.21/32 must receive low latency service

MAP: 1.1.1.21/32 in vrf BLUE must receive low latency service " tag with community (100:777)

BGP: 1.1.1.21/32, via 21


Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30


• PE22 tags 1.1.1.21/32 with a BGP community (e.g. 100:777) and sends to RR11


BGP: 1.1.1.21/32, via 21


Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30


• PE22 tags 1.1.1.21/32 with a BGP community (e.g. 100:777) and sends to RR11

• RR11 sends to PE3


BGP: 1.1.1.21/32, via 21


Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30

Dynamic VPN instantiation of SRTE policies • PE3 checks its policy and finds it must use a path to BGP NH (PE22) with optimized TE Metric1

–  A TE attributeset defines constrains and computation requirements (e.g. attr-set “LTCY”)

1 TE metric is used here to express link latency

MAP: Community (100:777) means “minimize TE Metric” and “compute at PCE”


Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30

Dynamic VPN instantiation of SRTE policies • PCC 3 requests a path towards (22) from PCE (10)

COMPUTE: minimize TE Metric to Node22

PCreq/reply


Vrf BLUE

Vrf BLUE

3

7

22

23

21

5

9

2 13 14

10 11

T:30

T:30

Dynamic VPN instantiation of SRTE policies • PCC 3 requests a path towards (22) from PCE (10)

• PCE computes a dynamic path with the required Optimization Objective and Constraints – Result: SID list, OIF: 3, Binding-

SID: 30022

COMPUTE: minimize TE Metric to Node22 RESULT: SID list: OIF: to3

PCreq/reply

BSID: 30022


Dynamic VPN instantiation of SRTE policies 1.1.1.21/32; NH: PE22 Received label: L_VPN Community 100:777 B

GP

SRTE Policy to PE22: SID List {S0, S1, S2}, OIF 3 Binding Label: 30022 TE


Local label: 30022 OIF: SRTE; Label stack {L1, L2}

Dynamic VPN instantiation of SRTE policies • TE installs SRTE Policy in FIB: Binding-SID (e.g. 30022): push {label L1, label L2}

1.1.1.21/32; NH: PE22 Received label: L_VPN Community 100:777 B

GP

FIB



Dynamic VPN instantiation of SRTE policies • TE installs SRTE Policy in FIB: Binding-SID (e.g. 30022): push {label L1, label L2}

• TE provides the Binding-SID of the SRTE Policy to BGP – Also: SRTE Policy state and

interface handle

1.1.1.21/32; NH: PE22 Received label: L_VPN Community 100:777 Binding Label: 30022 B

GP

FIB





Dynamic VPN instantiation of SRTE policies • BGP installs best-path in FIB: – 1.1.1.21/32 via 30022 – Push VPN label and steer in

SRTE Policy

1.1.1.21/32; NH: PE22 Received label: L_VPN Community 100:777 Binding Label: 30022

1.1.1.21/32; recursion-via-segment label L_VPN, NH via 30022


BG

P FI

B


Demo


Demo – Conclusion •  In this demo you learned: • How SR ODN triggers automatic SRTE policies towards VPN next hops

• How SR ODN automatically enforces steering of traffic into these SRTE Policies without performance implications

• How an IOS XR device can be used as multi-domain stateful SR PCE

Thank you.

segment routing on demand sr next hop - cisco.com · segment routing on demand sr next hop bertrand...

Documents