Subject: mboned: Comments to draft-ietf-mboned-ipv6-multicast-issues-01.txt

From: Jerome Durand <[email-masked]>
Date: Wed, 16 Feb 2005 16:34:08 +0100

Hi,

<quote>
       The most serious criticism of the SSM architecture is that it does
       not support shared trees which may be useful for supporting
       many-to-many applications.  In the short-term this is not a
       serious concern since the multicast application space is likely to
       be dominated by one-to-many applications.  Some other classes of
       multicast applications that are likely to emerge in the future are
       few-to-few (e.g.  private chat rooms, whiteboards), few-to-many
       (e.g., video conferencing, distance learning) and many-to-many
       (e.g., large chat rooms, multi-user games).  The first two classes
       can be easily handled using a few one-to-many source-based trees.
</quote>

It's not true, even some apps that follow the SSM model use today ASM.

<quote>
3.4  Embedding the RP Address in an IPv6 Multicast Address
</quote>

I think we need somewhere to address the management problems that we get 
with embedded-rp.

I am using an external RP. I have a problem. How do I debug? Should I 
contact the local NOC? The RP NOC? How does the escalation work? I mean 
how does it meet ISP's needs in terms of management.

Also, I deploy an embedded-RP (for global scope), I maybe don't want 
everyone to use it. How does it work?

To me this draft could be the appropriate place for that as it's an IPv6 
mcast issue :)

Your ideas?

Jerome

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

---

From: Jerome Durand <[email-masked]>
Date: Wed, 16 Feb 2005 16:55:57 +0100

> 3.4  Embedding the RP Address in an IPv6 Multicast Address

Oups sorry this is addresses in section 4.1.2.
Anyway I guess we should better state the problem that it's not only 
controling the thing but is also a matter of management (procedures we 
foresee?) I'll try to provide some text.

Jerome

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Feb 2005 20:34:44 +0200 (EET)

Hi,

It's ironic that after 5 months of quietness, just when I sent a 
revised version to [email-masked], someone says something ;-).

Basically, the IESG didn't like -01 document *), well, quoting Harald 
Alvestrand:

"I find this document very hard to parse. It's a mess content-wise, 
jumping from subject to subject without any clear plan, and showing no 
trace of an overall plan for "multicast in IPv6". [...]
I do not see that the IETF is usefully served by permanently archiving 
this rather disjointed set of notes on multicast in IPv6."

Well, I partially agree with that, and -02 is a start in trying to 
improve the document.  But we (as the WG) will need to figure out what 
we want to do with the document.

*) see 
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1523&filename=draft-ietf-mboned-ipv6-multicast-issues

Inline...

> It's not true, even some apps that follow the SSM model use today ASM.

Sigh.  That was a 5 year old quote.  Maybe I should just remove it...

> I think we need somewhere to address the management problems that we get with 
> embedded-rp.
>
> I am using an external RP. I have a problem. How do I debug? Should I contact 
> the local NOC? The RP NOC? How does the escalation work? I mean how does it 
> meet ISP's needs in terms of management.
>
> Also, I deploy an embedded-RP (for global scope), I maybe don't want everyone 
> to use it. How does it work?
>

Well, there are multiple issues here:

  - what should be the operational procedures for debugging problems 
with multicast, especially how it differs from what was done before, 
but I'm not convinced an IETF RFC is the right place for this work.

I'm not totally against the idea -- this may or may not be worth 
pursuing in MBONED -- but it should take a higher view, and detail 
suggested procedures for _all_ multicast debugging, not just 
embedded-RP.

  - restricting who can use the group.  This seems more of an 
operator-vendor interaction: operators must come up with requirements 
and/or features they would like to see supported, then vendors do 
those.  It might be OK to discuss these requirements and/or features 
in an IETF document, but before we have actual experience on what's 
really needed, putting these in an RFC seems premature.

Hence, it seems that the problem space is worth mentioning (actually 
section 4.1.2 tried to do it already), but 
draft-ietf-mboned-ipv6-multicast-issues-xx seems like the wrong place 
to elaborate on it.

That said, I'm open to suggestions how to improve the text.

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