Re: [MBONED] [Bier] [Msr6] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

[Toerless Eckert <[e-mail]>]

On Thu, Nov 03, 2022 at 03:35:45PM -0700, Dino Farinacci wrote:
> > We have that with PIM and a boat load of hardware that supports RPF based forwarding (ditto for Bidir-PIM forwarding).
> > 
> > [Xuesong] Do you mean that RPF could bring more security through mechanism like " Source address verification"? 
> 
> I am saying that if you are going to require new hardware for a new forwarding plane, the problem you want to solve must be compelling. And I think existing methods DO work.

Indeed. But IPv4 multicast also did work for all customer
use cases and somehow they still wanted IPv6... and then MPLS.. 
BIER, BIER-TE, MSR6, ?RBS?, ... just normal customer driven
solution field evolution.

Especially the change of encapsulation header from rfc8296 to MSR6
should be painless for any router supporting BIER and SRv6 (unicast).
Would we ultimately also want MSR6 for networks not using SRv6,
such as IPv6 IoT network that may use no IPv6 source steering or
rfc6554 ? Absolutely. But those platforms would much more likely
adopt BIER bitstrings via an IPv6 MSR6 extension header, so i
think using the IPv6 extension header approach is also the right
way to proliferate the BIER model itself broader.

> >> But still, security consideration is necessary, maybe referring to the previous experience from BIER and SPRING.
> > The fact that an Internet host "does not ask for packets", means anyone can send it packets they don't want. 
> > With explicitly joined trees and IGMP, we default differently with IP multicast. A feature and not a bug.
> > [Xuesong] I think "host-initiated multicast" doesn't mean that the host could send the packet to any receiver it want. The 
> 
> I don't know what your reference to "host-initiated multicast" means. It sounds like it is something new you are referring to. But hosts have always sent multicast packets.

Technically, a PE-router being BFIR/BFER is of course also a host,
and if there are linux implementations, that too helps. But:
If we do not want to limit use of stateless multicast to very
specific software implementations such as router-VM software,
then we can easily learn from our experiences about how well
network features proliferated through all the variety of
host stack libraries.

Only IPv6 made it through all the important
programming language SDKs, including Java/Javastack and so many
more SDK. No other network protocol. And by being embedded
into IP, IP?IPv6 multicast could sneak into those host-stack/SDK/
programming languages too. Show me for example any support for
any of the 3G/4G multipoint services of mobile networks. At
some point in time i tried to hunt those down, but beside
one or two mobile network multicast demo services implemented
by the mobile operators, i think you won't find something. And
i think there was something like a faustian contract you had
to sign to get access to their SDK...

> > receiver of the multicast should be determined by the application layer (e.g., http request with the same content requirement) or a controller could gather the information about which receivers want the same content.
> 
> Yes and that happens today and hence signals the lower layer IGMP/MLD protocol to send a "join signal" on the network.

Btw: Even IEEE did introduce for TSN services new signaling protocols
that support the flexible/hybrid signaling. Aka: whatever the
app indicates through API can be passed either hop-by-hop
through the network, or redirected to an OOB controller for
further processing. In IETF we only did one-offs for this, such
as the overlaying of PIM signaling from egres PE to ingres PE,
but really nothing comprehensive that would more easily allow to
build multicast into networks more flexible. Even after 30 years for
example, we are still struggling with incremental/partial deployments,
not being able to esily automatically make PIM work across non-PIM
hops. In BIER (and MSR6, such incremental deployment is easy to use
fully automated.

Cheers
    Toerless

> Dino
> 

-- 
---
[e-mail]