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

Tomonori Takeda <tomonori.takeda@ntt.com> Tue, 03 October 2017 05:52 UTC

Return-Path: <tomonori.takeda@ntt.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78CD13306F; Mon, 2 Oct 2017 22:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 XfNd_dHwfjGY; Mon, 2 Oct 2017 22:52:40 -0700 (PDT)
Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id DDB76124207; Mon, 2 Oct 2017 22:52:39 -0700 (PDT)
Received: from c0043i0.coe.ntt.com (c0043i0.nc.agilit-hosting.com [10.18.161.12]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id D44301C583E0; Tue, 3 Oct 2017 14:52:38 +0900 (JST)
Received: from C0035I0.coe.ntt.com (10.18.160.39) by c0043i0.coe.ntt.com (10.18.161.12) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 3 Oct 2017 14:52:38 +0900
Received: from C0561I0.coe.ntt.com ([169.254.1.200]) by C0035I0.coe.ntt.com ([10.18.160.39]) with mapi id 14.03.0361.001; Tue, 3 Oct 2017 14:52:38 +0900
From: Tomonori Takeda <tomonori.takeda@ntt.com>
To: "'TARAPORE, PERCY S'" <pt5947@att.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "'rtg-dir@ietf.org'" <rtg-dir@ietf.org>, "'draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org'" <draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org>, "'mboned@ietf.org'" <mboned@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-mboned-interdomain-peering-bcp-10.txt
Thread-Index: AdMbtumwnLtrsTGiQsK3S0y1oO1rugdbLPywALoEVuA=
Date: Tue, 03 Oct 2017 05:52:37 +0000
Message-ID: <EB0F2EAC05E9C64D80571F2042700A2A868D24D4@C0561I0.coe.ntt.com>
References: <EB0F2EAC05E9C64D80571F2042700A2A8684496C@C0561I0.coe.ntt.com> <ACC789373DA69C4285B9678D0CEBF86F13036DB1@MISOUT7MSGUSRDG.ITServices.sbc.com>
In-Reply-To: <ACC789373DA69C4285B9678D0CEBF86F13036DB1@MISOUT7MSGUSRDG.ITServices.sbc.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ccmail-original-to: pt5947@att.com, rtg-ads@ietf.org
x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org, mboned@ietf.org
x-originating-ip: [10.25.140.153]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/2WbY4VpKNcPgEPW3KhcuWPRmVCg>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-interdomain-peering-bcp-10.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Oct 2017 05:52:44 -0000

Hi Percy,

Thanks for catching these. Looks good to me.

Tomonori

-----Original Message-----
From: TARAPORE, PERCY S [mailto:pt5947@att.com] 
Sent: Friday, September 29, 2017 10:13 PM
To: Tomonori Takeda(武田知典); rtg-ads@ietf.org
Cc: 'rtg-dir@ietf.org'; 'draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org'; 'mboned@ietf.org'
Subject: RE: RtgDir review: draft-ietf-mboned-interdomain-peering-bcp-10.txt

Hi Tomonori,

Thank you for your careful read and detailed comments on our BCP. We have addressed your comments with new explanatory text and appropriate corrections. Please see inline below for specifics. The new version reflects these changes and has been uploaded.

Thanks again,

Best wishes,

Percy

-----Original Message-----
From: Tomonori Takeda [mailto:tomonori.takeda@ntt.com] 
Sent: Wednesday, August 23, 2017 12:53 AM
To: rtg-ads@ietf.org
Cc: 'rtg-dir@ietf.org' <rtg-dir@ietf.org>; 'draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org' <draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org>; 'mboned@ietf.org' <mboned@ietf.org>
Subject: RtgDir review: draft-ietf-mboned-interdomain-peering-bcp-10.txt

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 ​https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=4Z9x1ZAReZp_mJahI6h9bQ&m=KwP1hgxtGRIOF0_QEFN4-whcIOQCyyacO-Lk5F68qPo&s=8K_ctZZY9Aggtx1TtzofZcDz-by02pLJgPuGdWbWTgM&e=  



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.

PST: Paragraph added in Section 2 bottom of page 5 stating that AD-1 has prime responsibility.

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.

PST: Both sentences have been changed to indicate comparison with an AMT enabled peering 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?

PST: Clarifying sentence added in this bullet

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

PST: References changed as pointed out

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.

PST: Sentence changed to state that the 2 AD's interconnect via a peering point.

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?

PST: Section number corrected.



Thanks,

Tomonori Takeda