Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction
draft-ietf-magma-igmpv3-and-routing-05

AD review comments sent to list:


Overall the document looks ok and most of these comments are about clarity.

The "terminology" used can be confusing.
For instance, in section 2 is says "source ... included in the database".
Given that a multicast address in the database can be in either include
or exclude mode I think the above should say "to be forwarded according to
the information in the database".

It would also be good to specify in section 2 that the database
can have records of the form (and their semantics)
include
exclude
include <> Means nobody is interested
exclude <> Means interested for all sources

Section 3 says:
  IGMP version 3 and MLD version 2 specify that if at any point a
  router receives an older version query message on an interface that
  it must immediately switch into a compatibility mode with that
  earlier version.
I haven't double-checked, but is this really true?
I thought the spec had an admin knob that could say to ignore routers
with old versions.

Section 4.1/4.2:
This is good because it talks in terms of state changes but the description
of the state change is a bit fuzzy.

Section 6.1 should presumably have almost identical text to 4.1
but instead it talks about "being EXCLUDED", which is not defined,
and a "Leave message", which does not exist in IGMPv3/MLDv2.
So why not have it use the same text as 4.1?

Section 6.2: similar - why not use the same text as 4.2?

Section 7.1:
Here we get too fuzzy. It talks about "reception" of packets when presumably
the issue is state changes in the IGMPv3/MLDv2 state whether that is
caused by a packet or a timer.

This makes me think that it would be quite useful to add text to
section 2 specifying the type of state changes that effect the routing
protocol and how those are related to the IGMPv3/MLDv2 state.

I think there are only 4 state changes:
Dropping interest in a group for all sources
(i.e. state change from any state to include <>)

Adding interest in a source address
e.g. from include to include
or from exclude  to exclude
or from include  to exclude  (this one is odd)

Loosing interest in a source address
Inverse direction of transitions under "adding interest"

Adding interest for all source addresses
state change from any to exclude <>


That way section 4 through 7, especially 7.1 and 7.2, can be more succinct.

Section 7.1:
  It also can cause failures in some specific network
  architectures, and thus, can be overridden by local policy.
I'm not sure what "it" refers to? Is it the practise to send
report towards S?
What type of failures?
(As an implementor I would have no idea what impact the above sentence
is supposed to have on my understanding and/or the code I produce.)

  If this
  is the case, then all triggered joins are sent towards the RP as
  (*,G) joins. The initiating router is responsible for filtering the
  data before forwarding to the requesting network. 

"initiating router" and "requesting network" are undefined.

Section 8:
What is the reason for not covering PIM-SSM interaction in this document?
Too complex? Not yet decided by the SSM WG?

  [SSM]  H. Holbrook, et al, "Source-Specific Multicast for IP", work
          in progress.
I observe that this reference is only used for the SSM range.
Is there another reference that documents merely the SSM range?

Section 7:
  A PIM-SM interaction takes place when a PM-SM [PIMSM] router
  receives an IGMP or MLD message regarding a group address that is in
  the Any Source Multicast (ASM) range. This range is defined as the
  entire multicast address space excluding the global SSM range [SSM]
  and any locally defined Source Specific space. 
Wouldn't it be useful to add a reference to the mrdssm document at "locally
defined"?

Nits:
  routing protocols to manage and utilize the information.  This
  document will describe how multicast routing protocols will interact
  with these source-filtering group management protocols.
s/will describe/describes/

  Erik

Date: Mon, 3 Feb 2003 09:56:30 -0500
X-Authentication-Warning: ietf-ops.ietf.org: nobody set sender to iesg-secretary@ietf.org using -f
From: "Brian Haberman" 
To: iesg-secretary-req-dist@ietf.org
Subject: [iesg-secretary #5284] Request Advancement of draft-ietf-magma-igmpv3-and-routing-04.txt
Reply-To: iesg-secretary@ietf.org
X-Loop: WREQ 2


>From: Brian Haberman
>To: Erik Nordmark , Thomas Narten
>Subject: Request Advancement of draft-ietf-magma-igmpv3-and-routing-04.txt


Erik & Thomas,
      On behalf of the MAGMA working group, the chairs would like
to submit draft-ietf-magma-igmpv3-and-routing-04.txt as an
Informational document.  The working group last call passed on
January 24, 2003.


Regards,
Brian & Bill