Segment Routing - Interdomain traffic engineering using SR PCE with Lab

demo

Parag Sharma
Solutions Architect
Agenda
 SR Policy Building Blocks
 On-Demand Next hop (Single and Multidomain)
 SR-PCE
 SR-PCE Path Computation Flow
 SR-PCE Distributed Design
 LAB Use cases
SR Policy
SR Policy Identification
• An SR Policy is uniquely identified by a tuple
(head-end, color, end-point)
Head-end: where the SR Policy is instantiated (implemented)
Color: a numerical value to differentiate multiple SRTE Policies between the
same pair of nodes
End-point: the destination of the SR Policy
• At a given head-end, an SR
SR Policy
Policy
SR Policy is uniquely identified (1,
(1, green,
green, 4)
4)
2 3 4
by a tuple (color, end-point) Head-end:
Head-end: 11
Color:
Color: green
green 1
End-point:
End-point: 44
7 6 5
SR Policy – Candidate Paths
• An SR Policy consists of one or more candidate paths (Cpaths)
SR Policy Cpath11

Cpath22 Candidate
... Paths

Cpathnn
• An SR Policy instantiates one single path in RIB/FIB
• the selected* path, which is the preferred valid candidate path
• A candidate path is either dynamic or explicit

* See further.
SR-Policy – Candidate path …cont
SID-list
SID-list1111
<16003,
<16003,
16004>
16004>

VALID
SR
SR Policy
Policy Cpath
Cpath11 Weight
Weight 11
(( Head,
Head, Color,
Color, End
End )) Pref
Pref 110
110 SID-list
SID-list1212
<16004>
<16004>
Provided by
Weight
Weight 44 e.g. local configuration

SID-list
SID-list2121

VALID
Cpath
Cpath22
<16004>
<16004>
Pref
Pref 100
100

✔
SID-list
SID-list3131
Provided by
VALID
Cpath
Cpath33 <16005,
<16005,
Pref
Pref 200
200
16004>
16004> e.g. Dynamic SRTE
Weighted ECMP (WECMP)
• If a set of SID-lists is associated with the selected path of the SR Policy,
then the steering is flow and WECMP-based according to the relative
weight of each SID-list
SID-list
SID-list11:: 1/5
<16003,
<16003, of load
16004>
16004>
2
20
3 W e ight x
10GE

å W e ighti
Weight
Weight 11
Selected
Selected
SR
SR Policy
Policy Path
Path 1 4
i=1...n
SID-list
SID-list22:: 40GE
<16004>
<16004> 4/5 6 5
Weight
Weight 44 of load
Default link metric: 10
Binding-SID is fundamental to SR
• The Binding-SID is fundamental to SR, it provides scaling, network
opacity and service independence
• Use of BSID decreases the number of segments imposed by the source
• A BSID acts as a stable anchor point that isolates one domain from the churn
of another domain
• A BSID provides opacity and independence between domains
Binding-SID (BSID)
• The BSID of the SR Policy selected path is installed in the forwarding
table
• Remote steering
• A packet arriving on the SR Policy head-end with
the BSID as Active Segment (top of label stack) is BSID SID-list
steered into the SR Policy associated with the BSID
• Local steering
• A packet that matches a forwarding entry that Prefix
resolves on the BSID of an SR Policy is steered
into that SR Policy
BSID SID-list
Active SR Policy – FIB entry
20
2 10GE
3
Selected SID-list:
SID-list:
Selected
SR
SR Policy
Policy Path
Path
<16003,
<16003, 1 4
16004>
16004>
BSID:
BSID: 40GE
40104
40104 6 5
Default link metric: 10

Forwarding table on Node1

In Out Out_intf Fraction

40104 <16003, 16004> To Node2 100%

Constraints
• The following constraints can be specified:
• Include and/or exclude TE affinity
• Include and/or exclude IP address
• Include and/or exclude SRLG
• Maximum accumulated metric (IGP, TE, and delay)
• Maximum number of SIDs in the solution SID-list
• Disjoint from another SR Policy in the same association group
SR Policy – configuration example
On Node1:
segment-routing !
traffic-eng preference 200
policy POLICY1 explicit segment-list SIDLIST1
color 20 end-point ipv4 1.1.1.4 !
binding-sid mpls 1000 segment-list name SIDLIST1
candidate-paths index 10 mpls label 16002
preference 100 Path index 20 mpls label 30203
Path preference
preference 100
100
➊ dynamic
metric type te
index 30 mpls label 16004
20
Dynamic
Dynamic path
path
constraints
affinity ➋ 2 3
exclude-any color red Opt.
Opt. Obj.:
Obj.: TE
TE metric
metric
Constraint
1 4
Constraint
Path
Path preference
preference 200
200
➊ 6 5
➋
Explicit
Explicit SID-list1
SID-list1 Default link metric: 10

