Subject: RE: Standardization of IGMPv3

From: "Houdek, Stephen (S.W.)" <[email-masked]>
Date: Thu, 13 Jul 2000 18:11:54 -0400

A corporate perspective......

Don't wait to perfect it.  If it is close and this would cause unnecessary
delay, debate and incorporate this functionality via V4.  It appears this is
"somewhat" controversial and would be subject to a requisite amount of
debate.

Think Speed........

Stephen W. Houdek
[email-masked]
(313) 845-4128
(313) 845-2491

-----Original Message-----
From: Mark Handley [mailto:[email-masked]]
Sent: Thursday, July 13, 2000 2:14 PM
To: Bill Fenner
Cc: Mani Manoharan Balaraman; idmr; Beau Williamson
Subject: Re: Standardisation of IGMPv3

>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: Manolo Sola <[email-masked]>
Date: Fri, 14 Jul 2000 17:47:00 +0900

Some comments not aimed to interfere with the IGMPv3 last call but just
to continue with the debate regarding future IGMP versions: what about
having 2 more filter-modes, lets say, INCLUDE-PREFIX and EXCLUDE-PREFIX
? For this two filter modes what would appear in source-list[2n] and
source-list[2n+1] would be an address/prefix pair. In what respect to
the IGMPv3 message format, it would be enough to take a single bit from
the reserve field to indicate whether the message contains a list of
single sources or a list of address/prefix pairs.

Considering that IGMP must be independent of the multicast protocols
used to forward multicast traffic from sources to leaf routers, the way
PIM, CBT or other multicast protocols at routers use the list of sources
or the list of address/prefix pairs provided by IGMP becomes a multicast
protocol dependent issue and should not constrain IGMP specification.
The simplest IGMP implementation allowing address/prefix pairs can just
expand each prefix pair into single 32 bit address lists before doing
any further processing. More elaborated implementations can go further.
In any case it can make things simpler for those applications that need
to include or exclude ranges of source addresses. 

-- 
                                                        Manolo Sola
                                                        [email-masked]