GB/T 44887.5-2024IPv6 evolution technical requirements-Part 5: SRv6-based VPN (English PDF)

1 Scope

This document specifies the technical requirements for the architecture of the SRv6-based VPN network, for the SRv6 service TLV, for the layer 3 services over the SRv6 VPN network and for the layer 2 services over the SRv6 VPN network.

This document applies to the development, testing and application of SRv6 VPN technology in network devices.

2 Normative references

The contents of the following documents constitute indispensable provisions of this document through normative reference in the text. For dated references, only the version corresponding to that date applies; for undated references, the latest version, including all amendments, applies.

IETF RFC 2545 Use of BGP-4 multiprotocol extensions for IPv6 inter-domain routing; IETF RFC 4659 BGP-MPLS IP virtual private network (VPN) extension for IPv6 VPN; IETF RFC 7432 BGP MPLS-based Ethernet VPN; IETF RFC 8950 Advertising IPv4 network layer reachability information (NLRI) with an IPv6 next hop; IETF RFC 8986 SRv6 network programming; IETF RFC 9136 IP prefix advertisement in EVPN; IETF RFC 9251 Internet group management protocol (IGMP) and multicast listener discovery (MLD) proxies for Ethernet VPN (EVPN); IETF RFC 9256 Segment routing policy architecture.

3 Terms and definitions

The following terms and definitions apply to this document.

3.1 segment routing: a source routing technique applied to MPLS networks or to IPv6 networks that customizes the service path. Note: in an MPLS network the segment is encoded as an MPLS label; in an IPv6 network the segment takes the form of an IPv6 address and the forwarding path is indicated by the segment routing header.

4 Abbreviations

The following abbreviations apply to this document. AFI: address family identifier. BGP: border gateway protocol. CE: customer edge. ES: Ethernet segment. ESI: Ethernet segment identifier. EVPN: Ethernet virtual private network. IANA: Internet Assigned Numbers Authority. IGMP: Internet group management protocol. IPv4: Internet protocol version 4. IPv6: Internet protocol version 6. L3VPN: layer 3 virtual private network. MAC: media access control. MPLS: multi-protocol label switching. NLRI: network layer reachability information. PE: provider edge. SAFI: subsequent address family identifier. SID: segment identifier. SLA: service-level agreement. SR: segment routing. SRH: segment routing header. SRv6: segment routing over IPv6. TLV: type, length and value. VLAN: virtual local area network. VPN: virtual private network. VPWS: virtual private wire service. VRF: virtual routing and forwarding.

5 Architecture of the SRv6-based VPN network

An SRv6-based VPN network is a layer 2 or layer 3 overlay network that uses BGP as the control plane and SRv6 as the data plane. An SRv6 service SID is an SRv6 segment identifier associated with a specific service behaviour, including but not limited to the End.DT behaviour (decapsulate and look up the VRF table) or the End.DX behaviour (decapsulate and cross-connect to the next hop) in an L3VPN service. The SRv6-based VPN network uses BGP to advertise the reachability of a specific service prefix from the egress device to the ingress device, uses the existing BGP messages to carry the information of the SRv6 service SID between edge devices, and takes this as a way of interconnecting edge devices and building the VPN. The architecture of the SRv6-based VPN network is shown in Figure 1.

When an SRv6 service with best-effort connectivity is provided, the egress edge device shall use the BGP overlay service route message to advertise an SRv6 service SID, and the ingress edge device shall encapsulate the data payload inside an outer IPv6 header and set the outer destination address to that service SID. The underlay network between the edge devices only needs to support ordinary IPv6 forwarding.

When an SRv6 service that meets an SLA from network ingress to network egress is provided, the egress edge device shall add the BGP Color extended community attribute to the overlay service route, and the ingress edge device shall encapsulate the payload packet in an outer IPv6 header carrying an SRH extension header; that SRH contains the SID list of the SR policy associated with the corresponding SLA, and the last hop of that list shall be the SRv6 service SID associated with the route. For an underlay network node, if its SRv6 SID is part of the SID list, that node shall support the SRv6 data plane.

