Re: [Msr6] 【Rewrite based on the Discussions】 Review of the Draft MSR6 Charter

[Toerless Eckert <[e-mail]>]

Sorry if this train of thought below is a bit long, i hope its useful for MSR6 folks:

IMHO (speaking for myself, not my employer), one of the key reasons for MSR6
that i have seen is that there are significant number of networks designed
against the expectation that native IPv6 hop-by-hop forwarding is the only
required and desired forwarding plane, and that other parallel forwarding
planes hop-by-hop are not desired, including IPv4, MPLS or any other novel,
non-native-IPv6 forwarding planes (unicast or multicast).  But of course this
line of preferences is not unique to IPv6.

I still remember when i had to pitch IPv4 multicast into one of those
IPv6-only SP networks just because there where gaps in the IPv6 implementation suite
back then. It was seen as a really bad workaround (even though the subscribers
didn't see a difference in their TV service that was run over it).

Likewise, we (as the industry) did first introduce Multicast VPN (MVPN) with GRE/IP encapsulation
into MPLS/VPN networks (just because there was no native MPLS multicast), and while
that GRE encap it also delivered the same service quite well (thank you very much),
operators pushed hard until vendors and finally the IETF also introduced a native MPLS
multicast forarding plane (mLDP and RSVP-TE/P2MP). Not to mention control plane:
We had technical arguably perfectly working multicast MVPN signaling via PIM,
and operators forced us (vendors) with a lot of money to re-standardize/re-implement
pretty much the same functionality with BGP because that primarily just better fit the operators
network operations/design/constraints/preferences/requirements, but only to a small extend had
actual "functional benefits".

Aka: Whatever we did in IP Multicast as vendors and/or IETF, if its not modelled as closely as possible
to what network designs do in unicast, then we have to do that more closely aligned to
unicast option sooner or later for IP multicast.

Right now wrt. to native IPv6 network we already are IMHO "later", and there is
still outside of MSR6 proposals no native IPv6 stateless multicast work in IETF even though
there are very important classes of those native IPv6 only networks that
also have stateless per-hop steering for unicast and that want a comparable
stateless solution to scale and operate native IPv6 multicast better.

In the IETF, i can think of at least two working groups representing the interest
of such network design preferences / technical requirements wrt. MSR6. Both of these
groups work for IP-v6-only hop-by-hop forwarding networks:

- ROLL for low-speed native IPv6 networks (LLN)
  RFC6554 is the stateless steering solution header developed within 6MAN
  pretty much on behalf of ROLL interest and primarily by ROLL members
  
- SPRING for primarily high-speed native IPv6 networks
  RFC8754 is the stateless steering header developed within 6MAN
  pretty much on behalf of SPRING interest and primarily by SPRING members

Now, as we have seen in the past, the groups owning network requirements
and designs for IP unicast are not necessarily the ones who have the
best experience with IP multicast, but i think those groups are very important
adjacencies for MSR6.  Of course i can see a lot of benefit for MSR6 also
in other type of networks (high speed industrial and the like),
so certainly I would NOT like to see the scope of MSR6 to be constrained to these two
groups designs - but definitely support their requirements if there are
contributors willing to work on them.

Btw: I have seen a lot references to SPRING/SRv6 in MSR6 proposals, i have
seen little?/none towards ROLL. Which is fine if there are no current MSR6
contributors interested in ROLL, but if there is interest in MSR6 to be open
to engagements from ROLL, then maybe reach out to ROLL and invite them to
MSR6 @ IETF114.

>From my side, a bit of ROLL info: A few years back, i worked for about a year in ROLL
with other folks there to discuss use of bitstring technologies in ROLL/RPL,
and there was certainly good technical interest, but in the end just
not enough critical mass for the work to proceed due to contributor cycle cound
limits (back then, including unfortunately myself). But there are a couple unique
benefits for multicast via bitstrings in ROLL/RPL networks, and not even only for
multicast - but the very same solution could equally be used for unicast (as a
compressed unicast steering header).

If there is interest to contribute to MSR6 goals from both ROLL and
SPRING communities, then MSR6 could even help foster a common
MSR6 extension header design (even if requiring multiple options across 
those different market spaces). The fragmentation of knowledge between ROLL
and SPRING and varous other factors made this a no-option in the unicast case.

I will refrain to make explicit suggestions if/how any of this makes
sense for a charter text, but just wanted to mention it as hopefully helpfull
thoughts for people interested in MSR6. Hopefully this was not too long.

Cheers
    Toerless

On Wed, Jun 29, 2022 at 03:03:09PM -0400, Alvaro Retana wrote:
> On June 29, 2022 at 3:37:09 AM, Aijun Wang wrote:
> 
> 
> Aijun:
> 
> Hi!
> 
> > Based on the discussions and the newest version of MSR6 charter (ver5.0) on
> > https://github.com/MSR6-community/IETF-113-MSR6-BOF-Request/blob/main/BOF%20Charter%20v5.0,
> > I try to rewrite the contents, please see whether the following contents
> > reflect the key motivation and aims of MSR6:
> 
> Thanks for looking at this.
> 
> I like the fact that you removed network characteristics from the
> charter.  I agree that the use cases should reflect them.
> 
> However, some of the text you propose sounds speculative and too much
> on the marketing side for my taste.  Keep in mind that the charter
> should reflect what the WG will do -- and not sell the potential
> advantages of the new technology.
> 
> I have some specific comments:
> 
> 
> > Multicast Source Routing (MSR) is one promising way to deliver the multicast
> > traffic within the network, which can alleviate the pressures on the network
> > by eliminating the per flow status in intermediate nodes, as that
> > accomplished by the source routing for unicast.
> 
> "one promising way" -- this phrase gives the impression that there are
> other solutions and that MSR6 is a possibility but maybe not the right
> one.
> 
> "alleviate the pressures" -- very abstract and assumes that "the
> pressures" are only related to per-flow state.
> 
> "as that accomplished by the source routing for unicast" -- no need to
> compare with other technology.  Also, this is a multicast charter.
> 
> 
> > With the rapid adoption and deployment of IPv6 technologies in network, it is
> > desirable to deliver the multicast traffic on the IPv6 only network, which
> > can utilize the existing and on-development emerging IPv6 technologies.
> > However, current multicast source routing solution can’t incorporate various
> > IPv6 extension headers seamlessly.
> 
> "rapid adoption and deployment of IPv6..." -- as I mentioned before,
> MSR6 already talks about the technology working over IPv6, there's no
> need to position it as important.  We all know it is. :-)
> 
> 
> > The “Multicast Source Routing in IPv6 Network (MSR6)” working group will
> > define the IPv6 based multicast source routing solution for abundant
> > multicast services within large network scale. The extensibility of the
> > solution and the integration with other IPv6 technologies are expected to
> > improve upon the current solutions.
> 
> "abundant multicast services within large network scale" -- This
> sounds like a network characteristic, which should be felt to the use
> cases to scope.
> 
> "improve upon the current solutions" -- If current solutions can
> address the use cases then we don't have a reason for the WG. :-(  We
> don't need to compare MSR6 with any other solution.  At the BOF you
> will want to show that there are use cases that need new solutions
> (not just "better") ones.
> 
> 
> > The scope of MSR6 WG includes multicast source routing on native IPv6,
> > solutions for best effort/traffic engineering requirements, the management
> > and telemetry of MSR6 based multicast services etc.
> 
> Except for the "etc." at the end (which opens the door for much more),
> this is a good summary of the scope.
> 
> 
> I still think that the introductory paragraphs in the current version
> of the charter are more to the point.  We can add this last one you
> suggest:
> 
>    MSR6 (Multicast Source Routing over IPv6) defines multicast replication as
>    a Layer 3 function.  It reuses existing IPv6 headers, functions, and
>    capabilities to forward packets through non-multicast nodes, and adds no
>    flow state at intermediate network nodes.
> 
>    The definition of new IPv6 Extension Headers may be required by the use
>    cases.  The MSR6 WG can discuss their function and requirements.  The
>    modification of existing IPv6 extension headers or the definition of new
>    ones will be considered in the 6man WG.
> 
>    The scope of MSR6 WG includes multicast source routing over IPv6, solutions
>    for best effort and traffic engineering use cases, and the management of
>    MSR6 based multicast services.
> 
> 
> 
> Thanks!
> 
> Alvaro.
>