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

From: "James A. (Jim) Stevens" <[email-masked]>
Date: Fri, 27 Dec 2019 23:38:33 -0600

On 22 Dec 2019, Tim Chown responded to Dale Worley 21 Dec 2019 review

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

Some background to Tim Chown's comment about "pushback in earlier
discussions"
Section 4.4 is on Developing application guidance: SSM, ASM, service
discovery
Section 4.5 is on Preferring SSM applications intradomain

We have intradomain applications with up to hundreds of nodes doing many to
many multicast IP packet exchanges where the nodes can dynamically come and
go.  (Although most networks only contain 20 to 100 nodes, I believe the
largest such network had >250 nodes doing many to many multicast.

SSM is not feasible (and neither is ASM with PIM-SM due to the high
overhead and dynamics as nodes come and go).  So our applications use ASM
with BIDIR-PIM.

We want to ensure that operating system and router developers continue to
support ASM and BIDIR-PIM over the long term for our intradomain
applications. I.e., we do NOT want to deprecate intradomain use of ASM.

Thus, we pushed back against the recommendation in 4.4 to develop new
applications using SSM and in 4.5 to prefer SSM for future intradomain
applications.  In response, the
draft-ietf-mboned-deprecate-interdomain-asm document
was updated to put in the phrase "if feasible" in sections 4.4. and 4.5 so
that SSM is not recommended if not feasible.

Note that we do not object to deprecating interdomain use of ASM.

Jim Stevens

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 29 Dec 2019 20:23:06 +0000

From: MBONED <[email-masked]> On Behalf Of James A. (Jim) Stevens

> Some background to Tim Chown's comment about "pushback in earlier discussions"
> Section 4.4 is on Developing application guidance: SSM, ASM, service discovery
> We have intradomain applications with up to hundreds of nodes doing many to many multicast IP packet exchanges where the nodes can dynamically come and go.  (Although most networks only contain 20 to 100 nodes, I believe the largest such network had >250 nodes doing many to many multicast.
>
> SSM is not feasible (and neither is ASM with PIM-SM due to the high overhead and dynamics as nodes come and go).  So our applications use ASM with BIDIR-PIM.  
>
> We want to ensure that operating system and router developers continue to support ASM and BIDIR-PIM over the long term for our intradomain applications. I.e., we do NOT want to deprecate intradomain use of ASM.
>
> Thus, we pushed back against the recommendation in 4.4 to develop new applications using SSM and in 4.5 to prefer SSM for future intradomain applications.  In response, the draft-ietf-mboned-deprecate-interdomain-asm document was updated to put in the phrase "if feasible" in sections 4.4. and 4.5 so that SSM is not recommended if not feasible.
>

I would like to emphatically post a +1 here. On all points, except perhaps the use of PIM (for security reasons primarily).

As long as we're talking interdomain, no objections. But intradomain, the fact that the source of a given multicast might vary, without mandating that each destination join all possible source-specific multicasts individually, is a "feature" that we exploit.

The model is much the same as telephone conference calls. You send out the conference call number to all possible participants, but then you want to avoid the extra complication of requiring each one dialing in having to dial the number of each participant. That would be quite laborious and unnecessary.

Bert