Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 2 Nov 2016 12:13:31 +0900

Hi Percy,

It seems that you forgot to apply the changes for IGMP's and MLD’s RFCs at page 2.

One additional comment.
You refer to traceroute to facilitate the debugging of multicast control state and peering status in Section 5. 
However, I may recommend you to refer to Mtrace2 (I’ve just informed to the ML) for such purpose as traceroute does not provide such multicast state information.

Regards,
--
Hitoshi Asaeda

> 2016/10/28 23:38, TARAPORE, PERCY S <[email-masked]> wrote:
> 
> Approve!!
> 
> Percy
> 
> -----Original Message-----
> From: MBONED [mailto:[email-masked]] On Behalf Of Leonard Giuliano
> Sent: Friday, October 28, 2016 10:11 AM
> To: MBONED WG <[email-masked]>
> Subject: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp
> 
> WG,
> 
> Lots of good comments and feedback from the previous WGLC with changes reflected in the latest rev.  We'll run one more (hopefully last) WGLC. 
> Please respond by Nov 13.
> 
> https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/
> 
> 
> Thanks,
> Chairs
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thu, 3 Nov 2016 15:31:17 +0000

Hi Hitoshi,

I apologize for neglecting to change the references on page 2. Attached please find a revised draft with the correct references on page 2 based on your feedback during the previous Last Call. I have also added your Mtrace2 reference in Section 5 (page 25) - this is in addition to the original Traceroute reference. All references have been added in the reference list as well.

Request to Mailing List - As part of this Last Call, please let me know if these changes for references are acceptable.

Question for Chairs Greg & Lenny - Since these changes only involve references (and assuming there are no more substantive comments), will we need yet another Last Call? I can simply describe these changes in 5 minutes during the Seoul meeting.

Thank you.

Percy