segment-routing
traffic-eng
SID-list1
SID-list1 affinity-map
color red bit-position 0
On-Demand Nexthop (ODN)
On-Demand Nexthop
• A service head-end automatically instantiates an SR Policy to a BGP
next-hop when required (on-demand)
• Color community is used as SLA indicator
• Reminder: an SR Policy is defined (color, end-point)

BGP Color BGP

Community Next-hop
• Automated Steering (AS) automatically steers the BGP traffic into this
SR Policy, also based on nexthop and color
On-demand SR Policy
• Configure an SR Policy template for each color for which on-demand
SR Policy instantiation is desired
• An example with two color templates configured:
• color 10 for high bandwidth (optimize IGP metric)
• color 20 for low-delay (optimize link-delay metric)
segment-routing
segment-routing
traffic-eng
traffic-eng
on-demand
on-demand color
color 10
10
dynamic SR
dynamic
metric
SR Policy
Policy template
template High-
High-
metric type
type igp
igp BW
!! BW (color
(color 10)
10)
on-demand
on-demand color
color 20
20
dynamic SR
dynamic
metric
SR Policy
Policy template
template low-
low-
metric type
type delay
delay delay
delay (color
(color 20)
20)
On-demand SR Policy
• If an SR Policy template exists for color C, then a route with color C
can trigger an on-demand SR Policy candidate path instantiation to its
next-hop N, for any N
• The end-points for which an on-demand SR Policy candidate path will
be instantiated can be restricted per color
• Example configuration: only ipv4
ipv4 access-list
access-list ACL1
ACL1
10
10 permit
permit ipv4
ipv4 host
host 1.1.1.10
1.1.1.10 any
any
instantiate color 10 SR Policies 20
20 permit ipv4 host 1.1.1.11 any
permit ipv4 host 1.1.1.11 any
!!
for end-points 1.1.1.10 and segment-routing
segment-routing
1.1.1.11 traffic-eng
traffic-eng
on-demand color 10
on-demand color 10
restrict
restrict ACL1
ACL1
dynamic
dynamic
metric
metric type
type delay
delay
On-demand SR Policy work-flow
➎
➌ BGP: 20/8 via PE4
router
router bgpbgp 1
1
neighbor 1.1.1.10 VPN-LABEL: 99999
neighbor 1.1.1.10
Low-delay (color 20) ➋ BGP: 20/8 via PE4
address-family
address-family vpnv4
vpnv4 unicast
unicast RR VPN-LABEL: 99999
!! SR
segment-routing SR Policy
Policy template
template Low-
Low- Low-delay (color 20)
segment-routing delay
traffic-eng
traffic-eng
delay (color
(color 20)
20)
on-demand
on-demand color
color 20
20 ➍ PE4 with Low-delay
dynamic (color 20)? I: 50 ➊ BGP: 20/8 via CE
dynamic
metric
metric
2 4
➎ use template
type
type delay
delay
color 20 1 CE 20/8
➏  SID-list D: 15
<16002, 30204>
6 5

Default IGP cost: I:10

Default link-delay: D:10
Automated performant steering
➐➑ ➌ BGP: 20/8 via PE4
FIB table at PE1 VPN-LABEL: 99999
➋ BGP: 20/8 via PE4
BGP: 20/8 via 4001 Low-delay (color 20)
RR VPN-LABEL: 99999
SRTE: 4001: Push <16002, 30204> Low-delay (color 20)

Low delay to PE4

