From nobody Sun Jan 1 14:54:35 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774D01293DC for ; Sun, 1 Jan 2017 14:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-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 uSQTQ_ilpNJp for ; Sun, 1 Jan 2017 14:54:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34962128AC9 for ; Sun, 1 Jan 2017 14:54:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDQ12811; Sun, 01 Jan 2017 22:54:29 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 1 Jan 2017 22:54:28 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Sun, 1 Jan 2017 14:53:00 -0800 From: Linda Dunbar To: "trill@ietf.org" Thread-Topic: [trill] draft-ietf-trill-over-ip WG Last Call (11/15 - 12/6) Thread-Index: AQHSY6kZsee81Yu62kmMuB9AlrCFvaEkPDEQ Date: Sun, 1 Jan 2017 22:52:59 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65885FF23@dfweml501-mbb> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.586988A6.00B5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2d87ccacc05d8b145a94422e959e4054 Archived-At: Subject: Re: [trill] draft-ietf-trill-over-ip WG Last Call (11/15 - 12/6) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 22:54:33 -0000 Support for publishing=20 Linda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Nov 15, 2016 at 3:47 AM, Donald Eastlake wrote: > On behalf of the Chairs, this message begins a three week WG Last Call=20 > on https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ > There are no IPR declarations filed with the IETF on this draft. > > The call is three weeks rather than the usual two due to overlap with=20 > the IETF meeting when people are usually pretty busy. > > In your response please include answers to the following questions: > > Is this draft ready for publication? > Are there any significant aspects of TRILL over IP that are omitted=20 > from the draft? > > Is the encapsulation agreement method provided in the draft necessary=20 > and sufficient for good support of TRILL over IP? > > > Thanks, > Donald (TRILL WG Secretary) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From nobody Mon Jan 2 09:48:35 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA08B1296D8 for ; Mon, 2 Jan 2017 09:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.32 X-Spam-Level: X-Spam-Status: No, score=-7.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-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 vuZHDrrN3jb7 for ; Mon, 2 Jan 2017 09:48:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2651296DF for ; Mon, 2 Jan 2017 09:48:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDR21575; Mon, 02 Jan 2017 17:48:23 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 2 Jan 2017 17:48:22 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0301.000; Mon, 2 Jan 2017 09:48:16 -0800 From: Lucy yong To: "trill@ietf.org" Thread-Topic: RE:[trill] draft-ietf-trill-over-ip WG Last Call (11/15 - 12/6) Thread-Index: AdJlIF6tD+PHp0VKQOmMqwT+0nWv6Q== Date: Mon, 2 Jan 2017 17:48:16 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57B9BE55@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.166] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57B9BE55dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.586A9268.0080, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 59330b83549f650507fc56625121d1b6 Archived-At: Subject: Re: [trill] draft-ietf-trill-over-ip WG Last Call (11/15 - 12/6) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 17:48:29 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57B9BE55dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support publishing. One comment: In section 8.1 , d. Use of a "Managed Circuit Breaker" for= the TRILL traffic as described in [circuit-breaker]. CB can't serve this purpose. Please look at the congestion consideration t= ext in https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-19 Lucy On behalf of the Chairs, this message begins a three week WG Last Call on https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ There are no IPR declarations filed with the IETF on this draft. The call is three weeks rather than the usual two due to overlap with the I= ETF meeting when people are usually pretty busy. In your response please include answers to the following questions: Is this draft ready for publication? Are there any significant aspects of TRILL over IP that are omitted from th= e draft? Is the encapsulation agreement method provided in the draft necessary and s= ufficient for good support of TRILL over IP? Thanks, Donald (TRILL WG Secretary) --_000_2691CE0099834E4A9C5044EEC662BB9D57B9BE55dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support publishing.

 

One comment:  In section 8.1 ,   &nbs= p;d. Use of a "Managed Circuit Breaker" for the TRILL traffic as<= o:p>

      described in [circuit= -breaker].

CB can’t serve this purpose.  Please look= at the congestion consideration text in

 https://tools.ietf.org/html/draft-ietf-tsvwg= -gre-in-udp-encap-19

 

Lucy

 

On behalf of the Chairs, this message begins a three= week WG Last Call on

https://datatracker.ietf.org/doc/draft-ietf-trill-over-i= p/

There are no IPR declarations filed with the IETF on= this draft.

 

The call is three weeks rather than the usual two du= e to overlap with the IETF meeting when people are usually pretty busy.

 

In your response please include answers to the follo= wing questions: 

 

Is this draft ready for publication?

Are there any significant aspects of TRILL over IP t= hat are omitted from the draft?

Is the encapsulation agreement method provided in th= e draft necessary and sufficient for good support of TRILL over IP?

 

Thanks,
Donald (TRILL WG Secretary)

 

--_000_2691CE0099834E4A9C5044EEC662BB9D57B9BE55dfweml501mbb_-- From nobody Tue Jan 3 03:31:50 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E7D129570; Tue, 3 Jan 2017 03:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 i328QgyopCXv; Tue, 3 Jan 2017 03:31:46 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2041294EB; Tue, 3 Jan 2017 03:31:45 -0800 (PST) X-AuditID: c1b4fb30-d248a98000007ae2-99-586b8b9fae68 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 90.27.31458.F9B8B685; Tue, 3 Jan 2017 12:31:43 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.319.2; Tue, 3 Jan 2017 12:30:40 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F1C44510C6; Tue, 3 Jan 2017 13:31:01 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C96894EA97; Tue, 3 Jan 2017 13:30:59 +0200 (EET) To: Donald Eastlake References: <148290260152.14213.11124890517026127285.idtracker@ietfa.amsl.com> From: Ines Robles Message-ID: Date: Tue, 3 Jan 2017 20:30:37 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM2K7je787uwIg4ZXWhYHt2tafP46jd3i 2cb5LBYL1jxlt3g/eTubA6vHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx+0InW8FdlopZ jz8xNzBuZu5i5OSQEDCRWHbgHGsXIxeHkMA6Rokl6xayQzhbGSU6bnyCctYySsz9/gGqbB6j xMpprawg/cICRhKHn/YxgtgiAmoSr5cvYIEomsoocfrpdrB2ZoEZjBIr9jSCbWQD6jj74Scb iM0rYC8xaQOEzSKgIvFrzUmmLkYODlGBCImGw+kQJYISJ2c+YQGxOQUCJXq2bAcrZxawkJg5 /zwjhC0vsf3tHKiH1CSuntsEZgsJaEtMn3ufZQKj8Cwko2YhaZ+FpH0BI/MqRtHi1OKk3HQj I73Uoszk4uL8PL281JJNjMAYOLjlt8EOxpfPHQ8xCnAwKvHwfsjKihBiTSwrrsw9xCjBwawk wmvSkR0hxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUAyOb 8c4+s9cFPip73LeXF81Q2x5zPOfkhqLAEM7FisGX91w4qnvMM2I716+VYQcONpyv4rLzM3Hc c+8uY/Hn6PctLay612ZdFS1Yd1FwymOT9OIAaaaoe7yx9kn8RSsyjsbsO5zTcWVx5XFfi3WO 0dtWysu3Gyc9+FTIkF/0Lf7cXrv/v7Yuc1ViKc5INNRiLipOBADtMDHafQIAAA== Archived-At: Cc: "rtg-dir@ietf.org" , draft-ietf-trill-over-ip.all@ietf.org, IETF Discussion , "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-over-ip-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:31:47 -0000 Hi, I agree with your comment, thank you, Cheers, Ines. On 30.12.2016 02:43, Donald Eastlake wrote: >> Section 4.5: TRILL Over IP IS-IS SubNetwork Point of Attachment >> I think it would be nice to add in the text the meaning of "111111" >> depicted in the figure. > Humm... Those are the first digits of vertically arrayed bit numbers > (10 through 15). So, since it would fit, maybe we should make those > bits one character space wider so the bit number can be horizontal > rather than vertical. I think that would be clearer. > > From nobody Tue Jan 3 10:57:29 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA49B129AE5; Tue, 3 Jan 2017 10:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 5kKOCO0Uh_t2; Tue, 3 Jan 2017 10:57:20 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 15C15129AD3; Tue, 3 Jan 2017 10:57:20 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v03IuSVY024112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Jan 2017 10:56:29 -0800 (PST) To: Ines Robles , rtg-dir@ietf.org References: <148290260152.14213.11124890517026127285.idtracker@ietfa.amsl.com> From: Joe Touch Message-ID: <9bbd1c40-a983-e85c-5656-ef17d50b8605@isi.edu> Date: Tue, 3 Jan 2017 10:56:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148290260152.14213.11124890517026127285.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: trill@ietf.org, ietf@ietf.org, draft-ietf-trill-over-ip.all@ietf.org Subject: Re: [trill] Review of draft-ietf-trill-over-ip-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 18:57:22 -0000 Some observations: - the title is misleading; this is TRILL over UDP, not trill over IP. - the use of two different ports invites some potentially unintended problems, e.g., selective blocking of the control vs. data plane. IMO, given that TRILL's purpose is to extend Ethernet (not IP), this service would be better served using a single port and differentiated encapsulated traffic by whatever method TRILL nodes use internally. Otherwise, this spec needs to include specific description of unexpected behavior, e.g., data frames on the IS-IS port and IS-IS frames on the data port. - regardless of whether one or two ports are requested, this doc should provide the needed information for IANA (e.g., a service name and description compliant with RFC6335). - the section on MTU handling might benefit from informationally citing intarea-tunnels, and consider using the recommendations there. In particular, it's not sufficient to assume IPv4 supports 576 byte MTUs (that's the minimum receiver reassembly MTU, not the transit MTU). That section should also address issues of PMTUD and PLMTUD. FWIW. Joe From nobody Wed Jan 4 17:43:29 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875EC1294C6; Wed, 4 Jan 2017 17:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjKLHSYD72R7; Wed, 4 Jan 2017 17:43:27 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 25882129421; Wed, 4 Jan 2017 17:43:26 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id d9so468246069ioe.0; Wed, 04 Jan 2017 17:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=shYu8Lzejr0kqXrUueN31nYnZk9TQtaMo+crB2KPSWM=; b=QjfzUT3pGYyOscfjfq2vLi5Z8LZ8ACRyO/0R6BxUmrP+3HKSy1YLxFEKP1CFaeE4OA zLXZKS7hJZeCG17WBcsdMzNbzq8Vt886gI2I+RLfYbYAr9rMiVr12aHBAs/nTVhO3SOR y88+LilYYyvBUeLV0cMfmcGLkzi73VyvRyUERg2v9W3Jf5xvGgXYk90L4JQJ8GBxrDtz 8DjsbvGTbWqw5fKh+sw46yniHzOTj6huxbXm4rPtL2v+536myZR6vNsREAne0aejUS3D /Ub4N8dyak4ZzAsJ3ognkvQ62+Sy++p+ekDRAVFYrPZqEtmKgJ0INap1Utsmmvf8nqBC 0Btg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=shYu8Lzejr0kqXrUueN31nYnZk9TQtaMo+crB2KPSWM=; b=rctzrY0VOw/1LJ1cueja/EbSlseSUz/eVG/sbgUUQJGVjkheBMfBeV4AN1ydeqU1FL VNFGOzQs7i0VtXRAiet6O94IA3PEK1ZBqVofiNbXvaVBK7/s1zrKdjao4rOYYcTTepts 5lAM8O6Ubs/N113snaXKexJAh5sfCeYsl7hmiM6Nkwng3lZQY8a7Aqkd71GZOiToycg6 egu326SiGu/iTP+R4JmWiMsqaLxHeAweFUS2e5CN+LVogWNgrCqa3dbY+xxll0QCYa71 x1sKNiSwu/EdTXOZ6g4qU433FYmd6hyWI2lLdqXlf6BB7NDjv0ZtFXlgpuZCOy3v5Vwb shtg== X-Gm-Message-State: AIkVDXKt1CgGvefTozN9XlJ/CXfATB8SYR1/YOmrOX/B9/9ukwdO2fkqbU91rEmFeDHeNa4hMR+VpztWgiifOw== X-Received: by 10.107.175.80 with SMTP id y77mr50675142ioe.12.1483580606237; Wed, 04 Jan 2017 17:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.136 with HTTP; Wed, 4 Jan 2017 17:43:10 -0800 (PST) In-Reply-To: <9bbd1c40-a983-e85c-5656-ef17d50b8605@isi.edu> References: <148290260152.14213.11124890517026127285.idtracker@ietfa.amsl.com> <9bbd1c40-a983-e85c-5656-ef17d50b8605@isi.edu> From: Donald Eastlake Date: Wed, 4 Jan 2017 20:43:10 -0500 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-dir@ietf.org" , "trill@ietf.org" , IETF Discussion , draft-ietf-trill-over-ip.all@ietf.org Subject: Re: [trill] Review of draft-ietf-trill-over-ip-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 01:43:28 -0000 Hi Joe, Thanks for the comments. On Tue, Jan 3, 2017 at 1:56 PM, Joe Touch wrote: > > Some observations: > > - the title is misleading; this is TRILL over UDP, not trill over IP. Humm... The two encapsulations specified do use UDP and it seems implausible that TCP would be used. But it is possible someone would want to use SCTP or some other non-UDP IP encapsulation. That would presumably be via some future document. So I guess, on balance it would be better to change the title as you suggest. > - the use of two different ports invites some potentially unintended > problems, e.g., selective blocking of the control vs. data plane. IMO, > given that TRILL's purpose is to extend Ethernet (not IP), this service > would be better served using a single port and differentiated > encapsulated traffic by whatever method TRILL nodes use internally. > Otherwise, this spec needs to include specific description of unexpected > behavior, e.g., data frames on the IS-IS port and IS-IS frames on the > data port. I guess I don't see this. As for selective blocking, if someone can control the passing of traffic through links connecting TRILL switches, they can always block a subset of traffic based on whatever criteria they want. I don't think it makes significant difference what header field they look at. Similarly, if someone can modify traffic passing through links between TRILL switches, if the traffic is IP they could swap around port numbers, but they could also swap around other header fields. Presumably it is a policy decision for network managers based on their threat model whether or not to use facilities by TRILL or otherwise to provided to secure control traffic and/or use link security to protect all traffic over a link. (Similarly, it is a matter for end system users/managers to decide whether to use end-to-end security.) I suppose we could throw in a few sentences saying that if security is not being used and data or control is mislabeled as the other and it happens to be parseable as the other, you will get junk in the data stream or screwed up control information. But I don't think the mislabeling of control and data as the other by TRILL code is a realistic problem. It would be detected by the crudest of testing. > - regardless of whether one or two ports are requested, this doc should > provide the needed information for IANA (e.g., a service name and > description compliant with RFC6335). OK. > - the section on MTU handling might benefit from informationally citing > intarea-tunnels, and consider using the recommendations there. In > particular, it's not sufficient to assume IPv4 supports 576 byte MTUs > (that's the minimum receiver reassembly MTU, not the transit MTU). That > section should also address issues of PMTUD and PLMTUD. I'll take a look at that draft in this context. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > FWIW. > > Joe From nobody Thu Jan 5 10:45:20 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B161295F4; Thu, 5 Jan 2017 10:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 4RKGF3bD11XE; Thu, 5 Jan 2017 10:45:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 D0740129590; Thu, 5 Jan 2017 10:45:10 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v05IiaDY006532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 10:44:36 -0800 (PST) To: Donald Eastlake References: <148290260152.14213.11124890517026127285.idtracker@ietfa.amsl.com> <9bbd1c40-a983-e85c-5656-ef17d50b8605@isi.edu> From: Joe Touch Message-ID: <8ad2471d-e58c-44aa-8ce9-ff814652b10c@isi.edu> Date: Thu, 5 Jan 2017 10:44:37 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "rtg-dir@ietf.org" , "trill@ietf.org" , IETF Discussion , draft-ietf-trill-over-ip.all@ietf.org Subject: Re: [trill] Review of draft-ietf-trill-over-ip-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 18:45:12 -0000 Hi, Donald, On 1/4/2017 5:43 PM, Donald Eastlake wrote: > Hi Joe, > > Thanks for the comments. > > On Tue, Jan 3, 2017 at 1:56 PM, Joe Touch wrote: >> - the use of two different ports invites some potentially unintended >> problems, e.g., selective blocking of the control vs. data plane. IMO, >> given that TRILL's purpose is to extend Ethernet (not IP), this service >> would be better served using a single port and differentiated >> encapsulated traffic by whatever method TRILL nodes use internally. >> Otherwise, this spec needs to include specific description of unexpected >> behavior, e.g., data frames on the IS-IS port and IS-IS frames on the >> data port. > I guess I don't see this. It's a configuration issue - what happens when (not if) a sysadmin opens up one port but not the other? IMO, unless there's a reason for that sort of selective filtering or there's a specific need to encapsulate the traffic differently, these ought to be treated as a single service - TRILL UDP encapsulation. It's only inside the TRILL system that the difference between data and IS-IS is useful and this encapsulation will have no effect on those nodes. > As for selective blocking, if someone can control the passing of > traffic through links connecting TRILL switches, they can always block > a subset of traffic based on whatever criteria they want. I don't > think it makes significant difference what header field they look at. I'm thinking of the increased complexity and potential for failure by not "fate sharing" data and IS-IS traffic. > Similarly, if someone can modify traffic passing through links between > TRILL switches, if the traffic is IP they could swap around port > numbers, but they could also swap around other header fields. > Presumably it is a policy decision for network managers based on their > threat model whether or not to use facilities by TRILL or otherwise to > provided to secure control traffic and/or use link security to protect > all traffic over a link. (Similarly, it is a matter for end system > users/managers to decide whether to use end-to-end security.) I'm asking whether you actually expect or want IP transit nodes to treat data and IS-IS traffic differently - via different routes, different drop policies, etc. If not, then there's no benefit from having two service ports. > I suppose we could throw in a few sentences saying that if security is > not being used and data or control is mislabeled as the other and it > happens to be parseable as the other, you will get junk in the data > stream or screwed up control information. TRILL data and IS-IS is already treated differently inside a TRILL campus, e.g., by their existing headers. I can't see data being treated as IS-IS or vice versa inside the campus, regardless of which port the traffic arrives on. That's largely my point - if the encap/decap node wouldn't need to treat these differently in either direction (leaving or entering the TRILL campus), then they're one service. > But I don't think the > mislabeling of control and data as the other by TRILL code is a > realistic problem. It would be detected by the crudest of testing. It *can* be detected, but your protocol needs to specify the correct behavior. Is the UDP tunnel ingress/egress supposed to prevent such mislabeling on ingress? If so, why would it care? If not, then again there's no point to two services. Joe From nobody Thu Jan 5 11:01:28 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6468A129625; Thu, 5 Jan 2017 11:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 L7H6bbrofbc8; Thu, 5 Jan 2017 11:01:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 1829B129619; Thu, 5 Jan 2017 11:01:22 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v05J0uHG008810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 11:00:57 -0800 (PST) To: Donald Eastlake References: <148290260152.14213.11124890517026127285.idtracker@ietfa.amsl.com> <9bbd1c40-a983-e85c-5656-ef17d50b8605@isi.edu> <8ad2471d-e58c-44aa-8ce9-ff814652b10c@isi.edu> From: Joe Touch Message-ID: <78015424-9f4a-2d40-6898-38b02dacc7b9@isi.edu> Date: Thu, 5 Jan 2017 11:00:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <8ad2471d-e58c-44aa-8ce9-ff814652b10c@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "rtg-dir@ietf.org" , "trill@ietf.org" , IETF Discussion , draft-ietf-trill-over-ip.all@ietf.org Subject: Re: [trill] Review of draft-ietf-trill-over-ip-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:01:23 -0000 PS - I have a broader question about this work. Why is this a service at all? There are dozens of ways of taking existing IP or Ethernet traffic and encapsulating them for IP tunnel transit, some including much stronger protections (e.g. SEAL/AERO provides better fragmentation/reassembly support). Why not use one of those existing services? The only thing this saves is the link header/trailer overhead, but then it also begs the question of the identity of these tunnel endpoints within the TRILL system (which are indicated by addresses used in those link headers). (if there is an answer to this, it really should be included in the intro) Joe On 1/5/2017 10:44 AM, Joe Touch wrote: > Hi, Donald, > > > On 1/4/2017 5:43 PM, Donald Eastlake wrote: >> Hi Joe, >> >> Thanks for the comments. >> >> On Tue, Jan 3, 2017 at 1:56 PM, Joe Touch wrote: >>> - the use of two different ports invites some potentially unintended >>> problems, e.g., selective blocking of the control vs. data plane. IMO, >>> given that TRILL's purpose is to extend Ethernet (not IP), this service >>> would be better served using a single port and differentiated >>> encapsulated traffic by whatever method TRILL nodes use internally. >>> Otherwise, this spec needs to include specific description of unexpected >>> behavior, e.g., data frames on the IS-IS port and IS-IS frames on the >>> data port. >> I guess I don't see this. > It's a configuration issue - what happens when (not if) a sysadmin opens > up one port but not the other? > > IMO, unless there's a reason for that sort of selective filtering or > there's a specific need to encapsulate the traffic differently, these > ought to be treated as a single service - TRILL UDP encapsulation. > > It's only inside the TRILL system that the difference between data and > IS-IS is useful and this encapsulation will have no effect on those nodes. > >> As for selective blocking, if someone can control the passing of >> traffic through links connecting TRILL switches, they can always block >> a subset of traffic based on whatever criteria they want. I don't >> think it makes significant difference what header field they look at. > I'm thinking of the increased complexity and potential for failure by > not "fate sharing" data and IS-IS traffic. > >> Similarly, if someone can modify traffic passing through links between >> TRILL switches, if the traffic is IP they could swap around port >> numbers, but they could also swap around other header fields. >> Presumably it is a policy decision for network managers based on their >> threat model whether or not to use facilities by TRILL or otherwise to >> provided to secure control traffic and/or use link security to protect >> all traffic over a link. (Similarly, it is a matter for end system >> users/managers to decide whether to use end-to-end security.) > I'm asking whether you actually expect or want IP transit nodes to treat > data and IS-IS traffic differently - via different routes, different > drop policies, etc. If not, then there's no benefit from having two > service ports. > >> I suppose we could throw in a few sentences saying that if security is >> not being used and data or control is mislabeled as the other and it >> happens to be parseable as the other, you will get junk in the data >> stream or screwed up control information. > TRILL data and IS-IS is already treated differently inside a TRILL > campus, e.g., by their existing headers. I can't see data being treated > as IS-IS or vice versa inside the campus, regardless of which port the > traffic arrives on. > > That's largely my point - if the encap/decap node wouldn't need to treat > these differently in either direction (leaving or entering the TRILL > campus), then they're one service. > >> But I don't think the >> mislabeling of control and data as the other by TRILL code is a >> realistic problem. It would be detected by the crudest of testing. > It *can* be detected, but your protocol needs to specify the correct > behavior. Is the UDP tunnel ingress/egress supposed to prevent such > mislabeling on ingress? If so, why would it care? If not, then again > there's no point to two services. > > Joe From nobody Sun Jan 8 15:06:11 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5F6129458; Sun, 8 Jan 2017 15:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 kEol1yUHpwqr; Sun, 8 Jan 2017 15:06:08 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 291741200A0; Sun, 8 Jan 2017 15:06:05 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.7.201; From: "Susan Hares" To: Date: Sun, 8 Jan 2017 18:02:03 -0500 Message-ID: <001b01d26a03$3ac96910$b05c3b30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01D269D9.51F8DF50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJp/ay9nEwyTlv/Tzaj1/Mf9QDfeg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , draft-ietf-trill-directory-assist-mechanisms@ietf.org, 'Radia Perlman' , 'Liyizhou' , linda.dunbar@huawei.com Subject: [trill] draft-ietf-trill-directory-assist-mechanism-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 23:06:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01D269D9.51F8DF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Donald, Yizhou, Linda, and Radia: Thank you for your work on draft-ietf-trill-directory-assist-mechanisms. Each draft improves the readability and nails down some of the potential edge cases. I believe we are nearing the end of this journey toward IESG approval. I am joining with you on this journey by doing a shepherd review at the end of IETF LC. Status: Ready to publication, with some editorial nits you should consider Here's my editorial nits on the latest version. Please address #2 - that deals with the "SEND" functionality and #6 #1, p. 5 paragraph 1, list item 3. - simple spelling error Old:/MAC addresses "nomrally" / New: /MAC Addresses normally/ #2. p. 17-22 - section 3 #2.a Overall - I think you need to include SEND messages in this Query messages. #2.b p17, section 3.0 paragraph 5 specific text change Old:/The requests to Pull Directory servers are typically derived from ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or Draft frames with unknown unicast destination MAC addresses, intercepted by an ingress TRILL switch as described in Section 1.1/ New:/ The requests to Pull Directory servers are typically derived from ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or draft Layer 2 frames with unknown unicast destination MAC addresses intercepted by an ingress TRILL switch as described in Section 1.1/ Reason: SEND mechanisms need to be clearly specified in the draft. Suresh Krishnan mentioned this on the ARP optimization draft. #3 p. 19, section 3.2.1 paragraph 1, sentence 3 Old: /The priority of the channel message is a mapping of the priority of the frame being ingressed that caused the query with the default mapping depending, per Data Label, on the strategy (see Section 4 ) or a configured priority (DirGenQPriority, Section 3.9 ) for generated queries./ New:/ The priority of the channel message is a mapping of the priority of the ingress frame which caused the query combined with the default mapping per Data Label depending on the strategy for generated queries (see Section 4 ) or a configured priority (DirGenQPriority, Section 3.9 /. Reason: Clarify sentences. #4, p. 33 section 3.5.1 paragraph 3 Old:/ The Bridge shown might be a complex bridged LAN or might be absent if, as shown for End Station 1, End Station 2 was dual ported with point-to-point Ethernet links to RB1 and RB2./ New:/The Bridge shown might be a complex bridged LAN, a LAN without a bridge (as shown in End station 1), or connected via point-to-point links (as shown in End Station 2's which is connected through a bridge with point-to-point Ethernet links to RB1 and RB2./ Reason: Clarify the sentences #5, p. 33 section 3.5.1 paragraph 4 sentence 1. Old:./ Because an indirect Pull Directory server discards information it has cached from queries to an end station Pull Directory server if it loses adjacency to that server (Section 3.7 ), if it knowns that such information may be cached at RBridge clients and has no other source for the information, it MUST send Update Messages to those clients withdrawing the information/ New: /Since an indirect Pull Directory server discards information it has cached from queries to an end station Pull Directory server if it loses adjacency to the server (Section 3.7), if it detects that information may be cached at RBridge clients and has no other source for the information, it MUST send Update Messages to those clients withdrawing the information/ Words changed - in bold Why: anthropomorphism - TRILL switches do not know. TRILL switches detect based on logic. Why: Because/since - both indicate causes, but "since" seems to indicate an ordering that this paragraph suggests. #6: p. 43, 4th paragraph beginning with Although some . Current text: /Although some of the ports sending TRILL ES-IS PDUs are on end stations and thus not on routers (TRILL switches), they nevertheless may make use of the Router Capability (#242) and MT-Capability (#222) IS-IS TLVs to indicate capabilities as elsewhere specified./ It would be good to indicate where these capabilities are specified. #7 p. 44, section 6 - Security considerations After the SEC-DIR review comes in, consider if the end-system engage requires some extra text on privacy related to the end-systems. Since Donald and Radia are much better at all types of security, please consider this as a "please check". Kathleen and Stephen are focused on this work. ------=_NextPart_000_001C_01D269D9.51F8DF50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Donald, = Yizhou, Linda, and Radia:

 

Thank you = for your work on draft-ietf-trill-directory-assist-mechanisms.  = Each draft improves the readability and nails down some of the potential = edge cases.   I believe we are nearing the end of this journey = toward IESG approval. I am joining with you on this journey by doing a = shepherd review at the end of IETF LC.

 

Status: = Ready to publication, with some editorial nits you should consider =

 

 

 

Here’s = my editorial nits on the latest version.   Please address #2 = – that deals with the “SEND” functionality and #6 =

 

#1, p. 5 paragraph 1, list item 3.   – = simple spelling error

 

Old:/MAC = addresses “nomrally” /

New: /MAC Addresses normally/

 

#2. p. 17-22 = – section 3

 

#2.a Overall = – I think you need to include SEND messages in this Query  = messages.

 

#2.b p17, section 3.0 paragraph 5  specific text = change

 

Old:/The requests to Pull Directory servers are = typically derived from ingressed ARP [RFC826], ND [RFC4861],  RARP = [RFC903], or

Draft frames with = unknown unicast destination MAC addresses, intercepted by an ingress = TRILL switch as described in Section 1.1/

 

