Subject: [Last-Call] Genart last call review of draft-ietf-mboned-deprecate-interdomain-asm-05

From: Dale Worley via Datatracker <[email-masked]>
Date: Sat, 21 Dec 2019 13:10:49 -0800

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please treat these comments just like
any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:  draft-ietf-mboned-deprecate-interdomain-asm-05
Reviewer:  Dale R. Worley
Review Date:  2019-12-21
IETF LC End Date:  2019-12-23
IESG Telechat date:  not set

* Summary:

       This draft is basically ready for publication, but has some
       nits that should be fixed before publication.

* Major issues:

None

* Minor issues:

None of the recommendations are phrased with SHOULD, which I think
would be natural for a BCP.  The word "recommends" is used, and
replacing it with "RECOMMENDS" seems natural, but the RFC 2119 word is
"RECOMMENDED".  I guess you use the passive construction "It is
RECOMMENDED ...".  But perhaps the convention is not to use RFC 2119
words in BCPs.

* Nits/editorial comments: 

Requirements Language and Terminology

This section should be updated from RFC 2119 to RFC 8174.

1.  Introduction

   ... there has been
   no strong recommendation made by the IETF on the appropriateness of
   those models to certain scenarios, even though vendors and
   federations have often made such recommendations.

   This document addresses this gap by making a BCP-level recommendation
   ...

This isn't phrased correctly; it reads as if it is important for the
IETF "to make a strong recommendation" per se, and that is the primary
motivation for this document.  Instead, something like:

   It has become known that SSM is significantly superior to ASM in
   interdomain multicast uses, so this document changes the situation
   by making a BCP-level recommendation to deprecate the use of ASM
   for interdomain multicast, leaving SSM as the recommended
   mode of interdomain multicast.

2.1.  Multicast service models

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

s/ie/i.e./

3.1.  Observations on ASM and SSM deployments

   Some of these issues include complex flooding RPF
   rules, state attack protection, and filtering of undesired sources.

I assume "RPF" means "Reverse Path Forwarding" here.

   Support for IGMPv3 and MLDv2 has become widespread
   in common OSes for several years (Windows, MacOS, Linux/Android) and
   is no longer an impediment to SSM deployment.

It's probably worth stating that the large router vendors also support
these protocols.

3.2.2.  No network wide IP multicast group-address management

   receive each others IP multicast traffic.

s/others/other's/  (Or is that "others'"?  Have to check with the Editor!)

4.  Recommendations

   The more inclusive interpretation of this recommendation is that it
   also extends to the case where PIM may only be operated in a single
   operator domain, but where user hosts or non-PIM network edge devices
   are under different operator control.

The use of "inclusive" is a bit ambiguous, as it's not clear whether
the intention is to expand what is deprecated or to expand what is
approved.  I think this can be solved by changing "extends to" to
"also deprecates":

   The more inclusive interpretation of this recommendation is that it
   also deprecates the case where PIM is operated in a single operator
   domain, but where ...

4.4.  Developing application guidance: SSM, ASM, service discovery

   Applications with many-to-many communication patterns can create more
   (S,G) state than feasible for networks, whether the source discovery
   is done by ASM with PIM-SM or at the application level and SSM/PIM-
   SM.

This is unclear to me.  I think you want "at the application level
with SSM/PIM-SM" for parallelism.

But it's also not clear what "more state feasible for networks" means.
I think it means "more state than is feasible for networks to manage",
but that doesn't seem to mesh with "... or at the application level".
Perhaps the meaning is "more state than is feasible to manage".

   Unfortunately, today
   many applications simply use ASM for service discovery.

Probably better to say "many applications use ASM solely for service
discovery", as "simply" could be read in a number of ways.

4.5.  Preferring SSM applications intradomain

   If feasible, it is recommended for applications to use SSM even if
   they are initially only meant to be used in intradomain environments
   supporting ASM.

It seems like the words "If feasible" are reduendant given the meaning
of "recommended" (or at least the meaning of "RECOMMENDED").

4.8.  Not precluding Intradomain ASM

   In the past decade, Bidir-PIM too has seen deployments to scale
   interdomain ASM deployments beyond the capabilities of PIM-SM.

Perhaps change "Bidir-PIM too has seen deployments to scale
interdomain ASM" to "some Bidir-PIM deployments have scaled
interdomain ASM ...".

4.9.  Evolving PIM deployments for SSM

   In general, it is recommended to always use SSM address
   space for SSM applications.

I can see an advantage using "RECOMMENDED" here, to make sure this
sentence is not overlooked.

5.  Future interdomain ASM work

   Such work could modify or amend the recommendations of this document
   (like any future IETF standards/BCP work).

This could mean either

   Such work could modify or amend the recommendations of this document
   (as could any future IETF standards/BCP work).

or

   Such work (e.g., any future IETF standards/BCP work) could modify
   or amend the recommendations of this document.

[END]

---

From: Tim Chown <[email-masked]>
Date: Sun, 22 Dec 2019 10:09:38 +0000

Hi,

Thanks for the review Dale, comments in-line...

> On 21 Dec 2019, at 21:10, Dale Worley via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Dale Worley

That’s a good point; will discuss with the other authors and perhaps check with the RFC Editor.  As another review pointed out, currently the only 2119 language refers to another RFC.

>   mode of interdomain multicast.

Well, I think the discussion in mboned was around the lack of an IETF recommendation.  Personally, I quite like how it is phrased, as it speaks to the rationale for the document being written, but again I’ll check with the other authors.

>   in SSM is handled by some out-of-band mechanism (ie, the application

Thanks, one less for the RFC Editor :)

> I assume "RPF" means "Reverse Path Forwarding" here.

Yes, thanks, other reviews have also suggested we need to do some first use expansions of the acronyms in general in the document.  Will fix in the next rev.

> It's probably worth stating that the large router vendors also support

I think the point being made here is that use of SSM was only made practical once host support was added, and was generally the last piece in the deployment puzzle.  We also ensured that support for MLDv2, as a MUST, was added to the IPv6 Node Requirements RFC update.

> s/others/other's/  (Or is that "others'"?  Have to check with the Editor!)

Probably others’, but yes :)

>   also deprecates the case where PIM is operated in a single operator

Or maybe 

The more inclusive interpretation of this recommendation is that it  
also extends to deprecating use of ASM in the case where PIM is 
operated in a single operator domain, but where ...

?

> Perhaps the meaning is "more state than is feasible to manage".

I think what we’re trying to say is that if applications create a significant amount of (S,G) state then that may become problematic for networks to manage, particularly where the applications run over multiple domains, or as you say 
"more state than is feasible for networks to manage".

> discovery", as "simply" could be read in a number of ways.

Yes, I think either of your suggestions would improve that.

> of "recommended" (or at least the meaning of "RECOMMENDED").

There was some pushback in earlier discussions on this, “if feasible” was added as a compromise.  Ultimately, what an operator does in their own domain is up to them; the main recommendation of this BCP is on the inter-domain use.

> interdomain ASM" to "some Bidir-PIM deployments have scaled

Yes, we could do that.

> sentence is not overlooked.

We’ll review all use of recommended / RECOMMENDED.

>   or amend the recommendations of this document.

I think it’s implicitly true wither way :)

Thanks again!

Tim