Supported Features

The following are the supported functionalities:

• SRv6 policies with SRv6 uSID segments

• SRv6 policies with PCE-delegated dynamic paths

• SRv6 policies with explicit paths

• SRv6 policies with single or multiple candidate paths (CP)

• SRv6 policies with a single SID list per CP

• SRv6 policies with multiple (weighted ECMP) SID lists per CP

• Path delegation and reporting with PCEPv4

• Path delegation and reporting with PCEPv6

• PCEPv4 and PCEPv6 sessions with different PCEs

• PCEs with PCEP state-sync sessions must be either PCEPv4 or PCEPv6.

• PCEP path delegation with the following optimization objective (metric) types:

  • IGP metric

  • TE metric

  • Delay (latency)

  • Hop-count

• PCEP path delegation with the following constraint types:

  • Affinity (include-any, include-all, exclude-any)

  • Path disjointness (link, node, SRLG, SRLG+node)

    • For path-computation on PCE, configuring both affinity and disjoint-path is not supported.

  • Segment protection-type:

    • Protected-only

    • Protected-preferred

    • Unprotected-only

    • Unprotected-preferred

• SRv6 policy with TI-LFA (protection of the first segment in the segment list at the head-end)

• Steering over SRv6 policies with Automated Steering for the following services:

  • L3 BGP-based services (IPv4 L3VPN, IPv6 L3VPN, IPv4 BGP global, IPv6 BGP global)

Unsupported Features

The following functionalities are not supported:

• SRv6 policy counters

• PCE-initiated SRv6 policies via PCEP

• SRv6 policies with head-end computed dynamic paths

• PCE path delegation with segment-type Flex Algo constraint

• PCEPv4 and PCEPv6 sessions with same PCE

• Steering over SRv6 policies based on incoming BSID (remote automated steering)

• PCC with user-configured PCE groups

• SR-PM delay-measurement over SRv6 policies

• SR-PM liveness detection over SRv6 policies

• L3 services with BGP PIC over SRv6 policies

• SRv6 policy ping

• L2 BGP-based service (EVPN VPWS)

By default, 1K polices are supported. If MPLS tunnels are not configured on the router, use the following commands to get higher SRv6-TE scale:

• If the support for LDPoTE or SRoSR-TE MPLS features are not required, use the following command to configure higher RSVP-TE/SR-TE scale.

  hw-module profile cef te-tunnel highscale-no-ldp-over-te

• If the support for LDPoTE is required but not SRoSR-TE MPLS features, use the following command to configure higher tunnel scale.

  hw-module profile cef te-tunnel highscale-ldp-over-te-no-sr-over-srte

SRv6-TE uses a “policy” to steer traffic through the network. An SRv6-TE policy path is expressed as a list of micro-segments that specifies the path, called a micro-segment ID (uSID) list. Each segment list is an end-to-end path from the source to the destination, and instructs the routers in the network to follow the specified path instead of following the shortest path calculated by the IGP. If a packet is steered into an SRv6-TE policy, the uSID list is pushed on the packet by the head-end. The rest of the network executes the instructions embedded in the uSID list.

An SRv6-TE policy is identified as an ordered list (head-end, color, end-point):

• Head-end – Where the SRv6-TE policy is instantiated

• Color – A numerical value that distinguishes between two or more policies to the same node pairs (Head-end – End point)

• End-point – The destination of the SRv6-TE policy

Every SRv6-TE policy has a color value. Every policy between the same node pairs requires a unique color value.

An SRv6-TE policy uses one or more candidate paths. A candidate path can be made up of a single SID-list or a set of weighted SID-lists (for weighted equal cost multi-path [WECMP]).

A SID list can be either the result of a dynamic path computation by a PCE or a user-configured explicit path. See SRv6-TE Policy Path Types for more information.

SRv6-TE Policy Path Types

The following SRv6-TE policy path types are supported:

SRv6 Flexible Algorithm allows operators to customize IGP shortest path computation according to their own needs. An operator can assign custom SRv6 locators to realize forwarding beyond link-cost-based shortest path. As a result, Flexible Algorithm provides a traffic-engineered path automatically computed by the IGP to any destination reachable by the IGP.