The SRv6 SIDs of the layer 2 and layer 3 services of the SRv6-based VPN network shall be encapsulated in the SRv6 service TLV of the BGP Prefix-SID attribute.

6.1 SRv6 service TLV

The SRv6 service TLVs are defined as two new TLVs of the BGP Prefix-SID attribute, in order to advertise the SRv6 SIDs of layer 2 and layer 3 services. The content of the TLVs shall meet the following requirements.

The SRv6 layer 3 service TLV encodes the service SID information of the SRv6-based layer 3 services, corresponding to the MPLS label that provides the same function in layer 3 service routes. Some of the behaviours that can be encoded in this TLV include but are not limited to End.DX4, End.DT4, End.DX6, End.DT6 and End.DT46.

The SRv6 layer 2 service TLV encodes the service SID information of the SRv6-based layer 2 services, corresponding to the MPLS label that provides the same function for the various EVPN route messages. Some of the behaviours that can be encoded in this TLV include but are not limited to End.DX2, End.DX2V, End.DT2U and End.DT2M.

The encoding format of the SRv6 service TLV in the BGP Prefix-SID attribute is shown in Figure 2. TLV type (1 byte): this field is a value allocated from the IANA registry BGP Prefix-SID TLV Types; the value corresponding to the SRv6 layer 3 service TLV is 5 and the value corresponding to the SRv6 layer 2 service TLV is 6. TLV length (2 bytes): it identifies the length of the data part of the TLV, in octets. Reserved (1 byte): this field is reserved; the sender shall set it to zero and the receiver ignores it. SRv6 service sub-TLVs (variable length): this field contains the information relevant to the SRv6 service, encoded as an unordered list of sub-TLVs.

When a BGP speaker receives a route carrying a BGP Prefix-SID attribute in which one or more SRv6 service TLVs are contained, and advertises that route to other peers, the following rules shall be complied with. If the next hop field is not changed when the route is advertised, the SRv6 service TLV continues to be propagated even if it contains unknown sub-TLVs and sub-sub-TLVs, and the reserved fields in the SRv6 service TLV, sub-TLVs and sub-sub-TLVs are propagated unaltered. If the next hop field is changed when the route is advertised, the SRv6 service TLV, sub-TLVs and sub-sub-TLVs shall be updated with the locally allocated SRv6 SID information, and any unknown sub-TLV or sub-sub-TLV shall be deleted.

6.2 SRv6 service sub-TLV

The encoding format of a single SRv6 service sub-TLV is shown in Figure 3, with the following format requirements.

SRv6 service sub-TLV type (1 byte): it identifies the type of SRv6 service information and is a value allocated from the IANA registry SRv6 Service Sub-TLV Types.

SRv6 service sub-TLV length (2 bytes): it identifies the length of the data part of the sub-TLV, in octets.

SRv6 service sub-TLV data part (variable length): it contains the data of the specific sub-TLV type. Besides the fixed-length data, this part also contains other SRv6 service attributes, encoded as a series of SRv6 service data sub-sub-TLVs.

6.3 SRv6 SID information sub-TLV

Type 1 of the SRv6 service sub-TLV is allocated to the SRv6 SID information sub-TLV, which contains an SRv6 SID and other attributes. The encoding format of the SRv6 SID information sub-TLV is shown in Figure 4, with the following format requirements.

SRv6 service sub-TLV type (1 byte): this field is set to 1, indicating the SRv6 SID information sub-TLV. SRv6 service sub-TLV length (2 bytes): this field identifies the total length of the data part, in octets. Reserved 1 (1 byte): the sender sets it to zero and the receiver ignores it. SRv6 SID value (16 bytes): it holds one SRv6 SID. SRv6 service SID flags (1 byte): it holds the flags of the SRv6 service SID, at present unused; the sender sets them to zero and the receiver ignores any unknown flag. SRv6 endpoint behaviour (2 bytes): it holds the SRv6 endpoint behaviour and is a value allocated from the IANA registry SRv6 Endpoint Behaviors; this field shall be set to the value 0xFFFF to indicate that no specific behaviour is signalled, unless the router wishes to signal the actual behaviour. Reserved 2 (1 byte): the sender sets it to zero and the receiver ignores it. SRv6 service data sub-sub-TLVs (variable length): this field is used to advertise the attributes of the above SRv6 SID and is encoded as a series of SRv6 service data sub-sub-TLVs.

