[pim] Garmin use-cases and L3 (was: Re: draft-karstens-pim-ipv6-zeroconf-assignment-02 review)

[Toerless Eckert <[e-mail]>]

let me try to step back a bit and give a bit broader answer:

For the garmin use-cases, i think GAAP will work fine for a single L2 subnet
deployment without IP multicast routing. I haven't tried to wrap my head
around a use with LISP, but i think that combination may be a different use-case.

However, GAAP is defined as an L3 solution, specifically asking for non-link-local
group addresses for GAAP signalling itself.

But how could a deployment such as those i've seen described by Nate work with
L3 IP multicast routers ? And should we even bother about this ?

I for once think that PIM with RPs (PIM-SM or Bidir) are too complex to operate for
these deployments. We should really have zero-touch here instead of worring
bout positioning, configuring, redundancy and the like for RPs.

PIM-SSM itself does not work for GAAP signalling, it needs ASM. Likewise these
deployments use some ASM discovery protocol, similar i think to SAP. Which
also needs ASM.

RFC8364 is also a pretty bad fit for running GAAP or SAP like protocols over it.
More overhead in signalling than the ASM packets it needs to support. Also
likely problems with getting burst packets (first packet of new (S,G)) through
to receivers.

In some old router OSs, PIM-DM can be used as a solution, but its also too
complex.

IMHO we should really have for these type of "broadcast" groups that GAAP
or SAP likely would be in such deployments simply RPF-flooding. Which we haven't
specified in any RFC. Or else we'll have  really no good zeroconf option to
deploy GAAP or SAP or similar protocols in these type of "no-network-admin"
type networks.

Which circles back to the assignment draft: Maybe we should specify a sub-range
of the zeroconf address space for such "ASM-flooding" groups, which by
default could use RPF-flooding. And then assign explicit application groups from
that range. Such as GAAP or those SAP like groups.

And to get to Dinos question:

The garmin apps themselves are actual SSM applications. every group will have
just one sender, such as a a camera. If we wanted to have a zero-touch
deployment with L3 routing, what IP multicast routing protocol would we use ?

If we wanted to PIM-SSM, that would be IMHO the only real fit. But it would mean
that the group would need to be SSM.

We could say it's PIM-SM operating without RP, but that already confuses
implementers because that's not well specified. Similarily, we could say it's
SSM plus RFC8364. But that too would be overkill when there already is
source discovery in the form of some SAP equivalent.

So i do indeed think that the GAAP managed adress range should be statically
subdivided into two sub-ranges, one for SSM, one for ASM. Obviously in GAAP
itself, the choice of routing protocols to support either range wouldn't
need to be named, but in whatever zerotouch solution document one might want
to have, one could easily state to use PIM-SSM in the SSM range.

Cheers
    Toerless

On Mon, Oct 09, 2023 at 12:00:24PM -0700, Dino Farinacci wrote:
> Well I think you found a really important issue we need to address.
> 
> That is, we want to build our allocation protocols to just come up and work without colliding with group address ranges already used in the network. The conflict I see based on your comment is that ASM and SSM ranges are used for protocols that want to build certain types of trees. So we have cross-conflict among multicast routing protocols an multicast address allocation mechanisms.
> 
> What we need is for each IANA allocateion range to be split up into ASM and SSM sub-ranges from a given allocation. That would solve the problem for all allocation protocols that are introduced at the expense of wasting address space.
> 
> So I am fine, but would like to hear from others, that we keep things the way we have them now and PIM implementations can be configured to use ASM or SSM from sub-ranges from the allocation protocol ranges.
> 
> Comments?
> 
> Dino
> 
> > On Oct 8, 2023, at 10:36 PM, Gyan Mishra <[e-mail]> wrote:
> > 
> > 
> > Dear Authors 
> > 
> > I reviewed this draft presented at IETF 117.
> > 
> > Few comments.
> > 
> > With this draft method of dynamic generating multicast addresses for applications with a new IANA GDA allocation.
> > 
> > I am guessing this dynamic multicast addresses assignment method can  be extended to be used for both IPv6 ASM range or SSM FF3x::/96?
> > 
> > With SSM you can use the default 232/8 or any other block so this new IANA multicast ID range could it be mapped I guess to be used for SSM?
> > 
> > 
> > Kind Regards 
> > 
> > Gyan
> 

-- 
---
[e-mail]