Telechat Review of draft-ietf-mboned-interdomain-peering-bcp-11
review-ietf-mboned-interdomain-peering-bcp-11-tsvart-telechat-nishida-2017-10-12-00

Request Review of draft-ietf-mboned-interdomain-peering-bcp
Requested rev. no specific revision (document currently at 14)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2017-10-12
Requested 2017-10-09
Requested by Mirja K├╝hlewind
Authors Percy Tarapore, Robert Sayko, Greg Shepherd, Toerless Eckert, Ramki Krishnan
Draft last updated 2017-10-12
Completed reviews Rtgdir Last Call review of -10 by Tomonori Takeda (diff)
Secdir Last Call review of -10 by Barry Leiba (diff)
Genart Last Call review of -10 by Christer Holmberg (diff)
Opsdir Last Call review of -10 by Nevil Brownlee (diff)
Genart Telechat review of -11 by Christer Holmberg (diff)
Tsvart Telechat review of -11 by Yoshifumi Nishida (diff)
Comments
AD request: Could be could to have another look at this regarding rate-adaption. I don't think there are any issues. However, if you can find someone to review this week, why not...
Assignment Reviewer Yoshifumi Nishida
State Completed
Review review-ietf-mboned-interdomain-peering-bcp-11-tsvart-telechat-nishida-2017-10-12
Reviewed rev. 11 (document currently at 14)
Review result Almost Ready
Review completed: 2017-10-12

Review
review-ietf-mboned-interdomain-peering-bcp-11-tsvart-telechat-nishida-2017-10-12

Document: draft-ietf-mboned-interdomain-peering-bcp-11
Reviewer: Yoshifumi Nishida

I've reviewed this document as part of TSV-ART's ongoing effort to review
key IETF documents. These comments were written primarily for the transport
area directors, but are copied to the document's authors for their
information and to allow them to address any issues raised.When done at the
time of IETF Last Call, the authors should consider this review together
with any other last-call comments they receive. Please always CC tsv-art
@ietf.org if you reply to or forward this review.

Summary: This document is almost ready for publication, but several points
need to be clarified.

1: In Section 3.1b,
    " If the peering point between AD-1 and AD-2 is a controlled

   network environment, then bandwidth can be allocated
   accordingly by the two domains to permit the transit of non-
   rate adaptive multicast traffic. If this is not the case, then
   it is recommended that the multicast traffic should support
   rate-adaption."


    I think we need to use rate-adaption approach in non-controlled network
environments.
    However, it seems to me that texts look a bit ambiguous on this point
as it just says it is recommended.
    Are there any other approach that doesn't require congestion control in
this case?

2: The configuration described in Section 3.4 doesn't look very scalable to
me as the traffic usage on I2 will be increased as the number of AMTs
increases.
    This looks a solid disadvantage of this configuration.
    Also, we don't need any guidelines on this?


3: In Section 4.1,
     "When determining the appropriate bandwidth allocation, parties should
consider use

       of a multicast protocol suitable for live video streaming that
       is consistent with Congestion Control Principles [BCP41
<https://tools.ietf.org/html/draft-ietf-mboned-interdomain-peering-bcp-11#ref-BCP41>]."


    The text looks a bit ambiguous to me. Only live video streaming
applications need to follow congestion control principle?
    "should consider use of .." sounds to me there will be some cases where
they don't need it. But, I'm wondering what would be the cases.
    Also, I believe we also need to consider the bandwidth allocation for
tunnels as well as multicast traffics, however, this is not very clear in
the texts.

Thanks,
--
Yoshi