Revision History

Solution Component Software Versions

Summary

Segment Routing has become the de facto underlay transport architecture for next-generation IP networks. SR simplifies the underlay network while also enhancing it with additional capabilities to carry differentiated services and maintain end-to-end SLAs for network deployments such as 5G mobile services.

Segment Routing is an architecture, with a base set of functions achievable using standards based technology. The architecture gives SR the flexibility to adopt the best technology for a specific network and the use cases it needs to support.

One component where SR supports this flexibility is in the data-plane transport layer. At its core SR is an underlay transport technology allowing a network to carry overlay services, such as L2VPN, EVPN, and simple IP services. The most ubiquitous data-plane transport used today in packet networks is MPLS. MPLS originated as Cisco tag switching almost 25 years ago (1998) and powers both service provider and enterprise networks worldwide.
Segment Routing supports MPLS using the SR-MPLS data-plane, where SR SIDs are allocated as MPLS labels and is widely deployed today.

IPv6 is the next-generation of IP addressing, also available for more than two decades. IPv6 promised simplified networks and services by utilizing the large amount of address space to ues IPv6 addressing to easily correlate packet to service. The vision has been there but the proper technology did not fully enable it. Segment Routing v6 is the technology which not only provides an IPv6-only data-plane across the network, but also creates a symmetry between data-plane, overlay services, and performance monitoring.

SRv6 is the technology for enabling next-generation IPv6 based networks to support complex user and infrastructure services.

SRv6 Technology Overview

SRv6 Benefits

Scale

One of the main benefits of SRv6 is the ability to build networks at huge scale through address summarization. MPLS networks require a unique label per node be distributed to all nodes requiring mutual reachability. In most cases there is also the requirement of distributing a /32 IP prefix as well. In the MPLS CST design we have the option to eliminate the IP and MPLS label distribution by utilizing a PCE to compute end to end paths. While this method works well and is also available for SRv6 it can lead to a large number of SR-TE or SRv6-TE policies.

SRv6 allows us to summarize domain loopback addresses at IGP or BGP boundaries. This means a domain of 1000 nodes no longer requires advertising 1000 IP prefixes and associated labels, but can be summarized into a single IP advertisement reachable via a simple longest prefix match (LPM) lookup. Networks of tens of thousands of nodes can now provide full reachability with very few IPv6 routes. See the deployment options section for more information.

Simple Forwarding

In SRv6, if a node is not a terminating node it simply forwards the traffic using IPv6 IP forwarding. This means nodes which are not SRv6 aware can also participate in a SRv6 network.

Forwarding and Service Congruency

As you will see in the services section, the destination IPv6 address in SRv6 is the service endpoint. Coupled with the simple forwarding this aids in troubleshooting and is much easier to understand than the MPLS layered service and data plane.

Segment Routing v6 IETF Standards and Drafts

IPv6 Segment Routing Header (SRH)

Defined in RFC 8754, the SRv6 header includes the SRv6 SID list along with additional attributes to program the SRv6 IPv6 data plane path. The SRH may be inserted by the source node or a SRv6 termination point. The SRH is not required in all SRv6 use cases such as a simple L3VPN or L2VPN with no traffic engineering requirements. Unlike MPLS, the SRv6 end IPv6 address can be used to identify the endpoint node and the service.

SRv6 Locator

The SRv6 locator is part of the SRv6 SID structure of Locator:Function:Argument. The locator is allocated to nodes acting as SRv6 endpoints. The locator is defined as a specific amount of bits of the IPv6 address steering traffic to the endpoint node.

SRv6 Compressed SID (micro-SID / uSID)

SRv6 is made more efficient with the use compressed SIDs. Compressed SIDs are also known as micro-SIDs (uSID). In the case of micro-SID, multiple SRv6 SIDs can be encoded in a single 128-bit SRv6 SID. Additional SRv6 SIDs can be included in the path by adding an additional SRH if necessary.

SRv6 micro-SID Terminology

SRv6 Addressing with Compressed SID

Using the compressed SID or micro-SID format requires defining the IPv6 address structure segmenting the IPv6 address into a C-SID portion and Locator block portion. A dedicated IPv6 prefix should be used for SRv6 and SRv6 micro-SID allocation. RIR assigned public prefixes can be utilized or private ULA space defined in RFC4193.

SRv6 uSID Carrier Format

Micro-SID requires defining a carrier format used globally across the network. A parent block size is dedicated to micro-SID allocations and the length of each micro-SID. IOS-XR supports the F3216 format, defining a 32-bit micro-SID block and 16-bit ID format.

Global C-SID Block (GIB)

The global ID block defines the block of SIDs used to identify nodes either uniquely or as part of an anycast group. These addresses are used by other nodes on the network to send SRv6 service traffic to the endpoint with the Global C-SID assigned.

Local C-SID Block (LIB)

The local ID block is used to define SIDs which are local to a node. These are typically used to identify services terminating on a node.

Baseline SRv6 Forwarding Behavior

Forwarding in SRv6 follows the semantics of simple IPv6 routing. The destination is always identified as an IPv6 address. In the case of an SRv6 packet without an additional SRH, traffic is routed to the endpoint destination node hop by hop based on normal destination based prefix lookups. In the case of a SRH, the SRH is only processed by a node if it is the destination address in the outer IPv6 header. If the node is the last SID in the SID list it will pop the SRH and process the packet further. If the node is not the last SID in the SID list it will replace the outer IPv6 destination address with the next IPv6 address in the SID list.

Compressed SID without SRH

