Segment routing with IPv6 data plane (SRv6)

When assigning an IPv6 address from a classic SRv6 locator, the feature reserves the least significant octet of the locator subnet for the IPv6 address of the system (for example, system0) and loopback interfaces (for example, lo0). This is the main subnet of the locator with bits to the right of the node ID set to zero, except for the interface bits.

The following is an example of the address assignment.

This feature supports only a/128 mask value. A maximum of 255 addresses can be allocated from the last octet of the locator. A value of zero for that octet represents the identifier of the entire subnet and is not allocatable.

When assigning an IPv6 address from a micro-segment SRv6 locator, the feature reserves the least significant octet of the micro-segment locator subnet for the IPv6 address of system and loopback interfaces. This is the main subnet of the locator, with the bits to the right of the uN set to zero, except for the interface bits.

The following is an example of the address assignment.

• locator subnet: fc00:0:105::/48
• locator subnet identifier: fc00:0:105:0:0:0:0:0
• system/loopback interface addresses allowed are: fc00:0:105:0:0:0:0:00[01-FF]/128

This feature supports only a/128 mask value. A maximum of 255 addresses can be allocated from the last octet of the locator. A value of zero for that octet represents the identifier of the entire subnet and is not allocatable.

The following procedures are supported in the datapath:

• When the user configures an IPv6 address for a system interface or a loopback interface, and that address is drawn from the subnet of a locally configured locator, the CPM adds the /128 prefix into the route table and into the FIB.
  • A packet matching the more specific route in the FIB for the interface is extracted to the CPM for local interface processing.
  • A packet matching the less specific locator route of the locator in the FIB undergoes SRv6 tunnel termination processing, as usual.

• Ingress PE and transit P routers forward packets destined for this system or the loopback interface using either the more-specific interface route, if advertised in IGP or BGP by the owner router, or the less-specific locator route from which the interface address is derived.

• A packet destined for the system or a loopback interface whose IPv6 address is drawn from a local locator prefix subnet can be received with an SRH in its encapsulation. An example use case of a packet received from a transit router that forwarded it over the remote LFA or TI-LFA repair tunnel of the corresponding less-specific locator route when the repair tunnel SIDs are in USP SRH mode.

The following table lists the TLVs that micro-segment SRv6 supports in addition to the TLVs described in SRv6 IS-IS TLVs.

The following table lists the endpoint behavior codepoint for each SID function encoded in a micro-segment SRv6 SID.

When a local locator is enabled in the MT2 IPv6 unicast topology of an IS-IS instance, IS-IS advertises the following routes:

• The prefix in a top-level Multi-topology Reachable IPv6 Prefixes TLV type 237 with the MT-ID field set to 2.
• A top-level SRv6 Locator TLV type 27 that contains the locator prefix as well as the End SID sub-TLVs associated with this local locator. The locator TLV is advertised with the MT-ID field set to 2.
• The End.X or LAN End.X sub-TLV in the top-level Multi-topology Extended IS Reachability TLV (222).
• The TE Application Specific Link Attributes sub-TLV in the top level Multi-topology Extended IS Reachability TLV (222), which supports the flex-algo feature.
• The Application-Specific Shared Risk Link Group (SRLG) TLV (238).

The following table summarizes the new or modified TLVs in support of SRv6 in IS-IS MT2.

In prior releases of SR Linux, only local locator routes and local prefix routes were redistributed with an export policy between topologies MT0 and MT2 of the same IS-IS instance or different IS-IS instances. These local locators were redistributed as prefix TLVs and not as locator TLVs. In addition, the tag of the local locator was not redistributed. Routes of remote locators and remote prefixes were not redistributed.

Redistribution between MT0 and MT2 topologies of the same IS-IS instance is not allowed for either remote locator or remote prefix routes.

The MT2 local locator, remote locator, SID resolution, and programming into the tunnel table and datapath tunnel follow the same rules as those for enabling SRv6 in the single topology (MT0).

