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

[Toerless Eckert <[e-mail]>]

Thanks, Nate

Yes, too bad you can not be there in person. But if we run out of discussion time
during PIM, we can always grab a side-meeting room and have a video call as well afterwards.

See the very end of the last reply to dino that i sent.

Using SSM wouldn't IMHO change things as long as the switches only do MAC group forwarding,
but i could see that even lower-end IGMP snooping switches could implement the equivalent
to real IP (S,G) forwarding from more expensive switches once we have GAAP, for example if they have
per-port filtering of which port can send to a particular multicast group MAC. Then IGMP
snooping control plane that support SSM could figure out which port is connected to the
actual source and prohibit sending to that MAC group from other ports (and of course when
switchs are cascaded permit the switch-to-switch-ports).

Of course, there is still the point Dino brought up, about who's permitted to allocate groups
via GAAP.

Of course, this very likely would primarily start to become relevant when we're talking
about ships with larger number of people. Those type of people known as "customers" . 
Not really that difficult to put a simple ethernet interceptor onto some camera found
somewhere on a ship...

Cheers
    Toerless

On Mon, Oct 23, 2023 at 09:50:08PM +0000, Karstens, Nate wrote:
> Sorry, late to the conversation on this one. It looks like you plan to discuss more in Prague. I'm not able to attend Prague in person but plan to attend the pim session remotely. I'm not sure I have much to contribute to the L3 discussion anyway. I'll just mention a few things that might be helpful.
> 
> Regarding ASM vs SSM, I wanted to confirm that our use case is maybe best understood as "SSM-via-ASM". We want SSM, but our hardware only supports ASM, so we design around this by only having a single transmitter and allocate unique group addresses. If we really enjoy new acronyms we could consider calling this something like OSM or 1SM for "One-Source Multicast".
> 
> The group address used by SSM is perhaps less of a concern here. If SSM were an option, then we could assign one SSM group address for radar, another for sonar, etc. and then rely on receivers to indicate which source(s) they are interested in. The group IDs for these allocations would be in the Permanent IPv6 Multicast Addresses (0x00000001 - 0x3FFFFFFF) or Permanent IPv6 Multicast Group Identifiers (0x40000000 - 0x7FFFFFFF) range, minus the reserved values mentioned in RFC 4607, so would not conflict with any dynamically assigned addresses. With 1SM we have to worry about getting unique group IDs because we can't use source address.
> 
> Thanks,
> 
> Nate
> 
> -----Original Message-----
> From: pim <[e-mail]> On Behalf Of Dino Farinacci
> Sent: Thursday, October 12, 2023 15:56
> To: Toerless Eckert <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pim] Garmin use-cases and L3 (was: Re: draft-karstens-pim-ipv6-zeroconf-assignment-02 review)
> 
> CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> 
> 
> > On Wed, Oct 11, 2023 at 01:56:06PM -0700, Dino Farinacci wrote:
> >>> let me try to step back a bit and give a bit broader answer:
> >>
> >> Thank you. Because you are all over the map.  ;-)
> >
> > I am just trying to figure out missing bits for overall deployments to 
> > see if they would have impact on the drafts at hand.
> 
> Yes, of course. We all know you mean well.
> 
> >
> >>> 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.
> >>
> >> Yes, it would.
> >
> > Still need to understand the SSM way with LISP, best in person in prague.
> 
> Lets have a multicast overlay meetup in the bar. Anyone is welcome to attend. If we settle on a time, we can post here.
> 
> >
> >>> However, GAAP is defined as an L3 solution, specifically asking for 
> >>> non-link-local group addresses for GAAP signalling itself.
> >>
> >> No its not. It allocates addresses. Those addresses can be used in a L2 environment.
> >
> > But the addresses assigned are L3, and not link-local IP Multicast.
> > So they come from eiher an ASM or SSM IP Multicast block. And unless 
> > we explicitly offer application using GAAP to ask for ASM or SSM 
> > address, we will have a 50% chance for mismatch.
> 
> Well GAAP "wants" to operate in a general ASM mode. So discovery of sources are done at the app layer with no outside directory involved.
> 
> >> 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.
> >>
> >> They are not complex. Spanning-tree protocol is same as PIM-bidir with automatic root selection. We had a control protocol select an RP. Shared-trees are simpler for all parties involved, apps and network.
> >
> > There is no zero-touch solution to deploy PIM with RPs. You need to 
> > configure
> 
> Well if I was still working at cisco, I would have implemented the automatic RP selection for bidir-PIM. Note I didn't say PIM-SM. LOL.
> 
> > RP location, figure out which RP redundancy is right for you and configure it.
> > This is IMHO the core reason for IP Multicast failing to make more 
> > inroads into enterprises.
> >
> > Address allocation was another pain. GAAP can solve this. So i was 
> > just thinking of what the most lightweight zero-touch complete solutions could be at L3....
> 
> That is where we authors of GAAP are coming from.
> 
> >>
> >> Its not complex. But one would argue to not use flood-and-prune. Note PIM-DM is simpler than PIM-SSM since sending control packets (Prunes) are the exception and not the rule. And PIM-SSM just defaults the other way.
> >
> > Prunes would be the exception when we think about the broadcast groups 
> > like GAAP or SAP,
> 
> But there are many applications that do not use GAAP and SAP and GAAP/SAP packets would go to them if we use flood-and-prune.
> 
> > but not for actual ASM applications which would be sparser in their 
> > set of LANs they would need to go to. For those, RFC8364 would be lovely.
> 
> Remember the mother's day problem? Just look at the average size of a zoom call. Lots/tons of small member groups.
> 
> > Really hard to think what might be best recommendations for 
> > as-simple-as-possible deployment defaults in this ASM space.
> 
> Well if we want multicast to be deployed everywhere/anywhere, we have to use an overlay based on the state of affairs in today's Internet. So I think its simpler because the app just sends packets and the overlay protocol runs on the node with the app. And you could get source mobility for free.
> 
> >
> >>> 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
> >>
> >> Note flooding on the ENTIRE network must be used with caution. If GAAP is running everywhere, then there is no pruning for GAAP protocol packets.
> >
> > I guess i will get more of your attention when we look about how well 
> > this works and can be automatically protected against abuse in the 
> > LISP use-case than the L3 campus/enterpriecase - but i think the overall issue will be the same.
> 
> A LISP ITR would encapsulate exactly to 2 places, to the 2 topological locations of the 3-member group. And you give the user/app the multicast service model. That is golden IMO.
> 
> > Aka: for these type of apps we'd need some rate-based limiters. And 
> > the default limiter from RFC8364 for example already looks way too low...
> >
> >>> 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.
> >>
> >> When you refer to "RPF-flooding" are you referring to procedures in RFC8364 or PIM-DM?
> >
> > RPF flooding without tree state (unlike PIM-DM). Just source based RPF 
> > dropping (could come from unicast RPF dro code) and otherwise flooding 
> > except to the receiving interface. Plus rate-limiters.
> 
> You don't want GAAP packets to go everywhere, then people (when Claim messages are not encrypted) can eavesdrop.
> 
> >
> >
> >>> 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.
> >>
> >> I don't understand this.
> >
> > What type of IP Multicast routing could we put into "as-zero-touch-as-possible"
> > campus/enterprise/home equipment. SSM is very simple, we can do that no problems.
> 
> Simple for the network but you pushed (S,G) state to the app, who doesn't know sources. It has to put source discovery as part of its deliverables. That is quite a burden for apps. And if you want them to be decentralized, you can't use a directory.
> 
> >
> >>
> >> So if you do that, then the app has to ask for one sub-range versus the other. How does an app writer know which networks its app will run on and what netadmin ranges are configured. You put this feature in and no one can use it. Its not a good idea.
> >
> > The app will ask for ASM or SSM. We subdivide the GAAP address range 
> > in two blocks, one ASM, the other SSM. We're not exposing which 
> > protocol is run to provide ASM or SSM
> 
> You are not following my response. How does the app know? The app won't even know how to expand the acronym :-).
> 
> >
> >> For years, apps didn't know how to set the TOS bits in the IP header. It finally worked out because the simple rule was "if you are an audio app, set bits to x all the time, if you are a video app, set bits to y all the time, and everyone else set bits to z". And the TOS bits weren't "quality of service", they turned into a drop priority (where z packets were dropped first).
> >
> > TOS was a nice simple vision for applicartions and impossible to 
> > deploy in networks. Then the IETF tried to make it a deployable 
> > reality by develong DSCP, but in turn they turned it into a nightmare 
> > for applications. Great 180 degree turn ;-))
> >
> > Don't even get me started on that issue ;-))
> >
> > But it's not a valid comparison with ASM/SSM:
> 
> Right ASM/SSM is more complicated than the TOS example. The reason why I used it.
> 
> >
> > ASM and SSM are different in that way. We have well defined 
> > application APIs,
> > join/leave(G) for ASM, subscribe/unsubscribe(S,G) for SSM. If you want 
> > to use the ASM API you need to have an ASM G, if you want to use the 
> > SSM API, you need to have an SSM G.
> >
> > Or in your words: If your app can do source discovery and provide the 
> > network with the source, you MUST use an SSM group, else you MUST use an ASM group.
> 
> But it wants to do source discovery via multicast. That is one of multicast's features. Remember source discovery with expanding ring search? Finding the closet resource, etc.
> 
> > Why would your app wants to  use SSM if you can have ASM ?
> > - it allows you do prohibit any unwanted sources to clog your reception of desired sources.
> 
> Then the app also has to do network level access control?
> 
> > - It allows you to operate across more networks than ASM 
> > (wide-area/interdomain)
> > - It likely will run more stable because its easier in the network.
> > - yada yada rfc8815 ;-)
> 
> The reason multicast failed at the app level is because the multicast service model was so enticing but the network had too many knobs to give a reliable service model to apps.
> 
> Lets not continue this thread because its getting off topic.
> 
> I don't want to put sub-ranges into GAAP until anyone tells me how it can decide on which one to use. And the apps which use GAAP are decentralized, no coordination, configuration free. So tell me how an app developer writes code with logic to select a sub-range when its app can be deployed in any network with different sub-range policies.
> 
> Dino
> 
> _______________________________________________
> pim mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!EJc4YC3iFmQ!WqhgEDA0tMb9Uou9u8vDEztqHxorB61OFWUUi9FriZekTNWRLcqDmUfOLvvZDjvvpJ-9wvpwS6hVZYOKBBBS$
> 

-- 
---
[e-mail]