Subject: Re: mboned: I-D on overview of multicast routing

From: Jean-Jacques Pansiot <[email-masked]>
Date: Wed, 01 Dec 2004 15:35:07 +0100

Pekka Savola wrote:

> Hi,
>
> There was some support at IETF61 for creating a similar document as 
> the "multicast address architecture", but about multicast routing.

Hi,
very nice and useful work

First a general question:  is this a BCP about available technologies,
or a state of the art about technologies that should be available in the 
(near) future ?

Here are a few comments:

- in the introduction of section 2.2 you say that learning active 
sources is easy in a single domain with a single RP but completely 
unscalable to the whole Internet. Then in paragraph 2.2.3 you explain 
embedded-RP
that just does it ?  You should say what is unscalable (BSR, ...)

-  after the list of multicast routing protocols (section 2.3) , some 
for intra-domain only others for inter-domain, a paragraph on protocol 
interactions would be useful (say after 2.3.5)
(saying that different protocols can be run on different address ranges,
and  for inter-domain, PIM-SM is currently the only solution)

- section 2.4 The title should say that its about PIM-SM ? (configuring 
RP for PIM-SM)*

- section 2.5.2 A word about IGMPv2/MLDv1 , currently MLDv2 is not 
available with some well known OS ?
For example "PIM-SSM cannot be used with previous versions (IGMPv2, 
MLDv1) still  widely deployed in hosts"

- In   section  2.6.2 CGMP : what do you mean by "relatively clean 
solution" ?
It appears that CGMP switches have to process IGMPv2 leave messages,
and if IGMPv3 is used go back to the ""slow leave" situation (see below 
from http://www.cisco.com/warp/public/473/22.html#cgmp)
"Also, when using IGMPv3 in the network, switches using CGMP work 
normally apart from the fact that CGMP Fastleave does not work. If CGMP 
Fastleave is needed, it is best to revert to IGMPv2."
If I understand correctly "slow leave", once a port is added to a group, 
it remains there
until the group has no members at all in the switched LAN.
Also to my knowledge  there is currently no IPv6 support in CGMP.

-  Concerning  the reference [GARP], why not reference  the standard :
ANSI/IEEE Std 802.1D (also ISO/IEC 15802-3:1998)
where GARP and GMRP are specified ?

Jean-Jacques

>
> I've submitted a short I-D on this, but as it wasn't published 
> yesteday yet, here it is:
>
> http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-routingarch-00.txt
>
> Abstract
>    The lack of up-to-date documentation on IP multicast routing
>    protocols and procedures has caused a great deal of confusion.  To
>    clarify the situation, this memo describes the routing protocols and
>    techniques currently (as of this writing) in use.
> [....]
>    This memo deals with:
>
>    o  distributing multicast topology information (Section 2.1),
>    o  learning active sources (Section 2.2),
>    o  setting up multicast forwarding state (Section 2.3),
>    o  configuring the multicast network elements (Section 2.4),
>    o  interacting with hosts (Section 2.5), and
>    o  restricting the multicast flooding in the link layer (Section
>       2.6).
>
> Comments are welcome, of course.  In particular, I'd be interested in 
> hearing if folks think this should be merged in the same document with 
> the addressing architecture.
>

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Wed, 1 Dec 2004 22:36:28 +0200 (EET)

Thanks for your comments.  It's glad to see so many have found this 
interesting and responded so quickly.  :)

Inline..

> or a state of the art about technologies that should be available in the 

I've tried to stick to already-specified (and implemented mechanisms), 
but the slope has been slippery (e.g., there's text on MSNIP which 
might end up being removed).

In short -- if it's specified as an RFC, or expected to be RFC when 
this gets out, it should be OK.

If you have some specific concern in mind, fire away..

> Here are a few comments:
>
> - in the introduction of section 2.2 you say that learning active sources is 
> easy in a single domain with a single RP but completely unscalable to the 
> whole Internet. Then in paragraph 2.2.3 you explain embedded-RP

You probably refer to this:

    Learning active sources is a relatively straightforward process with
    a single PIM-SM domain and with a single RP, but this is a completely
    unscalable model for many reasons for the whole Internet.

This is ambiguous.  'This' refers to "having a single PIM-SM domain", 
not that active source discovery is necessarily unscalable.

> -  after the list of multicast routing protocols (section 2.3) , some for 
> intra-domain only others for inter-domain, a paragraph on protocol 

Agree, this could be clearer.  Maybe I'll try to do a simple table 
here.

> - section 2.4 The title should say that its about PIM-SM ? (configuring RP 
> for PIM-SM)*

Hmm.  Maybe, I'll consider this.

> - section 2.5.2 A word about IGMPv2/MLDv1 , currently MLDv2 is not available 
> with some well known OS ?
> For example "PIM-SSM cannot be used with previous versions (IGMPv2, MLDv1) 
> still  widely deployed in hosts"

MLDv2 is actually rather widely available on newer versions of 
systems, but I might add something here.

I might also refer to a different document about the issues with 
SSM/MLDv2/IGMPv3 (typically the problem comes from snooping switches 
which either mistreat IGMPv3/MLDv2/SSM or force you to flood all 
mcast).

> - In   section  2.6.2 CGMP : what do you mean by "relatively clean solution" 
> ?
> and if IGMPv3 is used go back to the ""slow leave" situation (see below from 
> http://www.cisco.com/warp/public/473/22.html#cgmp)
> "Also, when using IGMPv3 in the network, switches using CGMP work normally 
> apart from the fact that CGMP Fastleave does not work. If CGMP Fastleave is 
> needed, it is best to revert to IGMPv2."
> If I understand correctly "slow leave", once a port is added to a group, it 
> remains there

I didn't know of this IGMPv2 report snooping fast leave functionality; 
I'll soften the tone a bit.

> Also to my knowledge  there is currently no IPv6 support in CGMP.

Correct, AFAIK.

> where GARP and GMRP are specified ?

It seemed the reference I had described it a in a more understandable 
and terse fashion.  It should be apparent where to find the spec 
itself.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/