If a remote IPv6 prefix route is received in both MT0 and MT2, the route with the lowest cost (IGP metric) is selected. If both routes have the same metric, the MT0 route is selected. The selected route is programmed in the route table and FIB. If that prefix also advertised a locator TLV, the corresponding SRv6 route is updated in the route table and FIB to point to the SRv6 tunnel, which is programmed in the tunnel table.

The same selection rule applies to a locator TLV advertised with a flex-algo number in both MT0 and MT2. The selection is based on comparing the cost of the routes using the metric of that specific algorithm (IGP, TE, or latency metric). The selected SRv6 route is added to the tunnel table.

The tunnel table is not used directly in the SRv6 locator resolution, in SID resolution, or in packet forwarding. All resolution is performed in the RTM and forwarding is performed in the FIB.

Each resolved remote locator or local adjacency creates an entry in TTM (ROUTE_OWNER_SRV6_ISIS). The entries for remote locators and local adjacencies in the RTM and FIB point to the tunnel ID of this tunnel. The TTM entry is not used directly for forwarding SRv6 packets. However, the route resolution behavior for SRv6 services can be modified to preferentially resolve in TTMv6.

The SRv6 locator and adjacency routes in the route table can be used to forward the following user and CPM originated packets:

• user packets

• ICMPv6 echo request and echo reply packets as described in the SR Linux OAM and Diagnostics Guide

• UDP traceroute packets as described in the SR Linux OAM and Diagnostics Guide

Forwarding and terminating of any other CPM originated packets are not supported. Specifically, received management protocol and control plane protocol packets that are encapsulated in SRv6 are dropped.

If you configure the address of a BGP neighbor, an LDP peer, or an RSVP-TE LSP destination to match a locator prefix or a SID, packets are forwarded over the SRv6 tunnel but are dropped at the destination router.

The SRv6 processing is performed inline in the IP datapath when forwarding service packets over a shortest path SRv6 tunnel at service origination or when terminating an SRv6 packet with the service SID in the DA field of the outer IPv6 header.

The DA field of the IPv6 header contains a single SID is of the form 2001:db8:00d1:d547::

Multiple SIDs in the DA field and eventually in the SRH illustrate the following micro-segment SRv6 behavior.

Transit routers in micro-segment SRv6 illustrates the preceding example.

Node F does the same (based on matching on its own identifier).

Node D does the same but processes the packet in the service corresponding to the identifier.

It can be that the path is longer than the number of micro-SIDs that can be compressed in 128 bits. In that case, an SRH is used to convey the rest of the path. Each container in the SRH must be of the same form (a block part followed by a sequence of micro-SIDs). At some node along the path, because of the shift operations, the container in the IPv6 DA expires. At that node, micro-segment SRv6 implements a regular SRv6 END function (or END.X function if the match is on a uA).

For example, if node B receives a packet with 2001:0db8:00b1:: in the DA field, it detects that its own identifier is followed by an EoC. Node B copies the next segment or container from the SRH in the DA field.

The following steps summarize the packet processing for the transit router role. For more information about the specific processing of the SID function see RFC 8986.