New:/ The = requests to Pull Directory servers are typically derived from ARP = [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or = draft Layer 2 frames with unknown unicast destination MAC addresses = intercepted by an ingress TRILL switch as described in Section = 1.1/

 

Reason: SEND mechanisms need to be clearly specified = in the draft.  Suresh Krishnan mentioned this on the ARP = optimization draft.  

 

#3 p. 19, = section 3.2.1 paragraph 1, sentence 3

 

Old: /The priority of the channel message is a mapping =
of the
   priority of the frame being ingressed =
that caused the query with the
   default mapping depending, per Data =
Label, on the strategy (see
   Section 4) or a configured priority =
(DirGenQPriority, Section =
3.9)
   for generated =
queries./
 
New:/ The priority of the channel message is a =
mapping of the
   priority of the ingress frame which =
caused the query combined with the 
   default mapping per Data Label =
depending on the strategy for =
generated
   queries (see Section 4) or a configured priority =
(DirGenQPriority, Section =
3.9/.
 
Reason: Clarify sentences. =

 
#4, p. 33 section 3.5.1 paragraph 3 =

 
Old:/ The Bridge shown might be a complex bridged =
LAN or might be absent
   if, as shown for End Station 1, End =
Station 2 was dual ported with
   point-to-point Ethernet links to RB1 =
and RB2./
 
New:/The Bridge shown might be a complex bridged =
LAN, a LAN without a bridge
(as shown in End station 1), or connected via =
point-to-point links (as shown in 
End Station 2’s which is connected through a =
bridge with point-to-point Ethernet links to =

RB1 and RB2./ =

 
Reason: Clarify the sentences =

 

#5, p. 33 section 3.5.1 paragraph 4 sentence = 1.

 

Old:./

   Because an indirect Pull Directory =
server discards information it has
   cached from queries to an end station =
Pull Directory server if it
   loses adjacency to that server (Section 3.7), if it knowns that =
such
   information may be cached at RBridge =
clients and has no other source
   for the information, it MUST send =
Update Messages to those clients
   withdrawing the =
information/
 
 
New: /Since an indirect Pull Directory =
server discards information it has 
     cached from queries =
to an end station Pull Directory server if it =

     loses adjacency to =
the server (Section 3.7), if it detects that =

     information may be =
cached at RBridge clients and has no other =
source
  =
   for the information, it MUST send Update Messages to =
those clients
     withdrawing the =
information/

 

Words = changed – in bold

Why: = anthropomorphism – TRILL switches do not know.  TRILL = switches detect based on logic.

Why: = Because/since – both indicate causes, but “since” = seems to indicate an ordering that this paragraph suggests. =

 

#6: p. 43, 4th paragraph beginning with = Although some …

 

Current =
text:
  =
 /Although some of the ports sending TRILL ES-IS PDUs are on =
end
   =
stations and thus not on routers (TRILL switches), they =
nevertheless
   may make use of the Router Capability =
(#242) and MT-Capability (#222)
   IS-IS TLVs to indicate capabilities =
as elsewhere specified./
 
It would be =
good to indicate where these capabilities are specified. =

 
 =

#7 p. 44, section 6 – Security = considerations

 

After the SEC-DIR review comes in, consider = if the end-system engage requires some extra text on privacy related to = the end-systems.

 

Since Donald and Radia are much better at = all types of security, please consider this as a “please = check”.   Kathleen and Stephen are focused on this work. =

------=_NextPart_000_001C_01D269D9.51F8DF50-- From nobody Mon Jan 9 10:44:25 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0301289C4; Mon, 9 Jan 2017 10:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1AnkEnZlX6j; Mon, 9 Jan 2017 10:44:23 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 60C141204D9; Mon, 9 Jan 2017 10:44:20 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id x2so70112613itf.1; Mon, 09 Jan 2017 10:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E1N214CS7abHw2jmCCHzqMzr2jNgY2VxRmGxcqRT2Go=; b=uQ7GrbTBP6grt6o2YxMk5DDKZOFz016nAOoUgBnc5hrP56CQr1kWlXr8NVinH5ZzE3 EWciTekP84v5FzEEP7HWrtIRjdgDizc+oaDzXfpgFcMrS1HyPncTXb5N2GyWdtgsilgm EyXDBKZAi4ylFYdgHR1rrt/EQXF8jBtVAOxEXVn2X8CKZd1wXktVXaQlAGZ50GwbijXk HMZgn0DYA1Ab9U/dWkDGhzNiDVnq5NjVsOGEbFq21vKsVUMQLWTjRKXzfQwIlpWT6w7D ZP6bg0X+eKfEae6YCrCtLCYkvn/acklVpud586/PxJtYiQ7W4q9dzDKu5jYmLuYAEPyw uElQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E1N214CS7abHw2jmCCHzqMzr2jNgY2VxRmGxcqRT2Go=; b=uUOp+9FQKxo/2hnmljazGOdNb+2RVsm46xTN93XatKfiFyx1V+va+iwIhAK3qQoItD ahpF6tuybiRgEZ0jzNQjNU2cByY4OwtIkzH2LhLx5YkYR2PXC9xOetnJS1w8y5w7HHpO UJw2BfJ/zwFlDtrNOnDu/mdVN94g2ByAQfbWYYIuLfyLDhz5tOGBY++jHsY0RQxy+U4u KG3sfU4XfEHyUivfzU/nfgnkq2JeWFEcGzk8q7T9pgga5XmkAxdoTzKg80b81nYwYLWZ uEOZLOp84N7kMhZTLiS+WLtZBebexTXGKtXMDfuf74MVkyhs54RntAv5HiIhUo+9C5PF tOuw== X-Gm-Message-State: AIkVDXLAeKuom2eEVFl4tng8KQTeJ6IKwFZGMuLIi+zIFGd4LuCA/HUrHIk1tsOBSoXdfdVuX1nB5owIKcwoaw== X-Received: by 10.36.212.66 with SMTP id x63mr9474336itg.14.1483987459670; Mon, 09 Jan 2017 10:44:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.136 with HTTP; Mon, 9 Jan 2017 10:44:04 -0800 (PST) In-Reply-To: <148394930213.32546.3663932860006838464.idtracker@ietfa.amsl.com> References: <148394930213.32546.3663932860006838464.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 9 Jan 2017 13:44:04 -0500 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-trill-directory-extensions@ietf.org, Alia Atlas Subject: Re: [trill] I-D was expired X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 18:44:25 -0000 This draft contained material on extending Pull Directories so that they could be hosted by end stations and used by end stations. The material was moved into draft-ietf-trill-directory-assist-mechanisms so it was intended to allow this draft to expire. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jan 9, 2017 at 3:08 AM, I-D Expiring System wrote: > was just expired. > This draft is in the state "I-D Exists" in the ID Tracker. > > > Thanks, > IETF Secretariat. From nobody Tue Jan 10 18:20:37 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D75B1293DF; Tue, 10 Jan 2017 18:20:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148410123524.22226.813112745895699147.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 18:20:35 -0800 Archived-At: Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-rfc6439bis-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:20:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL: Appointed Forwarders Authors : Donald Eastlake Yizhou Li Mohammed Umair Ayan Banerjee Fangwei Hu Filename : draft-ietf-trill-rfc6439bis-04.txt Pages : 44 Date : 2017-01-10 Abstract: TRILL supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders", with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and obsoletes RFC 6439. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-rfc6439bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-rfc6439bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 10 18:32:54 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2291295CC for ; Tue, 10 Jan 2017 18:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_JMk10-vEU2 for ; Tue, 10 Jan 2017 18:32:52 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 656F712940B for ; Tue, 10 Jan 2017 18:32:52 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id j13so65403867iod.3 for ; Tue, 10 Jan 2017 18:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qiXByoq8HT6BlXRR4ytOz4YyykBEfI2/NkJBWHcA4gQ=; b=DhJB9XTd+xw3DWdW/3XHiZFq0hoTgwFmeliWD10Iwevo35pqNzgwOnbZGJ+nzGIwl7 UETfEprCYsX28DA3KE87bP4k7B7VmXV70/4tNiDancN6X/7kIwYaKRvEIImRKVeD3XWu Z013RrcFexaF/eE/8FoNIRldlFRPzZDJf+0eCpQCz+NB0zXp7SCh50ULGu0rZFbte3uq FHPahlBQuNSAY72UhRxEM3RAElJzICMl2lngNGm9yd6BGg0i7ZB2G/X7/CN2z6RvP/1W 9oJjP+8xDvUZF1FLSaaKQIlpxr6DrciJ5JWyjw1QhYhQrkdo6ThFAl6ER6/YnsJU8Tf/ +vPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qiXByoq8HT6BlXRR4ytOz4YyykBEfI2/NkJBWHcA4gQ=; b=U7JTwZZobIc+xJUnbnsPl1v00WMV9Rw/mZE4xd5AvQt1t5F/7rLBQ/yMB1reppMSMa XUi4weTpO+2XDcaiftyj/P7hFttw2y5AqhgliH/yrwmn9y+99nF8G+CJPYVUn8baa640 9LoIv/iiZvouTEc2cV2YZbq916JStb1lRonO/t7mnLbtGEH0FsVXzosW6QIYAO8E9lDz JpZZ9GvjtDlqTWSdDkbqN8L8GwrCOSc4ZR+jKsEUCDTxT1u4tH3v/lZ2CatA1RZ8f2ay huhWqXaNA7bOJ73tML2+ULU7zZdEy/CvZlpfj97syhB6/NXto3XubpmOS3V7kr5FAxSb m7xA== X-Gm-Message-State: AIkVDXJn7yHnjPPLJsDh97srFe/VnaN48UybU558BpDcvGgZDdE9HHmsNhG5NAcweUOtVfQTOKjvihYJoIVdsQ== X-Received: by 10.107.141.80 with SMTP id p77mr3749624iod.97.1484101971266; Tue, 10 Jan 2017 18:32:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Tue, 10 Jan 2017 18:32:35 -0800 (PST) In-Reply-To: <148410123524.22226.813112745895699147.idtracker@ietfa.amsl.com> References: <148410123524.22226.813112745895699147.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 10 Jan 2017 21:32:35 -0500 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [trill] I-D Action: draft-ietf-trill-rfc6439bis-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:32:53 -0000 This revision has two updated references and some very minor changes in response to a Security Directorate review. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jan 10, 2017 at 9:20 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. > > Title : TRILL: Appointed Forwarders > Authors : Donald Eastlake > Yizhou Li > Mohammed Umair > Ayan Banerjee > Fangwei Hu > Filename : draft-ietf-trill-rfc6439bis-04.txt > Pages : 44 > Date : 2017-01-10 > > Abstract: > TRILL supports multi-access LAN (Local Area Network) links where a > single link can have multiple end stations and TRILL switches > attached. Where multiple TRILL switches are attached to a link, > native traffic to and from end stations on that link is handled by a > subset of those TRILL switches called "Appointed Forwarders", with > the intent that native traffic in each VLAN be handled by at most one > TRILL switch. This document clarifies and updates the Appointed > Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and > obsoletes RFC 6439. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-trill-rfc6439bis-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-rfc6439bis-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Thu Jan 12 08:04:33 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2021F12940D; Thu, 12 Jan 2017 08:04:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 08:04:25 -0800 Archived-At: Cc: dromasca@gmail.com, draft-ietf-trill-rfc6439bis.all@ietf.org, ietf@ietf.org, trill@ietf.org Subject: [trill] Review of draft-ietf-trill-rfc6439bis-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 16:04:25 -0000 Reviewer: Dan Romascanu Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document clarifies and updates the TRILL Appointed Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and obsoletes RFC 6439. It's a complex document which requires extra reading to understand the context and the interraction with other RFCs. I believe that from an OPS-DIR perspective there are issues that need to be discussed before the document can be approved. The main issues with the document in its current form are: 1. The document makes consistent changes in the way TRILL operates. It replaces TLVs and procedures, define new ones, obsoletes previous mechanisms that define VLAN mapping, and incorporates updated material from other RFCs. There is however no indication in the text about the transition between existing deployed versions of TRILL based on RFC 6439 and related protocols with the current updated mechanisms. Are these backward compatible? Do they need a simultaneous upgrade of the whole network? 2. The document lacks a section or even minimal text concerning operational and manageability considerations. There are several mentions in the text concerning network managers or operator actions, but there is no indication or reference to what management protocols and data models are to be used for configuration, retrieval of operational status information, or alerts. I believe that these need to be added explicitly or by reference. From nobody Thu Jan 12 10:24:00 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD959128AB0; Thu, 12 Jan 2017 10:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9hyYOosLN4X; Thu, 12 Jan 2017 10:23:56 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 AE8B3129410; Thu, 12 Jan 2017 10:23:56 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id r185so19719380ita.0; Thu, 12 Jan 2017 10:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WXRGBrOPYPCn3C9Y/ddxWPk7vQHrriTmmBtYUPaUR8c=; b=HonnU5Eh8NBnnI5aXMiXQCBOYwegMzMOWZ1vs8y4XTiyZmhw4PAtqVdUWJ/ei+TSql +6/mseDN3Bd/nvIP7a3HnXiTvPD5g/eKZph1j/H4mcau+qbbMcgHnClAn+MDR8OoFciB 5paCdl7nKmG/nb3Cpuh/fl3U+/YYUoAz/XMGzMGnm8GksQQiTl07l79UtMPshMlN2bxY sIgrwcQ8JGHVHQzsRXvZCIsBfhn0y2nc408F8kYLWcSL8mQhaVuUehXb/1Dg2LnPIhrO n41aMahUkWh1kDSvhy6bwAleb9EdgHtnwY4a0H3XgT+bn5Opu8ESDljSIQma7gkgV2Cm /24Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WXRGBrOPYPCn3C9Y/ddxWPk7vQHrriTmmBtYUPaUR8c=; b=txag4cGPExRVG136/kEyiJikKexalZE2TkMxvjVdYtr5pUqQz70UUUnVX2Jc5/0OMP 4WH/U4AsJJt0EaE6WM/oF+jh48US2KJiudMJ9GEwi+wA++blAIRIsWE8tBUyWrGKzb0h 82Bd+5suYLc43B/QUzFPlGdWuvb8X4j8vMf5ZP12elDeZsTgFAkBhUOS21MVEBAnj9oP 0AXgYBEVuQuwgjLyRmMPug/pwZD89nCuQ+VbSOIMtO7HgNh04A2oht/Or1SA9dIrlpdy +eorXIj4NfRrVc6g7GNZlB67n64hAtoHZANY6uVMUPNwWGFlQosY+0DCjSwMUtx7ezDk aF9w== X-Gm-Message-State: AIkVDXI6t4a6rFC5u2TtY0N2uJ0bxapmkt37C0O7W82W6pMURRDcabd1bOb3cxbN2Oa/pTxqQxqaeP1eTpZlAg== X-Received: by 10.36.117.148 with SMTP id y142mr5892937itc.14.1484245435804; Thu, 12 Jan 2017 10:23:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Thu, 12 Jan 2017 10:23:40 -0800 (PST) In-Reply-To: <001b01d26a03$3ac96910$b05c3b30$@ndzh.com> References: <001b01d26a03$3ac96910$b05c3b30$@ndzh.com> From: Donald Eastlake Date: Thu, 12 Jan 2017 13:23:40 -0500 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Linda Dunbar , draft-ietf-trill-directory-assist-mechanisms@ietf.org, Radia Perlman , Liyizhou , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-directory-assist-mechanism-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:23:59 -0000 Hi Sue, Thanks for the review. On Sun, Jan 8, 2017 at 6:02 PM, Susan Hares wrote: > Donald, Yizhou, Linda, and Radia: > > Thank you for your work on draft-ietf-trill-directory-assist-mechanisms. > Each draft improves the readability and nails down some of the potential > edge cases. I believe we are nearing the end of this journey toward IES= G > approval. I am joining with you on this journey by doing a shepherd revie= w > at the end of IETF LC. > > > Status: Ready to publication, with some editorial nits you should conside= r > > > > Here=E2=80=99s my editorial nits on the latest version. Please address = #2 =E2=80=93 that > deals with the =E2=80=9CSEND=E2=80=9D functionality and #6 > > > #1, p. 5 paragraph 1, list item 3. =E2=80=93 simple spelling error > > Old:/MAC addresses =E2=80=9Cnomrally=E2=80=9D / > New: /MAC Addresses normally/ OK. > #2. p. 17-22 =E2=80=93 section 3 > > #2.a Overall =E2=80=93 I think you need to include SEND messages in this = Query > messages. OK. > #2.b p17, section 3.0 paragraph 5 specific text change > > Old:/The requests to Pull Directory servers are typically derived from > ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or > data frames with unknown unicast destination MAC addresses, intercepted b= y > an ingress TRILL switch as described in Section 1.1/ > > New:/ The requests to Pull Directory servers are typically derived from A= RP > [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or data > Layer 2 frames with unknown unicast destination MAC addresses intercepted= by > an ingress TRILL switch as described in Section 1.1/ > > Reason: SEND mechanisms need to be clearly specified in the draft. Sures= h > Krishnan mentioned this on the ARP optimization draft. OK. > #3 p. 19, section 3.2.1 paragraph 1, sentence 3 > > Old: /The priority of the channel message is a mapping of the > priority of the frame being ingressed that caused the query with the > default mapping depending, per Data Label, on the strategy (see > Section 4) or a configured priority (DirGenQPriority, Section 3.9) > for generated queries./ > > New:/ The priority of the channel message is a mapping of the > priority of the ingress frame which caused the query combined with the > default mapping per Data Label depending on the strategy for generated > queries (see Section 4) or a configured priority (DirGenQPriority, > Section 3.9/. > > Reason: Clarify sentences. I agree this could use clarification. How about: The priority of the channel message is a mapping of the priority of the ingressed frame that caused the query. The default mapping depends, per Data Label, on the strategy (see Section 4) or a configured priority (DirGenQPriority, Section 3.9) for generated queries. > #4, p. 33 section 3.5.1 paragraph 3 > > Old:/ The Bridge shown might be a complex bridged LAN or might be absent > if, as shown for End Station 1, End Station 2 was dual ported with > point-to-point Ethernet links to RB1 and RB2./ > > New:/The Bridge shown might be a complex bridged LAN, a LAN without a bri= dge > (as shown in End station 1), or connected via point-to-point links (as sh= own in > End Station 2=E2=80=99s which is connected through a bridge with point-to= -point > Ethernet links to > RB1 and RB2./ > > Reason: Clarify the sentences OK. > #5, p. 33 section 3.5.1 paragraph 4 sentence 1. > > Old:./ > Because an indirect Pull Directory server discards information it has > cached from queries to an end station Pull Directory server if it > loses adjacency to that server (Section 3.7), if it knowns that such > information may be cached at RBridge clients and has no other source > for the information, it MUST send Update Messages to those clients > withdrawing the information/ > > New: /Since an indirect Pull Directory server discards information it has > cached from queries to an end station Pull Directory server if it > loses adjacency to the server (Section 3.7), if it detects that > information may be cached at RBridge clients and has no other source > for the information, it MUST send Update Messages to those clients > withdrawing the information/ > > Words changed =E2=80=93 in bold > > Why: anthropomorphism =E2=80=93 TRILL switches do not know. TRILL switch= es detect > based on logic. > > Why: Because/since =E2=80=93 both indicate causes, but =E2=80=9Csince=E2= =80=9D seems to indicate an > ordering that this paragraph suggests. OK. > #6: p. 43, 4th paragraph beginning with Although some =E2=80=A6 > > Current text: > /Although some of the ports sending TRILL ES-IS PDUs are on end > stations and thus not on routers (TRILL switches), they nevertheless > may make use of the Router Capability (#242) and MT-Capability (#222) > IS-IS TLVs to indicate capabilities as elsewhere specified./ > > It would be good to indicate where these capabilities are specified. OK, we can add a reference to RFC 7176 > #7 p. 44, section 6 =E2=80=93 Security considerations > > After the SEC-DIR review comes in, consider if the end-system engage > requires some extra text on privacy related to the end-systems. > > Since Donald and Radia are much better at all types of security, please > consider this as a =E2=80=9Cplease check=E2=80=9D. Kathleen and Stephen= are focused on > this work. We could add something about edge RBridges being more aware of what IP addresses are being used. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri Jan 13 10:55:36 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61B129D7E; Fri, 13 Jan 2017 10:55:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148433373529.9748.4971789075908563298.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 10:55:35 -0800 Archived-At: Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-directory-assist-mechanisms-11.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:55:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL: Edge Directory Assist Mechanisms Authors : Donald Eastlake Linda Dunbar Radia Perlman Yizhou Li Filename : draft-ietf-trill-directory-assist-mechanisms-11.txt Pages : 53 Date : 2017-01-13 Abstract: This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi- destination traffic, particularly ARP/ND and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-directory-assist-mechanisms-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 13 11:00:14 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0091A129D80; Fri, 13 Jan 2017 11:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8zgbt8KmQLk; Fri, 13 Jan 2017 11:00:10 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 43B771294B1; Fri, 13 Jan 2017 11:00:10 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id r185so44259450ita.0; Fri, 13 Jan 2017 11:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=X8BS2umjnItP0jnRfZtXQ0ExMkSPmiSjDYzNwJbGifk=; b=jN+a+TkeQsnBhnSH3mcXBWQRPVNIQNXeWBETihgJNLHgpdUglKkDXgzwbA3mANKNcI kXEcNOAxxjeHjfZuE3Djet70JoGLcAmZeEuejZavBwmMT18rL1bSVfJuObs++ZBbLlet jIzqFb1mUoWAfvXwn4WueG5l+UZDvH5ijNO9kyJVZXwHe2zRT1X+zX4yULt0px8rxrFt zpaFo8efVBIAgVEPvAO4K8joXx9WGpZnj3KUc7vBJUF4jMHwz8Qetab0c5EiKXDrtsV+ pwjF1gSdNF4qiafStA5PI/DqxJoZAg8s9cSn3+Oh1IIWaXukc1ZdFLlchqPcY7rkC5vp v7eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=X8BS2umjnItP0jnRfZtXQ0ExMkSPmiSjDYzNwJbGifk=; b=jnzxCfShUpMWGJBh1ZcqqVlHF3THKlVT+jHFw/VfUdu8TDhXGmpdi9SI/T4UvICWbt +ykeF+vLGqI4/HBb1THdZZzakXqQNycNz+RaT5IZ/lT1DleWXRsaf3EfuR1dMoUvNNBO 9kK94UBLsLO/t/Vr3Rx2MJcKyCkbTXhwC33TJqrEI68HeqgEHhASPugOQaiatDG+mKfd FURo0npVX6oEa+Ok4lxv45VVJY50SLU+3RKhg9k3LLRrbB3VSvkFKuBqoSat+z+98dpV 4qdrmP9+3FaXnbA8ERxa5IjSuFrRaDKQr5tE83HoFvgHRumQODiwzZIaXdI8LkLqV3i2 84kg== X-Gm-Message-State: AIkVDXLlrNXy0o3+1gx0+TNBjrtisOPTiSXT4w3ce7/7Dc6OWfv8/0pSY43n8Y9lRfMr84krJ4iK7zNa4D1Iww== X-Received: by 10.36.96.70 with SMTP id i67mr3875920itc.59.1484334009388; Fri, 13 Jan 2017 11:00:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Fri, 13 Jan 2017 10:59:53 -0800 (PST) In-Reply-To: References: <001b01d26a03$3ac96910$b05c3b30$@ndzh.com> From: Donald Eastlake Date: Fri, 13 Jan 2017 13:59:53 -0500 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Linda Dunbar , draft-ietf-trill-directory-assist-mechanisms@ietf.org, Radia Perlman , Liyizhou , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-directory-assist-mechanism-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:00:13 -0000 Hi Sue, The -11 version just posted is intended to resolve your comments. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Jan 12, 2017 at 1:23 PM, Donald Eastlake wrote: > Hi Sue, > > Thanks for the review. > > On Sun, Jan 8, 2017 at 6:02 PM, Susan Hares wrote: >> Donald, Yizhou, Linda, and Radia: >> >> Thank you for your work on draft-ietf-trill-directory-assist-mechanisms. >> Each draft improves the readability and nails down some of the potential >> edge cases. I believe we are nearing the end of this journey toward IE= SG >> approval. I am joining with you on this journey by doing a shepherd revi= ew >> at the end of IETF LC. >> >> >> Status: Ready to publication, with some editorial nits you should consid= er >> >> >> >> Here=E2=80=99s my editorial nits on the latest version. Please address= #2 =E2=80=93 that >> deals with the =E2=80=9CSEND=E2=80=9D functionality and #6 >> >> >> #1, p. 5 paragraph 1, list item 3. =E2=80=93 simple spelling error >> >> Old:/MAC addresses =E2=80=9Cnomrally=E2=80=9D / >> New: /MAC Addresses normally/ > > OK. > >> #2. p. 17-22 =E2=80=93 section 3 >> >> #2.a Overall =E2=80=93 I think you need to include SEND messages in this= Query >> messages. > > OK. > >> #2.b p17, section 3.0 paragraph 5 specific text change >> >> Old:/The requests to Pull Directory servers are typically derived from >> ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or >> data frames with unknown unicast destination MAC addresses, intercepted = by >> an ingress TRILL switch as described in Section 1.1/ >> >> New:/ The requests to Pull Directory servers are typically derived from = ARP >> [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or dat= a >> Layer 2 frames with unknown unicast destination MAC addresses intercepte= d by >> an ingress TRILL switch as described in Section 1.1/ >> >> Reason: SEND mechanisms need to be clearly specified in the draft. Sure= sh >> Krishnan mentioned this on the ARP optimization draft. > > OK. > >> #3 p. 19, section 3.2.1 paragraph 1, sentence 3 >> >> Old: /The priority of the channel message is a mapping of the >> priority of the frame being ingressed that caused the query with the >> default mapping depending, per Data Label, on the strategy (see >> Section 4) or a configured priority (DirGenQPriority, Section 3.9) >> for generated queries./ >> >> New:/ The priority of the channel message is a mapping of the >> priority of the ingress frame which caused the query combined with th= e >> default mapping per Data Label depending on the strategy for generate= d >> queries (see Section 4) or a configured priority (DirGenQPriority, >> Section 3.9/. >> >> Reason: Clarify sentences. > > I agree this could use clarification. How about: > > The priority of the channel message is a mapping > of the priority of the ingressed frame that caused the query. > The default mapping depends, per Data Label, on the strategy > (see Section 4) or a configured priority (DirGenQPriority, Section > 3.9) for generated queries. > >> #4, p. 33 section 3.5.1 paragraph 3 >> >> Old:/ The Bridge shown might be a complex bridged LAN or might be absent >> if, as shown for End Station 1, End Station 2 was dual ported with >> point-to-point Ethernet links to RB1 and RB2./ >> >> New:/The Bridge shown might be a complex bridged LAN, a LAN without a br= idge >> (as shown in End station 1), or connected via point-to-point links (as s= hown in >> End Station 2=E2=80=99s which is connected through a bridge with point-t= o-point >> Ethernet links to >> RB1 and RB2./ >> >> Reason: Clarify the sentences > > OK. > >> #5, p. 33 section 3.5.1 paragraph 4 sentence 1. >> >> Old:./ >> Because an indirect Pull Directory server discards information it has >> cached from queries to an end station Pull Directory server if it >> loses adjacency to that server (Section 3.7), if it knowns that such >> information may be cached at RBridge clients and has no other source >> for the information, it MUST send Update Messages to those clients >> withdrawing the information/ >> >> New: /Since an indirect Pull Directory server discards information it ha= s >> cached from queries to an end station Pull Directory server if it >> loses adjacency to the server (Section 3.7), if it detects that >> information may be cached at RBridge clients and has no other sourc= e >> for the information, it MUST send Update Messages to those clients >> withdrawing the information/ >> >> Words changed =E2=80=93 in bold >> >> Why: anthropomorphism =E2=80=93 TRILL switches do not know. TRILL switc= hes detect >> based on logic. >> >> Why: Because/since =E2=80=93 both indicate causes, but =E2=80=9Csince=E2= =80=9D seems to indicate an >> ordering that this paragraph suggests. > > OK. > >> #6: p. 43, 4th paragraph beginning with Although some =E2=80=A6 >> >> Current text: >> /Although some of the ports sending TRILL ES-IS PDUs are on end >> stations and thus not on routers (TRILL switches), they nevertheless >> may make use of the Router Capability (#242) and MT-Capability (#222) >> IS-IS TLVs to indicate capabilities as elsewhere specified./ >> >> It would be good to indicate where these capabilities are specified. > > OK, we can add a reference to RFC 7176 > >> #7 p. 44, section 6 =E2=80=93 Security considerations >> >> After the SEC-DIR review comes in, consider if the end-system engage >> requires some extra text on privacy related to the end-systems. >> >> Since Donald and Radia are much better at all types of security, please >> consider this as a =E2=80=9Cplease check=E2=80=9D. Kathleen and Stephe= n are focused on >> this work. > > We could add something about edge RBridges being more aware of what IP > addresses are being used. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Fri Jan 13 15:18:28 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F84129F2D for ; Fri, 13 Jan 2017 15:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 3QBYwrE3LTNN for ; Fri, 13 Jan 2017 15:18:26 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 35A10129F29 for ; Fri, 13 Jan 2017 15:18:26 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: References: <001701d26df2$8a8d1260$9fa73720$@ndzh.com> In-Reply-To: <001701d26df2$8a8d1260$9fa73720$@ndzh.com> Date: Fri, 13 Jan 2017 18:14:30 -0500 Message-ID: <002701d26df2$cc24e950$646ebbf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01D26DC8.E34FF2C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKgem2ltJb30I9VsAjpsNDFlzUKdp+a8KkQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [trill] FW: Mail regarding draft-ietf-trill-mtu-negotiation X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 23:18:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0028_01D26DC8.E34FF2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Forwarding to trill mailing list. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, January 13, 2017 6:13 PM To: draft-ietf-trill-mtu-negotiation@ietf.org Cc: draft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; 'Donald Eastlake'; 'Mingui Zhang' Subject: Mail regarding draft-ietf-trill-mtu-negotiation Minqui, Xudong, Donald, Radia, and Somnath: In double checking the draft-ietf-trill-mtu-neogitation-05.txt before sending it to the IESG, I found 2 spelling errors and 2 places were the sentence grammar could be improved. These are listed below. Alia has reviewed this draft so these changes can be taken care of after Alia has reviewed again the text. Page 8, #2 leaving, #a sentence 3, #b sentence 2 - spelling error Old:/orgiatingL1LSPBufferSize/ New:/originatingL1LSPBuffer Size/ Page 9, section 5, line 3 OLD /that port SHOULD be disabled and, in any case, an adjacency cannot be formed/ New1 /that port SHOULD be disable since in any case an adjacency cannot be formed/ New2 /that port SHOULD be disabled since, in any case, an adjacency cannot be formed/ You can use either one of the NEWs Page 9, section 6, paragraph 2, line 2 Old/but are processed normally if received larger than that./ New/but are processed normally if received larger than that size./ I asked for IESG publication as you will probably get more editorial comments. Sue Hares Shepherd ------=_NextPart_000_0028_01D26DC8.E34FF2C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forwarding to trill mailing list. =

 

Sue =

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, January = 13, 2017 6:13 PM
To: = draft-ietf-trill-mtu-negotiation@ietf.org
Cc: = draft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; = 'Donald Eastlake'; 'Mingui Zhang'
Subject: Mail regarding = draft-ietf-trill-mtu-negotiation

 

Minqui, = Xudong, Donald, Radia, and Somnath:

 

In double = checking the draft-ietf-trill-mtu-neogitation-05.txt before sending it = to the IESG, I found 2 spelling errors and 2 places were the sentence = grammar could be improved. These are listed below.  Alia has = reviewed this draft so these changes can be taken care of after Alia has = reviewed again the text.

 

Page 8, #2 = leaving, #a sentence 3,  #b sentence 2 – spelling error =

 

Old:/orgiatingL1LSPBufferSize/ = New:/originatingL1LSPBuffer Size/

 

Page 9, = section 5, line 3

OLD  /that = port SHOULD be disabled and, in any case, an adjacency cannot be formed/ =

New1 /that port SHOULD be disable = since in any case an adjacency cannot be formed/

New2 /that port SHOULD be disabled since, in any case, = an adjacency cannot be formed/

 

You can use = either one of the NEWs

 

Page 9, = section 6, paragraph 2, line 2

 

Old/but are = processed normally if received larger than that./

New/but are processed normally if received larger than = that size./

 

I asked for IESG publication as you will probably get = more editorial comments.

 

Sue = Hares

Shepherd =  

------=_NextPart_000_0028_01D26DC8.E34FF2C0-- From nobody Fri Jan 13 16:20:40 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984701295D9 for ; Fri, 13 Jan 2017 16:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 xPwSkHlPWiTF for ; Fri, 13 Jan 2017 16:20:37 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9EDFC1293E8 for ; Fri, 13 Jan 2017 16:20:37 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Fri, 13 Jan 2017 19:16:41 -0500 Message-ID: <00b901d26dfb$7bee9d60$73cbd820$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01D26DD1.931A6A20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJt+2S/+Ovyvd7ORr6DNHwmJWiWuA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , mohamed.boucadair@orange.com, 'Radia Perlman' , 'Liyizhou' , linda.dunbar@huawei.com Subject: [trill] draft-ietf- X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 00:20:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BA_01D26DD1.931A6A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Forwarding to trill list this conversation. It appears I missed sending this last weekend.=20 =20 Sue=20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Saturday, January 7, 2017 8:59 PM To: 'Donald Eastlake'; 'Liyizhou'; linda.dunbar@huawei.com; 'Radia = Perlman'; 'Mohammed Umair' Cc: 'Alia Atlas' Subject: Donald Eastlake=20 =20 Donald, Yizhou, Linda, Radia, and Mohammed:=20 =20 I reviewed the TRILL ARP/ND optimization this evening (after my head = finally clear from allergies). I do not believe you have answered Suresh = Krishnan=92s issues about SEND clearly. I see 80% of the logic, but no place where = you clearly indicate when SEND should be used. I think you have answered = 90% of Alvaro=92s concerns, but I=92m concerned that without specific = references to SEND and clear indication about the SEND messages.=20 =20 Here=92s a set of changes that I think might work to resolve. =20 =20 Cheerily,=20 =20 Sue=20 =20 ---------- =20 #1=20 Page 5 =96 section 4, title =20 Old:/ Handling ARP/ND messages/ New:/Handling ARP/ND/SEND messages/ =20 #2 =96 change paragraph #3 =96 to add SEND=20 /in ND/ to /in ND and SEND/ =20 #3 =96 Could you as section 4.1, a short description about send that includes:=20 1) Why Send is needed,=20 2) How send interacts with ND,=20 3) Intermixing Topology =96 is this topology allowed =20 SEND =DF=E0 RBRIDGE ------RBRDGE =DF=E0ND=20 =20 [IMHO =96 this is a.2 or could be part of a.5]=20 =20 4) When SEND should be used=20 =20 #3 =96 Could you add a section 4.2 =96 1 paragraph that indicates why or = why not the RBRIDGE would verify the address.=20 =20 #4 =96 section 4.1 (change to section 4.3)=20 Add send by OLD%ARP/ND% to New%ARP/ND/SEND%=20 =20 #5 =96 section 4.2 (change to section 4.4)=20 =20 5.1 Paragraph 2, item a)=20 =20 change ARP/ND request to ARP/ND/SEND request=20 Change a.2 from ARP/ND to ARP/ND/SEND=20 Change a.5 from ARP/ND to ARP/ND/Send request=20 =20 5.2 paragraph 3 =96 item b) =20 Change sentence 1: Old% ARP/ND% New% ARP/ND/SEND% Change sentence 3 end=20 Old:/target=92s private key and only action b.1/ New/target=92s private key therefore only action b.1/=20 =20 5.2 paragraph 4 =96 item c) Change sentence 1: OLD%ARP/ND% NEW%ARP/ND/SEND% =20 5.3 paragraph 5) item d)=20 Include in the DAD [RFC4862] the ND and SEND version=20 =20 #6 =96 describe what happens if SEND CGA option does not exist in send, = or fails =20 This can be a new section or a re-written section 7 or a sub-section to section 7. =20 Describe what happens SEND CGA exists, does not exist, or fails due to = the wrong key. =20 This could also go in a revised section 4.1=20 =20 Section 8 =96 expand this to include the SEND functionality. =20 =20 Thanks=20 =20 =20 =20 ------=_NextPart_000_00BA_01D26DD1.931A6A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Forwarding to trill list this conversation.=A0 = It appears I missed sending this last weekend.

 

Sue =

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Saturday, January = 7, 2017 8:59 PM
To: 'Donald Eastlake'; 'Liyizhou'; = linda.dunbar@huawei.com; 'Radia Perlman'; 'Mohammed Umair'
Cc: = 'Alia Atlas'
Subject: Donald Eastlake =

 

Donald, = Yizhou, Linda, Radia, and Mohammed:

 

I reviewed = the TRILL ARP/ND optimization this evening (after my head finally clear = from allergies).  I do not believe you have answered Suresh = Krishnan’s issues about SEND clearly.   I see 80% of the = logic, but no place where you clearly indicate when SEND should be = used.   I think you have answered 90% of Alvaro’s = concerns, but I’m concerned that without specific references to = SEND and clear indication about the SEND = messages.

 

Here’s = a set of changes that I think might work to resolve.  =A0=A0=A0

 

Cheerily, =

 

Sue

 

----------

 

#1 =

Page 5 – section 4, = title

 

Old:/ Handling ARP/ND messages/

New:/Handling ARP/ND/SEND messages/

 

#2 – = change paragraph #3 – to add SEND

         &= nbsp;      /in ND/ to  /in ND and = SEND/

 

#3 – Could you as section 4.1,  a short = description about send that includes:

1)      = Why Send is needed,

2)      = How send interacts with ND,

3)      = Intermixing Topology – is this topology = allowed

 

SEND =DF=E0 RBRIDGE ------RBRDGE =DF=E0ND

      

[IMHO – this = is a.2 or could be part of a.5]

 

4)      = When SEND should be used

 

#3 – = Could you add a section 4.2 – 1 paragraph that indicates why or = why not the RBRIDGE would verify the address.

 

#4 – = section 4.1 (change to section 4.3)

         &= nbsp;      Add send by OLD%ARP/ND% to = New%ARP/ND/SEND%

 

#5 – = section 4.2 (change to section 4.4)

 

5.1 = Paragraph 2, item a)

 

change = ARP/ND request to  ARP/ND/SEND request

Change a.2 from ARP/ND to ARP/ND/SEND =

Change a.5 from ARP/ND to = ARP/ND/Send request

 

5.2 = paragraph 3 – item b)  

Change sentence 1:   Old% ARP/ND%  New% = ARP/ND/SEND%

Change sentence 3 end =

Old:/target’s private key and = only action b.1/

New/target’s = private key therefore only action b.1/

 

5.2 = paragraph 4 – item c)

Change = sentence 1:  OLD%ARP/ND% NEW%ARP/ND/SEND%

 

5.3 = paragraph 5) item d)

Include in the = DAD [RFC4862] the ND and SEND version

 

#6 – = describe what happens if SEND CGA option does not exist in send, or = fails

 

This can be a new section or a re-written section 7 or = a sub-section to section 7.

 

Describe = what happens SEND CGA exists, does not exist, or fails due to the wrong = key.   

This could also go = in a revised section 4.1

 

Section 8 = – expand this to include the SEND functionality.  =

 

Thanks

 

 

 

------=_NextPart_000_00BA_01D26DD1.931A6A20-- From nobody Fri Jan 13 16:34:44 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8773B129FDD for ; Fri, 13 Jan 2017 16:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 7L0g4PVpsLMt for ; Fri, 13 Jan 2017 16:34:42 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 5D50A129FBA for ; Fri, 13 Jan 2017 16:34:42 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Fri, 13 Jan 2017 19:30:22 -0500 Message-ID: <00cf01d26dfd$71313750$5393a5f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01D26DD3.885BF2A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJt+7m8uRd+TKbATRegni8S8vWkNw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , shares@ndzh.com, 'Jon Hudson' Subject: [trill] draft-ietf-trill-arp-optimization WG Last Call (11/15 - 12/6) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 00:34:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D0_01D26DD3.885BF2A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The extension of this WG LC has completed, and there is WG consensus to send this back to the IESG. A revised ID is needed for editorial changes need to further clarify the SEND issues mentioned by Alvaro Retana and Suresh Krishanan. Sue Hares Co-chair TRILL Shepherd for draft ------=_NextPart_000_00D0_01D26DD3.885BF2A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = extension of this WG LC has completed, and there is WG consensus to send = this back to the IESG.   A revised ID is needed for editorial = changes need to further clarify the SEND issues mentioned by Alvaro = Retana and Suresh Krishanan.

 

Sue Hares =

Co-chair TRILL

Shepherd for draft

