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

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 17 Feb 2005 15:13:46 -0500

Pekka Savola wrote:

> Jerome Durand wrote:
> > <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.
> 
> Sigh.  That was a 5 year old quote.  Maybe I should just remove it...

I wouldn't just remove it. I think it's important to include text that explains why ASM is still appropriate, even for IPv6, if indeed we decide it is. There are situations in which shared multicast trees make sense and in which it's best not to require any knowledge of multicast sources from group members (either include or exclude).

Not sure about debugging discussions. Sounds useful, but I don't see any such universal precedent in RFCs. I agree completely that if such discusion is included, it seems that the discussion should not be restricted to just RP debugging.

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

To stay with the tone of the RFC, the issue can be mentioned without being solved?

In short, I think this RFC is useful. Over the years, there have been way too many multicast proposals that came and went, and not everyone has followed the sequence closely enough to know where we stand today. An RFC that ties up all these loose ends, and specifically includes IPv6, is very valuable, IMO.

Bert

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