With SRv6 Flexible Algorithm, a PE can advertise BGP service routes (global, VPN) that include the SRv6 locator (Algo 0 or Flex Algo) of the intended transport SLA.

For information about configuring Flexible Algorithm, see Configuring SRv6 IS-IS Flexible Algorithm.

In the example below, the SR domain has 2 network slices. Each slice is assigned a /32 uSID Locator Block.

A slice can be realized with a user-defined Flex-Algo instances (for example, Flex Algo 128 = min-delay)

• Min-Cost Slice — FCBB:BB00/32

• Min-Delay Slice — FCBB:BB01/32

SR node2 gets a Shortest-Path Endpoint uSID (uN) from each slice:

• uN min-cost of Node2 — FCBB:BB00:0002/48

• uN min-delay of Node2 — FCBB:BB01:0002/48

Node2 announces locators via IS-IS:

• FCBB:BB00:0002/48 Algo 0 (min-cost)

• FCBB:BB01:0002/48 Algo 128 (min-delay)

IS-IS in Node1 computes shortest paths for each locator and programs them in the FIB:

Node1 and Node2 are PEs of a common VPN. PEs advertise VPN routes via BGP with different transport SLAs. For example, traffic to a set of prefixes is to be delivered over the min-cost slice, while for another set of prefixes is to be delivered over the min-delay slice. To achieve this, the egress PE’s service route advertisement includes the locator of the intended transport SLA type.

Use-case: VPN over Min-Cost Slice (Control Plane Behavior)

• Intuitive uSID program for routes advertised by Node2:

  • Within the Min-Cost Slice (FCBB:BB00)

  • Follow the shortest-path to Node2 (0002)

  • Execute VPN9 decapsulation function at Node2 (F009)

• Hardware Efficiency

  • Egress PE Node2 processes multiple uSIDs with a single /64 lookup

  • FCBB:BB00:0002:F009/64

Use-case: VPN over Min-Delay Slice (Control Plane Behavior)

• Intuitive uSID program for routes advertised by Node2:

  • Within the Min-Delay Slice (FCBB:BB01)

  • Follow the shortest-path to Node2 (0002)

  • Execute VPN9 decapsulation at Node2 (F009)

• Hardware Efficiency

  • Egress PE 2 processes multiple uSIDs with a single /64 lookup

  • FCBB:BB01:0002:F009/64

Use-case: VPN over Min-Cost Slice (Data Plane Behavior)

1. Ingress PE (Node 1) learns via BGP that prefix 10.2.0.0/24 in VPN9 is reachable via SID FCBB:BB00:0002:F009

2. Node 1 programs the prefix with “VPN Encaps” behavior

3. When receiving traffic with DA IP matching the prefix 10.2.0.0/24 FIB entry, Node 1 encapsulates the incoming packet into IPv6 with DA of FCBB:BB00:0002:F009

   

4. SRv6 allows for seamless deployment where any transit node (SRv6-capable or not) simply routes based on a /48 longest prefix match lookup.

   For example, transit node (Node 3) forwards traffic along the Algo 0 (min-cost) shortest path for the remote prefix FCBB:BB00:0002::/48.

   

5. Egress PE (Node 2) matches local SID FCBB:BB00:0002:F009/64. Node 2 applies “VPN Decaps” behavior into VRF9 by removing the IPv6 encapsulation and looking up the payload’s DA on the corresponding VPN table.

   

Use-case: VPN over Min-Delay Slice (Data Plane Behavior)

1. Ingress PE (Node 1) learns via BGP that prefix 20.2.0.0/24 in VPN9 is reachable via SID FCBB:BB01:0002:F009

2. Node 1 programs the prefix with “VPN Encaps” behavior

3. When receiving traffic with DA IP matching the prefix 20.2.0.0/24 FIB entry, Node 1 encapsulates the incoming packet into IPv6 with DA of FCBB:BB01:0002:F009

4. Transit node (Node 3) forwards traffic along the Algo 128 (min-delay) shortest path for the remote prefix FCBB:BB01:0002::/48.

5. Egress PE (Node 2) matches local SID FCBB:BB01:0002:F009/64. Node 2 applies “VPN Decaps” behavior into VRF9 by removing the IPv6 encapsulation and looking up the payload’s DA on the corresponding VPN table.