------=_NextPart_000_00D0_01D26DD3.885BF2A0-- From nobody Fri Jan 13 16:43:44 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7157E12957A for ; Fri, 13 Jan 2017 16:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 krt8YESCFWEZ for ; Fri, 13 Jan 2017 16:43:40 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 8731D1294EA for ; Fri, 13 Jan 2017 16:43:40 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Fri, 13 Jan 2017 19:39:44 -0500 Message-ID: <00dc01d26dfe$b3f36800$1bda3800$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01D26DD4.CB1EE6A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJt/qEeRDXjbkFHSnaNmsUQMopQxA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , akatlas@gmail.com Subject: [trill] draft-ietf-trill-arp-optimization WG Last Call (11/15 - 12/6) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 00:43:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DD_01D26DD4.CB1EE6A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-forwarding to get the right link to the WG LC. =20 Sue=20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Saturday, January 7, 2017 8:59 PM To: 'Donald Eastlake'; 'Liyizhou'; linda.dunbar@huawei.com; 'Radia = Perlman'; 'Mohammed Umair' Cc: 'Alia Atlas' Subject: Donald Eastlake=20 =20 Donald, Yizhou, Linda, Radia, and Mohammed:=20 =20 I reviewed the TRILL ARP/ND optimization this evening (after my head = finally clear from allergies). I do not believe you have answered Suresh = Krishnan=92s issues about SEND clearly. I see 80% of the logic, but no place where = you clearly indicate when SEND should be used. I think you have answered = 90% of Alvaro=92s concerns, but I=92m concerned that without specific = references to SEND and clear indication about the SEND messages.=20 =20 Here=92s a set of changes that I think might work to resolve. =20 =20 Cheerily,=20 =20 Sue=20 =20 ---------- =20 #1=20 Page 5 =96 section 4, title =20 Old:/ Handling ARP/ND messages/ New:/Handling ARP/ND/SEND messages/ =20 #2 =96 change paragraph #3 =96 to add SEND=20 /in ND/ to /in ND and SEND/ =20 #3 =96 Could you as section 4.1, a short description about send that includes:=20 1) Why Send is needed,=20 2) How send interacts with ND,=20 3) Intermixing Topology =96 is this topology allowed =20 SEND =DF=E0 RBRIDGE ------RBRDGE =DF=E0ND=20 =20 [IMHO =96 this is a.2 or could be part of a.5]=20 =20 4) When SEND should be used=20 =20 #3 =96 Could you add a section 4.2 =96 1 paragraph that indicates why or = why not the RBRIDGE would verify the address.=20 =20 #4 =96 section 4.1 (change to section 4.3)=20 Add send by OLD%ARP/ND% to New%ARP/ND/SEND%=20 =20 #5 =96 section 4.2 (change to section 4.4)=20 =20 5.1 Paragraph 2, item a)=20 =20 change ARP/ND request to ARP/ND/SEND request=20 Change a.2 from ARP/ND to ARP/ND/SEND=20 Change a.5 from ARP/ND to ARP/ND/Send request=20 =20 5.2 paragraph 3 =96 item b) =20 Change sentence 1: Old% ARP/ND% New% ARP/ND/SEND% Change sentence 3 end=20 Old:/target=92s private key and only action b.1/ New/target=92s private key therefore only action b.1/=20 =20 5.2 paragraph 4 =96 item c) Change sentence 1: OLD%ARP/ND% NEW%ARP/ND/SEND% =20 5.3 paragraph 5) item d)=20 Include in the DAD [RFC4862] the ND and SEND version=20 =20 #6 =96 describe what happens if SEND CGA option does not exist in send, = or fails =20 This can be a new section or a re-written section 7 or a sub-section to section 7. =20 Describe what happens SEND CGA exists, does not exist, or fails due to = the wrong key. =20 This could also go in a revised section 4.1=20 =20 Section 8 =96 expand this to include the SEND functionality. =20 =20 Thanks=20 =20 =20 =20 ------=_NextPart_000_00DD_01D26DD4.CB1EE6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-forwarding to get the right link to the WG = LC.

 

Sue =

From:= = Susan Hares [mailto:shares@ndzh.com] =
Sent: Saturday, January 7, 2017 8:59 PM
To: 'Donald = Eastlake'; 'Liyizhou'; linda.dunbar@huawei.com; = 'Radia Perlman'; 'Mohammed Umair'
Cc: 'Alia = Atlas'
Subject: Donald Eastlake =

 

Donald, = Yizhou, Linda, Radia, and Mohammed:

 

I reviewed = the TRILL ARP/ND optimization this evening (after my head finally clear = from allergies).  I do not believe you have answered Suresh = Krishnan’s issues about SEND clearly.   I see 80% of the = logic, but no place where you clearly indicate when SEND should be = used.   I think you have answered 90% of Alvaro’s = concerns, but I’m concerned that without specific references to = SEND and clear indication about the SEND = messages.

 

Here’s = a set of changes that I think might work to resolve.     

 

Cheerily, =

 

Sue

 

----------

 

#1 =

Page 5 – section 4, = title

 

Old:/ Handling ARP/ND messages/

New:/Handling ARP/ND/SEND messages/

 

#2 – = change paragraph #3 – to add SEND

         &= nbsp;      /in ND/ to  /in ND and = SEND/

 

#3 – Could you as section 4.1,  a short = description about send that includes:

1)      = Why Send is needed,

2)      = How send interacts with ND,

3)      = Intermixing Topology – is this topology = allowed

 

SEND =DF=E0 RBRIDGE ------RBRDGE =DF=E0ND

      

[IMHO – this = is a.2 or could be part of a.5]

 

4)      = When SEND should be used

 

#3 – = Could you add a section 4.2 – 1 paragraph that indicates why or = why not the RBRIDGE would verify the address.

 

#4 – = section 4.1 (change to section 4.3)

         &= nbsp;      Add send by OLD%ARP/ND% to = New%ARP/ND/SEND%

 

#5 – = section 4.2 (change to section 4.4)

 

5.1 = Paragraph 2, item a)

 

change = ARP/ND request to  ARP/ND/SEND request

Change a.2 from ARP/ND to ARP/ND/SEND =

Change a.5 from ARP/ND to = ARP/ND/Send request

 

5.2 = paragraph 3 – item b)  

Change sentence 1:   Old% ARP/ND%  New% = ARP/ND/SEND%

Change sentence 3 end =

Old:/target’s private key and = only action b.1/

New/target’s = private key therefore only action b.1/

 

5.2 = paragraph 4 – item c)

Change = sentence 1:  OLD%ARP/ND% NEW%ARP/ND/SEND%

 

5.3 = paragraph 5) item d)

Include in the = DAD [RFC4862] the ND and SEND version

 

#6 – = describe what happens if SEND CGA option does not exist in send, or = fails

 

This can be a new section or a re-written section 7 or = a sub-section to section 7.

 

Describe = what happens SEND CGA exists, does not exist, or fails due to the wrong = key.   

This could also go = in a revised section 4.1

 

Section 8 = – expand this to include the SEND functionality.  =

 

Thanks

 

 

 

------=_NextPart_000_00DD_01D26DD4.CB1EE6A0-- From nobody Fri Jan 13 17:06:59 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32EF129561; Fri, 13 Jan 2017 17:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 xjhWOUjYQoRB; Fri, 13 Jan 2017 17:06:56 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 79212129546; Fri, 13 Jan 2017 17:06:56 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Fri, 13 Jan 2017 20:03:01 -0500 Message-ID: <00fe01d26e01$f4638070$dd2a8150$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FF_01D26DD8.0B8E14B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJuAXCh5gcKq6oOQuaDKcP9q/hPXw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , trill-chairs@ietf.org Subject: [trill] draft-ietf-trill-over-ip WG Last Call (11/15 - 12/6) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:06:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FF_01D26DD8.0B8E14B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This extended WG LC has completed and the WG LC has reached consensus on this draft. A revised ID should be created to handle: 1) Radia Perlman's comments https://www.ietf.org/mail-archive/web/trill/current/msg07621.html 2) Lucy Yong's comments https://www.ietf.org/mail-archive/web/trill/current/msg07629.html 3) Ines Robles comments https://www.ietf.org/mail-archive/web/trill/current/msg07622.html 4) Joe Touch's comments https://www.ietf.org/mail-archive/web/trill/current/msg07631.html The authors do not need to accept every comment, but to provide a revised draft based on this input. Sue Hares Shepherd/WG Co-chair ------=_NextPart_000_00FF_01D26DD8.0B8E14B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = extended WG LC has completed and the WG LC has reached consensus on this = draft.  A revised ID should be created to handle:

 

1)      = Radia Perlman’s comments

https://www.ietf.org/mail-archive/web/trill/curr= ent/msg07621.html

2)      = Lucy Yong’s comments

https://www.ietf.org/mail-archive/web/trill/current/msg07629.html

 

3)      = Ines Robles comments

https://www.ietf.org/mail-archive/web/trill/current/msg07622.html

4)      = Joe Touch’s comments

https://www.ietf.org/mail-archive/web/trill/current/msg07631.html

 

 

The authors do not need to accept every = comment, but to provide a revised draft based on this input.  =

 

Sue Hares

Shepherd/WG Co-chair =

------=_NextPart_000_00FF_01D26DD8.0B8E14B0-- From nobody Fri Jan 13 17:11:50 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64615129564 for ; Fri, 13 Jan 2017 17:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 e8-OaduontU0 for ; Fri, 13 Jan 2017 17:11:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8E6129561 for ; Fri, 13 Jan 2017 17:11:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYT35794; Sat, 14 Jan 2017 01:11:42 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Jan 2017 01:11:40 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 14 Jan 2017 09:11:35 +0800 From: Mingui Zhang To: Susan Hares , "trill@ietf.org" Thread-Topic: [trill] FW: Mail regarding draft-ietf-trill-mtu-negotiation Thread-Index: AdJt8XD2ERUvHjq/TSKc2RL14S/wVP//fJcA//9aszA= Date: Sat, 14 Jan 2017 01:11:18 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A639AEF5@NKGEML515-MBX.china.huawei.com> References: <001701d26df2$8a8d1260$9fa73720$@ndzh.com> <002701d26df2$cc24e950$646ebbf0$@ndzh.com> In-Reply-To: <002701d26df2$cc24e950$646ebbf0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E7A639AEF5NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58797ACE.010A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ebe84a2ea5e722b1d7d3aae98f553f70 Archived-At: Subject: Re: [trill] FW: Mail regarding draft-ietf-trill-mtu-negotiation X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:11:48 -0000 --_000_4552F0907735844E9204A62BBDD325E7A639AEF5NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, Thanks for the checking. The changes are so incorporated into the updated v= ersion. Ready to take more comments from the publication call. Mingui From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Saturday, January 14, 2017 7:15 AM To: trill@ietf.org Subject: [trill] FW: Mail regarding draft-ietf-trill-mtu-negotiation Forwarding to trill mailing list. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, January 13, 2017 6:13 PM To: draft-ietf-trill-mtu-negotiation@ietf.org Cc: draft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; = 'Donald Eastlake'; 'Mingui Zhang' Subject: Mail regarding draft-ietf-trill-mtu-negotiation Minqui, Xudong, Donald, Radia, and Somnath: In double checking the draft-ietf-trill-mtu-neogitation-05.txt before sendi= ng it to the IESG, I found 2 spelling errors and 2 places were the sentence= grammar could be improved. These are listed below. Alia has reviewed this= draft so these changes can be taken care of after Alia has reviewed again = the text. Page 8, #2 leaving, #a sentence 3, #b sentence 2 - spelling error Old:/orgiatingL1LSPBufferSize/ New:/originatingL1LSPBuffer Size/ Page 9, section 5, line 3 OLD /that port SHOULD be disabled and, in any case, an adjacency cannot be= formed/ New1 /that port SHOULD be disable since in any case an adjacency cannot be = formed/ New2 /that port SHOULD be disabled since, in any case, an adjacency cannot = be formed/ You can use either one of the NEWs Page 9, section 6, paragraph 2, line 2 Old/but are processed normally if received larger than that./ New/but are processed normally if received larger than that size./ I asked for IESG publication as you will probably get more editorial commen= ts. Sue Hares Shepherd --_000_4552F0907735844E9204A62BBDD325E7A639AEF5NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

Thanks for the checking. The changes are so incorporated into the= updated version.  Ready to take more comments from the publication ca= ll.

 

Mingui

 

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Saturday, January 14, 2017 7:15 AM
To: trill@ietf.org
Subject: [trill] FW: Mail regarding draft-ietf-trill-mtu-negotiation=

 

Forward= ing to trill mailing list.

&n= bsp;

Sue

&n= bsp;

From: Susan Hares [mailt= o:shares@ndzh.com]
Sent: Friday, January 13, 2017 6:13 PM
To: dra= ft-ietf-trill-mtu-negotiation@ietf.org
Cc: dra= ft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; 'Donald= Eastlake'; 'Mingui Zhang'
Subject: Mail regarding draft-ietf-trill-mtu-negotiation<= /span>

 

Minqui, Xudong, Donald, Radia, = and Somnath:

 

In double checking the draft-ie= tf-trill-mtu-neogitation-05.txt before sending it to the IESG, I found 2 sp= elling errors and 2 places were the sentence grammar could be improved. The= se are listed below.  Alia has reviewed this draft so these changes can be taken care of after Alia has reviewed a= gain the text.

 

Page 8, #2 leaving, #a sentence= 3,  #b sentence 2 – spelling error

 

Old:/orgiatingL1LSPBufferSize/ = New:/originatingL1LSPBuffer Size/

 

Page 9, section 5, line 3 =

OLD  /that port SHOULD be = disabled and, in any case, an adjacency cannot be formed/

New1 /that port SHOULD be disab= le since in any case an adjacency cannot be formed/

New2 /that port SHOULD be disab= led since, in any case, an adjacency cannot be formed/

 

You can use either one of the N= EWs

 

Page 9, section 6, paragraph 2,= line 2

 

Old/but are processed normally = if received larger than that./

New/but are processed normally = if received larger than that size./

 

I asked for IESG publication as= you will probably get more editorial comments.

 

Sue Hares

Shepherd  

--_000_4552F0907735844E9204A62BBDD325E7A639AEF5NKGEML515MBXchi_-- From nobody Fri Jan 13 17:24:27 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A58129581; Fri, 13 Jan 2017 17:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 U05pp5KScXXe; Fri, 13 Jan 2017 17:24:25 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 ACC1512956B; Fri, 13 Jan 2017 17:24:21 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Fri, 13 Jan 2017 20:20:18 -0500 Message-ID: <011601d26e04$5f12d540$1d387fc0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01D26DDA.763DB7A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJuA+fbBjra68sAR/qKKeYVwxBq6w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: margaret@painless-security.com, 'Donald Eastlake' , trill-chairs@ietf.org, draft-ietf-trill-over-ip@ietf.org, 'Mingui Zhang' Subject: [trill] IPR statement on draft-ietf-trill-over-ip-08,txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:24:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0117_01D26DDA.763DB7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Margaret, Donald, Minqui, and Dacheng: Please send a note in response to the email indicating whether you know of any IPR. This draft will not be sent to the IESG unless we get IPR statements from all authors. Sue Hares Shepherd ------=_NextPart_000_0117_01D26DDA.763DB7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Margaret, = Donald, Minqui, and Dacheng:

 

Please send = a note in response to the email indicating whether you know of any = IPR.  This draft will not be sent to the IESG unless we get IPR = statements from all authors.

 

Sue = Hares

Shepherd

 

------=_NextPart_000_0117_01D26DDA.763DB7A0-- From nobody Fri Jan 13 17:28:03 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAA312956B; Fri, 13 Jan 2017 17:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_jnim_kjZb0; Fri, 13 Jan 2017 17:28:00 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 B8C6A129598; Fri, 13 Jan 2017 17:28:00 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id j18so56701123ioe.2; Fri, 13 Jan 2017 17:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hjppUMGaeluOiig97VmsYXykjkP/UQx4Pu+ZxnFvXTY=; b=b9ZVDF1I46YzfrgCEKWhDHew2Uv2K/5+v1IxGLsonptQmGuFqkwI+R8ycpmbt1wmwO O2PHdDTt5S7CoBBLNhVM2EIN71CKFH5frspz6P9i83RqT6y3PiYU9uNl72jqVMpg9+XJ i82tblzigYBPGe3WWshJQ6k6/QO+rgMMBUIUuWuJxJgJzHC/ZLGs3szcYTv9d6glPg/d J74tvtYvSAXu/f7eBf0ul1+qi3o+ZIg9Lxs7JTO3K72B4rHJSo1N2x/ORnFDjiNsKo6A qebH2BS/7lHgJ2LC6Xp/jLA6UhCD96aUZ6HFKCVOTnt9gqyma21mfFWp7wV2zeJpumHj Gniw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hjppUMGaeluOiig97VmsYXykjkP/UQx4Pu+ZxnFvXTY=; b=Xm4L5S5Y77zw81hwrs6sbLPx15HS5JYbnFvMGO7MQiwwdXTSARql74Y0BQCVefCllt UXMsIxyctFq1YFzvqQSmPyJfREfJLKGPCz6m1wR13USxjH85S6z6N0iMl1vnN1+gE0h+ 5n+Pn8vrT6fzWjdJSeX84bGymKhYcEybZGxsrM/QetFL1/pV9Teslutk0gtGbuZ5Tubv Bli7uiAHO6MrEO8arxUZ2qd4apgbl4FyYZ/xvjGkGTNJp46ZKcPOZRVKRgwwrfpQcMS9 t2KFl6/Hx3fo2lMIK8S1KrPuwrxZPFwcEV8fGC2GgcELc3TIg/bQ+Gybq8b+QIijNiDV J7zw== X-Gm-Message-State: AIkVDXIjlTqGrQ4g6YPhO7AppnI77Kajj4iC/8PS9VoT5XBhhKXxDce9QG8oVYHcw7sL+bowzv8XIp0/cGSIrw== X-Received: by 10.107.175.93 with SMTP id y90mr1776597ioe.12.1484357280106; Fri, 13 Jan 2017 17:28:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Fri, 13 Jan 2017 17:27:44 -0800 (PST) In-Reply-To: <011601d26e04$5f12d540$1d387fc0$@ndzh.com> References: <011601d26e04$5f12d540$1d387fc0$@ndzh.com> From: Donald Eastlake Date: Fri, 13 Jan 2017 20:27:44 -0500 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Margaret Cullen , Mingui Zhang , "trill-chairs@ietf.org" , draft-ietf-trill-over-ip@ietf.org, "trill@ietf.org" Subject: Re: [trill] IPR statement on draft-ietf-trill-over-ip-08,txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:28:02 -0000 I am not aware of any IPR in this draft. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Jan 13, 2017 at 8:20 PM, Susan Hares wrote: > Margaret, Donald, Minqui, and Dacheng: > > > > Please send a note in response to the email indicating whether you know of > any IPR. This draft will not be sent to the IESG unless we get IPR > statements from all authors. > > > > Sue Hares > > Shepherd > > From nobody Fri Jan 13 17:31:06 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26CC1294BC; Fri, 13 Jan 2017 17:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 iagFju6XAx6k; Fri, 13 Jan 2017 17:31:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB1712956B; Fri, 13 Jan 2017 17:31:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYT37122; Sat, 14 Jan 2017 01:31:00 +0000 (GMT) Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Jan 2017 01:30:59 +0000 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Sat, 14 Jan 2017 09:29:24 +0800 From: zhangdacheng To: Donald Eastlake , Susan Hares Thread-Topic: IPR statement on draft-ietf-trill-over-ip-08,txt Thread-Index: AQHSbgV2qqKG+qcStk2cXvJpXDs2b6E3LvxQ Date: Sat, 14 Jan 2017 01:29:23 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C2242C13CCD@szxemi502-mbx.china.huawei.com> References: <011601d26e04$5f12d540$1d387fc0$@ndzh.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58797F54.01B2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cea412045d1c23055f512cd84b825510 Archived-At: Cc: Margaret Cullen , Mingui Zhang , "trill-chairs@ietf.org" , "draft-ietf-trill-over-ip@ietf.org" , "trill@ietf.org" Subject: [trill] =?utf-8?b?562U5aSNOiBJUFIgc3RhdGVtZW50IG9uIGRyYWZ0LWll?= =?utf-8?q?tf-trill-over-ip-08=2Ctxt?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:31:05 -0000 VG8gbXkgYmVzdCBrbm93bGVkZ2UsIEkgZG9uJ3QgZmluZCBhbnkgSVBSIGlzc3VlIGluIHRoaXMg ZHJhZnQuDQoNCkNoZWVycw0KDQpEYWNoZW5nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWP keS7tuS6ujogRG9uYWxkIEVhc3RsYWtlIFttYWlsdG86ZDNlM2UzQGdtYWlsLmNvbV0gDQrlj5Hp gIHml7bpl7Q6IDIwMTflubQx5pyIMTTml6UgOToyOA0K5pS25Lu25Lq6OiBTdXNhbiBIYXJlcyA8 c2hhcmVzQG5kemguY29tPg0K5oqE6YCBOiB0cmlsbEBpZXRmLm9yZzsgdHJpbGwtY2hhaXJzQGll dGYub3JnOyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXBAaWV0Zi5vcmc7IE1hcmdhcmV0IEN1bGxl biA8bWFyZ2FyZXRAcGFpbmxlc3Mtc2VjdXJpdHkuY29tPjsgTWluZ3VpIFpoYW5nIDx6aGFuZ21p bmd1aUBodWF3ZWkuY29tPg0K5Li76aKYOiBSZTogSVBSIHN0YXRlbWVudCBvbiBkcmFmdC1pZXRm LXRyaWxsLW92ZXItaXAtMDgsdHh0DQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgaW4gdGhp cyBkcmFmdC4NCg0KVGhhbmtzLA0KRG9uYWxkDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQogRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsxLTUwOC0zMzMtMjI3MCAoY2VsbCkNCiAx NTUgQmVhdmVyIFN0cmVldCwgTWlsZm9yZCwgTUEgMDE3NTcgVVNBICBkM2UzZTNAZ21haWwuY29t DQoNCg0KT24gRnJpLCBKYW4gMTMsIDIwMTcgYXQgODoyMCBQTSwgU3VzYW4gSGFyZXMgPHNoYXJl c0BuZHpoLmNvbT4gd3JvdGU6DQo+IE1hcmdhcmV0LCBEb25hbGQsIE1pbnF1aSwgYW5kIERhY2hl bmc6DQo+DQo+DQo+DQo+IFBsZWFzZSBzZW5kIGEgbm90ZSBpbiByZXNwb25zZSB0byB0aGUgZW1h aWwgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSANCj4ga25vdyBvZiBhbnkgSVBSLiAgVGhpcyBkcmFm dCB3aWxsIG5vdCBiZSBzZW50IHRvIHRoZSBJRVNHIHVubGVzcyB3ZSANCj4gZ2V0IElQUiBzdGF0 ZW1lbnRzIGZyb20gYWxsIGF1dGhvcnMuDQo+DQo+DQo+DQo+IFN1ZSBIYXJlcw0KPg0KPiBTaGVw aGVyZA0KPg0KPg0K From nobody Fri Jan 13 17:32:51 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B41294BC; Fri, 13 Jan 2017 17:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 CSxGlSBUPDud; Fri, 13 Jan 2017 17:32:49 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 BDE1812956E; Fri, 13 Jan 2017 17:32:48 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Fri, 13 Jan 2017 20:28:52 -0500 Message-ID: <014601d26e05$91913470$b4b39d50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01D26DDB.A8BBA1A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJuBVhM0LIaIzcCRrqSiYt6l2s6dA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , trill-chairs@ietf.org Subject: [trill] WG LC for draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to 10/18) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:32:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0147_01D26DDB.A8BBA1A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This draft did not reach working group consensus. The authors should post a revision to this draft that address the issues mentioned by Donald Eastlake in the email: https://www.ietf.org/mail-archive/web/trill/current/msg07573.html The WG can reconsider this draft for WG LC after these issues have been addressed. Sue Hares WG co-chair ------=_NextPart_000_0147_01D26DDB.A8BBA1A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft = did not reach working group consensus.  The authors should post a = revision to this draft that address the issues mentioned by Donald = Eastlake in the email:

 

https://www.ietf.org/mail-archive/web/trill/current/msg07573.html

 

The WG can reconsider this draft for WG LC after these = issues have been addressed.

 

Sue Hares =

WG co-chair =

------=_NextPart_000_0147_01D26DDB.A8BBA1A0-- From nobody Fri Jan 13 17:49:28 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE19129591; Fri, 13 Jan 2017 17:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 9o8Ul1lE18ma; Fri, 13 Jan 2017 17:49:25 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 841EC129476; Fri, 13 Jan 2017 17:49:22 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Fri, 13 Jan 2017 20:45:22 -0500 Message-ID: <015301d26e07$e10f52f0$a32df8d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0154_01D26DDD.F83A3550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJuB0NLPSO2AZp/Tq2QEXD2r5PhPw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-trill-address-flush@ietf.org, trill-chairs@ietf.org Subject: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:49:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0154_01D26DDD.F83A3550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG Last Call for (1/13/2017 to 1/27/2017) for draft-ietf-trill-address-flush which you can access at: https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ In your review please consider the following questions: 1) Do you think this request from one TRILL Rbridge to another TRILL Rbridges is useful in deployments? 2) Does it supplement TRILL's automatic address forgetting and achieve better convergence times when topologies or configuration changes? 3) Are the mechanisms described in this draft technically sound without adding lots of complexity to Trill? 4) Is this document ready for publication? Will the authors please indicate if they know of any IPR relating to this draft in their response to this WG LC? I would appreciate if the authors will answer these four questions as well. Sue Hares Shepherd TRILL WG Co-chair ------=_NextPart_000_0154_01D26DDD.F83A3550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG Last Call for (1/13/2017 to 1/27/2017) for = draft-ietf-trill-address-flush which you can access at: =

https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/

 

In your review please consider the following = questions:

 

1)      = Do you think this request from one TRILL Rbridge = to another TRILL Rbridges is useful in deployments?  =

2)      = Does it supplement TRILL’s automatic = address forgetting and achieve better convergence times when topologies = or configuration changes? 

3)      = Are the mechanisms described in this draft = technically sound without adding lots of complexity to Trill? =

4)      = Is this document ready for = publication?

 

Will the authors please indicate if they know of any = IPR relating to this draft in their response to this WG LC?  I = would appreciate if the authors will answer these four questions as = well.

 

Sue Hares

Shepherd =

TRILL WG Co-chair =

------=_NextPart_000_0154_01D26DDD.F83A3550-- From nobody Fri Jan 13 17:54:17 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E9A129476; Fri, 13 Jan 2017 17:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 hFoAfLyYnQ7g; Fri, 13 Jan 2017 17:54:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45BD129581; Fri, 13 Jan 2017 17:54:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEJ95159; Sat, 14 Jan 2017 01:54:10 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Jan 2017 01:54:09 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 14 Jan 2017 09:53:58 +0800 From: Mingui Zhang To: zhangdacheng , Donald Eastlake , Susan Hares Thread-Topic: IPR statement on draft-ietf-trill-over-ip-08,txt Thread-Index: AQHSbgV2+wQQI0N1vEKSdW4S32ErHqE2qR6AgACMgWA= Date: Sat, 14 Jan 2017 01:53:40 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A639AF93@NKGEML515-MBX.china.huawei.com> References: <011601d26e04$5f12d540$1d387fc0$@ndzh.com> <879E76B64CF340468BF5E4DE504C2242C13CCD@szxemi502-mbx.china.huawei.com> In-Reply-To: <879E76B64CF340468BF5E4DE504C2242C13CCD@szxemi502-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.587984C2.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 736b0624d1731efcfd956bfb32ee62cb Archived-At: Cc: Margaret Cullen , "trill-chairs@ietf.org" , "draft-ietf-trill-over-ip@ietf.org" , "trill@ietf.org" Subject: Re: [trill] IPR statement on draft-ietf-trill-over-ip-08,txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 01:54:15 -0000 SSBhbSBub3QgYXdhcmUgb2YgSVBSIHRoYXQgaXMgcmVsZXZhbnQgdG8gdGhpcyBkcmFmdC4gDQoN ClRoYW5rcywNCk1pbmd1aQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHpoYW5nZGFjaGVuZw0KPiBTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxNCwgMjAxNyA5OjI5IEFN DQo+IFRvOiBEb25hbGQgRWFzdGxha2U7IFN1c2FuIEhhcmVzDQo+IENjOiB0cmlsbEBpZXRmLm9y ZzsgdHJpbGwtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXBAaWV0Zi5v cmc7DQo+IE1hcmdhcmV0IEN1bGxlbjsgTWluZ3VpIFpoYW5nDQo+IFN1YmplY3Q6IOetlOWkjTog SVBSIHN0YXRlbWVudCBvbiBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXAtMDgsdHh0DQo+IA0KPiBU byBteSBiZXN0IGtub3dsZWRnZSwgSSBkb24ndCBmaW5kIGFueSBJUFIgaXNzdWUgaW4gdGhpcyBk cmFmdC4NCj4gDQo+IENoZWVycw0KPiANCj4gRGFjaGVuZw0KPiANCj4gLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KPiDlj5Hku7bkuro6IERvbmFsZCBFYXN0bGFrZSBbbWFpbHRvOmQzZTNlM0BnbWFp bC5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxN+W5tDHmnIgxNOaXpSA5OjI4DQo+IOaUtuS7tuS6 ujogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCj4g5oqE6YCBOiB0cmlsbEBpZXRmLm9y ZzsgdHJpbGwtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXBAaWV0Zi5v cmc7DQo+IE1hcmdhcmV0IEN1bGxlbiA8bWFyZ2FyZXRAcGFpbmxlc3Mtc2VjdXJpdHkuY29tPjsg TWluZ3VpIFpoYW5nDQo+IDx6aGFuZ21pbmd1aUBodWF3ZWkuY29tPg0KPiDkuLvpopg6IFJlOiBJ UFIgc3RhdGVtZW50IG9uIGRyYWZ0LWlldGYtdHJpbGwtb3Zlci1pcC0wOCx0eHQNCj4gDQo+IEkg YW0gbm90IGF3YXJlIG9mIGFueSBJUFIgaW4gdGhpcyBkcmFmdC4NCj4gDQo+IFRoYW5rcywNCj4g RG9uYWxkDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gIERvbmFsZCBFLiBF YXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQo+ICAxNTUgQmVhdmVyIFN0cmVl dCwgTWlsZm9yZCwgTUEgMDE3NTcgVVNBICBkM2UzZTNAZ21haWwuY29tDQo+IA0KPiANCj4gT24g RnJpLCBKYW4gMTMsIDIwMTcgYXQgODoyMCBQTSwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNv bT4gd3JvdGU6DQo+ID4gTWFyZ2FyZXQsIERvbmFsZCwgTWlucXVpLCBhbmQgRGFjaGVuZzoNCj4g Pg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugc2VuZCBhIG5vdGUgaW4gcmVzcG9uc2UgdG8gdGhlIGVt YWlsIGluZGljYXRpbmcgd2hldGhlciB5b3UNCj4gPiBrbm93IG9mIGFueSBJUFIuICBUaGlzIGRy YWZ0IHdpbGwgbm90IGJlIHNlbnQgdG8gdGhlIElFU0cgdW5sZXNzIHdlDQo+ID4gZ2V0IElQUiBz dGF0ZW1lbnRzIGZyb20gYWxsIGF1dGhvcnMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gU3VlIEhhcmVz DQo+ID4NCj4gPiBTaGVwaGVyZA0KPiA+DQo+ID4NCg== From nobody Sat Jan 14 07:14:20 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98795129674; Sat, 14 Jan 2017 07:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 JJwQK22_ePXz; Sat, 14 Jan 2017 07:14:17 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 72E4E12945E; Sat, 14 Jan 2017 07:14:17 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185; From: "Susan Hares" To: Date: Sat, 14 Jan 2017 10:10:10 -0500 Message-ID: <01fe01d26e78$52a06560$f7e13020$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FF_01D26E4E.69CC3220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJuc2ZW/JsGLZoBSw2sBH+1A+0GaQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-trill-address-flush@ietf.org, trill-chairs@ietf.org Subject: Re: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 15:14:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01FF_01D26E4E.69CC3220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Weiquo, Donald, Yizhou, and Mohammed: Thank you for your work on draft-ietf-trill-address-flush. This is a shepherd's review for draft-ietf-trill-address-flush. ' Shepherd's answer to questions: 1) Deployment experience - No deployment experience, but this target action has been useful in other protocols. 2) Convergence experience - No convergence measurement experience, but targeted convergence based on a centralized controllers can provide better convergence theoretically. 3) Mechanisms comments below - seem to be editorial, but may be minor. 4) With editorial/minor changes - document is ready for publication Status: Ready with minor/editorial comments. Minor/editorial changes: #1 page 10,m paragraph 2 - after table, beginning with "All RBridges implementing" Editorial change: The next 4 paragraph state requirements for processing need to be clearly laid out. A set of suggested text that replaces paragraphs 2, 3, 4 (p. 10-11). New:/ Processing Requirements: The processing requirements based on support for Address Flush Channel message plus the additional types: . Basic RBridges functionality: All RBridges supporting the Address Flush Channel message MUST implement type 1 (Blocks of VLANs), type 2 (Bit map of VLANs), and type 6 (All Data labels). Type 6 indicates that all addresses are to be flushed for all data labels. . Optional RBridges functionality: RBridges SHOULD implement types 7 and type 8 so that specific MAC addresses can be can be flushed. If a set of RBridges does not implement types 7 and 8, the flush will be inefficient as those not intent to be flashed will have to be relearned. . FGL functionality : All RBridges implementing the FGL ingress/egress support and the Address Flush Channel message MUST implement type 3 (Blocks of FGLs), type 4 (Lists of FGLs), and type 5 (Bit Map of FGL). An RBridge that is merely FGL safe [RFC7172], but cannot egress TRILL data packets, SHOULD ignore the FGL types with the Address Flush Channel message as it will not learn any MAC addresses with FGL scope from the MAC data plane. Processing interactions: The parsing of the TLVs in an Rbridge Channel Message in the Address Flush Protocol Specific TLVS by a receiving bridge results in three items: 1) All-Data-label-found flag indicating whether one or more types 6 TLVs (All Data Labels) were encountered, 2) A set of Data labels and blocks of data labels compiled from VLAN TLVs (types 1 and 2), and/or FGL TLVs (types 3, 4, and 5), 3) If a MAC TLVs types (type 6 and 7) are implemented, a set of MAC addresses and Blocks of MAC addresses from the MAC TLVs. For the following flag settings, the processing is as follows: a) If the set of MAC addresses and Block of MAC address is null (item 3 above) then Address Flush applies to all messages. b) If the All-Data-label-found flag (item 1 above) is true, then the address flush message applies to all data labels. The set of Data label and block of data labels (item 2 above) does not have any effect. c) If the All-Data-label-found flag (item 1 above) is false, then the Address Flush message applies to the set of Data labels (see item 2 above) found in VLAn TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and 5). If the set of Data Labels (see item 2 above) is null, the Address Flush message does nothing. / #2 - editorial nits #2.a) p. 9, figure 4 - bottom +-+ does not match top - Is this what you wanted or an error? #2.b) p. 9, paragraph beginning "Type: The 8 bit" Old/ of this Section 2.2 for details on each type / New/of this section (section 2.2) for details on each type/ Sue Hares From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, January 13, 2017 8:45 PM To: trill@ietf.org Cc: draft-ietf-trill-address-flush@ietf.org; trill-chairs@ietf.org Subject: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017) This begins a 2 week WG Last Call for (1/13/2017 to 1/27/2017) for draft-ietf-trill-address-flush which you can access at: https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ In your review please consider the following questions: 1) Do you think this request from one TRILL Rbridge to another TRILL Rbridges is useful in deployments? 2) Does it supplement TRILL's automatic address forgetting and achieve better convergence times when topologies or configuration changes? 3) Are the mechanisms described in this draft technically sound without adding lots of complexity to Trill? 4) Is this document ready for publication? Will the authors please indicate if they know of any IPR relating to this draft in their response to this WG LC? I would appreciate if the authors will answer these four questions as well. Sue Hares Shepherd TRILL WG Co-chair ------=_NextPart_000_01FF_01D26E4E.69CC3220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Weiquo, Donald, Yizhou, and Mohammed: =

 

Thank you for your work = on draft-ietf-trill-address-flush. This is a shepherd’s review for = draft-ietf-trill-address-flush.  =   ‘

 

Shepherd’s = answer to questions: =  

1)      = Deployment = experience – No deployment experience, but this target action has = been useful in other protocols.

2)      = Convergence = experience – No convergence measurement experience, but targeted = convergence based on a centralized controllers can provide better = convergence theoretically.

3)      = Mechanisms = comments below – seem to be editorial, but may be minor. =

4)      = With = editorial/minor changes – document is ready for publication =

 

 

Status: = Ready with minor/editorial comments. 

 

Minor/editorial = changes:

 

