1 IETF-88 Vancouver, November 2013 Segment Routing Use Cases • Generic SR Use Cases – draft-filsfils-rtgwg-segment-routing-use-cases-02.txt • SR/LDP Interoperability – draft-filsfils-spring-segment-routing-ldp-interop-00.txt • OAM – draft-geib-spring-oam-usecase-00.txt • To be published: – FRR: draft-francois-segment-routing-resiliency-use-cases – Service Chaining – SR for IPv6 • Many authors of different drafts – and even more contributors… C. Filsfils S. Previdi Cisco Systems, Inc. P.Francois IMDEA Networks B. Decraene S. Litkowski Orange M. Horneffer R. Geib Deutsche Telekom I. Milojevic Telekom Srbija R. Shakir British Telecom S. Ytti TDC Oy W. Henderickx Alcatel-Lucent J. Tantsura S.Kini Ericsson E. Crabbe Google, Inc.
10
Embed
C. Filsfils Segment Routing Use Cases Cisco Systems, Inc. · PDF fileCoS-based Traffic Engineering 4.1.2 ... – Data and UK: push the node segment to UK ... 2G from A to Z please
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1 IETF-88 Vancouver, November 2013
Segment Routing Use Cases
• Generic SR Use Cases – draft-filsfils-rtgwg-segment-routing-use-cases-02.txt
• Simplification – no complex LDP/ISIS synchronization to troubleshoot – one less protocol to operate
• IPv6 over MPLS can be deployed directly with SR – no need for LDPv6
A B
M N
PE2 PE1
All VPN services ride on the node segment to PE2
4 IETF-88 Vancouver, November 2013
CoS-based TE
• Japan to UK – data: via US, cheap capacity
– voip: via Asia, low latency
• CoS-based TE with SR – IGP metric set such as > Japan to Asia: via Asia
> Japan to UK: via US
> Asia to UK: via Europe
– Anycast segment “Asia” advertised by Asia core routers
• Tokyo CoS-based policy – Data and UK: push the node segment to UK
– VoIP and UK: push the anycast node to Asia, push UK
Node segment to UK
Node segment to Asia
5 IETF-88 Vancouver, November 2013
• A sends traffic with [65] Classic ecmp “a la IP”
• A sends traffic with [111, 65] Packet gets attracted in blue plane and then uses classic ecmp “a la IP”
SR avoids state in the core
SR avoids enumerating RSVP-TE tunnels for each
ECMP paths
6 IETF-88 Vancouver, November 2013
Engineer traffic towards egress peers
A
B C
D
E
Z
AS1
AS2
AS3
AS4
• Ingress border routers control how their traffic is balanced between peers
– Overriding BGP decision at egress border
7 IETF-88 Vancouver, November 2013
Local Service Segment
• 72, 78, 65: global segments representing the shortest-path respectively to C, O and Z
• 9001: local segment to C representing a local service S1
• 9002: local segment to O representing a local service S2
• Ingress node A enforces a source route of forwarding and service instructions on flow F by appending the SR list {72, 9001, 78, 9002, 65} on its packets
• 9001 and 9002 represent local services
A B C
M N O
Z
D
P
65 78
72
65
9001
Service S1
Service S2
9002
8 IETF-88 Vancouver, November 2013
Application controls – network delivers
• The network is simple, highly programmable and responsive to rapid changes
– perfect support for centralized optimization efficiency, if required
2G from A to Z please
Link CD is full, I cannot use the shortest-path 65 straight to Z
65 FULL
65
9 IETF-88 Vancouver, November 2013
Application controls – network delivers
• The network is simple, highly programmable and responsive to rapid changes
Path ABCOPZ is ok. I account the BW. Then I steer the traffic on this path