1. The procedure in this step is common to the transit router role and the service termination router role.

   On the ingress IP network interface, the SRv6 feature concurrently performs two IPv6 address lookups on a received IPv6 packet:
   • A first (longest prefix match) lookup checks if the address in the outer header DA field matches either an SRv6 local locator subnet, a local service SID, a local End function, or a local End.X function. This first lookup is for the current SID.
   • A second lookup is performed on the next SID in the SRH (when the IPv6 packet has an SRH). The SRv6 feature reads next SID using the index value after decrementing the Segments-Left field.
     Note: SR Linux advertises Maximum Segments Left (MSL) MSD value in the IS-IS Maximum Segments Left MSD Type sub-TLV.

   The subsequent processing depends on the outcome of the first lookup:

   1. If the match is on a local service SID:

      • If the payload type is IPv4, IPv6, or Ethernet, the packet is forwarded to the service function processing; see step 2 in section At the egress PE for more details.

        The payload type refers to the value of the last next-header field in the processing chain of the packet. This could be the next-header field of the outer IPv6 packet, if there is no SRH. This could also be the next-header field of an expired SRH (Segments-Left = 0) for which the last SID matches the service SID.

      • If the payload type indicates any other protocol, including ICMPv6 (ICMP ping packet) and UDP (potential traceroute message when hop-limit field has a value of 1), the packet is redirected to the CPM for more processing. Protocol matching ICMPv6 ping and UDP traceroute have their packets processed as described in the SR Linux OAM and Diagnostics Guide. Other protocol packets are dropped.

        The CPM generates a specific ICMPv6 message to the address in the SA field of the processed or dropped packet depending on the protocol type and the result of the match of the address in the DA field of the packet. These ICMPv6 reply messages are summarized in the table that follows.

        Table 14. ICMPv6 reply messages to extracted SRv6 packets

        Protocol	Destination IP address match result	ICMPv6 reply(Type/code)
        ICMP echo request/reply (See SR Linux OAM and Diagnostics Guide for ICMPv6 Ping support in SRv6)	locator prefix [function | any arg]	echo reply/ping successful
        UDP / TCP (See SR Linux OAM and Diagnostics Guide for UDP Traceroute support in SRv6)	locator prefix [ function | any arg ]	dest unreachable, port unreachable
        Any other protocol	locator prefix [ function | any arg ]	ICMP Parameter Problem/SR Upper-layer Header Error
        All protocols including above	locator prefix | unsupported function	dest unreachable, communication prohibited

   2. If the match is on a local locator only:

      • If the payload type is IPv4, IPv6, or Ethernet, the packet is forwarded to the SRv6 FPE for potential service function processing; see step 2 in section At the egress PE for more information.

      • If the payload type indicates any other protocol, including ICMPv6 (ICMP ping packet) and UDP (potential traceroute message when hop-limit field has a value of 1), the packet is redirected to the CPM for more processing. Protocol matching ICMPv6 ping and UDP traceroute have their packets processed as described in the SR Linux OAM and Diagnostics Guide. Other protocol packets are dropped.

        The CPM generates a specific ICMPv6 message to the address in the SA field of the processed or dropped packet depending on the protocol type and the result of the match of the address in the DA field of the packet. These ICMPv6 reply messages are summarized in ICMPv6 reply messages to extracted SRv6 packets.

   3. If the match is on a specific local End function and the next SID lookup is not a local locator, the packet is processed as per the transit router role for these functions as detailed in step 2 that follows.

   4. If the match is on a specific local End function and the next SID resulted in a match on a local locator, the packet is processed as described in the preceding step 1.b with the next-header field used in the processing is that of the SRH.

   5. If the match is on a specific local End.X function, regardless of the next SID match outcome, the packet is processed in accordance with the transit router role for these functions; see step 2 that follows.

   6. If the match is on a regular IPv6 route or there is no match, the packet is forwarded or dropped. For forwarded packets, the destination address could match the locator prefix or a regular IPv6 prefix of a remote node.

