Subject: Summary of IGMPv3 Last Call discussion so far

From: Bill Fenner <[email-masked]>
Date: Wed, 19 Jul 2000 10:59:19 -0700

Dear IDMR,

  With the IGMPv3 Last Call to Proposed Standard halfway over, I thought
I'd summarize what I perceive as the state of the comments.

- There should be a bit to request SPT?  Better service?

  My view on this is that the SPT-request is implicit by including a
  source; it's up to the router policy as to what it does with it.
  Hosts shouldn't know about trees, so it'd have to be some kind of
  service metric, and it's very unclear how to represent it effectively.

- IGMPv3 should support a source netmask

  There have been several messages in support of this, and several against.
  The supporters have given no concrete reasons why these would be useful
  and worth the cost of adding them.

  A summary of the arguments for:
  - Filtering on source networks is useful
  - Interoperability between IGMPv3 and IGMPv4 (e.g. adding netmasks) is
    too hard.

  A summary of the arguments against:
  - IGMPv3 is already years overdue; adding netmasks would add months, if not
    years, to its lifetime as an internet-draft as opposed to RFC.
  - Merging requests for source networks is harder than merging requests for
    sources
  - Routing protocols may have extremely complex mappings (e.g. how do you
    map an exclude for (192/8,G)?  Does that become up to 65536 prunes, one
    for each route in that range?  If not, what is the mapping?)

- How will IGMPv3 affect IGMP-snooping routers?

  Summary: switches need to learn about the IGMPv3 membership report;
  recognizing them may be easier due to the fact that they're all sent
  to the same group; can't do IP source filtering at the ethernet layer
  so source-specific IGMPv3 info [shouldn't] add complexity.

  cisco is implementing IGMPv3 snooping for their switches.

- How do you leave a group?

  There are 3 ways to leave a group; is one preferred?  See
http://www.aciri.org/~fenner/idmr/html-archive/2000-07/msg00040.html
  for details.  There was no discussion on this point.

- Are groups in 224.0.0.[2,255] reported?

  Yes.

From my point of view, the notable discussion issues are:
- In what way would source network masks be useful?
- A more in-depth analysis of IGMPv3 snooping
- Is there a preferred method of leaving a group?  (This may relate to
  snooping, as well)

  Bill

---

From: Isidor Kouvelas <[email-masked]>
Date: Wed, 19 Jul 2000 12:05:01 -0700

>- Are groups in 224.0.0.[2,255] reported?

I believe Paras has some comments on this.

>- Is there a preferred method of leaving a group?  (This may relate to

Leaving a group reverts to INCLUDE mode with an empty source list. This
is handled by normal protocol operation by either sending a TO_IN{}
report when the host previously was in EXCLUDE mode, or sending a BLOCK
for the remaining sources when the host was previously in INCLUDE mode.
As far as protocol consistency goes, this is the prefered method for
leaving a group.

One alternative with some advantages is to send an IS_IN with an empty
source list when a host no longer wants to receive any sources in a
group. The advantage is that a snooping switch that does not maintain an
explicit source list can use this message whereas the BLOCK will not
provide any information.

thanks
Isidor

---

From: Isidor Kouvelas <[email-masked]>
Date: Wed, 19 Jul 2000 15:48:36 -0700

Wilbert de Graaf writes:
>Isidor Kouvelas wrote:
>I also think having a single way for a host to report dropping
>membership is useful. 

As far as the host implementation is concerned, having a single way to
leave the group is extra code. The behaviour specified in the draft is
not a special case.

>If it's going to be there, I considered these three alternatives:
>
>1) send a BLOCK_OLD{0.0.0.0}: block traffic from 'any' which is valid
>for both the move from EXC{A} to INC and from INC{A} to INC{}

Really dont like this.

>2) besides sending the report as specified in the draft, also send a v2
>leave message

this either...

>3) define a IGMPv3 record to indicate a leave
>
>Although TO_IN{} seems funny when coming from INC{A}, I do think TO_IN{}
>is fine: If you think about INC{} to be defined in the draft ($5.1) as a
>special (the non-existent) state. That's exactly the transistion: from
>membership either EXC{A} or INC{A} to this special state: INC{}.
>
>For short: I would vote TO_IN{}

TO_IN is a filter-mode change record which has different effects on
a router from a IS_IN{} report. I think the IS_IN is safer. I will have
to think a bit more about this.

thanks
I

---

From: Wilbert de Graaf <[email-masked]>
Date: Wed, 19 Jul 2000 14:56:30 -0700

- Wilbert