Compressed SIDs have the ability to instantiate a multi-hop SRv6 path using a single 128-bit IPv6 address. Each micro-SID in the F3216 format uses 16 bits to identify the next node. If the node receives the packet with its own address as the IPv6 destination address it will further process the packet. It will either shift the micro-SID component of the address 16 bits to the left and copy the new address into the IPv6 destination address or if the locator is local to the node further process the service packet. Using the F3216 carrier format in IOS-XR, upto 6 micro-SIDs can be encoded in a single 128-bit IPv6 address.

The example below illustrates the forwarding behavior with no additional SRH.

Compressed SID with additional SRv6 Headers

Using additional SRv6 headers increases the depth of the micro-SID list to support use cases with longer traffic engineered paths. This allows SRv6 with micro-SID to enable path hop counts greater than SR-MPLS.

TI-LFA Mid-Point Protection

SRv6 fully supports Topology Independent Loop-Free Alternates ensuring fast traffic protection the case of link and node failures. A per-prefix pre-computed loop-free backup path is created. If the path requires traversing links which may end up in a loop, the protecting node will insert an SRH with the appropriate SIDs to reach the Q node with loop-free reachability to the destination prefix.

SRv6 Deployment Overview

Scalable Deployment using Domain Summarization and Redistribution

In the CST design we utilize separate IGP instances to segment the network. These segments can be based on scale, place in the network, or for other administrative reasons. We do not recommend exceeding 2000 routers in a single IGP domains.

SRv6 and its summarization capabilities are ideal for building high scale networks based on the CST design. At each domain boundary the IPv6 locator blocks are summarized and redistributed across adjacent domains. The end to end redistribution of summary prefixes enabled reachability between any two nodes on the network by simply doing a longest-prefix match on the destination address.

Mutual Redistribution with Redundant Connectivity

Redistribution between IGP domains interconnected by multiple links requires additional consideration. While summary prefixes may not affect intra-domain connectivity, if they are redistributed back into the domain initially distributing them routing loops may occur. It’s important to make sure the router is properly configured to not violate the split-horizon rule of advertising routes back to the same domain they received them from. See the IGP implementation section for more details.

Unreachable Prefix Announcement

Summarization hides the state of longer prefixes within the aggregate summary, leading to traffic loss or slower failover when an egress PE is unreachable. UPA is an IGP function to quickly poison a prefix which has become unreachable to an upstream node. It enables the notification of an individual prefix becoming unreachable, outside of the local area/domain and across the network in a manner that does not leave behind any persistent state in the link-state database. When an ingress PE receives the UPA for an egress PE it can trigger fast switchover to an alternate path, such as a BGP PIC pre-programmed backup path.

SR Flexible Algorithms

Flexible Algorithms or Flex-Algo is an important component in SRv6 networks. SRv6 enables advanced forwarding behavior without utilizing SR-TE Policies, increasing scale and simplifying network deployments. Flex-Algo is used in the CST SRv6 design to differentiate traffic based on latency or path constraints.

SRv6-TE Policies for Advanced TE

SRv6 supports the same TE Policy functionality as SR-MPLS. In cases where more advanced TE is required than Flex-Algo provides, such as defining explicit paths or requiring a path be disjoint from another path, SRv6-TE can be utilized. In CST SRv6 1.0, on-demand networking can be used for supported services with SR-PCE to compute both intra-domain and inter-domain paths. Provisioning, visualization, and monitoring of SRv6-TE paths is available in Crosswork Network Controller 4.1.

SRv6 Network Functions and Endpoint Behaviors

RFC 8986 defines a set of SRv6 endpoint behaviors satisfying specific network service functions. The table below defines a base set of functions and the identifiers used. See RFC 8986 for details on each behavior.

SRv6 Compressed SID Behavior

When SRv6 SID compression is used enhanced methods are used when processing End SRv6 packets. Since multiple SIDs are encoded in a single IPv6 address as the argument component of the SRv6 address, a portion of the argument equal to the SID length is copied into a specific portion of the IPv6 destination address matching the next node in the path.

SRv6 Network Implementation

Implementing SRv6 in the network requires the following steps:

• Network Domain Planning
• SRv6 Network Address Planning
• SRv6 Router Configuration
• SRv6 Enabled Services Configuration

Network Domain Planning

Networks require segmentation to scale. The initial step in designing scalable networks is to determine where network boundaries. This leads directly to IGP segmentation of the network utilized in the CST SRv6 design. In our example network we have three domains, two access domains and one core domain. Each of these IGP domains is assigned a unique instance identifier.

SRv6 Network Address Planning

SRv6 using micro-SID requires allocating the appropriate parent IPv6 prefix and then further delegation based on the micro-SID carrier format. We will use the F3216 format, using a 32 bit block and 16 bits for each SID. It is recommended the parent prefix, such as a /24 be allocated ONLY for SRv6 use. The block can be from public IPv6 resources or utilize a ULA private block.

Specific segments of the IPv6 address can be used to represent areas of the network, flexible algorithms, or other network data. It is important to use the specific bits or bytes of the address used as identifiers to also aid in summarization.

Locator Planning and Formatting

The SRv6 locator identifies a node and its specific services. SRv6 using micro-SID should use a specific locator format that adheres to the micro-SID carrier format and lends itself to summarization at network boundaries. The following is a recommended way to define the locator format which allows for efficient summarization. It is required to use a locator prefix length of /48 on all nodes when using the F3216 carrier format.

The example locator above encodes the following information:

In our example network, we have a /32 micro-SID prefix allocated network wide for each Flex-Algo. This is recommended as it quickly allows operators to identify the FA being used and promotes more efficient summarization. However, if FA is not being used these bits could be used for a different identifier.

The 8-bit domain identifier allows 255 domains, the 8-bit node identifier allows 255 nodes per domain. This is flexible however, the structure could be shifted to allow less domains and more nodes per domain.

