[Tsv-art] TSV-ART review of draft-ietf-mboned-interdomain-peering-bcp-11

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 12 October 2017 06:35 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAB31320B5; Wed, 11 Oct 2017 23:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Level:
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ2Ezwva0owX; Wed, 11 Oct 2017 23:35:18 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E808126CB6; Wed, 11 Oct 2017 23:35:17 -0700 (PDT)
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5C7E527850A; Thu, 12 Oct 2017 15:35:15 +0900 (JST)
Received: by mail-wm0-f48.google.com with SMTP id k4so10265739wmc.1; Wed, 11 Oct 2017 23:35:15 -0700 (PDT)
X-Gm-Message-State: AMCzsaXP8AZJMJdxSgDvxRld9WXpz0DqaT0ThyDe2DI4/s4CcdKmgg1h p75oHILajCWrBO45QB49PWi4AJZ/lgoLqoNSTg8=
X-Google-Smtp-Source: AOwi7QAw99y3D2vT1/TruOOlCQKQOcE1ORY+5NoxASCwaMDcCl/BdLlr/pyP79frm4Rdjhb+RxfND2AmcKd7TL4mld8=
X-Received: by 10.223.152.86 with SMTP id v80mr963155wrb.268.1507790113341; Wed, 11 Oct 2017 23:35:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.171.232 with HTTP; Wed, 11 Oct 2017 23:35:12 -0700 (PDT)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Wed, 11 Oct 2017 23:35:12 -0700
X-Gmail-Original-Message-ID: <CAO249yeo-E2WQtBT7_DUF-B3ju26ypphO1NHDsb4LrYimZZ6Eg@mail.gmail.com>
Message-ID: <CAO249yeo-E2WQtBT7_DUF-B3ju26ypphO1NHDsb4LrYimZZ6Eg@mail.gmail.com>
To: tsv-art@ietf.org
Cc: mboned@ietf.org, draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary="f403045f4f281a0766055b53be2e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/hQ9va3nepVmgWn_w3NOIkwHMm5k>
Subject: [Tsv-art] TSV-ART review of draft-ietf-mboned-interdomain-peering-bcp-11
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Oct 2017 06:35:21 -0000

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