Re: Automatic Tunneling for Rapid Multicast Deployment

[Steve Deering <deering@cisco.com>]

At 8:34 AM +0100 7/29/00, Jon Crowcroft wrote:
> >>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

Perhaps, but that wasn't the purpose at the time.

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

You misunderstood what I said, Jon.  The purpose of IGMP was to isolate
hosts from knowledge of the multicast routing protocols, *not* to separate
multicast routing protocols  from each other.

>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:-)

Indeed.  No smiley meeded.

> >>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

I wasn't talking about any changes proposed to IGMP for SSM (which can
in fact be done in a way that does no protocol-specific violence to IGMP).
I was talking about the criticism of IGMP as supporting the super-set of
various protocol-specific requirements.

> >>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 didn't argue that they were technically wrong, just that they were
historically wrong and that they were out-of-line in claiming that IGMP
was technically wrong ("flawed").  There is no "right" or  "wrong" in
protocol design, only engineering trade-offs, and indeed theirs may well
be a valid and valuable contribution.  They shouldn't need to appeal to
imagined history to explain its merits.

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

Nor do I, nor did I say that is was.  My flame was against their shoddy
analysis of IGMP, not against their own proposal.

Steve