IPv6 Multicast Deployment Issues
draft-ietf-mboned-ipv6-multicast-issues-02

I can see this is a document raising the issues about how to proceed in IPv6 multicast -
it would be useful to state up front that it is not supposed to come to conclusions - I'm
pretty sure it does not.  This is not actually my Discuss though.

My Discuss is about ASM and whether there really is enough any demand to strain for inter-
domain ASM.  The applications given are  large chat rooms, videoconferencing and multi-user
games.  Of course, we know that bridges must precede their crossing, but even in Internet2, which
has faithfully provided ASM, much application use in these spaces has developed strongly without
ASM (see XCON, big IM chatrooms, large-scale online games, peer2peer stuff).  I'm very supportive
of multicast and I see a lot of applications - many from RMT now.  But I believe that ASM conferencing
has been mainly in enterprises, if at all.

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".
Its security considerations section is not reasonable either - the body of the text uses security as an argument.
I do not see that the IETF is usefully served by permanently archiving this rather disjointed set of notes on multicast in IPv6.

It would take a VERY strong argument that "this is as good as it gets" to make me say "this is good enough".

Brian (gen-ART reviewer) supports Margaret's comments - see comment.

I am sorry for this rather broad and befuddled discuss, but I don't think 
that I understand the goals of this document.  This document points out 
some problems with IPv6 multicast and makes some somewhat
contradictory statements about possible solutions to those problems.

Is it recommending particular operational practices?  Is it
recommending changes to existing IETF standards?  Or the creation of
additional standards?  Is it listing problems that will be analyzed
and/or explore elsewhere?  Or is this document attempting to analyze
these problems and investigate the trade-offs between different
solutions?

Many of my detailed comments (see below) are editorial in nature, but
they also relate to the clarity of the document.  The document is
difficult to follow, and I think that it lacks the clarity necessary
for the reader to understand the operational problems with IPv6
multicast and the trade-offs between different solutions.

Also, it is not clear to me that all of these issues (for example, the
lack of SSM deployment) are specific to IPv6 multicast (as opposed to
IPv4).

I'd like to see a more rigorous analysis of the problems specific to
IPv6 multicast deployment and clearer statements regarding the
trade-offs between different proposed solutions.  I'd also like to
better understand what this document is (or is not) recommending
to network operators and/or the IETF.

Is the mboned WG planning/expecting any follow-on activity based on
this document?

My detailed comments are in-line (marked with '>>'):

   Section 2 describes the justifications for providing an inter-domain
   multicast solution using Any Source Multicast (ASM) with IPv6.
   Section 3 in turn describes which options were considered for filling
   those the requirements for the IPv6 inter-domain multicast solutions.

>> s/those//

   ASM     Any Source Multicast
   BSR     Bootstrap Router
   CGMP    Cisco Group Management Protocol
   DR      Designated Router
   IGMP    Internet Group Management Protocol
   MLD     Multicast Listener Discovery
   MSDP    Multicast Source Discovery Protocol
   PIM     Protocol Independent Multicast
   PIM-SM  Protocol Independent Multicast - Sparse Mode
   RP      Rendezvous Point
   SSM     Source-specific Multicast

>> I think there should be references included for these definitions.

   This section documents the reasons and the discussion which led to
   the agreement why a solution to IPv6 inter-domain ASM was necessary.

>> s/why a/that

   The most difficult issue, multicast usage models, remains a problem
   as of this writing.  

>> The problem of "multicast usage models" has not been previously introduced.
>> Am I expected to know what it is at this point in the document?

   Many ASM applications are used with a smaller scope than global; some
   of these have a wider scope than others.  However, groups of smaller
   scope typically need to be in their own PIM-SM domains to prevent
   inappropriate data leakage.  Therefore if a site has groups of
   different scopes, having multiple PIM domain borders becomes a
   requirement unless inter-domain multicast is used instead; 

>> How would inter-domain multicast eliminate the need for multiple
>> PIM domain borders?

   further, configuring such nesting scopes would
   likely be an operational challenge.

