All things related to multicast

[Roy Hockett <>]

        Here at University of Michigan we are working on deployment of 
multicast throughout our backbone and then on LANs as the need is identified
and each LAN is evaluated for its capabilities to handle multicast. 
Our desire was to roll out production multicast, much like reliable 
unicast service.  However, as we started working with it with 
the GigaPoP, we soon found out how "non" production it is.  For many 
of the reasons Bill outlines I see multicast as still an developing
service, that can be enabled on networks, but that will take a back seat
to reliable Unicast traffic.  
        I am guessing that most institutions don't have, and can't afford 
both a production infrastructure, and an experimental one so that they 
can seperate things like multicast, and such. So with a single 
infrastructure, and the need for reliable unicast, multicast will always 
lose out.  Now one why to semi-achieve the experimental network is 
through the use of vlans, but this only works at Layer2, you still need 
seperate layer3 devices, so your reliable unicast routing doesn't break 
because of the bug for multicast routing.
        I think that there is a need for a mind set of multicast is 
production 
by service providers, software developers, tool developers, and
especially 
router and switch vendors, to provide reliable multicast infrastructures.
        I am concerned that even with the above, that without content that 
actracts users to multicast, it won't be taken seriously and recieve the 
attention that is needed to move into a production service.
        The final question is that what if multicast did become as popular 
as MP3 swapping did, will it scale?  will the networks beable to handle it?
        I think there is some good technology outthere that takes advantage 
of multicast, like the access-grid, but is this technology destine to 
stay only in the research comnumity only, or will it move to the 
comerical world?

Bill Owens wrote:
> 
> Although NYSERNet is on the 'good' list, something I'm happy about,
> that doesn't mean that we have good multicast deployment. One campus
> has it deployed everywhere, but it doesn't *work* everywhere; often
> when someone attempts to send or receive traffic from a new subnet
> there's troubleshooting and tweaking that has to take place. Another
> campus has multicast running just to the computer center. I have it
> to our entire network here at the NYSERNet office, but that's one
> router and one switch.
> 
> I think there are three problems preventing better deployment. One is
> that some sites' hardware just can't cut it; they have routers or
> switches that don't do anything but DVMRP, they have too many hubs,
> they have no choice but to use a firewall. Another is that multicast
> is hard to troubleshoot - it works (and breaks) differently from
> unicast, some of the troubleshooting tools are quirky and unreliable,
> there's less monitoring and alerting. The last is that it breaks, for
> me at least, on a constant basis. Every unicast routing change risks
> breaking multicast, as does every software upgrade. Even when
> *nothing* changes, multicast breaks out of spite ;)
> 
> Right now I have MSDP instablity with the Ciscos that I peer with (I
> also have a Cisco) but not with my backbone Junipers. I discovered
> that while trying to get multicast traffic from Columbia; one of
> their sources worked fine, the other didn't. Cisco problem? Bug in my
> bleeding-edge IOS? Some weird MSDP traffic? Change in unicast
> routing? Darned if I know. I'm not even positive the MSDP instability
> is related to my not being able to see their content. I'll spend a
> couple of hours troubleshooting and hopefully fix it, but next week
> or next month it will be something different.
> 
> All that being said, I do like multicast, especially native
> multicast. Things have come a long, long way since the first time I
> pulled up a multicast tunnel and they continue to get better. I will
> keep pushing it to NYSERNet members, making sure that they know both
> the benefits and the costs involved. And I've put a shiny new edge
> router in next year's budget ;)
> 
> Bill.

-- 

/********************************************************************/
/* Roy Hockett                     *   Telephone: (734) 763-7325    */
/* Network Engineer,               *         FAX: (734) 763-2180    */
/* ITD,                            *    Internet: 

  */
/* University of Michigan          *                                */
/********************************************************************/