2. The procedure in this step is specific to the transit router role.

   If the match is on a local End or End.X SID, the SID termination processing is performed on the packet.

   1. If the End or End.X SID is the last SID in the packet encapsulation, meaning there is no SRH or there are only expired SRHs (Segments-Left = 0), the packet is sent to the CPM for further processing.

      Note: The CPM processes ICMPv6 ping packets and UDP traceroute packets but drops any other protocol type. See the SR Linux OAM and Diagnostics Guide for more information about the processing of ICPMv6 echo request and reply packets and UDP traceroute packets.

   2. If the next-header in the IPv6 header is an SRH, the Segments-Left field is zero, and the next-header in the SRH is another SRH, the current SRH is removed and the remaining steps are applied on the next SRH.

   3. If the Segments-Left field is 1 and the SRH mode of the terminated SID is PSP, the SRH is removed. Otherwise, the Segments-Left field is decremented and used to read and copy the next SID into the DA field of the outer IPv6 header.

   4. Decrement the incoming outer IPv6 header hop-limit and write it into the outer IPv6 header hop-limit field of the outgoing packet.

   5. If the first SID lookup of the current SID in the FIB matched an End function, use the outcome of the second SID lookup of the next SID to forward the packet to the next hop of the next SID (in the DA field of the outer IPv6 header).

   6. If the first SID lookup of the current SID in the FIB matched an End.X function, override the outcome of the second SID lookup of the next SID with the set of next hops of the adjacency and forward the packet.

   7. If both the current and the next SIDs match a local End or End.X SID, the packet is forwarded as indicated in Forwarding behavior for back-to-back local SIDs.

      Table 15. Forwarding behavior for back-to-back local SIDs

      Current SID match	Next SID match	Forwarding action
      End	End	Process Current SID. Terminate Current SID. Copy Next SID as IPv6.DA and perform FIB lookup. Process Next SID. Terminate Next SID. If Next SID is the last SID, process the inner payload Header. If the inner payload header is IPv4 or IPv6, perform a FIB lookup to determine the forwarding decision. If the inner payload header is TCP/UDP/ICMPv6, extract the packet to CPM.
      End	End.X	Process Current SID. Terminate Current SID. Copy Next SID as IPv6.DA and perform FIB lookup. Process Next SID. Terminate Next SID. If Next SID is the last SID, process the inner payload Header. Otherwise, forward the packet to the L3 adjacency based on Next SID. If the inner payload header is IPv4 or IPv6, perform a FIB lookup to determine the forwarding decision. If the inner payload header is TCP/UDP/ICMPv6, extract the packet to CPM.
      End.X	End	Process Current SID. Terminate Current SID. Copy Next SID as IPv6.DA and forward the packet to the L3 adjacency based on the current SID. The peer node would send this packet back. Process Next SID (this has become the Current SID). If Next SID is the last SID, process the inner payload Header. If the inner payload header is IPv4 or IPv6, perform a FIB lookup to determine the forwarding decision. If the inner payload header is TCP/UDP/ICMPv6, extract the packet to CPM.
      End.X	End.X	Process Current SID. Terminate Current SID. Copy Next SID as IPv6.DA and forward the packet to the L3 adjacency based on the current SID. The peer node would send this packet back. Process Next SID (this has become the Current SID). If Next SID is the last SID, process the inner payload Header. Otherwise, forward the packet to the L3 adjacency based on Next SID. If the inner payload header is IPv4 or IPv6, perform a FIB lookup to determine the forwarding decision. If the inner payload header is TCP/UDP/ICMPv6, extract the packet to CPM.

When traffic is switched via SRv6 shortest path tunnel, flows are distributed across SRv6 tunnels and LAG links of the associated default network instance in an ECMP manner. The default hash calculation on the ingress non-default network instance is based on the existing hash procedures of an IPv4, IPv6, or an Ethernet packet. For IPv6 service packets, an option is provided to include the packet’s Flow Label field, when not zero, and to hash on the triplet {SA, DA, Flow Label}. The system load-balancing hash-options ipv6-flow-label command is used to enable this behavior on an access or network interface.

The ingress non-default network instance copies the output of the hash on the inner packet headers into the flow label field of the outer IPv6 header that it pushes on the SRv6 encapsulated packet. This is regardless of whether the flow label is used or not in the computation of the hash on the service packet.

On a transit router, the hashing of SRv6 encapsulated packets can also use the Flow Label field in the outer IPv6 header to provide more entropy to the load-balancing process of SRv6 packets. The system load-balancing hash-options ipv6-flow-label command can be configured on a network facing subinterface to hash on the triplet {SA, DA, Flow Label}. By default, a transit router only hashes on the tuple {SA, DA} in the header of a received IPv6 packet with a non-zero flow label field, including when the packet is SRv6.

