Subject: mboned: Re: comments on draft-ietf-mboned-routingarch solicited (fwd)

From: Jean-Jacques Pansiot <[email-masked]>
Date: Tue, 13 Jun 2006 17:59:03 +0200

Hello Pekka,

this document is very useful.  I have  a few small remarks (below),
plus one question (may be we already discussed this point, I forgot :-(( :
Almost nothing is said in the draft about addressing (and more 
precisely, how do I get a multicast address
if I want to run a multicast app).
This question is not independant of the routing arch since
solutions are different  with SSM and ASM.
This is not really a problem with SSM but what about
ASM IPv4 (besides glop and scoped addresses) ?
ASM IPv6 and embedded : how a user get a RPembedded address ?
what is the status of madcap ?

small remarks:

2.1.8
s/is it is/it is/

2.2.3
line 7:  RIB or MRIB?

2.4.1
is static anycast RP really providing RP load balancing ?
I think it is more some kind of load sharing based on proximity
(and if most sources are near the same RP, the load could be very uneven ?)
The hash method with BSR comes closer to a true load balancing ?

2.5.3 bidir
I am not sure I understand "better total convergence"
Do you mean that there is no transitional stage (register - SPT switch) 
when a new source shows up ?

2.6.1 hosts sending anycast
any concerns with multihomed sources ?
status of msnip ?

Good job

Jean-Jacques

>
>
> ---------- Forwarded message ----------
> Date: Tue, 13 Jun 2006 09:10:39 +0300 (EEST)
> From: Pekka Savola <[email-masked]>
> To: [email-masked]
> Subject: comments on draft-ietf-mboned-routingarch solicited
>
> Hi,
>
> Since the last meeting, there have been no comments on
> draft-ietf-mboned-routingarch-03.txt.
>
> As such, I'm not planning to revise it unless I get new comments.
>
> As the editor, I believe the document is ready to be WGLCed for BCP, 
> but now is your chance to speak up! ;-)
>

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 Jun 2006 19:14:18 +0300 (EEST)

Hi,

Thanks for comments,

On Tue, 13 Jun 2006, Jean-Jacques Pansiot wrote:
> Almost nothing is said in the draft about addressing (and more precisely, how 
> do I get a multicast address

You may not be aware of the earlier architecture document, which is 
supposed to describe this:

http://www.ietf.org/internet-drafts/draft-ietf-mboned-addrarch-04.txt

.. it's waiting for a write-up, i.e., soon to be IETF last called, so 
there's still time for comments if you have some (please change the 
subject line though).

> The hash method with BSR comes closer to a true load balancing ?

You're right, maybe 'load sharing' is a more precise word here.  In 
practice, however, more precise load balancing is not necessary.

> Do you mean that there is no transitional stage (register - SPT switch) when 
> a new source shows up ?

Maybe that part should be clearer, I just re-used other folks' words. 
I think the reason was the one you mentioned; no 
register-register-stop phase and no SPT switch. I'm all ears for 
suggestions.

> any concerns with multihomed sources ?

Maybe the document could state explicitly that a multicast routing 
protocols do not accommodate a moving source without redoing the 
signalling, but rather Mobile IP-like techniques might be necessary. 
But I'm not sure if that would useful enough.  If you have text 
suggestions, feel free to send them (one short paragraph maximum).

MSNIP was included in the first incarnations of this document, but was 
removed when MAGMA decided to discontinue MSNIP specification, i.e., 
we couldn't reference the spec normatively.

>> As the editor, I believe the document is ready to be WGLCed for BCP, but 
>> now is your chance to speak up! ;-)
>> 
>

-- 
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/

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Jun 2006 13:27:36 -0400

IMO, this continues to be a very useful document. Maybe it should remain
an I-D, just so it gets updated every 6 months.

A few editorial comments:

1. Section 2.1.2

"PIM-DM never really got popular due to its reliance ..."

I'd say "never became popular ... ."

2. Section 2.1.8.

"It is worth noting that is it is possible to run different protocols"

One "is" too many. Also, "otherwise" is one word.

3. Section 2.7.2

"To allow the snooping switches to identify at which ports the routers
reside (and therefore where to flood the packets) instead of requiring
manual configuration, Multicast Router Discovery protocol is being
specified [RFC4286]."

There are multiple ways discussed in IGMP snooping to discover the
switch ports at which routers reside. RFC 4286 is one of them, and
static configuration is another. But IGMP snooping also looks for the
source of IGMP queries, for example. So I'd reword that slightly to
avoid the implication that RFC 4286 is the only way.

4. Speaking of which, [I-D.ietf-magma-snoop] is now RFC 4541.

Nice work.

Bert

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jun 2006 12:13:56 +0300 (EEST)

Hi Bert,

Thanks for your comments.  I've addressed all of them.  As for your 
meta-comment,

> an I-D, just so it gets updated every 6 months.

.. I believe this needs to be published because otherwise it won't 
get any formal status and any cross-area, whole-IETF review is not 
sufficient enough.

On the other hand, a BCP is good because we can just revise the 
document e.g., every 2-3 years if there are significant changes yet 
retain the same BCP number.

Under a slightly different kind of IETF document organization (newtrk 
WG has been discussing these, e.g., "ISD" or "SRD" documents), this 
might not necessarily need to be an RFC, but whether that'll come up 
to something is a good question.