Using the schema above our example address is as follows:

This allows each domain’s SRv6 SIDs to be summarized per flex-algo at the /40 prefix length.

Router Configuration

The CST design supports using SRv6 micro-SID only. Legacy SRv6 using the 128-bit carrier format is not supported.

SRv6 Micro-SID Hardware Enablement

On NCS 540 and NCS 5500 platforms the following command enables SRv6 with micro-SID carrier.

 
hw-module profile segment-routing srv6 mode micro-segment format f3216

Loopback Interface Configuration

While not required, it is recommended to use an IPv6 address from the Algo 0 (base IGP) locator address block for the Loopback interface.

 
interface Loopback0
 ipv4 address 101.0.2.53 255.255.255.255
 ipv6 address fccc:0:214::1/128
!

PE Locator Configuration

SRv6 enabled routers terminating services must have SRv6 locators configured. In our Flex-Algo use case we will have a single locator configured for each Flex-Algo, although more locators can be configured as needed. The unode behavior is set to psp-usd which performs penultimate-segment-popping and ultimate-segment-decapsulation. See RFC 8986 for more information on these behaviors.

Locators are used to allocate both static and dynamic /64 SIDs used for services and link adjacency SIDs. The SIDs used for dynamic allocation are in the e0000-ffff range in bits 48-63 of the IPv6 address.

In this case the locator value is assigned based on the following as identified in the addressing section:

PE Locator Router Configuration

segment-routing
 srv6
  encapsulation
   source-address fccc:0:214::1
  !
  locators
   locator LocAlgo0
    micro-segment behavior unode psp-usd
    prefix fccc:0:214::/48
   !
   locator LocAlgo128
    micro-segment behavior unode psp-usd
    prefix fccc:1:214::/48
    algorithm 128
   !
   locator LocAlgo129
    micro-segment behavior unode psp-usd
    prefix fccc:2:214::/48
    algorithm 129
   !
   locator LocAlgo130
    micro-segment behavior unode psp-usd
    prefix fccc:3:214::/48
    algorithm 130
   !
   locator LocAlgo131
    micro-segment behavior unode psp-usd
    prefix fccc:4:214::/48
    algorithm 131
   !
  !
 !
!

Configured Locators

RP/0/RP0/CPU0:cst-a-pe3#show segment-routing srv6 locator
Thu Jan  5 17:27:30.127 UTC
Name                  ID       Algo  Prefix                    Status   Flags
--------------------  -------  ----  ------------------------  -------  --------
LocAlgo0              1        0     fccc:0:214::/48           Up       U
LocAlgo128            2        128   fccc:1:214::/48           Up       U
LocAlgo129            3        129   fccc:2:214::/48           Up       U
LocAlgo130            4        130   fccc:3:214::/48           Up       U
LocAlgo131            5        131   fccc:4:214::/48           Up       U

Dynamic Micro-SID Service SIDs based on Locator

As shown below the primary locator for Algo 0 is identified as fccc:0:103::/48. Each service has one or more SIDs allocated starting at fccc:0:103:e000::/64.

RP/0/RP0/CPU0:cst-a-pe3#show segment-routing srv6 sid
Thu Jan  5 17:30:55.250 UTC

*** Locator: 'LocAlgo0' ***

SID                         Behavior          Context                           Owner               State  RW
--------------------------  ----------------  --------------------------------  ------------------  -----  --
fccc:0:103::                uN (PSP/USD)      'default':259                     sidmgr              InUse  Y
fccc:0:103:e000::           uDT2U             4550:0                            l2vpn_srv6          InUse  Y
fccc:0:103:e001::           uDT2M             4550:0                            l2vpn_srv6          InUse  Y
fccc:0:103:e002::           uDX2              4600:600                          l2vpn_srv6          InUse  Y
fccc:0:103:e003::           uDX2              650:650                           l2vpn_srv6          InUse  Y
fccc:0:103:e004::           uDT4              'l3vpn-v4-srv6'                   bgp-100             InUse  Y

PE IS-IS Router Configuration

SRv6 is the IPv6 data plane for Segment Routing and utilizes the same SID distribution semantics as SR-MPLS. This is achieved through IGP extensions responsible for distributing SID reachability within an IGP domain or even across IGP domains. The CST design utilizes IS-IS.

It is recommended to utilize IS-IS as an IPv6 IGP. OSPFv3 is not widely deployed in networks today and typically lags behind IS-IS in feature development.

In this example we are utilizing the base Algo 0 and four additional Algos, 128,129,130,131. Each requires a separate Locator be applied to a Loopback interface on the router. The locator names are those defined in the earlier SRv6 base configuration section.

router isis ACCESS
 address-family ipv6 unicast
  metric-style wide
  microloop avoidance segment-routing
  router-id Loopback0
  segment-routing srv6
   locator LocAlgo0
   !
   locator LocAlgo128
   !
   locator LocAlgo129
   !
   locator LocAlgo130
   !
   locator LocAlgo131
   !
  !
  maximum-redistributed-prefixes 10000 level 2
 !
 interface Loopback0
  address-family ipv6 unicast
  !
 ! 
 interface TenGigE0/0/0/9
  bfd fast-detect ipv6
  point-to-point
  hello-password keychain ISIS-KEY
  address-family ipv6 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
  !
 !
!

Domain Boundary IS-IS Configuration

The multiple instance IS-IS configuration is similar to the SR-MPLS CST design. The primary differences are the use of summarization, redistribution between instances, and the use of UPA.

Unreachable Prefix Advertisement Configuration