>> What challenges would be involved?

   In consequence, if these
   applications of non-global scope need to be used, inter-domain
   multicast support is practically
   required.

   In consequence, especially if multicast with different non-global
   scopes is used, there will be a need for inter-domain multicast
   solutions.  

>> These two sentences seem to be redundant.

3.  Different Solutions to Inter-domain Multicast

   When ASM is used, the Internet must be divided to multiple PIM-SM for

>> s/to multiple PIM-SM/into multiple PIM-SM domains/ ??

   both administrative and technical reasons, which means there will be
   multiple PIM-SM RPs which need to communicate the information of
   sources between themselves.

>> What does "communicate the information of sources" mean?

   On the other hand, SSM does not require RPs and also works in the
   inter-domain without such communication.  Section 2 describes the
   justification why Inter-domain ASM was still considered to be
   required.  This section describes different solutions which were
   discussed to providing inter-domain multicast for IPv6.

   For inter-domain multicast, there is consensus to continue using SSM,
   and also use Embedded-RP as appropriate.

>> Consensus of whom?  Section 2 seems to say that SSM cannot
>> practically be used instead of ASM.  Would Embedded-RP handle the
>> many-to-many case?

   This section provides historical reference of the discussion and
   decisions.

   In any case, even though SSM would avoid the problems of ASM, it was
   felt that SSM is not sufficiently widely available to completely
   replace ASM (see Section 2.1), and that the IETF should not try to
   force the application writers to change their multicast usage models.

>> So, there is consensus to use SSM and Embedded-RP, and there is
>> also consensus not to use SSM?

>> It was felt by whom?  The passive voice is confusing in these
>> sections and it would be clearer to be declarative.  For instance,
>> instead of saying "it was felt that SSM is not sufficiently..." say
>> "SSM is not sufficiently...".

   In fact, Border Gateway Multicast Protocol (BGMP)
   [I-D.ietf-bgmp-spec] has been specified; however, it is widely held
   to be quite complex and there have been no implementations, nor will
   to make any.  

>> s/it is widely held to be quite/it is quite/

>> I'm not certain what the last clause means...  Perhaps:
>> s/implementations, nor will to make any./implementations./  ??

   Lacking deployment experience and specification
   analysis, it is difficult to say which problems it might solve (and

>> s/problems it/problems BGMP/

   possibly, which new ones to introduce).  One probable reason why BGMP

>> s/to introduce/BGMP might introduce/

   To completely replace the need for MSDP for IPv6, a different way to
   implement "Anycast RP" [RFC3446] -technique, for sharing the state
   information between different RP's in one PIM-SM domain, is also
   needed.  One such approach is described in [I-D.ietf-pim-anycast-rp].

>> Something seems to be wrong with this paragraph around
>> "-technique".  It doesn't parse and I am not quite sure what it is
>> trying to say.

   The author has seen one brand of managed Ethernet switches, and heard
   reports of a few unmanaged switches, that do not forward IPv6
   link-local multicast packets to other ports at all.  

>> Is there value in making this type of statement?  I have seen a
>> commercial TCP implementation that didn't retransmit and another
>> that sent 0 checksums on all TCP retransmissions, but those weren't
>> operational problems with TCP deployment, they were bugs.

   In essence,
   native IPv6 is impossible with this equipment.  These problems have
   likely been fixed in later revisions of the equipment, but this does
   not fix the equipment on the field, and it is likely that similar
   problems will surface again.

[...]

   One workaround might be to implement a toggle in the nodes that would
   use link-layer broadcast instead of multicast as a fallback solution.
   However, this would have to be used in all the systems on the same
   link, otherwise local communication is impaired.

>> These two paragraphs seem to be inconsistent.  If the problem is
>> with existing deployed equipment that can't be changed, it seems
>> unlikely that implementing a toggle on new equipment would help.

   In addition, some vendors have not realized which multicast addresses
   (in particular, link-local addresses) MLD reports -- utilized in the
   snooping -- should be generated for.  

>> It is not clear to me what this sentence means.  Is this another
   bug?