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

[Toerless Eckert <[e-mail]>]

Thanks for your review, Tomonori,

Question/replies inline

On Wed, Aug 23, 2017 at 04:52:36AM +0000, Tomonori Takeda wrote:
> 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 
> 
[...]

> 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.)

How about "AD-2 should provide relevant performance information to AD-1..." ?
                ^^^^^^

Sounds to me as in your "wholesale" case this is not necessary , so "should" should capture that ?!

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

The document tries to describe only technical aspects. "Business relationship" sounds
as if it might include aspects such as financials or legal obligations. Should we
explicitly say that the document does only discuss technical aspects, but
not business aspects such as financial or legal ? (i thought that was the
voldemort default assumption of IETF documents ;-)

> 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.

Hopefully one of the co-authors can chime in with an example. Not sure if its
meant to count the total number of hops across all viewer streams
or something else.

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

Right. Those two BR in 3.2 do not need to be the two "unicast" domain
border routers, instead they can be anywhere in AD-1 and AD-2.

Maybe add this picture:


     -------------------               -------------------
     /       AD-1        \             /        AD-2       \
    / (Multicast Enabled) \           / (Multicast Enabled) \
   /                       \         /                       \
   | +----+          +---+ |   I1    | +---+                 |
   | |    |   +--+   |uBR|-|---------|-|uBR|   +--+          |   +----+
   | | AS |-->|BR|   +---+-|         | +---+   |BR| -------->|-->| EU |
   | |    |   +--+ <.......|.........|........>+--+          |I2 +----+
   \ +----+                /  GRE    \                       /
    \                     /  Tunnel   \                     /
     \                   /             \                   /
      -------------------               -------------------


   AD = Administrative Domain (Independent Autonomous System)
   AS = Application (e.g., Content) Multicast Source
   uBR = unicast Border Router - not multicast enabled
   BR = Border Router - for multicast
   I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP)
   I2 = AD-2 and EU Multicast Connection

      Figure 2 - Content Distribution via GRE peering

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

Thanks!

> 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.

Did the proposed picture 2 help to answer this question ?
If not, then i am maybe not clear what you mean with routed network.

> 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

Cheers
    Toerless

> Thanks,
> Tomonori Takeda
> 
> 

-- 
---
[e-mail]