#1 page 10,m paragraph 2 = – after table, beginning with “All RBridges = implementing”

 

Editorial change:  = The next 4 paragraph state requirements for processing need to be = clearly laid out.  A set of suggested text that replaces paragraphs = 2, 3, 4 (p. 10-11).

 

New:/

Processing Requirements: =

 

The processing = requirements based on support for Address Flush Channel message plus the = additional types:  

 

·         = Basic = RBridges functionality:  All RBridges supporting the Address Flush = Channel message MUST implement type 1 (Blocks of VLANs),  type 2 = (Bit map of VLANs), and type 6 (All Data labels).  Type 6 indicates = that all addresses are to be flushed for all data = labels.

 

·         = Optional = RBridges functionality:  RBridges SHOULD implement types 7 and type = 8 so that specific MAC addresses can be can be flushed.  If a set = of RBridges does not implement types 7 and 8, the flush will be = inefficient as those not intent to be flashed will have to be relearned. =

 

·         = FGL = functionality : All RBridges implementing the FGL ingress/egress support = and the Address Flush Channel message MUST implement type 3 (Blocks of = FGLs), type 4 (Lists of FGLs), and type 5 (Bit Map of FGL).  An = RBridge that is merely FGL safe [RFC7172], but cannot egress TRILL data = packets, SHOULD ignore the FGL types with the Address Flush Channel = message as it will not learn any MAC addresses with FGL scope from the = MAC data plane.

 

Processing interactions: =

 

The parsing of the TLVs = in an Rbridge Channel Message in the Address Flush Protocol Specific = TLVS by a receiving bridge results in three items: =

1)      = All-Data-label-found flag indicating whether one = or more types 6 TLVs (All Data Labels) were = encountered,

2)      = A set of = Data labels and blocks of data labels compiled from VLAN TLVs (types 1 = and 2), and/or FGL TLVs (types 3, 4, and 5),

3)      = If a MAC = TLVs types (type 6 and 7)  are implemented, a set of MAC addresses = and Blocks of MAC addresses from the MAC TLVs.

 

For the following flag = settings, the processing is as follows:

a)      = If the set = of MAC addresses and Block of MAC address is null (item 3 above) then = Address Flush applies to all messages.

b)      = If the =  All-Data-label-found flag (item 1 above) is true, then the address = flush message applies to all data labels.  The set of Data label = and block of data labels (item 2 above) does not have any effect. =

c)       = If the = All-Data-label-found flag (item 1 above) is false, then the Address = Flush message applies to the set of Data labels (see item 2 above) found = in VLAn TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and = 5).   If the set of Data Labels (see item 2 above) is null, = the Address Flush message does nothing.

/

 

 

#2 – editorial = nits

#2.a) p. 9, figure 4 – bottom +-+ does not = match top – Is this what you wanted or an error? =  

#2.b) p. 9, paragraph beginning  = “Type: The 8 bit”

 

Old/ of this Section 2.2 = for details on each type /

New/of this section = (section 2.2) for details on each type/

 

Sue Hares =

 

 

From:= = trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, January 13, 2017 8:45 PM
To: = trill@ietf.org
Cc: draft-ietf-trill-address-flush@ietf.org; = trill-chairs@ietf.org
Subject: [trill] WG Last Call for = draft-ietf-trill-address-flush (1/13/2017 to = 1/27/2017)

 

This begins = a 2 week WG Last Call for (1/13/2017 to 1/27/2017) for = draft-ietf-trill-address-flush which you can access at: =

https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/

 

In your review please consider the following = questions:

 

1)      = Do you think this request from one TRILL Rbridge = to another TRILL Rbridges is useful in deployments?  =

2)      = Does it supplement TRILL’s automatic = address forgetting and achieve better convergence times when topologies = or configuration changes? 

3)      = Are the mechanisms described in this draft = technically sound without adding lots of complexity to Trill? =

4)      = Is this document ready for = publication?

 

Will the authors please indicate if they know of any = IPR relating to this draft in their response to this WG LC?  I = would appreciate if the authors will answer these four questions as = well.

 

Sue Hares

Shepherd =

TRILL WG Co-chair =

------=_NextPart_000_01FF_01D26E4E.69CC3220-- From nobody Sun Jan 15 17:48:52 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B475127058; Sun, 15 Jan 2017 17:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 fiuPUjDCZDU7; Sun, 15 Jan 2017 17:48:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E723128824; Sun, 15 Jan 2017 17:48:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYV48219; Mon, 16 Jan 2017 01:48:43 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 16 Jan 2017 01:48:41 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.43]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 16 Jan 2017 09:48:37 +0800 From: Haoweiguo To: Susan Hares , "trill@ietf.org" Thread-Topic: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017) Thread-Index: AdJuc2ZW/JsGLZoBSw2sBH+1A+0GaQBJyThQ Date: Mon, 16 Jan 2017 01:48:37 +0000 Message-ID: References: <01fe01d26e78$52a06560$f7e13020$@ndzh.com> In-Reply-To: <01fe01d26e78$52a06560$f7e13020$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517336602DCB1nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.587C267C.008A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.43, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 50be3ac7de77e0bd4bd681af0f4999ca Archived-At: Cc: "draft-ietf-trill-address-flush@ietf.org" , "trill-chairs@ietf.org" Subject: [trill] =?gb2312?b?tPC4tDogIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0?= =?gb2312?b?Zi10cmlsbC1hZGRyZXNzLWZsdXNoICgxLzEzLzIwMTcgdG8gMS8yNy8yMDE3?= =?gb2312?b?KQ==?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 01:48:49 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517336602DCB1nkgeml513mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIFN1ZSwgSSB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgYXMgcGVyIHlvdXIgY29tbWVudHMg QVNBUC4NCndlaWd1bw0KDQq3orz+yMs6IFN1c2FuIEhhcmVzIFttYWlsdG86c2hhcmVzQG5kemgu Y29tXQ0Kt6LLzcqxvOQ6IDIwMTfE6jHUwjE0yNUgMjM6MTANCsrVvP7IyzogdHJpbGxAaWV0Zi5v cmcNCrOty806IGRyYWZ0LWlldGYtdHJpbGwtYWRkcmVzcy1mbHVzaEBpZXRmLm9yZzsgdHJpbGwt Y2hhaXJzQGlldGYub3JnDQrW98ziOiBSRTogW3RyaWxsXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0 LWlldGYtdHJpbGwtYWRkcmVzcy1mbHVzaCAoMS8xMy8yMDE3IHRvIDEvMjcvMjAxNykNCg0KV2Vp cXVvLCBEb25hbGQsIFlpemhvdSwgYW5kIE1vaGFtbWVkOg0KDQpUaGFuayB5b3UgZm9yIHlvdXIg d29yayBvbiBkcmFmdC1pZXRmLXRyaWxsLWFkZHJlc3MtZmx1c2guIFRoaXMgaXMgYSBzaGVwaGVy ZKGvcyByZXZpZXcgZm9yIGRyYWZ0LWlldGYtdHJpbGwtYWRkcmVzcy1mbHVzaC4gICAgoa4NCg0K U2hlcGhlcmShr3MgYW5zd2VyIHRvIHF1ZXN0aW9uczoNCg0KMSkgICAgICBEZXBsb3ltZW50IGV4 cGVyaWVuY2UgqEMgTm8gZGVwbG95bWVudCBleHBlcmllbmNlLCBidXQgdGhpcyB0YXJnZXQgYWN0 aW9uIGhhcyBiZWVuIHVzZWZ1bCBpbiBvdGhlciBwcm90b2NvbHMuDQoNCjIpICAgICAgQ29udmVy Z2VuY2UgZXhwZXJpZW5jZSCoQyBObyBjb252ZXJnZW5jZSBtZWFzdXJlbWVudCBleHBlcmllbmNl LCBidXQgdGFyZ2V0ZWQgY29udmVyZ2VuY2UgYmFzZWQgb24gYSBjZW50cmFsaXplZCBjb250cm9s bGVycyBjYW4gcHJvdmlkZSBiZXR0ZXIgY29udmVyZ2VuY2UgdGhlb3JldGljYWxseS4NCg0KMykg ICAgICBNZWNoYW5pc21zIGNvbW1lbnRzIGJlbG93IKhDIHNlZW0gdG8gYmUgZWRpdG9yaWFsLCBi dXQgbWF5IGJlIG1pbm9yLg0KDQo0KSAgICAgIFdpdGggZWRpdG9yaWFsL21pbm9yIGNoYW5nZXMg qEMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uDQoNCg0KU3RhdHVzOiBSZWFkeSB3 aXRoIG1pbm9yL2VkaXRvcmlhbCBjb21tZW50cy4NCg0KTWlub3IvZWRpdG9yaWFsIGNoYW5nZXM6 DQoNCiMxIHBhZ2UgMTAsbSBwYXJhZ3JhcGggMiCoQyBhZnRlciB0YWJsZSwgYmVnaW5uaW5nIHdp dGggobBBbGwgUkJyaWRnZXMgaW1wbGVtZW50aW5nobENCg0KRWRpdG9yaWFsIGNoYW5nZTogIFRo ZSBuZXh0IDQgcGFyYWdyYXBoIHN0YXRlIHJlcXVpcmVtZW50cyBmb3IgcHJvY2Vzc2luZyBuZWVk IHRvIGJlIGNsZWFybHkgbGFpZCBvdXQuICBBIHNldCBvZiBzdWdnZXN0ZWQgdGV4dCB0aGF0IHJl cGxhY2VzIHBhcmFncmFwaHMgMiwgMywgNCAocC4gMTAtMTEpLg0KDQpOZXc6Lw0KUHJvY2Vzc2lu ZyBSZXF1aXJlbWVudHM6DQoNClRoZSBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cyBiYXNlZCBvbiBz dXBwb3J0IGZvciBBZGRyZXNzIEZsdXNoIENoYW5uZWwgbWVzc2FnZSBwbHVzIHRoZSBhZGRpdGlv bmFsIHR5cGVzOg0KDQoNCqGkICAgICAgICAgQmFzaWMgUkJyaWRnZXMgZnVuY3Rpb25hbGl0eTog IEFsbCBSQnJpZGdlcyBzdXBwb3J0aW5nIHRoZSBBZGRyZXNzIEZsdXNoIENoYW5uZWwgbWVzc2Fn ZSBNVVNUIGltcGxlbWVudCB0eXBlIDEgKEJsb2NrcyBvZiBWTEFOcyksICB0eXBlIDIgKEJpdCBt YXAgb2YgVkxBTnMpLCBhbmQgdHlwZSA2IChBbGwgRGF0YSBsYWJlbHMpLiAgVHlwZSA2IGluZGlj YXRlcyB0aGF0IGFsbCBhZGRyZXNzZXMgYXJlIHRvIGJlIGZsdXNoZWQgZm9yIGFsbCBkYXRhIGxh YmVscy4NCg0KDQoNCqGkICAgICAgICAgT3B0aW9uYWwgUkJyaWRnZXMgZnVuY3Rpb25hbGl0eTog IFJCcmlkZ2VzIFNIT1VMRCBpbXBsZW1lbnQgdHlwZXMgNyBhbmQgdHlwZSA4IHNvIHRoYXQgc3Bl Y2lmaWMgTUFDIGFkZHJlc3NlcyBjYW4gYmUgY2FuIGJlIGZsdXNoZWQuICBJZiBhIHNldCBvZiBS QnJpZGdlcyBkb2VzIG5vdCBpbXBsZW1lbnQgdHlwZXMgNyBhbmQgOCwgdGhlIGZsdXNoIHdpbGwg YmUgaW5lZmZpY2llbnQgYXMgdGhvc2Ugbm90IGludGVudCB0byBiZSBmbGFzaGVkIHdpbGwgaGF2 ZSB0byBiZSByZWxlYXJuZWQuDQoNCg0KDQqhpCAgICAgICAgIEZHTCBmdW5jdGlvbmFsaXR5IDog QWxsIFJCcmlkZ2VzIGltcGxlbWVudGluZyB0aGUgRkdMIGluZ3Jlc3MvZWdyZXNzIHN1cHBvcnQg YW5kIHRoZSBBZGRyZXNzIEZsdXNoIENoYW5uZWwgbWVzc2FnZSBNVVNUIGltcGxlbWVudCB0eXBl IDMgKEJsb2NrcyBvZiBGR0xzKSwgdHlwZSA0IChMaXN0cyBvZiBGR0xzKSwgYW5kIHR5cGUgNSAo Qml0IE1hcCBvZiBGR0wpLiAgQW4gUkJyaWRnZSB0aGF0IGlzIG1lcmVseSBGR0wgc2FmZSBbUkZD NzE3Ml0sIGJ1dCBjYW5ub3QgZWdyZXNzIFRSSUxMIGRhdGEgcGFja2V0cywgU0hPVUxEIGlnbm9y ZSB0aGUgRkdMIHR5cGVzIHdpdGggdGhlIEFkZHJlc3MgRmx1c2ggQ2hhbm5lbCBtZXNzYWdlIGFz IGl0IHdpbGwgbm90IGxlYXJuIGFueSBNQUMgYWRkcmVzc2VzIHdpdGggRkdMIHNjb3BlIGZyb20g dGhlIE1BQyBkYXRhIHBsYW5lLg0KDQpQcm9jZXNzaW5nIGludGVyYWN0aW9uczoNCg0KVGhlIHBh cnNpbmcgb2YgdGhlIFRMVnMgaW4gYW4gUmJyaWRnZSBDaGFubmVsIE1lc3NhZ2UgaW4gdGhlIEFk ZHJlc3MgRmx1c2ggUHJvdG9jb2wgU3BlY2lmaWMgVExWUyBieSBhIHJlY2VpdmluZyBicmlkZ2Ug cmVzdWx0cyBpbiB0aHJlZSBpdGVtczoNCg0KMSkgICAgICBBbGwtRGF0YS1sYWJlbC1mb3VuZCBm bGFnIGluZGljYXRpbmcgd2hldGhlciBvbmUgb3IgbW9yZSB0eXBlcyA2IFRMVnMgKEFsbCBEYXRh IExhYmVscykgd2VyZSBlbmNvdW50ZXJlZCwNCg0KMikgICAgICBBIHNldCBvZiBEYXRhIGxhYmVs cyBhbmQgYmxvY2tzIG9mIGRhdGEgbGFiZWxzIGNvbXBpbGVkIGZyb20gVkxBTiBUTFZzICh0eXBl cyAxIGFuZCAyKSwgYW5kL29yIEZHTCBUTFZzICh0eXBlcyAzLCA0LCBhbmQgNSksDQoNCjMpICAg ICAgSWYgYSBNQUMgVExWcyB0eXBlcyAodHlwZSA2IGFuZCA3KSAgYXJlIGltcGxlbWVudGVkLCBh IHNldCBvZiBNQUMgYWRkcmVzc2VzIGFuZCBCbG9ja3Mgb2YgTUFDIGFkZHJlc3NlcyBmcm9tIHRo ZSBNQUMgVExWcy4NCg0KRm9yIHRoZSBmb2xsb3dpbmcgZmxhZyBzZXR0aW5ncywgdGhlIHByb2Nl c3NpbmcgaXMgYXMgZm9sbG93czoNCg0KYSkgICAgICBJZiB0aGUgc2V0IG9mIE1BQyBhZGRyZXNz ZXMgYW5kIEJsb2NrIG9mIE1BQyBhZGRyZXNzIGlzIG51bGwgKGl0ZW0gMyBhYm92ZSkgdGhlbiBB ZGRyZXNzIEZsdXNoIGFwcGxpZXMgdG8gYWxsIG1lc3NhZ2VzLg0KDQpiKSAgICAgIElmIHRoZSAg QWxsLURhdGEtbGFiZWwtZm91bmQgZmxhZyAoaXRlbSAxIGFib3ZlKSBpcyB0cnVlLCB0aGVuIHRo ZSBhZGRyZXNzIGZsdXNoIG1lc3NhZ2UgYXBwbGllcyB0byBhbGwgZGF0YSBsYWJlbHMuICBUaGUg c2V0IG9mIERhdGEgbGFiZWwgYW5kIGJsb2NrIG9mIGRhdGEgbGFiZWxzIChpdGVtIDIgYWJvdmUp IGRvZXMgbm90IGhhdmUgYW55IGVmZmVjdC4NCg0KYykgICAgICAgSWYgdGhlIEFsbC1EYXRhLWxh YmVsLWZvdW5kIGZsYWcgKGl0ZW0gMSBhYm92ZSkgaXMgZmFsc2UsIHRoZW4gdGhlIEFkZHJlc3Mg Rmx1c2ggbWVzc2FnZSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgRGF0YSBsYWJlbHMgKHNlZSBpdGVt IDIgYWJvdmUpIGZvdW5kIGluIFZMQW4gVExWcyAodHlwZXMgMSBhbmQgMiksIGFuZC9vciBGR0xz IFRMVlMgKHR5cGVzIDMsIDQsIGFuZCA1KS4gICBJZiB0aGUgc2V0IG9mIERhdGEgTGFiZWxzIChz ZWUgaXRlbSAyIGFib3ZlKSBpcyBudWxsLCB0aGUgQWRkcmVzcyBGbHVzaCBtZXNzYWdlIGRvZXMg bm90aGluZy4NCi8NCg0KDQojMiCoQyBlZGl0b3JpYWwgbml0cw0KIzIuYSkgcC4gOSwgZmlndXJl IDQgqEMgYm90dG9tICstKyBkb2VzIG5vdCBtYXRjaCB0b3AgqEMgSXMgdGhpcyB3aGF0IHlvdSB3 YW50ZWQgb3IgYW4gZXJyb3I/DQojMi5iKSBwLiA5LCBwYXJhZ3JhcGggYmVnaW5uaW5nICChsFR5 cGU6IFRoZSA4IGJpdKGxDQoNCk9sZC8gb2YgdGhpcyBTZWN0aW9uIDIuMiBmb3IgZGV0YWlscyBv biBlYWNoIHR5cGUgLw0KTmV3L29mIHRoaXMgc2VjdGlvbiAoc2VjdGlvbiAyLjIpIGZvciBkZXRh aWxzIG9uIGVhY2ggdHlwZS8NCg0KU3VlIEhhcmVzDQoNCg0KRnJvbTogdHJpbGwgW21haWx0bzp0 cmlsbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VzYW4gSGFyZXMNClNlbnQ6IEZy aWRheSwgSmFudWFyeSAxMywgMjAxNyA4OjQ1IFBNDQpUbzogdHJpbGxAaWV0Zi5vcmc8bWFpbHRv OnRyaWxsQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtdHJpbGwtYWRkcmVzcy1mbHVzaEBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNoQGlldGYub3JnPjsgdHJp bGwtY2hhaXJzQGlldGYub3JnPG1haWx0bzp0cmlsbC1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbdHJpbGxdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNo ICgxLzEzLzIwMTcgdG8gMS8yNy8yMDE3KQ0KDQpUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMYXN0 IENhbGwgZm9yICgxLzEzLzIwMTcgdG8gMS8yNy8yMDE3KSBmb3IgZHJhZnQtaWV0Zi10cmlsbC1h ZGRyZXNzLWZsdXNoIHdoaWNoIHlvdSBjYW4gYWNjZXNzIGF0Og0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmlsbC1hZGRyZXNzLWZsdXNoLw0KDQpJbiB5b3Vy IHJldmlldyBwbGVhc2UgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoNCg0KMSkg ICAgICBEbyB5b3UgdGhpbmsgdGhpcyByZXF1ZXN0IGZyb20gb25lIFRSSUxMIFJicmlkZ2UgdG8g YW5vdGhlciBUUklMTCBSYnJpZGdlcyBpcyB1c2VmdWwgaW4gZGVwbG95bWVudHM/DQoNCjIpICAg ICAgRG9lcyBpdCBzdXBwbGVtZW50IFRSSUxMoa9zIGF1dG9tYXRpYyBhZGRyZXNzIGZvcmdldHRp bmcgYW5kIGFjaGlldmUgYmV0dGVyIGNvbnZlcmdlbmNlIHRpbWVzIHdoZW4gdG9wb2xvZ2llcyBv ciBjb25maWd1cmF0aW9uIGNoYW5nZXM/DQoNCjMpICAgICAgQXJlIHRoZSBtZWNoYW5pc21zIGRl c2NyaWJlZCBpbiB0aGlzIGRyYWZ0IHRlY2huaWNhbGx5IHNvdW5kIHdpdGhvdXQgYWRkaW5nIGxv dHMgb2YgY29tcGxleGl0eSB0byBUcmlsbD8NCg0KNCkgICAgICBJcyB0aGlzIGRvY3VtZW50IHJl YWR5IGZvciBwdWJsaWNhdGlvbj8NCg0KV2lsbCB0aGUgYXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUg aWYgdGhleSBrbm93IG9mIGFueSBJUFIgcmVsYXRpbmcgdG8gdGhpcyBkcmFmdCBpbiB0aGVpciBy ZXNwb25zZSB0byB0aGlzIFdHIExDPyAgSSB3b3VsZCBhcHByZWNpYXRlIGlmIHRoZSBhdXRob3Jz IHdpbGwgYW5zd2VyIHRoZXNlIGZvdXIgcXVlc3Rpb25zIGFzIHdlbGwuDQoNClN1ZSBIYXJlcw0K U2hlcGhlcmQNClRSSUxMIFdHIENvLWNoYWlyDQo= --_000_DD5FC8DE455C3348B94340C0AB5517336602DCB1nkgeml513mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks Sue, I will update the draft as per your comments ASAP.

weiguo

 

=B7=A2=BC=FE=C8=CB: Susan Hares [mailto:s= hares@ndzh.com]
=B7=A2=CB=CD= =CA=B1=BC=E4: 2017=C4=EA1=D4=C2<= span lang=3D"EN-US">14=C8=D5 23:10
=CA=D5=BC=FE=C8=CB: trill@ietf.org
=B3=AD=CB=CD: draft-ietf-trill-address-flush@ietf.org; trill-chairs@ietf.org
=D6=F7=CC=E2: RE: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to= 1/27/2017)

 

Weiquo,= Donald, Yizhou, and Mohammed:

&n= bsp;

Thank y= ou for your work on draft-ietf-trill-address-flush. This is a shepherd=A1= =AFs review for draft-ietf-trill-address-flush.    =A1=AE

&n= bsp;

Shep= herd=A1=AFs answer to questions:  

= 1)      Deployment experience =A8C No deployment experience, but this target actio= n has been useful in other protocols.

= 2)      Convergence experience =A8C No convergence measurement experience, but tar= geted convergence based on a centralized controllers can provide better con= vergence theoretically.

= 3)      Mechanisms comments below =A8C seem to be editorial, but may be minor.

= 4)      With editorial/minor changes =A8C document is ready for publication

&n= bsp;

&n= bsp;

Stat= us: Ready with mino= r/editorial comments. 

 

Mino= r/editorial changes:

&n= bsp;

#1 page= 10,m paragraph 2 =A8C after table, beginning with =A1=B0All RBridges imple= menting=A1=B1

&n= bsp;

Editori= al change:  The next 4 paragraph state requirements for processing nee= d to be clearly laid out.  A set of suggested text that replaces parag= raphs 2, 3, 4 (p. 10-11).

&n= bsp;

New:/

Process= ing Requirements:

&n= bsp;

The pro= cessing requirements based on support for Address Flush Channel message plu= s the additional types:  

&n= bsp;

=A1=A4      &n= bsp;  Basic RBridges functionality:  All RBridges supporting the Address Fl= ush Channel message MUST implement type 1 (Blocks of VLANs),  type 2 (= Bit map of VLANs), and type 6 (All Data labels).  Type 6 indicates that all addresses are to be flushed for all data labels.=

=  

=A1=A4      &n= bsp;  Optional RBridges functionality:  RBridges SHOULD implement types 7 a= nd type 8 so that specific MAC addresses can be can be flushed.  If a = set of RBridges does not implement types 7 and 8, the flush will be inefficient as those not intent to be flashed will ha= ve to be relearned.

=  

=A1=A4      &n= bsp;  FGL functionality : All RBridges implementing the FGL ingress/egress suppo= rt and the Address Flush Channel message MUST implement type 3 (Blocks of F= GLs), type 4 (Lists of FGLs), and type 5 (Bit Map of FGL).  An RBridge that is merely FGL safe [RFC7172], bu= t cannot egress TRILL data packets, SHOULD ignore the FGL types with the Ad= dress Flush Channel message as it will not learn any MAC addresses with FGL= scope from the MAC data plane.

&n= bsp;

Process= ing interactions:

&n= bsp;

The par= sing of the TLVs in an Rbridge Channel Message in the Address Flush Protoco= l Specific TLVS by a receiving bridge results in three items:

= 1)      All-Data-label-found flag indicating whether one or more types 6 TLVs (All= Data Labels) were encountered,

= 2)      A set of Data labels and blocks of data labels compiled from VLAN TLVs (ty= pes 1 and 2), and/or FGL TLVs (types 3, 4, and 5),

= 3)      If a MAC TLVs types (type 6 and 7)  are implemented, a set of MAC add= resses and Blocks of MAC addresses from the MAC TLVs.

&n= bsp;

For the= following flag settings, the processing is as follows:

= a)      If the set of MAC addresses and Block of MAC address is null (item 3 above= ) then Address Flush applies to all messages.

= b)      If the  All-Data-label-found flag (item 1 above) is true, then the ad= dress flush message applies to all data labels.  The set of Data label= and block of data labels (item 2 above) does not have any effect.

= c)       If the All-Data-label-found flag (item 1 above) is false, then the Address= Flush message applies to the set of Data labels (see item 2 above) found i= n VLAn TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and 5).   If the set of Data Labels (see = item 2 above) is null, the Address Flush message does nothing.

/<= /o:p>

&n= bsp;

&n= bsp;

#2 =A8C= editorial nits

#2.a) p= . 9, figure 4 =A8C bottom +-+ does not match top =A8C Is this what = you wanted or an error?  

#2.b) p= . 9, paragraph beginning  =A1=B0Type: The 8 bit=A1=B1

&n= bsp;

Old/ of= this Section 2.2 for details on each type /

New/of = this section (section 2.2) for details on each type/

&n= bsp;

Sue Har= es

&n= bsp;

&n= bsp;

From: trill [mail= to:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, January 13, 2017 8:45 PM
To: trill@ietf.org
Cc: draft= -ietf-trill-address-flush@ietf.org; trill-chairs@ietf.org
Subject: [trill] WG Last Call for draft-ietf-trill-address-flush (1/= 13/2017 to 1/27/2017)

 

This begins a 2 week WG Last Ca= ll for (1/13/2017 to 1/27/2017) for draft-ietf-trill-address-flush which yo= u can access at:

https://datatracker.ietf.org/= doc/draft-ietf-trill-address-flush/

 

In your review please consider = the following questions:

 

1= )   &= nbsp;  Do you think this reque= st from one TRILL Rbridge to another TRILL Rbridges is useful in deployment= s? 

2= )   &= nbsp;  Does it supplement TRIL= L=A1=AFs automatic address forgetting and achieve better convergence times = when topologies or configuration changes? 

3= )   &= nbsp;  Are the mechanisms desc= ribed in this draft technically sound without adding lots of complexity to = Trill?

4= )   &= nbsp;  Is this document ready = for publication?

 

Will the authors please indicat= e if they know of any IPR relating to this draft in their response to this = WG LC?  I would appreciate if the authors will answer these four quest= ions as well.

 

Sue Hares

Shepherd

TRILL WG Co-chair

