Dear colleagues, [sorry for cross-posting, but alas, the work seems to be so scattered across IETF WG, that it is hard to reach stakeholders through a single WG mailing list. At least as long as we have not decided to have a common solution WG via MSR6 ;-)]
The co-authors just posted subject draft: https://datatracker.ietf.org/doc/draft-eckert-msr6-rbs/ I would like to encourage you to check it out and let us know if you are interested to help work on it as co-authors/contributor. I did ask the MSR6 BOF chairs for a slot to present it, and our thoughts on the overall MSR6 concept at the BOF. This draft is an update from the prior draft-xu-msr6-rbs, proposing a particular variant of an MSR6 IPv6 routing header. Let me highlight three areas of specific interest: a) Inclusion of destination address field in the MSR6/RBS IPv6 routing (extension) header. The header supports native IPv6 multicast source routing with intent to be aligned with the SRv6/SRH architecture, specifically by including a field to carry the IPv6 multicast destination address, eliminating potentially another redundant IPinIP encapsulation to carry it. This enhancement should make this routing header an immediate replacement of stateful native IPv6 multicast in native IPv6 networks (with/without SRv6) with a stateless source-routing/tree-steering solution. This should be especially beneficially to transition existing stateful PIM IPv6 multicast deployments in native-IPv6 / SRv6 networks because it minimizes the overall changes required to eliminate stateful trees in IPv6 multicast, which is the main operational, scalability, and performance concern of operators with IPv6 multicast. Note that this also allows to use pre-existing MVPN control plane signaling via BGP or PIM, both of which rely on IPv6 multicast group addresses to indicate VPN groups (PMSI). Of course, this field could also hold a SID (maybe we should also turn multicast group addresses into SIDs ?), therefore allowing us to apply the more flexible IPv6 programmability to IPv6 MVPNs, in the same way they can be used for the unicast part. It is optional, so by not including it, one could equally design further header-space optimized services, such as L2.5'ish, maybe L2VPN. b) Enhanced RBS structure The "Recursive Bitstring Structure" (RBS) for compact encoding of the engineered multicast tree has been improved to minimize per-steering-hop rewrite. It now does not require rewrite of the complete RBS structure (as in our prior draft-xu-msr6-rbs), but instead by incrementing two offset fields into the RBS structure, pretty similar to decreasing the Segments Left in the SRH header. This minimizes the write-cycles for high-speed router in the packet header and avoids having to change the packet/header length along the path (only 24 more bits rewrite on top of the 128 bit IPv6 destination address rewrite required by RFC8200). c) Efficiency = use for MSR6 TE and BE mode The RBS structure primarily supports what MSR6 calls the "Traffic Engineering" mode, by allowing to have traffic-steered forwarding & replication, but our (initial) simulations have shown that the performance in large SP networks (with many PE) can actually be better than the multiple "flat bitstrings" as in RFC8279 or draft-lx-msr6-rgb-segment, so msr6-rbs should be able to also quite well provide what MSR6 calls the BE (non TE) solution. [ Hint: the 4 MVPN-PE you need to replicate to are sadly in 4 different flat bitstrings, so you need to send 4 packets, whereas in RBS you can always encode any set of a small number of PE into a single RBS structure. ] Hope this all sounds interesting and makes you at least attend the MSR6 BOF ;-) Cheers Toerless _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