When several SRv6 SID information sub-TLVs are present at the same time, the ingress edge device shall use the SRv6 SID of the first information sub-TLV. An implementation may provide a local policy that replaces this default behaviour.

6.4 SRv6 service data sub-sub-TLV

The encoding format of the SRv6 service data sub-sub-TLV is shown in Figure 5, with the following format requirements.

SRv6 service data sub-sub-TLV type (1 byte): it identifies the type of the sub-sub-TLV and is a value allocated from the IANA registry SRv6 Service Data Sub-Sub-TLVs. SRv6 service data sub-sub-TLV length (2 bytes): it identifies the total length of the data part of the sub-sub-TLV, in octets. SRv6 service data sub-sub-TLV data part (variable length): it contains the data of that specific type of sub-sub-TLV.

6.5 SRv6 SID structure sub-sub-TLV

Type 1 of the SRv6 service data sub-sub-TLV is allocated to the SRv6 SID structure sub-sub-TLV. The SRv6 SID structure sub-sub-TLV is encapsulated in the SRv6 SID information sub-TLV and is used to advertise the length of each individual part of the SRv6 SID; its encoding format is shown in Figure 6, with the following format requirements.

SRv6 service data sub-sub-TLV type (1 byte): this field is set to 1, identifying the SRv6 SID structure sub-sub-TLV. SRv6 service data sub-sub-TLV length (2 bytes): this field has the fixed value of 6 bytes. Locator block length (1 byte): it identifies the length of the SRv6 SID locator block, in bits. Locator node length (1 byte): it identifies the length of the SRv6 SID locator node, in bits. Function length (1 byte): it identifies the length of the SRv6 SID function field, in bits. Argument length (1 byte): it identifies the length of the SRv6 SID argument field, in bits. Transposition length (1 byte): the transposition length field, that is the length of the part of the SID that has been transposed into the MPLS label field, in bits. Transposition offset (1 byte): the transposition offset field, that is the offset position of the part of the SID that has been transposed into the MPLS label field, in bits.

In the transposition mechanism used when advertising an SRv6 service SID, the variable-length part of the SRv6 SID value, that is the function field and/or the argument field, shall be transposed and stored in the existing MPLS label field, so that the network layer reachability information of these service prefixes is carried more efficiently in the BGP update message. When an SRv6 service SID is advertised in transposed form, the SRv6 SID structure sub-sub-TLV shall be present and its length fields shall be filled in correctly, so that the receiver can restore the original SID value exactly. The transposition length field indicates the number of bits transposed and the transposition offset field indicates the starting point of the transposition operation. The transposed bits shall be removed from the SRv6 SID value and placed in the high-order part of the MPLS label field, and the original position in the SRv6 SID value shall be set to zero. When the transposition length field is zero, no transposition operation is performed and the SRv6 SID value shall be encoded in full in the SID information sub-TLV; in this case the transposition offset field shall be set to zero.

The length of the MPLS label field limits the number of bits that can be transposed from the SRv6 SID. In the IETF RFC 4364 and IETF RFC 8277 scenarios the label field shall be 20 bits long; in the IETF RFC 7432 scenario the label field shall be 24 bits long. As required by IETF RFC 8986, the sum of the locator block length, the locator node length, the function length and the argument length shall be not greater than 128 and shall be not less than the sum of the transposition length and the transposition offset fields.

The SRv6 SID structure sub-sub-TLV is optional, and it may also be present when the whole SRv6 service SID value is encoded in the SID information sub-TLV. Arguments are normally used only for certain specific behaviours, such as End.DT2M, so when arguments are not applicable the argument length field shall be set to zero.

7.1 Implementation mechanism of layer 3 services

