[RTG-DIR] RtgDir review: draft-ietf-mboned-interdomain-peering-bcp-10.txt

[Tomonori Takeda <[e-mail]>]

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 ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 

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.

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.

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?

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]"?

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.

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?


Thanks,
Tomonori Takeda