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

[Ballot discuss]
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.

[Ballot discuss]
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.

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART

His review:

This is very much a snapshot document that leaves many open questions.
It also relies very heavily on work-in-progress references. I guess it
is perhaps useful to archive it as Informational, but keeping it alive
as a draft until some of the issues crystallize might be just as
useful.  I tend to agree with Margaret Wasserman's Discuss comments.

> 3.  Different Solutions to Inter-domain Multicast
>    When ASM is used, the Internet must be divided to multiple PIM-SM
>    for
>    both administrative and technical reasons, which means there will
>    be multiple PIM-SM RPs which need to communicate the information
>    of sources between themselves.

This sentence needs syntax corrections, and it is only an example. I
guess we can leave all that for the RFC Editor, but it will cause
delay.

[Ballot comment]
No additional DISCUSS, but Brian supports Margaret's comments - see below.

Reviewed by Brian Carpenter, Gen-ART

His review:

This is very much a snapshot document that leaves many open questions.
It also relies very heavily on work-in-progress references. I guess it
is perhaps useful to archive it as Informational, but keeping it alive
as a draft until some of the issues crystallize might be just as
useful.  I tend to agree with Margaret Wasserman's Discuss comments.

> 3.  Different Solutions to Inter-domain Multicast
>    When ASM is used, the Internet must be divided to multiple PIM-SM
>    for
>    both administrative and technical reasons, which means there will
>    be multiple PIM-SM RPs which need to communicate the information
>    of sources between themselves.

This sentence needs syntax corrections, and it is only an example. I
guess we can leave all that for the RFC Editor, but it will cause
delay.

[Ballot discuss]
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?