The following describes the interaction of the SRv6 feature with other datapath features:

• When SRv6 is enabled on default network instance, datapath enables forwarding and receiving SRv6 encapsulated packets on all network facing sub interfaces. The datapath, however, drops an SRv6 encapsulated packet if received from or needs forwarding to a(non default network instance). A service packet received on either a compatible network instance such as default network instance or a ip-vrf network instance an be encapsulated into an SRv6 packet and forwarded via default network-instance.

• The SRv6 feature performs concurrently a couple of IPv6 address lookups on a packet received with an SRH on a default sub interface. The first lookup is for the current SID in the DA field in the header of the received SRv6 packet and the second is for the next SID in the SRH.

The following BGP extensions are supported, as defined in RFC 9252:

• The following SRv6 Service TLVs:

  • SRv6 Service TLV encoded in the BGP Prefix-SID attribute

  • SRv6 SID Information Sub-TLV (SRv6 Service Sub-TLV type 1) encoded in the SRv6 Service TLV

  • SRv6 SID Structure Sub-Sub-TLV (SRv6 Service Data Sub-Sub-TLV type 1)

• Transposition of 16 or 20 bits of the FUNCTION to the Label field of the NLRI

• Arg.FE2 arguments used for split-horizon filtering in EVPN multihoming, advertised in the EVPN AD per-ES routes with 16 bits of the argument transposed to the label field of the ESI Label extended community.

The BGP extensions are applied to the following routes by setting the behavior field in the SRv6 Services TLV, as defined in RFC 8986:

• VPN-IPv4

• VPN-IPv6

• IPv4

• IPv6

• EVPN AD per-EVI

• EVPN AD per-ES

The EVPN, VPN-IPv4, VPN-IPv6, IPv4, and IPv6 routes for the SRv6-enabled services are advertised along with the SRv6 Service TLV. The TLV format is described in RFC 9252 and shown in the following figure.

The SRv6 Service TLV encoded in the BGP Prefix-SID attribute can have two different types:

• Type 5 is used for Layer 3 service SIDs or the SIDs signaled for IP-VRF services with VPN-IP or EVPN-IFL routes. Layer 3 service SIDs are also supported for the base router along with IPv4 or IPv6 routes.

• Type 6 is used for Layer 2 service SIDs or the SIDs signaled for VPWS (or MAC-VRF) services. Type 6 is supported along with AD per-EVI and per-ES routes for Epipes.

  Note: MAC-VRF is not supported in SR Linux.

The SRv6 Service TLV may contain an unordered list of sub-TLVs, but currently the SRv6 Service TLV is advertised with only one sub-TLV: the SRv6 SID Info sub-TLV (type 1). This sub-TLV encodes the following information:

• For the SID value, the entire 128-bit SID is allocated to the service, including the locator configured for the service and the allocated FUNCTION (which can be dynamically allocated or statically configured on the service). The ARGUMENT is always 0.

• SID flags are all zero.

• Endpoint behavior encodes the behavior as in RFC 8986, in decimal values. The following values are relevant for SR Linux:

  • 18 – End.DT6

  • 19 – End.DT4

  • 20 – End.DT46

  • 21 – End.DX2

  • 24 – End.DT2m (only for AD per-ES routes)

• One SID Structure Sub-Sub-TLV (Service Data Sub-Sub-TLV type 1)

The SID Structure Sub-Sub-TLV is always included in routes with label fields and always uses the following values when advertised:

• Locator Block Length - encodes the length of the block configured in the locator for the service, default value of 32

• Locator Node Length - the length of the node configured in the locator for the service, default value of 16

• Function Length - default value of 16

• Argument Length - 0 (default) or 16 (configured)

• Transposition Length (TL) - 20 for EVPN and VPN-IP routes with full SIDs and 16 for micro segments and 0 for IP routes in the base router

