Brkrst 3123 previdi-final

Segment Routing for IPv6
Networks
Stefano Previdi (sprevidi@cisco.com)
Distinguished Engineer
BRKRST-3123

• Introduction to Segment Routing
• Segment Routing and the IPv6 Source Routing Model
• IPv6 Segment Routing Header (SRH)
• SRH Procedures
• SR-IPv6 Examples
• Use Cases
• Standardization
• Conclusion
Agenda

Introduction to Segment
Routing

What is Segment Routing ?
• IPv6 and MPLS architecture that seeks the right balance between distributed
intelligence and centralized optimization and programming.
• simplifies operation (lower opex)
• enables application-based service creation (new revenue)
• allows for better utilization of the installed infrastructure (lower capex)
• An IPv6/MPLS architecture with wide application
• (SP, OTT/Web, GET) across (WAN, Metro/Agg, DC)
• MPLS and IPv6 dataplanes
• SDN controller
• An architecture designed with SDN in mind
• Segment Routing technology is extensively explained in
• http://www.segment-routing.net (includes all published IETF drafts)

Segment Routing
• Source Routing: the source chooses a path and encodes it in the packet header
as an ordered list of segments.
• SR-IPv6: list of segment is encoded into a new (and secure) Routing Header
• SR-MPLS: list of segments is represented by a label stack
• Segment: an identifier for any type of instruction
• Service
• Context
• Locator
• IGP-based forwarding construct
• BGP-based forwarding construct
• Local value or Global Index
• …
Segment = Instructions such as
"go to node N using the shortest path"

Segment Routing – Scalability and Virtualization
• Each engineered application flow is mapped on a path
• millions of paths
• A path is expressed as an ordered list of segments
• The network maintains segments
• thousands of segments
• completely independent of application size/frequency
• Excellent scaling and virtualization
• the application state is no longer within the router but
within the packet
Millions of
Application
flow paths
A path is
mapped on a
list of
segments
The network
only
maintains
segments
No per-flow
application
state

Segment Routing - Strong Operator Partnership
• Fundamental to the velocity and success
• Significant commitment
• technical transparency
• multi-vendor commitment
• beta and poc
• Many more operators now involved
• Segment Routing MPLS now standardized and (almost) deployed…
• Segment Routing IPv6 is getting up to speed
• Open and standardized technology
• More than 25 drafts under standardization process in IETF WGs:
• SPRING, 6MAN, IS-IS, IDR, OSPF, PCE
• For both MPLS and IPv6 dataplanes

Segment Routing and the
IPv6 Source Routing
Model

Segment Routing and the Source Based Routing Model
Wait a Moment !!
• There are two ways of using Segment Routing on v6 networks
• IPv6 control plane with a MPLS dataplane
• IPv6 control plane with a IPv6 dataplane
• This presentation covers Segment Routing for IPv6 control & data planes

• SR-IPv6 allows IPv6 dataplane networks to benefit from all features deployed
over the years on MPLS network:
• Traffic Engineering
• VPNs
• Fast Reroute
• Egress Peer Engineering
• …

Segment Routing IPv6 and the Source Based Routing Model
• Segment Routing:
• Source based routing model where the source chooses a path and encodes it in the
packet header as an ordered list of segments
• A new type of the existing IPv6 Routing Extension Header is used for Segment Routing:
SRH
• The Segment Routing Header (SRH) contains the list of segments
• Path state in the packet, not in the network
• A segment is an instruction applied to the packet:
• IGP-based forwarding construct
• BGP-based forwarding construct
• local adjacency
• service/application
• location,
• context, …
• Segment Routing leverages the source routing architecture defined in RFC2460 for IPv6

Example of Segments
• Examples:
• Go to this node using shortest path (Node-SID)
• Go to this prefix using shortest path (Prefix-SID)
• Go through this specific link (no matter what SPT says, Adj-SID)
• Go through this egress interface / peering AS (Adj-SID, Peer-SID)
• Etc.
• Simple protocol extensions allowing advertisement of segments
• IGP, BGP, BGPLS, PCEP, …
A B C
M N O
Z
D
P
Node segment to C
Node segment to Z
Adj Segment
Node segment to C Peer Segment
Peer Segment
1
2
S1
Service Segment to S1