The UPA configuration is enabled by configuring the UPA parameters under prefix-unreachable and enabling the “adv-unreachable” for the summary prefix. The adv-metric sets the metric of the unreachable prefix and the adv-lifetime sets the amount of time it should be advertised in milliseconds. Prefixes generated by UPA can also be limited to those with a specific IGP tag by using the unreachable-component-tag option. As an example Loopback and SRv6 Locator addresses can be tagged so they generate a UPA but infrastructure links are omitted.

Summary Prefix Configuration

A flex-algo algorithm can be attached to the summary prefix and used in path computation. Using the explicit keyword means only SRv6 prefix SIDs with the specified algorithm attached will be considered as contributing prefixes for the summary.

Core and Access Mutual Redistribution

Redistribution between IGP instances should always utilize route policies with appropriate prefix-sets or tags to restrict the prefixes advertised between domains.

Link-state IGP protocols only allow prefix summarization at boundaries such as IS-IS areas, levels, or OSPF area boundaries. Summarization can also be performed on external prefixes redistributed from another protocol or IGP instance. In our case the summary-prefix configuration for the ACCESS IGP instances is in the CORE instance configuration. Tagging can be used to filter multiple prefixes based on a single tag, such as all prefixes belonging to a specific domain.

UPA prefixes must also be redistributed beyond domain boundaries. The longer UPA component prefix is generated in the CORE IS-IS instance, and must be redistributed into the appropriate remote instance. As an example if fccc:01/128 in Access Domain 1 is unreachable, a UPA is generated in the CORE domain for the /128 prefix, and then must be redistributed in Access domain 2 so ingress PEs can more quickly switch to an alternative path. In our example BGP next-hop for service routes is the /128 Loopback address assigned from Algo 0, so we must leak /128 UPAs from the core into each access domain matching the remote domain prefixes. This can be simplified by using tagging instead of strict prefix-lists.

Access-1 to Core Boundary

prefix-set ACCESS1-PE-uSID
  fccc:0:100::/40 eq 48,
  fccc:1:100::/40 eq 48,
  fccc:2:100::/40 eq 48,
  fccc:3:100::/40 eq 48,
  fccc:4:100::/40 eq 48
end-set

prefix-set ACCESS2-PE-uSID-Summary
  fccc:0:200::/40,
  fccc:1:200::/40,
  fccc:2:200::/40,
  fccc:3:200::/40,
  fccc:4:200::/40
end-set

prefix-set ACCESS2-PE-uSID-UPA
  fccc:0:200::/40 eq 128
end-set

route-policy CORE-TO-ACCESS1-SRv6
  if destination in ACCESS2-PE-uSID-Summary then
    pass
  else
    drop
  endif
end-policy

route-policy ACCESS1-TO-CORE-SRv6
  if destination in ACCESS1-PE-uSID then
    pass
  else
    drop
  endif
end-policy

router isis ACCESS
 address-family ipv6 unicast
  prefix-unreachable
   adv-metric 4261412866
   adv-lifetime 1000
   rx-process-enable
  !
  summary-prefix fccc::/40 tag 100 adv-unreachable 
  redistribute isis CORE route-policy CORE-TO-ACCESS1-SRv6

In the ACCESS instance configuration the summary prefix is equivalent to fccc:0000:00/40 as IOS-XR removes trailing zeroes from the address in the configuration.

router isis CORE
 address-family ipv6 unicast
  prefix-unreachable
   adv-metric 4261412866
   adv-lifetime 1000
   rx-process-enable
  !
  summary-prefix fccc:0:100::/40 tag 101 adv-unreachable
  summary-prefix fccc:1:100::/40 algorithm 128 tag 101 adv-unreachable explicit
  summary-prefix fccc:2:100::/40 algorithm 129 tag 101 adv-unreachable explicit 
  summary-prefix fccc:3:100::/40 algorithm 130 tag 101 adv-unreachable explicit 
  summary-prefix fccc:4:100::/40 algorithm 131 tag 101 adv-unreachable explicit 
  redistribute isis ACCESS route-policy ACCESS1-TO-CORE-SRv6
  !
 !
!

Access-2 to Core Boundary

prefix-set ACCESS2-PE-uSID
  fccc:0:200::/40 le 48,
  fccc:1:200::/40 le 48,
  fccc:2:200::/40 le 48,
  fccc:3:200::/40 le 48,
  fccc:4:200::/40 le 48
end-set

prefix-set ACCESS1-PE-uSID-Summary
  fccc:0:100::/40,
  fccc:1:100::/40,
  fccc:2:100::/40,
  fccc:3:100::/40,
  fccc:4:100::/40
end-set

prefix-set ACCESS1-PE-uSID-UPA 
  fccc:0:100::/40 eq 128
end-set

route-policy CORE-TO-ACCESS2-SRv6
  if destination in ACCESS1-PE-uSID-Summary then
    pass
  else
    drop
  endif
end-policy

route-policy ACCESS2-TO-CORE-SRv6
  if destination in ACCESS2-PE-uSID then
    pass
  else
    drop
  endif
end-policy

router isis ACCESS
 address-family ipv6 unicast
  prefix-unreachable
   adv-metric 4261412866
   adv-lifetime 1000
   rx-process-enable
  !
  summary-prefix fccc::/40 tag 100 adv-unreachable 
  redistribute isis CORE route-policy CORE-TO-ACCESS2-SRv6

router isis CORE
 address-family ipv6 unicast
  prefix-unreachable
   adv-metric 4261412866
   adv-lifetime 1000
   rx-process-enable
  !
  summary-prefix fccc:0:200::/40 tag 102 adv-unreachable
  summary-prefix fccc:1:200::/40 algorithm 128 tag 102 adv-unreachable explicit
  summary-prefix fccc:2:200::/40 algorithm 129 tag 102 adv-unreachable explicit 
  summary-prefix fccc:3:200::/40 algorithm 130 tag 102 adv-unreachable explicit 
  summary-prefix fccc:4:200::/40 algorithm 131 tag 102 adv-unreachable explicit 
  redistribute isis ACCESS route-policy ACCESS2-TO-CORE-SRv6
  !
 !
