Segment Routing On Demand SR Next Hop. Bertrand Duvivier Principal Engineer CKN, March 29 th 2016

Transcription

1 Segment Routing On Demand SR Next Hop Bertrand Duvivier Principal Engineer CKN, March 29 th 2016

2 (from next slide) 2

3 Network Bandwidth demand in SP s Network demand double every 18 months Compute demand double every 24 months Network Compute Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 Year 9 Year

4 Impact on network design Bigger routers: 100G Multi-Chassis Hardware bandwidth double every 3-4 years More routers: Access DC MAN WAN Limited amount of router per IGP domain Resulting in insertion of additional domain s Example: MAN between WAN, DC and Access Access NY region DC Seamless services: DC, WAN, MAN, Aggregation, Access 4

5 METRO architecture changes WAN WAN P P P P Leaf Leaf Leaf Leaf Man Fabric PE PE Access Peering DCI DCI PE PE CDN NfV Access Peering DC DC 5

6 MAN fabric & traffic flows P WAN P CLOS architecture (2, 3 or 4 layers) 100G Large ECMP Heavy use of CDN Leaf DCI CDN DC Leaf Leaf Leaf DCI PE PE NfV Access Peering DC North-South! 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. East-West 6

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

8 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 8

9 Segment Routing Traffic Engineering: Keep it simple via innovation On Demand Next Hop BGP SR-TE dynamic HA with IOS-XR PCE SR controller 9

10 On demand SR Next Hop Tail-f NSO controller Hint: 1. PCE collect topology and SID via BGP LS PCE controller BGP Route Reflector BGP Link State Unicast-SID Unicast-SID Unicast-SID Anycast-SID Anycast-SID Unicast-SID ToR1 ABR1 ABR3 AC1 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast-SID Anycast-SID Unicast-SID Anycast-SID Unicast-SID

11 On demand SR Next Hop Tail-f NSO controller PCE controller Hint: 1. PCE collect topology and SID via BGP LS 2. NSO to configure service XML YANG: - PW-123 from ToR1 to AC1 BGP Route Reflector XML YANG: - PW-123 from AC1 to ToR1 Unicast-SID Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID ToR1 ABR1 ABR3 AC1 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

12 On demand SR Next Hop Do I have LSP to AC1? Tail-f NSO controller PCE controller BGP Route Reflector 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 Unicast-SID Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID ToR1 ABR1 ABR3 AC1 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

13 On demand SR Next Hop PCEP request - Could you provide me the ERO to reach AC1? Tail-f NSO controller PCE controller BGP Route Reflector 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 Unicast-SID PCEP reply - ERO is: 18001,18002,16001 Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID ToR1 3 ABR1 ABR3 AC1 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

14 On demand SR Next Hop XML YANG notification: - PW-123 is UP Tail-f NSO controller PCE controller BGP Route Reflector 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 Unicast-SID Unicast-SID Unicast-SID Anycast-SID Anycast-SID Unicast-SID Ethernet ToR1 ABR1 ABR3 AC1 Etherne DC WAN Access Ethernet PW Ethernet PW Ethernet PW ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast-SID Anycast-SID Unicast-SID Anycast-SID Unicast-SID

15 ODN with policy Tail-f NSO controller PCE controller Hint: 1. PCE collect topology and SID via BGP LS 2. NSO to configure service XML YANG: - PW-123 from ToR1 to AC1 - Policy: Low Latency BGP Route Reflector XML YANG: - PW-123 from AC1 to ToR1 - Policy: Low Latency Unicast-SID Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID ToR1 ABR1 ABR3 AC1 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

16 ODN with policy PCEP request - Could you provide me the ERO to reach AC1? - Policies are Low Latency Tail-f NSO controller PCE controller BGP Route Reflector 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 1 2 PCEP reply - ERO is: 17001,17003,16001 Unicast-SID Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID ToR1 3 ABR1 ABR3 AC1 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

17 On demand steering for BGP services Technical name: BGP SR-TE dynamic Tail-f NSO controller PCE controller Hint: 1. CPE send BGP update for prefix X and add LL community ex: 100:333 BGP Route Reflector Unicast-SID Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID NLRI: X Community: LL CPE1 ToR1 ABR1 ABR3 AC1 CPE2 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

18 On demand steering for BGP services Technical name: BGP SR-TE dynamic Tail-f NSO controller PCE controller BGP Route Reflector Hint: 1. CPE send BGP update for prefix X and add LL community 2. AC1 PE announce VPN prefix X with LL community NLRI: VPN_X Community: LL Unicast-SID Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID CPE1 ToR1 ABR1 ABR3 AC1 CPE2 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

19 On demand steering for BGP services Technical name: BGP SR-TE dynamic PCEP request - Could you provide me the ERO to reach AC1? - Policy is Low Latency Tail-f NSO controller PCE controller BGP Route Reflector Hint: 1. CPE send BGP update for prefix X and 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 Unicast-SID PCEP reply - ERO is: 17001,17003,16001 Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID CPE1 ToR1 3 ABR1 ABR3 AC1 CPE2 DC WAN Access ToR2 ABR2 ABR4 AC2 Unicast-SID Unicast SID Anycast SID Unicast SID Anycast SID Unicast-SID