In the implementation of layer 3 services over the SRv6 VPN network, the BGP egress edge device shall advertise the overlay service prefix together with its service SID, that SID being encapsulated in the SRv6 layer 3 service TLV of the BGP Prefix-SID attribute. The SRv6 service SID shall provide reachability between the ingress and the egress device and encodes the behaviour of an SRv6 service endpoint.

When the traffic steering of the SRv6 service is based on SPF shortest path forwarding, the ingress edge device shall encapsulate the IPv4 or IPv6 service packet in an outer IPv6 packet header and set the destination address field of the outer IPv6 header to the SRv6 service SID associated with the corresponding BGP route update message. Before using a received prefix in the BGP best path computation, the ingress edge device shall perform a resolvability check on the SRv6 service SID associated with it. If that SRv6 SID is reachable through several forwarding tables, the device will use a local policy to decide which forwarding table to use. If the local policy of the ingress edge device allows other traffic steering mechanisms to be used, the result of the resolvability check of the SRv6 service SID may be ignored.

For services over the SRv6 VPN network, the egress edge device shall set the BGP next hop field to one of the several IPv6 addresses it owns. That address may be covered by the SRv6 locator address block in which the SRv6 service SID lies. The BGP next hop field is used to track the reachability of that egress edge device.

When a BGP route received by the ingress edge device is marked with the Color extended community attribute and a valid SRv6 policy is available, the traffic steering process of the service flow shall comply with IETF RFC 9256. When the ingress edge device determines that the SRv6 service SID and the last SRv6 SID in the SID list of the SRv6 policy belong to the same SRv6 locator address block, it may leave that last SRv6 SID out when steering the traffic.

7.2 IPv4 VPN service

The details of running an IPv4 VPN service over an IPv6 network shall comply with IETF RFC 8950. In an SRv6 network the MP_REACH_NLRI is encoded as follows: the AFI takes the value 1; the SAFI takes the value 128 (unicast) or 129 (multicast); the length of the next hop network address is 24 bytes or 48 bytes; the next hop network address is the VPN-IPv6 address of the next hop with the RD set to zero; the NLRI is an IPv4-VPN route.

When the transposition scheme is used for the encoding, the label value of the IPv4-VPN NLRI shall be set to the whole or part of the content of the function field of the SRv6 SID. If the transposition scheme is not used for the encoding, the label value shall be set to the implicit null label. When the transposition scheme is used, the transposition length shall be not greater than 20 bits and not greater than the length of the function field.

The SRv6 service SID is encoded as part of the SRv6 layer 3 service TLV. The SRv6 endpoint behaviour shall be one of End.DX4, End.DT4 or End.DT46.

7.3 IPv6 VPN service

The details of running an IPv6 VPN service over an IPv6 network shall comply with IETF RFC 4659. In an SRv6 network the MP_REACH_NLRI is encoded as follows: the AFI takes the value 2; the SAFI takes the value 128; the length of the next hop network address is 24 bytes or 48 bytes; the next hop network address consists of an 8-byte RD set to zero followed by the IPv6 address of the next hop; the NLRI is an IPv6-VPN route.

When the transposition scheme is used for the encoding, the label value of the IPv6-VPN NLRI shall be set to the whole or part of the content of the function field of the SRv6 SID. If the transposition scheme is not used for the encoding, the label value shall be set to the implicit null label. When the transposition scheme is used, the transposition length shall be not greater than 20 bits and not greater than the length of the function field.

The SRv6 service SID is encoded as part of the SRv6 layer 3 service TLV. The SRv6 endpoint behaviour shall be one of End.DX6, End.DT6 or End.DT46.

7.4 Globally addressable IPv4 service

The details of running an IPv4 service over an IPv6 network shall comply with IETF RFC 8950. In this case the MP_REACH_NLRI is encoded as follows: the AFI takes the value 1; the SAFI takes the value 1; the length of the next hop network address is 16 bytes or 32 bytes; the next hop network address is the IPv6 address of the next hop; the NLRI is an IPv4 route.

The SRv6 service SID is encoded as part of the SRv6 layer 3 service TLV. The SRv6 endpoint behaviour shall be one of End.DX4, End.DT4 or End.DT46.

