Subject: Re: Standardisation of IGMPv3

From: Mark Handley <[email-masked]>
Date: Thu, 13 Jul 2000 11:14:03 -0700

>This point has been made by several others and I think is quite
>valid.  I'd personally prefer that we add the ability to specify a
>mask before going to Last Call.

Bill,

I'd like to voice a different viewpoint.

I'm unconvinced that adding a mask is a good idea for a number of
reasons:

 - It would complicate the IGMPv3 machinery (which is already pretty
   complex) because you'd have to resolve mismatched masks.  Eg one
   host specifies "Exclude (128.1.0.0/16, G)" another host specifies
   "Exclude (128.1.2.0/24, G)". 
    
 - You also have to cope with nested include and exclude masks.  Eg
   one host specifies "Exclude (128.1.0.0/16, G)" and another host
   specifies "Include (128.1.2.0/24, G)".  For IGMPv3, this is additional
   complexity.  If you want to map this into PIM this would want to map
   into two Prune *ranges* - you can't implement this with a single
   mask, so you'd actually need a large number Prune mask entries
   (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G), 
   etc).

   Do (S-mask,G) prune entries actually work in PIM?  The packet
   format allows it....

   If the router doesn't try and map (S-mask,G) IGMP exclude messages
   into (S-mask,G) Prune messages, then the purpose of (S-mask,G)
   IGMP exclude messages is kind of lost.  Anyone spoofing from all
   the addresses on a subnet will generate a small amount of
   local-area IGMP exclude traffic which gets mapped into a large
   amount of wide-area PIM prune traffic.  Thus the optimization doesn't
   seem worthwhile.

 - It requires the API be extended to allow apps to specify masks.  
   For exclude masks, there doesn't seem to be any practical way the
   app can use the mask.  It's never going to be told by a misbehaving
   sender what the correct netmask is, and it's increasingly unlikely
   to be able to guess correctly.

 - If the IGMPv3 host specifies an include netmask that is too large,
   how do you implement this in PIM?  Do you route an (S-mask,G) Join to
   the place where the routes diverge, and then have to split the Join
   to go multiple ways?  I guess you'd have an issue if someone
   specifies "Include 192.1.0.0/16" for example.  

   If the router doesn't try and map (S-mask,G) IGMP include messages
   into (S-mask,G) Join messages or a large number of (S,G) Join
   messages, then I don't think (S-mask,G) IGMP include messages serve
   any purpose whatsoever.  The receiver simply won't get the traffic
   they asked for.

   I guess you could do a (*,G) Join, and then have the router
   generate the (S,G,rpt) Prunes for unwanted sources, but the host
   can just as well do this with the current IGMPv3.

In general, I think this raises too many complexities for what seems
to me to be too little gain, so that it just doesn't seem worthwhile.
It's likely to add significant delay to standardizing and deploying
SSM, and that seems to be a bad tradeoff to me.

Cheers,
	Mark

---

From: Thomas Maufer <[email-masked]>
Date: Thu, 13 Jul 2000 12:08:18 -0700

Mark--

I'd tend to agree with you.  Not only for the reasons
that you mentioned, but I can't imagine that it would
be very likely that there would be a set of servers
offering related content (or temporally correlated
abuse) such that grouping them together under a common
prefix would be meaningful.

So, unless someone can illustrate situations where this
would actually be useful (and where *not* having the
netmask information would be a real impediment), as well
as mechanisms to enable the group-members to learn about
the source's local prefix,  I think this feature could
be safely postponed until IGMPv4.  :-)

Cheers,
Tom

---

From: Dave Thaler <[email-masked]>
Date: Fri, 14 Jul 2000 14:42:32 -0700 (PDT)

> I'm unconvinced that adding a mask is a good idea for a number of
[...]
> SSM, and that seems to be a bad tradeoff to me.

I strongly agree with Mark.  Adding rules to deal with a mask would 
severly delay (if not halt all together) both standardization and
deployment of IGMPv3, at a time where it's already overdue,
and for little (no?) benefit.

-Dave

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 17 Jul 2000 08:35:14 +0100

In message <[email-masked]>, Dave Thaler typed:

well the jury appears to be out on what to DO with the masks, but why
not leave something there for future experimentation? 

whatever happend to the old IETF tradition of forwards
compatability?:-)

so we put in the firleds but leave their USE undefined (actually,
sorry, explictily mark them as experimental)

that would seem to address all the complaitns about them and all the
requests for them.

 >>and for little (no?) benefit.

 cheers

   jon