All things related to multicast

[Joel Jaeggli <>]

John Lyons wrote:
> Hi Lenny,
> 
>> It strikes me as odd that lack of snooping could CAUSE mcast to not be 
>> deployed and used.  Lack of snooping is only a problem when there's too 
>> much mcast (and one could argue that's a good sign for mcast deployment- 
>> there's too much mcast!).
> 
>  This strikes me as a very dangerous statement, I can think of very few 
>  situations where flooding multicast is acceptable but many many more 
>  where it is completely unacceptable. 

Since I bear some responsibility for starting this, let me just weigh in
again.

You don't need this as much as you think you do.

If you do need it that badly it's because a trunked bunch of vlans on
core switches to avoid buying more l3 ports is a poor way to build a
network. If you melt your switch core before the edges that would indeed
be a bad thing.


Modern (eg in the last 10 years) ethernet chipsets have a decent enough
multicast filter down in the cam to drop quite a few Mb of multicast
without noticing. So that leaves 1/2 duplex network segments (who cares)
really big broadcast domains (better subnetting), wireless edge networks
(which switch packets in software and can be configured to drop them
just as easily as forward them them), and legacy devices.

The legacy devices are an interesting problem, but they pose the same
problem in other realms, They're never going to be ipv6 aware, support
jumbo frames, do auto-negotiation, support tcp TOS bits, and of course
understand multicast, and at some-point they'll have to fall off the
network, just like all the localtalk devices did when broadcast
appletalk traffic routed on your (and everyone elses campus) exceeded
the line-rate of the localtalk interface, or when you (everyone) stopped
routing decnet and all the vaxstations stopped working.

>> It's also been my experience that operators (and humans in general) are 
>> generally not proactive enough to delay the deployment of a compelling 
>> service bc of the anticipation of a potential problem down the road.  It's 
>> usually some other, more pressing reason.
> 
>  This is not a "potential problem", Lack of snooping is a complete show
>  stopper when it comes to rolling out multicast in the vast majority of
>  networks (particularly outside of NRENs and connected institutions).

Again, some people have used this various versions of this excuse to
retard their campus deployments for almost a decade. The hardware will
never be ready with the foo magic feature that is required this time to
make it all work. Moreover no-one replaces all their hardware at once
which means by the time you get to the point were you got all the
features you need everywhere you need them, your needs, or protocol
development, or vendor featureitis will have moved on to something else,
which will the pose a different impediment to deployment.

We deployed multicast across campus more than a decade ago and by in
large our customers neither noticed or cared, yeah some of their apps
magically worked (IPTV, Ghost etc), but the network didn't catch fire
and burn down, and I don't expect that an eventual deployment of v6
multicast support will cause it to either even if all the l2 pieces
aren't in place...

>  John

I concluded a long time ago that Steve Deering's original premise, which
was to regain the functionality (flooding) lost when Ethernets became
routed, was probably a flawed one (That I spent 11 years of my life
working on it is another); But it's the people and the economics that
have been persistent barriers to deployment not the technology, however
flawed it may be.

-- 
-------------------------------------------------
Joel Jaeggli 
()
GPG Key Fingerprint:
5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2