!

SRv6-TE Policies

SRv6 supports Traffic Engineering policies, using different metric types and additional path constraints to engineer traffic paths from head-end to endpoint node. SRv6 TE Policy configuration follows the same configuration as SR-MPLS TE policies.

In the CST SRv6 design 1.0 dynamic path calculation is supported using SR-PCE. Please see the CST implementation guide for PCE configuration details. Additionally, in CST SRv6 1.0 path computation for SRv6-TE Policies requires a path of nodes supporting for SRv6, if the only path is via a node not supporting SRv6, path calculation will fail.

segment-routing
 traffic-eng
  policy srte_c_21009_ep_fccc:0:215::1
   srv6
    locator LocAlgo0 binding-sid dynamic behavior ub6-insert-reduced
   !
   source-address ipv6 fccc:0:103::1
   color 21009 end-point ipv6 fccc:0:215::1
   candidate-paths
    preference 100
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
    !
   !
  !
 !
!

Operational Details

RP/0/RP0/CPU0:cst-a-pe3#show segment-routing traffic-eng policy color 21009
Thu Jan  5 23:42:24.222 UTC

SR-TE policy database

Color: 21009, End-point: fccc:0:215::1
  Name: srte_c_21009_ep_fccc:0:215::1
  Status:
    Admin: up  Operational: up for 13:36:55 (since Jan  5 10:05:28.918)
  Candidate-paths:
    Preference: 100 (configuration) (active)
      Name: srte_c_21009_ep_fccc:0:215::1
      Requested BSID: dynamic
      PCC info:
        Symbolic name: cfg_srte_c_21009_ep_fccc:0:215::1_discr_100
        PLSP-ID: 52
      Constraints:
        Protection Type: protected-preferred
        Maximum SID Depth: 7
      Dynamic (pce 101.0.1.101) (valid)
        Metric Type: IGP,   Path Accumulated Metric: 260
          SID[0]: fccc:0:108::/48 Behavior: uN (PSP/USD) (48)
                  Format: f3216
                  LBL:32 LNL:16 FL:0 AL:80
                  Address: fccc:0:108::1
          SID[1]: fccc:0:e::/48 Behavior: uN (PSP/USD) (48)
                  Format: f3216
                  LBL:32 LNL:16 FL:0 AL:80
                  Address: fccc:0:e::1
          SID[2]: fccc:0:215::/48 Behavior: uN (PSP/USD) (48)
                  Format: f3216
                  LBL:32 LNL:16 FL:0 AL:80
                  Address: fccc:0:215::1
      SRv6 Information:
        Locator: LocAlgo0
        Binding SID requested: Dynamic
        Binding SID behavior: End.B6.Insert.Red
  Attributes:
    Binding SID: fccc:0:103:e014::
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no
    Max Install Standby Candidate Paths: 0

Explicit segment list definition

In the case of building a policy with explicit paths, the sid-format must be defined so the appropriate uSID container can be populated with each node SID in the path.

segment-routing
 traffic-eng
  segment-lists
   srv6
    sid-format usid-f3216
   !
   segment-list APE7-srv6
    srv6
     index 1 sid fccc:0:109::
     index 2 sid fccc:0:20f::
     index 3 sid fccc:0:215::
    !
   !
  !
 !
!

On-Demand SRv6-TE Policy

On-demand next-hop or ODN is supported for SRv6. In the 1.0 version of the CST SRv6 design, ODN paths must be computed using SR-PCE.

In this case the dynamic binding SID for the policy is associated with the flex-algo Algo128 locator and has a constraint to use algorithm 128.

segment-routing
 traffic-eng
  on-demand color 6128
   srv6
    locator LocAlgo128 binding-sid dynamic behavior ub6-insert-reduced
   !
   source-address ipv6 fccc:1:103::
   dynamic
    pcep
    !
    metric
     type igp
    !
   !
   constraints
    segments
     sid-algorithm 128
    !
   !
  !
 !
!

Enabling Services over SRv6

Segment Routing with the IPv6 data plane is used to support all of the services supported by the MPLS data plane while also enabling advanced functionality not capable in MPLS based networks. In CST SRv6 1.0 L3VPN, EVPN-ELAN, and EVPN-VPWS services are supported using SRv6 micro-SID.

Services Route Reflector Design

The Converged SDN Transport design makes use of a set of service BGP route reflectors (S-RRs) communicating BGP service routes between PE nodes in a scalable and resilient manner. In CST SRv6 1.0 SRv6 service routes are expected from an IPv6 peer.

SRv6 Service Forwarding

MPLS uses a multi-label stack to carry overlay VPN services over an MPLS underlay network. There is always at least a 2-label stack identifying the egress node and specific underlay service or service entity.

SRv6 utilizes the flexibility of IPv6 to encode the service information without multiple layers. Since the Locator assigned to the egress node is a /48 all traffic within the /48 will reach the node. This leaves the remaining 80 bits to be used for identifying services and service components. IOS-XR will dynamically assign a /64 out of the /48 Locator for services. As an example a L3VPN with per-VRF SRv6 SID allocation will be assigned a /64 as will an EVPN-VPWS service.

In the simplest forwarding use case the ingress node simply sets the SRv6 packet destination address to the IPv6 service address. It is forwarded hop by hop based on the IPv6 DA, meaning intermediate nodes not SRv6 aware can also forward the traffic.

L3VPN Forwarding Example