-----Original Message-----
From: Hitoshi Asaeda [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2016 11:14 PM
To: TARAPORE, PERCY S <[email-masked]>
Cc: MBONED WG <[email-masked]>
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

Hi Percy,

One additional comment.

Regards,
--
Hitoshi Asaeda

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 3 Nov 2016 09:18:04 -0700

Change that are not substantive shouldn't need another LC.  Let's get all 
the changes done first and then we can see if it needs another call.  This 
is what WGLC is for.

On Thu, 3 Nov 2016, TARAPORE, PERCY S wrote:

| Hi Hitoshi,
| 
| I apologize for neglecting to change the references on page 2. Attached please find a revised draft with the correct references on page 2 based on your feedback during the previous Last Call. I have also added your Mtrace2 reference in Section 5 (page 25) - this is in addition to the original Traceroute reference. All references have been added in the reference list as well.
| 
| Request to Mailing List - As part of this Last Call, please let me know if these changes for references are acceptable.
| 
| Question for Chairs Greg & Lenny - Since these changes only involve 
| references (and assuming there are no more substantive comments), will 
| we need yet another Last Call? I can simply describe these changes in 5 
| minutes during the Seoul meeting.
| 
| Thank you.
| 
| Percy
| 
| -----Original Message-----
| From: Hitoshi Asaeda [mailto:[email-masked]] 
| Sent: Tuesday, November 01, 2016 11:14 PM
| To: TARAPORE, PERCY S <[email-masked]>
| Cc: MBONED WG <[email-masked]>
| Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp
| 
| Hi Percy,
| 
| It seems that you forgot to apply the changes for IGMP's and MLD’s RFCs at page 2.
| 
| One additional comment.
| You refer to traceroute to facilitate the debugging of multicast control state and peering status in Section 5. 
| However, I may recommend you to refer to Mtrace2 (I’ve just informed to the ML) for such purpose as traceroute does not provide such multicast state information.
| 
| Regards,
| --
| Hitoshi Asaeda
| 
| 
| 
| 
| > 2016/10/28 23:38, TARAPORE, PERCY S <[email-masked]> wrote:
| > 
| > Approve!!
| > 
| > Percy
| > 
| > -----Original Message-----
| > From: MBONED [mailto:[email-masked]] On Behalf Of Leonard Giuliano
| > Sent: Friday, October 28, 2016 10:11 AM
| > To: MBONED WG <[email-masked]>
| > Subject: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp
| > 
| > WG,
| > 
| > Lots of good comments and feedback from the previous WGLC with changes reflected in the latest rev.  We'll run one more (hopefully last) WGLC. 
| > Please respond by Nov 13.
| > 
| > https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/
| > 
| > 
| > Thanks,
| > Chairs
| > 
| > _______________________________________________
| > MBONED mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/mboned
| > 
| > _______________________________________________
| > MBONED mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/mboned
| 
|

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Nov 2016 09:47:07 +0100 (CET)

On Fri, 28 Oct 2016, Leonard Giuliano wrote:

> WG,
>
> Lots of good comments and feedback from the previous WGLC with changes 
> reflected in the latest rev.  We'll run one more (hopefully last) WGLC. 

Hi,

I did a quick once-over of this document again and I have some thoughts...

In the introduction there this this:

"Hence, in the case of inter-domain peering, it is recommended to use only 
SSM protocols."

I would like to see text added for clarification regarding the scope of 
this document, for example:

"Thus, the setup of interdomain peering for ASM (Any-Source Multicast) is 
not in scope for this document."

To make it really clear, it might be good to even add text to the abstract 
that this document is only regarding SSM and nothing else. Right now the 
abstract reads:

"This document examines the use of multicast across inter-domain
    peering points. The objective is to describe the setup process for
    multicast-based delivery across administrative domains and document
    supporting functionality to enable this process."

I don't think it actually "examines" that much. It lists some deployment 
models and lists pro:s and con:s for each, but it doesn't say anything 
about other deployment models that are not listed, and why not to use 
them.

Also in 4.2.1:

"Exchange relevant Peering Point information such as Capacity and
         Utilization (Other??)"

This "(other??)", is that going to be just removed? There are also some 
nit:s in that some sentences preceded by "o" has a trailing "." but some 
don't. I guess this will be fixed by the RFC editor before publication? 
Also that in some cases points preceded by "o" have newline between them 
in some sections, whilst in others they do not.

This document also does not list at all the use-case of exchanging 
multicast over public IXPs with a shared vlan with many ISPs on it. 
Perhaps this should be clarified in the scope as well?

Perhaps the abstract could read:

"This document examines the use of SSM (Source Specific Multicast) across 
inter-domain peering points with some deployment scenarios. The objective 
is to describe the setup process for these deployment scenarios for 
multicast-based delivery across administrative domains and document 
supporting functionality to enable this process."

and then add somthing in the introduction along the lines of:

"o This document primarily describes a scenario where two ADs interconnect 
via a direct connection to each other. Security and operational aspects 
for exchanging traffic on a public IXP (Internet Exchange point) with a 
large shared broadcast domain between many operators, is not in scope for 
this document."

With changes like this the document would clearly state that it lists some 
(not all) possible scenarios for exchanging multicast traffic, and 
specifically that it's only about SSM.

Thoughts?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Fri, 4 Nov 2016 16:09:35 +0000

Hi Mikael,

Thanks for your feedback. I have made the following changes to the draft per your comments - please see attached:

1.     Abstract changed per your recommendation.

2.     Two changes in the Introduction:

a.     Sentence added per your recommendation in first full bullet paragraph on the top of Page 4 stating "the setup of inter-domain peering for ASM (Any-Source Multicast) is not in scope for this document."

b.    New paragraph added near the bottom of Page 4 per your recommendation stating "Thus, the primary purpose of this document is to describe a scenario where two ADs interconnect via a direct connection to each other. Security and operational aspects for exchanging traffic on a public Internet Exchange Point (IXP) with a large shared broadcast domain between many operators, is not in scope for this document."

3.     Fixed some of the nits that you noticed:

a.     Removed "(Other)" from the "Utilization (Other)" text in Section 4.2.1

b.    Added periods and commas where needed in the Bullet Points

Please take a look at this draft revision and let me know if there are other comments.

Thank you

Percy

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Friday, November 04, 2016 4:47 AM
To: MBONED WG <[email-masked]>
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

> https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering

> -bcp/

Hi,

"Hence, in the case of inter-domain peering, it is recommended to use only SSM protocols."

I would like to see text added for clarification regarding the scope of this document, for example:

"Thus, the setup of interdomain peering for ASM (Any-Source Multicast) is not in scope for this document."

To make it really clear, it might be good to even add text to the abstract that this document is only regarding SSM and nothing else. Right now the abstract reads:

I don't think it actually "examines" that much. It lists some deployment models and lists pro:s and con:s for each, but it doesn't say anything about other deployment models that are not listed, and why not to use them.

Also in 4.2.1:

         Utilization (Other??)"

This "(other??)", is that going to be just removed? There are also some nit:s in that some sentences preceded by "o" has a trailing "." but some don't. I guess this will be fixed by the RFC editor before publication?

Also that in some cases points preceded by "o" have newline between them in some sections, whilst in others they do not.

This document also does not list at all the use-case of exchanging multicast over public IXPs with a shared vlan with many ISPs on it.

"This document examines the use of SSM (Source Specific Multicast) across inter-domain peering points with some deployment scenarios. The objective is to describe the setup process for these deployment scenarios for multicast-based delivery across administrative domains and document supporting functionality to enable this process."

"o This document primarily describes a scenario where two ADs interconnect via a direct connection to each other. Security and operational aspects for exchanging traffic on a public IXP (Internet Exchange point) with a large shared broadcast domain between many operators, is not in scope for this document."

With changes like this the document would clearly state that it lists some (not all) possible scenarios for exchanging multicast traffic, and specifically that it's only about SSM.

Thoughts?

--

Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>

MBONED mailing list

[email-masked]<mailto:[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 7 Nov 2016 07:45:52 +0100 (CET)

Thanks, looks good to me!