Subject: [magma] AD review of magma-igmpv3-and-routing-04.txt

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 May 2003 10:57:34 +0200 (CEST)

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 <list>
	exclude <list>
	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 <a> to include <a, b>
		or from exclude <a, b> to exclude <a>
		or from include <x> to exclude <y> (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

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma