All things related to multicast

["Jill Gemmill" <>]

Kevin - thanks for your comments.  Evaluations of a slide presentation when
you've not heard the talk help me see how it stands on its own.

  > Emphasis on "has been"...  we are now moving down the chain to deal
  > with issues raised by member institutions.  As an MI you should talk
  > to the folks in the Gigapop about how you can get multicast from
  > them...  There isn't just one choice.

I know - we began with the one they decided to send us.  We now know what we'd
like to receive, instead.

  > 1.  There is no MBone in the backbone (slide 2).  The term MBone has
  >     lots of meanings and lots of people disagree.  We are deploying
  >     native multicast.

This is an interesting observation.  I have only heard these broadcasts 
referred
to as MBone up until now (that is, the technology is native multicast; the
broadcasts are MBone?  not worth differentiating?) This is probably a common
mis-nomer

  > 2.  Slide 14...  you might want to mention what would happen if
  >     people were doing lots of unicast on the link.  Multicast is
  >     less expensive than unicast (ignoring some details of IGMP).

That was the point made in slide 13 - the 3-10MB of incoming traffic have a
noticeable affect on hubs when "loosed" on them.  slide 9 makes the point 
about
efficiency.   This can be repeated on 14.


  > 3.  You should mention that many of the hardware components needed
  >     are already available.

Yes -- but "which ones" is the interesting topic.  In responses I got to my
"informal survey" of SURA and I2 institutions, most of those who answered
assured me that CISCO proprietary was the only way to successfully deliver
multicast traffic.

The multicast workgroup can make a good contribution by documenting which ones
do in fact work, are interoperable, and so on.  If indeed this working group
will be focusing more on campus delivery, I would be happy to participate in 
any
way that you-all might find useful.