• Transposition Offset (TO)

  • for EVPN and VPN-IP routes:

    • If the Function Length equals 20 or 16, the Transposition Offset (TO) value equals the prefix length configured in the locator

    • If the Function Length is greater than 20, the TO value equals:

      (prefix length configured in the locator) + (FunctLength 20)

  • for IP routes in base router, TO value is always 0

• For IP routes in the base router, the TO value is always 0.

The purpose of the SID Structure Sub-Sub-TLV is twofold:

• Advertise the structure of the SRv6 SID used in the service, including the length of the Locator block, node, function and argument.

• Support transposition procedures for efficient service route packing. The FUNCTION is transposed into the label field in the route’s NLRI. Because the rest of the SID is common for routes of the same type in the service, this transposition operation supports efficient packing of routes into the same BGP update.

The following figure shows how the FUNCTION part of the SID is transposed. This example illustrates how transposition works for EVPN-VPWS, and it would be similar for VPN-IP routes.

In the preceding figure, PE6 is configured with an Epipe that uses a configured locator with LB length = 40 bits and LN length = 24 bits. The Function length is set at 24, and 20 bits are always transposed into the NLRI (non-configurable). In the preceding figure, the following rules apply:

• On reception, the router can build any SID out of the received route, irrespective of transposition, as long as the lengths are correctly encoded.

• On transmission, the system performs a transposition for VPN-IP and EVPN service routes as follows:

• The following rules apply for Function Length:

  • If Function Length is greater than 20 in the Locator configuration, the function bits are put at the right-most bits of the L bits. For example, if LB LEN is 40 bits and the LN Len is 24 bits:

  • If Function Length = 20, the entire function is transposed into the label field, and the following is signaled in the route:

    Length [LBL, LNL, FL, AL] : [40, 24, 20, 0]

    TL:20, TO:64

The supported service routes for SRv6 are:

• IPVRF services, configured for SRv6:

  • VRF -IPv4 routes

  • VRF -IPv6 routes

• Base router

  • IPv6 routes, if configured for SRv6 in IPv6 family

  • IPv4 routes, if configured for SRv6 in IPv4 family

• Epipe services, configured for SRv6:

  • EVPN AD per-EVI routes

  • EVPN AD per-ES routes, for VPWS that make use of Ethernet Segments

As specified in RFC 9252, BGP Overlay Services Based on Segment Routing over IPv6 (SRv6), the egress PE may set the next hop to any of its IPv6 addresses. When the IPv6 address value is not covered by the SRv6 locator from which the SRv6 Service SID is allocated, the ingress PE performs reachability checks for the SRv6 Service SID in addition to the BGP next-hop reachability procedures.

Route-matching criteria and route-modifying actions that are specific to BGP routes carrying SRv6 TLVs can be configured for route policies.

For information about BGP-LS extensions for SRv6 supported in SR Linux, see the "BGP Link-State" section of the SR Linux Routing Protocols Guide.

SRv6 for IP-VRF allows the transport of IP-VRF-related IPv4 and IPv6 data across an SRv6-enabled network. To this end, IP-VRF-related data is sent to an ingress SRv6 router, where it is encapsulated and forwarded via an SRv6 tunnel. The SRv6 tunnel transports the encapsulated data across the SRv6-enabled network to an egress SRv6 router, where it is decapsulated and forwarded further as IP-VRF-related data. SRv6-tunneled data is encapsulated using an IPv6 header, where the destination address is a unique SRv6 segment identifier (SID), and is processed and forwarded in the IPv6 data plane.

An SRv6 SID is a preconfigured 128-bit routable IPv6 prefix address that is encoded in three parts: a locator, a function, and an argument. The locator is a summary IPv6 prefix for a set of SRv6 SIDs instantiated on an SRv6-capable router. It is used to route the data within the IPv6 transport network. Each participating SRv6-capable router needs its unique locator, based on a common block that all participating SRv6-capable routers share in the IPv6 address space. The function is an opaque identifier that indicates the local behavior at the endpoint of an SRv6 segment. The focus in this topic is on the SRv6 End.DT4 and the SRv6 End.DT6 functions for the IP-VRF, performing a prefix lookup in the IP-VRF service IPv4 route table (End.DT4) or in the IP-VRF service IPv6 route table (End.DT6). The argument is not used in SR Linux and is set to all zeros.

