Last Call Review of draft-ietf-mboned-interdomain-peering-bcp-10
review-ietf-mboned-interdomain-peering-bcp-10-rtgdir-lc-takeda-2017-08-23-00

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