7.5 Globally addressable IPv6 service

The details of running an IPv6 service over an IPv6 network shall comply with IETF RFC 2545. In this case the MP_REACH_NLRI is encoded as follows: the AFI takes the value 2; the SAFI takes the value 1; the length of the next hop network address is 16 bytes or 32 bytes; the next hop network address is the IPv6 address of the next hop; the NLRI is an IPv6 route.

The SRv6 service SID is encoded as part of the SRv6 layer 3 service TLV. The SRv6 endpoint behaviour shall be one of End.DX6, End.DT6 or End.DT46.

8.1 Implementation mechanism of layer 2 services

In the implementation of layer 2 services over the SRv6 VPN network, route types 1, 2, 3 and 4 shall comply with IETF RFC 7432, route type 5 shall comply with IETF RFC 9136, and route types 6, 7 and 8 shall comply with IETF RFC 9251. The route types concerned are: the Ethernet auto-discovery route (route type 1); the MAC/IP advertisement route (route type 2); the inclusive multicast Ethernet tag route (route type 3); the Ethernet segment route (route type 4); the IP prefix route (route type 5); the selective multicast Ethernet tag route (route type 6); the IGMP join synch route (route type 7); the IGMP leave synch route (route type 8).

One or more SRv6 service SIDs shall be advertised in the form of route type 1, route type 2, route type 3 or route type 5, and the SRv6 service SID of each route type shall be encapsulated in the SRv6 layer 3 or layer 2 service TLV field of the BGP Prefix-SID attribute.

When the traffic steering of the SRv6 service is based on SPF shortest path forwarding, the ingress edge device shall encapsulate the layer 2 Ethernet service packet in an outer IPv6 packet header and set the destination address field of the outer IPv6 header to the SRv6 service SID associated with the corresponding BGP route update message. Before using a received prefix in the BGP best path computation, the ingress edge device shall perform a resolvability check on the SRv6 service SID associated with it. If that SRv6 SID is reachable through several forwarding tables, the device will use a local policy to decide which forwarding table to use. If the local policy of the ingress edge device allows other traffic steering mechanisms to be used, the result of the resolvability check of the SRv6 service SID may be ignored.

For services over the SRv6 VPN network, the egress edge device shall set the BGP next hop field to one of the several IPv6 addresses it owns. That address may be covered by the SRv6 locator address block in which the SRv6 service SID lies. The BGP next hop field is used to track the reachability of that egress edge device.

When a BGP route received by the ingress edge device is marked with the Color extended community attribute and a valid SRv6 policy is available, the traffic steering process of the service flow shall follow IETF RFC 9256. When the ingress edge device determines that the SRv6 service SID and the last SRv6 SID in the SID list of the SRv6 policy belong to the same SRv6 locator address block, it may leave that last SRv6 SID out when steering the traffic.

8.2 Ethernet auto-discovery route

The Ethernet auto-discovery route (route type 1) can be used for split horizon filtering, fast convergence and aliasing, and also for EVPN-VPWS and EVPN flexible cross-connect and for the advertisement of point-to-point service IDs. The encoding format of EVPN route type 1 in an SRv6 network is shown in Figure 7.

Auto-discovery route with ES granularity. RD: it carries the RD value of the EVI. Ethernet segment ID: it identifies an ES. Ethernet tag ID: it is set to the maximum value of that field, MAX-ET. MPLS label: when the ESI filtering method and the transposed SID encoding scheme are used, the label contains the whole or part of the content of the argument field of the SRv6 SID; otherwise the high-order 20 bits of the label are set to the implicit null label (0x000030). When the transposition scheme is used, the transposition length shall be not greater than 24 and not greater than the length of the argument field. A service SID shall be encapsulated in the SRv6 layer 2 service TLV of the BGP Prefix-SID attribute and advertised together with the auto-discovery route. The endpoint behaviour of this service SID shall be End.DT2M. When the ESI filtering method is used, this service SID indicates the Arg.FE2 SID argument of the applicable End.DT2M SID. When the local-bias method is used, this service SID may take the value zero.