• Segment Routing IPv6:
• The notion of a “segment” is not new in IPv6
• Routing Extension Header has been defined in RFC 2460 and defines the “segment”
• In both RFC 2460 and Segment Routing a segment is identified by an IPv6 address
• Segment Routing leverages RFC 2460 Routing Header by defining a new type
• Improves Routing Header
• Enhance the source routing model
• Introduces security
• Segment Routing does NOT require a forklift upgrade of the network
• SR and non-SR nodes can co-exist
• Gradual deployment
• Full interoperability
• Backward compatibility

Segment Routing Model
• How to express an explicit (source routed) path knowing that:
• Nodes may represent routers, hosts, servers, application instances, services, chains of
services, etc.
• A path is encoded into the packet by the originator (or ingress) node
• A path may be modified by a node within the path
• The network may have plurality of nodes not all supporting Segment Routing
• A path can be “loose” or “strict”
• Likely to be loose…
• A single mechanism, a single placeholder where the “path” of the packet is expressed

Segment Routing Model
• Assuming following topology:
– Node A has two shortest paths to C
• Q: How to best express path: [A, B, C, F, G, H]
• A: Source rooted path with segments: [C,F,H]
> First segment: set of shortest paths from A to C (ECMP aware)
> Second segment: adjacency/link from C to F
> Third segment: shortest path from F to H
• Loose Source Routing
HA
G
D
F
CB
E
HA
G
D
F
CB
E

Segment Routing Header
• At ingress:
– Path is computed or received by a controller (e.g.: SDN Controller)
– Path is instantiated through a list of segments
– A SRH is created with the segment list representing the path
– Packet is sent to the first segment
> ECMP fully leveraged !
X A
B
E
PAYLOAD
IPv6 Hdr: SA=X, DA=Y
C
IPv6 Hdr: SA=X, DA=C
SR Hdr: SL= C, F, H, Y
PAYLOAD
PAYLOAD

