Re: [v6ops] draft-ietf-6man-grand : saving lookups

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Fred:

100% agree. If the size of the multicast table is roughly that of the routing table, it looks particularly inefficient to maintain a multicast table for the sole purpose of DAD and lookup. We take great care in hiding that simple truth under the carpet by saying that’s a L2 problem. But it does not seem that L2 has taken the bait, has it.

As another case of what you’re describing,  fabrics are optimized to use a routing protocol (e.g., BGP with eVPN) and broadcast is the last resort, but there is no multicast in between. Sadly it is still there, because the fabric is lacking a clear view of what’s there.

Note also that the routing protocol is better suited to announce reachability than to perform DAD.

This is where some help from the host would be needed in place of the useless IGMP games. The host can help the fabric by providing accurate information on the addresses it is effectively using, a sense of duration, a sense of order in movements, and a proof of ownership. This information should be enough to differentiate a case of multihoming / anycast with a movement.

All the best

Pascal


On Aug 11, 2020, at 12:48 PM, Templin (US), Fred L <[e-mail]<mailto:[e-mail]>> wrote:
That is more or less the principle for NBMA, yes. But take a conservatively-sized NBMA
link with 1M nodes on the link but only 2-3 of them need to receive the multicast then
serially unicasting seems pretty efficient and does not disturb the vast majority of
nodes that don’t care.