Subject: Re: [MBONED] WGLC for draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm

From: Leonard Giuliano <[email-masked]>
Date: Fri, 2 Aug 2019 13:11:08 -0700

Not aware of any IPR related to draft-ietf-mboned-deprecate-interdomain-asm

On Fri, 19 Jul 2019, Leonard Giuliano wrote:

| 
| We would like to officially begin working group last call for BOTH
| draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm.
| Please post whether you support/oppose the advancement of either/both of the
| drafts as well as any comments you may have to the list by Aug 16.  Also,
| please note if you are aware of any IPR involved in this drafts (we must hear
| from the authors about IPR).
| 
| Most recent version of the draft can be found here:
| https://datatracker.ietf.org/doc/draft-ietf-mboned-dc-deploy/
| https://datatracker.ietf.org/doc/draft-ietf-mboned-deprecate-interdomain-asm/
|

---

From: Xiejingrong <[email-masked]>
Date: Sat, 3 Aug 2019 06:54:15 +0000

Support.

Thanks
Jingrong

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Leonard Giuliano
Sent: Saturday, July 20, 2019 4:34 AM
To: MBONED WG <[email-masked]>
Subject: [MBONED] WGLC for draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm

We would like to officially begin working group last call for BOTH draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm.  Please post whether you support/oppose the advancement of either/both of the drafts as well as any comments you may have to the list by Aug 16.  Also, please note if you are aware of any IPR involved in this drafts (we must hear from the authors about IPR).

Most recent version of the draft can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-dc-deploy/
https://datatracker.ietf.org/doc/draft-ietf-mboned-deprecate-interdomain-asm/

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 5 Aug 2019 07:44:06 -0700

Jingrong- are you supporting draft-ietf-mboned-dc-deploy or 
draft-ietf-mboned-deprecate-interdomain-asm or both here?

Thanks,
Lenny

On Sat, 3 Aug 2019, Xiejingrong wrote:

| Support.
| 
| Thanks
| Jingrong
| 
| -----Original Message-----
| From: MBONED [mailto:[email-masked]] On Behalf Of Leonard Giuliano
| Sent: Saturday, July 20, 2019 4:34 AM
| To: MBONED WG <[email-masked]>
| Subject: [MBONED] WGLC for draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm
| 
| 
| We would like to officially begin working group last call for BOTH draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm.  Please post whether you support/oppose the advancement of either/both of the drafts as well as any comments you may have to the list by Aug 16.  Also, please note if you are aware of any IPR involved in this drafts (we must hear from the authors about IPR).
| 
| Most recent version of the draft can be found here:
| https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddc-2Ddeploy_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=F2l5seFhiCeRfyJe2ZvfwcXI8nGcnteHSXUPWsAqRTc&s=TDIVht56Apuajt5A0WDQ8s7H-Hw8rtNSNIS3_AyX6S8&e= 
| https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddeprecate-2Dinterdomain-2Dasm_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=F2l5seFhiCeRfyJe2ZvfwcXI8nGcnteHSXUPWsAqRTc&s=WvnfzK9LQkUxwogIadAFy2uixfbtffv3Nu86y8eGJ9I&e= 
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=F2l5seFhiCeRfyJe2ZvfwcXI8nGcnteHSXUPWsAqRTc&s=v1X8d8ZVcAIXSJZrsN37IlWfnV_n7-PBMHdu4z9wzGE&e= 
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=F2l5seFhiCeRfyJe2ZvfwcXI8nGcnteHSXUPWsAqRTc&s=v1X8d8ZVcAIXSJZrsN37IlWfnV_n7-PBMHdu4z9wzGE&e= 
|

---

From: Xiejingrong <[email-masked]>
Date: Tue, 6 Aug 2019 01:07:27 +0000

Hi Leonard, 
I support publication of both documents.
I think they are both useful as guidance for multicast deployment.

Thanks
Jingrong

-----Original Message-----
From: Leonard Giuliano [mailto:[email-masked]] 
Sent: Monday, August 05, 2019 10:44 PM
To: Xiejingrong <[email-masked]>
Cc: Leonard Giuliano <lenny=[email-masked]>; MBONED WG <[email-masked]>
Subject: Re: [MBONED] WGLC for draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm

Jingrong- are you supporting draft-ietf-mboned-dc-deploy or draft-ietf-mboned-deprecate-interdomain-asm or both here?

Thanks,
Lenny

| Support.
| 
| Thanks
| Jingrong
| 
| -----Original Message-----
| From: MBONED [mailto:[email-masked]] On Behalf Of Leonard 
| Giuliano
| Sent: Saturday, July 20, 2019 4:34 AM
| To: MBONED WG <[email-masked]>
| Subject: [MBONED] WGLC for draft-ietf-mboned-dc-deploy and 
| draft-ietf-mboned-deprecate-interdomain-asm
| 
| 
| We would like to officially begin working group last call for BOTH draft-ietf-mboned-dc-deploy and draft-ietf-mboned-deprecate-interdomain-asm.  Please post whether you support/oppose the advancement of either/both of the drafts as well as any comments you may have to the list by Aug 16.  Also, please note if you are aware of any IPR involved in this drafts (we must hear from the authors about IPR).
| 
| Most recent version of the draft can be found here:
| https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
| org_doc_draft-2Dietf-2Dmboned-2Ddc-2Ddeploy_&d=DwICAg&c=HAkYuh63rsuhr6
| Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWT
| aavDg&m=F2l5seFhiCeRfyJe2ZvfwcXI8nGcnteHSXUPWsAqRTc&s=TDIVht56Apuajt5A
| 0WDQ8s7H-Hw8rtNSNIS3_AyX6S8&e= 
| https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
| org_doc_draft-2Dietf-2Dmboned-2Ddeprecate-2Dinterdomain-2Dasm_&d=DwICA
| g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23z
| dah2FoG9Do-zEmGgWTaavDg&m=F2l5seFhiCeRfyJe2ZvfwcXI8nGcnteHSXUPWsAqRTc&
| s=WvnfzK9LQkUxwogIadAFy2uixfbtffv3Nu86y8eGJ9I&e=
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
| man_listinfo_mboned&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
| zoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=F2l5seFhiCeRfyJe2
| ZvfwcXI8nGcnteHSXUPWsAqRTc&s=v1X8d8ZVcAIXSJZrsN37IlWfnV_n7-PBMHdu4z9wz
| GE&e=
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
| man_listinfo_mboned&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
| zoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=F2l5seFhiCeRfyJe2
| ZvfwcXI8nGcnteHSXUPWsAqRTc&s=v1X8d8ZVcAIXSJZrsN37IlWfnV_n7-PBMHdu4z9wz
| GE&e=
|

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 7 Aug 2019 06:58:51 +0000

I read deprecate-interdomain-asm.  I think technically it looks
to me to be in pretty good shape with one minor exception, but
there are a bunch of minor language and editorial issues.

I don't object to moving the doc forward, but I think it would be
better to tighten up the language first.  I took some quick notes
on the issues and nits that jumped out at me as grammar errors or
reasonably egregious problems that probably should get fixed.

Here's the notes:

Technical:

3.2.3 Intrinsic source-control security
   SSM is implicitly secure against unauthorized/undesired sources.
- the only protection is against off-path attackers, not against all
  unauthorized sources.

Editorial:

Intro:
   the recommended interdomain mode of multicast.  This recommendation
   thus also implicitly states that all hosts and routers that are
   expected to support interdomain multicast applications fully support
- it's explicitly stated here, so "implicitly states" seems wrong.
  Maybe "implies"?  Or maybe make the recommendation explicit?

2.2.1 PIM Sparse Mode (PIM-SM)
last paragraph:
   To this day, there is no IETF Proposed Standard level interdomain
   solution for IPv4 ASM multicast because MSDP was the "best" component
- quoted '"best"' in last paragraph seems almost sarcastic--maybe
  "most widely deployed" would be better?
- "where" -> "were" in:
  Other protocol options where investigated at the same time

2.2.3 Bidir-RP
nit: "may want to sent" -> "may want to send"

2.3 SSM Routing Protocols
   SSM is detailed in [RFC4607].  It mandates the use of PIM-SSM for
   routing of SSM.  PIM-SSM as it merely a subset of PIM-SM ([RFC7761]).
- incomplete sentence: "PIM-SSM as it merely a subset of PIM-SM ([RFC7761])."

3.1 Observations on ASM and SSM deployments:
   troubleshoot (complex flooding RPF rules, state attack protection,
   filtering of undesired sources, ...).
- should the ellipsis be filled in or exchanged for "and a number of
  other issues"?  This whole parenthetical seems maybe better as a
  fleshed-out explanatory sentence.

3.2.1 Reduced network operations complexity
last paragraph
   PIM.  In Bidir-PIM, traffic is forwarded to an RPs instead o building
   state as in PIM-SM.  Even in the absence of receivers.  Bidir-PIM

- "to an RP" or "to RPs", I think
- "o" -> "of"
- "Even in the absence of receivers." is an incomplete sentence.

3.2.2 No network wide IP multicast group-address management
   a source like a unicast transport protocol port number: No two
   independent applications on the host must use same IP multicast group
- "No" capitalized after colon is wrong I think?
- weird phrasing in "no two applications must use the same"--something
  maybe more like "the only coordination required is to ensure that
  applications running on the same host don't send to the same group
  address"

4.1 Deprecating use of ASM for interdomain multicast
   operated by two or more separate administrative entities (domains,
   organisations).
- this is a weird parenthetical with unclear meaning.  I think these
  are examples of administrative entities?  It might be best to cut
  the parenthetical or explain with exposition here?

   are under different operator control.  A typical example of this case
   is an SP providing IPTV (single operator domain for PIM) to
- "SP" not defined

4.4 Developing application guidance: SSM, ASM, service discovery

   Deploying any form of IP
   multicast solely in support of such service discovery is in general
   not recommended (complexity, control, ...) but instead dedicated
   service discovery via DNS [RFC6763]
- This is not a complete sentence, and doesn't end with a period
- "(complexity, control, ...)" is a weird list and ellipsis, probably
  better to expand and explain.

   Best practices should be developed to explain when to use SSM in
   applications, when ASM without (S,G) state in the network is better,
   or when dedicated service-discovery mechanisms should be used.
- This seems like something that would be in-scope for this document,
  but is just left out?  (Or maybe this whole section should be cut,
  and a note somewhere else added saying this topic is out of scope?
  Or just the problem of ASM for service discovery should be explained
  and advised against?)

4.8 Not precluding Intradomain ASM

- unclosed paren at end of 2nd paragraph "(see Section 4.4."

- "does also not preclude" -> "also does not preclude"

4.9 Evolving PIM deployments for SSM

First paragraph has several problems:
- "with no or little changes" is weird.
- "whener" -> whenever
- "configuring/enabled" -> "enabled"
- "This allows to easily migrate" - no subject in this sentence?
- "transitioning" -> "transition"
- "Unchanged" capitalized after colon

5. Future interdomain ASM work

- "this document does not believe" -> something like "the mboned
  working group does not believe"? (documents don't have beliefs)

HTH.

Best,
Jake

On 2019-07-19, 13:34, "Leonard Giuliano" <lenny=[email-masked]> wrote:

    We would like to officially begin working group last call for BOTH 
    draft-ietf-mboned-dc-deploy and 
    draft-ietf-mboned-deprecate-interdomain-asm.  Please post whether you 
    support/oppose the advancement of either/both of the drafts as well as any 
    comments you may have to the list by Aug 16.  Also, please note if you are 
    aware of any IPR involved in this drafts (we must hear from the authors 
    about IPR).

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 12 Aug 2019 11:27:54 -0700

Jake- thanks for the thorough review.  We are discussing the changes and 
will get back to you shortly.

On Wed, 7 Aug 2019, Holland, Jake wrote:

