• A maximum of 500 SR policies are supported.

• Only native COE is supported.

• Effective Cisco IOS XE Bengaluru 17.5.1, Bandwidth optimization based on SR tactical policy is supported on RSP3.

• Bandwidth optimization by using COE is not supported.

• PIC core and PIC edge are not supported over SR-TE tunnel till Cisco IOS XE Cupertino Release 17.8.1. Starting with Cisco IOS XE Release 17.9.1, PIC core is supported for short LCM policies with 0, 1, or 2 SR labels.

• Effective Cisco IOS XE Bengaluru 17.5.1, ECMP over SR-TE is supported on RSP3.

• 6PE and 6VPE are not supported with three and four transport labels.

• IPv6 is not supported.

• A maximum of 10,000 VPNv4 prefix limits are supported.

• BGP LU (RFC 3107) is not supported for intra-AS and inter-AS.

Cisco ASR 900 RSP3 module supports sr_5_label_push_enable and sr_pfp_enable templates. Following restrictions apply for different template combinations.

With sr_5_label_push_enable template:

• Only one service label is supported with LB over SR-TE tunnels with three or four TE labels. This service label includes L3VPN, L2VPN, 6PE, 6VPE, and RFC 3107 BGP-LU label.

• 6PE and 6VPE are not supported with three and four SR-TE tunnel labels.

• Segment routing is not supported in enable_portchannel_qos_multiple_active template.

• HW load balancing for L2VPN/EVPN services is not supported if the L2VPN/EVPN destination has a static route configured over SR-TE tunnel.

With sr_pfp_enable template:

• SR PM HW time stamping is not supported.

• VLAN COS marking is not supported.

• HW load balancing is not supported.

• Policer based hierarchical QOS on the ingress is not supported.

• Short-Pipe tunneling mode is not supported.

Other Restrictions:

• PIC core over SR-TE tunnels are not supported till Cisco IOS XE Cupertino Release 17.8.1.

• PIC edge over SR TE tunnels are not supported till Cisco IOS XE Cupertino Release 17.8.1.

• PIC edge multipath over SR TE tunnels are not supported till Cisco IOS XE Cupertino Release 17.9.1.

• W-ECMP is not supported.

• Next hop ECMP is not supported within an SR policy.

• Local congestion mitigation (LCM) is applicable only for best effort traffic. All other delay sensitive traffic uses safe SIDs (Flex Algo 128). Delay sensitive traffic is not redirected using the LCM tunnels.

In today’s network deployments it is important for every router in the network to have the capability to provision the traffic in such a way that it avoids the congestion based on the amount of traffic ingressing and egressing out of it. In order to provision this congestion mitigation, it is essential for the routers to support Equal Cost Multi-Path (ECMP) load balancing, that is, distributing the traffic based on the number of paths available to reach the destination.

Congestion mitigation helps the routers to move certain traffic to a different path than the current path, using the tactical SR policies. When the link congestion threshold is crossed, the COE (Cisco Optimization Engine) that monitors the link congestion based on the interface counters, pushes these tactical policies using PCE. These PCE initiated tactical policies that are used for local congestion mitigation (LCM) are deployed when necessary and only best effort traffic is load balanced over these tactical SR-TE policies.

In the above topology, let us assume that the best effort traffic is coming in to P1 from PE1 and PE2 for the destination PE3 and the link between P1 and PE3 is congested. To mitigate the congestion between P1 and PE3, ECMP paths from P1 and PE3 are required. With segment routing this is achieved by deploying multiple tactical SR policies from P1 to PE3, one through directly connected link P1-PE3 and the other through the path P1-PE4-PE3. These policies are called tactical policies and are used to avoid local congestion mitigation by load balancing the best effort traffic over these tactical policies. The LCM is applicable only for best effort traffic. All other delay sensitive traffic would use safe SIDs (Flex Algo 128). Delay sensitive traffic is not redirected using the LCM tunnels. Originating traffic is directed on non-LCM tunnels and transiting traffic with safe-SIDs is treated as normal label entry traffic and forwarded accordingly.

In the above topology, any node may deploy LCM tactical tunnels to mitigate congestion over a particular link. These nodes transit or sometimes originate the traffic to the LCM tunnel end points or even beyond the tunnel end points.

Let us assume that PE nodes originate the traffic and P nodes are transit node for the traffic originated somewhere else. Based on these combinations following are the different types of traffic that have to be considered:

As a PE Node,

• L3VPN best effort traffic

• L2VPN best effort traffic

• Global traffic

As a P node,

• Any traffic that comes in for a non-flexible algorithm 0 label is treated as an entry swap on the Label lookup.

• Any traffic that comes in for flexible algorithm 0 label is treated as a swap case or it may be translated to pop and push stack of labels, if there is an LCM created for that outgoing link based on congestion.

Based on the number of TE labels that the LCM tunnels have to push, the number of labels outside of TE labels can be either one or two (service labels).

At the head end, following are the different types of traffic that is subjected to load balancing. The traffic type here includes both best effort and delay sensitive.

As a PE Node,

• L3VPN traffic

• L2VPN traffic

• Global traffic

As a P node,

• Any traffic that comes in is treated based on the Label lookup.

The below configuration shows how to configure ECMP over SR-TE policy with OSPF autoroute announce and PCE initiated segement routing policy with profile ID as 100.

pce
    address ipv4 13.13.13.13
segment-routing traffic-eng
   peer ipv4 10.0.0.1  
    segment-list name ss1
    index 1 mpls label 18021
    index 2 mpls label 18023
    policy 100
     binding-sid mpls 15999
     color 100 end-point ipv4 12.12.12.12
     candidate-paths
      preference 10
       explicit segment-list ss1 
    !
       constraints
       segments
       dataplane mpls
 profile-id 100

Now, to push the PCE initiated OSPF autoroute announce from PCE to PCC, the profile IDs on PCE and PCC must match. The below configuration shows the PCC configuration and that the profile ID is matching with PCE and thus the autoroute announce is enabled. Based on the number of autoroute policies configured on the ECMP link, packets are load balanced on the ECMP links for the non-strict SIDs.

segment-routing traffic-eng                                                             
  pcc
  pce address 13.13.13.13 source-address 10.0.0.1
  profile 100
   autoroute
    include all