SRH (RH Type)
• Segment Routing Header:
– Segment List describes the path of the
packet: list of segments (IPv6 addresses)
– Segments Left: Defined in [RFC2460], it
contains the index, in the Segment List, of
the next segment to inspect. Segments Left
is decremented at each segment and it is
used as an index in the segment list
– HMAC
– Flags and optional policy information
• The Active Segment is set as the DA of the packet
– At each segment endpoint, the DA is updated with the next active segment found in the segment list
– Compliant with RFC2460 rules for the Routing Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Segment | Flags | HMAC Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[0] (128 bits ipv6 address) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List[n] (128 bits ipv6 address) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy List[0] (128 bits ipv6 address) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (256 bits, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SR-IPv6 Example
• Example:
– Classify packets coming from X and destined to Y and forward them across
A,B,C,F,G,H path
– Nodes A, C, F and H are SR capable
– Nodes B, E, D and G are plain ipv6 forwarders
X A
F
CB
E
Y
G
D
PAYLOAD
IPv6 Hdr: SA=X, SA=Y
PAYLOAD
H

SR-IPv6 Example
• At ingress, the Segment Routing Header (SRH) contains
– Segment List: C,F,H,Y (original destination address is encoded as last segment of the path)
– Segments Left: points to the next segment of the path (F)
– DA is set as the address of the first segment: C
• Packet is sent towards its DA (C, representing the first segment)
– Packet can travel across non SR nodes who will just ignore the SRH
– RFC2460 mandates only the node in the DA must examine the SRH
X A
F
CB
E
Y
G
D
PAYLOAD
H
IPv6 Hdr: SA=X, DA=C,
PAYLOAD

SR-IPv6 Example
• When packet reaches the segment endpoint C
– Segment Left is inspected and used in order to update the DA with the next segment address: F
– Segment Left pointer is decremented: now points to H
– Packet is sent towards its DA
X A
F
CB
E
Y
G
D
PAYLOAD
H
PAYLOAD
IPv6 Hdr: SA=X, DA=F
PAYLOAD

SR-IPv6 Example
• When packet reaches the segment endpoint F the same process is executed:
– Segments Left is inspected and used in order to update the DA with the next segment address: H
– Segments Left pointer is decremented: now points to Y (the original DA)
X A
F
CB
E
Y
G
D
H
IPv6 Hdr: SA=X, DA=H
PAYLOAD
PAYLOAD
IPv6 Hdr: SA=X, DA=Y IPv6 Hdr: SA=X, DA=C
PAYLOAD
PAYLOAD

SR-IPv6 Example
• When packet reaches the segment endpoint H:
– Segments Left is inspected and used in order to update the DA with the next segment address: Y
– A flag (cleanup-flag) in SRH tells H to cleanup the packet and remove the SRH
X A
F
CB
E
Y
G
D
H PAYLOAD
PAYLOAD
PAYLOAD
PAYLOAD
PAYLOAD

Segment Routing for IPv6 Dataplane
• Segment Routing for IPv6 Dataplane
– Defines SID as 128 bit IPv6 addresses
– Simple from a signaling perspective: no need to advertise
anything else than IPv6 prefixes (the prefix is the SID)
– Define a new Routing Extensions Header type
> Segment Routing Header (SRH)
> Contains Segment List

SRH (RH Type TBD) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Policy List[0] (optional, 128 bits ipv6 address) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// HMAC //
| (optional, 256 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Next Header: 8-bit selector. Identifies the type of header
immediately following the SRH
• Hdr Ext Len: 8-bit unsigned integer. Defines the length of the
SRH header in 8-octet units, not including the first 8 octets
• Type: TBD (SRH)
• Segments Left: index, in the Segment List, of the current active
segment in the SRH. Decremented at each segment endpoint.
• First Segment: offset in the SRH, not including the first 8 octets
and expressed in 16-octet units, pointing to the last element of
the Segment List (i.e.: that contains the first segment of the
path).
• Flags: 16 bits of flags. Following flags are defined:
– bit-0: cleanup
– bit-1: rerouted packet
– bits 2 and 3: reserved
– bits 4 to 15: policy flags. Define the type of the IPv6 addresses
encoded into the Policy List (each address is described by 3 bits):
> 0x0: Not present
> 0x1: ingress SR PE address
> 0x2: egress SR PE address
> 0x3: original source address

SRH (RH Type TBD)
• Segment List[n]: 128 bit IPv6 addresses representing
each segment of the path. The segment list is
encoded in the reverse order of the path: the last
segment is in the first position of the list and the first
segment is in the last position.
• Policy List[n]: Addresses representing specific nodes
in the SR path:
Ingress SR PE: IPv6 address representing the SR
node which has imposed the SRH
(SR domain ingress)
Egress SR PE: IPv6 address representing the egress
SR domain node
Original Source Address: IPv6 address originally
present in the SA field of the packet
• HMAC: SRH authentication (optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// HMAC //
| (optional, 256 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Segment Routing IPv6
• SRH is a new type of the existing routing header. Therefore, it inherits routing
header properties:
– Can only appear once
– If “Segments Left” is 0, the SRH is silently ignored and packet is NOT dropped
• SRH format is almost identical to RH0 that has been deprecated
– Carry ipv6 addresses
– Segments (SL and PL)
– Security: HMAC
• Deprecation has been motivated by security concerns
– SRH address them through HMAC and restricted domain of application
> BRKSEC-3200 Advanced IPv6 Security

Segment Routing Security
• Routing Type 0 (RH0) extension header has been deprecated by
RFC5095
• Reason: vulnerability (amplification attack) of RH0
• SRH defines an HMAC field to be used at ingress of a SR domain in
order to validate the SRH
• draft-vyncke-6man-segment-routing-security
• Avoid malicious attempts to steer a packet out of its intended path
• Amplification attack with RH-0
• Addresses concerns of RFC5095

Segment Routing Security
• When used within the boundaries of a controlled domain, the HMAC is
not necessary
• Similarly, IETF has standardized the Routing Extension Header type 3
(RPL) without any security mechanism
• RH3 is assumed to be used within the boundaries of a private/controlled domain

SRH Processing: Ingress Node
• Ingress node may be a SR capable host
• At ingress
– SRH is created (or received by an SDN controller) with:
> Segment List encoded in the reverse order of the path:
• Segment List[0]: LAST segment
• Segment List[n]: FIRST segment
> “Segments Left” field set to n-1 where n is the number of segments in the SL
> “First Segment” field is set to n-1
– The DA of the packet is set as the first segment of the path
> DA = Segment_List[Segments_Left]
– The packet is sent out to the first segment
X A
B
E
PAYLOAD
PAYLOAD

SRH Processing: Transit Node
• Different types of Transit Nodes
– NON-SR Transit nodes
– SR Intra-segment Transit nodes
– SR Segment Endpoint nodes

SRH Processing: Non-SR Transit Node
• NON-SR Transit nodes
– Plain IPv6 forwarding
– Solely based on IPv6 DA
– No SRH inspection or update
– Transparent / interoperable
X A
F
CB
E
Y
G
D
H PAYLOAD
PAYLOAD
PAYLOAD
PAYLOAD
PAYLOAD

SRH Processing: SR Intra Segment Transit Node
• Only nodes whose address is in DA inspects and process the SRH
(according to RFC2460)
• No difference with non-SR transit node
• A SR Intra-segment Transit node forwards SR packets according to
DA and SR FIB
– DA inspection
– SR FIB Lookup
– Forwarding

SRH Processing: SR Segment Endpoint nodes
• SR Endpoints: SR Capable nodes whose address is in DA.
• Endpoints inspects SHR and do:
1. IF DA = myself (segment endpoint)
2. IF Segments Left > 0 THEN
decrement Segments Left
update DA with Segment List[Segments Left]
3. IF Segments Left == 0 THEN
IF Clean-up bit is set THEN remove the SRH
4. ELSE give the packet to next PID (application)
End of processing.
5. Forward the packet out
X A
F
CB
E
Y
G
D
H PAYLOAD
PAYLOAD
PAYLOAD
PAYLOAD
PAYLOAD

SR-IPv6
• Example: packet enters into the SR domain and need to exit without SRH
Esid1
C
DHost
A
Server
Z
B
SR Domain
A/C
A/Z
A/ZA/D
A/Esid2
sid3
sid4

SR-IPv6
• Node B creates new SRH with Segment List
– Original destination address (Z) is the last segment
– The Segment List is encoded in the reverse order of the path: Z, E, D, C
– Segments_Left is set to 3 (number of elements in segment list – 1)
• DA = Segment_List[Segments_Left]
– DA = C
• Packet is sent out to C
Z (128 bits)
Next
Header
Hdr Ext
Len
Type Segments
Left(3)
E (128 bits)
D (128 bits)
C (128 bits)
Flags (clean)
Esid1
C
DHost
A
Server
Z
B
SR Domain
A/C

SR-IPv6
• Node C inspects SRH and does:
– Decrement Segments_Left by one (now: 2)
– DA = D
• Packet is sent out to D
Flags (clean)
Z (128 bits)
Next
Header
Hdr Ext
Len
Type Segments
Left(2)
E (128 bits)
D (128 bits)
C (128 bits)
E
C
DHost
A
Server
Z
B
SR Domain
A/D
sid2

SR-IPv6
• Node D inspects SRH and does:
– Decrement Segments_Left by one (now: 1)
– DA = E
• Packet is sent out to E
Flags (clean)
Z (128 bits)
Next
Header
Hdr Ext
Len
Type Segments
Left(1)
E (128 bits)
D (128 bits)
C (128 bits)
E
C
DHost
A
Server
Z
B
SR Domain
A/E
sid3

SR-IPv6
• Node E inspects SRH and does:
– Decrement Segments_Left by one (now: 0  LAST SEGMENT)
– DA = Z
• Check cleanup bit. If set, remove SRH
• Packet is sent out to Z after SRH has been removed
E
C
DHost
A
Server
Z
B
SR Domain
A/Z
sid4

Segment Routing Service Chaining
• Node connecting the service instance originates a Segment Identifier on behalf of
the service
• Node can be either virtual or physical (router or virtualized instance)
• Segment Identifiers to be known in ingress node
• Multiple APIs available: IGP/BGP protocols, NETCONF,
REST, OF, SNMP, …
• No burden on application
• No state per chain, one single state per service instance
• Same model applies to MPLS and IPv6 dataplanes
• Application remains SR unaware
C
S1
C and D advertise S1 and S2 as
Segment Identifiers for their
attached service instances
IngressA
Ingress classifies the flow and
apply the chain: S1, S2
S2
D

Segment Routing Service Chaining
NSH Integration
• Recently, IETF defined a proposal in order to carry Service Chains information
within a newly defined header
• Network Service Header, work in progress
• Segment Routing and NSH interoperates
• SR to define the service path as a list of segments
• NSH to identify the chain (path-id) and to carry metadata
• Mapping Segments into path-id’s is one option in the DC

SR-IPv6 Overlay
• With SR-capable service instances,
service chaining leverages the SRH
• Still interoperable with NSH
• No need to support SR across the network
• Transparent to network infrastructure
• Next Step: allow SR service chaining with non-SR applications…
• Work in progress
Service
Instance S1
X HA
G
D
F
CB
E
PAYLOAD
Service
Instance S2
Y
IPv6 Hdr: SA=X, DA=S1
SR Hdr: SL= S1, S2, Y
PAYLOAD
SR Hdr: SL= S1, S2, Y,
PAYLOAD
PAYLOAD
IPv6 Hdr: DA=Y, SA=X
PAYLOAD
PAYLOAD
PAYLOAD

SR-IPv6 Topology
Host VM1
db91::9
VPE2
db23::2
Host
VM2
db92::9
VPE4
db24::4
SR-App
db95::9
NON-SR-App
db96::9
VPE1
db91::1
VPE3
db13::3

SR-IPv6 Topology
Host VM1
db91::9
VPE2
db23::2
Host
VM2
db92::9
VPE4
db24::4
SR-App
db95::9
NON-SR-App
db96::9
IPv6 Hdr: SA=db91::9, DA=db92::9
SR Hdr: db96::9, db95::9, db92::9
PAYLOAD
SR Hdr: db96::9, db95::9, db92::9
PAYLOAD
PAYLOAD
VPE1
db91::1
VPE3
db13::3
SR Hdr: db96::9, db95::9, db92::9
PAYLOAD
SR Hdr: db96::9, db95::9, db92::9
PAYLOAD
PAYLOAD

Trace in VPE3 - incoming from NON-SR-app
- outgoing to VPE2 (transit)
00:01:11:983942: dpdk-input
GigabitEthernet0/b/0 rx queue 0
buffer 0x31180: current data 0, length 174, free-list 4, trace 0x12
00:01:11:983949: ip6-input
IPV6_ROUTE: db91::9 -> db92::9
00:01:11:983950: ip6-local
adjacency: local db96::3/64 flow hash: 0x00000000
00:01:11:983952: sr-local
SR-LOCAL: src db91::9 dst db95::9 len 160 next_index 1
next proto 58, len 56, type 4
next seg 1, last_seg 1, flags clean
db95::9
db92::9
db96::9
00:01:11:983956: ip6-rewrite
adjacency: GigabitEthernet0/4/0
00:01:11:983957: GigabitEthernet0/4/0-output
GigabitEthernet0/4/0
Host
VM1
db91::9
VPE1
db91
::1
VPE
3
db1
3::3
VPE2
db23:
:2
Host
VM2
db92::
9
VPE4
db24:
:4
SR-App
db95::9
NON-SR-App
db96::9
SR Hdr: db96::9, db95::9, db92::9
PAYLOAD
SR Hdr: db96::9, db95::9, db92::9
PAYLOAD

Disjoint TE Service
• A to Z any plane
• Set of IGP shortest paths to Z
• A to Z via blue plane
• Traffic Engineering policy:
• Set of shortest paths to BLUE (anycast IPv6 address/segment)
• Set of shortest paths to Z
• Benefits
• ECMP
• Traffic Engineering with no signaling
• Traffic Engineering with no midpoint state
IPv6 Hdr: SA=X, DA=Z
SR Hdr: SL= Z, Y
PAYLOAD
IPv6 Hdr: SA=X, DA=A
SR Hdr: SL= A, BLUE, Z, Y
PAYLOAD
1
2
Z
PE A
IPv6: BLUE IPv6: BLUE
IPv6: BLUE
IPv6: BLUE
PAYLOAD
PAYLOAD 1
2
Z
PE A
SR Hdr: SL= Z, Y
PAYLOAD
SR Hdr: SL= A, BLUE, Z, Y
PAYLOAD
PAYLOAD
PAYLOAD

TI-LFA: Automated 50-msec Protection for IGP Segments
• Guaranteed Link/Node FRR in any topology
• 50msec protection
• Simplicity
• Entirely automated
• No signaling
• No intermediate state
• Incremental deployment
• Applicable to all traffic
• Optimal backup path along post-convergence path
• Prevents transient congestion and suboptimal routing
• Repair path expressed as a list of segment and pre-installed in FIB

Latency TE Service
• Data from Tokyo to Brussels
• IGP shortest-path via US, higher and cheaper capacity
• Prefix-SID of Brussels
• Voice from Tokyo to Brussels
• SR TE policy uses one additional segment “Russia Anycast”
• Low-latency path
• Benefits
• ECMP
• Availability of the anycast segment against node failure
• No hop-by-hop signaling load and delay
• No midpoint state
Node segment to Brussels
SRH: Brussels
Data pkt
IPv6 Hdr
Node segment to Russia
SRH: Russia
Brussels
Voice pkt
IPv6 Hdr

AS1
AS2
AS3
Content producer engineers its WAN traffic to egress peers
AS4
B
C
D
E
Z
IGP SR-based
A
Best BGP
and IGP
Path
Engineered
Path
TE Policy
installed by
Controller
IPv6 Hdr: SA:X,
DA:B
SR Hdr: SL= B,Z
PAYLOAD
IPv6 Hdr: SA:X, DA:Z
PAYLOAD
IPv6 Hdr: SA:X, DA:CE
SR Hdr: SL= CE, Z
PAYLOAD
PAYLOAD

AS1
AS2
AS3
Content producer engineers its WAN traffic to egress peers
AS4
B
C
D
E
Z
IGP SR-based
A
Best BGP
and IGP
Path
Engineered
Path
TE Policy
installed by
Controller
IPv6 Hdr: SA:X,
DA:B
SR Hdr: SL= B,Z
PAYLOAD
PAYLOAD
IPv6 Hdr: SA:X, DA:CD
SR Hdr: SL= CD, Z
PAYLOAD
PAYLOAD

SR-IPv6 Egress Peer Engineer (SR-IPv6 EPE)
AS1
AS2
AS3
B
C
D
E
AS6
Z
IGP SR-based
A
Best BGP
and IGP
Path
Engineered Path
TE Policy
installed by
Controller Payload
SRH: CE, EG, Z
IPv6 Hdr: DA=CE
Engineered Path
AS5
F
AS4
G
Payload
SRH: CE, EG, Z
IPv6 Hdr: DA=EG
Payload
SRH: CE, EG, Z
IPv6 Hdr: DA=Z
Payload
IPv6 Hdr: DA=Z
Payload
IPv6 Hdr: DA=Z
Payload
IPv6 Hdr: DA=BD
Payload
IPv6 Hdr: DA=Z
Intra-AS EPE Inter-AS EPE Remote-AS EPE

IETF and Segment Routing
• Segment Routing architecture ~(data plane agnostic), use cases and
requirements are documented and discussed in SPRING WG
– More than 25 drafts have been produced
– Usual debate happened… now over
• Segment Routing is endorsed by the industry
– Multiple vendors have produced interoperable implementations of SR-MPLS already
– Segment Routing IPv6 implementation available VERY soon
• Protocol extensions (OSPF, ISIS, BGP, PCEP) are being standardized
in their respective WGs
• SR-IPv6 drafts are submitted in 6man
– draft-previdi-6man-segment-routing-header
– draft-evyncke-6man-segment-routing-security

Segment Routing Header IETF Drafts
• Segment Routing Header (SRH)
– draft-previdi-6man-segment-routing-header-06
• IPv6 SPRING Use Cases – aka: Segment Routing IPv6 Use Cases
– draft-ietf-spring-ipv6-use-cases-03
• IPv6 Segment Routing Header (SRH) Security Considerations
– draft-vyncke-6man-segment-routing-security-01

Summary
• IPv6/MPLS architecture that seeks the right balance between distributed
intelligence and centralized optimization and programming.
• simplifies operation (lower opex)
• enables application-based service creation (new revenue)
• allows for better utilization of the installed infrastructure (lower capex)
• An IPv6/MPLS architecture with wide application
• (SP, OTT/Web, GET) across (WAN, Metro/Agg, DC)
• MPLS and IPv6 dataplanes
• SDN controller
• An architecture designed with SDN in mind
• Segment Routing technology is extensively explained in
• http://www.segment-routing.net (includes all published IETF drafts)

Summary
• Segment Routing IPv6 implements the well known IPv6 Source Routing
model
• IPv6 source routing model is already integrated in RC2460 and Segment
Routing introduces minor changes through a new routing type header
• Segment Routing Header (SRH)
• Segment Routing is very flexible and interoperable with non-SR nodes
• A SR node can be a router, a server, any appliance, an application, …
• Segments are identified by IPv6 addresses

Get involved
• Majority of the Segment Routing use-cases are either FCS or beta available
• MPLS Dataplane
• SR-IPv6 implementations are available, PoC, lab demos
• Productization in progress…
• Get involved and provide ideas and requirements
• SR is operator driven: SP, OTT, Enterprise, … Join the club !
• Your help is key
• Pointers:
http://www.segment-routing.net
mailto:ask-segment-routing@cisco.com

Participate in the “My Favorite Speaker” Contest
• Promote your favorite speaker through Twitter and you could win $200 of Cisco
Press products (@CiscoPress)
• Send a tweet and include
• Your favorite speaker’s Twitter handle @StefanoPrevidi
• Two hashtags: #CLUS #MyFavoriteSpeaker
• You can submit an entry for more than one of your “favorite” speakers
• Don’t forget to follow @CiscoLive and @CiscoPress
• View the official rules at http://bit.ly/CLUSwin
Promote Your Favorite Speaker and You Could Be a Winner

Complete Your Online Session Evaluation
Don’t forget: Cisco Live sessions will be available
for viewing on-demand after the event at
CiscoLive.com/Online
• Give us your feedback to be
entered into a Daily Survey
Drawing. A daily winner
will receive a $750 Amazon
gift card.
• Complete your session surveys
though the Cisco Live mobile
app or your computer on
Cisco Live Connect.

Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Table Topics
• Meet the Engineer 1:1 meetings
• Related sessions

Brkrst 3123 previdi-final

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Brkrst 3123 previdi-final

Ähnlich wie Brkrst 3123 previdi-final (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Brkrst 3123 previdi-final