Auto-discovery route with EVI (EVPN instance) granularity. Ethernet tag ID: in the EVPN-VPWS scenario it takes the value of the local service ID; where VPLS is accessed in VLAN-aware bundle mode it shall take the value of the BD-Tag that identifies the specific broadcast domain; where VPLS is accessed in port-based, VLAN-based or VLAN bundle interface mode it shall take the value 0. MPLS label: when the ESI filtering method and the transposed SID encoding scheme are used, the label shall contain the whole or part of the content of the function field of the SRv6 SID; otherwise the high-order 20 bits of the label shall be set to the implicit null label (0x000030). When the transposition scheme is used, the transposition length shall be not greater than 24 and not greater than the length of the function field. A service SID shall be encapsulated in the SRv6 layer 2 service TLV of the BGP Prefix-SID attribute and advertised together with the auto-discovery route. The endpoint behaviour of this service SID shall be End.DX2, End.DX2V or End.DT2U.

8.3 MAC/IP advertisement route

The MAC/IP advertisement route (route type 2) is used to advertise, through MP-BGP, the MAC and IP address reachability of unicast traffic to all the other edge devices of an EVPN instance. The encoding format of EVPN route type 2 in an SRv6 network is shown in Figure 8. The requirements on the MPLS label fields are as follows.

MPLS label 1: it relates to the SRv6 layer 2 service TLV. When the ESI filtering method and the transposed SID encoding scheme are used, the label shall contain the whole or part of the content of the function field of the SRv6 SID; otherwise the high-order 20 bits of the label shall be set to the implicit null label (0x000030). When the transposition scheme is used, the transposition length shall be not greater than 24 and not greater than the length of the function field.

MPLS label 2: it relates to the SRv6 layer 3 service TLV. When the ESI filtering method and the transposed SID encoding scheme are used, the label shall contain the whole or part of the content of the function field of the SRv6 SID; otherwise the high-order 20 bits of the label shall be set to the implicit null label (0x000030). When the transposition scheme is used, the transposition length shall be not greater than 24 and not greater than the length of the function field.

The service SID shall be encapsulated in the SRv6 layer 2 service TLV of the BGP Prefix-SID attribute, and optionally also in the SRv6 layer 3 service TLV, and advertised together with the MAC/IP advertisement route. Depending on whether IP address information is included, MAC/IP advertisement routes fall into two classes.

MAC/IP advertisement route that advertises the MAC only: the route contains only MPLS label 1 and the MAC address information. A service SID shall be encapsulated in the SRv6 layer 2 service TLV of the BGP Prefix-SID attribute and advertised together with the route. The endpoint behaviour of this service SID shall be End.DX2 or End.DT2U.

MAC/IP advertisement route that advertises both the MAC address and the IP address: the route contains MPLS label 1, MPLS label 2, the MAC address and the IP address. A layer 2 service SID shall be encapsulated in the SRv6 layer 2 service TLV of the BGP Prefix-SID attribute and advertised together with the route; in addition, a layer 3 service SID shall be encapsulated in the SRv6 layer 3 service TLV of the BGP Prefix-SID attribute and may be advertised together with the route. For the layer 2 service SID the endpoint behaviour shall be End.DX2 or End.DT2U; for the layer 3 service SID the endpoint behaviour shall be End.DT46, End.DT4, End.DT6, End.DX4 or End.DX6.

8.4 Inclusive multicast Ethernet tag route

EVPN route type 3 is used to advertise, through MP-BGP, the address reachability of multicast traffic to all the other edge devices of an EVPN instance. The encoding format of EVPN route type 3 in an SRv6 network is shown in Figure 9.

EVPN route type 3 shall carry the PMSI attribute, which conveys the tunnel information. The encoding format of the PMSI tunnel attribute in an SRv6 network is shown in Figure 10, with the following format requirements. Flags: set to zero. Tunnel type: the type of tunnel carried; in the EVPN scenario the tunnel type value is usually 6. MPLS label: when the ESI filtering method and the transposed SID encoding scheme are used, the label shall contain the whole or part of the content of the function field of the SRv6 SID; otherwise the high-order 20 bits of the label are set to the implicit null label (0x000030); when the transposition scheme is used, the transposition length shall be not greater than 24 and not greater than the length of the function field. Tunnel identifier: the IP address of the egress edge device.