In the single-domain example below, a VPNv4 L3VPN is configured between routers R1 and R3. R3 advertises the VPNv4 prefix with the appropriate parameters required for R1 to properly build the packet to R3. As you can see, there is no SRH involved in this simple example, all of the information is encoded in the VPNv4 advertisement to allow R1 to use a single IPv6 destination address to send traffic to the appropriate service.

Traffic will be routed across the proper Flex-Algo path. R4 will utilize standard LPM (longest prefix match) routing using the Algo 128 topology.

The uDT4 behavior means “decapsulate the packet and perform an IPv4 routing lookup”. The local SID fccc:1:215:e004::/64 is assigned to the specific L3VPN VRF.

L3VPN Configuration Example

This is an example of a 3-node L3VPN using SRv6. Each node has already been assigned a SRv6 Locator to be used with this L3VPN. In this case we are using the Locator defined for the base algo, LocAlgo0. Service SIDs will be allocated from the fccc::103::/48 block. This service is carrying IPv4 routes over SRv6 and utilizes the
uDT4 behavior type.

Egress PE Configuration

Locator Configuration

segment-routing
 srv6
  locators
   locator LocAlgo0
    micro-segment behavior unode psp-usd
    prefix fccc:0:103::/48

VRF Configuration The VRF configuration is identical to non-SRv6 use cases.

BGP Configuration SRv6 must be explicitly enabled for services utilizing SRv6.
In IOS-XR 7.8.1 per-vrf is the only SID allocation mode supported.

router bgp 100
 vrf l3vpn-v4-srv6
  rd 100:6001
  address-family ipv4 unicast
   segment-routing srv6
    locator LocAlgo0
    alloc mode per-vrf
   !
   redistribute connected
  !
 !
!

SID Allocation Here we see the two SIDs allocated to each address family.

RP/0/RP0/CPU0:cst-a-pe3#show segment-routing srv6 sid detail fccc:0:103:e004::
Sun Jan  8 16:54:01.080 UTC

*** Locator: 'LocAlgo0' ***

SID                         Behavior          Context                           Owner               State  RW
--------------------------  ----------------  --------------------------------  ------------------  -----  --
fccc:0:103:e004::           uDT4              'l3vpn-v4-srv6'                   bgp-100             InUse  Y
  SID Function: 0xe004
  SID context: { table-id=0xe0000005 ('l3vpn-v4-srv6':IPv4/Unicast) }
  Locator: 'LocAlgo0'
  Allocation type: Dynamic
  Created: Nov 28 20:20:21.184 (5w5d ago)

L3VPN Route on Ingress Node

Here we see the route received from the egress node. There is a new SubTLV containing the SRv6 encoding type and we can see the service SID has been encoded as part of the BGP label TLV.

RP/0/RP0/CPU0:cst-a-pe8#show bgp vrf l3vpn-v4-srv6 64.4.4.0/24 detail
BGP routing table entry for 64.4.4.0/24, Route Distinguisher: 100:6001
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker             2215286      2215286
    Flags: 0x20041012+0x00000000;
Last Modified: Dec 20 03:42:26.946 for 2w5d
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x2000000085060005+0x00, import: 0x39f
  Not advertised to any peer
  Local
    fccc:0:103::1 (metric 120) from fccc:0:216::1 (101.0.1.50), if-handle 0x00000000
      Received Label 0xe0040
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 2215286
      Extended community: RT:100:6001
      Originator: 101.0.1.50, Cluster list: 101.0.2.202, 101.0.0.200, 101.0.1.201
      PSID-Type:L3, SubTLV Count:1, R:0x00,
       SubTLV:
        T:1(Sid information), Sid:fccc:0:103::, F:0x00, R2:0x00, Behavior:63, R3:0x00, SS-TLV Count:1
         SubSubTLV:
          T:1(Sid structure):
           Length [Loc-blk,Loc-node,Func,Arg]:[32,16,16,0], Tpose-len:16, Tpose-offset:48
      Source AFI: VPNv4 Unicast, Source VRF: l3vpn-v4-srv6, Source Route Distinguisher: 100:6001

Forwarding Entry on Ingress Node

In the forwarding entry we see the SRv6 encapsulation with a SID list of the service address. This address is used as a the destination address of the IPv6 packet sent from the ingress router. The router will utilize the /40 summary to reach the end service address.

RP/0/RP0/CPU0:cst-a-pe8#show cef vrf l3vpn-v4-srv6 64.4.4.0/24
64.4.4.0/24, version 11, SRv6 Headend, internal 0x5000001 0x30 (ptr 0x8c326328) [1], 0x0 (0x0), 0x0 (0x9016d028)
 Updated Dec 20 03:42:26.875
 Prefix Len 24, traffic index 0, precedence n/a, priority 3
  gateway array (0xa4a8b360) reference count 1, flags 0x2010, source rib (7), 0 backups
                [1 type 3 flags 0x48441 (0xa5ba6658) ext 0x0 (0x0)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Dec 20 03:42:26.874
 LDI Update time Dec 20 03:42:26.874

  Level 1 - Load distribution: 0
  [0] via fccc:0:103::/128, recursive

   via fccc:0:103::/128, 619 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8df4b168 0x0]
    next hop VRF - 'default', table - 0xe0800000
    next hop fccc:0:103::/128 via fccc:0:100::/40
    SRv6 H.Encaps.Red SID-list {fccc:0:103:e004::}

    Load distribution: 0 1 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   TenGigE0/0/0/8            fe80::28a:96ff:fe4a:8078
    1     Y   TenGigE0/0/0/9            fe80::28a:96ff:fec7:e878


RP/0/RP0/CPU0:cst-a-pe8#show route ipv6 fccc:0:103:e004::