| I read deprecate-interdomain-asm.  I think technically it looks
| to me to be in pretty good shape with one minor exception, but
| there are a bunch of minor language and editorial issues.
| 
| I don't object to moving the doc forward, but I think it would be
| better to tighten up the language first.  I took some quick notes
| on the issues and nits that jumped out at me as grammar errors or
| reasonably egregious problems that probably should get fixed.
| 
| Here's the notes:
| 
| Technical:
| 
| 3.2.3 Intrinsic source-control security
|    SSM is implicitly secure against unauthorized/undesired sources.
| - the only protection is against off-path attackers, not against all
|   unauthorized sources.
| 
| 
| Editorial:
| 
| Intro:
|    the recommended interdomain mode of multicast.  This recommendation
|    thus also implicitly states that all hosts and routers that are
|    expected to support interdomain multicast applications fully support
| - it's explicitly stated here, so "implicitly states" seems wrong.
|   Maybe "implies"?  Or maybe make the recommendation explicit?
| 
| 2.2.1 PIM Sparse Mode (PIM-SM)
| last paragraph:
|    To this day, there is no IETF Proposed Standard level interdomain
|    solution for IPv4 ASM multicast because MSDP was the "best" component
| - quoted '"best"' in last paragraph seems almost sarcastic--maybe
|   "most widely deployed" would be better?
| - "where" -> "were" in:
|   Other protocol options where investigated at the same time
| 
| 2.2.3 Bidir-RP
| nit: "may want to sent" -> "may want to send"
| 
| 2.3 SSM Routing Protocols
|    SSM is detailed in [RFC4607].  It mandates the use of PIM-SSM for
|    routing of SSM.  PIM-SSM as it merely a subset of PIM-SM ([RFC7761]).
| - incomplete sentence: "PIM-SSM as it merely a subset of PIM-SM ([RFC7761])."
| 
| 3.1 Observations on ASM and SSM deployments:
|    troubleshoot (complex flooding RPF rules, state attack protection,
|    filtering of undesired sources, ...).
| - should the ellipsis be filled in or exchanged for "and a number of
|   other issues"?  This whole parenthetical seems maybe better as a
|   fleshed-out explanatory sentence.
| 
| 3.2.1 Reduced network operations complexity
| last paragraph
|    PIM.  In Bidir-PIM, traffic is forwarded to an RPs instead o building
|    state as in PIM-SM.  Even in the absence of receivers.  Bidir-PIM
| 
| - "to an RP" or "to RPs", I think
| - "o" -> "of"
| - "Even in the absence of receivers." is an incomplete sentence.
| 
| 3.2.2 No network wide IP multicast group-address management
|    a source like a unicast transport protocol port number: No two
|    independent applications on the host must use same IP multicast group
| - "No" capitalized after colon is wrong I think?
| - weird phrasing in "no two applications must use the same"--something
|   maybe more like "the only coordination required is to ensure that
|   applications running on the same host don't send to the same group
|   address"
|  
| 
| 4.1 Deprecating use of ASM for interdomain multicast
|    operated by two or more separate administrative entities (domains,
|    organisations).
| - this is a weird parenthetical with unclear meaning.  I think these
|   are examples of administrative entities?  It might be best to cut
|   the parenthetical or explain with exposition here?
| 
|    are under different operator control.  A typical example of this case
|    is an SP providing IPTV (single operator domain for PIM) to
| - "SP" not defined
| 
| 4.4 Developing application guidance: SSM, ASM, service discovery
| 
| 
|    Deploying any form of IP
|    multicast solely in support of such service discovery is in general
|    not recommended (complexity, control, ...) but instead dedicated
|    service discovery via DNS [RFC6763]
| - This is not a complete sentence, and doesn't end with a period
| - "(complexity, control, ...)" is a weird list and ellipsis, probably
|   better to expand and explain.
| 
|    Best practices should be developed to explain when to use SSM in
|    applications, when ASM without (S,G) state in the network is better,
|    or when dedicated service-discovery mechanisms should be used.
| - This seems like something that would be in-scope for this document,
|   but is just left out?  (Or maybe this whole section should be cut,
|   and a note somewhere else added saying this topic is out of scope?
|   Or just the problem of ASM for service discovery should be explained
|   and advised against?)
| 
| 4.8 Not precluding Intradomain ASM
| 
| - unclosed paren at end of 2nd paragraph "(see Section 4.4."
| 
| - "does also not preclude" -> "also does not preclude"
| 
| 4.9 Evolving PIM deployments for SSM
| 
| First paragraph has several problems:
| - "with no or little changes" is weird.
| - "whener" -> whenever
| - "configuring/enabled" -> "enabled"
| - "This allows to easily migrate" - no subject in this sentence?
| - "transitioning" -> "transition"
| - "Unchanged" capitalized after colon
| 
| 5. Future interdomain ASM work
| 
| - "this document does not believe" -> something like "the mboned
|   working group does not believe"? (documents don't have beliefs)
| 
| 
| HTH.
| 
| Best,
| Jake
| 
| On 2019-07-19, 13:34, "Leonard Giuliano" <lenny=[email-masked]> wrote:
| 
|     
|     We would like to officially begin working group last call for BOTH 
|     draft-ietf-mboned-dc-deploy and 
|     draft-ietf-mboned-deprecate-interdomain-asm.  Please post whether you 
|     support/oppose the advancement of either/both of the drafts as well as any 
|     comments you may have to the list by Aug 16.  Also, please note if you are 
|     aware of any IPR involved in this drafts (we must hear from the authors 
|     about IPR).
|     
|     Most recent version of the draft can be found here:
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddc-2Ddeploy_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=iGOi3d2ESqqQiSMChau3ZzCOxK5Pm9cfhZ7bYzvjsYg&s=DQ3wIt7yMATSrjA9uFvOzDWQa47SENcnXLYb63I1mAk&e= 
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddeprecate-2Dinterdomain-2Dasm_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=iGOi3d2ESqqQiSMChau3ZzCOxK5Pm9cfhZ7bYzvjsYg&s=cZZVruG-gduaapy7KRw9QcFvVyuduuMWq9_aGu9lU6M&e= 
|     
|     _______________________________________________
|     MBONED mailing list
|     [email-masked]
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=iGOi3d2ESqqQiSMChau3ZzCOxK5Pm9cfhZ7bYzvjsYg&s=26PkbDTiryLBxKPCWaxQKc8MQ-1bkBxn09K6BbGtJuE&e= 
|     
| 
|

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 13 Aug 2019 12:54:20 -0700