The local router installs its locator prefix in its IPv6 route table and forwarding information base (FIB), and advertises its locator prefix in IS-IS with the SRv6 locator sub-TLV. Each remote router populates its route table and FIB with the received locator prefixes, including the tunneled next hop to the originating router. Each remote router also populates its IP-VRF service route table with the received network prefixes, including the tunneled next hop to the IP-VRF of the originating router.

Service providers prefer an optimized, standardized, and unified control plane for VPNs. EVPN-VPWS is supported in SRv6 networks that may also run other EVPN-based services, such as EVPN-based VPLS services or Layer 3 EVPN IFL (interface-less) services. From a control plane perspective, EVPN-VPWS is a simplified point-to-point version of RFC 7432, because there is no need to advertise MAC/IP advertisement routes in VPWS. EVPN-VPWS is described in RFC 8214, and the signaling aspects to support SRv6 are specified in RFC 9252.

EVPN-VPWS supports all-active multihoming (per-flow load-balancing multihoming) as well as single-active multihoming (per-service load-balancing multihoming), using the same Ethernet segments (ESs) used for EVPN-based VPLS services. EVPN-VPWS uses route type 1 and route type 4; it does not use route types 2, 3, or 5, because MAC/IP routes, inclusive multicast routes, or IP-prefix routes are not required.

EVPN-VPWS uses AD per-EVI routes, and optionally, if multihoming is used, AD per-ES and ES routes are required:

• route type 1 - Auto-discovery per EVPN instance (AD per-EVI). This route type is used in all EVPN-VPWS scenarios, with or without multihoming. For EVPN-VPWS, the Ethernet tag field is encoded with the local attachment circuit (AC) of the advertising PE. This value is configured using the network-instance protocols bgp-evpn bgp-instance vpws-attachment-circuits local local-attachment-circuit ethernet-tag command. The route distinguisher (RD), label, and the Ethernet segment identifier (ESI) are encoded as for EVPN-based VPLS. The label field is used as service label. In case of multihoming, AD per-EVI routes containing the same ESI are used to provide aliasing and a backup path to the PEs part of the ES. The L2 MTU field is encoded with the service MTU configured in the Epipe. The flags used for EVPN-VPWS are:

  • Flag C: this flag is set if a control word is configured in the service; however, this does not apply if the transport is SRv6.

  • Flag P: this flag is set if the advertising PE is a primary PE.

    • If no multihoming is used, there is no primary PE (P = 0).

    • In all-active multihoming, all PEs in the ES are primary (P = 1).

    • In single-active multihoming, only one PE per-EVI in the ES is a primary (P = 1).

  • Flag B: this flag is set if the advertising PE is a backup PE.

    • Flag B is only set in case of single-active multihoming and only for one PE, even if more than two PEs are present in the same single-active ES. The backup PE is the winner of the second designated forwarder (DF) election (excluding the DF). The remaining non-DF PEs send B = 0.

  If there is no multihoming, the ESI, flag P, and flag B are set to zero.

• route type 1 - Auto-discovery per Ethernet segment (AD per-ES). This route type has the same encoding as for EVPN-based VPLS. The AD per-ES route is only used in multihoming scenarios where it is advertised from the PE for each ES. This route type carries the ESI label (used for split-horizon, but only for VPLS services and not for Epipe services) and can affect procedures such as the DF election, as well as the aliasing on remote PEs.

• route type 4 - ES route. This route type has the same encoding as for EVPN-based VPLS. The ES route is only used in multihoming scenarios. This route type advertises a local configured ES. The exchange of this route type can discover remote PEs that are part of the same ES and the DF election algorithm among them.