Re: Automatic Tunneling for Rapid Multicast Deployment

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

 >>The *real* historical reason why IGMP is a separate protocol from the
 >>router-to-router protocol was to allow the use of multiple, different

um, i thought at the time that the breakthrough was in designing 
the first working example of a new communications paradigm:
receiver driven end to end protocols

the separation of inter-domain and intra-domain routing for multicast
is not a function of IGMP at all, and is not made easier or harder by
it....the problems of interdomain in terms of distributing receiver
membership and the existinence of senders in domains has dogged us for
some time and was at least to some extent  exacerbated by the
existence of dense mode protocols, but not anything to do with the
host group model or its management as far as i can se...

sender 
 >>multicast routing protocols in different parts of the Internet, and to
 >>allow a region to change from one multicast routing protocol to another,
 >>without requiring any changes to the hosts or knowledge in the hosts of
 >>which particular multicast routing protocol they happened to be
 >>connected to on any given day.  That this was important was evident
 >>from the experience with unicast routing protocols, where we had RIP,
 >>OSPF, IGRP, and others all being used in different parts of the Internet;
 >>requiring host changes whenever a unicast routing protocol was changed
 >>or introduced would have been a major deployment hurdle, and would have
 >>inhibited improvements in unicast routing.  And indeed IGMP accomplished
 >>its goal: hosts that implement only IGMP can successfully be used to
 >>receive multicast packets via DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT.
 >>
 >>>1. IGMPv1 designed to be a super-set of all the information that a 
 >>>host needs to send to the designated router (DR).
 >>
 >>That's exactly opposite to the truth.  The "classic" multicast routing
 >>protocols were designed to work with the information the IGMP provided,
 >>not the other way around.  The changes to IGMP have been driven by the
 >>desire to correct inherent shortcomings (specifically, high leave latency)
 >>or to enhance the multicast service model (i.e., adding support for source
 >>filters), both of which reasons are completely independent of the "needs"
 >>of any particular multicast routing protocol, in keeping with IGMP's
 >>purpose.

i guess the only case where this isn't 100% is the debate about adding
msaks, which in abny case just supports your argument, since the
debate largely went against addign them:-)
 >>
 >>And by the way, not all multicast routing protocols have "designated
 >>routers" and IGMP, being routing-protocol agnostic, does not assume that
 >>they do.
 >>
 >>> When the multicast protocols required low leave latency, IGMPv2 was
 >>>created. When the  protocols required source-specific, IGMPv3 was created.
 >>>Any of these changes caused a redundant change in the operating system.
 >>>This may  continue forever.
 >>
 >>Any successful protocol evolves over time to correct shortcomings and
 >>meet new needs.  After all, we are not running IPv1.  The important
 >>observation is that IGMP has required fewer and less frequent changes
 >>than all the various multicast routing protocols that it has
 >>interoperated with, which is exactly as it was designed to do (given
 >>that updating IGMP in all hosts takes far more time and effort that
 >>updating the multicast routing protocol in the routers in one domain).
 >>
 >>> The basic flaw is that there is no general super-set, and the required
 >>>information to be transferred between the  host and the router is
 >>>protocol specific.
 >>
 >>The basic flaw in your analysis is that you misunderstand the nature and
 >>purpose of IGMP and its evolution.  It has not evolved to provide a
 >>"super-set" of the requirements of specific multicast routing protocols.
 >>There has often been pressure to throw in routing-protocol-specific
 >>features (e.g., including a "core" or "rendezvous point" address for
 >>CBT or PIM-DM), but so far we have managed to prevent such changes,
 >>which would be exactly contrary to IGMP's goals of keeping hosts isolated
 >>from knowledge of the multicast routing protocol du jour.

this is a misrepresentation of the change proposed in simple - the
change there was to the address format and had no efect on the
operation of IGMP, only on its payload (and then no more than IPv6
does:-)
 >>
 >>>2. There is no need for two different set of protocols. There is no 
 >>>real difference between the last hop and all other hops. One protocol 
 >>>can, and should, do it all. This way, IP multicast can be defined by a 
 >>>single specification!
 >>
 >>Sure, until next year, when someone comes up with the New New Multicast
 >>protocol.

yep....
 >>
 >>>4. IGMP, especially [IGMPv3], is far too complicated, with too many 
 >>>messages and fields that [SSM] protocols do not need. 
 >>
 >>I agree that IGMPv3 is more complicated than I would wish.  But the
 >>mismatch between what IGMPv3 provides and what SSM requires is due
 >>to the fact that SSM provides only a limited subset of the *service model*
 >>(*not* the multicast routing protocols) that IGMPv3 is designed for.
 >>Sure, if you offer a less functional service, you can do it with a simpler
 >>protocol (just as IGMPv2 is much less complex than IGMPv3).  The choice of
 >>what service(s) to provide at what layer is, of course, the topic of the
 >>most long-running debates in the field of data networking.  I would
 >>appreciate it if you would acknowledge that these issues are indeed
 >>debatable, and the fact that IGMP is not what you want does not
 >>necessarily represent a "basic flaw" in IGMP.  And if you won't do that,
 >>at least resist the urge to fabricate bogus "historical reasons" for
 >>things you don't understand.
 
this is a bit harsh steve - someoen could understand the apparent
current technical state but get the history wrong - aerguing that they
are technically wrong _because_ they dont know the history is not a
good way to debate what may otherwise be a valid contribution...

i think whats being proposed might be thought of as IGMPbis in the
same way that SSM supports IP Multicast Servicebis -with an
appropriate applicability statement (for both the host group
management and the subset routing protocl) I dont see why this is
a totally bad idea, history notwithstanding...

 cheers

   jon
history is bunk - ford
ford is dead - god
god is dead - nietcsze
god is ford - huxley
landrover is ford - bmw