A service SID shall be encapsulated in the SRv6 layer 2 service TLV of the BGP Prefix-SID attribute and advertised together with that route, and the endpoint behaviour of the service SID shall be End.DT2M.

8.5 Ethernet segment route

The encoding format of the Ethernet segment route (route type 4) in an SRv6 network is shown in Figure 11.

The SRv6 service TLV of the BGP Prefix-SID attribute shall not be advertised together with this route. The processing of this route is unchanged and shall comply with IETF RFC 7432.

8.6 IP prefix route

The IP prefix route (route type 5) is used to advertise, through MP-BGP, IP address reachability to all the edge routers of an EVPN instance. The IP address may contain a host IP prefix or any specific subnet. The encoding format of EVPN route type 5 in an SRv6 network is shown in Figure 12.

As regards the MPLS label, when the ESI filtering method and the transposed SID encoding scheme are used, the label shall contain the whole or part of the content of the function field of the SRv6 SID; otherwise the high-order 20 bits of the label shall be set to the implicit null label (0x000030). When the transposition scheme is used, the transposition length shall be not greater than 24 and not greater than the length of the function field.

The SRv6 service SID is encoded as part of the SRv6 layer 3 service TLV, and the endpoint behaviour of the service SID shall be End.DT4, End.DT6, End.DT46, End.DX4 or End.DX6.

8.7 EVPN multicast routes

The EVPN multicast routes (route type 6, route type 7 and route type 8) do not require an SRv6 service TLV to be advertised together with them. As for EVPN route type 4, the BGP next hop field is the IPv6 address of the egress device.

9 Handling of protocol message errors

If any error is encountered while processing an SRv6 service TLV, the details of the error shall be logged for further analysis. If several instances of the SRv6 layer 3 service TLV are encountered, all instances except the first shall be ignored. If several instances of the SRv6 layer 2 service TLV are encountered, all instances except the first shall be ignored.

An SRv6 service TLV shall be regarded as malformed in the following cases: the length of the TLV is less than 1; the length of the TLV is inconsistent with the length of the BGP Prefix-SID attribute; at least one sub-TLV is malformed.

Where the length of a sub-TLV is inconsistent with the value of the length field of the SRv6 service TLV that encapsulates it, the SRv6 service sub-TLV shall be regarded as malformed.

An SRv6 SID information sub-TLV shall be regarded as malformed in the following cases: the length of the sub-TLV is less than 21; the length of the sub-TLV is inconsistent with the value of the length field of the SRv6 service TLV that encapsulates it; at least one sub-sub-TLV is malformed.

Where the length of a sub-sub-TLV is inconsistent with the value of the length field of the SRv6 service sub-TLV that encapsulates it, the SRv6 service data sub-sub-TLV shall be regarded as malformed.

No TLV, sub-TLV or sub-sub-TLV shall be regarded as malformed merely because its type cannot be recognized. No TLV, sub-TLV or sub-sub-TLV shall be regarded as malformed merely because its value range fails a syntax check.

SRv6 overlay network services require a service SID in order to guide forwarding. If the BGP Prefix-SID attribute contains at least one malformed SRv6 service TLV, the treat-as-withdraw action shall be performed.

When the transposition length field of the SID structure sub-sub-TLV is greater than the length of the label field, or when any of the constraints on the fields of the SID structure sub-sub-TLV is not satisfied, the SRv6 SID value in the SRv6 SID information sub-TLV shall be considered invalid. When the SID structure sub-sub-TLV is advertised and the transposition scheme has not been used for the SID encoding, the transposition offset and transposition length fields shall be set to zero. A path containing a Prefix-SID attribute that carries no valid SRv6 SID information shall be considered ineligible in the process of selecting the best path for the corresponding prefix.