Skip to main content

Deprecating Any-Source Multicast (ASM) for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-07

Yes

Warren Kumari

No Objection

(Alexey Melnikov)
(Deborah Brungard)
(Martin Vigoureux)
(Suresh Krishnan)

Note: This ballot was opened for revision 05 and is now closed.

Warren Kumari
Yes
Roman Danyliw
No Objection
Comment (2020-01-07 for -06) Sent
** Section 4.1.  This section appears to provide multiple definitions of “separate administrative entities”.  Per the paragraph “The more inclusive interpretation of this recommendation …”, it wasn’t clear to me under what circumstance the reader should use the more “inclusive interpretation”.

** Section 4.  This section would benefit from being clearer on who should act on a few of the recommendation:

-- Section 4.3 – vendors/developers of multicast applications?

-- Section 4.4 – not clear who is supposed to develop this guidance?  

-- Section 4.6 – not clear who is supposed to developing this guidance long term

** Editorial Nits:
-- Section 3.2.3. Typo. s/particularily/particularly/

-- Section 4.9.  Typo. s/implentations/implementations/
Éric Vyncke
No Objection
Comment (2020-01-03 for -06) Sent for earlier
Thank you for the work put into this document. The document is really easy to read with a nice introduction. I trust the responsible AD and my routing colleagues on their evaluation whether it is reasonable, sensible and useful to deprecate ASM in interdomain deployments.

Regards,

-éric

== COMMENTS ==
Mostly a DISCUSS but really trivial to fix, please refer to RFC 8174 in addition to RFC 2119.

Also, AFAIK, Toerless is affiliated to Futurewei and not Huawei, please fix his affiliation in the header.

== NITS ==

-- Section 2.3 --
Please use lowercase in IPv6 addresses.
Alvaro Retana Former IESG member
Yes
Yes (2020-01-08 for -06) Sent
Just a documentation nit:  this document should be tagged in the Datatracker as replacing draft-acg-mboned-deprecate-interdomain-asm.
Adam Roach Former IESG member
No Objection
No Objection (2020-01-08 for -06) Not sent
Thanks for this well-written and well-reasoned document. Given the rather limited knowledge I have of the nuts and bolts of how multicast works at the routing layer, I found the text clear and easy to follow.
Alexey Melnikov Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2020-01-06 for -06) Sent
A couple of suggestions to help the document be more timeless:

= Section 2.2.1 =

s/To this day/At the time of this writing/

= Section 4.4 =

OLD
While the WG discussions had consensus that best practices should be
   developed to explain when to use SSM in applications, e.g, when ASM
   without (S,G) state in the network is better, or when dedicated
   service-discovery mechanisms should be used, it was agreed that
   documenting such practices are outside the scope of this document.

NEW
This document describes best practices to explain when to use SSM in applications, e.g, when ASM without (S,G) state in the network is better, or when dedicated service-discovery mechanisms should be used, but specifying these practices is outside the scope of this document.
Barry Leiba Former IESG member
No Objection
No Objection (2020-01-07 for -06) Sent
Thanks for a very clear document that was an easy read.  I just have a few very minor editorial suggestions, which need no specific reply:

— Section 2.1 —

   Source discovery
   in SSM is handled by some out-of-band mechanism (i.e., the
   application layer)

The “i.e.” seems a bit odd here to my eye.  I’d suggest wording this without the parentheses altogether, thus:

NEW
   Source discovery
   in SSM is handled by some out-of-band mechanism in the
   application layer
END

— Section 2.3 —

   PIM-SSM expects that the sender's source address(es) is known in
   advance by receivers

The “is” sounds odd with “addresses”, and it’s always difficult to know what to do for number agreement with things such as “address(es)”.  I suggest writing around the problem this way:

NEW
   PIM-SSM expects the sender's source address(es) to be known in
   advance by receivers
END

— Section 3.2.2 —
There needs to be a hyphen in “network-wide”.

— Section 4.1 —

   This document recommends that the use of ASM is deprecated for
   interdomain multicast

This needs subjunctive mood: “that the use of ASM be deprecated”.
Benjamin Kaduk Former IESG member
No Objection
No Objection (2020-01-08 for -06) Sent
Thanks for this well-written document!

Section 2.1

   to deliver traffic from the sender(s) to the receivers.  If there are
   multiple senders for a given group, traffic from all senders will be
   delivered to the receiver.  Since receivers specify only the group

nit: "receivers" plural.

Section 3.1

   troubleshoot.  Some of these issues include complex flooding Reverse
   Path Forwarding (RPF) rules, state attack protection, and filtering
   of undesired sources.

I'm not sure how to parse "complex flooding Reverse Path Forwarding
(RPF) rules" (but think I could figure out "complex Reverse Path
Forwarding (RPF) flooding rules" -- do I need to try harder?

   within one domain.  While this approach solves the MSDP issues, it
   does not solve the problem of unauthorised sources sending traffic to
   ASM multicast groups; this security issue is one of biggest problems
   of interdomain multicast.