➍ PE4 with Low-delay
(color 20)? ➐ I: 50 ➊ BGP: 20/8 via CE
2 4
Automatically, the service route resolves ➎ use template
on the Binding-SID (4001) of the SR color 20 1 CE 20/8
Policy it requires ➏  SID-list D: 15
<16002, 30204>
6 5
Simplicity and Performance
➐ instantiate
SR Policy Default IGP cost: I:10
No complex PBR to configure, no PBR BSID 4001 Default link-delay: D:10
performance tax ➑ forward 20/8
via BSID 4001
Multi-domain
On-Demand Nexthop
(ODN)
On-Demand Nexthop – multi-domain
• On-demand Nexthop automatically provides inter-domain best-effort
reachability and inter-domain reachability with SLA
• Head-end uses SR PCE to automatically provide an SR Policy path to
the remote domain destination when needed (On-demand)
• Scaling benefit
• On-Demand Nexthop: on-demand pull model
• Classic inter-domain reachability uses a push model
• Think of a large-scale aggregation with 100k access nodes where each such
node only needs to talk to 10’s of other nodes
On-Demand Nexthop reachability
➎ ➌ BGP: 20/8 via PE3 ➋ BGP: 20/8 via PE3
VPN-LABEL: 99999 VPN-LABEL: 99999
router
router bgpbgp 11
neighbor 1.1.1.10 Best-effort (color 10) Best-effort (color 10)
neighbor 1.1.1.10 RR
address-family
address-family vpnv4
vpnv4 unicast
unicast
!! SR
segment-routing SR Policy
Policy template
template Best-
Best- ➏ to PE4 SR
segment-routing effort PCE
traffic-eng
traffic-eng
effort (color
(color 10)
10) with lowest
on-demand IGP metric? ➐  SID-list
on-demand color
color 10
10 ➊ BGP:
dynamic <16002, 16003>
dynamic 20/8 via CE
pcep
pcep ➍ PE4 with Best-effort
metric
metric (color 10)? 1 I:100 2 I:100 3
type
type igp
!!
igp ➎ use template CE
on-demand
on-demand color
color 20
20
color 10 5 4 20/8
dynamic
dynamic
pcep
pcep 6 I:100 7 I:100 8
metric
metric
type
type delay
delay Default IGP link metric: I:10
Default link-delay metric: D:10
On-Demand Nexthop reachability
➌ BGP: 20/8 via PE3 ➋ BGP: 20/8 via PE3
➑➒ VPN-LABEL: 99999 VPN-LABEL: 99999
FIB table at PE1 Best-effort (color 10) Best-effort (color 10)
BGP: 20/8 via 4002 RR
SRTE: 4002: Push <16002, 16003> ➏ to PE4 SR
with lowest PCE
IGP metric? ➐  SID-list
➊ BGP:
<16002, 16003> Best-effort 20/8 via CE
➍ PE4 with Best- to PE3
Automatically, the service route resolves 3
effort (color 10)? 1 ➑ I:100 2 I:100
on the Binding SID (4002) of the SR Policy
it requires ➎ use template CE
color 10 5 4 20/8
➑ instantiate
Simplicity and Performance
SR Policy 6 I:100 7 I:100 8
BSID 4002
➒ forward 20/8 Default IGP link metric: I:10
via BSID 4002 Default link-delay metric: D:10
Benefits
• Scalable – PE1 only gets the inter-domain paths that it needs
• Simple – no BGP3107 pushing all routes everywhere
• No complex steering configuration
• Automated steering of BGP routes on the right SLA path
• Data plane performant
SR PCE
SR Path Computation Element (SR PCE)
• SR PCE is an IOS XR multi-domain stateful SR-optimized PCE
• IOS XR: SR PCE functionality is available on any physical or virtual IOS XR
node, activated with a single configuration command
• 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
• SR-optimized: native SR-optimized computation algorithms
• SR PCE is fundamentally distributed
• Not a single all-overseeing entity (“god box”), but distributed across the
network; RR-alike deployment
SR Path Computation Element (SR-PCE)
SRTE Head-End

Distributed Mode – SR-TE Head-End APP APP APP

Visibility is limited to its own IGP domain

Single / REST API Native SR

Solution Multi-Domain algorithms
Topology
Multi-Domain SRTE Visibility
Centralized/Distributed SR-PCE for Multi-Domain
Topo
Topology view Compute
Integration with Applications
DB
SR-PCE runs on
North-bound APIs for topology/deployment virtual or physical
IOS-XR node

Delivers across the unified SR Fabric the SLA requested by the Collect Deploy
service PCEP
IGP
BGP-LS
Benefits BGP

Simplicity and Automation

Access Metro Core Metro Data Center
End-to-End network topology awareness
SLA-aware path computation across network domains
1 2 3 4
Aggregation

© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Confidential
BGP-LS Overview
• Optimal Path Computation for Multi-area TE PCE
Traffic
Engineering
Databse (TED)
• Solution is BGP, not IGP.
• BGP-LS is an address-family
• afi=16388, safi=71
BGP-LS

• Defined to carry IGP link-state database via BGP Domain 0 RR

• Supports both IS-IS and OSPF
BGP-LS
• Delivers topology information to outside BGP-LS

agents
Domain 1 Domain 2
 SR PCE and Multi-domain
• When advertising multiple topologies/domains in BGP-LS, each
topology/domain must have a unique instance-id
• Instance-id identifies a “routing universe”
• Default: 0 – Value range ISIS: <2-65535>; OSPF: <0-4294967295>
• Values 1-31 should not be used
• RFC7752: Values in the range 32 to 264-1 are for "Private Use"
For example, on the BGP-LS node in Domain1:
router isis Domain1 distribute link-state instance-id 32

For example, on the BGP-LS node in Domain2: Unique instance-id

router isis Domain2 distribute link-state instance-id 33
SR PCE Path Computation
Flow
 Request/Reply/Report workflow A
• ➊ Node1 is configured to instantiate a low- A single
single centralized
centralized
SR
SR PCE
PCE node
node to
to
delay SR Policy to Node3, e.g. by Network SR simplify
simplify illustration
illustration
Service Orchestrator (NSO), or a human PCE
operator
• Since the end-point Node3 is in a remote
domain, Node1 cannot compute the dynamic
path locally and must use SR PCE 1 I:100
2 I:100
3
➊ low-delay to 3 ?

5 74

6 I:100
7 I:100
8
Domain1 Domain2

Default IGP link metric: I:10 PCEP

Default link-delay metric: D:10
 Request/Reply/Report workflow (Cont.) ➋ PCReq “to 3”,
• ➋ Node1 sends a PCEP Path Computation “TE metric”
➌  SID-list
Request (PCReq) to SR PCE, requesting path SR
<30102, 30203>
“to Node3” with “Optimize TE metric” ➍ PCRepl PCE
“SID-list <30102, 30203>”
• ➌ SR PCE stores the request and computes a
TE metric shortest-path from Node1 to Node3,
say the resulting SID list is <30102, 30203>
1 2 3
• ➍ PCE sends “SID list <30102, 30203>” to ➊ I:100 I:100

Node1 in PCEP Path Computation Reply

(PCRepl) 5 74

6 I:100
7 I:100
8
Domain1 Domain2

Default IGP link metric: I:10 PCEP

Default link-delay metric: D:10
 Request/Reply/Report workflow (Cont.)
• ➎ Node1 allocates a BSID 4001 and activates
the SR Policy path to Node3 via <30102, ➋
SR ➌
30203> ➍ PCE

• and ➏ sends Path Computation Report (PCRpt)

➏ PCRept
to SR PCE, delegating the SR Policy to SR PCE “BSID 4001”, “delegate”
and including BSID
➊
1 I:100
2 I:100
3
➎ SID-list:
<30102, 30203>
FIB table at Node1
SRTE: 4001: Push <30102, 30203> 5 74
BSID
6 I:100
7 I:100
8
Domain1 Domain2

Default IGP link metric: I:10 PCEP

Default link-delay metric: D:10
Decouple overlay/underlay
• The Request/Reply model separates the service creation and
maintenance (overlay) from the topology and path maintenance
(underlay)
• NSO (Overlay Controller) does not need to be aware of the topology
• SR PCE (Underlay Controller) is not aware of the service, SR Policy and traffic
steering configuration
• NSO does not need to interact directly with SR PCE;
Overlay Controller is decoupled from Underlay Controller
Inter PCE State Sync
• PCE is required to compute two (perhaps more in the future) disjoint paths originating from
different PCCs. Typically, a PCC I connected to more than one PCEs for redundancy reasons. In this
case, a given path is computed by one and only one PCE (chosen by PCC). However, a PCC reports
computed paths to all PCEs, and hence all PCEs have the up-to-date view of paths.
• It is possible that a PCC can be connected to a single PCE (either due to network design or
network failure). In this case, a PCE that is not connected to a PCC may not have the knowledge of
paths originating from that PCC and hence cannot accurately compute disjoint paths when a path
originates from that PCC.
• To solve the above problem, we allow a PCE to report paths (reported by a PCC) to another PCE.
We call such reporting “inter-PCE state-sync
 Inter PCE State Sync..cont