20 ODN HA model IOS-XR PCE SR controller Coming soon Tail-f NSO controller Tail-f NSO controller Hint: Hint: 1. NSO Collect and topology provisioning and SID centralized via BGP and LS 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. CPE1 Unicast-SID ToR1 ToR2 Unicast-SID Unicast SID Unicast SID Anycast SID Anycast SID Unicast-SID PCE ABR1 RR DC WAN Access PCE ABR2 RR Unicast SID Anycast SID PCE PCE ABR3 RR PCE ABR4 RR Unicast SID Anycast SID AC1 AC2 Unicast-SID CPE2 20

21 Platform s supporting SR IOS XR IOS classic NexOS Linux NCS5000 NCS6000 CRS-3 / CRS-X ASR9000 NCS5500 ASR900 CSR1000v XRV-9000 ASR1000 / ISR400 / cbr8 NEXUS 9000 FD.io 2013 Cisco and/or its affiliates. All rights reserved. 21 Cisco Confidential 21

22 Thank you.

23 Segment Routing On-Demand Next-Hop (ODN) Demonstration Kris Michielsen

24 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 24

25 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 25

26 Reference Topology Router-id of NodeX: 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 26

27 Reference Topology SR: Segment Routing Domain 1 IS-IS / SR Domain 2 IS-IS / SR Router-id of NodeX: 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 27

28 Demo Components SR PCE SR: Segment Routing PCE: Path Computation Element PCC: Path Computation Client 3 PCC 5 PCC PCC 9 PCC 23 Domain 1 IS-IS / SR Domain 2 IS-IS / SR 28

29 Demo Components SR PCE SR: Segment Routing PCE: Path Computation Element BGP-LS: BGP Link-state BGP-LS Domain 1 IS-IS / SR Domain 2 IS-IS / SR 29

30 Demo Components SR PCE SR: Segment Routing PCE: Path Computation Element PCEP: PCE Protocol PCEP PCEP 3 PCEP 5 PCEP Domain 1 IS-IS / SR Domain 2 IS-IS / SR 30

31 Demo Components RR RR: Route Reflector 3 BGP BGP 5 22 BGP BGP Domain 1 IS-IS / SR Domain 2 IS-IS / SR 31

32 Dynamic VPN instantiation of SRTE policies CE21 advertises prefixes to PE BGP: /32, via

33 Dynamic VPN instantiation of SRTE policies CE21 advertises prefixes to PE PE22 checks its policy and finds that /32 must receive low latency service MAP: /32 in vrf must receive low latency service " tag with community (100:777) BGP: /32, via

34 Dynamic VPN instantiation of SRTE policies CE21 advertises prefixes to PE PE22 checks its policy and finds that /32 must receive low latency service PE22 tags /32 with a BGP community (e.g. 100:777) and sends to RR11 MAP: /32 in vrf must receive low latency service " tag with community (100:777) BGP: /32, via

35 Dynamic VPN instantiation of SRTE policies CE21 advertises prefixes to PE PE22 checks its policy and finds that /32 must receive low latency service PE22 tags /32 with a BGP community (e.g. 100:777) and sends to RR11 RR11 sends to PE3 MAP: /32 in vrf must receive low latency service " tag with community (100:777) BGP: /32, via 21 35

36 Dynamic VPN instantiation of SRTE policies PE3 checks its policy and finds it must use a path to BGP NH (PE22) with optimized TE Metric 1 A TE attributeset defines constrains and computation requirements (e.g. attr-set LTCY ) MAP: Community (100:777) means minimize TE Metric and compute at PCE TE metric is used here to express link latency

37 Dynamic VPN instantiation of SRTE policies PCC 3 requests a path towards (22) from PCE (10) COMPUTE: minimize TE Metric to Node22 PCreq/reply

38 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: PCreq/reply BSID: COMPUTE: minimize TE Metric to Node22 RESULT: SID list: OIF: to

39 Dynamic VPN instantiation of SRTE policies BGP /32; NH: PE22 Received label: L_VPN Community 100:777 TE SRTE Policy to PE22: SID List {S0, S1, S2}, OIF 3 Binding Label:

40 Dynamic VPN instantiation of SRTE policies TE installs SRTE Policy in FIB: Binding-SID (e.g ): push {label L1, label L2} BGP TE /32; NH: PE22 Received label: L_VPN Community 100:777 SRTE Policy to PE22: SID List {S0, S1, S2}, OIF 3 Binding Label: FIB Local label: OIF: SRTE; Label stack {L1, L2} 40

41 Dynamic VPN instantiation of SRTE policies TE installs SRTE Policy in FIB: Binding-SID (e.g ): push {label L1, label L2} TE provides the Binding-SID of the SRTE Policy to BGP Also: SRTE Policy state and interface handle BGP TE FIB /32; NH: PE22 Received label: L_VPN Community 100:777 Binding Label: SRTE Policy to PE22: SID List {S0, S1, S2}, OIF 3 Binding Label: Local label: OIF: SRTE; Label stack {L1, L2} 41

42 Dynamic VPN instantiation of SRTE policies BGP installs best-path in FIB: /32 via Push VPN label and steer in SRTE Policy BGP TE /32; NH: PE22 Received label: L_VPN Community 100:777 Binding Label: SRTE Policy to PE22: SID List {S0, S1, S2}, OIF 3 Binding Label: FIB /32; recursion-via-segment label L_VPN, NH via Local label: OIF: SRTE; Label stack {L1, L2} 42

43 Demo 43

44 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 44

45 Thank you.