--_000_DD5FC8DE455C3348B94340C0AB5517336602DCB1nkgeml513mbschi_-- From nobody Mon Jan 16 15:04:49 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A712985B; Mon, 16 Jan 2017 15:04:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 15:04:47 -0800 Archived-At: Cc: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, shares@ndzh.com, trill@ietf.org Subject: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 23:04:48 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-trill-directory-assist-mechanisms-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text, It might learn that information from the directory or could query the directory if it does not know. is "learning information from the directory" different from "querying the directory"? My apologies for not knowing TRILL well. I found this text, A Push Directory also advertises whether or not it believes it has pushed complete mapping information for a Data Label. to be odd ("directories believe things?"), and I'm wondering what that belief would be based on. If a Push Directory has pushed all the information it's currently storing, is that what's being described here? Or does this mean something else? In section 2.3.1, there are several states that refer to "enough time for propagation" - for example, Active Completing : Same behavior as the Active state except that the server responds differently to events. The purpose of this state is to be sure there has been enough time for directory information to propagate to subscribing edge TRILL switches before the Directory Server advertises that the information is complete. Is it possible to provide a pointer or reference that describes how "enough time" is calculated? I'm not sure whether this is referring to PushDirTimer in Section 2.7 or something else. It's a nit, but I think this text, TRILL switches, whether or not they are a Push Directory server, should be something like TRILL switches, whether or not they are Push Directory servers, - there's a numbering mismatch. I think this text, Thus, there is commonly a small window during which the an RBridge using directory information might either (1) drop or unnecessarily flood a frame as having an unknown unicast destination or (2) encapsulate a frame to an edge RBridge where the end station is not longer connected when the frame arrives at that edge RBridge. is garbled (somewhere around "during which the an RBridge"). In this text, Support of TRILL ES-IS is generally optional for both the TRILL switches and the end stations on a link but may be required to support certain features. can you give any guidance to the reader on how to know whether TRILL ES-IS support is required for a feature? From nobody Mon Jan 16 16:23:13 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB81126579; Mon, 16 Jan 2017 16:23:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148461258839.22482.5195721834167205640.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 16:23:08 -0800 Archived-At: Cc: trill-chairs@ietf.org, shares@ndzh.com, draft-ietf-trill-rfc6439bis@ietf.org, trill@ietf.org Subject: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-rfc6439bis-04: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 00:23:08 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-trill-rfc6439bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I had trouble parsing "output it to or queue it for" (this occurs twice in the sentence). However, it does not output it to or queue it for that link, although, if appropriate (for example, the frame is multi- destination), it may output it to or queue it for other links. I don't think the text is incorrect, just awkward. Perhaps commas would help? In these three subsection titles, 3.2.1 Change Optimization One 3.2.2 Change Optimization Two 3.2.3 Settling Detection Optimization I found the title for 3.2.3 helpful, but not 3.2.1 or 3.2.2. Is it possible to come up with more descriptive titles? I found For robustness, a TRILL switch sends a number of copies of a Port- Shutdown messages configurable from one to three, which defaults to two copies, at a configurable interval, which defaults to 20 milliseconds (see Section 6.6). difficult to parse. Perhaps For robustness, a TRILL switch sends a configurable number of copies of Port-Shutdown messages separated by a configurable interval. The default number of copies is two, although this can be configured as one copy or as three copies, and the default interval is 20 milliseconds (see Section 6.6). ? From nobody Mon Jan 16 17:49:22 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B51129929; Mon, 16 Jan 2017 17:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRERR0kDgcXr; Mon, 16 Jan 2017 17:49:16 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 5BEEB129695; Mon, 16 Jan 2017 17:49:16 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id 203so86066486ith.0; Mon, 16 Jan 2017 17:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xw73WrPYECg2Pr6uzEbPEurGDi84UB66mCng+BrE3rw=; b=edim9od7Ox8L61u+r1s6av+L/+UTxNDq3RAX7DN6GJLrTg/ne6ZWt7xZxYNUUVJvw+ MMw0aB4yKMWrroQjBKK16qux2xpCGwxSFDXk+wi70AoqeBbrXJWq3IKtZpKvwrXn7QhC mySLS24ApjCbKGjX1xZ2rvSyLUmQOSS/Blyan/4mBZX72Nftrn5XDUtBE7K+OqkHegU8 K5qJLw2DdZEzUe0a8712H2LL69FlWX5PTRoUDMTR+mEv+NTJzaxrmA9HZEn9kbQ687Fz 3g1ZPf1kKIBcRBnAv1TvXygfzpb0U1zFxO2z18CRq2xJgdLVZz2rNTpCVuinxjB38Bv4 j8AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xw73WrPYECg2Pr6uzEbPEurGDi84UB66mCng+BrE3rw=; b=N3uJOhp+i7FVsJuk8PZtBBz1Abq3xy9ms8KHt9SxO4UDpuYpumXP0stzZgVyW48tI+ s1/CWGMn2teJeOwwhDWR6r/ZFDBSUSBf7rGHDgkV9N/XWpazFXmnsutxXqG7L5hi01+A gC0eiOXPVes4Xgda05KmadnHCbTj+CsEDD6aoCV0TDBeiu2N0uUVi228/nxS59biKz3Y xoovSMldr6CVd4J59u/EaRDKkc0lkqbsZbpZF3KBXuCmRtNddRj9hdGUIi10Qq3CyCV6 424rL8ERibbkAXU4wiLldaOlBRFNmh7ROlk+uPsE4mRVvGC+Jb1zsfpo6PCELTx2BHGK HK1A== X-Gm-Message-State: AIkVDXIztnTZukm6B/iqBY8/6VmykZhgKs7/b033Lrp2Vmc9go3hbyqIqd59Z/0l3gnRmASZ1tJ+wG2jCDcSjg== X-Received: by 10.36.107.194 with SMTP id v185mr17360147itc.59.1484617755463; Mon, 16 Jan 2017 17:49:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Mon, 16 Jan 2017 17:48:59 -0800 (PST) In-Reply-To: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> References: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 16 Jan 2017 20:48:59 -0500 Message-ID: To: Dan Romascanu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ops-dir@ietf.org" , draft-ietf-trill-rfc6439bis.all@ietf.org, IETF Discussion , "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-rfc6439bis-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:49:18 -0000 Hi Dan, Thanks for your review. As per my further response below, while the draft could perhaps use some clarifying additions related to operations, I believe is as bad as you say. On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu wrote: > > Reviewer: Dan Romascanu > Review result: Has Issues > > I have reviewed this document as part of the Operational > directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the intent > of improving the operational aspects of the IETF drafts. Comments > that are not addressed in last call may be included in AD reviews > during the IESG review. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document clarifies and updates the TRILL Appointed > Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and > obsoletes RFC 6439. > > It's a complex document which requires extra reading to understand > the context and the interraction with other RFCs. I believe that > from an OPS-DIR perspective there are issues that need to be > discussed before the document can be approved. > > The main issues with the document in its current form are: > > 1. The document makes consistent changes in the way TRILL > operates. It replaces TLVs and procedures, define new ones, > obsoletes previous mechanisms that define VLAN mapping, and I am not aware of any case where this draft replaces a TLV in the sense of requiring use of a new TLV. It does provide some new TLVs and procedures that are believed to be superior to or useful additions to previous ones. But I am not aware of any case where it "obsoletes" previous provisions in the sense of prohibiting their use. > incorporates updated material from other RFCs. There is however no > indication in the text about the transition between existing > deployed versions of TRILL based on RFC 6439 and related protocols > with the current updated mechanisms. Are these backward compatible? I don't know that much is really required to be said about "transition" when you specify an optional optimization. Since it is optional, by implication the implementer is free to use it or not and things will work either way. This could be stated explicitly in those cases. Much of the material in this draft comes from RFC 6439 or the parts of RFC 7177 that updated RFC 6439. Most of the new material is optional improved behaviors. The only mandatory new behavior is the mandatory support of the link local E-L1CS flooding scope [RFC7357] specified in Section 8. There is material in this draft covering backwards compatibility for this new mandatory behavior. Section 8 already explains how to determine whether or not all TRILL switches on a link support E-L1CS flooding scope. The only use of E-L1CS flooding scope in this draft is as part of a mechanism for the DRB (Designated RBridge (TRILL switch)) to advertise Forwarder Appointments and, as stated in Section 2.1 (see paragraph at the bottom of page 8 in draft -04), if any RBridge on the link does not support E-L1CS, then the DRB MUST fall back to advertising those appointments in Hellos. Section 8, which mandates support of E-L1CS, also requires that any use of E-L1CS specified in the future must provide for backward compatibility. > Do they need a simultaneous upgrade of the whole network? No. > 2. The document lacks a section or even minimal text concerning > operational and manageability considerations. There are several Such a section can be added but there is not much to say. For example, as explained below, there is very little specified in this document to configure. > mentions in the text concerning network managers or operator > actions, but there is no indication or reference to what management > protocols and data models are to be used for configuration, RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs 6850 and 7784. However, there are also YANG modules underway in draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and draft-ietf-trill-yang-pm. It does not seem best for this rfc6439bis draft to change the implementation requirement level for SNMP or NETCONF for TRILL. If that were to be done, it seems like something more appropriate for the base TRILL YANG draft (draft-ietf-trill-yang-*) to do. > retrieval of operational status information, or alerts. I believe > that these need to be added explicitly or by reference. Reviewing the significant protocol additions in this draft at a high level: - There is significant material about the various ways the Designated RBridge on a link can announce who it is selecting as the Appointed Forwarder on the link for various VLANs. The election of the Designated RBridge depends on a configurable priority but that election is unchanged from RFC 7177 and in fact is identical to the election of the designated router on any IS-IS link. The decision on which RBridges to appointer as forwarder for which VLAN is out of scope. I don't see that there is anything to configure here, other than RBridge priority to be DRB, which is already specified in other RFCs. - There are some optional optimizations to the inhibition mechanism. The inhibition mechanism is necessary for loop safety but any RBridge can use or not use any of these optimizations, as they choose, and things will work fine. - Port Shutdown message: There are two new configuration parameters here, namely how many copies of the Port Shutdown message to send and at what interval. These are listed, along with units and default value in Section 6.6. - FGL-VLAN mapping consistency check: As specified in RFC 7172, in a TRILL campus supporting Fine Grained Labels (FGL), the VLAN of a native frame can be mapped to an FGL on ingress and an FGL is mapped to a VLAN on egress. This draft makes no changes to that mechanism. It merely provides that an RBridge performing such mapping can optionally advertise the mapping it is performing at a port to other RBridges with ports on the same link which can then check it for consistency with any mapping they are performing. It is recommended that the network operator be alerted to such inconsistency and there is a configurable parameter for how long the inconsistency needs to exist before such alert. Is it your position that some specific protocol mechanism must be specified by which the network operator is alerted? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Mon Jan 16 18:57:58 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF01294B8; Mon, 16 Jan 2017 18:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qu0R_1Mudydm; Mon, 16 Jan 2017 18:57:55 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 86FE4129675; Mon, 16 Jan 2017 18:57:55 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id c7so86903222itd.1; Mon, 16 Jan 2017 18:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Myfk9j9XLwZQwGERHwt+wUqvp/crpJiz7tCe4zDXY4s=; b=JdPhiKPjLfopImIM5wXIBXRAykcTH6D2/iVUibRwqm7P+z8T2Ur8zKs2Nx4CpnOCJk NgiP1EvqXwjYnJiha/9gR15AnTxMD67jQ3ttTN1gnzS5UG+1GtLmTNQ7cBl29/3PAfEF +dSQ/pLkmdeE1s7c2qo5Z8DTZPLnhYjW4c9Xhy1E+Fn2umnT0fCjIbH0is/BeoYPuLsF 5ZiHMlNlZlm38aJFsQ/X3eXaS9d8vpq00rV6VI/ZCw3b2yWuhXaO1GnZ0o3egMTVN78j 8uiQBEOvJYNyF/68SYesMZljqfStVi+0lhkNevAAyiuKftAn9GJ2jIyqCU3TAxGzbi8m PgXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Myfk9j9XLwZQwGERHwt+wUqvp/crpJiz7tCe4zDXY4s=; b=PMY1dwJz80LiGr0/hDaX156jr/mjCsi5u4wIfg6xchHKFHHxCWSoqe7PnNEROGvFB8 uRuo6FhNLf8w42M3J9hCKSlo0Yp/SDrskXgaVqYX5xXHoS9Y4zHrQniNzP5jNQEV7u78 SXLFfp+YSKsS+Wa63b8d1PRtQDz3BPUx+dN3YRZEHEp9B/ikPHi2onI8/rF6eRN0MVvi jZzUMRwYCJzgvk1SY/gC8oOsatl1flqTNda/uiQxvnhLhN34wsu3+r4HKpzKiBgJwtTK iI8NyLVtSPRThGEUXIxW6FI3HYF85cSHgvlrAD5pBp1wqWmx2To4WQQsEBziYOznN502 Ic/A== X-Gm-Message-State: AIkVDXJCYf5mB6QTlo7kAf7jwRCNHH/mopIzpe4OnhWaFsRcIFsQiQoruFGPWIAzmcaPlhny7KCVn9nxYIpY1A== X-Received: by 10.36.3.73 with SMTP id e70mr16884979ite.14.1484621874615; Mon, 16 Jan 2017 18:57:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Mon, 16 Jan 2017 18:57:39 -0800 (PST) In-Reply-To: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com> References: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 16 Jan 2017 21:57:39 -0500 Message-ID: To: Spencer Dawkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 02:57:56 -0000 Hi Spencer, Thanks for your thorough review. See below On Mon, Jan 16, 2017 at 6:04 PM, Spencer Dawkins wrote: > > Spencer Dawkins has entered the following ballot position for > draft-ietf-trill-directory-assist-mechanisms-11: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In this text, > > It might learn that information from > the directory or could query the directory if it does not know. > > is "learning information from the directory" different from "querying the > directory"? My apologies for not knowing TRILL well. It should probably say "It might have learned that information from the directory or could query the direction if it does not already know it." because it could be that either (1) it has been pushed to it by a Push Directory or (2) it could have pulled it from a Pull Directory and cached it. > I found this text, > > A Push Directory also advertises whether or not it > believes it has pushed complete mapping information for a Data > Label. > > to be odd ("directories believe things?"), and I'm wondering what that > belief would be based on. If a Push Directory has pushed all the > information it's currently storing, is that what's being described here? > Or does this mean something else? Not quite. It could be de-anthropomorphised and made more precise by saying something like "A Push Directory advertises when it both is configured to be a directory having complete information and has actually pushed all the information it has." > In section 2.3.1, there are several states that refer to "enough time for > propagation" - for example, > > Active Completing : Same behavior as the Active state except > that the server responds differently to events. The purpose of > this state is to be sure there has been enough time for directory > information to propagate to subscribing edge TRILL switches > before > the Directory Server advertises that the information is complete. > > Is it possible to provide a pointer or reference that describes how > "enough time" is calculated? I'm not sure whether this is referring to > PushDirTimer in Section 2.7 or something else. This propagation time, as you might expect, depends on network topology. The worst possible time for a network with a large number of TRILL switches could be impractically long. Yet, in a richly connected data center or Internet exchange with reasonably high bandwidth links, one second would be plenty of time. In this specification, the time in the time for "The Time Condition" as specified in Section 2.3.2, page 11 and is, indeed, PushDirTimer. It defaults to twice the CSNP time, which is related to the ESADI link state consistency time scale and is pretty conservative. It might be good to add some forward pointers to the places where there is this "enough time" wording. > It's a nit, but I think this text, > > TRILL switches, whether or not they are a Push Directory server, > > should be something like > > TRILL switches, whether or not they are Push Directory servers, > > - there's a numbering mismatch. OK > I think this text, > > Thus, there is commonly a > small window during which the an RBridge using directory information > might either (1) drop or unnecessarily flood a frame as having an > unknown unicast destination or (2) encapsulate a frame to an edge > RBridge where the end station is not longer connected when the frame > arrives at that edge RBridge. > > is garbled (somewhere around "during which the an RBridge"). Yes, the first occurrence of the word "the" should be deleted. > In this text, > > Support of TRILL ES-IS is generally optional for both the TRILL > switches and the end stations on a link but may be required to > support certain features. > > can you give any guidance to the reader on how to know whether TRILL > ES-IS support is required for a feature? Any feature that needs TRILL ES-IS needs to say so. TRILL ES-IS is specified in Section 5 which enumerates in its first paragraph the only existing use of TRILL ES-IS (Pull Directory hosting on and use by end stations) and the two anticipated uses of TRILL ES-IS (the trill-directory-assisted-encap and trill-smart-endnodes drafts). Probably the first and second paragraphs of Section 5 could be re-organized a bit to clarify this. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Tue Jan 17 00:45:47 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E52129446; Tue, 17 Jan 2017 00:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iGOkMUJY12xt; Tue, 17 Jan 2017 00:45:41 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 0636F129407; Tue, 17 Jan 2017 00:45:41 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id l7so145144277qtd.1; Tue, 17 Jan 2017 00:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lYBMwHm/pQnY5vTnX0NQhpL4R30Ejx8nCLFWsJy3SZ4=; b=hMiZjj531STDj+ygIzY9g9W6VakP9Y5VcyCdGqyd18Du+hQbFwHBK/Q4FF+OgrFM5n 1Ik8JPUcHiShDj0FLUI4qFWhe0hW4O1OkgjMv4GRMN/SQCSYsEUL6V/b/iSrljyna8f5 lXOsV1H8SkCbj2/W7jRf3wpddmo6a/wUmxUGqMSGidkxfiFzEtQFKv76t59LOfk0WfTj eaXufjPGoWan3aDVO/4gDJPs3rtuJgw6BdIqyCVSWD6ju726U/VWBRcTxYYrFDcAq7yj cTc66NzZx/RfRaMAr2yUYBdVZaTcpfbto1PXB1s00vFqAeXFy4X0tm4R/Lf4YAttHzCu zJmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lYBMwHm/pQnY5vTnX0NQhpL4R30Ejx8nCLFWsJy3SZ4=; b=TqjNuDRqgKw695Stf3yIEG9FOZ6uKU5aqXzta1Bz1a/cHXqyxfsZwxVhNtUjBhrPP0 uNkUFVn7W4uCK3N3trQDM6N9Okx+jpc7b+GbK9Dfrf3NcB7shS2EAgTZKNPekRmmcanz hl+sXqJua0mj+FcMcG/yoijXHLYQ3jihHvtH5S9VxmqAqHJiXZ7jmFLIp4I1ZC4Kwu7I ZZ8jYrYpHaqQExEzwBUEY2bmYV36ed0ZJaBkthqq1sdosRdKdyiJ6OFcanyoJXs2DPAg Sfdb1/yTjIWU56sVymmRr34LY6NIozhO1N6/v9qIu6cU91GbBdG1TLk9ExBQ4cHDuyLx za6w== X-Gm-Message-State: AIkVDXKyCG/rPez/+sxOd6OqHJWmCAj7+UtQeNqK2p/GhZ5ExT55GTOW960JurwI4k43ybfgwQaNXr4qiCCbXg== X-Received: by 10.237.61.20 with SMTP id g20mr36144899qtf.272.1484642740025; Tue, 17 Jan 2017 00:45:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.11 with HTTP; Tue, 17 Jan 2017 00:45:39 -0800 (PST) In-Reply-To: References: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> From: Dan Romascanu Date: Tue, 17 Jan 2017 10:45:39 +0200 Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a11432912234afc0546465301 Archived-At: Cc: "ops-dir@ietf.org" , draft-ietf-trill-rfc6439bis.all@ietf.org, IETF Discussion , "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-rfc6439bis-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 08:45:43 -0000 --001a11432912234afc0546465301 Content-Type: text/plain; charset=UTF-8 Hi Donald, Thank you for your answer and explanations. They make sense to me, but I still beleive that the document may benefit if some edits are being done to clarify what may be the obvious for the people who know all details and history, but not for the other users of the document in the future - implementers and operators. Specifically: > I am not aware of any case where this draft replaces a TLV in the sense of requiring use of a new TLV. It does provide some new TLVs and procedures that are believed to be superior to or useful additions to previous ones. But I am not aware of any case where it "obsoletes" previous provisions in the sense of prohibiting their use. The header of the document includes Obsoletes 6439. If part of the content of 6439 remains valid this needs to be clarified, If some superior TLVs and procedures are introduced there is a need to explain what will happen with the previous ones. Should they be implemented? deployed? activated? > I don't know that much is really required to be said about "transition" when you specify an optional optimization. Since it is optional, by implication the implementer is free to use it or not and things will work either way. This could be stated explicitly in those cases. If I understand what you say, the new features are optional (although the status of the document is Proposed Standard), they can or cannot be implemented (one, the other, both?) and the network will still work. Yes, I suggest to explicitly state this). > RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs 6850 and 7784. However, there are also YANG modules underway in draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and draft-ietf-trill-yang-pm. > It does not seem best for this rfc6439bis draft to change the implementation requirement level for SNMP or NETCONF for TRILL. If that were to be done, it seems like something more appropriate for the base TRILL YANG draft (draft-ietf-trill-yang-*) to do. If I was an implementer of TRILL, or an operator considering to deploy TRILL, I would have a hard time trying to understand what to implement and what to deploy as management interfaces. Maybe this is not the place but I believe that there need to be some documentation on this respect. Thanks and Regards, Dan On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake wrote: > Hi Dan, > > Thanks for your review. As per my further response below, while the > draft could perhaps use some clarifying additions related to > operations, I believe is as bad as you say. > > On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu > wrote: > > > > Reviewer: Dan Romascanu > > Review result: Has Issues > > > > I have reviewed this document as part of the Operational > > directorate's ongoing effort to review all IETF documents being > > processed by the IESG. These comments were written with the intent > > of improving the operational aspects of the IETF drafts. Comments > > that are not addressed in last call may be included in AD reviews > > during the IESG review. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > This document clarifies and updates the TRILL Appointed > > Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and > > obsoletes RFC 6439. > > > > It's a complex document which requires extra reading to understand > > the context and the interraction with other RFCs. I believe that > > from an OPS-DIR perspective there are issues that need to be > > discussed before the document can be approved. > > > > The main issues with the document in its current form are: > > > > 1. The document makes consistent changes in the way TRILL > > operates. It replaces TLVs and procedures, define new ones, > > obsoletes previous mechanisms that define VLAN mapping, and > > I am not aware of any case where this draft replaces a TLV in the > sense of requiring use of a new TLV. It does provide some new TLVs > and procedures that are believed to be superior to or useful additions > to previous ones. But I am not aware of any case where it "obsoletes" > previous provisions in the sense of prohibiting their use. > > > incorporates updated material from other RFCs. There is however no > > indication in the text about the transition between existing > > deployed versions of TRILL based on RFC 6439 and related protocols > > with the current updated mechanisms. Are these backward compatible? > > I don't know that much is really required to be said about > "transition" when you specify an optional optimization. Since it is > optional, by implication the implementer is free to use it or not and > things will work either way. This could be stated explicitly in those > cases. > > Much of the material in this draft comes from RFC 6439 or the parts of > RFC 7177 that updated RFC 6439. Most of the new material is optional > improved behaviors. > > The only mandatory new behavior is the mandatory support of the link > local E-L1CS flooding scope [RFC7357] specified in Section 8. There is > material in this draft covering backwards compatibility for this new > mandatory behavior. Section 8 already explains how to determine > whether or not all TRILL switches on a link support E-L1CS flooding > scope. The only use of E-L1CS flooding scope in this draft is as part > of a mechanism for the DRB (Designated RBridge (TRILL switch)) to > advertise Forwarder Appointments and, as stated in Section 2.1 (see > paragraph at the bottom of page 8 in draft -04), if any RBridge on the > link does not support E-L1CS, then the DRB MUST fall back to > advertising those appointments in Hellos. Section 8, which mandates > support of E-L1CS, also requires that any use of E-L1CS specified in > the future must provide for backward compatibility. > > > Do they need a simultaneous upgrade of the whole network? > > No. > > > 2. The document lacks a section or even minimal text concerning > > operational and manageability considerations. There are several > > Such a section can be added but there is not much to say. For example, > as explained below, there is very little specified in this document to > configure. > > > mentions in the text concerning network managers or operator > > actions, but there is no indication or reference to what management > > protocols and data models are to be used for configuration, > > RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) > SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs > 6850 and 7784. However, there are also YANG modules underway in > draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and > draft-ietf-trill-yang-pm. > > It does not seem best for this rfc6439bis draft to change the > implementation requirement level for SNMP or NETCONF for TRILL. If that > were to be done, it seems like something more appropriate for the base > TRILL YANG draft (draft-ietf-trill-yang-*) to do. > > > retrieval of operational status information, or alerts. I believe > > that these need to be added explicitly or by reference. > > Reviewing the significant protocol additions in this draft at a high > level: > > - There is significant material about the various ways the Designated > RBridge on a link can announce who it is selecting as the Appointed > Forwarder on the link for various VLANs. The election of the > Designated RBridge depends on a configurable priority but that > election is unchanged from RFC 7177 and in fact is identical to the > election of the designated router on any IS-IS link. The decision on > which RBridges to appointer as forwarder for which VLAN is out of > scope. I don't see that there is anything to configure here, other > than RBridge priority to be DRB, which is already specified in other > RFCs. > > - There are some optional optimizations to the inhibition mechanism. > The inhibition mechanism is necessary for loop safety but any > RBridge can use or not use any of these optimizations, as they > choose, and things will work fine. > > - Port Shutdown message: There are two new configuration parameters > here, namely how many copies of the Port Shutdown message to send > and at what interval. These are listed, along with units and default > value in Section 6.6. > > - FGL-VLAN mapping consistency check: As specified in RFC 7172, in a > TRILL campus supporting Fine Grained Labels (FGL), the VLAN of a > native frame can be mapped to an FGL on ingress and an FGL is mapped > to a VLAN on egress. This draft makes no changes to that mechanism. > It merely provides that an RBridge performing such mapping can > optionally advertise the mapping it is performing at a port to other > RBridges with ports on the same link which can then check it for > consistency with any mapping they are performing. It is recommended > that the network operator be alerted to such inconsistency and there > is a configurable parameter for how long the inconsistency needs to > exist before such alert. Is it your position that some specific > protocol mechanism must be specified by which the network operator > is alerted? > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --001a11432912234afc0546465301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Donald,

Thank you for your answer and explanations. They make sense to me, but I = still beleive that the document may benefit if some edits are being done to= clarify what may be the obvious for the people who know all details and hi= story, but not for the other users of the document in the future - implemen= ters and operators.

Specifically:

> I am not aware= of any case where this draft replaces a TLV in the
sense of requiring use of a new TLV.=C2=A0 It does provide some new TLVs and procedures that are believed to be superior to or useful additions
to previous ones. But I am not aware of any case where it "obsoletes&q= uot;
previous provisions in the sense of prohibiting their use.

The= header of the document includes Obsoletes 6439. If part of the content of = 6439 remains valid this needs to be clarified, If some superior TLVs and pr= ocedures are introduced there is a need to explain what will happen with th= e previous ones. Should they be implemented? deployed? activated?

&= gt; I don't know that much is really required to be said about
"transition" when you specify an optional optimization. Since it = is
optional, by implication the implementer is free to use it or not and
things will work either way. This could be stated explicitly in those
cases.

If I understand what you say, the new features are opti= onal (although the status of the document is Proposed Standard), they can o= r cannot be implemented (one, the other, both?) and the network will=C2=A0 = still work. Yes, I suggest to explicitly state this).

> RFC 6325,= the base TRILL protocol RFC, says TRILL switches (RBridges)
SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs
6850 and 7784. However, there are also YANG modules underway in
draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and
draft-ietf-trill-yang-pm.

> It does not seem best for this rfc6439bis draft to change the
implementation requirement level for SNMP or NETCONF for TRILL. If that
were to be done, it seems like something more appropriate for the base
TRILL YANG draft (draft-ietf-trill-yang-*) to do.

If I was an = implementer of TRILL, or an operator considering to deploy TRILL, I would h= ave a hard time trying to understand what to implement and what to deploy a= s management interfaces. Maybe this is not the place but I believe that the= re need to be some documentation on this respect.

Thanks and = Regards,

Dan


On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake <d3e= 3e3@gmail.com> wrote:
Hi Da= n,

Thanks for your review. As per my further response below, while the
draft could perhaps use some clarifying additions related to
operations, I believe is as bad as you say.

On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu <dromasca@gmail.com>
wrote:
>
> Reviewer: Dan Romascanu
> Review result: Has Issues
>
> I have reviewed this document as part of the Operational
> directorate's ongoing effort to review all IETF documents being > processed by the IESG.=C2=A0 These comments were written with the inte= nt
> of improving the operational aspects of the IETF drafts. Comments
> that are not addressed in last call may be included in AD reviews
> during the IESG review.=C2=A0 Document editors and WG chairs should tr= eat
> these comments just like any other last call comments.
>
> This document clarifies and updates the TRILL Appointed
>=C2=A0 Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and<= br> >=C2=A0 obsoletes RFC 6439.
>
> It's a complex document which requires extra reading to understand=
> the context and the interraction with other RFCs. I believe that
> from an OPS-DIR perspective there are issues that need to be
> discussed before the document can be approved.
>
> The main issues with the document in its current form are:
>
> 1. The document makes consistent changes in the way TRILL
> operates. It replaces TLVs and procedures, define new ones,
> obsoletes previous mechanisms that define VLAN mapping, and

I am not aware of any case where this draft replaces a TLV in the sense of requiring use of a new TLV.=C2=A0 It does provide some new TLVs and procedures that are believed to be superior to or useful additions
to previous ones. But I am not aware of any case where it "obsoletes&q= uot;
previous provisions in the sense of prohibiting their use.

> incorporates updated material from other RFCs. There is however no
> indication in the text about the transition between existing
> deployed versions of TRILL based on RFC 6439 and related protocols
> with the current updated mechanisms. Are these backward compatible?
I don't know that much is really required to be said about
"transition" when you specify an optional optimization. Since it = is
optional, by implication the implementer is free to use it or not and
things will work either way. This could be stated explicitly in those
cases.

Much of the material in this draft comes from RFC 6439 or the parts of
RFC 7177 that updated RFC 6439. Most of the new material is optional
improved behaviors.

The only mandatory new behavior is the mandatory support of the link
local E-L1CS flooding scope [RFC7357] specified in Section 8. There is
material in this draft covering backwards compatibility for this new
mandatory behavior.=C2=A0 Section 8 already explains how to determine
whether or not all TRILL switches on a link support E-L1CS flooding
scope. The only use of E-L1CS flooding scope in this draft is as part
of a mechanism for the DRB (Designated RBridge (TRILL switch)) to
advertise Forwarder Appointments and, as stated in Section 2.1 (see
paragraph at the bottom of page 8 in draft -04), if any RBridge on the
link does not support E-L1CS, then the DRB MUST fall back to
advertising those appointments in Hellos. Section 8, which mandates
support of E-L1CS, also requires that any use of E-L1CS specified in
the future must provide for backward compatibility.

> Do they need a simultaneous upgrade of the whole network?

No.

> 2. The document lacks a section or even minimal text concerning
> operational and manageability considerations.=C2=A0 There are several<= br>
Such a section can be added but there is not much to say. For exampl= e,
as explained below, there is very little specified in this document to
configure.

> mentions in the text concerning network managers or operator
> actions, but there is no indication or reference to what management > protocols and data models are to be used for configuration,

RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges= )
SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs
6850 and 7784. However, there are also YANG modules underway in
draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and
draft-ietf-trill-yang-pm.

It does not seem best for this rfc6439bis draft to change the
implementation requirement level for SNMP or NETCONF for TRILL. If that
were to be done, it seems like something more appropriate for the base
TRILL YANG draft (draft-ietf-trill-yang-*) to do.

> retrieval of operational status information, or alerts. I believe
> that these need to be added explicitly or by reference.

Reviewing the significant protocol additions in this draft at a high=
level:

- There is significant material about the various ways the Designated
=C2=A0 RBridge on a link can announce who it is selecting as the Appointed<= br> =C2=A0 Forwarder on the link for various VLANs. The election of the
=C2=A0 Designated RBridge depends on a configurable priority but that
=C2=A0 election is unchanged from RFC 7177 and in fact is identical to the<= br> =C2=A0 election of the designated router on any IS-IS link. The decision on=
=C2=A0 which RBridges to appointer as forwarder for which VLAN is out of =C2=A0 scope. I don't see that there is anything to configure here, oth= er
=C2=A0 than RBridge priority to be DRB, which is already specified in other=
=C2=A0 RFCs.

- There are some optional optimizations to the inhibition mechanism.
=C2=A0 The inhibition mechanism is necessary for loop safety but any
=C2=A0 RBridge can use or not use any of these optimizations, as they
=C2=A0 choose, and things will work fine.

- Port Shutdown message: There are two new configuration parameters
=C2=A0 here, namely how many copies of the Port Shutdown message to send =C2=A0 and at what interval. These are listed, along with units and default=
=C2=A0 value in Section 6.6.

- FGL-VLAN mapping consistency check: As specified in RFC 7172, in a
=C2=A0 TRILL campus supporting Fine Grained Labels (FGL), the VLAN of a
=C2=A0 native frame can be mapped to an FGL on ingress and an FGL is mapped=
=C2=A0 to a VLAN on egress. This draft makes no changes to that mechanism.<= br> =C2=A0 It merely provides that an RBridge performing such mapping can
=C2=A0 optionally advertise the mapping it is performing at a port to other=
=C2=A0 RBridges with ports on the same link which can then check it for
=C2=A0 consistency with any mapping they are performing. It is recommended<= br> =C2=A0 that the network operator be alerted to such inconsistency and there=
=C2=A0 is a configurable parameter for how long the inconsistency needs to<= br> =C2=A0 exist before such alert. Is it your position that some specific
=C2=A0 protocol mechanism must be specified by which the network operator =C2=A0 is alerted?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

--001a11432912234afc0546465301-- From nobody Tue Jan 17 06:22:21 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919BC1294A2; Tue, 17 Jan 2017 06:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3UEa_DUdks0; Tue, 17 Jan 2017 06:22:14 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 E3A12126D73; Tue, 17 Jan 2017 06:22:13 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id v96so115489230ioi.0; Tue, 17 Jan 2017 06:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=69EA2iYv/nlHmPBOqh4apb96GYpx8u6NQuzjxNOf3NM=; b=QPtXD3ZrmOeiFF08esAso5y9UIHlZE4zBIfaWdQnHf4xLN6wc6PamLVZqJB+BYz8/R l/B2AT4ZuZ9Ulou5NQTMFfYFRo4I9p7mYwOlX+Rfp0/vtYEsWAA/3cZMb2sWWy937g1m vaIWVdtVbuMcOlMIciLJih3rIhCYyFUkCrbvJ9wPD5qoDcbziv7NugHeKUz67RoOPnRk uTXIUVmskeqSE6AG4HBndnkMZbVvLopYu794pKtFEhxOojPg21UI3rCj7LK+kaHqbYfg DcaEaDF+6JQ/3W39NbP9UC/Z8F3O+J5mjkdoPeG7Z+CZyUN/bzXFo2oSUY/l2o8Wofbw Kb7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=69EA2iYv/nlHmPBOqh4apb96GYpx8u6NQuzjxNOf3NM=; b=Edh94eqWGP1Dmb6JM2nDcyKlR0tiK5StHNcmKZcvOAws9hxmn7s8PDuBJZZnzggL3d xC3KojeYslIRZNTK+V0vz6Qq0IgMr9loBchzoJRdqa6m+S6r8mW9VbzQvWR6EieV7Xht YqYatXSXvfA6PTOIIdctdJwvdXO1Re6mXWQ6Jvd3eB8NTifK+FWRsF3xCI8e3BtHpH41 gsVpahUgGYUZ7lDmPhKBWfzn9E2AM4R6yddlsnILSgFswQjcSAYAEHewzHmNjPaDA80w /2MGKeK64OgsLtX7Ae4eTCxkk+GfYAKApS6iYN7kQq8HLtC/ZGMy8DtaRPRT7wGSJShr euZA== X-Gm-Message-State: AIkVDXL9alwartGW2uEaZ6Ef/iq3PTGEaU/tvPgy0WlfllD8CcVC1COkkbEyzIBp/CXEs7bLvPWx42CiVRSAIQ== X-Received: by 10.107.141.80 with SMTP id p77mr34468141iod.97.1484662933082; Tue, 17 Jan 2017 06:22:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Tue, 17 Jan 2017 06:21:57 -0800 (PST) In-Reply-To: <148461258839.22482.5195721834167205640.idtracker@ietfa.amsl.com> References: <148461258839.22482.5195721834167205640.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 17 Jan 2017 09:21:57 -0500 Message-ID: To: Spencer Dawkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , "trill@ietf.org" , The IESG , draft-ietf-trill-rfc6439bis@ietf.org, Susan Hares Subject: Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-rfc6439bis-04: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:22:16 -0000 Hi Spencer, Thanks for the comments. See below On Mon, Jan 16, 2017 at 7:23 PM, Spencer Dawkins wrote: > > Spencer Dawkins has entered the following ballot position for > draft-ietf-trill-rfc6439bis-04: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I had trouble parsing "output it to or queue it for" (this occurs twice > in the sentence). > > However, it does not output it to or queue it for that link, > although, if appropriate (for example, the frame is multi- > destination), it may output it to or queue it for other links. It's kind of verbose but I believe that actual output port implementations typically provide for directly streaming out a packet even as other parts of the packet are still arriving at the switch, particularly in cut-through routing, or just sticking it in a queue for output later if the port is busy. Do you have any suggestion for better wording? > I don't think the text is incorrect, just awkward. Perhaps commas would > help? > > In these three subsection titles, > > 3.2.1 Change Optimization One > > 3.2.2 Change Optimization Two > > 3.2.3 Settling Detection Optimization > > I found the title for 3.2.3 helpful, but not 3.2.1 or 3.2.2. Is it > possible to come up with more descriptive titles? That's a reasonable point. Maybe 3.2.1 Optimization for Change to Lower Priority 3.2.2 Optimization for Change to Priority Only > I found > > For robustness, a TRILL switch sends a number of copies of a Port- > Shutdown messages configurable from one to three, which defaults to > two copies, at a configurable interval, which defaults to 20 > milliseconds (see Section 6.6). > > difficult to parse. Perhaps > > For robustness, a TRILL switch sends a configurable number of copies > of Port-Shutdown messages separated by a configurable interval. The > default > number of copies is two, although this can be configured as one copy > or as three copies, and the default interval is 20 milliseconds > (see Section 6.6). > > ? Sure, that seems like an improvement. Might also be good to say "time interval" instead of just "interval". Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Tue Jan 17 08:42:51 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3C1299E6; Tue, 17 Jan 2017 08:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xyQfIBo4658N; Tue, 17 Jan 2017 08:42:44 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 BA563129565; Tue, 17 Jan 2017 08:42:44 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id l23so45123014ybj.2; Tue, 17 Jan 2017 08:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vFroCA6CbKOWlTeYrkkR+zSC5K1L+WxvaGxQFh9WYLM=; b=LN5RD+k19AtnwHi9IBHrE0v1Dj9xldtNK61Ha5oq1L/HOdMG3XfUDJrNza8EZJOOuz 6S1aqSvhM2+Q2GDj88sS1y9A8dWY69o0empT+QQTAriZggPr8g4brQ8ver5NkK/1oP1r PP5X0kQgn9gOQhc5ovmbAz7clX6PKWDkhVTBGmHRV8m3B8IF+hJT4UBjED+iwQFA9Jgd K4uXjeHt8GNKzI2wNgyvAIyxv0JNXpeHvgclBXaE4yUdQIfTDyhmR+c/v/b6vTC1SSbm qXWze12iF6xUEqqzdYLNEGljqNs8NiiEKPHVZcrjwSY31Pvld0cD/qn+uzhcmkZv0rEe 5++g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vFroCA6CbKOWlTeYrkkR+zSC5K1L+WxvaGxQFh9WYLM=; b=rMCeZGWxRJaOfQmWzQP4LBkvt9WXSkRw3DKRvVGeXUpAdbH/FdIA+l738xcwqlFcZb Qqlz9FLpQOUQ73zHd/vENTK7OL1dzafz/okhud9hZ+weF0+c4egI2Lrqe47neoHykdsz I1PqqgTnGP1un+IIu6ABOL7oeMS+FRS2j75Homylqe2HRnZl+J5HvO2lSZQUDwiZniWQ BW3KHR0mb+Aiwdjn4dyFjnmYaLYWtW17vVVhXXuf7LuKBT9bjqrm7Wdq0KQdAYW0Qmfz NHpR1luemmjBEAXeY5XcqX/+LOkeH8Q0s2w6azvIYUWZJcUf/ongZKzGieNG+WVRb6m9 w9TA== X-Gm-Message-State: AIkVDXLfz49GcOAqs9ZVejuSyqCyHbPMMU9Rkcag6TlZS5HtWwtGpr25aougaEigiq4P9Fez3OeeCn9Uy4f6QQ== X-Received: by 10.37.92.68 with SMTP id q65mr25872327ybb.12.1484671363906; Tue, 17 Jan 2017 08:42:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.221.4 with HTTP; Tue, 17 Jan 2017 08:42:43 -0800 (PST) In-Reply-To: References: <148461258839.22482.5195721834167205640.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 17 Jan 2017 10:42:43 -0600 Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a1140f82041023005464cfd08 Archived-At: Cc: "trill-chairs@ietf.org" , "trill@ietf.org" , The IESG , draft-ietf-trill-rfc6439bis@ietf.org, Susan Hares Subject: Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-rfc6439bis-04: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:42:46 -0000 --001a1140f82041023005464cfd08 Content-Type: text/plain; charset=UTF-8 Hi, Donald, On Tue, Jan 17, 2017 at 8:21 AM, Donald Eastlake wrote: > Hi Spencer, > > Thanks for the comments. See below > > On Mon, Jan 16, 2017 at 7:23 PM, Spencer Dawkins > wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-trill-rfc6439bis-04: No Objection > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I had trouble parsing "output it to or queue it for" (this occurs twice > > in the sentence). > > > > However, it does not output it to or queue it for that link, > > although, if appropriate (for example, the frame is multi- > > destination), it may output it to or queue it for other links. > > It's kind of verbose but I believe that actual output port > implementations typically provide for directly streaming out a packet > even as other parts of the packet are still arriving at the switch, > particularly in cut-through routing, or just sticking it in a queue > for output later if the port is busy. Do you have any suggestion for > better wording? > I was thinking that However, it does not output it to, or queue it for, that link, although, if appropriate (for example, the frame is multi- destination), it may output it to, or queue it for, other links. might be clearer. If the RFC Editor removes the commas, of course, you can slap me in Chicago ;-) Spencer > > > I don't think the text is incorrect, just awkward. Perhaps commas would > > help? > > > > In these three subsection titles, > > > > 3.2.1 Change Optimization One > > > > 3.2.2 Change Optimization Two > > > > 3.2.3 Settling Detection Optimization > > > > I found the title for 3.2.3 helpful, but not 3.2.1 or 3.2.2. Is it > > possible to come up with more descriptive titles? > > That's a reasonable point. Maybe > > 3.2.1 Optimization for Change to Lower Priority > > 3.2.2 Optimization for Change to Priority Only > > > > I found > > > > For robustness, a TRILL switch sends a number of copies of a Port- > > Shutdown messages configurable from one to three, which defaults to > > two copies, at a configurable interval, which defaults to 20 > > milliseconds (see Section 6.6). > > > > difficult to parse. Perhaps > > > > For robustness, a TRILL switch sends a configurable number of copies > > of Port-Shutdown messages separated by a configurable interval. The > > default > > number of copies is two, although this can be configured as one copy > > or as three copies, and the default interval is 20 milliseconds > > (see Section 6.6). > > > > ? > > Sure, that seems like an improvement. Might also be good to say "time > interval" instead of just "interval". > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --001a1140f82041023005464cfd08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Donald,

