All things related to multicast

["Richard Mavrogeanes" <>]

It's very simple, really.  When the oddball device connected to an
Ethernet port on some far node of the campus network stops working
because it cannot absorb 20 Mbps of multicast traffic that it receives
because of switch flooding, they turn multicast off....hey, everything
was 'fine' before we turned it on, right?  I've seen it happen...circa
1997 print servers. With thousands of ports in a local network, no one
really knows what's connected any more than you know what's connected to
the power grid.

They conclude that multicast causes problems.  Same when their config
causes high bandwidth multicast to be forwarded to a T1/E1 WAN port.
Lack of planning, lack of understanding, and all too often lack of
effort gives 'multicast' a bum rap.

I think it is dangerous to suggest flooding is okay.  It's okay in a
lab, but not in a production network.

/rich



-----Original Message-----
From: Leonard Giuliano 
[mailto:]
 
Sent: Monday, May 22, 2006 12:01 PM
To: Richard Mavrogeanes
Cc: Joel Jaeggli; Alan Crosswell; 

Subject: RE: IPV6 Multicast


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!).

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.

-Lenny

On Sat, 20 May 2006, Richard Mavrogeanes wrote:

-) Joel,
-)  
-) Yes, MLDv2 snooping...but this may be too limiting a statement
because vendors can/should implement what works for them to enable
end-to-end IPV6 multicast. Some vendors do some proprietary things to
enhance multicast behavior I seem to recall, but the result is
consistant with snooping...that is, you can join a group the switch
already has without a trip to the router, flooding is avoided, and group
leaves are pretty quick thus avoiding local oversubscription.
-)  
-) We have multicast-enabled hundreds of colleage and K-12 networks in
the last few years, as well as district-level networks that interconnect
many schools.  To your point, there remains FUD on the part of the local
IT manager with regard to multicast rollout...but we've been able to
overcome these objections and I would say multicast is at last becoming
conventional wisdom.  I think this is true because it works when
properly deployed and gives the deploying institution capabilities
otherwise virtually impossible.
-)  
-) My concern is that those forward-thinking institutions planning a
migration to IPV6 will encounter the same trouble the industry as a
whole has only recently begun to overcome with IGMPv2 and IGMPv3.  I
think I'm hearing it's not possible to deploy IPV6 multicast in any sort
of reasonable end-to-end way...yet.  Please keep in mind that my
perspective for this thread is largely inside the enterprise, not so
much the WAN.
-)  
-) /rich
-)  
-)  
-) 
-)      -----Original Message----- 
-)      From: Joel Jaeggli 
[mailto:]
 
-)      Sent: Sat 5/20/2006 3:08 PM 
-)      To: Richard Mavrogeanes 
-)      Cc: Alan Crosswell; 

 
-)      Subject: Re: IPV6 Multicast
-)      
-)      
-) 
-)      Richard Mavrogeanes wrote:
-)      > Alan,
-)      > 
-)      > Well, the next release supports IPV6, and perhaps multicast
too.
-)      > 
-)      > The trouble/question is local Ethernet switch support
("snooping" behavior), and I'm hoping someone has some war stories to
share.  It was bad enough getting the switch vendors fully onboard with
IGMP, and I wonder where they are with IPV6 multicast.  Obviously, IPV6
is not so useful if it can't reach the end user (desktop).
-)      
-)      By "snooping behavior" I assume you mean mldv2 snooping?
-)      
-)      It always seems like people are looking for a reason to not
deploy this
-)      (foo multicast technology).    "If we just had igmpv2/v3/mld/v2
capable
-)      switches there'd be no impediment to use rolling it out."
-)      
-)      The fact of the matter is l2 switching hardware will almost
always
-)      evolve more slowly than host stacks or routers. Looking inside
ethernet
-)      frames is an expensive exercise for most l2 switches.
-)      
-)      What do you do with an elephant with three balls?
-)      
-)      Walk it, and pitch to the giraffe...
-)      
-)      > /rich
-)      > 
-)      >
-)      >       -----Original Message-----
-)      >       From: Alan Crosswell 
[mailto:]
-)      >       Sent: Sat 5/20/2006 12:54 PM
-)      >       To: Richard Mavrogeanes
-)      >       Cc: 

-)      >       Subject: Re: IPV6 Multicast
-)      >      
-)      >      
-)      >
-)      >       Abiline and most of the gigapops support it.  There are
some issues with
-)      >        some international networks not yet support embedded
RP.  Campuses are
-)      >       pretty far behind.  NYU is one of the few that has done
v6 multicast
-)      >       with NYSERNet.  In the first ever v6 multicast hands on
workshop in
-)      >       Albuquerque a few months ago, we viewed content that was
being multicast
-)      >       from Syracuse.
-)      >      
-)      >       Put it in a product and I'll have an excuse to replace
my Vbrick 1200's:-)
-)      >      
-)      >       /a
-)      >      
-)      >       Richard Mavrogeanes wrote:
-)      >       > I'd like to explore this group's experience with IPV6
multicast, in particular, what do we believe is the current state of the
Internet2 backbone network and what do we think is the state of
enterprise routers and switches to allow it?
-)      >       >
-)      >       > Looking forward to an interesting thread...
-)      >       >
-)      >       > /rich
-)      >       >
-)      >      
-)      >
-)      
-)      
-)      --
-)      -------------------------------------------------
-)      Joel Jaeggli 
()
-)      GPG Key Fingerprint:
-)      5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
-)      
-) 
-)