In the base router BGP instance, BGP routes may be originated, propagated or received with SRv6 TLVs in the prefix SID attribute. The processing rules are expected to use the following logic:
A VPN-IPv4 or VPN-IPv6 route that is imported by the base router BGP instance from a VPRN (through the VRF export process) and that already has a prefix SID attribute with an SRv6 TLV at this stage, is advertised to all VPN-IPv4/VPN-IPv6 peers of the base router BGP instance, with next-hop-self as normal. There is no option to strip the SRv6 TLV/prefix SID attribute toward any of these peers, however, there is an option to drop the entire route toward selected peers or groups. (This is similar to the effect of a BGP export policy that drops the route, but route policies cannot match routes based on presence of an SRv6 TLV.)
An IPv6 route that is imported by the base router BGP instance from another protocol’s route that was added to base router RTM (static, ospf, isis, and so on) does not have a prefix-SID attribute carrying the SRv6 TLV added to it by default. This can only be achieved by configuring the config>router>bgp>segment-routing-v6>family ipv6 add-srv6-tlvs command, but this command also has the effect of adding a prefix SID attribute with SRv6 TLV to BGP IPv6 routes received from other peers without the SRv6 TLV and that are propagated to other family IPv6 peers with next-hop-self applied.
Any BGP route received with a prefix SID attribute carrying SRv6 TLVs that is not an imported VPN-IPv4/VPN-IPv6/EVPN route or an IPv6 unlabeled unicast route is treated the same as existing routes, that is, by ignoring the prefix SID attribute contents, resolving the route based only on its BGP next hop, and propagating the prefix SID attribute to other peers unchanged.
If an IPv6 unlabeled unicast route is received with a prefix SID attribute carrying an SRv6 TLV and the config>router>bgp>segment-routing-v6>family ipv6 ignore-received-srv6-tlvs command is configured, that route is treated the same as an existing route, that is, by ignoring the prefix SID attribute contents, resolving the route based only on its BGP next hop, and propagating the attribute to other peers unchanged, irrespective of the next-hop-self.
If an IPv6 unlabeled unicast route is received with a prefix SID attribute carrying an SRv6 TLV and the config>router>bgp>segment-routing-v6>family ipv6 ignore-received-srv6-tlvs command is set to FALSE then that route should be considered resolved if and only if its BGP next hop is reachable AND the locator prefix is reachable. The datapath/FNH programming and IGP cost to reach the next hop (used by the BGP decision process) is based on the route to the locator prefix. The IPv6 route is propagated to other family IPv6 peers with the prefix SID attribute and its SRv6 TLV unchanged, irrespective of the next-hop-self.
An IPv6 unlabeled unicast route that is received without a prefix SID attribute containing an SRv6 TLV does not have a prefix-SID attribute carrying the SRv6 TLV added to it by default, even if it is re-advertised with the next-hop-self applied. This can only be achieved by configuring the config>router>bgp>segment-routing-v6>family ipv6 add-srv6-tlvs. However, this command also has the effect of adding a prefix SID attribute with SRv6 TLV to imported/redistributed routes as noted in point 2.
configure
+--router
+--segment-routing
| | +--- base-routing-instance
| | | | locator <locator-name>
| | | | +---function
| | | | | +---end-dt6 <integer>
configure
+--router
+--bgp
+--segment-routing-v6
+--source-address <ipv6-address>
+--family*
+--add-srv6-tlvs
| +--locator <locator-name>
+--ignore-received-srv6-tlvs
When an SRv6 TLV is added to an IPv6 unlabeled unicast route, the signaled behavior is End.DT6 and the SID Structure Sub-Sub-TLV contains a Transposition Offset and Transposition Length of 0.
As in the case of VPRNs, a locator (that is associated with an FPE SRv6 function) is configured for the base router. If the End.DT6 function for that locator is not statically configured, a dynamically-allocated function is reserved for the End.DT6 behavior. This is internally mapped to a label, as in the case of VPRNs.