On Tue, Jan 17, 2017 at 8:21 AM, Donald Eastlake <d3e3e3@gmail.c= om> wrote:
Hi Spencer,

Thanks for the comments. See below

On Mon, Jan 16, 2017 at 7:23 PM, Spencer Dawkins
<spencerdawkins.ietf@gm= ail.com> wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-trill-rfc6439bis-04: No Objection
>
> -----------------------------------= -----------------------------------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I had trouble parsing "output it to or queue it for" (this o= ccurs twice
> in the sentence).
>
>=C2=A0 =C2=A0 However, it does not output it to or queue it for that li= nk,
>=C2=A0 =C2=A0 although, if appropriate (for example, the frame is multi= -
>=C2=A0 =C2=A0 destination), it may output it to or queue it for other l= inks.

It's kind of verbose but I believe that actual output port
implementations typically provide for directly streaming out a packet
even as other parts of the packet are still arriving at the switch,
particularly in cut-through routing, or just sticking it in a queue
for output later if the port is busy. Do you have any suggestion for
better wording?

I was thinking that=C2= =A0

=C2=A0 =C2=A0 However, it does not output it t= o, or queue it for, that link,
=C2=A0=C2=A0 =C2=A0although, if ap= propriate (for example, the frame is multi-
=C2=A0 =C2=A0destinat= ion), it may output it to, or queue it for, other links.

might be clearer.=C2=A0

If the RFC Editor r= emoves the commas, of course, you can slap me in Chicago ;-)

=
Spencer=C2=A0

> I don't think the text is incorrect, just awkward. Perhaps commas = would
> help?
>
> In these three subsection titles,
>
>=C2=A0 =C2=A0 3.2.1 Change Optimization One
>
>=C2=A0 =C2=A0 3.2.2 Change Optimization Two
>
>=C2=A0 =C2=A0 3.2.3 Settling Detection Optimization
>
> I found the title for 3.2.3 helpful, but not 3.2.1 or 3.2.2. Is it
> possible to come up with more descriptive titles?

That's a reasonable point. Maybe

=C2=A0 =C2=A03.2.1 Optimization for Change to Lower Priority

=C2=A0 =C2=A03.2.2 Optimization for Change to Priority Only


> I found
>
>=C2=A0 =C2=A0 For robustness, a TRILL switch sends a number of copies o= f a Port-
>=C2=A0 =C2=A0 Shutdown messages configurable from one to three, which d= efaults to
>=C2=A0 =C2=A0 two copies, at a configurable interval, which defaults to= 20
>=C2=A0 =C2=A0 milliseconds (see Section 6.6).
>
> difficult to parse. Perhaps
>
>=C2=A0 =C2=A0 For robustness, a TRILL switch sends a configurable numbe= r of copies
>=C2=A0 =C2=A0 of Port-Shutdown messages separated by a configurable int= erval. The
> default
>=C2=A0 =C2=A0 number of copies is two, although this can be configured = as one copy
>=C2=A0 =C2=A0 or as three copies, and the default interval is 20 millis= econds
>=C2=A0 =C2=A0 (see Section 6.6).
>
> ?

Sure, that seems like an improvement. Might also be good to say &quo= t;time
interval" instead of just "interval".

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