Perhaps it's worth expanding on the security issue as including a
substantial level of traffic amplification.  (Or do I misunderstand the
security issue?)

Section 4.1

   The more inclusive interpretation of this recommendation is that it
   also extends to deprecating use of ASM in the case where PIM is

Are we claiming or disclaiming this "more inclusive interpretation"?
The current wording feels ambiguous, and I don't think we should leave
it that way.

Section 4.2

   support SSM (i.e., explicitly sending source-specific reports).  The
   updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states

nit: the I-D reference is not yet an RFC, so it's not proper to refer to
it as one; since it's only an informative reference we will not
necessarily wait to publish this document until that one has an RFC
number assigned, so I think this should be reworded.  (Also, even if
there was a new RFC number, "updated [...] RFC [RFCXXXX]" would still
scan kind of strangely.)

Section 4.3

   The recommendation to use SSM for interdomain multicast means that
   applications should properly trigger the sending of IGMPv3/MLDv2
   source-specific report messages.  It should be noted, however, there
   is a wide range of applications today that only support ASM.  In many
   cases this is due to application developers being unaware of the
   operational concerns of networks.  This document serves to provide
   clear direction for application developers to support SSM.

Without some discussion of the relative level of difficulty for applications
tosupport SSM (to compare against the well-portrayed problems with network
support for ASM), it would be fairly easy to misread this as network
operators getting an IETF BCP to try to force applications to do what's easy
for the network.  I'm given to understand that's not actually the case here,
as the changes in application software are fairly minor, and no one would
expect existing applications to grow a way to announce multicast source
addresses spontaneously, so a little more text might go a long way.

Section 4.4

   While the WG discussions had consensus that best practices should be
   developed to explain when to use SSM in applications, e.g, when ASM
   without (S,G) state in the network is better, or when dedicated
   service-discovery mechanisms should be used, it was agreed that
   documenting such practices are outside the scope of this document.

It might be possible to rephrase this in terms of "the conclusions of
the MBONED WG" or "the consensus of the MBONED WG"; the current phrasing
feels a little informal to me, though I don't place much weight on my
sentiment here.

Section 4.6

A lot of this section feels somewhat speculative and leaves me uncertain
what the BCP recommendations in this space are.

   In the case of existing ASM applications that cannot readily be
   ported to SSM, it may be possible to use some form of protocol
   mapping, i.e., to have a mechanism to translate a (*,G) join or leave
   to a (S,G) join or leave, for a specific source, S.  The general

nit: I think this would read better with fewer commas, i.e., "to
translate a (*,G) join or leave to a (S,G) join or leave for a specific
source S".

Section 4.9

   it.  This allows easy migration of ASM applications to SSM/PIM-SSM
   solely through application side development to handle source-

nit: hyphenate "application-side".

   signaling via IGMPv3/MLDv2 and using SSM addresses.  No network

Do the application developers also consider this work "easy"? ;)

   When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also
   result in the desired PIM-SSM (S,G) operations and bypass any RP
   procedures, but this is not standardized but depends on
   implementation and may require additional configuration in available
   products.  [...]

nit: this sentence is fairly long and convoluted; could it be reworded
and/or split up into smaller pieces?

   Note that these migration recommendations do not include the
   considerations when or how to evolve those intradomain applications
   best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM.  This may also
   be important but is outside the scope of this document.

nit: is there a missing word ("for"/"about"/"on") after
"considerations"?

   Accordingly, this document recommends that future work for general
   purpose interdomain IP multicast focus on SSM items listed in
   Section 4.

nit: hyphenate "general-purpose".

Section 6

We could perhaps consider mentioning again the consequences of
infrastructure assuming that SSM-range addresses are always used for
SSM, such as during the transition period where applications migrating
from ASM to SSM continue to use ASM-range addresses, as mentioned in
Section 4.7.

Changing the model for intradomain multicast to one where
source discovery/state-propagation is not done by the network and is
instead a responsibility of the application layer means that the
applications are responsible for properly implementing such
functionality.  While it's true that we do want applications to not have
bugs in general (and that would hopefully go without saying), we might
want to discuss the scope of potential issues if applications get this
wrong.  Could application bugs (or bugs in host-level IGMPv3 or MLDv2
implementations) specific to SSM usage lead to any worse problems than
just "application traffic doesn't flow", e.g., state exhaustion in the
network?

Section 10.1

I'm not seeing any references to RFC 4610 that would qualify it as
normative; if normative is indeed the proper status, perhaps additional
citations are in order?
Deborah Brungard Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2020-01-06 for -06) Sent
Thanks for this well-written document.

I'm by far no expert here but reading this document it sounds a bit like RFC3618 should be moved to historic... was that discussed?

This document seem not to use normative RFC2119 language but I think could benefit from it. Was that considered?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -06) Not sent