Re: [MBONED] RtgDir review: draft-ietf-mboned-interdomain-peering-bcp-10.txt

["TARAPORE, PERCY S" <[e-mail]>]

Hi Tomonori,

Thank you for your careful read and detailed comments on our BCP. We have addressed your comments with new explanatory text and appropriate corrections. Please see inline below for specifics. The new version reflects these changes and has been uploaded.

Thanks again,

Best wishes,

Percy

-----Original Message-----
From: Tomonori Takeda [mailto:[e-mail]] 
Sent: Wednesday, August 23, 2017 12:53 AM
To: [e-mail]
Cc: '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>
Subject: RtgDir review: draft-ietf-mboned-interdomain-peering-bcp-10.txt

Hello, 



I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=4Z9x1ZAReZp_mJahI6h9bQ&m=KwP1hgxtGRIOF0_QEFN4-whcIOQCyyacO-Lk5F68qPo&s=8K_ctZZY9Aggtx1TtzofZcDz-by02pLJgPuGdWbWTgM&e=  



Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. 



 Document: draft-ietf-mboned-interdomain-peering-bcp-10.txt

 Reviewer: Tomonori Takeda

 Review Date: Aug. 23rd, 2017

 IETF LC End Date: Aug. 23rd, 2017 

 Intended Status: BCP



Summary:

This document is basically ready for publication, but has nits that should be considered prior to publication.



Comments:

This document describes deployment scenarios of multicast (specifically SSM) across inter-domain peering points. Also, this document describes supporting functionalities for those deployment scenarios.

I think the document is well-organized and easy to read, but there are a few points to be clarified.



Major Issues:

None



Minor Issues:

1) I think it is better to describe assumed business relationship between AD-1 and AD-2, perhaps in Section 2.

According to descriptions in Section 4, it seems that AD-1 has the ultimate responsibility to deliver multicast traffic to EU.

(For example, it says "AD-2 provides relevant performance information to AD-1; this enables AD-1 to create an end-to-end performance view on behalf of the multicast application source.")



I think another possible model is that AD-1 is providing a wholesale service to AD-2, where AD-1's responsibility is to delivery data up to AD-2, and AD-2 has the ultimate responsibility to delivery data to EUs afterwards.

(Note that I am not saying this model should be included in the document.)



So I think it is beneficial to describe assumed business relationship between AD-1 and AD-2 in this document.

PST: Paragraph added in Section 2 bottom of page 5 stating that AD-1 has prime responsibility.

2) In Sections 3.1 and 3.2, it says:



      "o Fewer devices in the path traversed by the multicast stream when

         compared to unicast transmissions."



I don't understand this point.

PST: Both sentences have been changed to indicate comparison with an AMT enabled peering point.

3) In Section 3.2, it says:



      "o Ability to support only partial IP multicast deployments in AD-

         1 and/or AD-2."



I don't understand this point. For example, are you assuming that GRE is terminated not on AS border routers?

PST: Clarifying sentence added in this bullet

Nits:

1) I think some of the references may not be appropriate. 

- In Section 1, "PIM-SM [RFC4609]" should be "PIM-SM [RFC7761]"?

- In Section 4.1, "MBGP [RFC4271]" should be "MBGP [RFC4760]"?

PST: References changed as pointed out

2) In Section 1, it says:



   "Thus, the primary purpose of this document is to describe a scenario

    where two AD's interconnect via a direct connection to each other."



I think "a direction connection" is a bit unclear. In deployment scenarios, you are mentioning that the peering point is multicast enabled or not.

Does it mean that the peering point may be a routed network? It would be good to clarify this.

PST: Sentence changed to state that the 2 AD's interconnect via a peering point.

3) In Section 3.2, is says:



   "Section 4.3 provides an overview of one method that

    finds the optimal Relay-Gateway combination via the use of an

    Anycast IP address for AMT Relays."



I think Section 4.3 should be Section 4.2?

PST: Section number corrected.



Thanks,

Tomonori Takeda