• A PCE is able to identify whether a PCRpt is from
a PCC or PCE (i.e., due to inter-PCE state-sync).
This is possible due to inclusion of a private Cisco
PCE-1 PCRpt PCE-2
specific TLV in PCRpt message generated by a PCEP
PCE. session

• If a PCE receives PCRpts from PCC and PCE, the

PCRpt
latter is discarded. PCRpt
• A PCE reports only the delegated paths to
another PCE. PCC
• While computing disjoint paths, a PCE cannot
modify a path learned from another PCE.
 Stateful – SR PCE updates path
SR PCE stores path computation requests (stateful) ➌  SID-list
<30102, 16003>
SR
➍ PCUpd PCE
➋ BGP-LS update
“SID-list <30102, 16003>”
• ➊ A topology change occurs in Domain2
• TI-LFA protects traffic within 50ms
• ➋ BGP-LS pushes the topology change to SR 1 2 1 3
I:100 I:100
PCE
• ➌ SR PCE re-computes path; the new SID-list is
<30102, 16003> 5 74
• ➍ SR PCE sends PCUpd message with “SID list
<30102, 16003>” to Node1 6 7 8
I:100 I:100
Domain1 Domain2

Default IGP link metric: I:10 PCEP

Default link-delay metric: D:10 BGP-LS
 Stateful – SR PCE updates path
• ➎ Node1 updates SR Policy Path via <30102,
16003>, maintaining the BSID 4001 ➌
SR
PCE
• and ➏ sends Path Computation Report (PCRpt) ➍
➋
to SR PCE, delegating the SR Policy to SR PCE ➏ PCRept
and including BSID “BSID 4001”, “delegate”

1 I:100
2 1
I:100
3
➎ SID-list:
<30102, 16003>
FIB table at Node1
SRTE: 4001: Push <30102, 16003>
30203> 5 74
BSID
6 I:100
7 I:100
8
Domain1 Domain2

Default IGP link metric: I:10 PCEP

Default link-delay metric: D:10 BGP-LS
SR PCE – High Availability (HA)
• SR PCE leverages the well-known standardized PCE HA
• Head-end sends PCEP Report for its SR Policies to all connected SR
PCE nodes
• Head-end delegates control to its primary SR PCE
• Delegate flag (D) is set in PCRept to primary SR PCE
• Upon failure of the primary SR PCE, head-end re-delegates control to
another SR PCE
 SR PCE HA – workflow
• ➊ Node1 requests SR PCE1 to compute path to
Node3, ➋ SR PCE1 computes path and replies ➊
PCE
with SID list <30102, 30203> and ➌ Node1 ➋ 1

activates SR Policy
➍ PCRept
• ➍ Node1 reports SR Policy to both SR PCE1 “delegate” (D:1)
and SR PCE2 and delegates control of the SR
Policy to SR PCE1 (“delegate” (D:1)) 1 I:100
2 I:100
3
➌

5 74
➍ PCRept
(D:0)
PCE
2 6 I:100
7 I:100
8
Domain1 Domain2

Default IGP link metric: I:10 PCEP

Default link-delay metric: D:10
 SR PCE HA – workflow
• ➎ SR PCE1 (primary) fails
• ➏ Node1 detects SR PCE1 PCEP failure PCE
51
(keepalive) and starts re-delegation timer
• ➐ when the timer expires, Node1 delegates
the SR Policy control to SR PCE2 ➏
• SR PCE2 re-computes path and updates path if 1 I:100
2 I:100
3
required
➐ PCRept 5 74
“delegate” (D:1)

PCE
2 6 I:100
7 I:100
8
Domain1 Domain2

Default IGP link metric: I:10 PCEP

Default link-delay metric: D:10
SR-PCE Distributed Design
SR PCE – Fundamentally Distributed
• Add SR PCE nodes where needed; per geographic region, per
service, ...
• SR PCE needs to get the required topology information for its task
• E.g. to compute inter-domain paths SR PCE needs the topology of all domains
• Example:
Domain1 Domain2 Domain3

A BR1 B BR3 BR5 Z

BR2 BR4 BR6

SR SR SR SR SR SR
PCE PCE PCE PCE PCE PCE PCEP
SR PCE – Fundamentally Distributed
• Using RRs to scale the BGP-LS topology distribution
• Any node can have a BGP-LS session to the RR
Domain1 Domain2 Domain3

