[Idr] routing directorate QA review of draft-ietf-idr-ls-trill-01.txt

Ross Callon <rcallon@juniper.net> Tue, 21 June 2016 02:27 UTC

Return-Path: <rcallon@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528B012D79C; Mon, 20 Jun 2016 19:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 G4DMm3j8YXwK; Mon, 20 Jun 2016 19:27:55 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr680117.outbound.protection.outlook.com [40.107.68.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A905712D88C; Mon, 20 Jun 2016 19:27:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yNrSZSRiGz9+Zv+0NJPy58qIp0FzCLQCKFFaUV5wyBA=; b=kS7fwutu0PbHZWgSv0RYUkod8aLper1lx/jx0mTfVyjuS9Ldu8NgO9EUSFT7vqzmvscZ5+DfAtzsJTwBe0cBbUBrJAWg4biLpCOefTkcWuRfBdFbNceAhrj4DClqmsF6KXGT/SV5FkKPnbkWPDd8et/eN967tLYQ5Mcg1eTZWCY=
Received: from DM2PR05MB573.namprd05.prod.outlook.com (10.141.159.16) by DM2PR05MB576.namprd05.prod.outlook.com (10.141.159.26) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 02:27:52 +0000
Received: from DM2PR05MB573.namprd05.prod.outlook.com ([10.141.159.16]) by DM2PR05MB573.namprd05.prod.outlook.com ([10.141.159.16]) with mapi id 15.01.0523.015; Tue, 21 Jun 2016 02:27:52 +0000
From: Ross Callon <rcallon@juniper.net>
To: "haoweiguo@huawei.com" <haoweiguo@huawei.com>, Donald Eastlake <d3e3e3@gmail.com>, Susan Hares <shares@ndzh.com>, "sujay.gupta@ipinfusion.com" <sujay.gupta@ipinfusion.com>, "mdurrani@cisco.com" <mdurrani@cisco.com>, 'Yizhou Li' <liyizhou@huawei.com>, John Scudder <jgs@juniper.net>
Thread-Topic: routing directorate QA review of draft-ietf-idr-ls-trill-01.txt
Thread-Index: AdHLZIDwzATvmHF5Tgi9n3A+2f5ymw==
Date: Tue, 21 Jun 2016 02:27:52 +0000
Message-ID: <DM2PR05MB5730CEEFE1F13EB5EA57ED4A52B0@DM2PR05MB573.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net;
x-originating-ip: [66.129.241.12]
x-ms-office365-filtering-correlation-id: bcd8fbfc-447b-469d-f0ab-08d3997ba59d
x-microsoft-exchange-diagnostics: 1; DM2PR05MB576; 6:Yqf9mOVZDE/QrBYy0npsqAeuL2HzWykbUQ2ctAVmO4MWfVNb29bdIjlEP5UiQiAjk+OvUdzJeNzxJppQi5v2fmnzC2e9e3pLVxdxyBNENqKJaQihNDKhsyy1160ICFQ0Glt8j/F88scNT+b9JN3o6KL4P87bWn0SeTeykli1A5yH2Dt4gwvmbdCKp+YPx0SOwnYtr8bNzlGqXOJjGZpHn787tzBNdDdGxJvm6YM1RAbDdTtEbmcKR19+d6TEvdi91GdicYv2X1wTLiEUJmas+Vm0LpfdL2aUNhO4KffhsjWauyq5X7gYyzShK14CFqy1A5qN8DZcfAD7+X8CSF20zw==; 5:M8abhHqoY4shTiKziAxiXHCPo1WECW9E/kIRWWRACRm1qoBG5yjJxja7c4FV5YiqMvmB/aicT0IS5oTpJfN+N1sbJZj7jnsW9Z1Crk3eQRu9zq1E+SZG7ku6YyP8lprY/TJ+WX4ic7uA+IqOvWNg7A==; 24:TLaxdIKotTV4bOf840okn8pUNR9/c/NPaBnHrVYiNiKZW2qwVda/9IfTnmi35JhnmQ6dxEgVSUowSBOSLfq93P5/ZblR0ZrGsZkiHPJITPY=; 7:Mkr1NMuR4FtEEWLRGsW4aEa2TNqTk4ZDL+B8p8LS56UTnthcrp0JvWKS80I/QX52uFdA41Nx3wMLZC8n/wEYl8Sn81F2lrS3+Em+wVZWhSBHb/7P5rFwmJlHK7pYc1DZ7W71YYbVoBYmmN2mEO80ufRD/zWNJ+J26TBDAbj+uaynIVfoDamKRMVl2Dfeuu1nrzLTbfJxVPWpLsUrUGRCkdbeRdgLEuche4mByHjEXeXkcugJ33c+ojOVbjGy5Dru
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB576;
x-microsoft-antispam-prvs: <DM2PR05MB576E1A6AAA72ABE713E608CA52B0@DM2PR05MB576.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR05MB576; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB576;
x-forefront-prvs: 098076C36C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(189002)(199003)(77096005)(229853001)(15975445007)(19580395003)(97736004)(5001770100001)(2900100001)(76576001)(3660700001)(8936002)(11100500001)(92566002)(9686002)(4001450100002)(3280700002)(101416001)(33656002)(105586002)(106356001)(2201001)(10400500002)(575784001)(86362001)(586003)(2906002)(50986999)(1941001)(122556002)(8676002)(5002640100001)(4001430100002)(102836003)(6116002)(2501003)(7846002)(66066001)(189998001)(87936001)(3846002)(54356999)(4326007)(68736007)(74316001)(230783001)(107886002)(81166006)(81156014)(5003600100003)(7696003)(7736002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB576; H:DM2PR05MB573.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR05MB5730CEEFE1F13EB5EA57ED4A52B0DM2PR05MB573namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2016 02:27:52.6429 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB576
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7yXVhY98e-eFgSCQa7NXx-p_0hY>
X-Mailman-Approved-At: Tue, 21 Jun 2016 05:12:16 -0700
Cc: "idr@ietf.org" <idr@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Subject: [Idr] routing directorate QA review of draft-ietf-idr-ls-trill-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2016 02:27:58 -0000

I have been selected as the QA reviewer for draft-ietf-idr-ls-trill-01.txt. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Summary:

I think that this draft is straightforward and well written. I have only a couple of questions and some very minor nits.

I can see situations in which putting TRILL information into BGP may make sense, particularly in the case of providing TRILL information to a SDN controller as pointed out in the draft. Due to the close relationship of this draft to the work in TRILL I have CC'd the TRILL working group on this review and I assume that the TRILL working group will similarly be informed when the document goes to WGLC.


Questions:

Section 1, second to last paragraph states:

   If ESADI (End Station Address Distribution Information) protocol
   [RFC7357] is used for control plane MAC learning in each data center,
   BGP LS also can be used for MAC address reachability information
   synchronization across multiple TRILL domains.  End-to-end unicast
   forwarding paths can be calculated based on the synchronized
   information.

Would this be limited to the case where routes are computed by SDN controllers? I am thinking that if instead the MAC reachability from one data center is passed via BGP and fed back into TRILL in a different data center then this would lead to significant issues which have not been discussed in this document.


Section 5 (security considerations) states:

   Procedures and protocol extensions defined in this document do not
   affect the BGP security model.  See [RFC6952] for details.

I am not a TRILL expert and therefore might not fully understand all cases in which TRILL is used. I am however wondering if there are TRILL-specific issues in that the TRILL information must only be passed to TRILL capable devices. I am also wondering whether there is any valid use of "TRILL in BGP" other than passing TRILL information to SDN controllers. Passing TRILL information from one TRILL domain to another TRILL domain and then redistributing the information back into normal TRILL packets seems like a bad idea at first glance. I am wondering if this section should say something like "this protocol MUST be used ONLY for passing TRILL information from TRILL devices to SDN controllers, and for passing TRILL information between SDN controllers.


Very minor nits:

Section 2 defines the RFC2119 terms and abbreviations used in this document in the same section with no subsections. I think that it is more normal to have a subsection for RFC 2119 terms and a different subsection for abbreviations used in this document.

Section 3, first paragraph, last sentence: "...multicast group address, and  etc." should be "...multicast group address, etc.".

Section 3.1, "iS-IS" should be "IS-IS".

Section 4, second paragraph, I thought that it was a bit odd for a document to reference itself, as in "An implementation of this specification[idr-ls-trill], MUST do...". Would this be a bit less awkward as: "Any implementation of the protocol in this specification (ie that distributes TRILL Link-State information using BGP), MUST do...".


That is all that I found in a couple of readings of this document,
Thanks, Ross