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

Donald Eastlake <d3e3e3@gmail.com> Tue, 26 July 2016 15:21 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 24D1D12DF25; Tue, 26 Jul 2016 08:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aqwdkQj06eRm; Tue, 26 Jul 2016 08:21:23 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB8312D7C2; Tue, 26 Jul 2016 07:47:01 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id m101so23783041ioi.2; Tue, 26 Jul 2016 07:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5Xu5lwSLiZ+j5NGlmFdVzS/QsDqJAo7sck0xtKFyV4c=; b=NlFKStQrvCaiUMXOy9z5/4XcChksAW71c33KXUGmxcSorg1Usa/pJ5wEYQHIIMzplP OC8lImsQqBIgxUvWuA/7D+nd0+UHucej1Au2O27pWNmK6nwk/S2DYkJ/al76FO0gkKcs htKrcijaY3aAmz8LYiWkw/GHW12YA5lvaqAdykB0RHMTzTVJurKkDhU7DmiP0V2MHKbq fB89hPqVoL/FlYZjbV1w2mKfh3rA3xnGrGCPdRO2GmTwUdB2DPqVmxHIw9txckkoHb5z hOsapTaR4MbWGbzzl4o/IJ5oC2Mk6NiRMw3nu4IpDYnPNtucwRzeztGBcXod7d/PMqep WoVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5Xu5lwSLiZ+j5NGlmFdVzS/QsDqJAo7sck0xtKFyV4c=; b=ZeI70XWk5oOsJiBhf76iMyqpcaL7DBulnn4XK/5iYlIXJrIVsXNOMWrwgxjthBV3W8 OalM12HfGKvRaBJ2AC9OBoJtFxAQDR5EtXQL1U3kNOe5K44A6+AgjzP3YMwtB/d6YiHA TEJ7uCT6haLS3n4b66PzBadTV1JTEnYC4Ca8+uS/7Y7dwXmeSRVmsCnf1TVdv6JJdzhL pu5YVdhylZyatDQjSITvvX/rC5AJWBTun6+M76F/uNmaw4VDYvWm+d5LdEOY7WJKsugi uTeN+aVcm1SfB4xuxwam8y3baRcm8Dwt2Mvxw8MASDK1S/yl7k8Tr2rffEq3iwUqrHF9 sJmQ==
X-Gm-Message-State: AEkoouuq6uSmdtr5OuKkfjlwsmS2act2R/V6nygapmJHX7yTXmTLnQzFozN1J2Mm+BOyf1o4BGg8bTmB/YFT8w==
X-Received: by with SMTP id c2mr12150583otb.181.1469544420748; Tue, 26 Jul 2016 07:47:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 26 Jul 2016 07:46:46 -0700 (PDT)
In-Reply-To: <CAF4+nEEbJC2GJep0EUWJBWLCNU8gpgr6a9Rp6NnLXdXhSrXHfQ@mail.gmail.com>
References: <DM2PR05MB5730CEEFE1F13EB5EA57ED4A52B0@DM2PR05MB573.namprd05.prod.outlook.com> <DD5FC8DE455C3348B94340C0AB55173350D676F3@nkgeml513-mbx.china.huawei.com> <CAF4+nEEbJC2GJep0EUWJBWLCNU8gpgr6a9Rp6NnLXdXhSrXHfQ@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 26 Jul 2016 10:46:46 -0400
Message-ID: <CAF4+nEFJK0FDRfuzJxJ5tzfZEVSO8weEfm_v_QfxYhdVrtvLJg@mail.gmail.com>
To: "trill@ietf.org" <trill@ietf.org>, idr@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/wpceGb6rmn4Buw0vnhRvcKjYVyg>
Cc: Ross Callon <rcallon@juniper.net>
Subject: [trill] Fwd: routing directorate QA review of draft-ietf-idr-ls-trill-01.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 15:21:27 -0000

Forwarding to addresses that should have been cc'ed below.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

---------- Forwarded message ----------
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, Jul 26, 2016 at 1:47 AM
Subject: Re: routing directorate QA review of draft-ietf-idr-ls-trill-01.txt
To: Ross Callon <rcallon@juniper.net>
Cc: Susan Hares <shares@ndzh.com>om>, "sujay.gupta@ipinfusion.com"
<sujay.gupta@ipinfusion.com>om>, "mdurrani@cisco.com"
<mdurrani@cisco.com>om>, Liyizhou <liyizhou@huawei.com>om>, John Scudder
<jgs@juniper.net>et>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>rg>, Haoweiguo
<haoweiguo@huawei.com>om>, "trill-chairs@ietf.org"

Hi Ross,

Sorry for the delay in response. Based on discussions with Hao Weiguo,
the plan is to make minor changes in the draft so as to indicate that
the transported MAC reachability information and the like is for
telemetry purposes and for use by SDN controller(s) where the
coordination or protocol between the SDN controllers is out of scope.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

On Sun, Jul 10, 2016 at 8:58 PM, Haoweiguo <haoweiguo@huawei.com> wrote:
> Hi Ross,
> Sorry for late response.
> Thanks for your great comments. Pls see inline.
> weiguo
> ________________________________
> From: Ross Callon [rcallon@juniper.net]
> Sent: Tuesday, June 21, 2016 10:27
> To: Haoweiguo; Donald Eastlake; Susan Hares; sujay.gupta@ipinfusion.com;
> mdurrani@cisco.com; Liyizhou; John Scudder
> Cc: idr@ietf.org; trill@ietf.org; rtg-dir@ietf.org; Ross Callon
> Subject: routing directorate QA review of draft-ietf-idr-ls-trill-01.txt
> 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.
> [weiguo]: Yes, the routes are consumed and computed by SDN controllers is
> the main case. However, i don't know why the MAC reachability passing from
> one data center and feeding back into another data center will cause
> significant problems, can you explain further about this?
> 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.
> [weiguo]: BGP LS provides a mechanism for passing TRILL information from one
> domain to another domain, it also can be used for passing TRILL information
> from TRILL devices to SDN controllers and between SDN controllers. Can you
> explain further about why BGP LS can't be used for passing TRILL information
> from one domain to another domain?
> 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.
> [weiguo]: OK, will change it in next version.
> Section 3, first paragraph, last sentence: “…multicast group address, and
> etc.” should be “…multicast group address, etc.”.
> [weiguo]: OK, will change it in next version.
> Section 3.1, “iS-IS” should be “IS-IS”.
> [weiguo]: OK, will change it in next version.
> 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…”.
> [weiguo]: OK, will change it in next version.
> That is all that I found in a couple of readings of this document,
> Thanks, Ross