The 100 Gbit/s problem in your network

Jeff Kell jeff-kell at utc.edu
Tue Feb 12 04:33:41 UTC 2013


On 2/11/2013 11:05 PM, Tim Durack wrote:
> Multicast is dead. Feel free to disagree. :-) Tim:> 

Multicast is a vendor selling point, as you essentially need a coherent
end-to-end solution to get it to work PROPERLY.  Of course if it does
not work PROPERLY, it will still largely work, albeit inefficiently, in
most cases other than routed multicast.  So personally I'd love to see
the multicast environment die as well :)  It's so... well... decades old
stuff.  For cable / IPTV it may fly and scale, but there is a decided
move to the on-demand model.  And even with live broadcast, there's the
growing DVR selling point of "pause and resume" which is buffering and
unicast, just localized to the set top box.

It is also the opposite of "on demand" as multicast only works on a
synchronized timeline.  Few if any people will demand a specific item
"on demand" at the same time, or even within a reasonable time window
for a buffered/staged multicast (..."this channel should be available
shortly...").

You could multicast to cache boxes, but that is prone to cache hit
randomization, and only useful to "pre-populate" an incident.

Multicast still works for live broadcast.  And can be convoluted to work
in odd/mixed topologies (e.g., Octoshape...  hideous thing).  But
working multicast requires tweaking (PIM, IGMP snooping, CGMP/etc
vendor-specific L2 pruning) that makes it ugly.

We had enough headaches just trying to route multicast computer imaging
traffic (Ghost, SCOM, etc) that I couldn't imagine trying to extend that
out into userland without some serious forklift upgrades to insure it
would work at the hardware level.  Locally, knock y'erself out with
fingers crossed, you'll only nuke your broadcast domain, but routing it? 

Jeff





More information about the NANOG mailing list