RR RR RR

2 4 5
1
6
3

SR SR SR SR SR SR
PCE PCE PCE PCE PCE PCE
BGP-LS
 Transport Programmability – SRTE Policy
NSO
BGP-LS
SR-PCE RR SR-PCE
PCEP/BGP

Anycast-SID Anycast-SID

PE3 PE5
A1 Access Core Access A6
PE2 PE4
IGP SR (ISIS/OSPF) – Intra-Domain LSP IGP SR (ISIS/OSPF) – Intra-Domain LSP IGP SR (ISIS/OSPF) – Intra-Domain LSP

MPLS Data-Plane Left-To-Right ->

TI-LFA
TI-LFA End-To-End, Each IGP Domain Independently
TI-LFA
PE2/PE3 SR PHP PE4/PE5 SR PHP A6 SR PHP
PE4/PE5 SR PE4/PE5 SR A6 SR A6 SR Service Service

A6 SR A6 SR Service Service
Service Service
Lab Use case
 Lab Topology
PCE1 PCE2

R1 R4-Inline RR R7
Ge0/0/0/2 Ge0/0/0/1 Ge0/0/0/2 Ge
Ge0/0/0/4 0/0
Ge /0/
Ge 0 3
0/0
/0/ 0
0/0
/0/ /0/0/

Ge0/0/0/1
Ge0/0/0/2
Ge0/0/0/0
1 0/ 3 Ge
0
/0/
1 0/ Ge
Ge R5 0/0 Ge
0/
Ge
0/ R6-PCE 0/
2
0/1
0/0
/0/ Ge 0/ 0/
0/ 0/
4 1 Ge CE2
Ge
Ge0/0/0/0 0/2 0/ 0/
2

Ge0/0/0/0

Ge0/0/0/0
0/0 Ge
0/0/ /3 /0 0/ Ge
Ge /0 /0 0/ Ge0
3 0 0/ /0/
Ge /0/ Ge 3 0/
CE1 /0/
0/2 0/0
/0/ Ge
0/ 0 2
0 2
Ge0/2 Ge0/0/0/3 Ge 0/3
0/0/
Ge0/0/0/1 Ge0/0/0/1 Ge0/0/0/4 Ge0/0/0/1 Ge

Ge0/0/0/5
R2 R3 Inline RR R8

CE3 Ge0/1
ISIS AGG ISIS CORE
BGP LU RFC3107
 Lab Topology With IGP Metric
PCE1 PCE2

R1 R4 R7
10 10

10 R5 10 10
10
10 10 CE2
1000 1000
1000 1000 R6-PCE
CE1

1000 1000
R2 R3 R8

Metric are mentioned on each link

Link Configured with affinity red

CE3
 Lab Topology With Latency
PCE1 PCE2

R1 R4 R7
100 100
10 0 10 0
0 R5 10 0 10
100 CE2
100
1 1 1
1 R6-PCE
CE1

1 1
R2 R3 R8
Latency configured on each link

CE3
Use Cases
• Usecase1: Distributed PCE design Architecture and PCE redundancy
• Usecase2: Interdomain disjoint path SRTE ODN policy is configured on R1 and R2. R1 is using XTC2 as primary
PCE and R2 is using XTC1 as primary PCE. Disjoint path are configured on R1 and R2 with group ID 1 and
color 600. Task is to ensure path are disjoint in nature along with verification of state sync on PCE
• Usecase3: Network slicing Demonstration for interdomain SRTE with metric type as IGP and metric Type as
Latency with SR-PM. R2 will be headend and R8 will be tail end router. Color used would be 800 and 850.
Task is to verify diverse path is taken by both the traffic flow
• Usecase4: Network slicing Demonstration for interdomain SRTE with Affinities. R2 will be headend and R8
will be tail end router. Affinity RED is configured on the path R2<->R5<->R4<->R6<->R8. ODN with color 111
is configured to include RED affinity link only. This will be used to steer traffic via the R2<->R5<->R4<->R6<-
>R8 Path. Another ODN policy with color 110 is configured between same source and destination routers to
use shortest IGP path. Task is to verify diverse path is taken by both the traffic flow
• Usecase5: Dual home Customer is connected on R7 and R8 and advertising same subnet. On R1 ODN policy
with color 78 is configured. Task is to verify whether we achieve load balancing of traffic based on metric and
BGP max-path.