Hello SPRING folks, I was redirected to this mailing list from here <https://mailarchive.ietf.org/arch/msg/v6ops/6a7Oy-xMwZ0qanvDWmAekb1kO_M/>+ here <https://mailarchive.ietf.org/arch/msg/srv6ops/IZGp7mzFO3XO1J9Jhgo1_DhKBfU/> to discuss SR-MPLS data plane with an IPv6-only control plane and IPv6-only IGP (IS-IS) underlay adjacencies (SR-MPLSv6).
I've been running into issues with this particular protocol when attempting to do IPv6-only on different vendors. And it appears the root cause stems from the lack of an official RFC spec to specify labelling behaviour in the world of SR-MPLS data plane with IPv6-only control plane and IPv6-only IGP underlay. So vendors appear to interpret and do things differently (interop doesn't appear to be widely supported, albeit with some caveats explained at the bottom of this email body). This is my observation/interpretation of how this works in Arista EOS, when the links are IPv6-only underlay and IPv6-only overlay, but the packet/payload is IPv4 (src/dst) with IPv6 next-hops: - Implicit Null - The PHP ensures the correct EtherType is used based on the L3 headers (suggesting L3 inspection) after the label is popped, and it forwards the frame based on the dst-MAC of the ultimate hop that's connected directly to the Penultimate Hop. - Explicit Null - Arista correctly forwards the frame using label 0 over the IPv6-only links from ingress to egress, ensuring that when the ultimate hop receives the frame, label 0 is looked at and then popped, and of course it's correctly "dropped" into the IPv4 routing table So far so good; this works on Arista. IS-IS handles everything; no BGP magic (like BGP-LU) is required. On other platforms, however, it doesn't appear to work at all or works partially. On Junos, what I observed was: - Implicit Null - The PHP pops label 3; the IPv4 packet is exposed; nothing gets forwarded past the penultimate hop. - Explicit Null - Label 2 is pushed into the frame (because IPv6-only underlay and control plane), the frame reaches the ultimate hop, label 2 is looked at and popped, the packet (IPv4) is dropped into the inet6.0 table, and of course it doesn't work. On the "partial" aspect, it works for VRFs (across multiple vendors but not all) because the second label in the label stack attached; signals which VRF the packet should correctly be dropped into. But this doesn't work for the global default table on some of these platforms (excluding Arista EOS). I'm sure some of you recall that in 2024 (or 2023?), EANTC did SR-MPLSv6 testing for interop, but it appears it was only tested for interop with VRFs across vendors (which should work), but not for global table-only across vendors or even within a single vendor, excluding Arista. To be precise, all of the above is completely *not* related to the generalised concept of "4PE <https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/>", which, to my understanding, relies on BGP-LU as opposed to the clean approach of Arista, where everything from ingress to egress is handled by the IGP (IS-IS), with no requirements for BGP-LU or any other protocol; just your IGP (not unlike SRv6?) is sufficient. Do we perhaps need some draft to attempt to specify this behaviour for this use case? Happy to be corrected if I missed anything. *--* Best Regards Daryll Swer Website: daryllswer.com <https://l.linktourl.es/l/5d2d15cc979f7663f283e35291cd763282f0aacd?u=2153471>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