<chair hat off, speaking as individual contributor>

I support publication of draft-ietf-mboned-dc-deploy as this document 
describes a number of pertinent issues for mcast in a DC environment.

Some mostly editorial comments below:

Abstract: "judiciously" misspelled

Sect 1. Intro, 2nd para: I am confused by the tense used in this para- is 
it talking about the current situation, or in the future or even the past?  
If the future, how can an assumption of the future be known to be 
incorrect in the present?  Don't we need to arrive at that future point to 
determine how correct this assumption is?  Anyway, suggest sticking to the 
current state of affairs.

Sect 2.1, 2nd para: "... there is a consensus..."
	-would "expectation" be more appropriate than "consensus"

Sect 2.2, 1st para: "... overlays mainly simply ..."
	-probably just "simply" would be simpler

Sect 3: "...arguably the intuitive initial course of action for a data 
center operator..."
	-perhaps better to say: "it makes sense for a data center 
operator..."

Sect 3.3, 1st para, last sentence: "Thus, PIM must be running..."
	-"Thus, a multicast routing protocol (typically PIM) must be 
running..."

Sect 4.1: I thought this section was very informative and well-written

Sect 4.4, 3rd para:  "The
   deployment envisioned with overlay networks is that the the
   encapsulation endpoints would be the BFIR."
	-suggest something like the following: "The BFIRs are the 
encapsulation endpoints in the deployment envisioned with overlay 
networks."

|

---

From: Olufemi Komolafe <[email-masked]>
Date: Fri, 23 Aug 2019 00:15:48 +0100

Thanks for the good feedback Lenny.  We will make the suggested changes.

Regards,
Femi
> On 13 Aug 2019, at 20:54, Leonard Giuliano <lenny=[email-masked]> wrote:
> 
>