--001a1140f82041023005464cfd08-- From nobody Tue Jan 17 12:05:36 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBA31294D7; Tue, 17 Jan 2017 12:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNF-AoGc9l37; Tue, 17 Jan 2017 12:05:33 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 412A8129468; Tue, 17 Jan 2017 12:05:33 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id c7so103200808itd.1; Tue, 17 Jan 2017 12:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zBrXEsXxtAMSGNK4anHrTpx1NDxwBkc9NqOTRJw2kQE=; b=jjBnZDS3M5FL8n/skTfnX3HympBxYqTSctA8dyv2JbYLEmJ2qWDQfXCcJRz5qrmR0f h4G/MKUy3dvqGgYdnNvnEp4UfJPyF6/nQyaXdtEZp/xIKTHpzWkcBdO10SAKYx/VQSsx vMDpQ57yVCq9toY9ljLGZs97/haN27923G0aqjm10NGlYofEZPLALP474+6LzKkVi488 5Gzr7LVGqDeBpZsQwBAqrB4HL75JSQsGJr0++wjNJQ7ToL7PA9BHPKkbC+XhdhxO6qAA /m1crKVPCJFmW8INWc1P6uJ83LMneM7peUw9b55+xYMozCoviVxOq71qaPhNOOmMoeVv cB0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zBrXEsXxtAMSGNK4anHrTpx1NDxwBkc9NqOTRJw2kQE=; b=ZDtm8C/xrLr1+RhW0Zzg6j/cvjqHz0WgwC3IO7ShxliZhgEzxXRBVJ8hjBKuhiymNu xvEq0nTluqfj4Whr7oToewTqp30ssiMaHadtK/+9rTJmq54xm/kp/E+Xuka5vWQk0BZ7 9bogFYn8ranZAFptKEGXqPL6UKRpjSd0nwMdQdrBs6hrKHTLTYdFUKjAfkf6dk+RVw9Y iNn9klEIFpWIn5hfDEx8JcGgz33No7jppe8OrtNV3PT6jTLAIkhIY7DtGI+cnPeKkipb u09iwaYcV7gEHzSsePE6MsdjX4A+fMk9i1+D9rbp03OCGNjk334iohGlUkqj+7a1i8Hp wCkg== X-Gm-Message-State: AIkVDXKuGTBBzpIReTrbrJgXgPTRizrlt9HQjUblDeh0l9OjddQtmk8TOeSwo5kZBOdBMWQtZ+/fNNAqElbhgA== X-Received: by 10.36.60.7 with SMTP id m7mr21172390ita.7.1484683532368; Tue, 17 Jan 2017 12:05:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Tue, 17 Jan 2017 12:05:16 -0800 (PST) In-Reply-To: References: <148461258839.22482.5195721834167205640.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 17 Jan 2017 15:05:16 -0500 Message-ID: To: Spencer Dawkins at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , "trill@ietf.org" , The IESG , draft-ietf-trill-rfc6439bis@ietf.org, Susan Hares Subject: Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-rfc6439bis-04: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:05:34 -0000 Hi Spencer, On Tue, Jan 17, 2017 at 11:42 AM, Spencer Dawkins at IETF wrote: > Hi, Donald, > > On Tue, Jan 17, 2017 at 8:21 AM, Donald Eastlake wrote: >> >> Hi Spencer, >> >> Thanks for the comments. See below >> >> On Mon, Jan 16, 2017 at 7:23 PM, Spencer Dawkins >> wrote: >> > >> > Spencer Dawkins has entered the following ballot position for >> > draft-ietf-trill-rfc6439bis-04: No Objection >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I had trouble parsing "output it to or queue it for" (this occurs twice >> > in the sentence). >> > >> > However, it does not output it to or queue it for that link, >> > although, if appropriate (for example, the frame is multi- >> > destination), it may output it to or queue it for other links. >> >> It's kind of verbose but I believe that actual output port >> implementations typically provide for directly streaming out a packet >> even as other parts of the packet are still arriving at the switch, >> particularly in cut-through routing, or just sticking it in a queue >> for output later if the port is busy. Do you have any suggestion for >> better wording? > > > I was thinking that > > However, it does not output it to, or queue it for, that link, > although, if appropriate (for example, the frame is multi- > destination), it may output it to, or queue it for, other links. > > might be clearer. OK. That looks good to me. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > If the RFC Editor removes the commas, of course, you can slap me in Chicago > ;-) > > Spencer >> >> >> > I don't think the text is incorrect, just awkward. Perhaps commas would >> > help? >> > >> > In these three subsection titles, >> > >> > 3.2.1 Change Optimization One >> > >> > 3.2.2 Change Optimization Two >> > >> > 3.2.3 Settling Detection Optimization >> > >> > I found the title for 3.2.3 helpful, but not 3.2.1 or 3.2.2. Is it >> > possible to come up with more descriptive titles? >> >> That's a reasonable point. Maybe >> >> 3.2.1 Optimization for Change to Lower Priority >> >> 3.2.2 Optimization for Change to Priority Only >> >> >> > I found >> > >> > For robustness, a TRILL switch sends a number of copies of a Port- >> > Shutdown messages configurable from one to three, which defaults to >> > two copies, at a configurable interval, which defaults to 20 >> > milliseconds (see Section 6.6). >> > >> > difficult to parse. Perhaps >> > >> > For robustness, a TRILL switch sends a configurable number of copies >> > of Port-Shutdown messages separated by a configurable interval. The >> > default >> > number of copies is two, although this can be configured as one copy >> > or as three copies, and the default interval is 20 milliseconds >> > (see Section 6.6). >> > >> > ? >> >> Sure, that seems like an improvement. Might also be good to say "time >> interval" instead of just "interval". >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com > > From nobody Wed Jan 18 06:29:43 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 533051293F5; Wed, 18 Jan 2017 06:29:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148474978229.2020.18417985258475140839.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 06:29:42 -0800 Archived-At: Cc: dromasca@gmail.com, trill-chairs@ietf.org, shares@ndzh.com, draft-ietf-trill-rfc6439bis@ietf.org, trill@ietf.org Subject: [trill] Benoit Claise's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:29:42 -0000 Benoit Claise has entered the following ballot position for draft-ietf-trill-rfc6439bis-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to see a resolution to Dan Romascanu's OPS DIR concern. https://datatracker.ietf.org/doc/review-ietf-trill-rfc6439bis-04-opsdir-telechat-romascanu-2017-01-12/ Note that the discussion is under way with Donald Eastlake From nobody Wed Jan 18 07:58:58 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA09129409; Wed, 18 Jan 2017 07:58:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148475513653.2001.17665625207200773811.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 07:58:56 -0800 Archived-At: Cc: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, shares@ndzh.com, trill@ietf.org Subject: [trill] Alissa Cooper's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 15:58:56 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-trill-directory-assist-mechanisms-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since this document implies the creation of centralized databases of addressing information, I think it would help to call out in Section 6 the need to secure the directory contents themselves, not just against abuses of the push or pull services but in general against unauthorized access. Also, I recall in prior evaluations of TRILL documents some discussion about how TRILL deals with ephemeral MAC addresses and my recollection is that they are likely prohibited by policy on TRILL networks. But if there is some interaction between ephemeral MAC addresses and the services described in this document that would be good for implementors to be aware of, those are probably worth mentioning. From nobody Wed Jan 18 10:41:32 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4ED5129401; Wed, 18 Jan 2017 10:41:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148476488466.1938.12713482038067828903.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 10:41:24 -0800 Archived-At: Cc: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, shares@ndzh.com, trill@ietf.org Subject: [trill] Alvaro Retana's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:41:31 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-trill-directory-assist-mechanisms-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to see some more information related to the overall operation of the network, including guidance on how/when to use different mechanisms and their location. Specifically, I think this document should include more information in these cases: [1] Server Learning and Advertisement of information in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. I don't think it is explicit in the document, but I'm assuming that the Servers (for both Push and Pull) learn using the mechanisms in Section 4.8.1. (Learning End-Station Addresses) of RFC6325. One of those mechanisms is to use ESADI...Section 2.5 (Additional Push Details) says: TRILL switches, whether or not they are a Push Directory server, MAY continue to advertise any locally learned MAC attachment information in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. However, if a Data Label is being served by complete Push Directory servers, advertising such locally learned MAC attachment generally SHOULD NOT be done as it would not add anything and would just waste bandwidth and ESADI link state space. An exception might be when a TRILL switch learns local MAC connectivity and that information appears to be missing from the directory mapping. It seems to me that a switch advertising information in ESADI using the Reachable MAC Addresses TLV is independent of whether Push or Pull is being used on the network (or for a specific Data Label), so I think my questions/comments below apply to both. I understand why using the information in the Reachable MAC Addresses TLV may be redundant, but as the text points out, there are cases where it may be a good thing. I would like to see guidelines or suggestions on the use of "traditional" ESADI learning (RFC7357) in Section 4. (Directory Use Strategies and Push-Pull Hybrids). This section already talks about what a TRILL switch may do if it doesn't have complete information, but it doesn't talk about what a Directory Server could do. Related to the above, if ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165] does't really add anything to the Push Directory service, then it seems to me that they would be equivalent (the outcome is the same) -- when should one be used over the other? Are there cases where the centralized service may not scale and is better to adopt a distributed strategy? It seems to me than the options in Section 4. (Directory Use Strategies and Push-Pull Hybrids) may not be just between Pull and Push... [2] Location and Priority of Push Directory Servers Section 2.2 (Push Directory Servers) talks about PushDirPriority, but there are no guidelines as to how it should be set by an operator. I suspect that a higher priority may want to be assigned to Directory Servers with a higher density of connected high-use stations...or maybe not, which is why I would like you to provide some guidance. [3] Location and Number of Requests for Pull Directory Servers Section 3.(Pull Model Directory Assistance Mechanisms) reads: If multiple data reachable TRILL switches indicate in the link state database that they are Pull Directory Servers for a particular Data Label, pull requests can be sent to any one or more of them but it is RECOMMENDED that pull requests be preferentially sent to the server or servers that are lowest cost from the requesting TRILL switch. Are there guidelines related to the location (and number) of these servers? When would a switch not send a request to the server(s) with the lowest cost? IOW, why "RECOMMENDED" and not "MUST"? How many servers should the request be sent to? For the Push case, a default of 2 copies is specified -- should 2 requests be enough? Are there cases where more are needed? From nobody Wed Jan 18 11:02:34 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA421294C6; Wed, 18 Jan 2017 11:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVOlq0OjZ0le; Wed, 18 Jan 2017 11:02:28 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 AD66F120725; Wed, 18 Jan 2017 11:02:28 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id j18so19575788ioe.2; Wed, 18 Jan 2017 11:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B5bGZgYANwLHkdGoDzwmpn9KnrfugB0zTBMubfO6yb8=; b=UPpgkvcaogdRD2viuY2v/7dwx1T24WI8G6VBYnPKmmEho5hhjLSqtwL6475yD70dDs JM8lpI7++gEsgqaM1TWJg2L2+/Yfuh+I8a0Iq3Zl+8Y/jBx/v7ueIfjGNt2mINERvxdz o43iVmWgBhSDJ5wFXOzTrBcreSfzZ34efjqkRtvm0Onb9HDm1JkjQ+S3qtNfQmAsm1SO xWEya+xFh/vRnDxswB2T4DPq/9cYWwTLDNVS0ugqjYl/kg42gLNnyksPG6MpYSLfCaNW PJYfEjkC7riACq+O963wcYYjfR1z/fhGLPw9fFqPlEJnc9mbJTM+oVzNlCGsdc9tfQ1D UfIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B5bGZgYANwLHkdGoDzwmpn9KnrfugB0zTBMubfO6yb8=; b=drDyrVXD5nb2Au2BW05GvnXcVZTs4tfJAzAmo2o7KI9wsrHszhDzPuMEKCNsvuFnDO c6eTpgccaiObz14Jn9SRcda7xaUqrqT8ccK42CKxwdPkqSxZ3SWz3nmDkAnpG1f16fSh FImBZWKlkfTJEWEv0Z23WBxioGpwLgQki0b8iJLCI7UjH716Lj7dU4iapogIV8h/Noq7 m6F86b4uKJIW3V3i40lMAD+i8i2LRvLx/tCyeSAj4Edh0CkJheXkchWwanF8JTEmzolD mJcBGn8oXjsOye80AUHjwx5whQkYK1jNz3DUd+PpWnTGUR66tnllZdkZjp7qVUCwfsb6 F+Bw== X-Gm-Message-State: AIkVDXKz7q6qiEiC6QiBJ5qAguzt5apvpfr4tZWbYNcrcK42UOXDKka1aBoBjiaWife4krbnGSUji2ziZZ3+jA== X-Received: by 10.107.141.80 with SMTP id p77mr5126428iod.97.1484766147934; Wed, 18 Jan 2017 11:02:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Wed, 18 Jan 2017 11:02:12 -0800 (PST) In-Reply-To: <148475513653.2001.17665625207200773811.idtracker@ietfa.amsl.com> References: <148475513653.2001.17665625207200773811.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 18 Jan 2017 14:02:12 -0500 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Alissa Cooper's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:02:30 -0000 Hi Alissa, On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper wrote: > > Alissa Cooper has entered the following ballot position for > draft-ietf-trill-directory-assist-mechanisms-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since this document implies the creation of centralized databases of > addressing information, I think it would help to call out in Section 6 Yes, although such centralized databases are quite common currently in terms of data center management and orchestration system databases. > the need to secure the directory contents themselves, not just against > abuses of the push or pull services but in general against unauthorized > access. OK. I'm not sure the need to secure directories resident on TRILL switches is that much different from the need to secure the routing function and routing data of TRILL switches. But the draft also supports Pull Directories hosted on end stations and I think something should be said about end station security in connection with the end station hosting a directory. > Also, I recall in prior evaluations of TRILL documents some discussion > about how TRILL deals with ephemeral MAC addresses and my recollection is > that they are likely prohibited by policy on TRILL networks. But if there The payload of a TRILL Data packet looks like an Ethernet frame. TRILL delivers it to end station(s) based on the destination MAC address and, by default, learns about MAC reachability by observing the source MAC address. So, while I would not say ephemeral or frequently changing MAC addresses are prohibited by "policy", they would reduce the efficiency of a TRILL campus by frequently obsoleting learned MAC reachability information. > is some interaction between ephemeral MAC addresses and the services > described in this document that would be good for implementors to be > aware of, those are probably worth mentioning. Directories need not be complete. If, for example, there were servers with fixed MACs and clients with mostly ephemeral MACs, I think it would still be reasonable to have the reachability (edge attachment point) information for the fixed MACs in a directory. Something about this could be added to the draft. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed Jan 18 11:14:08 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF6B1279EB; Wed, 18 Jan 2017 11:14:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 11:14:03 -0800 Archived-At: Cc: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, shares@ndzh.com, trill@ietf.org Subject: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:14:04 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-trill-directory-assist-mechanisms-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In Section 3.1 there is a Version field. What are the condition(s) for bumping this version number? What backward compatibility guaranties are expected (if any)? How would version negotiation be done? From nobody Wed Jan 18 11:16:25 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1D12945C; Wed, 18 Jan 2017 11:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycc_ibWqbA8F; Wed, 18 Jan 2017 11:16:20 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 58D191279EB; Wed, 18 Jan 2017 11:16:20 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id c7so124718363itd.1; Wed, 18 Jan 2017 11:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7F6UFBY2lqv8I49Jwz+o8emsVm65DF6R1nUxrhtDszU=; b=kRG64qbNIBfKPzRGpoviLibStUQ3tNFVXTScmtzm6MItyvm7uG96yyc/65FqqJs42K B3rc4sCJuQz7x+RdtfWwGpVUKcQxNxOuXXRToFricGZIwOZpRgTflnZ9u3s/Y10OaSIx kT1PamAJD2aG7kLHbqLVtSUyyg7C9E/1bNp8SP/c5AD9pkCrTmmjaEjy94kmrTdVnyJa d2sQMqB1PtLHV4mZO2KPJN1+lR3psFdU9OQwGSbfLpv5C3iThwwT+YcxN4aEpViERMEP 7YOWBmSWL+lRVNH5xB9SmvQIQPXagyrVmiz2mU+2qa0NTUruM5eb+RsTVjzG7RGyqifH rzIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7F6UFBY2lqv8I49Jwz+o8emsVm65DF6R1nUxrhtDszU=; b=QNnOK7+7ve267AHyYJZSAVEYFy5wVtrGGS4+CXaJe6oaLFc9Z5s8wKCEt7J95DiuUW HKmOo0/yrEqMo16zm0aL63k7r5v6V56brDE8Hzf3Gg/WLvQVrkbVFIXMS2LV7fU3Cnu2 T5aarNtQ0jix9jvkEq6iGwa73YhUifdOH9YazvqEAdw0XYQqemnZEoP7shcfLp1Lgy4z rGNMtcxSlhtiikzsOcTH+H+PyZ9gU1Q2HZzk9Gr86WrylKeBNsyxnq+HO70rh7RIQyiR kwz+Y8N2ZYpUkO7qhAM3/yNCVafzBH+hZCP6XQltNe3a8cloX/5+ZRYTQ+nOcIy9L0DH 5voQ== X-Gm-Message-State: AIkVDXKTLW4lupwXer0saSRnC+lP032qun4kwIOvS4IC2UEoGBmZg8B3zPFT/j3nE1hgwr6F4YNqx2z9n7D9yQ== X-Received: by 10.36.107.194 with SMTP id v185mr25837798itc.59.1484766979489; Wed, 18 Jan 2017 11:16:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Wed, 18 Jan 2017 11:16:03 -0800 (PST) In-Reply-To: References: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 18 Jan 2017 14:16:03 -0500 Message-ID: To: Dan Romascanu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ops-dir@ietf.org" , draft-ietf-trill-rfc6439bis.all@ietf.org, IETF Discussion , "trill@ietf.org" Subject: Re: [trill] Review of draft-ietf-trill-rfc6439bis-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:16:22 -0000 Hi Dan, On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu wrote: > Hi Donald, > > Thank you for your answer and explanations. They make sense to me, but I > still beleive that the document may benefit if some edits are being done to > clarify what may be the obvious for the people who know all details and > history, but not for the other users of the document in the future - > implementers and operators. Sure, I agree that it would benefit for the addition of some text here and there./ > Specifically: > >> I am not aware of any case where this draft replaces a TLV in the > sense of requiring use of a new TLV. It does provide some new TLVs > and procedures that are believed to be superior to or useful additions > to previous ones. But I am not aware of any case where it "obsoletes" > previous provisions in the sense of prohibiting their use. > > The header of the document includes Obsoletes 6439. If part of the content > of 6439 remains valid this needs to be clarified, If some superior TLVs and > procedures are introduced there is a need to explain what will happen with > the previous ones. Should they be implemented? deployed? activated? OK. Stating that essentially all of RFC 6439 is incorporated and outlining what parts of the new draft are optional improvements over which part of RFC 6439, etc. would probably be a good addition. >> I don't know that much is really required to be said about > "transition" when you specify an optional optimization. Since it is > optional, by implication the implementer is free to use it or not and > things will work either way. This could be stated explicitly in those > cases. > > If I understand what you say, the new features are optional (although the > status of the document is Proposed Standard), they can or cannot be > implemented (one, the other, both?) and the network will still work. Yes, I > suggest to explicitly state this). OK. >> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) > SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs > 6850 and 7784. However, there are also YANG modules underway in > draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and > draft-ietf-trill-yang-pm. > >> It does not seem best for this rfc6439bis draft to change the > implementation requirement level for SNMP or NETCONF for TRILL. If that > were to be done, it seems like something more appropriate for the base > TRILL YANG draft (draft-ietf-trill-yang-*) to do. > > If I was an implementer of TRILL, or an operator considering to deploy > TRILL, I would have a hard time trying to understand what to implement and > what to deploy as management interfaces. Maybe this is not the place but I > believe that there need to be some documentation on this respect. OK. I think it would be reasonable to say something about the current implementation requirement level of SNMPv3 and to say that YANG modules are under development, so implementers will know more about what is going on. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thanks and Regards, > Dan > > > On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake wrote: >> >> Hi Dan, >> >> Thanks for your review. As per my further response below, while the >> draft could perhaps use some clarifying additions related to >> operations, I do not believe it is as bad as you say. >> >> On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu >> wrote: >> > >> > Reviewer: Dan Romascanu >> > Review result: Has Issues >> > >> > I have reviewed this document as part of the Operational >> > directorate's ongoing effort to review all IETF documents being >> > processed by the IESG. These comments were written with the intent >> > of improving the operational aspects of the IETF drafts. Comments >> > that are not addressed in last call may be included in AD reviews >> > during the IESG review. Document editors and WG chairs should treat >> > these comments just like any other last call comments. >> > >> > This document clarifies and updates the TRILL Appointed >> > Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and >> > obsoletes RFC 6439. >> > >> > It's a complex document which requires extra reading to understand >> > the context and the interraction with other RFCs. I believe that >> > from an OPS-DIR perspective there are issues that need to be >> > discussed before the document can be approved. >> > >> > The main issues with the document in its current form are: >> > >> > 1. The document makes consistent changes in the way TRILL >> > operates. It replaces TLVs and procedures, define new ones, >> > obsoletes previous mechanisms that define VLAN mapping, and >> >> I am not aware of any case where this draft replaces a TLV in the >> sense of requiring use of a new TLV. It does provide some new TLVs >> and procedures that are believed to be superior to or useful additions >> to previous ones. But I am not aware of any case where it "obsoletes" >> previous provisions in the sense of prohibiting their use. >> >> > incorporates updated material from other RFCs. There is however no >> > indication in the text about the transition between existing >> > deployed versions of TRILL based on RFC 6439 and related protocols >> > with the current updated mechanisms. Are these backward compatible? >> >> I don't know that much is really required to be said about >> "transition" when you specify an optional optimization. Since it is >> optional, by implication the implementer is free to use it or not and >> things will work either way. This could be stated explicitly in those >> cases. >> >> Much of the material in this draft comes from RFC 6439 or the parts of >> RFC 7177 that updated RFC 6439. Most of the new material is optional >> improved behaviors. >> >> The only mandatory new behavior is the mandatory support of the link >> local E-L1CS flooding scope [RFC7357] specified in Section 8. There is >> material in this draft covering backwards compatibility for this new >> mandatory behavior. Section 8 already explains how to determine >> whether or not all TRILL switches on a link support E-L1CS flooding >> scope. The only use of E-L1CS flooding scope in this draft is as part >> of a mechanism for the DRB (Designated RBridge (TRILL switch)) to >> advertise Forwarder Appointments and, as stated in Section 2.1 (see >> paragraph at the bottom of page 8 in draft -04), if any RBridge on the >> link does not support E-L1CS, then the DRB MUST fall back to >> advertising those appointments in Hellos. Section 8, which mandates >> support of E-L1CS, also requires that any use of E-L1CS specified in >> the future must provide for backward compatibility. >> >> > Do they need a simultaneous upgrade of the whole network? >> >> No. >> >> > 2. The document lacks a section or even minimal text concerning >> > operational and manageability considerations. There are several >> >> Such a section can be added but there is not much to say. For example, >> as explained below, there is very little specified in this document to >> configure. >> >> > mentions in the text concerning network managers or operator >> > actions, but there is no indication or reference to what management >> > protocols and data models are to be used for configuration, >> >> RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges) >> SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs >> 6850 and 7784. However, there are also YANG modules underway in >> draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and >> draft-ietf-trill-yang-pm. >> >> It does not seem best for this rfc6439bis draft to change the >> implementation requirement level for SNMP or NETCONF for TRILL. If that >> were to be done, it seems like something more appropriate for the base >> TRILL YANG draft (draft-ietf-trill-yang-*) to do. >> >> > retrieval of operational status information, or alerts. I believe >> > that these need to be added explicitly or by reference. >> >> Reviewing the significant protocol additions in this draft at a high >> level: >> >> - There is significant material about the various ways the Designated >> RBridge on a link can announce who it is selecting as the Appointed >> Forwarder on the link for various VLANs. The election of the >> Designated RBridge depends on a configurable priority but that >> election is unchanged from RFC 7177 and in fact is identical to the >> election of the designated router on any IS-IS link. The decision on >> which RBridges to appointer as forwarder for which VLAN is out of >> scope. I don't see that there is anything to configure here, other >> than RBridge priority to be DRB, which is already specified in other >> RFCs. >> >> - There are some optional optimizations to the inhibition mechanism. >> The inhibition mechanism is necessary for loop safety but any >> RBridge can use or not use any of these optimizations, as they >> choose, and things will work fine. >> >> - Port Shutdown message: There are two new configuration parameters >> here, namely how many copies of the Port Shutdown message to send >> and at what interval. These are listed, along with units and default >> value in Section 6.6. >> >> - FGL-VLAN mapping consistency check: As specified in RFC 7172, in a >> TRILL campus supporting Fine Grained Labels (FGL), the VLAN of a >> native frame can be mapped to an FGL on ingress and an FGL is mapped >> to a VLAN on egress. This draft makes no changes to that mechanism. >> It merely provides that an RBridge performing such mapping can >> optionally advertise the mapping it is performing at a port to other >> RBridges with ports on the same link which can then check it for >> consistency with any mapping they are performing. It is recommended >> that the network operator be alerted to such inconsistency and there >> is a configurable parameter for how long the inconsistency needs to >> exist before such alert. Is it your position that some specific >> protocol mechanism must be specified by which the network operator >> is alerted? >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com > > From nobody Wed Jan 18 12:32:21 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8E1129583; Wed, 18 Jan 2017 12:32:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 12:32:16 -0800 Archived-At: Cc: trill-chairs@ietf.org, shares@ndzh.com, draft-ietf-trill-rfc6439bis@ietf.org, trill@ietf.org Subject: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 20:32:16 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-trill-rfc6439bis-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.4 (Overload and Appointed Forwarders) talks about potential Appointed Forwarders which are overloaded. In IS-IS, a node with the overload bit set "shall not" (ISO 10589) be considered for transit. However, the use of "SHOULD NOT appoint an RBridge in overload" and "SHOULD re-assign VLANs from the overloaded RBridge" leaves a potential hole in the proper forwarding of TRILL data packers. Why aren't MUST NOT/MUST used? Is there something in the specific use of IS-IS by TRILL that I am missing? I think this should be an easy DISCUSS to clear; either point to the piece I'm missing, or don't use an overloaded node. From nobody Wed Jan 18 20:44:11 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003601288B8; Wed, 18 Jan 2017 20:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO5QxEZW8mru; Wed, 18 Jan 2017 20:44:07 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 77B8B127058; Wed, 18 Jan 2017 20:44:07 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id j18so29282742ioe.2; Wed, 18 Jan 2017 20:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=so6rTVCtXEhI6ABM4BEk+w10qfjgOnYvj6SqK6fr7/o=; b=HAcvbOmIDLonw7ZHIQBvhsTLe4DYisHf2UY+kMBuDUkAZbbbJzv62xjY2MKv8y48Yi UJDM5fH7zDtzkEXCR4+N2f+gtJkGIZsyn1eRAiKXcUtSHbzJY1onK4xADD0hUrbzG99i LGfct28E70KX6dGOrIOy1eUhORJT7MFdf/tZLn9RI2V6cVrkW3nJSIoKyVDbG0qk9GDw ZQP4aqc6o9kpJ7HDkKNRzw6fcbUzPdKTcEM7zXeHdQXiiyPqbzaN85YWSTFDNuv/FETt ikURGoYW13IAMI13eBvUg1lc8Z2slyL9JuLuf8Uu/KSLV0t4pDD5iDWTzzTerGquLCAb R5HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=so6rTVCtXEhI6ABM4BEk+w10qfjgOnYvj6SqK6fr7/o=; b=iPYqXyD28AookNrpIN5loGbWfsFmEPJV/cnIuBe5/F4EMuspZf9bHOopTe5Qp7QAPo 66qGNcTlvKnSDl1gICzKy6G6mc6Vwfg2Fxyx8MZon7mFZ8vGz2FN0SIhFw+7iQp1ry+X D3iBiI+Sc5LrPJOk5il9tT+Hahi3VPexgptfzxNTLc3RdZkbEAbpb8i+8j/7T4FyewVf PJWwNYiHoT9n07Hq0+UX78zKpvjmKgKYTCdHeCDMq2U0itgJbW6lv71SfFVwPmZvRmCh LUkirA664gQBGD6IY5qRBARlCz1we7L9nk0SE2HolQapW7ULiX/am8/5V3MY7Otv0S4L +cHQ== X-Gm-Message-State: AIkVDXLE3PlZDcoPcj2Yl2oebR+AnFzXJohkrsXvVdPNph8SFybuQSUpboSUBFUgz3f8QGdYQHN+0JNFBQYrpw== X-Received: by 10.107.175.93 with SMTP id y90mr6450353ioe.12.1484801046758; Wed, 18 Jan 2017 20:44:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Wed, 18 Jan 2017 20:43:51 -0800 (PST) In-Reply-To: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com> References: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 18 Jan 2017 23:43:51 -0500 Message-ID: To: Alvaro Retana Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , "trill@ietf.org" , The IESG , draft-ietf-trill-rfc6439bis@ietf.org, Susan Hares Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 04:44:09 -0000 Hi Alvaro, On Wed, Jan 18, 2017 at 3:32 PM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-trill-rfc6439bis-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.4 (Overload and Appointed Forwarders) talks about potential > Appointed Forwarders which are overloaded. In IS-IS, a node with the > overload bit set "shall not" (ISO 10589) be considered for transit. > However, the use of "SHOULD NOT appoint an RBridge in overload" and > "SHOULD re-assign VLANs from the overloaded RBridge" leaves a potential > hole in the proper forwarding of TRILL data packers. Why aren't MUST > NOT/MUST used? Is there something in the specific use of IS-IS by TRILL > that I am missing? The Appointed Forwarder function has to do with accepting frames from end stations for ingress and egressing frames to end stations. It does not have anything to do with TRILL Data packet transit routing. Consider the following case: two TRILL switches (RBridges) RB1 and RB2 are connected by a link L1 that also has end stations on it. The end stations are all in VLAN X. There are other end stations in VLAN X in the TRILL campus not on L1 but all of these other end stations are directly connected to RB2. RB2 is in overload. Under these circumstances, RB2 should be the Appointed Forwarder for VLAN X as that way traffic between all of the VLAN X end stations can be forwarded by RB2 without any IS-IS routing at all. RB2 will just be, in effect, forwarding native frames between RB2 ports (although, for consistency, the TRILL specifications say that RB2 ingresses this VLAN X traffic by encapsulating it into a TRILL Data frame, and then notices it is destined for an end station on a local port, immediately decapsulates it, and sends it out that port). > I think this should be an easy DISCUSS to clear; either point to the > piece I'm missing, or don't use an overloaded node. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed Jan 18 21:17:20 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58ACE12940E; Wed, 18 Jan 2017 21:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-B_1R0nFc1U; Wed, 18 Jan 2017 21:17:14 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 28965127071; Wed, 18 Jan 2017 21:17:14 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id j13so29652938iod.3; Wed, 18 Jan 2017 21:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YP/aUNKchysR8zZwC8wKd/Gh1OlmjOBYNjULPwBAoNM=; b=Nfy1ejUBeh199xpaeLaGwNCFhWxzAeb83M1N0NyrJnbBaWhPiNFcRkRTVjhLhzkh2w JFxO9wxIAg166FR6zAlmNVA1yqUcPKLvr+gJNglIU/UYBbdL9AEunYNZaS27XzzvAc3v 1T+WAPvN9P8Mdp96kilkjO4HtaqgYfSmTg0uIrVAzabz5aVduWyB5bMpZlfEBtxtzifn oDYGIqkjB70U3gln3kHLG1qYAJCQUoWToM//pxpSzGzdKa1f0EV3d4PWEcNZiRgs+LO2 WeTB8O0+fw+1izDPr34wiyutZA8Dwbt0fv2FB+0wn8Q5PqPaBCVCAOeSZ1yavTob0XJk Pebw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YP/aUNKchysR8zZwC8wKd/Gh1OlmjOBYNjULPwBAoNM=; b=FP5rU9M1Z348l9MFJO2/q+B/Bv76OQkpIrI8Y3WB2bKz9S8TgP0MenDqdutam7TDOh ipvG4mV9XdRyw9T4xulefKjWzfKvwfJvbJuLhxtUUUe9W4+3TQQG/HudCcbJDJ6Aw3ez QNBIOxDcZ8xCJ3JLiFz45A/s5qneGk5OiuIRl6x+EbMt+yCbSmEGAprYK3h2y3bHj23E DN0uTHGp1uyqIp2e0TLmiI5mYJHsDzvmmZwmguptckaQmNVlStUUgn24nN4UpqBFFb4F rRTKhvurXo1xlCMYWhCLkujJ7PTgwOaHlXevJYgA1tgXPXcCBwR24R1okGwIzM0EqLNf yWMw== X-Gm-Message-State: AIkVDXIp86A5S+85U9qgsQD09PNa9sQjqtbbLZD5H3ZV2jQ23X5fms6sQTwNkSXK7cOhsAuvvhec7ZoQaTwncA== X-Received: by 10.107.175.93 with SMTP id y90mr6521876ioe.12.1484803033499; Wed, 18 Jan 2017 21:17:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Wed, 18 Jan 2017 21:16:58 -0800 (PST) In-Reply-To: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> References: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 19 Jan 2017 00:16:58 -0500 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 05:17:15 -0000 Hi Alexey, On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-trill-directory-assist-mechanisms-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > In Section 3.1 there is a Version field. What are the condition(s) for > bumping this version number? What backward compatibility guaranties are > expected (if any)? How would version negotiation be done? Well, I could say that the answers to all of your questions are about the same for this Version field as they are for the RBridge Channel Header version field [RFC7178], the TRILL Header version field [RFC6325], and many other version fields in IETF protocols but you probably wouldn't consider that a very good answer. I suppose if text was being added along this lines, it should say that the version number must be incremented for a specification that does not just specify new field values where that is allowed in version zero but cannot be correctly parsed beyond the version nibble. Since the protocol is a request/response protocol, the responder should indicate the highest version number they understand but the response must be valid in the version number specified in the request including the possibility of indicating a valid error saying that the version is not implemented. Thus all implementations of version X would need to be able to at least send such an error for all versions from 0 through X-1. Then you would add an explicit suberror code in Section 3.6.3 for unimplemented version. For a version zero implementation, that would be returned for any higher version. However, I don't expect an incremented version number to be needed anytime soon. Was it your intent with this DISCUSS to get something like the above added to the draft? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Jan 19 01:39:09 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F218127ABE; Thu, 19 Jan 2017 01:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=i1rWVLI/; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=cb70xgFN 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 8tu6X1n8F2Nc; Thu, 19 Jan 2017 01:39:02 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485E4128B38; Thu, 19 Jan 2017 01:39:02 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AA61420875; Thu, 19 Jan 2017 04:39:01 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 19 Jan 2017 04:39:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=9v1olWQcsxK4YWs JdgcLZk7uoGE=; b=i1rWVLI/WShxbTe485hym6J5gjEBsD+yIwAfMOBNiF2HIv+ bWwqqE65zpNpHzEgxVu9BMck+O4Ih4vRhg6FEYfZj1iApU4m093K/R2wCjHbweBN yfm6csbqGsgALFlhgVhvM7jp/uWaPq/axZVEJIAFvTTzoaPHk2NFfXmT0070= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=9v1olWQcsxK4YWsJdgcLZk7uoGE=; b=cb70xgFNyMg8/QER1qOk Je/mn3pCu03Vt/AwH+c5UqtPVzFAAbgUWB90mwJI7bUiA5ghjalKW7fyvunPXaZI jDnGwudJH/BRVSPhbjshOhmjI4Fn9Hn35ToA8sjQcEN5x5Y8z4neMBJTdsNqu7rO 0kMDrMwcaAgmDmm+n2Ru3WI= X-ME-Sender: X-Sasl-enc: sIkLpf4/XXJfgeo0K0KwJbmXhmRdFJ207ilmuBvGc7pj 1484818741 Received: from [10.232.42.151] (unknown [185.69.144.232]) by mail.messagingengine.com (Postfix) with ESMTPA id 4CD5E2475F; Thu, 19 Jan 2017 04:39:01 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Thu, 19 Jan 2017 09:48:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <09692183-AC90-4862-8EA9-86A176C69EF8@fastmail.fm> References: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> To: Donald Eastlake Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 09:39:04 -0000 Hi Donald, > On 19 Jan 2017, at 05:16, Donald Eastlake wrote: >=20 > Hi Alexey, >=20 >> On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov = wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-trill-directory-assist-mechanisms-11: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> In Section 3.1 there is a Version field. What are the condition(s) for >> bumping this version number? What backward compatibility guaranties are >> expected (if any)? How would version negotiation be done? >=20 > Well, I could say that the answers to all of your questions are about > the same for this Version field as they are for the RBridge Channel > Header version field [RFC7178], the TRILL Header version field > [RFC6325], and many other version fields in IETF protocols but you > probably wouldn't consider that a very good answer. >=20 > I suppose if text was being added along this lines, it should say that > the version number must be incremented for a specification that does > not just specify new field values where that is allowed in version > zero but cannot be correctly parsed beyond the version nibble. Since > the protocol is a request/response protocol, the responder should > indicate the highest version number they understand but the response > must be valid in the version number specified in the request including > the possibility of indicating a valid error saying that the version is > not implemented. Thus all implementations of version X would need to > be able to at least send such an error for all versions from 0 through > X-1. Then you would add an explicit suberror code in Section 3.6.3 for > unimplemented version. For a version zero implementation, that would > be returned for any higher version. >=20 > However, I don't expect an incremented version number to be needed > anytime soon. Was it your intent with this DISCUSS to get something > like the above added to the draft? Yes, exactly along the lines of your text above. From nobody Thu Jan 19 03:02:35 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2CA126BF7; Thu, 19 Jan 2017 03:02:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148482375422.10442.8090725437940894464.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 03:02:34 -0800 Archived-At: Cc: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, shares@ndzh.com, trill@ietf.org Subject: [trill] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-ietf-?= =?utf-8?q?trill-directory-assist-mechanisms-11=3A_=28with_COMMENT=29?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 11:02:34 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-trill-directory-assist-mechanisms-11: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's not clear to me why a new protocol for the pull case is needed (instead of using an existing one). However, I also don't have enough background knowledge on trill to make a judgement here. From nobody Thu Jan 19 04:19:29 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB7C129499; Thu, 19 Jan 2017 04:19:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148482836602.10328.15276840045846655138.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 04:19:26 -0800 Archived-At: Cc: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, shares@ndzh.com, trill@ietf.org Subject: [trill] Stephen Farrell's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 12:19:26 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-trill-directory-assist-mechanisms-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 2.6: I wondered why this was useful. Is it for cases where the secondary push service is differently connected or is it in case the primary goes down? Might be good to say. - section 6: what security mechanism differences are there between the push and pull cases? Why aren't those called out here? Forcing the reader to delve into the various other security mechanism RFCs and figure this out themselves seems less good. - section 6: apologies if I asked this before (in which case I forget the answer;-) but how fictional/real is the crypto stuff with TRILL in terms of the likelihood of it being actually used? I ask again, as if the crypto stuff is mostly fictional, then I think you ought note that here, given the attack surface that the directory function creates. From nobody Thu Jan 19 04:43:42 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BB412007C; Thu, 19 Jan 2017 04:43:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148482982098.10352.9816816043381207445.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 04:43:40 -0800 Archived-At: Cc: trill-chairs@ietf.org, shares@ndzh.com, draft-ietf-trill-rfc6439bis@ietf.org, trill@ietf.org Subject: [trill] Stephen Farrell's No Objection on draft-ietf-trill-rfc6439bis-04: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 12:43:41 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-trill-rfc6439bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 6: is port-shutdown a new potential DoS vector? Shouldn't that be noted here and/or in section 9? From nobody Thu Jan 19 06:19:08 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB442129415; Thu, 19 Jan 2017 06:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IilAO3jPbEZe; Thu, 19 Jan 2017 06:18:42 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77F51295F6; Thu, 19 Jan 2017 06:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17922; q=dns/txt; s=iport; t=1484835521; x=1486045121; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PY6LC+krHb6fmK+YSK9H8LXUAEcXx4LQvAoK+qEPnQI=; b=E0XK5LJomgrbKRVvS9rlt3wciAznKLA6u+Kxq9uyk8GfcwN1JOel0R3p /kTW9X3Qw2+MH3l4rbmVLHnOU6hZavUHMNW9q14UjdHOu3qJgNgHXmTHY l8O4eQ60Tlrfi8lW1zcTeQs7sbcB3haoYNobCXZEg4ffcixMowL0Ee6CM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAQD5yYBY/51dJa1bAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJvQQ8BAQEBAR9ggQkHg0qKCJoHh32DHIIPggyGIgIagWQ/GAECAQE?= =?us-ascii?q?BAQEBAWMohGoGI1YQAgEIDjEDAgICHxEUEQIEDgWIaAMYr2yCJSuHCw2CfAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2GS4IFgmmCUYFKEQEzCgsbgj8tgjEFiH6MN4V?= =?us-ascii?q?XOAGNX4QFgXeFD4loihuIVAEfOHJUFUoBhiZzhzaBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,254,1477958400"; d="scan'208,217";a="195242306" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2017 14:18:40 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0JEIe3q027483 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 14:18:40 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 19 Jan 2017 08:18:40 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 19 Jan 2017 08:18:40 -0600 From: "Alvaro Retana (aretana)" To: Donald Eastlake Thread-Topic: Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) Thread-Index: AQHSccn8d2iuKLA/v0GoMHUkJqLJpaE/nkSAgABMx4A= Date: Thu, 19 Jan 2017 14:18:40 +0000 Message-ID: References: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_FDF0EF47D4FE4A6296B3FB3559287AC4ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "trill-chairs@ietf.org" , "trill@ietf.org" , The IESG , "draft-ietf-trill-rfc6439bis@ietf.org" , Susan Hares Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:18:54 -0000 --_000_FDF0EF47D4FE4A6296B3FB3559287AC4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uYWxkOg0KDQpIaSENCg0KSSBhbSBub3QgY29uY2VybmVkIGFib3V0IHRoZSBjYXNlIHlvdSBk ZXNjcmliZWQgYmVsb3c6IHdoZXJlIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFyZSBhdHRh Y2hlZCB0byB0aGUgc2FtZSBzd2l0Y2guICBOb3IgYW0gSSBjb25jZXJuZWQgYWJvdXQgdHJhbnNp dCBUUklMTCBkYXRhIHBhY2tldHMuDQoNCkkgYW0gY29uY2VybmVkIGFib3V0IHRoZSBjYXNlIHdo ZXJlIHRoZSBvdGhlciBlbmQgc3RhdGlvbnMgYXJlIG5vdCBhdHRhY2hlZCB0byBhbnkgb2YgdGhl IGxvY2FsIHN3aXRjaGVzLCBidXQgYXJlIHNvbWV3aGVyZSBlbHNlIGluIHRoZSBjYW1wdXMgKG9y IHRoZSBtaXhlZCBjYXNlIHdoZXJlIHNvbWUgb2YgdGhlIG90aGVyIGVuZCBzdGF0aW9ucyBhcmUg YXR0YWNoZWQgdG8gYW4gb3ZlcmxvYWRlZCBzd2l0Y2gsIGJ1dCBvdGhlcnMgYXJlIGVsc2V3aGVy ZSkuICBJbiB0aGF0IGNhc2UsIGlmIEkgYW0gbm90IG1pc3NpbmcgYW55dGhpbmcsIHRoZSBhcHBv aW50ZWQgZm9yd2FyZGVyIGZvciB0aGUgbG9jYWwgbGluayB3aWxsIGFjY2VwdCB0aGUgbmF0aXZl IGZyYW1lIGFuZCB3aWxsIGhhdmUgdG8gc2VuZCBhIFRSSUxMIERhdGEgUGFja2V0IGFjcm9zcyB0 aGUgY2FtcHVzIOKAkyB0aGUgaW5mb3JtYXRpb24gdG8gZG8gdGhhdCBtYXkgbm90IGJlIGF2YWls YWJsZSBpZiB0aGUgc3dpdGNoIGlzIG92ZXJsb2FkZWQuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0K DQpPbiAxLzE4LzE3LCAxMTo0MyBQTSwgIkRvbmFsZCBFYXN0bGFrZSIgPGQzZTNlM0BnbWFpbC5j b208bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgQWx2YXJvLA0KDQpPbiBX ZWQsIEphbiAxOCwgMjAxNyBhdCAzOjMyIFBNLCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hQGNpc2Nv LmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+PiB3cm90ZToNCkFsdmFybyBSZXRhbmEgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLXRy aWxsLXJmYzY0MzliaXMtMDQ6IERpc2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2Vl cCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNz ZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhp cw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJ U0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClNlY3Rpb24gMi40IChPdmVybG9hZCBhbmQgQXBwb2lu dGVkIEZvcndhcmRlcnMpIHRhbGtzIGFib3V0IHBvdGVudGlhbA0KQXBwb2ludGVkIEZvcndhcmRl cnMgd2hpY2ggYXJlIG92ZXJsb2FkZWQuICBJbiBJUy1JUywgYSBub2RlIHdpdGggdGhlDQpvdmVy bG9hZCBiaXQgc2V0ICJzaGFsbCBub3QiIChJU08gMTA1ODkpIGJlIGNvbnNpZGVyZWQgZm9yIHRy YW5zaXQuDQpIb3dldmVyLCB0aGUgdXNlIG9mICJTSE9VTEQgTk9UIGFwcG9pbnQgYW4gUkJyaWRn ZSBpbiBvdmVybG9hZCIgYW5kDQoiU0hPVUxEIHJlLWFzc2lnbiBWTEFOcyBmcm9tIHRoZSBvdmVy bG9hZGVkIFJCcmlkZ2UiIGxlYXZlcyBhIHBvdGVudGlhbA0KaG9sZSBpbiB0aGUgcHJvcGVyIGZv cndhcmRpbmcgb2YgVFJJTEwgZGF0YSBwYWNrZXJzLiAgV2h5IGFyZW4ndCBNVVNUDQpOT1QvTVVT VCB1c2VkPyAgSXMgdGhlcmUgc29tZXRoaW5nIGluIHRoZSBzcGVjaWZpYyB1c2Ugb2YgSVMtSVMg YnkgVFJJTEwNCnRoYXQgSSBhbSBtaXNzaW5nPw0KDQpUaGUgQXBwb2ludGVkIEZvcndhcmRlciBm dW5jdGlvbiBoYXMgdG8gZG8gd2l0aCBhY2NlcHRpbmcgZnJhbWVzIGZyb20NCmVuZCBzdGF0aW9u cyBmb3IgaW5ncmVzcyBhbmQgZWdyZXNzaW5nIGZyYW1lcyB0byBlbmQgc3RhdGlvbnMuIEl0IGRv ZXMNCm5vdCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggVFJJTEwgRGF0YSBwYWNrZXQgdHJhbnNp dCByb3V0aW5nLg0KDQpDb25zaWRlciB0aGUgZm9sbG93aW5nIGNhc2U6IHR3byBUUklMTCBzd2l0 Y2hlcyAoUkJyaWRnZXMpIFJCMSBhbmQgUkIyDQphcmUgY29ubmVjdGVkIGJ5IGEgbGluayBMMSB0 aGF0IGFsc28gaGFzIGVuZCBzdGF0aW9ucyBvbiBpdC4gVGhlIGVuZA0Kc3RhdGlvbnMgYXJlIGFs bCBpbiBWTEFOIFguIFRoZXJlIGFyZSBvdGhlciBlbmQgc3RhdGlvbnMgaW4gVkxBTiBYIGluDQp0 aGUgVFJJTEwgY2FtcHVzIG5vdCBvbiBMMSBidXQgYWxsIG9mIHRoZXNlIG90aGVyIGVuZCBzdGF0 aW9ucyBhcmUNCmRpcmVjdGx5IGNvbm5lY3RlZCB0byBSQjIuIFJCMiBpcyBpbiBvdmVybG9hZC4N Cg0KVW5kZXIgdGhlc2UgY2lyY3Vtc3RhbmNlcywgUkIyIHNob3VsZCBiZSB0aGUgQXBwb2ludGVk IEZvcndhcmRlciBmb3INClZMQU4gWCBhcyB0aGF0IHdheSB0cmFmZmljIGJldHdlZW4gYWxsIG9m IHRoZSBWTEFOIFggZW5kIHN0YXRpb25zIGNhbg0KYmUgZm9yd2FyZGVkIGJ5IFJCMiB3aXRob3V0 IGFueSBJUy1JUyByb3V0aW5nIGF0IGFsbC4gUkIyIHdpbGwganVzdA0KYmUsIGluIGVmZmVjdCwg Zm9yd2FyZGluZyBuYXRpdmUgZnJhbWVzIGJldHdlZW4gUkIyIHBvcnRzIChhbHRob3VnaCwNCmZv ciBjb25zaXN0ZW5jeSwgdGhlIFRSSUxMIHNwZWNpZmljYXRpb25zIHNheSB0aGF0IFJCMiBpbmdy ZXNzZXMgdGhpcw0KVkxBTiBYIHRyYWZmaWMgYnkgZW5jYXBzdWxhdGluZyBpdCBpbnRvIGEgVFJJ TEwgRGF0YSBmcmFtZSwgYW5kIHRoZW4NCm5vdGljZXMgaXQgaXMgZGVzdGluZWQgZm9yIGFuIGVu ZCBzdGF0aW9uIG9uIGEgbG9jYWwgcG9ydCwgaW1tZWRpYXRlbHkNCmRlY2Fwc3VsYXRlcyBpdCwg YW5kIHNlbmRzIGl0IG91dCB0aGF0IHBvcnQpLg0KDQpJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGFu IGVhc3kgRElTQ1VTUyB0byBjbGVhcjsgZWl0aGVyIHBvaW50IHRvIHRoZQ0KcGllY2UgSSdtIG1p c3NpbmcsIG9yIGRvbid0IHVzZSBhbiBvdmVybG9hZGVkIG5vZGUuDQoNClRoYW5rcywNCkRvbmFs ZA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KRG9uYWxkIEUuIEVhc3RsYWtlIDNy ZCAgICsxLTUwOC0zMzMtMjI3MCAoY2VsbCkNCjE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBN QSAwMTc1NyBVU0ENCmQzZTNlM0BnbWFpbC5jb208bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+DQoN Cg== --_000_FDF0EF47D4FE4A6296B3FB3559287AC4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6EE10FD2E55882409DC358C344686426@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Eb25h bGQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+SSBhbSBub3QgY29uY2VybmVkIGFib3V0IHRoZSBjYXNlIHlvdSBkZXNjcmliZWQgYmVsb3c6 IHdoZXJlIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFyZSBhdHRhY2hlZCB0byB0aGUgc2Ft ZSBzd2l0Y2guJm5ic3A7IE5vciBhbSBJIGNvbmNlcm5lZCBhYm91dCB0cmFuc2l0IFRSSUxMIGRh dGEgcGFja2V0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIGFtIGNvbmNlcm5lZCBhYm91 dCB0aGUgY2FzZSB3aGVyZSB0aGUgb3RoZXIgZW5kIHN0YXRpb25zIGFyZSBub3QgYXR0YWNoZWQg dG8gYW55IG9mIHRoZSBsb2NhbCBzd2l0Y2hlcywgYnV0IGFyZSBzb21ld2hlcmUgZWxzZSBpbiB0 aGUgY2FtcHVzIChvciB0aGUgbWl4ZWQgY2FzZSB3aGVyZSBzb21lIG9mIHRoZSBvdGhlcg0KIGVu ZCBzdGF0aW9ucyBhcmUgYXR0YWNoZWQgdG8gYW4gb3ZlcmxvYWRlZCBzd2l0Y2gsIGJ1dCBvdGhl cnMgYXJlIGVsc2V3aGVyZSkuJm5ic3A7IEluIHRoYXQgY2FzZSwgaWYgSSBhbSBub3QgbWlzc2lu ZyBhbnl0aGluZywgdGhlIGFwcG9pbnRlZCBmb3J3YXJkZXIgZm9yIHRoZSBsb2NhbCBsaW5rIHdp bGwgYWNjZXB0IHRoZSBuYXRpdmUgZnJhbWUgYW5kIHdpbGwgaGF2ZSB0byBzZW5kIGEgVFJJTEwg RGF0YSBQYWNrZXQgYWNyb3NzIHRoZSBjYW1wdXMg4oCTDQogdGhlIGluZm9ybWF0aW9uIHRvIGRv IHRoYXQgbWF5IG5vdCBiZSBhdmFpbGFibGUgaWYgdGhlIHN3aXRjaCBpcyBvdmVybG9hZGVkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJn aW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDEvMTgvMTcsIDExOjQzIFBNLCAmcXVvdDtEb25hbGQgRWFzdGxha2Um cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkM2UzZTNAZ21haWwuY29tIj5kM2UzZTNAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWx2YXJvLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAxOCwgMjAxNyBhdCAz OjMyIFBNLCBBbHZhcm8gUmV0YW5hICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYUBjaXNjby5j b20iPmFyZXRhbmFAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVD NERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21h cmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRo ZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQtaWV0Zi10cmlsbC1yZmM2NDM5YmlzLTA0 OiBEaXNjdXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRh Y3QgYW5kIHJlcGx5IHRvIGFsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIu KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ESVNDVVNTOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDIuNCAoT3ZlcmxvYWQgYW5kIEFwcG9pbnRl ZCBGb3J3YXJkZXJzKSB0YWxrcyBhYm91dCBwb3RlbnRpYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFwcG9pbnRlZCBGb3J3YXJkZXJzIHdoaWNo IGFyZSBvdmVybG9hZGVkLiZuYnNwOyZuYnNwO0luIElTLUlTLCBhIG5vZGUgd2l0aCB0aGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm92ZXJsb2Fk IGJpdCBzZXQgJnF1b3Q7c2hhbGwgbm90JnF1b3Q7IChJU08gMTA1ODkpIGJlIGNvbnNpZGVyZWQg Zm9yIHRyYW5zaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ib3dldmVyLCB0aGUgdXNlIG9mICZxdW90O1NIT1VMRCBOT1QgYXBwb2ludCBhbiBS QnJpZGdlIGluIG92ZXJsb2FkJnF1b3Q7IGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7U0hPVUxEIHJlLWFzc2lnbiBWTEFOcyBmcm9t IHRoZSBvdmVybG9hZGVkIFJCcmlkZ2UmcXVvdDsgbGVhdmVzIGEgcG90ZW50aWFsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ob2xlIGluIHRoZSBw cm9wZXIgZm9yd2FyZGluZyBvZiBUUklMTCBkYXRhIHBhY2tlcnMuJm5ic3A7Jm5ic3A7V2h5IGFy ZW4ndCBNVVNUPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5OT1QvTVVTVCB1c2VkPyZuYnNwOyZuYnNwO0lzIHRoZXJlIHNvbWV0aGluZyBpbiB0aGUg c3BlY2lmaWMgdXNlIG9mIElTLUlTIGJ5IFRSSUxMPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGF0IEkgYW0gbWlzc2luZz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIEFwcG9pbnRlZCBGb3J3YXJkZXIgZnVuY3Rpb24gaGFzIHRvIGRvIHdpdGggYWNjZXB0aW5n IGZyYW1lcyBmcm9tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5lbmQgc3RhdGlvbnMgZm9yIGluZ3Jlc3MgYW5kIGVncmVzc2luZyBmcmFtZXMgdG8g ZW5kIHN0YXRpb25zLiBJdCBkb2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ub3QgaGF2ZSBhbnl0aGluZyB0byBkbyB3aXRoIFRSSUxMIERhdGEg cGFja2V0IHRyYW5zaXQgcm91dGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uc2lkZXIgdGhlIGZvbGxvd2luZyBjYXNlOiB0d28gVFJJ TEwgc3dpdGNoZXMgKFJCcmlkZ2VzKSBSQjEgYW5kIFJCMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXJlIGNvbm5lY3RlZCBieSBhIGxpbmsgTDEg dGhhdCBhbHNvIGhhcyBlbmQgc3RhdGlvbnMgb24gaXQuIFRoZSBlbmQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0YXRpb25zIGFyZSBhbGwgaW4g VkxBTiBYLiBUaGVyZSBhcmUgb3RoZXIgZW5kIHN0YXRpb25zIGluIFZMQU4gWCBpbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIFRSSUxMIGNh bXB1cyBub3Qgb24gTDEgYnV0IGFsbCBvZiB0aGVzZSBvdGhlciBlbmQgc3RhdGlvbnMgYXJlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kaXJlY3Rs eSBjb25uZWN0ZWQgdG8gUkIyLiBSQjIgaXMgaW4gb3ZlcmxvYWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVuZGVyIHRoZXNlIGNpcmN1bXN0 YW5jZXMsIFJCMiBzaG91bGQgYmUgdGhlIEFwcG9pbnRlZCBGb3J3YXJkZXIgZm9yPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5WTEFOIFggYXMgdGhh dCB3YXkgdHJhZmZpYyBiZXR3ZWVuIGFsbCBvZiB0aGUgVkxBTiBYIGVuZCBzdGF0aW9ucyBjYW48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlIGZv cndhcmRlZCBieSBSQjIgd2l0aG91dCBhbnkgSVMtSVMgcm91dGluZyBhdCBhbGwuIFJCMiB3aWxs IGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmJlLCBpbiBlZmZlY3QsIGZvcndhcmRpbmcgbmF0aXZlIGZyYW1lcyBiZXR3ZWVuIFJCMiBwb3J0 cyAoYWx0aG91Z2gsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5mb3IgY29uc2lzdGVuY3ksIHRoZSBUUklMTCBzcGVjaWZpY2F0aW9ucyBzYXkgdGhh dCBSQjIgaW5ncmVzc2VzIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlZMQU4gWCB0cmFmZmljIGJ5IGVuY2Fwc3VsYXRpbmcgaXQgaW50byBh IFRSSUxMIERhdGEgZnJhbWUsIGFuZCB0aGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3RpY2VzIGl0IGlzIGRlc3RpbmVkIGZvciBhbiBlbmQg c3RhdGlvbiBvbiBhIGxvY2FsIHBvcnQsIGltbWVkaWF0ZWx5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZWNhcHN1bGF0ZXMgaXQsIGFuZCBzZW5k cyBpdCBvdXQgdGhhdCBwb3J0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGlu IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGlzIHNob3VsZCBiZSBhbiBlYXN5IERJU0NVU1MgdG8g Y2xlYXI7IGVpdGhlciBwb2ludCB0byB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBpZWNlIEknbSBtaXNzaW5nLCBvciBkb24ndCB1c2UgYW4g b3ZlcmxvYWRlZCBub2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb25hbGQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRvbmFsZCBFLiBFYXN0bGFrZSAzcmQmbmJzcDsmbmJzcDsgJiM0MzsxLTUwOC0zMzMtMjI3 MCAoY2VsbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0E8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpk M2UzZTNAZ21haWwuY29tIj5kM2UzZTNAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FDF0EF47D4FE4A6296B3FB3559287AC4ciscocom_-- From nobody Thu Jan 19 06:21:31 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEBC1295FA; Thu, 19 Jan 2017 06:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=g0H5O0Uo; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=AACyDRCM 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 Q9hL6gDGj7Mv; Thu, 19 Jan 2017 06:21:25 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28DA1295F2; Thu, 19 Jan 2017 06:21:24 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 423E9208ED; Thu, 19 Jan 2017 09:21:24 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 19 Jan 2017 09:21:24 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=rlfydeBBsJ9pidN q0OS6rS2xgSQ=; b=g0H5O0UozJVNbRt6ntVS3cRNEujvhUb+uEGslJUI/CDzElI Xsm05SPrbZCm+mJ2wU+qVmUmkWM4NSDSnREV96b8zXZI0x4fsqXRkpoIy43nRLzb 1Rv3QhaN98j/MGvkG9ew59dw54nwzvcDD0pxJmKjpD8aHZ1O/mvovjQCi8yw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=rlfydeBBsJ9pidNq0OS6rS2xgSQ=; b=AACyDRCMu8iPCBRSZIiD orsVidJ59bBuKaLpVLA3Rv0GNosOEefMWJsHJIZW5li82iquFin/nKLQQN1i3TR4 ngAbqHo6gZeVXbvjzFjvtAZBEgFgdIeZw6vcrcNKg11LQUXXCrwStGLzY/I3Ty4F VH3EX/1UXG4r21Oq5QVJudA= X-ME-Sender: X-Sasl-enc: UEjyJ9IoSzN3e9BmSfq2JCR+5rrNifsipOgzbR5utfNi 1484835683 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id EF36F2418A; Thu, 19 Jan 2017 09:21:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Thu, 19 Jan 2017 09:21:21 -0500 Content-Transfer-Encoding: 7bit Message-Id: <049DB5B4-422C-496D-824E-3ABB290D289A@cooperw.in> References: <148475513653.2001.17665625207200773811.idtracker@ietfa.amsl.com> To: Donald Eastlake X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "trill-chairs@ietf.org" , draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG , "shares@ndzh.com" , "trill@ietf.org" Subject: Re: [trill] Alissa Cooper's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:21:26 -0000 > On Jan 18, 2017, at 2:02 PM, Donald Eastlake wrote: > > Hi Alissa, > > On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper wrote: >> >> Alissa Cooper has entered the following ballot position for >> draft-ietf-trill-directory-assist-mechanisms-11: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Since this document implies the creation of centralized databases of >> addressing information, I think it would help to call out in Section 6 > > Yes, although such centralized databases are quite common currently in > terms of data center management and orchestration system databases. > >> the need to secure the directory contents themselves, not just against >> abuses of the push or pull services but in general against unauthorized >> access. > > OK. > > I'm not sure the need to secure directories resident on TRILL switches > is that much different from the need to secure the routing function > and routing data of TRILL switches. But the draft also supports Pull > Directories hosted on end stations and I think something should be > said about end station security in connection with the end station > hosting a directory. Sounds good. > >> Also, I recall in prior evaluations of TRILL documents some discussion >> about how TRILL deals with ephemeral MAC addresses and my recollection is >> that they are likely prohibited by policy on TRILL networks. But if there > > The payload of a TRILL Data packet looks like an Ethernet frame. TRILL > delivers it to end station(s) based on the destination MAC address > and, by default, learns about MAC reachability by observing the source > MAC address. So, while I would not say ephemeral or frequently > changing MAC addresses are prohibited by "policy", they would reduce > the efficiency of a TRILL campus by frequently obsoleting learned MAC > reachability information. > >> is some interaction between ephemeral MAC addresses and the services >> described in this document that would be good for implementors to be >> aware of, those are probably worth mentioning. > > Directories need not be complete. If, for example, there were servers > with fixed MACs and clients with mostly ephemeral MACs, I think it > would still be reasonable to have the reachability (edge attachment > point) information for the fixed MACs in a directory. Something about > this could be added to the draft. I think that would be helpful. Thanks, Alissa > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Fri Jan 20 21:02:22 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D8512988A; Fri, 20 Jan 2017 21:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 YJO9TBP3Eefe; Fri, 20 Jan 2017 21:02:14 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFABC129888; Fri, 20 Jan 2017 21:02:10 -0800 (PST) Received: from [192.168.1.11] (unknown [49.150.98.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D34F418013D1; Sat, 21 Jan 2017 06:02:06 +0100 (CET) From: Loa Andersson To: rtg-dir@ietf.org, trill-chairs@ietf.org, draft-ietf-trill-ecn-support@ietf.org Message-ID: Date: Sat, 21 Jan 2017 13:02:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Yemin \(Amy'" , trill@ietf.org Subject: [trill] QA review of draft-ietf-trill-ecn-support X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 05:02:16 -0000 Authors, I have been asked to do a Routing Area Directorate QA review of draft-ietf-trill-ecn-support. Caveat - I'm not a congestion control expert, and this will show up in my comments. The place where I ask for clarifications might be perfectly clear for a reader that is up to speed in the area. Summary: I think the document is on the right track, for a reader not an expert in the area there are a lot of abbreviations that are not properly expanded. I also think that it would be a good idea to more clearly make the the case why the document is needed (abstract and/or introduction). After a while I stop trying to distinguish between "Minor issues" and "Nits" and placed everything as Minor Issues. I guess I could have done everything as Nits :). Other than the Comment/Minor Issues I find the document pretty solid, though I sometimes found it hard to parse sentences. If you want I can take a look at that aspect once what is in this review has been addressed. Comments: Last paragraph of the Introduction ---------------------------------- Whichever RBridges do not support ECN, this specification ensures congestion notification will propagate safely to Destination because the packet will be dropped if explicit congestion notification cannot be propagated and drop is itself an implicit form of congestion notification. Is this logic really watertight? What if the packet is dropped because of a checksum error? Major Issues: Minor Issues: Abstract -------- I find the Abstract a bit meager, a little more context would be good. Maybe lead with some short words about what ECN is good for. And maybe use this from the Introduction: This specification provides for any ECN marking in the traffic at the ingress to be copied into the TRILL Extension Header Flags Word. It also enables congestion marking by a congested RBridge such as RBn or RB1 above in the TRILL Header Extension Flags Word [RFC7179]. ECNencapGuide ------------- This reference has expired, probably not a problem since Bob is a co-author of both documents. TRILL Header ------------ Referred to in section in the Introduction, I think a reference would be good. The ECN Specific Extended Header Flags -------------------------------------- The pictures is less than intuitive, it took me quite some time de-code it. I did the following: Critical (?) flags 0 - CRHbH (no expansion found in document) 1 - CRItE (no expansion found in document) 2 - CRRsv (no expansion found in document) CHbH flags (Critical Hop by Hop flags - no expansion found in document) 3 - unassigned 4 - unassigned 5 - unassigned 6 - unassigned 7 - CRCAF (no expansion found in document) NCHbH flags = Non-Critical Hop-by-Hop flags 8 - NCCAF (no expansion found in document) 9 - unassigned 10 - unassigned 11 - unassigned ------------------------------------------- 12 - ECN = Explicit Congestion Notification 13 (two bit flags) ------------------------------------------- CRSV flags (no expansion found in document) ------------------------------------------- 14 - Ext Hop Cnt (no expansion found in document) 15 three bit field 16 ------------------------------------------ NCRSV flags (no expansion found in document) 17 - unassigned 18 - unassigned 19 - unassigned 20 - unassigned ------------------------------------------ CItE flags = Critical Ingress-to-Egress ------------------------------------------ 21 - unassigned 22 - unassigned 23 - unassigned 24 - unassigned 25 - unassigned 26 - CCE = Critical Congestion Experienced ------------------------------------------ NCItE flags = Non Critical Ingress-to-Egress -------------------------------------------- 27 - Ext Clr (no expansion found in document) 28 two bit field -------------------------------------------- 29 - unassigned 30 - unassigned 31 - unassigned Multi-bit flags --------------- In the context I've been active "flags" are one bit, if there are multiple bits they are called fields. I understand that in the context this is written there are multiple bit flags. Bit 11 and 12 ------------- Bit 11 and 12 has the following code points: Binary Name Meaning ------ ------- ----------------------------------- 00 Not-ECT Not ECN-Capable Transport 01 ECT(1) ECN-Capable Transport (1) 10 ECT(0) ECN-Capable Transport (0) 11 NCCE Non-Critical Congestion Experienced Table 1. TRILL-ECN Field Codepoints There is no good explanation what ECT(0) and ECT(1) means, even though it is (page 9) said that "ECT(1) as a lesser severity level, termed the Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is a higher severity level, but this should be clearly spelled out. RFC 3168 does not make the distinction between ECT(0) and ECT(1), but says that it will be done in future RFCs; since this is about 3000 RFCs ago it might have happened but I couldn't find it. If this has been done I think a reference would be good. Code Point 0b11 --------------- The text above Table 1 says: OLD "However codepoint 11 is called Non-Critical Congestion Experienced (NCCE)..." I think this should be: However code point 0b11 is called Non-Critical Congestion Experienced (NCCE)..." The text further says that the code point is call NCCE to distinguish it from Congestion Experienced in IP. The question I have is why it is necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10? ECN SUpport ----------- The first paragraph has "logically" at three places, what would be the difference if these "logically" are dropped? First sentence in sectuion 3.1 ------------------------------ The sentence says: "The ingress behavior is as follows:" I would say "The behavior of an ingress RBridge is as follows:" or even "The behavior of an ingress RBridge MUST be as follows:" cleared vs set to zero ---------------------- The last sub-bullet in the first main bullet of section 3.1 says: "ensure the CCE flag is cleared to zero (Flags Word bit 26)." I would have used "cleared" or "swt to zero". First line section 3,2 ---------------------- s/ahow/shown Caveat I normally don't English grammar reviews, but sometimes I can't stop myself :) Second line first main bullet in section 3.2 -------------------------------------------- I prefer the format "guidelines in RFC 7567 [RFC7567]" Third sub-bullet in the third main bullet of section 3.2 --------------------------------------------------------- It says: "+ set the TRILL-ECN field to Not-ECT (00);" Here you use "field" instead of "flag", which is fine, but the document should be consistent. Either: + set the TRILL-ECN field to Not-ECT (0b00); or + set the TRILL-ECN flag to Not-ECT (0b00); Egress ECN Support ------------------ First sentence: "If the egress RBridge does not support ECN, it will ignore bits 12 and 13 of any Flags Word that is present, because it does not contain any special ECN logic." in "it will ignore" what does "it" refer to? SHould it be: "If the egress RBridge does not support ECN, the RBridge will ignore the TRILL-ECN field (bits 12 and 13) if a Flags Word that is present, because it has no ECN logic." TRILL Support for ECN Variants ------------------------------ The sedond sentence of section four says: Section 3 specifies interworking between TRILL and the original standardized form of ECN in IP [RFC3168]. RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to RFC 3168 or does the updates come into plan. IF the updates are in scope I think the sentence should say: Section 3 specifies interworking between TRILL and the original standardized form of ECN in IP RFC 3168 [RFC3168], and the updates in RFC4310 [RFC4301] and RFC 6040 [6040]. Nits: Codepoints ---------- at several places "codepoint(s)" I think the words IANA and the RFC Editor use is "code point(s)" /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jan 21 03:14:43 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C380D129A73; Sat, 21 Jan 2017 03:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 1uiachnWorSz; Sat, 21 Jan 2017 03:14:40 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 248191299B4; Sat, 21 Jan 2017 03:14:39 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=71.13.235.4; From: "Susan Hares" To: "'Loa Andersson'" , , , References: In-Reply-To: Date: Sat, 21 Jan 2017 06:10:41 -0500 Message-ID: <000001d273d7$016784d0$04368e70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIJRraBnau4pI8DyrHztW6f57h6AaDVIHlQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Yemin \(Amy'" , trill@ietf.org Subject: Re: [trill] QA review of draft-ietf-trill-ecn-support X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 11:14:41 -0000 Loa: Thank you for providing this review to the authors. Sue Hares Trill co-chair -----Original Message----- From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, January 21, 2017 12:02 AM To: rtg-dir@ietf.org; trill-chairs@ietf.org; draft-ietf-trill-ecn-support@ietf.org Cc: 'Yemin (Amy'; trill@ietf.org Subject: [trill] QA review of draft-ietf-trill-ecn-support Authors, I have been asked to do a Routing Area Directorate QA review of draft-ietf-trill-ecn-support. Caveat - I'm not a congestion control expert, and this will show up in my comments. The place where I ask for clarifications might be perfectly clear for a reader that is up to speed in the area. Summary: I think the document is on the right track, for a reader not an expert in the area there are a lot of abbreviations that are not properly expanded. I also think that it would be a good idea to more clearly make the the case why the document is needed (abstract and/or introduction). After a while I stop trying to distinguish between "Minor issues" and "Nits" and placed everything as Minor Issues. I guess I could have done everything as Nits :). Other than the Comment/Minor Issues I find the document pretty solid, though I sometimes found it hard to parse sentences. If you want I can take a look at that aspect once what is in this review has been addressed. Comments: Last paragraph of the Introduction ---------------------------------- Whichever RBridges do not support ECN, this specification ensures congestion notification will propagate safely to Destination because the packet will be dropped if explicit congestion notification cannot be propagated and drop is itself an implicit form of congestion notification. Is this logic really watertight? What if the packet is dropped because of a checksum error? Major Issues: Minor Issues: Abstract -------- I find the Abstract a bit meager, a little more context would be good. Maybe lead with some short words about what ECN is good for. And maybe use this from the Introduction: This specification provides for any ECN marking in the traffic at the ingress to be copied into the TRILL Extension Header Flags Word. It also enables congestion marking by a congested RBridge such as RBn or RB1 above in the TRILL Header Extension Flags Word [RFC7179]. ECNencapGuide ------------- This reference has expired, probably not a problem since Bob is a co-author of both documents. TRILL Header ------------ Referred to in section in the Introduction, I think a reference would be good. The ECN Specific Extended Header Flags -------------------------------------- The pictures is less than intuitive, it took me quite some time de-code it. I did the following: Critical (?) flags 0 - CRHbH (no expansion found in document) 1 - CRItE (no expansion found in document) 2 - CRRsv (no expansion found in document) CHbH flags (Critical Hop by Hop flags - no expansion found in document) 3 - unassigned 4 - unassigned 5 - unassigned 6 - unassigned 7 - CRCAF (no expansion found in document) NCHbH flags = Non-Critical Hop-by-Hop flags 8 - NCCAF (no expansion found in document) 9 - unassigned 10 - unassigned 11 - unassigned ------------------------------------------- 12 - ECN = Explicit Congestion Notification 13 (two bit flags) ------------------------------------------- CRSV flags (no expansion found in document) ------------------------------------------- 14 - Ext Hop Cnt (no expansion found in document) 15 three bit field 16 ------------------------------------------ NCRSV flags (no expansion found in document) 17 - unassigned 18 - unassigned 19 - unassigned 20 - unassigned ------------------------------------------ CItE flags = Critical Ingress-to-Egress ------------------------------------------ 21 - unassigned 22 - unassigned 23 - unassigned 24 - unassigned 25 - unassigned 26 - CCE = Critical Congestion Experienced ------------------------------------------ NCItE flags = Non Critical Ingress-to-Egress -------------------------------------------- 27 - Ext Clr (no expansion found in document) 28 two bit field -------------------------------------------- 29 - unassigned 30 - unassigned 31 - unassigned Multi-bit flags --------------- In the context I've been active "flags" are one bit, if there are multiple bits they are called fields. I understand that in the context this is written there are multiple bit flags. Bit 11 and 12 ------------- Bit 11 and 12 has the following code points: Binary Name Meaning ------ ------- ----------------------------------- 00 Not-ECT Not ECN-Capable Transport 01 ECT(1) ECN-Capable Transport (1) 10 ECT(0) ECN-Capable Transport (0) 11 NCCE Non-Critical Congestion Experienced Table 1. TRILL-ECN Field Codepoints There is no good explanation what ECT(0) and ECT(1) means, even though it is (page 9) said that "ECT(1) as a lesser severity level, termed the Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is a higher severity level, but this should be clearly spelled out. RFC 3168 does not make the distinction between ECT(0) and ECT(1), but says that it will be done in future RFCs; since this is about 3000 RFCs ago it might have happened but I couldn't find it. If this has been done I think a reference would be good. Code Point 0b11 --------------- The text above Table 1 says: OLD "However codepoint 11 is called Non-Critical Congestion Experienced (NCCE)..." I think this should be: However code point 0b11 is called Non-Critical Congestion Experienced (NCCE)..." The text further says that the code point is call NCCE to distinguish it from Congestion Experienced in IP. The question I have is why it is necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10? ECN SUpport ----------- The first paragraph has "logically" at three places, what would be the difference if these "logically" are dropped? First sentence in sectuion 3.1 ------------------------------ The sentence says: "The ingress behavior is as follows:" I would say "The behavior of an ingress RBridge is as follows:" or even "The behavior of an ingress RBridge MUST be as follows:" cleared vs set to zero ---------------------- The last sub-bullet in the first main bullet of section 3.1 says: "ensure the CCE flag is cleared to zero (Flags Word bit 26)." I would have used "cleared" or "swt to zero". First line section 3,2 ---------------------- s/ahow/shown Caveat I normally don't English grammar reviews, but sometimes I can't stop myself :) Second line first main bullet in section 3.2 -------------------------------------------- I prefer the format "guidelines in RFC 7567 [RFC7567]" Third sub-bullet in the third main bullet of section 3.2 --------------------------------------------------------- It says: "+ set the TRILL-ECN field to Not-ECT (00);" Here you use "field" instead of "flag", which is fine, but the document should be consistent. Either: + set the TRILL-ECN field to Not-ECT (0b00); or + set the TRILL-ECN flag to Not-ECT (0b00); Egress ECN Support ------------------ First sentence: "If the egress RBridge does not support ECN, it will ignore bits 12 and 13 of any Flags Word that is present, because it does not contain any special ECN logic." in "it will ignore" what does "it" refer to? SHould it be: "If the egress RBridge does not support ECN, the RBridge will ignore the TRILL-ECN field (bits 12 and 13) if a Flags Word that is present, because it has no ECN logic." TRILL Support for ECN Variants ------------------------------ The sedond sentence of section four says: Section 3 specifies interworking between TRILL and the original standardized form of ECN in IP [RFC3168]. RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to RFC 3168 or does the updates come into plan. IF the updates are in scope I think the sentence should say: Section 3 specifies interworking between TRILL and the original standardized form of ECN in IP RFC 3168 [RFC3168], and the updates in RFC4310 [RFC4301] and RFC 6040 [6040]. Nits: Codepoints ---------- at several places "codepoint(s)" I think the words IANA and the RFC Editor use is "code point(s)" /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From nobody Thu Jan 26 01:31:45 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE30129508; Thu, 26 Jan 2017 01:31:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148542310490.16618.7851491420441729577.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2017 01:31:44 -0800 Archived-At: Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-address-flush-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 09:31:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL: Address Flush Message Authors : Weiguo Hao Donald E. Eastlake Yizhou Li Mohammed Umair Filename : draft-ietf-trill-address-flush-02.txt Pages : 20 Date : 2017-01-26 Abstract: The TRILL (TRansparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local MAC addresses and edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and edge switch of attachment from the decapsulation of remotely sourced TRILL Data packets. This document specifies a message by which an originating TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting and can assist in achieving more rapid convergence in case of topology or configuration change. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-address-flush-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-address-flush-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 26 14:09:46 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CFE129C0C; Thu, 26 Jan 2017 14:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_IHjQA6rFsb; Thu, 26 Jan 2017 14:09:42 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 8D9EC129BFD; Thu, 26 Jan 2017 14:09:42 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id 203so6527973ith.2; Thu, 26 Jan 2017 14:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KkjBNeRZSH1uG2dsrAjIqV+NEEhtOgMabN1sHfP/ix8=; b=FOPWjxG6P4SUDR3UYaK88yKTcinYie37IR5Z1nN/4/TiIu5s993rrBcJX5DVuHC7fI 6r+DhOC1Xcl1EJCIJGPmo7Z8fdEWwztcLt5H9lL6x9OsL8Lkz0VJa+Xf1hFkoG2S72yR oPBvgyzKQ6E7eSJWa9RuifjEzXwzGoBdi+3xNxH2JG7Co5I6IKNNpTD2eubF7BWP+7re Lgtg8UgTIbpi0W19hLOEigRPkFYA+Drs1nrWCtT38tVhP7E43Qtr4CxuUzjJJtTp6vOs fzoJMaK62MXT+eCoqWWIhBQctooMwab9tKCkRozYRLV7qvJYZpi04HTm8mDjcsNAPYW+ gdNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KkjBNeRZSH1uG2dsrAjIqV+NEEhtOgMabN1sHfP/ix8=; b=BMF2Q0UG/lXOp4x/SH6zCmI2kTIndaWXS0cVZj4LiUzGAOPaJYdOpg8DvUeU2q/5PH 9D1loBh90ASmBSvg6pqOAUfzmtudeD395Dy6YNVdR/dRJRn58uTCHgDOSlegiMdDSuGs arkdoTd5aCzNVroeavtqJnUDSfdClPr6zLX9ccI29kR/5Md82vRA1tNTxNfr656scVBY VwDtKTJEH6NMYx9pkkXO2eQxzM72xciYNrTmZ7noxDeIYYFFb1UlnOr3dttTZKrxUWWR ksVe7X3G38fiVnmRVBKbPU66e4K1DAGIQ/yXHzl8I0C2rHE+jZXjAKFPO0g3TjS3QWgF lTrA== X-Gm-Message-State: AIkVDXIfabK9JzFZHPU+z3Yaz6j7asBh4KWAvD7Y/ogDsNWumYjVu8VwKVtpqXBG3x4jcFHbj0LtlosD6H9a4w== X-Received: by 10.36.170.68 with SMTP id y4mr689740iti.7.1485468581571; Thu, 26 Jan 2017 14:09:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Thu, 26 Jan 2017 14:09:26 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Thu, 26 Jan 2017 17:09:26 -0500 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-dir@ietf.org" , draft-ietf-trill-ecn-support@ietf.org, "trill-chairs@ietf.org" , "Yemin \(Amy" , "trill@ietf.org" Subject: Re: [trill] QA review of draft-ietf-trill-ecn-support X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 22:09:45 -0000 Hi Loa, Thanks for your comments. See below On Sat, Jan 21, 2017 at 12:02 AM, Loa Andersson wrote: > Authors, > > I have been asked to do a Routing Area Directorate QA review of > draft-ietf-trill-ecn-support. > > Caveat - I'm not a congestion control expert, and this will show up in > my comments. The place where I ask for clarifications might be perfectly > clear for a reader that is up to speed in the area. > > Summary: > > I think the document is on the right track, for a reader not an > expert in the area there are a lot of abbreviations that are not > properly expanded. I also think that it would be a good idea to more > clearly make the the case why the document is needed (abstract > and/or introduction). > > After a while I stop trying to distinguish between "Minor issues" > and "Nits" and placed everything as Minor Issues. I guess I could > have done everything as Nits :). OK :-) > Other than the Comment/Minor Issues I find the document pretty solid, Thanks. > though I sometimes found it hard to parse sentences. > If you want I can take a look at that aspect once what is in this > review has been addressed. > > Comments: > > Last paragraph of the Introduction > ---------------------------------- > > Whichever RBridges do not support ECN, this > specification ensures congestion notification will propagate safely > to Destination because the packet will be dropped if explicit > congestion notification cannot be propagated and drop is itself an > implicit form of congestion notification. > > Is this logic really watertight? What if the packet is dropped because of a > checksum error? I think the point of that paragraph is to overcome the presumption many readers might have that ECN marking would be useless if the Destination does not understand ECN marking. > Major Issues: > > > Minor Issues: > > Abstract > -------- > I find the Abstract a bit meager, a little more context would be good. > > Maybe lead with some short words about what ECN is good for. > > And maybe use this from the Introduction: > > This specification provides for any ECN marking in the traffic at the > ingress to be copied into the TRILL Extension Header Flags Word. It > also enables congestion marking by a congested RBridge such as RBn or > RB1 above in the TRILL Header Extension Flags Word [RFC7179]. OK. How about this: Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better flow control without packet drops. This document extends ECN to TRILL switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179). > ECNencapGuide > ------------- > > This reference has expired, probably not a problem since Bob is a > co-author of both documents. > > TRILL Header > ------------ > > Referred to in section in the Introduction, I think a reference would be > good. OK. > The ECN Specific Extended Header Flags > -------------------------------------- > > The pictures is less than intuitive, it took me quite some time de-code it. > I did the following: > Critical (?) flags > 0 - CRHbH (no expansion found in document) > 1 - CRItE (no expansion found in document) > 2 - CRRsv (no expansion found in document) > > CHbH flags (Critical Hop by Hop flags - no expansion found in document) > 3 - unassigned > 4 - unassigned > 5 - unassigned > 6 - unassigned > 7 - CRCAF (no expansion found in document) > > NCHbH flags = Non-Critical Hop-by-Hop flags > 8 - NCCAF (no expansion found in document) > 9 - unassigned > 10 - unassigned > 11 - unassigned > ------------------------------------------- > 12 - ECN = Explicit Congestion Notification > 13 (two bit flags) > ------------------------------------------- > > CRSV flags (no expansion found in document) > ------------------------------------------- > 14 - Ext Hop Cnt (no expansion found in document) > 15 three bit field > 16 > ------------------------------------------ > > NCRSV flags (no expansion found in document) > 17 - unassigned > 18 - unassigned > 19 - unassigned > 20 - unassigned > ------------------------------------------ > > CItE flags = Critical Ingress-to-Egress > ------------------------------------------ > 21 - unassigned > 22 - unassigned > 23 - unassigned > 24 - unassigned > 25 - unassigned > 26 - CCE = Critical Congestion Experienced > ------------------------------------------ > > NCItE flags = Non Critical Ingress-to-Egress > -------------------------------------------- > 27 - Ext Clr (no expansion found in document) > 28 two bit field > -------------------------------------------- > 29 - unassigned > 30 - unassigned > 31 - unassigned I'm not sure how much explanation/definition needs to appear in this document for bits that are irrelevant to the document. All of your "no expansion found in document" comments are true and probably a bit more should be said but the draft does, in connection with bits other than those it specifies, say See [RFC7780] and [RFC7179] for the meaning of the other bits. The format seems moderately clear and is the same as in Section 10.2 of RFC 7780. Adding a mention that the TRILL Header Extension Flags Word is 32-bits and the bit numbers are across the top might help. Also, for those wishing to see a more tabular presentation, a pointer to the IANA Registry http://www.iana.org/assignments/trill-parameters/trill-parameters.xhtml#extended-header-flags might help. > Multi-bit flags > --------------- > > In the context I've been active "flags" are one bit, if there are multiple > bits they are called fields. I understand that in the context > this is written there are multiple bit flags. At the beginning of Section 2, it says "a two-bit TRILL-ECN field". Since the name of the TRILL Header "Extension Flags Word" is now embedded in multiple RFCs, I don't think that should be changed but I wouldn't have any problem reviewing the draft to see that multi-bit regions of that 32-bit word are consistently referred to as fields. > Bit 11 and 12 > ------------- > > Bit 11 and 12 has the following code points: > > Binary Name Meaning > ------ ------- ----------------------------------- > 00 Not-ECT Not ECN-Capable Transport > 01 ECT(1) ECN-Capable Transport (1) > 10 ECT(0) ECN-Capable Transport (0) > 11 NCCE Non-Critical Congestion Experienced > > Table 1. TRILL-ECN Field Codepoints > > There is no good explanation what ECT(0) and ECT(1) means, even though > it is (page 9) said that "ECT(1) as a lesser severity level, termed the > Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is > a higher severity level, but this should be clearly spelled out. That distinction between ECT(0) and ECT(1) only applies if the PCN variant of ECN is in use which is why the text you quote is in a subsection of Section 4 (TRILL Support for ECN Variants). There is a reference to RFC 6660 which talks about this. Perhaps we can make that clearer. > RFC 3168 does not make the distinction between ECT(0) and ECT(1), but > says that it will be done in future RFCs; since this is about 3000 RFCs > ago it might have happened but I couldn't find it. If this has been done > I think a reference would be good. This distincition is in RFC 6660 on PCN (Pre-Congestion Notification). > Code Point 0b11 > --------------- > The text above Table 1 says: > OLD > "However codepoint 11 is called Non-Critical Congestion Experienced > (NCCE)..." > I think this should be: > However code point 0b11 is called Non-Critical Congestion Experienced > (NCCE)..." OK. > The text further says that the code point is call NCCE to distinguish > it from Congestion Experienced in IP. The question I have is why it is > necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10? Because the meaning of the other three code points is the same in TRILL and IP. > ECN SUpport > ----------- > > The first paragraph has "logically" at three places, what would be the > difference if these "logically" are dropped? Probably not. I think that word was included to be careful not to overly constrain the order of processing within a TRILL switch. > First sentence in sectuion 3.1 > ------------------------------ > > The sentence says: > "The ingress behavior is as follows:" > > I would say > "The behavior of an ingress RBridge is as follows:" > or even > "The behavior of an ingress RBridge MUST be as follows:" OK. > cleared vs set to zero > ---------------------- > The last sub-bullet in the first main bullet of section 3.1 says: > "ensure the CCE flag is cleared to zero (Flags Word bit 26)." I would > have used "cleared" or "swt to zero". I think "set to zero" is clearer. > First line section 3,2 > ---------------------- > s/ahow/shown > Caveat I normally don't English grammar reviews, but sometimes I can't stop > myself :) OK. > Second line first main bullet in section 3.2 > -------------------------------------------- > > I prefer the format "guidelines in RFC 7567 [RFC7567]" I really don't see any benefit to that and I think "RFC xxxx [RFCxxxx]" is not used in TRILL RFCs. > Third sub-bullet in the third main bullet of section 3.2 > --------------------------------------------------------- > > It says: > "+ set the TRILL-ECN field to Not-ECT (00);" > > Here you use "field" instead of "flag", which is fine, but the document > should be consistent. Either: > + set the TRILL-ECN field to Not-ECT (0b00); > or > + set the TRILL-ECN flag to Not-ECT (0b00); I agree with your earlier comment that "field" is generally better. > Egress ECN Support > ------------------ > First sentence: > "If the egress RBridge does not support ECN, it will ignore bits 12 > and 13 of any Flags Word that is present, because it does not contain > any special ECN logic." > > in "it will ignore" what does "it" refer to? > > SHould it be: > > "If the egress RBridge does not support ECN, the RBridge will ignore > the TRILL-ECN field (bits 12 and 13) if a Flags Word that is > present, because it has no ECN logic." Yes, although it might be even clearer in the first line to say "... ECN, that RBridge will ..." > TRILL Support for ECN Variants > ------------------------------ > The second sentence of section four says: > > Section 3 specifies interworking between TRILL and the original > standardized form of ECN in IP [RFC3168]. > > RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to > RFC 3168 or does the updates come into plan. IF the updates are in > scope I think the sentence should say: > > Section 3 specifies interworking between TRILL and the original > standardized form of ECN in IP RFC 3168 [RFC3168], and the updates > in RFC4310 [RFC4301] and RFC 6040 [6040]. Interestingly, although RFC Editor meta-data consistencly shows RFC 4301 as updating RFC 3168, this is not indicated on the first page of RFC 4301. While ECN is mentioned a number of times in RFC 4301 and that RFC could be viewed as extending ECN, I'm not quite sure what, if any, change RFC 4301 makes to the behavior standardized RFC in 3168. I'll look at this more closely but I think the text currently in the draft is OK and need not refer to either RFC 4301 or RFC 6040. > Nits: > > Codepoints > ---------- > at several places "codepoint(s)" I think the words IANA and the > RFC Editor use is "code point(s)" While I didn't to an exhaustive search, everywhere I looked in the ECN and PCN RFCs, "codepoint" is used so I would prefer to leave this unchanged for now. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > /Loa > -- > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jan 28 00:45:04 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C146129453; Sat, 28 Jan 2017 00:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 LvLivUpzPZFe; Sat, 28 Jan 2017 00:44:55 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE6512946C; Sat, 28 Jan 2017 00:44:54 -0800 (PST) Received: from [192.168.1.11] (unknown [122.52.28.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D57FE18013DA; Sat, 28 Jan 2017 09:44:49 +0100 (CET) To: Donald Eastlake References: From: Loa Andersson Message-ID: <2a67b907-bba6-31c9-2d53-7581df97cac4@pi.nu> Date: Sat, 28 Jan 2017 16:44:40 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , draft-ietf-trill-ecn-support@ietf.org, "trill-chairs@ietf.org" , "Yemin \(Amy" , "trill@ietf.org" Subject: Re: [trill] QA review of draft-ietf-trill-ecn-support X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 08:44:58 -0000 Donald, I'm pretty happy with your response on my comments. I think that the agreed updates will go a long way to improve readability of the document. /Loa On 2017-01-27 06:09, Donald Eastlake wrote: > Hi Loa, > > Thanks for your comments. See below > > On Sat, Jan 21, 2017 at 12:02 AM, Loa Andersson wrote: >> Authors, >> >> I have been asked to do a Routing Area Directorate QA review of >> draft-ietf-trill-ecn-support. >> >> Caveat - I'm not a congestion control expert, and this will show up in >> my comments. The place where I ask for clarifications might be perfectly >> clear for a reader that is up to speed in the area. >> >> Summary: >> >> I think the document is on the right track, for a reader not an >> expert in the area there are a lot of abbreviations that are not >> properly expanded. I also think that it would be a good idea to more >> clearly make the the case why the document is needed (abstract >> and/or introduction). >> >> After a while I stop trying to distinguish between "Minor issues" >> and "Nits" and placed everything as Minor Issues. I guess I could >> have done everything as Nits :). > > OK :-) > >> Other than the Comment/Minor Issues I find the document pretty solid, > > Thanks. > >> though I sometimes found it hard to parse sentences. >> If you want I can take a look at that aspect once what is in this >> review has been addressed. >> >> Comments: >> >> Last paragraph of the Introduction >> ---------------------------------- >> >> Whichever RBridges do not support ECN, this >> specification ensures congestion notification will propagate safely >> to Destination because the packet will be dropped if explicit >> congestion notification cannot be propagated and drop is itself an >> implicit form of congestion notification. >> >> Is this logic really watertight? What if the packet is dropped because of a >> checksum error? > > I think the point of that paragraph is to overcome the presumption > many readers might have that ECN marking would be useless if the > Destination does not understand ECN marking. > >> Major Issues: >> >> >> Minor Issues: >> >> Abstract >> -------- >> I find the Abstract a bit meager, a little more context would be good. >> >> Maybe lead with some short words about what ECN is good for. >> >> And maybe use this from the Introduction: >> >> This specification provides for any ECN marking in the traffic at the >> ingress to be copied into the TRILL Extension Header Flags Word. It >> also enables congestion marking by a congested RBridge such as RBn or >> RB1 above in the TRILL Header Extension Flags Word [RFC7179]. > > OK. How about this: > > Explicit congestion notification (ECN) allows a forwarding element > to notify downstream devices, including the destination, of the > onset of congestion without having to drop packets. This can > improve network efficiency through better flow control without > packet drops. This document extends ECN to TRILL switches, > including integration with IP ECN, and provides for ECN marking in > the TRILL Header Extension Flags Word (see RFC 7179). > >> ECNencapGuide >> ------------- >> >> This reference has expired, probably not a problem since Bob is a >> co-author of both documents. >> >> TRILL Header >> ------------ >> >> Referred to in section in the Introduction, I think a reference would be >> good. > > OK. > >> The ECN Specific Extended Header Flags >> -------------------------------------- >> >> The pictures is less than intuitive, it took me quite some time de-code it. >> I did the following: >> Critical (?) flags >> 0 - CRHbH (no expansion found in document) >> 1 - CRItE (no expansion found in document) >> 2 - CRRsv (no expansion found in document) >> >> CHbH flags (Critical Hop by Hop flags - no expansion found in document) >> 3 - unassigned >> 4 - unassigned >> 5 - unassigned >> 6 - unassigned >> 7 - CRCAF (no expansion found in document) >> >> NCHbH flags = Non-Critical Hop-by-Hop flags >> 8 - NCCAF (no expansion found in document) >> 9 - unassigned >> 10 - unassigned >> 11 - unassigned >> ------------------------------------------- >> 12 - ECN = Explicit Congestion Notification >> 13 (two bit flags) >> ------------------------------------------- >> >> CRSV flags (no expansion found in document) >> ------------------------------------------- >> 14 - Ext Hop Cnt (no expansion found in document) >> 15 three bit field >> 16 >> ------------------------------------------ >> >> NCRSV flags (no expansion found in document) >> 17 - unassigned >> 18 - unassigned >> 19 - unassigned >> 20 - unassigned >> ------------------------------------------ >> >> CItE flags = Critical Ingress-to-Egress >> ------------------------------------------ >> 21 - unassigned >> 22 - unassigned >> 23 - unassigned >> 24 - unassigned >> 25 - unassigned >> 26 - CCE = Critical Congestion Experienced >> ------------------------------------------ >> >> NCItE flags = Non Critical Ingress-to-Egress >> -------------------------------------------- >> 27 - Ext Clr (no expansion found in document) >> 28 two bit field >> -------------------------------------------- >> 29 - unassigned >> 30 - unassigned >> 31 - unassigned > > I'm not sure how much explanation/definition needs to appear in this > document for bits that are irrelevant to the document. All of your "no > expansion found in document" comments are true and probably a bit more > should be said but the draft does, in connection with bits other than > those it specifies, say > > See [RFC7780] and [RFC7179] for the meaning of the other > bits. > > The format seems moderately clear and is the same as in Section 10.2 > of RFC 7780. Adding a mention that the TRILL Header Extension Flags > Word is 32-bits and the bit numbers are across the top might > help. Also, for those wishing to see a more tabular presentation, a > pointer to the IANA Registry > http://www.iana.org/assignments/trill-parameters/trill-parameters.xhtml#extended-header-flags > might help. > >> Multi-bit flags >> --------------- >> >> In the context I've been active "flags" are one bit, if there are multiple >> bits they are called fields. I understand that in the context >> this is written there are multiple bit flags. > > At the beginning of Section 2, it says "a two-bit TRILL-ECN > field". Since the name of the TRILL Header "Extension Flags Word" is > now embedded in multiple RFCs, I don't think that should be changed > but I wouldn't have any problem reviewing the draft to see that > multi-bit regions of that 32-bit word are consistently referred to as > fields. > >> Bit 11 and 12 >> ------------- >> >> Bit 11 and 12 has the following code points: >> >> Binary Name Meaning >> ------ ------- ----------------------------------- >> 00 Not-ECT Not ECN-Capable Transport >> 01 ECT(1) ECN-Capable Transport (1) >> 10 ECT(0) ECN-Capable Transport (0) >> 11 NCCE Non-Critical Congestion Experienced >> >> Table 1. TRILL-ECN Field Codepoints >> >> There is no good explanation what ECT(0) and ECT(1) means, even though >> it is (page 9) said that "ECT(1) as a lesser severity level, termed the >> Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is >> a higher severity level, but this should be clearly spelled out. > > That distinction between ECT(0) and ECT(1) only applies if the PCN > variant of ECN is in use which is why the text you quote is in a > subsection of Section 4 (TRILL Support for ECN Variants). There is a > reference to RFC 6660 which talks about this. Perhaps we can make that > clearer. > >> RFC 3168 does not make the distinction between ECT(0) and ECT(1), but >> says that it will be done in future RFCs; since this is about 3000 RFCs >> ago it might have happened but I couldn't find it. If this has been done >> I think a reference would be good. > > This distincition is in RFC 6660 on PCN (Pre-Congestion Notification). > >> Code Point 0b11 >> --------------- >> The text above Table 1 says: >> OLD >> "However codepoint 11 is called Non-Critical Congestion Experienced >> (NCCE)..." >> I think this should be: >> However code point 0b11 is called Non-Critical Congestion Experienced >> (NCCE)..." > > OK. > >> The text further says that the code point is call NCCE to distinguish >> it from Congestion Experienced in IP. The question I have is why it is >> necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10? > > Because the meaning of the other three code points is the same in > TRILL and IP. > >> ECN SUpport >> ----------- >> >> The first paragraph has "logically" at three places, what would be the >> difference if these "logically" are dropped? > > Probably not. I think that word was included to be careful not to > overly constrain the order of processing within a TRILL switch. > >> First sentence in sectuion 3.1 >> ------------------------------ >> >> The sentence says: >> "The ingress behavior is as follows:" >> >> I would say >> "The behavior of an ingress RBridge is as follows:" >> or even >> "The behavior of an ingress RBridge MUST be as follows:" > > OK. > >> cleared vs set to zero >> ---------------------- >> The last sub-bullet in the first main bullet of section 3.1 says: >> "ensure the CCE flag is cleared to zero (Flags Word bit 26)." I would >> have used "cleared" or "swt to zero". > > I think "set to zero" is clearer. > >> First line section 3,2 >> ---------------------- >> s/ahow/shown >> Caveat I normally don't English grammar reviews, but sometimes I can't stop >> myself :) > > OK. > >> Second line first main bullet in section 3.2 >> -------------------------------------------- >> >> I prefer the format "guidelines in RFC 7567 [RFC7567]" > > I really don't see any benefit to that and I think "RFC xxxx > [RFCxxxx]" is not used in TRILL RFCs. > >> Third sub-bullet in the third main bullet of section 3.2 >> --------------------------------------------------------- >> >> It says: >> "+ set the TRILL-ECN field to Not-ECT (00);" >> >> Here you use "field" instead of "flag", which is fine, but the document >> should be consistent. Either: >> + set the TRILL-ECN field to Not-ECT (0b00); >> or >> + set the TRILL-ECN flag to Not-ECT (0b00); > > I agree with your earlier comment that "field" is generally better. > >> Egress ECN Support >> ------------------ >> First sentence: >> "If the egress RBridge does not support ECN, it will ignore bits 12 >> and 13 of any Flags Word that is present, because it does not contain >> any special ECN logic." >> >> in "it will ignore" what does "it" refer to? >> >> SHould it be: >> >> "If the egress RBridge does not support ECN, the RBridge will ignore >> the TRILL-ECN field (bits 12 and 13) if a Flags Word that is >> present, because it has no ECN logic." > > Yes, although it might be even clearer in the first line to say > "... ECN, that RBridge will ..." > >> TRILL Support for ECN Variants >> ------------------------------ >> The second sentence of section four says: >> >> Section 3 specifies interworking between TRILL and the original >> standardized form of ECN in IP [RFC3168]. >> >> RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to >> RFC 3168 or does the updates come into plan. IF the updates are in >> scope I think the sentence should say: >> >> Section 3 specifies interworking between TRILL and the original >> standardized form of ECN in IP RFC 3168 [RFC3168], and the updates >> in RFC4310 [RFC4301] and RFC 6040 [6040]. > > Interestingly, although RFC Editor meta-data consistencly shows RFC > 4301 as updating RFC 3168, this is not indicated on the first page of > RFC 4301. While ECN is mentioned a number of times in RFC 4301 and > that RFC could be viewed as extending ECN, I'm not quite sure what, if > any, change RFC 4301 makes to the behavior standardized RFC in 3168. > > I'll look at this more closely but I think the text currently in the > draft is OK and need not refer to either RFC 4301 or RFC 6040. > >> Nits: >> >> Codepoints >> ---------- >> at several places "codepoint(s)" I think the words IANA and the >> RFC Editor use is "code point(s)" > > While I didn't to an exhaustive search, everywhere I looked in the ECN > and PCN RFCs, "codepoint" is used so I would prefer to leave this > unchanged for now. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> /Loa >> -- >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64