In our lab setup, using all IOS XR routers and an XTC based PCE, we do not understand why all the dynamic SR-TE tunnels calculated by XTC are expressed as SR Adjacency SIDs, never as Node SIDs, hence never taking advantage of all the ECMP paths and resulting in very long SID-lists (a label stack always equal to the number of hops of the tunnel).
Examples found on dcloud labs/demos show PCE calculated path with node-SIDs and/or a combination of Adj-SID and Node-SIDs with the exact same network setup and configuration. Any idea what could be causing this issue?
Just a Note: when configuring explicit SR-TE tunnel with a manually configured SID-list based on Node-SIDs, everything works well.
The headend, a ASR9001-001 is configured with an TE interface tunnel that request dynmaic SR path calculation to the XTC and the resulting SID-list is a sequence of Adjacency SID in all scenarios (the setup has 10 nodes, 5 of which in the same domain and the other 5 in another domain, but same result). In the cases where the tail-end (egress PE) is for example 7 hops away, the XTC calculated path is 7 Adjacency SIDs
Example of an output:
The tunnel configuration:
RP/0/RSP0/CPU0:ASR9001-001#show run int tunnel-te 100
Wed Nov 15 12:16:57.695 CET
description min TE metric tunnel
ipv4 unnumbered Loopback0
path-option 1 dynamic pce segment-routing
and the PCE calculated path (6 hops, all Adj-SID when our topology has a few ECMP paths that satisfies the object "minimum TE metric"
(same result with IGP metric):
RP/0/RSP0/CPU0:ASR9001-001#show mpls traffic-eng tunnels 100
Wed Nov 15 12:20:19.981 CET
Name: tunnel-te100 Destination: 10.92.224.105 Ifhandle:0x520
Admin: up Oper: up Path: valid Signalling: connected
path option 1, (Segment-Routing) type dynamic pce (Basis for Setup, path weight 230)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Thu Nov 2 08:49:44 2017 (1w6d ago)
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (interface)
Tiebreaker: Min-fill (default)
Protection: any (default)
Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
AutoRoute: disabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Autoroute Destinations: 0
Loadshare: 0 equal loadshares
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
SRLG discovery: Disabled
Tunnel has been up for: 00:08:12 (since Wed Nov 15 12:12:08 CET 2017)
Uptime: 00:08:12 (since Wed Nov 15 12:12:08 CET 2017)
LSP not signalled, has no S2Ls
Date/Time: Wed Nov 15 12:09:28 CET 2017 [00:10:52 ago]
ID: 34 Path Option: 1
Removal Trigger: tunnel shutdown
Segment-Routing Path Info (PCE computed path)
Segment0[Link]: 10.93.11.1 - 10.93.11.2, Label: 24001
Segment1[Link]: 10.93.2.13 - 10.93.2.14, Label: 24028
Segment2[Link]: 10.93.3.10 - 10.93.3.9, Label: 24001
Segment3[Link]: 10.93.2.17 - 10.93.2.18, Label: 24003
Segment4[Link]: 10.93.4.5 - 10.93.4.6, Label: 24010
Segment5[Link]: 10.94.2.1 - 10.94.2.2, Label: 24004
Displayed 1 (of 7) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
Please refer to the following documents for more information:
I also recommend you post this to the Cisco Support Community for more feedback.
Moderator for Cisco Customer Communities
Looks like there is an issue with OSPF in genereal.
I reconfigured the IGP in all the domains with ISIS (instead of OSPF) and the problem was resolved: the PCE is now provided paths with node SIDs using a minimum number of SIDs (instead of Adj-SID for EVERY hop) allowing for ECMP and reducing the label-stack depth.
Is this a known issue with OSPF?