Routing entry for fccc:0:100::/40
  Known via "isis ACCESS", distance 115, metric 120
  Tag 1003, type level-2
  Installed Dec  1 01:53:02.153 for 5w3d
  Routing Descriptor Blocks
    fe80::28a:96ff:fe4a:8078, from fccc:0:e::1, via TenGigE0/0/0/8, Protected, ECMP-Backup (Local-LFA)
      Route metric is 120
    fe80::28a:96ff:fec7:e878, from fccc:0:e::1, via TenGigE0/0/0/9, Protected, ECMP-Backup (Local-LFA)
      Route metric is 120
  No advertising protos.

L2VPN EVPN-VPWS

EVPN-VPWS is configured similar to the MPLS use case with the exception of specifying the transport type as srv6.

RP/0/RP0/CPU0:cst-a-pe3#show run l2vpn xconnect group EVPN-VPWS-SRv6_MH
Sun Jan  8 17:22:09.140 UTC
l2vpn
 xconnect group EVPN-VPWS-SRv6_MH
  p2p EVPN-VPWS-SRv6_MH
   interface TenGigE0/0/0/5.600
   neighbor evpn evi 4600 service 600 segment-routing srv6
   !
  !
 !
!

L2VPN EVPN-VPWS State

The SRv6 behavior of uDX2 means micro-SID behavior with L2 cross-connect. This is a multi-homed service on the remote side, so there are two service SIDs listed as remote endpoints.

Group EVPN-VPWS-SRv6_MH, XC EVPN-VPWS-SRv6_MH, state is up; Interworking none
  AC: TenGigE0/0/0/5.600, state is up
    Type VLAN; Num Ranges: 1
    Rewrite Tags: []
    VLAN ranges: [600, 600]
    MTU 1500; XC ID 0x264; interworking none
    Statistics:
      packets: received 480066518, sent 480034205
      bytes: received 480066514256, sent 479074130038
      drops: illegal VLAN 0, illegal length 0
  EVPN: neighbor ::ffff:10.0.0.1, PW ID: evi 4600, ac-id 600, state is up ( established )
    XC ID 0xc0000031
    Encapsulation SRv6
    Encap type Ethernet
    Ignore MTU mismatch: Enabled
    Transmit MTU zero: Enabled
    Reachability: Up

      SRv6              Local                        Remote
      ----------------  ---------------------------- --------------------------
      uDX2              fccc:0:103:e002::            fccc:0:214:e002::
                                                     fccc:0:215:e002::
      AC ID             600                          600
      MTU               1514                         0
      Locator           LocAlgo0                     N/A
      Locator Resolved  Yes                          N/A
      SRv6 Headend      H.Encaps.L2.Red              N/A
    Statistics:
      packets: received 480034205, sent 480066518
      bytes: received 479074130038, sent 480066514256

EVPN ELAN

In this case we are using Algorithm 128, the low latency Flex Algo for the end to end path between the ingress node and egress node.

Egres PE EVPN Configuration

evpn 
  evi 4500 segment-routing srv6
    bgp
    route-target import 100:4500
    route-target export 100:4500
    !
    advertise-mac
    !
    locator LocAlgo128
  !
!

Egress PE BVI Configuration

l2vpn
 bridge group srv6_evpn_MH
  bridge-domain srv6_evpn_MH_1
   interface Bundle-Ether25.4500
   !
   evi 4500 segment-routing srv6
   !
  !
 !
!

Egress PE SRv6 SID Allocation

The EVPN detailed output shows the two SRv6 SIDs allocated for the service. These are allocated from the Algo128 Locator block. Unicast and BUM are handled by different labels in MPLS based EVPN, and with SRv6 use two separate SIDs one for the uDT2U unicast behavior and one for the uDT2M multicast behavior.

RP/0/RP0/CPU0:cst-a-pe7#show evpn evi vpn-id 4500 detail

VPN-ID     Encap      Bridge Domain                Type
---------- ---------- ---------------------------- -------------------
4500       SRv6       srv6_evpn_MH_1               EVPN
   Stitching: Regular
   Unicast SID:  fccc:1:215:e000::
   Multicast SID:  fccc:1:215:e001::
   E-Tree: Root
   Forward-class: 0
   Advertise MACs: Yes
   Advertise BVI MACs: No
   Aliasing: Enabled
   UUF: Enabled
   Re-origination: Enabled
   Multicast:
     Source connected   : No
     IGMP-Snooping Proxy: No
     MLD-Snooping Proxy : No
   BGP Implicit Import: Enabled
   VRF Name:
   SRv6 Locator Name: LocAlgo128
   Preferred Nexthop Mode: Off
   BVI Coupled Mode: No
   BVI Subnet Withheld: ipv4 No, ipv6 No
   RD Config: none
   RD Auto  : (auto) 101.0.2.52:4500
   RT Auto  : 100:4500
   Route Targets in Use           Type
   ------------------------------ ---------------------
   100:4500                       Import
   100:4500                       Export

*** Locator: 'LocAlgo128' ***

SID                         Behavior          Context                           Owner               State  RW
--------------------------  ----------------  --------------------------------  ------------------  -----  --
fccc:1:215:e000::           uDT2U             4500:0                            l2vpn_srv6          InUse  Y
fccc:1:215:e001::           uDT2M             4500:0                            l2vpn_srv6          InUse  Y

MPLS and SRv6 Migration

In 7.8.1 IOS-XR supports two transition technologies used to interwork between traditional MPLS and SRv6 domains. Interworking between different data plane
types can take place using transport layer interworking or service layer interworking. The transition methods supported in CST SRv6 1.0 and IOS-XR 7.8.1 utilize service interworking and support IPv4 and IPv6 L3VPN services.

SRv6 and MPLS Service Interworking Gateway

IETF draft draft-agrawal-spring-srv6-mpls-interworking-10 covers the semantics of the SRv6 and MPLS gateway functionality. A gateway node translates L3VPN service routes and their associated data plane forwarding information between SR-MPLS and SRv6 endpoints.
In CST SRv6 1.0 the ASR 9000 and NCS 5500 series support this functionality using per-VRF MPLS label and SRv6 SID allocation.

vrf gw-l3vpn-v4-srv6
 address-family ipv4 unicast
  enable label-mode
  segment-routing srv6
  import route-target
   100:6200 stitching
   100:6210
  !
  export route-target
   100:6200 stitching
   100:6210
  !
 !
!
router bgp 100
 nsr
 bgp router-id 101.0.0.3
 bgp redistribute-internal
 bgp graceful-restart
 segment-routing srv6
  locator LocAlgo0
 !
neighbor 101.0.2.202
  use neighbor-group SvRR
  address-family vpnv4 unicast
   import reoriginate stitching-rt
   route-reflector-client
   advertise vpnv4 unicast re-originated
   next-hop-self
  !
  address-family vpnv6 unicast
   import reoriginate stitching-rt 
   route-reflector-client
   advertise vpnv6 unicast re-originated 
  !
!
 neighbor fccc:0:10::1
  use neighbor-group SvRR-Client-srv6
  address-family vpnv4 unicast
   import stitching-rt reoriginate 
   route-reflector-client
   encapsulation-type srv6 
   advertise vpnv4 unicast re-originated stitching-rt 
   next-hop-self
  !
  address-family vpnv6 unicast
   import stitching-rt reoriginate
   route-reflector-client
   encapsulation-type srv6
   advertise vpnv6 unicast re-originated stitching-rt 
   next-hop-self
  !
 !

The interworking gateway uses the concept of a stitching Route Target to identify prefixes requiring re-origination using the opposite data plane. L3VPN prefixes are advertised to the IPv4 BGP neighbor using the MPLS data plane and prefixes advertised to the SRv6 BGP neighbor using the SRv6 data plane. The gateway node is always in the data path for service prefixes being translated.

The folowing shows the data plane in the MPLS to SRv6 direction

In-Depth SRv6 to MPLS Service Interworking Documentation

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-8/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-78x/configure-srv6-micro-sid.html#id_133508

Dual-Connected PE

Dual Connected PE allows the seamless migration of L3VPN PE routers from the MPLS to SRv6 data plane. In the dual-connected PE scenario the PE can communicate with MPLS and SRv6 neighbors within the same VRF. By default, IOS-XR will advertise prefixes using an MPLS label, advertising with an SRv6 SID requires the encapsulation-type srv6 keyword. In the case below, routes advertised to the 101.0.2.202 neighbor will use the default MPLS label, routes advertised to fccc:0:10::1 will use the SRv6 encapsulation. The PE node will properly process incoming packets using the MPLS label or SRv6 SID.

vrf dual-l3vpn-v4-srv6
 address-family ipv4 unicast
  enable label-mode
  segment-routing srv6
  import route-target
   100:7200 
   100:7210
  !
  export route-target
   100:7200 
   100:7210
  !
 !
!
router bgp 100
 segment-routing srv6
  locator LocAlgo0
 !
neighbor 101.0.2.202
  use neighbor-group SvRR-MPLS-ONLY
  address-family vpnv4 unicast
   route-reflector-client
   next-hop-self
  !
  address-family vpnv6 unicast
   route-reflector-client
   next-hop-self
  !
!
 neighbor fccc:0:10::1
  use neighbor-group SvRR-SRV6-ONLY
  address-family vpnv4 unicast
   route-reflector-client
   encapsulation-type srv6 
   next-hop-self
  !
  address-family vpnv6 unicast
   route-reflector-client
   encapsulation-type srv6
   next-hop-self
  !
 !

SRv6 Automation

Crosswork Network Controller 4.1

Crosswork Network Controller 4.1 supports the provisioning and visualization of SRv6 domains and SRv6-TE Policies. CNC also supports provisioning L2VPN EVPN-VPWS and L3VPN services utilizing an SRv6 data plane.

The Traffic Engineering dashboard gives summary information for all TE path types

Selecting an SRv6-TE Policy will highlight the end to end path across domains

Selecting the ellipses and “details” will show details about the policy

We can now see the full details of the SRv6-TE policy incuding the uSID list which has been created to build the end-to-end path across IGP instances. Since we are crossing two domains we have two additional micro-SIDs at cst-pa1 and cst-pe3. The last SID is the egress node, a-pe7.

Additional Resources

Converged SDN Transport Design

High Level Design Guide: https://xrdocs.io/design/blogs/latest-converged-sdn-transport-hld Implementation Guide: https://xrdocs.io/design/blogs/latest-converged-sdn-transport-ig

Cisco Segment Routing Home

https://segment-routing.net contains many blogs, demo videos, and configuration guides for SRv6 and SRv6 Micro-SID.

SRv6 CCO Documentation

SRv6 Micro-SID Configuration Guide for ASR 9000: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-8/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-78x/configure-srv6-micro-sid.html
SRv6 Traffic Engineering Configuration Guide for ASR 9000: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-8/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-78x/configure-srv6-traffic-engineering.html

SRv6 Micro-SID Configuration Guide for NCS 5500: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/segment-routing/78x/b-segment-routing-cg-ncs5500-78x/configure-srv6-micro-sid.html
SRv6 Traffic Engineering Configuration Guide for NCS 5500: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/segment-routing/78x/b-segment-routing-cg-ncs5500-78x/configure-srv6-traffic-engineering.html