Although the message below was cc'ed to the TRILL WG m= ailing list, for some reason it does not appear in the archives. So I am fo= rwarding it to the list..

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
=C2=A0Donald E. Eastlake 3rd= =C2=A0=C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street,=C2=A0Milfor= d, MA 01757 USA
=C2=A0d3e3e3@gmail.com

---------- Forwarded message ----------
F= rom: Haoweiguo <haoweiguo@huawei.com>
= Date: Sat, Apr 2, 2016 at 9:04 PM
Subject: RE: [trill] =E7=AD=94=E5=A4= =8D: Re: draft-ietf-trill-6439bis WG LC [3/17 to 4/5/2016)
To: "hu.fangwei@zte.com.cn" <= hu.fangwei@zte.com.cn>, Moh= ammed Umair <mohammed.= umair2@ipinfusion.com>
Cc: trill <trill-bounces@ietf.org>, "hu.fangwei@xzte.com.cn" <hu.fangwei@xzte.com.cn>, Liyizhou <liyizhou@huawei.com>, "trill@ietf.org" <trill@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;, "ayabaner@cisco.om" = <ayabaner@cisco.om>, Susan H= ares <shares@ndzh.com>

Support. I think this update is necessary and is ready for adoption.

Thanks,

weiguo

From: hu.fangwei@zte.com.cn [hu.fangwei@zte.com.cn]
Sent: Thursday, March 31, 2016 15:38
To: Mohammed Umair
Cc: trill; hu.fangwei@xzte.com.cn; Liyizhou; trill@ietf.org; Donald Eastlake; mohamed.boucadair@orange.com<= /a>; ayabaner@cisco.= om; Susan Hares
Subject: [trill] =E7=AD=94=E5=A4=8D: Re: draft-ietf-trill-643= 9bis WG LC [3/17 to 4/5/2016)

Support!

Regards.
Fangwei

Mohammed Umair &l= t;moham= med.umair2@ipinfusion.com>
=E5=8F=91=E4=BB=B6=E4=BA=BA: =C2=A0&qu= ot;trill" <trill-bounces@ietf.org>

2016-03-31 15:34

=E6=94=B6=E4=BB= =B6=E4=BA=BA	Susan Hares <shares@ndzh.com>, trill@ietf.org,
=E6=8A=84=E9=80= =81	Donald Eastlake <d3e3e3@gmail.com>, mohamed.boucadai= r@orange.com, hu.fangwei@xzte.com.cn, Liyizhou <liyizhou@huawei.com>, ayabaner@cisco.om
=E4=B8=BB=E9=A2= =98	Re: [trill] draft-ietf-trill-6439b= is WG LC [3/17 to 4/5/2016)

Support as coauthor.
=C2=A0
Regards,
Umair
=C2=A0
From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, March 18, 2016 12:02 AM
To: trill@ietf.org
Cc: 'Donald Eastlake'; mohamed.boucadair@orange.com; hu.fangwei@xzte.com.cn; 'Liyizhou'; ayabaner@cisco.om
Subject: [trill] draft-ietf-trill-6439bis WG LC [3/17 to 4/5/2016)
=C2=A0
This begins a 2 week WG LC for draft-ietf= -rfc6439bis-01.txt.=C2=A0 In your discussion, please indicate if you believ= e:
=C2=A0
1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This upd= ate to RFC6439 is necessary to update and clarify RFC6439,
2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If you f= eel this document is ready for WG adoption.
=C2=A0
Sue Hares and Jon Hudson

.______________________________________________= _ trill mailing list trill@ietf.orghttps://www.ietf.org/mailman/listinfo/tril= l

--089e0118260606a99d053038c75c-- From nobody Mon Apr 11 11:54:20 2016 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 141A912F2FE for ; Mon, 11 Apr 2016 11:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 0P_Ofvs3hQ_s for ; Mon, 11 Apr 2016 11:54:17 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 DA88F12F2FD for ; Mon, 11 Apr 2016 11:54:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: Date: Mon, 11 Apr 2016 14:54:15 -0400 Message-ID: <041101d19423$8c006f60$a4014e20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0412_01D19402.04F1DCA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGUIwyCPhrg+5dKSLKvLWSJ8Yvkdw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 to 4/25) 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, 11 Apr 2016 18:54:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0412_01D19402.04F1DCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week Working Group adoption for draft-hao-trill-address-flush-01.txt https://datatracker.ietf.org/doc/draft-hao-trill-address-flush/ This draft specifies a message by which an originating TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the egress 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. In your comments on the draft, please indicate: 1) Do you feel the address flush is useful for deployments, 2) Do you feel the draft is enough technical merit to be adopted as WG draft, Sue Hares and Jon Hudson ------=_NextPart_000_0412_01D19402.04F1DCA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week Working Group adoption for = draft-hao-trill-address-flush-01.txt

= https://datatracker.ietf.org/doc/draft-hao-trill-address-flush/<= /o:p>

This draft specifies a message by which an = originating TRILL

switch = can explicitly request other TRILL switches to flush = certain

MAC reachability = learned through the egress 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.

In your = comments on the draft, please indicate:

1) = Do you feel the address flush is useful for = deployments,

2) = Do you feel the draft is enough technical merit = to be adopted as WG draft,

Sue Hares = and Jon Hudson

------=_NextPart_000_0412_01D19402.04F1DCA0-- From nobody Mon Apr 11 11:57:05 2016 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 E56D412F2A7 for ; Mon, 11 Apr 2016 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 1849vFnNSYGV for ; Mon, 11 Apr 2016 11:57:04 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 C08BB12F275 for ; Mon, 11 Apr 2016 11:57:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: Date: Mon, 11 Apr 2016 14:57:02 -0400 Message-ID: <041e01d19423$ef8df840$cea9e8c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041F_01D19402.687F6580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGUI578tzq8NdXRQLeqbY2/3PLeDg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - WG adoption (4/11 to 4/25) 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, 11 Apr 2016 18:57:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_041F_01D19402.687F6580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week Working Group adoption call for: draft-zhang-trill-multi-level-unique-nickname. https://datatracker.ietf.org/doc/draft-zhang-trill-multilevel-unique-nicknam e/ TRILL routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated Nickname. This document specifies the unique nickname approach. In your comments please indicate: 1) Do you think the nickname approach is useful in deployments of TRILL, 2) Do you feel this draft provides a good solution for the unique nickname approach. Sue Hares and Jon Hudson ------=_NextPart_000_041F_01D19402.687F6580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week Working Group adoption call for: = draft-zhang-trill-multi-level-unique-nickname.

https://datatracker.ietf.org/doc/draft-zhang-trill-multile= vel-unique-nickname/

= TRILL routing can be extended to support multiple levels by = building

on the = multilevel feature of IS-IS routing. Depending on how

nicknames are managed, there are two = primary alternatives to realize

TRILL multilevel: the unique nickname = approach and the aggregated

Nickname. This document specifies = the unique nickname approach.

In your = comments please indicate:

1) = Do you think the nickname approach is useful in = deployments of TRILL,

2) = Do you feel this draft provides a good solution = for the unique nickname approach.

Sue Hares = and Jon Hudson

------=_NextPart_000_041F_01D19402.687F6580-- From nobody Mon Apr 11 19:15:01 2016 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 88BBA12DD5A; Mon, 11 Apr 2016 19:14:58 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160412021458.13045.5252.idtracker@ietfa.amsl.com> Date: Mon, 11 Apr 2016 19:14:58 -0700 Archived-At: Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-tree-selection-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: Tue, 12 Apr 2016 02:14:58 -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: Data Label based Tree Selection for Multi-destination Data Authors : Yizhou Li Donald Eastlake Weiguo Hao Hao Chen Somnath Chatterjee Filename : draft-ietf-trill-tree-selection-04.txt Pages : 20 Date : 2016-04-11 Abstract: TRILL uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress RBridge for flows regardless of the VLAN, Fine Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on VLAN and/or FGL and/or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast path hardware, the amount of pruning information is multiplied by the number of trees, but there is a limited hardware capacity for such pruning information. This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast group thus reducing the total amount of pruning information so that it can more easily be accommodated by fast path hardware. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-tree-selection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-tree-selection-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-tree-selection-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 Mon Apr 11 19:59:07 2016 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 6AAE212DF82 for ; Mon, 11 Apr 2016 19:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 bOU4kNhih3To for ; Mon, 11 Apr 2016 19:59:04 -0700 (PDT) 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 A70B112DF7A for ; Mon, 11 Apr 2016 19:59:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHE36076; Tue, 12 Apr 2016 02:59:01 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 03:59:00 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 10:58:53 +0800 From: Mingui Zhang To: Susan Hares , "trill@ietf.org" Thread-Topic: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 to 4/25) Thread-Index: AdGUIwyCPhrg+5dKSLKvLWSJ8YvkdwAQ8siQ Date: Tue, 12 Apr 2016 02:58:52 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787C7E65B@NKGEML515-MBX.china.huawei.com> References: <041101d19423$8c006f60$a4014e20$@ndzh.com> In-Reply-To: <041101d19423$8c006f60$a4014e20$@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_4552F0907735844E9204A62BBDD325E787C7E65BNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.570C6476.0038, 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: 5fb32f7ea9b96333990f5b250c1f6a33 Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: Re: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 to 4/25) 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, 12 Apr 2016 02:59:06 -0000 --_000_4552F0907735844E9204A62BBDD325E787C7E65BNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support for adoption. According to the discussion before, we found it useful to do address flush = when ESADI is not available. Thanks, Mingui From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, April 12, 2016 2:54 AM To: trill@ietf.org Cc: 'Donald Eastlake'; 'Jon Hudson' Subject: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 = to 4/25) This begins a 2 week Working Group adoption for draft-hao-trill-address-flu= sh-01.txt https://datatracker.ietf.org/doc/draft-hao-trill-address-flush/ This draft specifies a message by which an originating TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the egress 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. In your comments on the draft, please indicate: 1) Do you feel the address flush is useful for deployments, 2) Do you feel the draft is enough technical merit to be adopted as WG= draft, Sue Hares and Jon Hudson --_000_4552F0907735844E9204A62BBDD325E787C7E65BNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support for adoption.

According to the discussion before, we found it useful to do addr= ess flush when ESADI is not available.

Thanks,

Mingui

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, April 12, 2016 2:54 AM
To: trill@ietf.org
Cc: 'Donald Eastlake'; 'Jon Hudson'
Subject: [trill] draft-hao-trill-address-flush-01 - WG Adoption call= (4/11 to 4/25)

This begins a 2 week Working Gr= oup adoption for draft-hao-trill-address-flush-01.txt

https://datatracker.ietf.org/d= oc/draft-hao-trill-address-flush/

This draft specifies a m= essage by which an originating TRILL

switch can explici= tly request other TRILL switches to flush certain

MAC reachability l= earned through the egress of TRILL Data packets.

This is a suppleme= nt to the TRILL automatic address forgetting and

can assist in achi= eving more rapid convergence in case of topology or

configuration chan= ge.

In your comments on the draft, = please indicate:

1) &nbs= p; Do you feel the address= flush is useful for deployments,

2) &nbs= p; Do you feel the draft i= s enough technical merit to be adopted as WG draft,

Sue Hares and Jon Hudson <= /o:p>

--_000_4552F0907735844E9204A62BBDD325E787C7E65BNKGEML515MBXchi_-- From nobody Tue Apr 12 18:20:51 2016 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 5421A12D762 for ; Tue, 12 Apr 2016 18:20:50 -0700 (PDT) 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, HTML_MESSAGE=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 ULuwFZW4txNl for ; Tue, 12 Apr 2016 18:20:48 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 B8C5F12D714 for ; Tue, 12 Apr 2016 18:20:48 -0700 (PDT) Received: by mail-ob0-x236.google.com with SMTP id tz8so23398283obc.0 for ; Tue, 12 Apr 2016 18:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=HR4thVFeglfSSjzXh2IcqUqvTY3Wz0GKtxztVTJZT0o=; b=07A/a/XNh6nDUSIlUrXdy5k8D78ysfP4mYN+xJfv2fQgM0v+frVz6DIZE0neGoFgzi J1U9ifU2lyiOni2GHi32cWssvqRxsuA5sabbk2AT7k6ZJ/ljBea5B+EZOJCfZlhSBOcL hTauaLVD98tsGNa0Sv1kDB9MZ/fu9ygiMMDI1AaHiHU6Zt+T0c7+O0UqA0zcJRZSuKPL +sviIOMGt+OmOCE3AnB5IAFTg8obL/W18Wfd/JLD85j2o8HxyHI2/r8fji//sBbvyGKv WiCTStWASDr8sEguhI/Lbk3y77dXMQ5msRrBiKIwAYCClaKZPhEjC/n5AnSrwMBdC/JR M1ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HR4thVFeglfSSjzXh2IcqUqvTY3Wz0GKtxztVTJZT0o=; b=TOMsasSO6SGQrcZH5vdcqwgCF9K4yUj8xdHu95Mq/gHp257c+XJ9trWO3uPcmoPElo nc9BrGxCKYVDIVT7NSF74jf6Vw1kLLbC/G/UhrlFmdITwYCRo7OvoLpL7Wap6Q8NyZJJ zJATeRszcvmC4EtpHePk8sWz18BvLMIBIPH+gaom8jI0jTNHfZEiJVB8YefsFtTPVywB 6cEGi06Fat5kuA1VvzDJG8Wuh2F3uR0z7CJGff/km9s8YUOOMab+Tr+HlWRTVB98VA3Z rpVXqZ3N49JP8tLToq/DJi/htzpUj51R7MdHjlDkyVAhTSuxK7zL60H+cphrc5lMTYQg WizQ== X-Gm-Message-State: AOPr4FWc6N9II0ghtnmc/2r81mbiCd8uGiTHFpD/AmYmluMZJRMjzTlq2mfsQkxoddTRSzoBpMCC7f7bkohe6Q== X-Received: by 10.182.252.75 with SMTP id zq11mr2984150obc.53.1460510448173; Tue, 12 Apr 2016 18:20:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.250 with HTTP; Tue, 12 Apr 2016 18:20:33 -0700 (PDT) From: Donald Eastlake Date: Tue, 12 Apr 2016 21:20:33 -0400 Message-ID: To: "trill@ietf.org" Content-Type: multipart/alternative; boundary=001a1134be0a74493a0530539675 Archived-At: Subject: [trill] Progressing ECN TRILL 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: Wed, 13 Apr 2016 01:20:50 -0000 --001a1134be0a74493a0530539675 Content-Type: text/plain; charset=UTF-8 A presentation was given by Bob Briscoe at the TRILL WG meeting in Buenos Aires on TRILL ECN support. This started with draft-eastlake-trill-ecn-support-00; however, Bob had come up with an improved scheme shortly before the meeting which was also presented. See the slides here https://www.ietf.org/proceedings/95/slides/slides-95-trill-5.pdf The scheme in the -00 draft is described as alternative #2 in the slides and the improved scheme as alternative #3. Our plan is to update the draft to a -01 incorporating this improved scheme and then ask for a call for WG adoption. Comments and suggestions welcome. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a1134be0a74493a0530539675 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A presentation was given by Bob Briscoe at the TRILL WG me= eting in Buenos Aires on TRILL ECN support. This started with draft-eastlak= e-trill-ecn-support-00; however, Bob had come up with an improved scheme sh= ortly before the meeting which was also presented. See the slides here

= https://www.ietf.org/proceedings/95/slides/slides-95-trill-5.pdf

The scheme in the -00 draft is described as alternative #2 in the sli= des and the improved scheme as alternative #3.

Our= plan is to update the draft to a -01 incorporating this improved scheme an= d then ask for a call for WG adoption.

Comments an= d suggestions welcome.

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
=C2=A0Donald E. Eastlake 3= rd=C2=A0=C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street,=C2=A0Milf= ord, MA 01757 USA
=C2=A0d3e3e3@gmail.com

--001a1134be0a74493a0530539675-- From nobody Wed Apr 13 13:47:39 2016 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 3320412E516; Wed, 13 Apr 2016 13:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 CZSC-BumzuAw; Wed, 13 Apr 2016 13:47:35 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 9A58012E515; Wed, 13 Apr 2016 13:47:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 573C21C0346; Wed, 13 Apr 2016 13:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460580452; bh=yFhSTxCQFf+1llxpYORygXKDfbNMOg1v/KrknjtwFfk=; h=To:Cc:From:Subject:Date:From; b=ftHb1dilZNEnUk3bj2nHOKWtIdVh9PzeLwYzgiDZZgmLfioGqNosAWN+EtJArVirK n60POsPeX6crNdhOzW8r4umPawsdIHpDJ5hNVCbTbmh03Wl+QlQrn0ROdhgFYtOwVq 68TK8GCmv8/EbjyLTAK/zrDYP9KFcsiN+tTRQOkA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9A580540435; Wed, 13 Apr 2016 13:47:31 -0700 (PDT) To: "rtg-ads@ietf.org" From: "Joel M. Halpern" Message-ID: <570EB05D.20802@joelhalpern.com> Date: Wed, 13 Apr 2016 16:47:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-dir@ietf.org" , trill@ietf.org, draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 13 Apr 2016 20:47:37 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-trill-directory-assist-mechanisms-07.txt Reviewer: Joel Halpern Review Date: 13-April-2016 IETF LC End Date: N/A Intended Status: Proposed Standard Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. I do believe that the major issues are easily resolvable. I have tried to provide my best guess as to text how to resolve each of them. I would like to see the minor issues discussed and preferably addressed. Major Issues: In the state machine transitions in section 2.3.3 for push servers, it appears that if the event indicating that the server is being shut down occurs while the server is already Going Stand-By or Uncompleting, the transitions indicate that this "going down" event will be lost. A strict reading of this would seem to mean that the "go Down" event would need to recur after the timeout condition. This would seem to be best addressed by a new state "Going-Down" whose timeout behavior is to move to down state. In section 2.3.2, The descriptions for event 3 and 5 are identical. I believe from the state transitions that condition 3 is supposed to reflect the server NOT having complete data when the Activate condition is met. In section 3.2.1 there is provision for using a received frame as a Query. There are type indications as to what the type of the frame is. I believe that the intent is that the query always contains the full received Ethernet Frame, no matter what the type is. But it does not say that. So one could also conclude that for ARP, what I should send is the ARP message, and for ND, the ND message, etc. I believe the text needs to be clarified. If my guess is correct that the full Ethernet Frame is to be send in all cases, then explanatory text as to why the various type codes exist would seem helpful, since the received frame contains enough information to support decoding. Minor Issues: In section 2.3.3 describing the state transitions for push servers, there is an event (event 1) described as "the server was Down but is now Up." The state transition diagram describes this as being a valid event that does not change the servers state if the server is in any state other than "Down." In one sense, this is reasonable, saying that such an event is harmless. I would however expect some sort of logging or administrative notification, as something in the system is quite confused. Should section 2.4 include a note that indicates that reliance on information completeness does mean that there are windows when new entities join the space represented by particular TRILL data label during which packets for that destination may be dropped, due to clients not yet having received the updated information? I believe this window is small, and it is quite reasonable to also note that in such text. Text in section 3.2.2.1 on lifetimes and the information maintenance in section 3.3 imply that the clients and servers must maintain a connection. Presumably, this is required already by the RBRidge Channel protocol, and I understand that we should not repeat the entire protocol here. It would seem to make readers life MUCH simpler if the text noted that the RBRidge Channel protocol requires that there be a maintained connection between the client and the server, and that these mechanisms leverage the presence of that connection. In section 3.2.2.2 on Pull directory forwarding, I expect to see text about and to whom the Pull server will flood the received request. Instead, the text appears to say that it is teh response that will be flooded. More importantly, the descriptive text talks about sending the response, which would normally be a description of sending the response to the requestor, not sending it to someone else. In a related confusion, it seems very strange that a "flood" request will result in sending an underlying paket unicast to the destination. This may be just terminology, but it seems likely to confuse implementors. Maybe the flag should be called the Forward flag, with a note in the definition that it nromally causes the response to be sent to multiple parties, but in the case of a raw MAC frame, results in the packet being forwarded to the destination or flooded, as the server can manage? In the description in section 3.3 of Cache management, in the text on method one in which the servers keep minimal state, it would seem that a large health warning is needed, as this method will cause all clients to discard all positive data whenever any positive data at the server changes (even if no client is using the modified data.) This makes a flapping end station an attack on the cache of all clients! It strikes me that the working group could help get robust deployment by making method 3 (tracking what you told clients) a SHOULD. (I grant that it is not a MUST, as the other choices do work.) Editorial Issues / Nits : From nobody Wed Apr 13 15:53:53 2016 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 C00F312DD59; Wed, 13 Apr 2016 15:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] 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 x9wTWzs27uZ0; Wed, 13 Apr 2016 15:53:48 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 BA6DA12DA7A; Wed, 13 Apr 2016 15:53:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Joel M. Halpern'" , References: <570EB05D.20802@joelhalpern.com> In-Reply-To: <570EB05D.20802@joelhalpern.com> Date: Wed, 13 Apr 2016 18:53:42 -0400 Message-ID: <02c401d195d7$550d7e70$ff287b50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLt0ar96cOf013H3k5feyl+BDKWp51QCxpQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, trill@ietf.org, draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 13 Apr 2016 22:53:50 -0000 Joel:=20 Thank you for the review of this document. As co-chair, I will work = with the authors to try to address this issue.=20 Sue=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, April 13, 2016 4:47 PM To: rtg-ads@ietf.org Cc: rtg-dir@ietf.org; = draft-ietf-trill-directory-assist-mechanisms.all@ietf.org; = trill@ietf.org Subject: RtgDir review of = draft-ietf-trill-directory-assist-mechanisms-07.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see =E2=80=8B = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-trill-directory-assist-mechanisms-07.txt Reviewer: Joel Halpern Review Date: 13-April-2016 IETF LC End Date: N/A Intended Status: Proposed Standard Summary: I have significant concerns about this document and recommend = that the Routing ADs discuss these issues further with the authors. I do believe that the major issues are easily resolvable. I have = tried to provide my best guess as to text how to resolve each of them. I would like to see the minor issues discussed and preferably = addressed. Major Issues: In the state machine transitions in section 2.3.3 for push servers, = it appears that if the event indicating that the server is being shut = down occurs while the server is already Going Stand-By or Uncompleting, = the transitions indicate that this "going down" event will be lost. A = strict reading of this would seem to mean that the "go Down" event would = need to recur after the timeout condition. This would seem to be best = addressed by a new state "Going-Down" whose timeout behavior is to move = to down state. In section 2.3.2, The descriptions for event 3 and 5 are identical. I = believe from the state transitions that condition 3 is supposed to = reflect the server NOT having complete data when the Activate condition = is met. In section 3.2.1 there is provision for using a received frame as a = Query. There are type indications as to what the type of the frame is.=20 I believe that the intent is that the query always contains the full = received Ethernet Frame, no matter what the type is. But it does not = say that. So one could also conclude that for ARP, what I should send = is the ARP message, and for ND, the ND message, etc. I believe the text = needs to be clarified. If my guess is correct that the full Ethernet = Frame is to be send in all cases, then explanatory text as to why the = various type codes exist would seem helpful, since the received frame = contains enough information to support decoding. Minor Issues: In section 2.3.3 describing the state transitions for push servers, = there is an event (event 1) described as "the server was Down but is now = Up." The state transition diagram describes this as being a valid event = that does not change the servers state if the server is in any state = other than "Down." In one sense, this is reasonable, saying that such an = event is harmless. I would however expect some sort of logging or = administrative notification, as something in the system is quite = confused. Should section 2.4 include a note that indicates that reliance on = information completeness does mean that there are windows when new = entities join the space represented by particular TRILL data label = during which packets for that destination may be dropped, due to clients = not yet having received the updated information? I believe this window = is small, and it is quite reasonable to also note that in such text. Text in section 3.2.2.1 on lifetimes and the information = maintenance in section 3.3 imply that the clients and servers must = maintain a connection. Presumably, this is required already by the = RBRidge Channel protocol, and I understand that we should not repeat the = entire protocol here. It would seem to make readers life MUCH simpler = if the text noted that the RBRidge Channel protocol requires that there = be a maintained connection between the client and the server, and that = these mechanisms leverage the presence of that connection. In section 3.2.2.2 on Pull directory forwarding, I expect to see = text about and to whom the Pull server will flood the received request.=20 Instead, the text appears to say that it is teh response that will be = flooded. More importantly, the descriptive text talks about sending the = response, which would normally be a description of sending the response = to the requestor, not sending it to someone else. In a related confusion, it seems very strange that a "flood"=20 request will result in sending an underlying paket unicast to the = destination. This may be just terminology, but it seems likely to = confuse implementors. Maybe the flag should be called the Forward flag, = with a note in the definition that it nromally causes the response to be = sent to multiple parties, but in the case of a raw MAC frame, results in = the packet being forwarded to the destination or flooded, as the server = can manage? In the description in section 3.3 of Cache management, in the text = on method one in which the servers keep minimal state, it would seem = that a large health warning is needed, as this method will cause all = clients to discard all positive data whenever any positive data at the = server changes (even if no client is using the modified data.) This = makes a flapping end station an attack on the cache of all clients! It strikes me that the working group could help get robust = deployment by making method 3 (tracking what you told clients) a SHOULD. = (I grant that it is not a MUST, as the other choices do work.) Editorial Issues / Nits : From nobody Wed Apr 13 18:35:25 2016 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 0370E12DE7C; Wed, 13 Apr 2016 18:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 psgCFb6WODIr; Wed, 13 Apr 2016 18:35:19 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003: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 0F96412DA3C; Wed, 13 Apr 2016 18:35:19 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id s79so80732416oie.1; Wed, 13 Apr 2016 18:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7N+KkVzkY9nxDKdBLICYpai7fEzodohK1LSFphsiEA4=; b=M+pIh5nuDDfR5fLhSPnrFJSJSn/UkUeSKKmVdCgJl1AsRE8dtN5nfV/lRuaw3pWv1r SuIvKZ/5eGC37LSxpZVmvS5FTivCvpXzBSXXXYmpdMblcM91VfdR/FdQw1DeNZdbcu/6 cjpvsBIW9BrltfGupgArtGnR7/+3mWnzaeTswZcJYoQXy+UsyYaFpyyJkQEoOpnq4Nq3 jb+pEYCG7rf82JWxJWCV7Z5B6NgQa73oZfEQQ8PnolpAWAoN8FKZ7/eHBrdXpC0BdX59 9cPlcYsy7xkcECMbKtvNAuiBfClBRH415tcMOerC4h8pOHRoe7248On4hhleSbx7G3JN FdQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7N+KkVzkY9nxDKdBLICYpai7fEzodohK1LSFphsiEA4=; b=K/XYngApJ7iAbyIusybjbGgWnKoRJQH+fWhc6HN44JHQkF+BQqFA8dau/GE7mYRzlm Zjsmwtq3IdD1ZMOhlzW93MKO1nnrHf1TfjS9d+v5zNZBvvgq3oMIOTZZ3QhO8wpP7F10 PeCQhvI8rWKCwP4e6PnRnGucBQwSEWj4tN+jBcG1gOUYsrdBxS7NgoG0l99WBO7uZIYC 7ltqu8ueN8YVsoOTVsXijQutvFjwEKdZQMjtEA1ecIble5fzfswFXQEEqt7f/H6vxK8w 2M0ZgQkZbvpJDws7Zt8MVS0fZr+GFK4bGH8KtczQPiue6+h2Pz9LS9RzOj+geRhUAJJr /5DA== X-Gm-Message-State: AOPr4FWs3I3vKuamYLboN1xW1x0Ia0Te0UzkOl0m6YO/bzJYIS7/ORmsjxzJoqupmz6qZDarxnnnW2a1iLg4DQ== MIME-Version: 1.0 X-Received: by 10.202.172.201 with SMTP id v192mr5638435oie.29.1460597718419; Wed, 13 Apr 2016 18:35:18 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Wed, 13 Apr 2016 18:35:18 -0700 (PDT) In-Reply-To: <02c401d195d7$550d7e70$ff287b50$@ndzh.com> References: <570EB05D.20802@joelhalpern.com> <02c401d195d7$550d7e70$ff287b50$@ndzh.com> Date: Wed, 13 Apr 2016 21:35:18 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: multipart/alternative; boundary=001a113ced742a926b053067e8a9 Archived-At: Cc: "" , "rtg-dir@ietf.org" , "Joel M. Halpern" , trill@ietf.org, draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 14 Apr 2016 01:35:22 -0000 --001a113ced742a926b053067e8a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joel, Thank you very much for your review! Alia On Wed, Apr 13, 2016 at 6:53 PM, Susan Hares wrote: > Joel: > > Thank you for the review of this document. As co-chair, I will work with > the authors to try to address this issue. > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 13, 2016 4:47 PM > To: rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; > draft-ietf-trill-directory-assist-mechanisms.all@ietf.org; trill@ietf.org > Subject: RtgDir review of > draft-ietf-trill-directory-assist-mechanisms-07.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8B http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-trill-directory-assist-mechanisms-07.txt > Reviewer: Joel Halpern > Review Date: 13-April-2016 > IETF LC End Date: N/A > Intended Status: Proposed Standard > > Summary: I have significant concerns about this document and recommend > that the Routing ADs discuss these issues further with the authors. > I do believe that the major issues are easily resolvable. I have > tried to provide my best guess as to text how to resolve each of them. > I would like to see the minor issues discussed and preferably > addressed. > > Major Issues: > In the state machine transitions in section 2.3.3 for push servers, > it appears that if the event indicating that the server is being shut dow= n > occurs while the server is already Going Stand-By or Uncompleting, the > transitions indicate that this "going down" event will be lost. A strict > reading of this would seem to mean that the "go Down" event would need to > recur after the timeout condition. This would seem to be best addressed = by > a new state "Going-Down" whose timeout behavior is to move to down state. > > In section 2.3.2, The descriptions for event 3 and 5 are identical. I > believe from the state transitions that condition 3 is supposed to reflec= t > the server NOT having complete data when the Activate condition is met. > > In section 3.2.1 there is provision for using a received frame as a > Query. There are type indications as to what the type of the frame is. > I believe that the intent is that the query always contains the full > received Ethernet Frame, no matter what the type is. But it does not say > that. So one could also conclude that for ARP, what I should send is the > ARP message, and for ND, the ND message, etc. I believe the text needs t= o > be clarified. If my guess is correct that the full Ethernet Frame is to = be > send in all cases, then explanatory text as to why the various type codes > exist would seem helpful, since the received frame contains enough > information to support decoding. > > > > Minor Issues: > In section 2.3.3 describing the state transitions for push servers, > there is an event (event 1) described as "the server was Down but is now > Up." The state transition diagram describes this as being a valid event > that does not change the servers state if the server is in any state othe= r > than "Down." In one sense, this is reasonable, saying that such an event = is > harmless. I would however expect some sort of logging or administrative > notification, as something in the system is quite confused. > > Should section 2.4 include a note that indicates that reliance on > information completeness does mean that there are windows when new entiti= es > join the space represented by particular TRILL data label during which > packets for that destination may be dropped, due to clients not yet havin= g > received the updated information? I believe this window is small, and it > is quite reasonable to also note that in such text. > > Text in section 3.2.2.1 on lifetimes and the information maintenance > in section 3.3 imply that the clients and servers must maintain a > connection. Presumably, this is required already by the RBRidge Channel > protocol, and I understand that we should not repeat the entire protocol > here. It would seem to make readers life MUCH simpler if the text noted > that the RBRidge Channel protocol requires that there be a maintained > connection between the client and the server, and that these mechanisms > leverage the presence of that connection. > > In section 3.2.2.2 on Pull directory forwarding, I expect to see tex= t > about and to whom the Pull server will flood the received request. > Instead, the text appears to say that it is teh response that will be > flooded. More importantly, the descriptive text talks about sending the > response, which would normally be a description of sending the response t= o > the requestor, not sending it to someone else. > In a related confusion, it seems very strange that a "flood" > request will result in sending an underlying paket unicast to the > destination. This may be just terminology, but it seems likely to confus= e > implementors. Maybe the flag should be called the Forward flag, with a > note in the definition that it nromally causes the response to be sent to > multiple parties, but in the case of a raw MAC frame, results in the pack= et > being forwarded to the destination or flooded, as the server can manage? > > In the description in section 3.3 of Cache management, in the text o= n > method one in which the servers keep minimal state, it would seem that a > large health warning is needed, as this method will cause all clients to > discard all positive data whenever any positive data at the server change= s > (even if no client is using the modified data.) This makes a flapping en= d > station an attack on the cache of all clients! > It strikes me that the working group could help get robust deploymen= t > by making method 3 (tracking what you told clients) a SHOULD. > (I grant that it is not a MUST, as the other choices do work.) > > Editorial Issues / Nits : > > > > --001a113ced742a926b053067e8a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Joel,

Thank you very much for your revi= ew! =C2=A0=C2=A0

Alia

On Wed, Apr 13, 2016 at 6:53 PM, S= usan Hares <shares@ndzh.com> wrote:

Joel:

Thank you for the review of this document.=C2=A0 As co-chair, I will work w= ith the authors to try to address this issue.

Sue

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@jo= elhalpern.com]
Sent: Wednesday, April 13, 2016 4:47 PM
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org; draft-ietf-= trill-directory-assist-mechanisms.all@ietf.org; trill@ietf.org
Subject: RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.t= xt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see = =E2=80=8B http://trac.tools.ietf.org/area/rtg/tr= ac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

Document: draft-ietf-trill-directory-assist-mechanisms-07.txt
Reviewer: Joel Halpern
Review Date: 13-April-2016
IETF LC End Date: N/A
Intended Status: Proposed Standard

Summary: I have significant concerns about this document and recommend that= the Routing ADs discuss these issues further with the authors.
=C2=A0 =C2=A0 =C2=A0I do believe that the major issues are easily resolvabl= e.=C2=A0 I have tried to provide my best guess as to text how to resolve ea= ch of them.
=C2=A0 =C2=A0 =C2=A0I would like to see the minor issues discussed and pref= erably addressed.

Major Issues:
=C2=A0 =C2=A0 =C2=A0In the state machine transitions in section 2.3.3 for p= ush servers, it appears that if the event indicating that the server is bei= ng shut down occurs while the server is already Going Stand-By or Uncomplet= ing, the transitions indicate that this "going down" event will b= e lost.=C2=A0 A strict reading of this would seem to mean that the "go= Down" event would need to recur after the timeout condition.=C2=A0 Th= is would seem to be best addressed by a new state "Going-Down" wh= ose timeout behavior is to move to down state.

In section 2.3.2, The descriptions for event 3 and 5 are identical.=C2=A0 I= believe from the state transitions that condition 3 is supposed to reflect= the server NOT having complete data when the Activate condition is met.
In section 3.2.1 there is provision for using a received frame as a Query.= =C2=A0 There are type indications as to what the type of the frame is.
=C2=A0 I believe that the intent is that the query always contains the full= received Ethernet Frame, no matter what the type is.=C2=A0 But it does not= say that.=C2=A0 So one could also conclude that for ARP, what I should sen= d is the ARP message, and for ND, the ND message, etc.=C2=A0 I believe the = text needs to be clarified.=C2=A0 If my guess is correct that the full Ethe= rnet Frame is to be send in all cases, then explanatory text as to why the = various type codes exist would seem helpful, since the received frame conta= ins enough information to support decoding.

Minor Issues:
=C2=A0 =C2=A0 =C2=A0In section 2.3.3 describing the state transitions for p= ush servers, there is an event (event 1) described as "the server was = Down but is now Up."=C2=A0 The state transition diagram describes this= as being a valid event that does not change the servers state if the serve= r is in any state other than "Down." In one sense, this is reason= able, saying that such an event is harmless.=C2=A0 I would however expect s= ome sort of logging or administrative notification, as something in the sys= tem is quite confused.

=C2=A0 =C2=A0 =C2=A0Should section 2.4 include a note that indicates that r= eliance on information completeness does mean that there are windows when n= ew entities join the space represented by particular TRILL data label durin= g which packets for that destination may be dropped, due to clients not yet= having received the updated information?=C2=A0 I believe this window is sm= all, and it is quite reasonable to also note that in such text.

=C2=A0 =C2=A0 =C2=A0Text in section 3.2.2.1 on lifetimes and the informatio= n maintenance in section 3.3 imply that the clients and servers must mainta= in a connection.=C2=A0 Presumably, this is required already by the RBRidge = Channel protocol, and I understand that we should not repeat the entire pro= tocol here.=C2=A0 It would seem to make readers life MUCH simpler if the te= xt noted that the RBRidge Channel protocol requires that there be a maintai= ned connection between the client and the server, and that these mechanisms= leverage the presence of that connection.

=C2=A0 =C2=A0 =C2=A0In section 3.2.2.2 on Pull directory forwarding, I expe= ct to see text about and to whom the Pull server will flood the received re= quest.
=C2=A0 Instead, the text appears to say that it is teh response that will b= e flooded.=C2=A0 More importantly, the descriptive text talks about sending= the response, which would normally be a description of sending the respons= e to the requestor, not sending it to someone else.
=C2=A0 =C2=A0 =C2=A0In a related confusion, it seems very strange that a &q= uot;flood"
request will result in sending an underlying paket unicast to the destinati= on.=C2=A0 This may be just terminology, but it seems likely to confuse impl= ementors.=C2=A0 Maybe the flag should be called the Forward flag, with a no= te in the definition that it nromally causes the response to be sent to mul= tiple parties, but in the case of a raw MAC frame, results in the packet be= ing forwarded to the destination or flooded, as the server can manage?

=C2=A0 =C2=A0 =C2=A0In the description in section 3.3 of Cache management, = in the text on method one in which the servers keep minimal state, it would= seem that a large health warning is needed, as this method will cause all = clients to discard all positive data whenever any positive data at the serv= er changes (even if no client is using the modified data.)=C2=A0 This makes= a flapping end station an attack on the cache of all clients!
=C2=A0 =C2=A0 =C2=A0It strikes me that the working group could help get rob= ust deployment by making method 3 (tracking what you told clients) a SHOULD= .
=C2=A0 (I grant that it is not a MUST, as the other choices do work.)

Editorial Issues / Nits :

--001a113ced742a926b053067e8a9-- From nobody Thu Apr 14 13:45:27 2016 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 B1C0012D634 for ; Thu, 14 Apr 2016 13:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 xLcAKXFnGtxG for ; Thu, 14 Apr 2016 13:45:24 -0700 (PDT) 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 E22B212D764 for ; Thu, 14 Apr 2016 13:45:23 -0700 (PDT) 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 CME16767; Thu, 14 Apr 2016 20:45:21 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 21:45:20 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 13:45:10 -0700 From: Linda Dunbar To: Susan Hares , "trill@ietf.org" Thread-Topic: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 to 4/25) Thread-Index: AdGUIwyCPhrg+5dKSLKvLWSJ8YvkdwCa25kQ Date: Thu, 14 Apr 2016 20:45:10 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E6EC02@dfweml501-mbb> References: <041101d19423$8c006f60$a4014e20$@ndzh.com> In-Reply-To: <041101d19423$8c006f60$a4014e20$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.250] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC02dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57100161.00C6, 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: 6516b09cf21dc4cafcec148cc811971c Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: Re: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 to 4/25) 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, 14 Apr 2016 20:45:26 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC02dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read the document and support the WG adoption. Linda From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 11, 2016 1:54 PM To: trill@ietf.org Cc: 'Donald Eastlake'; 'Jon Hudson' Subject: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 = to 4/25) This begins a 2 week Working Group adoption for draft-hao-trill-address-flu= sh-01.txt https://datatracker.ietf.org/doc/draft-hao-trill-address-flush/ This draft specifies a message by which an originating TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the egress 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. In your comments on the draft, please indicate: 1) Do you feel the address flush is useful for deployments, 2) Do you feel the draft is enough technical merit to be adopted as WG= draft, Sue Hares and Jon Hudson --_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC02dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read the docume= nt and support the WG adoption.

Linda

From: trill [m= ailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, April 11, 2016 1:54 PM
To: trill@ietf.org
Cc: 'Donald Eastlake'; 'Jon Hudson'
Subject: [trill] draft-hao-trill-address-flush-01 - WG Adoption call= (4/11 to 4/25)

This begins a 2 week Working Group adoption for draf= t-hao-trill-address-flush-01.txt

https://datatracker.ietf.org/doc/draft-hao-trill-ad= dress-flush/

This draft specifies a message by which an or= iginating TRILL

switch can explicitly request other TRI= LL switches to flush certain

MAC reachability learned through the eg= ress of TRILL Data packets.

This is a supplement to the TRILL autom= atic address forgetting and

can assist in achieving more rapid conv= ergence in case of topology or

configuration change.

In your comments on the draft, please indicate:

1) Do you feel the address flush is useful for deploym= ents,

2) Do you feel the draft is enough technical merit to = be adopted as WG draft,

Sue Hares and Jon Hudson

--_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC02dfweml501mbb_-- From nobody Thu Apr 14 13:48:12 2016 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 A8AD712E36C for ; Thu, 14 Apr 2016 13:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 HEaTco9nJJpe for ; Thu, 14 Apr 2016 13:48:09 -0700 (PDT) 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 115FC12E2D0 for ; Thu, 14 Apr 2016 13:48:08 -0700 (PDT) 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 CME16889; Thu, 14 Apr 2016 20:48:07 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 21:48:06 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 13:47:54 -0700 From: Linda Dunbar To: Susan Hares , "trill@ietf.org" Thread-Topic: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - WG adoption (4/11 to 4/25) Thread-Index: AdGUI578tzq8NdXRQLeqbY2/3PLeDgCavdtQ Date: Thu, 14 Apr 2016 20:47:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E6EC15@dfweml501-mbb> References: <041e01d19423$ef8df840$cea9e8c0$@ndzh.com> In-Reply-To: <041e01d19423$ef8df840$cea9e8c0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.250] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC15dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57100207.006A, 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: b583006938e74de64d549ac60cb507f5 Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: Re: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - WG adoption (4/11 to 4/25) 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, 14 Apr 2016 20:48:10 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC15dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read the document and support the WG adoption. Linda From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 11, 2016 1:57 PM To: trill@ietf.org Cc: 'Donald Eastlake'; 'Jon Hudson' Subject: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - WG adopt= ion (4/11 to 4/25) This begins a 2 week Working Group adoption call for: draft-zhang-trill-mul= ti-level-unique-nickname. https://datatracker.ietf.org/doc/draft-zhang-trill-multilevel-unique-nickna= me/ TRILL routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated Nickname. This document specifies the unique nickname approach. In your comments please indicate: 1) Do you think the nickname approach is useful in deployments of TRIL= L, 2) Do you feel this draft provides a good solution for the unique nick= name approach. Sue Hares and Jon Hudson --_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC15dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read the docume= nt and support the WG adoption.

Linda

From: trill [m= ailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, April 11, 2016 1:57 PM
To: trill@ietf.org
Cc: 'Donald Eastlake'; 'Jon Hudson'
Subject: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - W= G adoption (4/11 to 4/25)

This begins a 2 week Working Group adoption call for= : draft-zhang-trill-multi-level-unique-nickname.

https://datatracker.ietf.org/doc/dra= ft-zhang-trill-multilevel-unique-nickname/

TRILL routing can be extended to suppor= t multiple levels by building

on the multilevel feature of IS-IS rout= ing. Depending on how

nicknames are managed, there are two pr= imary alternatives to realize

TRILL multilevel: the unique nickname a= pproach and the aggregated

Nickname. This document specifies= the unique nickname approach.

In your comments please indicate:

1) Do you think the nickname approach is useful in dep= loyments of TRILL,

2) Do you feel this draft provides a good solution for= the unique nickname approach.

Sue Hares and Jon Hudson

--_000_4A95BA014132FF49AE685FAB4B9F17F657E6EC15dfweml501mbb_-- From nobody Fri Apr 15 05:28:51 2016 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 A275012D1DC for ; Fri, 15 Apr 2016 05:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-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 puX4WEOOYkhd for ; Fri, 15 Apr 2016 05:28:44 -0700 (PDT) Received: from smtp.tom.com (smtpt1.163vip.net [211.100.40.41]) by ietfa.amsl.com (Postfix) with SMTP id E634212E106 for ; Fri, 15 Apr 2016 05:28:35 -0700 (PDT) Received: from smtp.tom.com (unknown [172.24.202.204]) by bjsd-tm-app7.localdomain (SMTP) with ESMTP id BAA469110E3 for ; Fri, 15 Apr 2016 20:28:27 +0800 (CST) Authentication-Results: bjsd-antispam1 smtp.user=honjun.zhai@tom.com; auth=pass (LOGIN) Received: from [180.99.64.110] ([180.99.64.110:13787] helo=[10.36.55.24]) by bjsd-antispam1 (envelope-from ) (ecelerity 3.5.4.38585 r(Platform:3.5.4.0)) with ESMTPA id 14/AA-08796-96ED0175; Fri, 15 Apr 2016 20:28:25 +0800 Date: Fri, 15 Apr 2016 20:28:24 +0800 Message-ID: <14.AA.08796.96ED0175@bjsd-antispam1> From: "honjun.zhai" To: Linda Dunbar , Susan Hares , "trill@ietf.org" MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: Re: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - WG adoption (4/11 to 4/25) 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, 15 Apr 2016 12:28:49 -0000 QXMgYSBjby1hdXRob3IsIEkgc3VwcG9ydCB0aGUgV0cgYWRvcHRpb24gZm9yIHRoaXMgZHJhZnQu PGJyPjxicj5UaGFua3MsPGJyPkhvbmdqdW4gWmhhaTxicj48YnI+5p2l6Ieq5oiR55qE5Y2O5Li6 5omL5py6PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5z Om89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53 My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PC9oZWFkPjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj48ZGl2IGNsYXNzPSJxdW90ZSI+PGJyPjxicj4tLS0tLS0t LSDljp/lp4vpgq7ku7YgLS0tLS0tLS08YnI+5Li76aKY77yaUmU6IFt0cmlsbF0gZHJhZnQtemhh bmctdHJpbGwtbXVsdGlsZXZlbC11bmlxdWUtbmlja25hbWUtMDAgLSBXRyBhZG9wdGlvbiAoNC8x MSB0byA0LzI1KTxicj7lj5Hku7bkurrvvJpMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3 ZWkuY29tPjxicj7mlLbku7bkurrvvJpTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPix0cmls bEBpZXRmLm9yZzxicj7mioTpgIHvvJonRG9uYWxkIEVhc3RsYWtlJyA8ZDNlM2UzQGdtYWlsLmNv bT4sJ0pvbiBIdWRzb24nIDxqb24uaHVkc29uQGdtYWlsLmNvbT48YnI+PGJyPjxiciB0eXBlPSJh dHRyaWJ1dGlvbiI+PGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+Cgo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11 cy1hc2NpaSI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTIgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEtLQovKiBGb250IERlZmluaXRpb25zICov CkBmb250LWZhY2UKCXtmb250LWZhbWlseTpTaW1TdW47CglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOwoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJp OwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9udC1mYW1p bHk6VGFob21hOwoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQpAZm9udC1mYWNlCgl7 Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsKCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLwpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsCgl7bWFyZ2luOjBpbjsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZTox MS4wcHQ7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOmJsdWU7Cgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6cHVycGxlOwoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgKCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7CgltYXJnaW4tdG9w OjBpbjsKCW1hcmdpbi1yaWdodDowaW47CgltYXJnaW4tYm90dG9tOjBpbjsKCW1hcmdpbi1sZWZ0 Oi41aW47CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0OwoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9CnNwYW4uRW1haWxTdHlsZTE4Cgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJ Y29sb3I6d2luZG93dGV4dDt9CnNwYW4uRW1haWxTdHlsZTE5Cgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJY29sb3I6 IzFGNDk3RDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7Cglm b250LXNpemU6MTAuMHB0O30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo4LjVpbiAxMS4waW47 CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQovKiBMaXN0IERlZmluaXRpb25zICovCkBsaXN0IGwwCgl7bXNvLWxp c3QtaWQ6MTQ0MzIwNzcwOwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTIzNjkyODQ2OCA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwwOmxldmVs MQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3Qg bDA6bGV2ZWwyCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQt aW5kZW50Oi0uMjVpbjt9CkBsaXN0IGwwOmxldmVsMwoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDA6bGV2ZWw0Cgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMDpsZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDA6bGV2 ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVu dDotOS4wcHQ7fQpAbGlzdCBsMDpsZXZlbDcKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBsaXN0 IGwwOmxldmVsOAoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0 LWluZGVudDotLjI1aW47fQpAbGlzdCBsMDpsZXZlbDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9Cm9sCgl7bWFyZ2luLWJvdHRv bTowaW47fQp1bAoJe21hcmdpbi1ib3R0b206MGluO30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+Cjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4KCgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBoYXZl IHJlYWQgdGhlIGRvY3VtZW50IGFuZCBzdXBwb3J0IHRoZSBXRyBhZG9wdGlvbi4KPG86cD48L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGluZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyaWxsIFttYWlsdG86dHJpbGwtYm91 bmNlc0BpZXRmLm9yZ10KPGI+T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBIYXJlczxicj4KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXByaWwgMTEsIDIwMTYgMTo1NyBQTTxicj4KPGI+VG86PC9iPiB0cmls bEBpZXRmLm9yZzxicj4KPGI+Q2M6PC9iPiAnRG9uYWxkIEVhc3RsYWtlJzsgJ0pvbiBIdWRzb24n PGJyPgo8Yj5TdWJqZWN0OjwvYj4gW3RyaWxsXSBkcmFmdC16aGFuZy10cmlsbC1tdWx0aWxldmVs LXVuaXF1ZS1uaWNrbmFtZS0wMCAtIFdHIGFkb3B0aW9uICg0LzExIHRvIDQvMjUpPG86cD48L286 cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJlZ2lucyBhIDIgd2VlayBX b3JraW5nIEdyb3VwIGFkb3B0aW9uIGNhbGwgZm9yOiBkcmFmdC16aGFuZy10cmlsbC1tdWx0aS1s ZXZlbC11bmlxdWUtbmlja25hbWUuCjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctdHJpbGwtbXVsdGlsZXZl bC11bmlxdWUtbmlja25hbWUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC16aGFuZy10cmlsbC1tdWx0aWxldmVsLXVuaXF1ZS1uaWNrbmFtZS88L2E+PG86cD48L286cD48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgVFJJTEwgcm91dGluZyBjYW4gYmUgZXh0ZW5kZWQgdG8g c3VwcG9ydCBtdWx0aXBsZSBsZXZlbHMgYnkgYnVpbGRpbmc8bzpwPjwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IG9uIHRoZSBtdWx0aWxldmVsIGZlYXR1cmUgb2Yg SVMtSVMgcm91dGluZy4gRGVwZW5kaW5nIG9uIGhvdzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgbmlja25hbWVzIGFyZSBtYW5hZ2VkLCB0aGVyZSBhcmUg dHdvIHByaW1hcnkgYWx0ZXJuYXRpdmVzIHRvIHJlYWxpemU8bzpwPjwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFRSSUxMIG11bHRpbGV2ZWw6IHRoZSB1bmlxdWUg bmlja25hbWUgYXBwcm9hY2ggYW5kIHRoZSBhZ2dyZWdhdGVkPG86cD48L286cD48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBOaWNrbmFtZS4mbmJzcDsgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgdGhlIHVuaXF1ZSBuaWNrbmFtZSBhcHByb2FjaC48bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIHlvdXIgY29tbWVudHMgcGxlYXNlIGluZGljYXRlOiA8bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48 L3NwYW4+PCEtLVtlbmRpZl0tLT5EbyB5b3UgdGhpbmsgdGhlIG5pY2tuYW1lIGFwcHJvYWNoIGlz IHVzZWZ1bCBpbiBkZXBsb3ltZW50cyBvZiBUUklMTCwKPG86cD48L286cD48L3A+CjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8yIj48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwh LS1bZW5kaWZdLS0+RG8geW91IGZlZWwgdGhpcyBkcmFmdCBwcm92aWRlcyBhIGdvb2Qgc29sdXRp b24gZm9yIHRoZSB1bmlxdWUgbmlja25hbWUgYXBwcm9hY2guCjxvOnA+PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1ZSBIYXJlcyBh bmQgSm9uIEh1ZHNvbiA8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CgoKPC9ibG9ja3F1b3RlPjwvam9u Lmh1ZHNvbkBnbWFpbC5jb20+PC9kM2UzZTNAZ21haWwuY29tPjwvc2hhcmVzQG5kemguY29tPjwv bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+PC9kaXY+PC9ib2R5PjwvaHRtbD4= From nobody Fri Apr 15 08:23:39 2016 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 2BB1312DDDB; Fri, 15 Apr 2016 08:23:37 -0700 (PDT) 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, HTML_MESSAGE=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 UBMg7gib1Ven; Fri, 15 Apr 2016 08:23:32 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 5A5BA12DF96; Fri, 15 Apr 2016 08:23:32 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id s79so127184827oie.1; Fri, 15 Apr 2016 08:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XW+CZWyx/fFE6Xm+yOqrOGpr5mv12//meK/r3Z6uuYM=; b=cBeO8IJoDAb/HGhjiiPqrgc9FxfRA4xfNyhbxF3vocIpHSc5q5jMfabTeWRQsuB/XB HnXDuScFbIwurMOagdF8FvoNFqMnx9gYuydRP24oYKwxgFB+/t7PfUJ85oCF4NEq9Yjx 9rR8ftnZ0aWwGHm1QBvPIa7mCQui2t4fpPhCcPsMFVMycUgLtUAmW1TZkOL/SbjM01J1 lJyQexm0uhEFaRUoZ0hfHaFF789QZMl3blxwquzXCuYMz5K9l/6vtPb7NhOTra65Q0nJ VSAqaafAlcOuiERn12ihTU1i39bqauhFZhuAkEs3rPJy8y3A2nNcHrSGplIPa/tlJfP4 GRag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XW+CZWyx/fFE6Xm+yOqrOGpr5mv12//meK/r3Z6uuYM=; b=S5wY9tZRu5ZAnbVHyq0bDbMNDX5Jl5VsAZg5h8/6qgYR8GHwnxvurDK8MjBZbKTptN kOQoWUqASj3urlAvw4GXpQQuqgm9Kwev3O4TbIa3PDpHOf2cD/7RG0FAmWagBvP6dzkY w6ioNcx4H45YB/kPc92JoV3nabejU0VXIeOYkPx3GTElFs4/18CacvLdvqU2nfRm5j8c M5xIYY/+LwVNpVBQze39AzzdF1YaFsakthZ1q9eucvH7c0rXMSI33WBOaV7zI/fMZWuR cGv0oNuOdhJhSup4sggQR5VXvwBV3FdiD2fcd/iIFaRMF1RuFlJpRvz/2FxzAEjKM0t5 e2Zg== X-Gm-Message-State: AOPr4FXVQpffFfcUsiJ3YeUO1t0BDsBZliQRsXvqHy7kK41ukKDWr1BDpbQezvOLF3z6zR6gwlBf5eMBq9zQMg== X-Received: by 10.157.2.69 with SMTP id 63mr11237504otb.170.1460733811655; Fri, 15 Apr 2016 08:23:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.250 with HTTP; Fri, 15 Apr 2016 08:23:17 -0700 (PDT) In-Reply-To: <570EB05D.20802@joelhalpern.com> References: <570EB05D.20802@joelhalpern.com> From: Donald Eastlake Date: Fri, 15 Apr 2016 11:23:17 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=94eb2c114d24f48ca00530879739 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" , draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 15 Apr 2016 15:23:38 -0000 --94eb2c114d24f48ca00530879739 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joel Thanks for your thorough review and comments. See below On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see =E2=80=8B > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use > of the Routing ADs, it would be helpful if you could consider them > along with any other IETF Last Call comments that you receive, and > strive to resolve them through discussion or by updating the draft. > > Document: draft-ietf-trill-directory-assist-mechanisms-07.txt > Reviewer: Joel Halpern > Review Date: 13-April-2016 > IETF LC End Date: N/A > Intended Status: Proposed Standard > > Summary: I have significant concerns about this document and > recommend that the Routing ADs discuss these issues further with the > authors. > > I do believe that the major issues are easily resolvable. I > have tried to provide my best guess as to text how to resolve > each of them. Thanks. > I would like to see the minor issues discussed and preferably > addressed. > > Major Issues: > In the state machine transitions in section 2.3.3 > for push servers, it appears that if the event indicating that the > server is being shut down occurs while the server is already Going > Stand-By or Uncompleting, the transitions indicate that this "going > down" event will be lost. A strict reading of this would seem to > mean that the "go Down" event would need to recur after the timeout > condition. This would seem to be best addressed by a new state > "Going-Down" whose timeout behavior is to move to down state. I understand your point but "going down" and the like are called "events or conditions" in this draft, not just events. The problem with adding a single "Going-Down" state is that transition to that state would lose the information as to whether or not the Push Directory had been advertising that it was pushing complete information or not. The reason to remember this is that you would want to behave a differently if the "going down" condition was revoked before it completed. This information could be preserved in a Boolean pseudo variable but the current style of state machine in this draft avoids such pseudo variables and encodes all of the relevant push directory's state into the state machine state. Thus, I can see three possible responses to your comment: 1) Change wording to emphasize that these "events or conditions" can be conditions that cause a state transition some substantial time after they become true. 2) Add two new states: (1) going down - was complete; (2) going down - was incomplete. 3) Change the style of state machine to admit pseudo variables which can be set and testing as part of the state machinery. Option 1 is just some minor wording changes but adopting either options 2 or 3 involves more extensive changes so I would prefer to avoid them. > In section 2.3.2, the descriptions for event 3 and 5 are identical. > I believe from the state transitions that condition 3 is supposed to > reflect the server NOT having complete data when the Activate > condition is met. You are correct. Thanks for spotting this somewhat glaring error in the event descriptions. > In section 3.2.1 there is provision for using a received frame as a > Query. There are type indications as to what the type of the frame > is. I believe that the intent is that the query always contains the > full received Ethernet Frame, no matter what the type is. But it > does not say that. So one could also conclude that for ARP, what I > should send is the ARP message, and for ND, the ND message, etc. I > believe the text needs to be clarified. If my guess is correct that > the full Ethernet Frame is to be send in all cases, then explanatory > text as to why the various type codes exist would seem helpful, > since the received frame contains enough information to support > decoding. Good point that this needs to say that the full Ethernet Frame (less the FCS) is to be included. QTYPEs 2, 3, and 4 for ARP, ND, and RARP could be combined. QTYPE 5 for an unknown unicast destination MAC address is really a different service. > Minor Issues: > In section 2.3.3 describing the state transitions for push > servers, there is an event (event 1) described as "the server was > Down but is now Up." The state transition diagram describes this as > being a valid event that does not change the servers state if the > server is in any state other than "Down." In one sense, this is > reasonable, saying that such an event is harmless. I would however > expect some sort of logging or administrative notification, as > something in the system is quite confused. Again, I see your point but it seems to me to be a matter of state machine style. Note that the "event" is described as a condition, so from that point of view, it is true anytime the state is other than Down. On the other hand, if you view it as strictly an event, you are left with the question of what to put at the intersection of a state and event in the table when it is impossible for that event to occur in that state. Some people note this with an "N/A" (not applicable) entry. In fact, previous TRILL state diagrams such as in RFC 7177 use "N/A" so it would probably be simplest to change to that for consistency. > Should section 2.4 include a note that indicates that reliance > on information completeness does mean that there are windows when > new entities join the space represented by particular TRILL data > label during which packets for that destination may be dropped, due > to clients not yet having received the updated information? I > believe this window is small, and it is quite reasonable to also > note that in such text. Yes, something like that would be a good addition to Section 2.4. It depends a bit on how the Push Directory is being managed. It may be pushing data provided by orchestration. In any case, there are always finite delays and for a particular ingress TRILL switch and an end station being connected to some other TRILL switch, the ingress could learn reachability for the end station either a bit before or after it is actually reachable so traffic intended for the end station could, for example, be dropped during a brief window of time when it should be forwarded. > Text in section 3.2.2.1 on lifetimes and the information > maintenance in section 3.3 imply that the clients and servers must > maintain a connection. Presumably, this is required already by the > RBridge Channel protocol, and I understand that we should not repeat > the entire protocol here. It would seem to make readers life MUCH > simpler if the text noted that the RBridge Channel protocol requires > that there be a maintained connection between the client and the > server, and that these mechanisms leverage the presence of that > connection. The basic RBridge Channel protocol [RFC7178] is a datagram protocol rather than a connection protocol. So there is no guaranteed continuity of connection between RBridges that have previously exchanged RBridge Channel messages. But connection would only be lost if the network partitions since RBridge Channel messages look like data packets to any transit RBridges and will get forwarded as long as there is any route. Network partition is immediately visible in the link state database to the RBridges at both ends of an RBridge Channel exchange. Section 3.7 provides that if a Pull Directory is no longer reachable (i.e., RBridge Channel protocol packets would no longer get through), then all pull responses from that Pull Directory MUST be discarded since cache consistency update messages can't get through. Perhaps a reference to Section 3.7 should be added to Section 3.3. > In section 3.2.2.2 on Pull directory forwarding, I expect to see > text about and to whom the Pull server will flood the received > request. Instead, the text appears to say that it is the response > that will be flooded. More importantly, the descriptive text talks > about sending the response, which would normally be a description of > sending the response to the requestor, not sending it to someone > else. If an ingress RBridge receives one of these broadcast/multicast requests (ARP, etc.) and wants it flooded, they just do the normal encapsulation as a TRILL data packet and it will be flooded (within the VLAN or FGL). It is only if the ingress RBridge wants the directory to answer the request that it would package it into an RBridge Channel message and unicast it to a directory. As to whom a response synthesized by the directory should be sent, it seems like the safest thing is to send it as the response would normally be sent by an end station responder. So, if an ARP response would be broadcast (within a VLAN or the like), then I don't see what is wrong about the directory flooding it. > In a related confusion, it seems very strange that a "flood" > request will result in sending an underlying packet unicast to the > destination. This may be just terminology, but it seems likely to > confuse implementers. Maybe the flag should be called the Forward > flag, with a note in the definition that it normally causes the > response to be sent to multiple parties, but in the case of a raw > MAC frame, results in the packet being forwarded to the destination > or flooded, as the server can manage? I don't have any particular problem with changing the FL flood flag to an FR forward flag or whatever, but I'm not sure what difference it would make to behavior. If you want the failure of the directory to be able to answer the query to be that the query (ARP request or whatever) to be sent pretty much as if it had never been packaged into an RBridge Channel message and sent to the directory, then you set this flag. When the flag is set and the directory can't answer the query, it sends it as a TRILL Data packet. If the original frame was broadcast or multicast, as is usually the case, then the directory server "floods" it (with the frames VLAN or FGL). The same is true if the request was of the "unknown destination unicast MAC" type -- if the directory does not know the edge RBridge from which that MAC is reachable and the FL flag is set, it floods it even though in this case the Inner.MacDA is a unicast address. In the unknown destination MAC case where the directory does know the reachability of that MAC, then the frame is decapsulated from the RBridge Channel and then encapsulated as a TRILL Data packet and sent to the edge RBridge from which that MAC is reachable. In this case, the FL flag has no effect since it only comes into play if the directory does not have the required information. I=E2=80=99m fine with adding some clarifying text on all this. > In the description in section 3.3 of Cache management, in the > text on method one in which the servers keep minimal state, it would > seem that a large health warning is needed, as this method will > cause all clients to discard all positive data whenever any positive > data at the server changes (even if no client is using the modified > data.) This makes a flapping end station an attack on the cache of > all clients! That would be true if the directory data comes from data plane learning but not so much if it is from an orchestration system in a Data Center. Adding some additional efficiency warning(s) is reasonable. > It strikes me that the working group could help get robust > deployment by making method 3 (tracking what you told clients) a > SHOULD. (I grant that it is not a MUST, as the other choices do > work.) That sounds reasonable. We can check with the WG. 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --94eb2c114d24f48ca00530879739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Joel

=C2=A0

Thanks for your thorough review and comments. See be= low

=C2=A0

On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern <jmh@joelhalpern.com>

wrote:

> Hello,

>=C2=A0

> I have been selected as the Routing Directorate reviewer for this

> draft. The Routing Directorate seeks to review = all routing or

> routing-related drafts as they pass through IET= F last call and IESG

> review, and sometimes on special request. The p= urpose of the review

> is to provide assistance to the Routing ADs. Fo= r more information

> about the Routing Directorate, please see =E2= =80=8B

> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<= /p>

> Although these comments are primarily for the u= se

> of the Routing ADs, it would be helpful if you = could consider them

> along with any other IETF Last Call comments th= at you receive, and

> strive to resolve them through discussion or by updating the draft.

> Document: draft-ietf-trill-directory-assist-mechanisms-07.txt

> Reviewer: Joel Halpern

> Review Date: 13-April-2016

> IETF LC End Date: N/A

> Intended Status: Proposed Standard

>=C2=A0

> Summary: I have significant concerns about this document and

> recommend that the Routing ADs discuss these is= sues further with the

> authors.

>=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 I do believe that the major issues are easily resolvable.=C2=A0 I

>=C2=A0=C2=A0=C2=A0=C2=A0 have tried to provide my best guess as to text how to resolve

>=C2=A0=C2=A0=C2=A0=C2=A0 each of them.

=C2=A0

Thanks.

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 I would like to see the minor issues discussed and preferably

>=C2=A0=C2=A0=C2=A0=C2=A0 addressed.=C2=A0

> Major Issues:

>=C2=A0=C2=A0=C2=A0=C2=A0 In the state machine transitions in section 2.3.3

> for push servers, it appears that if the event indicating that the

> server is being shut down occurs while the serv= er is already Going

> Stand-By or Uncompleting, the transitions indic= ate that this "going

> down" event will be lost.=C2=A0 A strict r= eading of this would seem to

> mean that the "go Down" event would n= eed to recur after the timeout

> condition.=C2=A0 This would seem to be best addressed by a new state

> "Going-Down" whose timeout behavior i= s to move to down state.

=C2=A0

I understand your point but "going down" a= nd the like are called

"events or conditions" in this draft, not = just events.

=C2=A0

The problem with adding a single "Going-Down&qu= ot; state is that transition

to that state would lose the information as to wheth= er or not the Push

Directory had been advertising that it was pushing c= omplete

information or not. The reason to remember this is t= hat you would want

to behave a differently if the "going down"= ; condition was revoked

before it completed.=C2=A0 This information could be preserved in a Boolean

pseudo variable but the current style of state machi= ne in this draft

avoids such pseudo variables and encodes all of the = relevant push

directory's state into the state machine state. = Thus, I can see three

possible responses to your comment:

=C2=A0

1) Change wording to emphasize that these "even= ts or conditions" can

be conditions that cause a state transition some sub= stantial time

after they become true.

=C2=A0

2) Add two new states: (1) going down - was complete= ; (2) going down -

was incomplete.

=C2=A0

3) Change the style of state machine to admit pseudo variables which

can be set and testing as part of the state machiner= y.

=C2=A0

Option 1 is just some minor wording changes but adop= ting either

options 2 or 3 involves more extensive changes so I = would prefer to

avoid them.

=C2=A0

> In section 2.3.2, the descriptions for event 3 = and 5 are identical.

> I believe from the state transitions that condi= tion 3 is supposed to

> reflect the server NOT having complete data whe= n the Activate

> condition is met.

=C2=A0

You are correct. Thanks for spotting this somewhat g= laring error in

the event descriptions.

=C2=A0

> In section 3.2.1 there is provision for using a received frame as a

> Query.=C2=A0 There are type indications as to what the type of the frame

> is.=C2=A0 I believe that the intent is that the query always contains the

> full received Ethernet Frame, no matter what th= e type is.=C2=A0 But it

> does not say that.=C2=A0 So one could also conclude that for ARP, what I

> should send is the ARP message, and for ND, the= ND message, etc.=C2=A0 I

> believe the text needs to be clarified.=C2=A0 I= f my guess is correct that

> the full Ethernet Frame is to be send in all ca= ses, then explanatory

> text as to why the various type codes exist wou= ld seem helpful,

> since the received frame contains enough inform= ation to support

> decoding.

=C2=A0

Good point that this needs to say that the full Ethe= rnet Frame (less

the FCS) is to be included. QTYPEs 2, 3, and 4 for A= RP, ND, and RARP

could be combined. QTYPE 5 for an unknown unicast de= stination MAC

address is really a different service.

=C2=A0

> Minor Issues:

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 In section 2.3.3 describing the state transitions for push

> servers, there is an event (event 1) described = as "the server was

> Down but is now Up."=C2=A0 The state trans= ition diagram describes this as

> being a valid event that does not change the se= rvers state if the

> server is in any state other than "Down.&q= uot; In one sense, this is

> reasonable, saying that such an event is harmle= ss.=C2=A0 I would however

> expect some sort of logging or administrative notification, as

> something in the system is quite confused.

=C2=A0

Again, I see your point but it seems to me to be a m= atter of state

machine style. Note that the "event" is de= scribed as a condition, so

from that point of view, it is true anytime the stat= e is other than

Down. On the other hand, if you view it as strictly = an event, you are

left with the question of what to put at the interse= ction of a state

and event in the table when it is impossible for tha= t event to occur

in that state. Some people note this with an "N= /A" (not applicable)

entry. In fact, previous TRILL state diagrams such a= s in RFC 7177 use

"N/A" so it would probably be simplest to = change to that for

consistency.

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 Should section 2.4 include a note that indicates that reliance

> on information completeness does mean that ther= e are windows when

> new entities join the space represented by part= icular TRILL data

> label during which packets for that destination= may be dropped, due

> to clients not yet having received the updated information?=C2=A0 I

> believe this window is small, and it is quite reasonable to also

> note that in such text.

=C2=A0

Yes, something like that would be a good addition to= Section 2.4. It

depends a bit on how the Push Directory is being man= aged. It may be

pushing data provided by orchestration. In any case,= there are always

finite delays and for a particular ingress TRILL swi= tch and an end

station being connected to some other TRILL switch, = the ingress could

learn reachability for the end station either a bit = before or after it

is actually reachable so traffic intended for the en= d station could,

for example, be dropped during a brief window of tim= e when it should

be forwarded.

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 Text in section 3.2.2.1 on lifetimes and the information

> maintenance in section 3.3 imply that the clien= ts and servers must

> maintain a connection.=C2=A0 Presumably, this is required already by the

> RBridge Channel protocol, and I understand that= we should not repeat

> the entire protocol here.=C2=A0 It would seem t= o make readers life MUCH

> simpler if the text noted that the RBridge Chan= nel protocol requires

> that there be a maintained connection between t= he client and the

> server, and that these mechanisms leverage the = presence of that

> connection.

=C2=A0

The basic RBridge Channel protocol [RFC7178] is a da= tagram protocol

rather than a connection protocol. So there is no gu= aranteed

continuity of connection between RBridges that have previously

exchanged RBridge Channel messages. But connection w= ould only be lost

if the network partitions since RBridge Channel mess= ages look like

data packets to any transit RBridges and will get fo= rwarded as long as

there is any route.=C2=A0 Network partition is immediately visible in the

link state database to the RBridges at both ends of = an RBridge Channel

exchange.=C2=A0 Section 3.7 provides that if a Pull Directory is no longer

reachable (i.e., RBridge Channel protocol packets wo= uld no longer get

through), then all pull responses from that Pull Dir= ectory MUST be

discarded since cache consistency update messages ca= n't get through.

=C2=A0

Perhaps a reference to Section 3.7 should be added t= o Section 3.3.

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 In section 3.2.2.2 on Pull directory forwarding, I expect to see

> text about and to whom the Pull server will flo= od the received

> request.=C2=A0 Instead, the text appears to say that it is the response

> that will be flooded.=C2=A0 More importantly, the descriptive text talks

> about sending the response, which would normall= y be a description of

> sending the response to the requestor, not send= ing it to someone

> else.

=C2=A0

If an ingress RBridge receives one of these broadcast/multicast

requests (ARP, etc.) and wants it flooded, they just= do the normal

encapsulation as a TRILL data packet and it will be = flooded (within

the VLAN or FGL). It is only if the ingress RBridge = wants the directory

to answer the request that it would package it into = an RBridge Channel

message and unicast it to a directory.

=C2=A0

As to whom a response synthesized by the directory s= hould be sent, it

seems like the safest thing is to send it as the res= ponse would

normally be sent by an end station responder. So, if= an ARP response

would be broadcast (within a VLAN or the like), then= I don't see what

is wrong about the directory flooding it.

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 In a related confusion, it seems very strange that a "flood"

> request will result in sending an underlying pa= cket unicast to the

> destination.=C2=A0 This may be just terminology, but it seems likely to

> confuse implementers.=C2=A0 Maybe the flag should be called the Forward

> flag, with a note in the definition that it nor= mally causes the

> response to be sent to multiple parties, but in= the case of a raw

> MAC frame, results in the packet being forwarde= d to the destination

> or flooded, as the server can manage?

=C2=A0

I don't have any particular problem with changin= g the FL flood flag to

an FR forward flag or whatever, but I'm not sure= what difference it

would make to behavior. If you want the failure of t= he directory to be

able to answer the query to be that the query (ARP r= equest or

whatever) to be sent pretty much as if it had never = been packaged into

an RBridge Channel message and sent to the directory= , then you set

this flag. When the flag is set and the directory ca= n't answer the

query, it sends it as a TRILL Data packet. If the or= iginal frame was

broadcast or multicast, as is usually the case, then= the directory

server "floods" it (with the frames VLAN o= r FGL). The same is true if

the request was of the "unknown destination uni= cast MAC" type -- if

the directory does not know the edge RBridge from wh= ich that MAC is

reachable and the FL flag is set, it floods it even = though in this

case the Inner.MacDA is a unicast address.

=C2=A0

In the unknown destination MAC case where the direct= ory does know the

reachability of that MAC, then the frame is decapsul= ated from the

RBridge Channel and then encapsulated as a TRILL Dat= a packet and sent

to the edge RBridge from which that MAC is reachable= . In this case,

the FL flag has no effect since it only comes into p= lay if the

directory does not have the required information.

=C2=A0

I=E2=80=99m fine with adding some clarifying text on= all this.

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 In the description in section 3.3 of Cache management, in the

> text on method one in which the servers keep mi= nimal state, it would

> seem that a large health warning is needed, as = this method will

> cause all clients to discard all positive data = whenever any positive

> data at the server changes (even if no client i= s using the modified

> data.)=C2=A0 This makes a flapping end station an attack on the cache of

> all clients!

=C2=A0

That would be true if the directory data comes from = data plane

learning but not so much if it is from an orchestrat= ion system in a

Data Center. Adding some additional efficiency warni= ng(s) is

reasonable.

=C2=A0

>=C2=A0=C2=A0=C2=A0=C2=A0 It strikes me that the working group could help get robust

> deployment by making method 3 (tracking what yo= u told clients) a

> SHOULD.=C2=A0 (I grant that it is not a MUST, as the other choices do

> work.)

=C2=A0

That sounds reasonable. We can check with the WG.

=C2=A0

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

=C2=A0Donald E. Eastlake 3rd=C2=A0=C2=A0 +1-508-333-2270 (cell)

=C2=A0155 Beaver Street, Milford, MA 01757 USA

=C2=A0d3e3e3@gma= il.com

=C2=A0

--94eb2c114d24f48ca00530879739-- From nobody Fri Apr 15 08:52:08 2016 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 57D0412D9DF; Fri, 15 Apr 2016 08:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 AUXNif2rSkLD; Fri, 15 Apr 2016 08:52:05 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 D0BE312D9A3; Fri, 15 Apr 2016 08:52:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 82D252E27DC; Fri, 15 Apr 2016 08:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460735525; bh=iK6V/+M9YffJC4eZYJfqhuVBlh1m9hotNn1OSrl94LM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=j1f7rldtgUYled8rktTizzQA90Vfl3cjgfLNoZO6Bkt6vEZ41OX5ayBw8VkmfI5n/ 9er16879PfJeoXUegJtivEeC1xRYVKk3OMRSoScOoUmvTHFAyBu2Em33iiobRaUg0z CntXmmStu+aAHe3Jh9d1ab+iHMLdqBnsvy2jDybU= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8B2D61C0D95; Fri, 15 Apr 2016 08:52:04 -0700 (PDT) To: Donald Eastlake References: <570EB05D.20802@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <57110E19.6050304@joelhalpern.com> Date: Fri, 15 Apr 2016 11:51:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" , draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 15 Apr 2016 15:52:07 -0000 Thank you Donald. Points of agreement elided, some responses to try to clarify my observations. I will note that from your comments about 3.1, I believe my concerns, now moved to 3.7, are larger, as I had assumed that the magic was in some other protocol, and you now say it is not defined there. Yours, Joel On 4/15/16 11:23 AM, Donald Eastlake wrote: > Hi Joel > > Thanks for your thorough review and comments. See below > > On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern > > > wrote: > ... >> Major Issues: > >> In the state machine transitions in section 2.3.3 > >> for push servers, it appears that if the event indicating that the > >> server is being shut down occurs while the server is already Going > >> Stand-By or Uncompleting, the transitions indicate that this >> "going > >> down" event will be lost. A strict reading of this would seem to > >> mean that the "go Down" event would need to recur after the >> timeout > >> condition. This would seem to be best addressed by a new state > >> "Going-Down" whose timeout behavior is to move to down state. > > I understand your point but "going down" and the like are called > > "events or conditions" in this draft, not just events. > > The problem with adding a single "Going-Down" state is that > transition > > to that state would lose the information as to whether or not the > Push > > Directory had been advertising that it was pushing complete > > information or not. The reason to remember this is that you would > want > > to behave a differently if the "going down" condition was revoked > > before it completed. This information could be preserved in a > Boolean > > pseudo variable but the current style of state machine in this draft > > avoids such pseudo variables and encodes all of the relevant push > > directory's state into the state machine state. Thus, I can see > three > > possible responses to your comment: > > 1) Change wording to emphasize that these "events or conditions" can > > be conditions that cause a state transition some substantial time > > after they become true. > > 2) Add two new states: (1) going down - was complete; (2) going down > - > > was incomplete. > > 3) Change the style of state machine to admit pseudo variables which > > can be set and testing as part of the state machinery. > > Option 1 is just some minor wording changes but adopting either > > options 2 or 3 involves more extensive changes so I would prefer to > > avoid them. > From what I have seen, trying to build a state machine with conditions rather than events is fraught with problems and tends to lead to errors in implementation. It amounts to hiding pseudo-variables inside the states, but not describing them. Thus, I would much prefer solution 2, but it is of course up to the WG. ... >> Minor Issues: > >> In section 2.3.3 describing the state transitions for push > >> servers, there is an event (event 1) described as "the server was > >> Down but is now Up." The state transition diagram describes this >> as > >> being a valid event that does not change the servers state if the > >> server is in any state other than "Down." In one sense, this is > >> reasonable, saying that such an event is harmless. I would >> however > >> expect some sort of logging or administrative notification, as > >> something in the system is quite confused. > > Again, I see your point but it seems to me to be a matter of state > > machine style. Note that the "event" is described as a condition, so > > from that point of view, it is true anytime the state is other than > > Down. On the other hand, if you view it as strictly an event, you > are > > left with the question of what to put at the intersection of a state > > and event in the table when it is impossible for that event to occur > > in that state. Some people note this with an "N/A" (not applicable) > > entry. In fact, previous TRILL state diagrams such as in RFC 7177 > use > > "N/A" so it would probably be simplest to change to that for > > consistency. I think N/A would be good. ... >> Text in section 3.2.2.1 on lifetimes and the information > >> maintenance in section 3.3 imply that the clients and servers must > >> maintain a connection. Presumably, this is required already by the > >> RBridge Channel protocol, and I understand that we should not >> repeat > >> the entire protocol here. It would seem to make readers life MUCH > >> simpler if the text noted that the RBridge Channel protocol >> requires > >> that there be a maintained connection between the client and the > >> server, and that these mechanisms leverage the presence of that > >> connection. > > The basic RBridge Channel protocol [RFC7178] is a datagram protocol > > rather than a connection protocol. So there is no guaranteed > > continuity of connection between RBridges that have previously > > exchanged RBridge Channel messages. But connection would only be > lost > > if the network partitions since RBridge Channel messages look like > > data packets to any transit RBridges and will get forwarded as long > as > > there is any route. Network partition is immediately visible in the > > link state database to the RBridges at both ends of an RBridge > Channel > > exchange. Section 3.7 provides that if a Pull Directory is no > longer > > reachable (i.e., RBridge Channel protocol packets would no longer > get > > through), then all pull responses from that Pull Directory MUST be > > discarded since cache consistency update messages can't get through. > > Perhaps a reference to Section 3.7 should be added to Section 3.3. > I don't think a reference to 3.7 is sufficient, although it is helpful. If the protocol is a datagram protocol, and if it is important to discard data from unreachable pull servers, then I think 3.7 NEEDS to say more than just ~if you happen to magically figure out you can't reach the server, discard data it has given you.~ From the rest of the text, this is an important and unspecified protocol mechanism. ... In the flooding flag and behavior, (long text elided) I don't think there is anything wrong with the intended behavior. It is just that the very brief description of the FL flag leads the reader to an incorrect expectation. Yes, it gets sorted out, but that is not good. What I would suggest is when the flag is defined (with whatever name you choose) note that "for the qtypes 2,3,and 4, the flag indicates that the server should flood its response." ... > > Thanks, > > Donald From nobody Fri Apr 15 18:44:24 2016 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 484A512D64D for ; Fri, 15 Apr 2016 18:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.787 X-Spam-Level: X-Spam-Status: No, score=-107.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=apnic.net 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 65RysfqTmN9u for ; Fri, 15 Apr 2016 18:44:20 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (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 A05A212D602 for ; Fri, 15 Apr 2016 18:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=/LkNkQOoj7qLfiJhVEDTEPalv+6IfL4l3RdPw7FMZew=; b=O8B/v6SnGihn50dXeBdFLyWH8acesISNfLFgDW5AQwHHFfUawHWkODcpwlQeZQqfoK48lcb1F5FEp rNSsXJZUKWvEtRjYmUd4cC4h9GX9ZaMVGZ3ewXhehO43pkt3IFse7D3z26lyNTpJ5DPpuLgDqhCulB qai3lqK6KOhvNjQc= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Sat, 16 Apr 2016 11:46:58 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 16 Apr 2016 11:43:47 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 $3124$) From: Geoff Huston In-Reply-To: Date: Sat, 16 Apr 2016 11:44:11 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <85F5A4D0-AE6B-4B5A-B888-0F0FF9859991@apnic.net> References: To: X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-trill-arp-optimization@tools.ietg.org, rtg-dir@ietf.org, trill@ietf.org Subject: [trill] RtgDir review: draft-ietf-trill-arp-optimization 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, 16 Apr 2016 01:44:22 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-trill-arp-optimization-05.txt Reviewer: Geoff Huston Review Date: 16 April 2016 IETF LC End Date: date-if-known=20 Intended Status: copy-from-I-D Summary:=20 This document is basically ready for publication, but has nits = that should be considered prior to publication. Comments: I found the draft concise and clear. It was readable and readily = understood. Major Issues: No major issues found Minor Issues: No minor issues found. Nits: Minor: section 2: =E2=80=9C...receive and save such mapping = information also.=E2=80=9D seems a bit stilted and I would say =E2=80=9Ca= lso receive and save such mapping information. section 3.1 "populate the information of sender's IP/MAC in its = ARP table=E2=80=9D. Do the authors really mean "ARP table" if the = information was learned by ND? i.e. its clear that the authors are = referring to the local IP/MAC address table, but the previous text tends = to associated ARP with IPv4 and ND with IPv6. Perhaps =E2=80=9CAARP/ND = table=E2=80=9D ?= From nobody Fri Apr 15 20:12:26 2016 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 2D46612DD86; Fri, 15 Apr 2016 20:12:23 -0700 (PDT) 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 QWQ-ORlRV4EK; Fri, 15 Apr 2016 20:12:21 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 5701712DD54; Fri, 15 Apr 2016 20:12:21 -0700 (PDT) Received: by mail-ob0-x22b.google.com with SMTP id bg3so73601529obb.1; Fri, 15 Apr 2016 20:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lB/98AmUlQe54F6LLUuxFanybL7EVUTfqRQ//s0Nh94=; b=HxiHB3OBocY/qmSVSv8tK85agCuDmC02iKxtbckXdOG8VOLa/2Qw1HtoB4+lCw+H5P u/paaYPQgwuSIDYkD74DjpMQLEzcuezVdPktT2jSn3EXfoU3u+SKGsz3qYqhNmkmGap0 +tzpCZU5pREXbixsyJNnU8wBnq6zpVP4Cb2Q+oJDwZOkXGslFMAoHj//86KA1OGqxDWx gl0NSkNtpbjwgp/bixWwqpykSIwX3vRImCMcwhsW4WQ5V/DBCwGdprTalkZU7qMuwThb HveZw86+8YmB0KD1+9yvo9L+r/voj5phMD1WOIrYOcV58Uegj1jX94ZMB+XOj2VK1G/V mx9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lB/98AmUlQe54F6LLUuxFanybL7EVUTfqRQ//s0Nh94=; b=FuctY57EkokBFimXuDYI/GbC7ECIrRrBkfm6ILnIty8gOaja0uBqx/51pfpaAj/8vV WOBj1/2T/i5CKdRNqRjKbWpCcQYUrPJERcCppTounit3pl15pmePIBbHCIjipo5n2DaZ QHJIYS3FPFQyZN8nfCjISnDaV681fZslx+c+lEAxJRINRXPKe6xKWb40a0HqTHqI8jFo 5+NkJGgl9btywwlay9BmQqwTvxTclGDtnIbLq9ieA/vuvh9sd9PVgx8nd56XOYbruRgn 6AiH8SooJwMjR2+6iNfC64OkOZ+i25yJkweIrG8eIl+KOYF7bMe2Mrywz7PbNXbxPFBK p0nw== X-Gm-Message-State: AOPr4FX0C1BHPE1PUH6f/rEnMwRh4Mmq2onTs4Iy/mRqe7P1oitZ7QSYe8+lrt2zrIp0iLewP120mH63aYdVUQ== X-Received: by 10.182.103.194 with SMTP id fy2mr12018602obb.74.1460776340599; Fri, 15 Apr 2016 20:12:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.250 with HTTP; Fri, 15 Apr 2016 20:12:06 -0700 (PDT) In-Reply-To: <57110E19.6050304@joelhalpern.com> References: <570EB05D.20802@joelhalpern.com> <57110E19.6050304@joelhalpern.com> From: Donald Eastlake Date: Fri, 15 Apr 2016 23:12:06 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" , draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 16 Apr 2016 03:12:23 -0000 Hi Joel, On Fri, Apr 15, 2016 at 11:51 AM, Joel M. Halpern wrote: > Thank you Donald. Points of agreement elided, some responses to try to > clarify my observations. I will note that from your comments about 3.1, I > believe my concerns, now moved to 3.7, are larger, as I had assumed that the > magic was in some other protocol, and you now say it is not defined there. > > Yours, > Joel > > On 4/15/16 11:23 AM, Donald Eastlake wrote: >> >> Hi Joel >> >> Thanks for your thorough review and comments. See below >> >> On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern > wrote: >> > ... > >>> Major Issues: >>> In the state machine transitions in section 2.3.3 >>> for push servers, it appears that if the event indicating that the >>> server is being shut down occurs while the server is already Going >>> Stand-By or Uncompleting, the transitions indicate that this >>> "going >>> down" event will be lost. A strict reading of this would seem to >>> mean that the "go Down" event would need to recur after the >>> timeout >>> condition. This would seem to be best addressed by a new state >>> "Going-Down" whose timeout behavior is to move to down state. >> >> I understand your point but "going down" and the like are called >> "events or conditions" in this draft, not just events. >> The problem with adding a single "Going-Down" state is that >> transition >> to that state would lose the information as to whether or not the >> Push >> Directory had been advertising that it was pushing complete >> information or not. The reason to remember this is that you would >> want >> to behave a differently if the "going down" condition was revoked >> before it completed. This information could be preserved in a >> Boolean >> pseudo variable but the current style of state machine in this draft >> avoids such pseudo variables and encodes all of the relevant push >> directory's state into the state machine state. Thus, I can see >> three >> possible responses to your comment: >> >> 1) Change wording to emphasize that these "events or conditions" can >> be conditions that cause a state transition some substantial time >> after they become true. >> >> 2) Add two new states: (1) going down - was complete; (2) going down >> - >> was incomplete. >> >> 3) Change the style of state machine to admit pseudo variables which >> can be set and testing as part of the state machinery. >> >> Option 1 is just some minor wording changes but adopting either >> options 2 or 3 involves more extensive changes so I would prefer to >> avoid them. > > From what I have seen, trying to build a state machine with conditions > rather than events is fraught with problems and tends to lead to errors in > implementation. It amounts to hiding pseudo-variables inside the states, > but not describing them. > Thus, I would much prefer solution 2, but it is of course up to the WG. Well, option 2 wouldn't be too hard. Option 3 would probably involve the most change. > ... > >>> Minor Issues: >>> In section 2.3.3 describing the state transitions for push >>> servers, there is an event (event 1) described as "the server was >>> Down but is now Up." The state transition diagram describes this >>> as >>> being a valid event that does not change the servers state if the >>> server is in any state other than "Down." In one sense, this is >>> reasonable, saying that such an event is harmless. I would >>> however >>> expect some sort of logging or administrative notification, as >>> something in the system is quite confused. >> >> Again, I see your point but it seems to me to be a matter of state >> machine style. Note that the "event" is described as a condition, so >> from that point of view, it is true anytime the state is other than >> Down. On the other hand, if you view it as strictly an event, you >> are >> left with the question of what to put at the intersection of a state >> and event in the table when it is impossible for that event to occur >> in that state. Some people note this with an "N/A" (not applicable) >> entry. In fact, previous TRILL state diagrams such as in RFC 7177 >> use >> "N/A" so it would probably be simplest to change to that for >> consistency. > > I think N/A would be good. OK. > ... > >>> Text in section 3.2.2.1 on lifetimes and the information >>> maintenance in section 3.3 imply that the clients and servers must >>> maintain a connection. Presumably, this is required already by the >>> RBridge Channel protocol, and I understand that we should not >>> repeat >>> the entire protocol here. It would seem to make readers life MUCH >>> simpler if the text noted that the RBridge Channel protocol >>> requires >>> that there be a maintained connection between the client and the >>> server, and that these mechanisms leverage the presence of that >>> connection. >> >> The basic RBridge Channel protocol [RFC7178] is a datagram protocol >> rather than a connection protocol. So there is no guaranteed >> continuity of connection between RBridges that have previously >> exchanged RBridge Channel messages. But connection would only be >> lost >> if the network partitions since RBridge Channel messages look like >> data packets to any transit RBridges and will get forwarded as long >> as >> there is any route. Network partition is immediately visible in the >> link state database to the RBridges at both ends of an RBridge >> Channel >> exchange. Section 3.7 provides that if a Pull Directory is no >> longer >> reachable (i.e., RBridge Channel protocol packets would no longer >> get >> through), then all pull responses from that Pull Directory MUST be >> discarded since cache consistency update messages can't get through. >> Perhaps a reference to Section 3.7 should be added to Section 3.3. > > I don't think a reference to 3.7 is sufficient, although it is helpful. > If the protocol is a datagram protocol, and if it is important to discard > data from unreachable pull servers, then I think 3.7 NEEDS to say more than > just ~if you happen to magically figure out you can't reach the server, > discard data it has given you.~ From the rest of the text, this is an > important and unspecified protocol mechanism. Figuring out whether/how you can reach other RBridges is a basic function of TRILL IS-IS based routing, not something "magical". Whenever their is a topology change, an RBridge MUST determine routes to all data reachable RBridges in the new topology. If there was an RBridge previously reachable but no longer reachable, as would be the case for all RBridges on the other side of a network partition, this MUST be noticed so that, for example, all MAC reachability information associated with each of the no longer reachable RBridges can be discarded. It does not seem like much of a stretch to believe that an RBridge would keep track of the Pull Directory or Directories it was using, each of which will be some other RBridge, and notice when a topology change makes any of them inaccessible. But I have no problem adding some wording to make this clearer. > ... > In the flooding flag and behavior, (long text elided) I don't think there is > anything wrong with the intended behavior. It is just that the very brief > description of the FL flag leads the reader to an incorrect expectation. > Yes, it gets sorted out, but that is not good. What I would suggest is when > the flag is defined (with whatever name you choose) note that "for the > qtypes 2,3,and 4, the flag indicates that the server should flood its > response." We can work on clarifying the wording. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri Apr 15 20:46:39 2016 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 08FDE12E2A6; Fri, 15 Apr 2016 20:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 i0lv23oNAbou; Fri, 15 Apr 2016 20:46:35 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 537FC12DBFA; Fri, 15 Apr 2016 20:46:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 135DB5E0BF8; Fri, 15 Apr 2016 20:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460778395; bh=jD3WISf2Pcc5wFpjWpbSQm/plcDm3j96LLtUbtRtllk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=IkiaN1zxFNz2H2ncBNLbFxjpYiSuT+vXMZjtQmsp4NjEsw8LFlXjfMt6rGmQYRRGF Swq81RwPYYVb//FG+zQH7xkbCQ7BjNFAKxA9bFrUqAb4h60DY5EB8xqqIApkE5Muvo XJsErcSzoliC1B7PYsjfiDmZzBhBUMQoOoS6rNWM= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 242DD5E0BF6; Fri, 15 Apr 2016 20:46:34 -0700 (PDT) To: Donald Eastlake References: <570EB05D.20802@joelhalpern.com> <57110E19.6050304@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <5711B58E.8010506@joelhalpern.com> Date: Fri, 15 Apr 2016 23:46:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" , draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 16 Apr 2016 03:46:37 -0000 If by the connectivity check to the directory server, you mean the underlying IS-IS routing reporting connectivity, then say that. While that is not actually interchangeable with real connectivity, it is perfectly reasoanble for the WG to deem it sufficient. I think it would only take a sentence or two to clarify for the reader that what is meant is apparent topological connectivity, as distinct from verified communication. Yours, Joel On 4/15/16 11:12 PM, Donald Eastlake wrote: > Hi Joel, > > On Fri, Apr 15, 2016 at 11:51 AM, Joel M. Halpern wrote: >> Thank you Donald. Points of agreement elided, some responses to try to >> clarify my observations. I will note that from your comments about 3.1, I >> believe my concerns, now moved to 3.7, are larger, as I had assumed that the >> magic was in some other protocol, and you now say it is not defined there. >> >> Yours, >> Joel >> >> On 4/15/16 11:23 AM, Donald Eastlake wrote: >>> >>> Hi Joel >>> >>> Thanks for your thorough review and comments. See below >>> >>> On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern >> wrote: >>> >> ... >> >>>> Major Issues: >>>> In the state machine transitions in section 2.3.3 >>>> for push servers, it appears that if the event indicating that the >>>> server is being shut down occurs while the server is already Going >>>> Stand-By or Uncompleting, the transitions indicate that this >>>> "going >>>> down" event will be lost. A strict reading of this would seem to >>>> mean that the "go Down" event would need to recur after the >>>> timeout >>>> condition. This would seem to be best addressed by a new state >>>> "Going-Down" whose timeout behavior is to move to down state. >>> >>> I understand your point but "going down" and the like are called >>> "events or conditions" in this draft, not just events. >>> The problem with adding a single "Going-Down" state is that >>> transition >>> to that state would lose the information as to whether or not the >>> Push >>> Directory had been advertising that it was pushing complete >>> information or not. The reason to remember this is that you would >>> want >>> to behave a differently if the "going down" condition was revoked >>> before it completed. This information could be preserved in a >>> Boolean >>> pseudo variable but the current style of state machine in this draft >>> avoids such pseudo variables and encodes all of the relevant push >>> directory's state into the state machine state. Thus, I can see >>> three >>> possible responses to your comment: >>> >>> 1) Change wording to emphasize that these "events or conditions" can >>> be conditions that cause a state transition some substantial time >>> after they become true. >>> >>> 2) Add two new states: (1) going down - was complete; (2) going down >>> - >>> was incomplete. >>> >>> 3) Change the style of state machine to admit pseudo variables which >>> can be set and testing as part of the state machinery. >>> >>> Option 1 is just some minor wording changes but adopting either >>> options 2 or 3 involves more extensive changes so I would prefer to >>> avoid them. >> >> From what I have seen, trying to build a state machine with conditions >> rather than events is fraught with problems and tends to lead to errors in >> implementation. It amounts to hiding pseudo-variables inside the states, >> but not describing them. >> Thus, I would much prefer solution 2, but it is of course up to the WG. > > Well, option 2 wouldn't be too hard. Option 3 would probably involve the most > change. > >> ... >> >>>> Minor Issues: >>>> In section 2.3.3 describing the state transitions for push >>>> servers, there is an event (event 1) described as "the server was >>>> Down but is now Up." The state transition diagram describes this >>>> as >>>> being a valid event that does not change the servers state if the >>>> server is in any state other than "Down." In one sense, this is >>>> reasonable, saying that such an event is harmless. I would >>>> however >>>> expect some sort of logging or administrative notification, as >>>> something in the system is quite confused. >>> >>> Again, I see your point but it seems to me to be a matter of state >>> machine style. Note that the "event" is described as a condition, so >>> from that point of view, it is true anytime the state is other than >>> Down. On the other hand, if you view it as strictly an event, you >>> are >>> left with the question of what to put at the intersection of a state >>> and event in the table when it is impossible for that event to occur >>> in that state. Some people note this with an "N/A" (not applicable) >>> entry. In fact, previous TRILL state diagrams such as in RFC 7177 >>> use >>> "N/A" so it would probably be simplest to change to that for >>> consistency. >> >> I think N/A would be good. > > OK. > >> ... >> >>>> Text in section 3.2.2.1 on lifetimes and the information >>>> maintenance in section 3.3 imply that the clients and servers must >>>> maintain a connection. Presumably, this is required already by the >>>> RBridge Channel protocol, and I understand that we should not >>>> repeat >>>> the entire protocol here. It would seem to make readers life MUCH >>>> simpler if the text noted that the RBridge Channel protocol >>>> requires >>>> that there be a maintained connection between the client and the >>>> server, and that these mechanisms leverage the presence of that >>>> connection. >>> >>> The basic RBridge Channel protocol [RFC7178] is a datagram protocol >>> rather than a connection protocol. So there is no guaranteed >>> continuity of connection between RBridges that have previously >>> exchanged RBridge Channel messages. But connection would only be >>> lost >>> if the network partitions since RBridge Channel messages look like >>> data packets to any transit RBridges and will get forwarded as long >>> as >>> there is any route. Network partition is immediately visible in the >>> link state database to the RBridges at both ends of an RBridge >>> Channel >>> exchange. Section 3.7 provides that if a Pull Directory is no >>> longer >>> reachable (i.e., RBridge Channel protocol packets would no longer >>> get >>> through), then all pull responses from that Pull Directory MUST be >>> discarded since cache consistency update messages can't get through. >>> Perhaps a reference to Section 3.7 should be added to Section 3.3. >> >> I don't think a reference to 3.7 is sufficient, although it is helpful. >> If the protocol is a datagram protocol, and if it is important to discard >> data from unreachable pull servers, then I think 3.7 NEEDS to say more than >> just ~if you happen to magically figure out you can't reach the server, >> discard data it has given you.~ From the rest of the text, this is an >> important and unspecified protocol mechanism. > > Figuring out whether/how you can reach other RBridges is a basic > function of TRILL IS-IS based routing, not something "magical". > Whenever their is a topology change, an RBridge MUST determine routes > to all data reachable RBridges in the new topology. If there was an > RBridge previously reachable but no longer reachable, as would be the > case for all RBridges on the other side of a network partition, this > MUST be noticed so that, for example, all MAC reachability information > associated with each of the no longer reachable RBridges can be discarded. > It does not seem like much of a stretch to believe that an RBridge would > keep track of the Pull Directory or Directories it was using, each of > which will be some other RBridge, and notice when a topology change > makes any of them inaccessible. But I have no problem adding some > wording to make this clearer. > >> ... >> In the flooding flag and behavior, (long text elided) I don't think there is >> anything wrong with the intended behavior. It is just that the very brief >> description of the FL flag leads the reader to an incorrect expectation. >> Yes, it gets sorted out, but that is not good. What I would suggest is when >> the flag is defined (with whatever name you choose) note that "for the >> qtypes 2,3,and 4, the flag indicates that the server should flood its >> response." > > We can work on clarifying the wording. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > From nobody Sat Apr 16 19:03:43 2016 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 2087212D950; Sat, 16 Apr 2016 19:03:39 -0700 (PDT) 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 YDHpUGOxLF8U; Sat, 16 Apr 2016 19:03:37 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 3844312D0BB; Sat, 16 Apr 2016 19:03:37 -0700 (PDT) Received: by mail-ob0-x232.google.com with SMTP id j9so81772259obd.3; Sat, 16 Apr 2016 19:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s4jcW4lOCW4Q0YidEkOti2gbG3redYKPrzsldRoN598=; b=Rsy56jXlgP73AZ3tFcu402Gjl7cpFp7KlupjEOlxNiSZzo9Ryh577SnoEoTdK3Td4d J6kV9soxz3berpoU+LiDEi7avupEQClRAPE5z7p2ohjUqF+WinqvKzXWRXNaZckM39lb Oco52m2v4O0/Rw76zFL8JceGvRA2WqeAhTx7kmZKV+VCro4S8Fcvpe5XloO4bI688noO 93Ux20wXTvsT2mQnjNEEIVCdyJU22QmevGvijyoZb2ckNLmrzr4bISx5jBUnZOkrXNV4 y4sJ5gTzDwaDQ0n4u+sJi3zpgPbqAR6nIHNZlUe0MZ8fD7nvd51vS0KAz0WgdoKz68aa w47w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s4jcW4lOCW4Q0YidEkOti2gbG3redYKPrzsldRoN598=; b=VzNLpO43imUIM1BtNgp6btT8q9ggDahgf8F4CtnglLr2FDBV8oiLuL7BWmXO3vRwj4 ng4wDoPEEGllQQnLvUgw5KiFxdGkWmnEgcReFSdH6NWSBwvWMzUdQL9q+KSPteOZ00mG YFLBLIv96P/JNUr6kxfh14al2vTM//l9tYvUOQkqdfRWBmhbeuMLx0r3FW0tNLbwF5Xf NS9Lr5lbRTfGHvggu7dYtGSrQCvLyFoGoZc5uznmU+ae2On7fdDpl+/FxUmqanD2AbiV rSBgDPBdXZfgQZihsf/n+hYzPX0/5w0/zeWcWmqlKK/mlWFuHrgKf3mVgzdfmopz4CHp oDXw== X-Gm-Message-State: AOPr4FUXfMtPNmTzMxalxIq7Z6AGjAdOevYbNYOnrDM/nmzUgG+Tnt/6nJ7NsETLYLVGGBNNBOZcbrUzDqvezw== X-Received: by 10.60.97.38 with SMTP id dx6mr13620416oeb.5.1460858616541; Sat, 16 Apr 2016 19:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.250 with HTTP; Sat, 16 Apr 2016 19:03:22 -0700 (PDT) In-Reply-To: <5711B58E.8010506@joelhalpern.com> References: <570EB05D.20802@joelhalpern.com> <57110E19.6050304@joelhalpern.com> <5711B58E.8010506@joelhalpern.com> From: Donald Eastlake Date: Sat, 16 Apr 2016 22:03:22 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" , draft-ietf-trill-directory-assist-mechanisms.all@ietf.org Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.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, 17 Apr 2016 02:03:39 -0000 Hi Joel, On Fri, Apr 15, 2016 at 11:46 PM, Joel M. Halpern wrote: > If by the connectivity check to the directory server, you mean the > underlying IS-IS routing reporting connectivity, then say that. OK. > While that > is not actually interchangeable with real connectivity, it is perfectly > reasoanble for the WG to deem it sufficient. I think it would only take a > sentence or two to clarify for the reader that what is meant is apparent > topological connectivity, as distinct from verified communication. The phrase usually used in TRILL (See RFC 7780) is "data reachable". Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Yours, > Joel > > > On 4/15/16 11:12 PM, Donald Eastlake wrote: >> >> Hi Joel, >> >> On Fri, Apr 15, 2016 at 11:51 AM, Joel M. Halpern >> wrote: >>> >>> Thank you Donald. Points of agreement elided, some responses to try to >>> clarify my observations. I will note that from your comments about 3.1, >>> I >>> believe my concerns, now moved to 3.7, are larger, as I had assumed that >>> the >>> magic was in some other protocol, and you now say it is not defined >>> there. >>> >>> Yours, >>> Joel >>> >>> On 4/15/16 11:23 AM, Donald Eastlake wrote: >>>> >>>> >>>> Hi Joel >>>> >>>> Thanks for your thorough review and comments. See below >>>> >>>> On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern >>> wrote: >>>> >>> ... >>> >>>>> Major Issues: >>>>> In the state machine transitions in section 2.3.3 >>>>> for push servers, it appears that if the event indicating that the >>>>> server is being shut down occurs while the server is already Going >>>>> Stand-By or Uncompleting, the transitions indicate that this >>>>> "going >>>>> down" event will be lost. A strict reading of this would seem to >>>>> mean that the "go Down" event would need to recur after the >>>>> timeout >>>>> condition. This would seem to be best addressed by a new state >>>>> "Going-Down" whose timeout behavior is to move to down state. >>>> >>>> >>>> I understand your point but "going down" and the like are called >>>> "events or conditions" in this draft, not just events. >>>> The problem with adding a single "Going-Down" state is that >>>> transition >>>> to that state would lose the information as to whether or not the >>>> Push >>>> Directory had been advertising that it was pushing complete >>>> information or not. The reason to remember this is that you would >>>> want >>>> to behave a differently if the "going down" condition was revoked >>>> before it completed. This information could be preserved in a >>>> Boolean >>>> pseudo variable but the current style of state machine in this draft >>>> avoids such pseudo variables and encodes all of the relevant push >>>> directory's state into the state machine state. Thus, I can see >>>> three >>>> possible responses to your comment: >>>> >>>> 1) Change wording to emphasize that these "events or conditions" can >>>> be conditions that cause a state transition some substantial time >>>> after they become true. >>>> >>>> 2) Add two new states: (1) going down - was complete; (2) going down >>>> - >>>> was incomplete. >>>> >>>> 3) Change the style of state machine to admit pseudo variables which >>>> can be set and testing as part of the state machinery. >>>> >>>> Option 1 is just some minor wording changes but adopting either >>>> options 2 or 3 involves more extensive changes so I would prefer to >>>> avoid them. >>> >>> >>> From what I have seen, trying to build a state machine with conditions >>> rather than events is fraught with problems and tends to lead to errors >>> in >>> implementation. It amounts to hiding pseudo-variables inside the states, >>> but not describing them. >>> Thus, I would much prefer solution 2, but it is of course up to the WG. >> >> >> Well, option 2 wouldn't be too hard. Option 3 would probably involve the >> most >> change. >> >>> ... >>> >>>>> Minor Issues: >>>>> In section 2.3.3 describing the state transitions for push >>>>> servers, there is an event (event 1) described as "the server was >>>>> Down but is now Up." The state transition diagram describes this >>>>> as >>>>> being a valid event that does not change the servers state if the >>>>> server is in any state other than "Down." In one sense, this is >>>>> reasonable, saying that such an event is harmless. I would >>>>> however >>>>> expect some sort of logging or administrative notification, as >>>>> something in the system is quite confused. >>>> >>>> >>>> Again, I see your point but it seems to me to be a matter of state >>>> machine style. Note that the "event" is described as a condition, so >>>> from that point of view, it is true anytime the state is other than >>>> Down. On the other hand, if you view it as strictly an event, you >>>> are >>>> left with the question of what to put at the intersection of a state >>>> and event in the table when it is impossible for that event to occur >>>> in that state. Some people note this with an "N/A" (not applicable) >>>> entry. In fact, previous TRILL state diagrams such as in RFC 7177 >>>> use >>>> "N/A" so it would probably be simplest to change to that for >>>> consistency. >>> >>> >>> I think N/A would be good. >> >> >> OK. >> >>> ... >>> >>>>> Text in section 3.2.2.1 on lifetimes and the information >>>>> maintenance in section 3.3 imply that the clients and servers must >>>>> maintain a connection. Presumably, this is required already by the >>>>> RBridge Channel protocol, and I understand that we should not >>>>> repeat >>>>> the entire protocol here. It would seem to make readers life MUCH >>>>> simpler if the text noted that the RBridge Channel protocol >>>>> requires >>>>> that there be a maintained connection between the client and the >>>>> server, and that these mechanisms leverage the presence of that >>>>> connection. >>>> >>>> >>>> The basic RBridge Channel protocol [RFC7178] is a datagram protocol >>>> rather than a connection protocol. So there is no guaranteed >>>> continuity of connection between RBridges that have previously >>>> exchanged RBridge Channel messages. But connection would only be >>>> lost >>>> if the network partitions since RBridge Channel messages look like >>>> data packets to any transit RBridges and will get forwarded as long >>>> as >>>> there is any route. Network partition is immediately visible in the >>>> link state database to the RBridges at both ends of an RBridge >>>> Channel >>>> exchange. Section 3.7 provides that if a Pull Directory is no >>>> longer >>>> reachable (i.e., RBridge Channel protocol packets would no longer >>>> get >>>> through), then all pull responses from that Pull Directory MUST be >>>> discarded since cache consistency update messages can't get through. >>>> Perhaps a reference to Section 3.7 should be added to Section 3.3. >>> >>> >>> I don't think a reference to 3.7 is sufficient, although it is helpful. >>> If the protocol is a datagram protocol, and if it is important to discard >>> data from unreachable pull servers, then I think 3.7 NEEDS to say more >>> than >>> just ~if you happen to magically figure out you can't reach the server, >>> discard data it has given you.~ From the rest of the text, this is an >>> important and unspecified protocol mechanism. >> >> >> Figuring out whether/how you can reach other RBridges is a basic >> function of TRILL IS-IS based routing, not something "magical". >> Whenever their is a topology change, an RBridge MUST determine routes >> to all data reachable RBridges in the new topology. If there was an >> RBridge previously reachable but no longer reachable, as would be the >> case for all RBridges on the other side of a network partition, this >> MUST be noticed so that, for example, all MAC reachability information >> associated with each of the no longer reachable RBridges can be discarded. >> It does not seem like much of a stretch to believe that an RBridge would >> keep track of the Pull Directory or Directories it was using, each of >> which will be some other RBridge, and notice when a topology change >> makes any of them inaccessible. But I have no problem adding some >> wording to make this clearer. >> >>> ... >>> In the flooding flag and behavior, (long text elided) I don't think there >>> is >>> anything wrong with the intended behavior. It is just that the very >>> brief >>> description of the FL flag leads the reader to an incorrect expectation. >>> Yes, it gets sorted out, but that is not good. What I would suggest is >>> when >>> the flag is defined (with whatever name you choose) note that "for the >>> qtypes 2,3,and 4, the flag indicates that the server should flood its >>> response." >> >> >> We can work on clarifying the wording. >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> > From nobody Sun Apr 17 08:55:38 2016 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 1F20412DF92; Sun, 17 Apr 2016 08:55:35 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160417155535.28704.87982.idtracker@ietfa.amsl.com> Date: Sun, 17 Apr 2016 08:55:35 -0700 Archived-At: Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-over-ip-06.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: Sun, 17 Apr 2016 15: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 (Transparent Interconnection of Lots of Links) over IP Authors : Margaret Cullen Donald Eastlake Mingui Zhang Dacheng Zhang Filename : draft-ietf-trill-over-ip-06.txt Pages : 40 Date : 2016-04-17 Abstract: The TRILL (Transparent Interconnection of Lots of Links) protocol supports both point-to-point and multi-access links and is designed so that a variety of link protocols can be used between TRILL switch ports. This document standardizes methods for encapsulating TRILL in IP (v4 or v6) so as to use IP as a TRILL link protocol in a unified TRILL campus. It updates RFC 7177 and updates RFC 7178. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trill-over-ip-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-over-ip-06 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 Sun Apr 17 19:50:35 2016 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 6259912D695; Sun, 17 Apr 2016 19:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 D69_UoVFzmYS; Sun, 17 Apr 2016 19:50:29 -0700 (PDT) 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 CAF5612D514; Sun, 17 Apr 2016 19:50:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHT41051; Mon, 18 Apr 2016 02:50:23 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 18 Apr 2016 03:50:22 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 18 Apr 2016 10:50:18 +0800 From: Liyizhou To: Geoff Huston , "rtg-ads@tools.ietf.org" Thread-Topic: [trill] RtgDir review: draft-ietf-trill-arp-optimization Thread-Index: AQHRl4GIP3VGSJP0X0KTEMHOwz8xxp+PChcw Date: Mon, 18 Apr 2016 02:50:18 +0000 Message-ID: References: <85F5A4D0-AE6B-4B5A-B888-0F0FF9859991@apnic.net> In-Reply-To: <85F5A4D0-AE6B-4B5A-B888-0F0FF9859991@apnic.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.180.237] 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.0A090203.57144B70.002D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3892fa909b3e4652b982b66b17dd265d Archived-At: Cc: "draft-ietf-trill-arp-optimization@tools.ietg.org" , "rtg-dir@ietf.org" , "trill@ietf.org" Subject: Re: [trill] RtgDir review: draft-ietf-trill-arp-optimization 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, 18 Apr 2016 02:50:31 -0000 SGkgR2VvZmYsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBhbmQgY29tbWVudHMuIEkgd2ls bCB1cGRhdGUgdGhlIHRleHQgYXMgeW91IHN1Z2dlc3RlZCBpbiBuZXh0IHJldmlzaW9uLg0KDQpU aGFua3MsDQpZaXpob3UNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHJp bGwgW21haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvZmYgSHVz dG9uDQpTZW50OiBTYXR1cmRheSwgQXByaWwgMTYsIDIwMTYgOTo0NCBBTQ0KVG86IHJ0Zy1hZHNA dG9vbHMuaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLXRyaWxsLWFycC1vcHRpbWl6YXRpb25AdG9v bHMuaWV0Zy5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnDQpTdWJqZWN0OiBb dHJpbGxdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtdHJpbGwtYXJwLW9wdGltaXphdGlvbg0K DQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1l cyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJv dmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVz ZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywg aXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRo IGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQg c3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcg dGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi10cmlsbC1hcnAtb3B0aW1pemF0aW9u LTA1LnR4dA0KUmV2aWV3ZXI6IEdlb2ZmIEh1c3Rvbg0KUmV2aWV3IERhdGU6IDE2IEFwcmlsIDIw MTYNCklFVEYgTEMgRW5kIERhdGU6IGRhdGUtaWYta25vd24gDQpJbnRlbmRlZCBTdGF0dXM6IGNv cHktZnJvbS1JLUQNCg0KU3VtbWFyeTogDQoJVGhpcyBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVh ZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJl ZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQoJSSBmb3VuZCB0aGUgZHJhZnQg Y29uY2lzZSBhbmQgY2xlYXIuIEl0IHdhcyByZWFkYWJsZSBhbmQgcmVhZGlseSB1bmRlcnN0b29k Lg0KDQpNYWpvciBJc3N1ZXM6DQoJTm8gbWFqb3IgaXNzdWVzIGZvdW5kDQoNCg0KTWlub3IgSXNz dWVzOg0KCU5vIG1pbm9yIGlzc3VlcyBmb3VuZC4NCg0KTml0czoNCglNaW5vcjoNCgkgc2VjdGlv biAyOiDigJwuLi5yZWNlaXZlIGFuZCBzYXZlIHN1Y2ggbWFwcGluZyBpbmZvcm1hdGlvbiBhbHNv LuKAnSBzZWVtcyBhIGJpdCBzdGlsdGVkICBhbmQgSSB3b3VsZCBzYXkg4oCcYWxzbyByZWNlaXZl IGFuZCBzYXZlIHN1Y2ggbWFwcGluZyBpbmZvcm1hdGlvbi4NCg0KICAgICAgICAgc2VjdGlvbiAz LjEgInBvcHVsYXRlIHRoZSBpbmZvcm1hdGlvbiBvZiBzZW5kZXIncyBJUC9NQUMgaW4gaXRzIEFS UCB0YWJsZeKAnS4gRG8gdGhlIGF1dGhvcnMgcmVhbGx5IG1lYW4gIkFSUCB0YWJsZSIgaWYgdGhl IGluZm9ybWF0aW9uIHdhcyBsZWFybmVkIGJ5IE5EPyBpLmUuIGl0cyBjbGVhciB0aGF0IHRoZSBh dXRob3JzIGFyZSByZWZlcnJpbmcgdG8gdGhlIGxvY2FsIElQL01BQyBhZGRyZXNzIHRhYmxlLCBi dXQgdGhlIHByZXZpb3VzIHRleHQgdGVuZHMgdG8gYXNzb2NpYXRlZCBBUlAgd2l0aCBJUHY0IGFu ZCBORCB3aXRoIElQdjYuIFBlcmhhcHMg4oCcQUFSUC9ORCB0YWJsZeKAnSA/DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0 DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 cmlsbA0K From nobody Mon Apr 18 00:10:18 2016 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 F2B4D12D1E4 for ; Mon, 18 Apr 2016 00:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 BNRcow_xsRyj for ; Mon, 18 Apr 2016 00:10:13 -0700 (PDT) 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 0579E12D5EF for ; Mon, 18 Apr 2016 00:10:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHT66426; Mon, 18 Apr 2016 07:10:09 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 18 Apr 2016 08:10:06 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 18 Apr 2016 15:09:57 +0800 From: Haoweiguo To: Linda Dunbar , Susan Hares , "trill@ietf.org" Thread-Topic: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 to 4/25) Thread-Index: AQHRlxJsn0gvdGs+QkC30QkOJcqIx5+PU3gE Date: Mon, 18 Apr 2016 07:09:56 +0000 Message-ID: References: <041101d19423$8c006f60$a4014e20$@ndzh.com>, <4A95BA014132FF49AE685FAB4B9F17F657E6EC02@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E6EC02@dfweml501-mbb> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.153.212] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB551733502A49BEnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57148852.00B4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5fb32f7ea9b96333990f5b250c1f6a33 Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: Re: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 to 4/25) 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, 18 Apr 2016 07:10:16 -0000 --_000_DD5FC8DE455C3348B94340C0AB551733502A49BEnkgeml513mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support as a co-author. The address flush is useful for fast network conve= rgence, and is ready to be adopted as WG draft. Thanks, weiguo ________________________________ From: Linda Dunbar [linda.dunbar@huawei.com] Sent: Friday, April 15, 2016 4:45 To: Susan Hares; trill@ietf.org Cc: 'Donald Eastlake'; 'Jon Hudson' Subject: Re: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4= /11 to 4/25) I have read the document and support the WG adoption. Linda From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 11, 2016 1:54 PM To: trill@ietf.org Cc: 'Donald Eastlake'; 'Jon Hudson' Subject: [trill] draft-hao-trill-address-flush-01 - WG Adoption call (4/11 = to 4/25) This begins a 2 week Working Group adoption for draft-hao-trill-address-flu= sh-01.txt https://datatracker.ietf.org/doc/draft-hao-trill-address-flush/ This draft specifies a message by which an originating TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the egress 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. In your comments on the draft, please indicate: 1) Do you feel the address flush is useful for deployments, 2) Do you feel the draft is enough technical merit to be adopted as WG= draft, Sue Hares and Jon Hudson --_000_DD5FC8DE455C3348B94340C0AB551733502A49BEnkgeml513mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Support as a co-author. The addr= ess flush is useful for fast network convergence, and is ready to be adopte= d as WG draft.

Thanks,

weiguo

From: Linda Dunbar [linda.dunbar@huawei.co= m]
Sent: Friday, April 15, 2016 4:45
To: Susan Hares; trill@ietf.org
Cc: 'Donald Eastlake'; 'Jon Hudson'
Subject: Re: [trill] draft-hao-trill-address-flush-01 - WG Adoption = call (4/11 to 4/25)

I have read the docum= ent and support the WG adoption.

Linda

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, April 11, 2016 1:54 PM
To: trill@ietf.org
Cc: 'Donald Eastlake'; 'Jon Hudson'
Subject: [trill] draft-hao-trill-address-flush-01 - WG Adoption call= (4/11 to 4/25)

This begins a 2 week Working Group adoption for draf= t-hao-trill-address-flush-01.txt

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

This draft specifies a message by which an or= iginating TRILL

switch can explicitly request other TRI= LL switches to flush certain

MAC reachability learned through the eg= ress of TRILL Data packets.

This is a supplement to the TRILL autom= atic address forgetting and

can assist in achieving more rapid conv= ergence in case of topology or

configuration change.

In your comments on the draft, please indicate:

1) Do you feel the address flush is useful for deployments,

2) Do you feel the draft is enough technical merit to be adopted= as WG draft,

Sue Hares and Jon Hudson

--_000_DD5FC8DE455C3348B94340C0AB551733502A49BEnkgeml513mbxchi_-- From nobody Mon Apr 18 00:56:18 2016 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 6322512DF79 for ; Mon, 18 Apr 2016 00:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 LA1fX-4XBDlc for ; Mon, 18 Apr 2016 00:56:05 -0700 (PDT) Received: from 189corp.21cn.com (forptr.bnet.cn [183.61.185.78]) by ietfa.amsl.com (Postfix) with ESMTP id 41C0B12DF6C for ; Mon, 18 Apr 2016 00:56:03 -0700 (PDT) HMM_SOURCE_IP: 10.64.15.13:45092.291076825 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-103.59.216.83 (unknown [10.64.15.13]) by 189corp.21cn.com (HERMES) with ESMTP id 79324480093; Mon, 18 Apr 2016 15:55:22 +0800 (CST) Received: from Lenovo-K-PC ([103.59.216.83]) by zment-as3(MEDUSA 0.0.0.0) with ESMTP id 00b4db9c-9d52-48e4-ad5b-e2f87f785eb2 for linda.dunbar@huawei.com; Mon Apr 18 15:55:23 2016 0/X-Total-Score: 0: X-FILTER-SCORE: to=<8d8a8f85824f85968f8382936189968298868a4f84908e>, score=<1460966123CbCCAC9bA1L/ON3CCCCC9CcPPcPbccdrrsstPPPPPbPP> X-REAL-FROM: liudx@gsta.com X-Receive-IP: 103.59.216.83 Date: Mon, 18 Apr 2016 15:55:23 +0800 From: "liudx@gsta.com" To: "Linda Dunbar" , "Susan Hares" , "trill@ietf.org" References: <041e01d19423$ef8df840$cea9e8c0$@ndzh.com>, <4A95BA014132FF49AE685FAB4B9F17F657E6EC15@dfweml501-mbb> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <201604181554489973773@gsta.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart230654572622_=----" Archived-At: Cc: 'Donald Eastlake' , 'Jon Hudson' Subject: Re: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - WG adoption (4/11 to 4/25) 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, 18 Apr 2016 07:56:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart230654572622_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGZvciBhZG9wdGlvbi4gDQoNClRoaXMgYXBwcm9hY2ggaXMgdXNlZnVsIGluIGRl cGxveW1lbnQgc2luY2UgaXQgcHJvbWlzZXMgYSBzY2FsYWJsZSBUUklMTC4NCiANCkFzIGFuIG9w ZXJhdG9yLCBJIHRoaW5rIG11bHRpbGV2ZWwgYWxzbyBiZW5lZml0cyB0aGUgc2NhbGFiaWxpdHkg b2Ygc2VjdXJpdHkgc2NoZW1lcy4gVGhpcyBtaWdodCBiZSBhIGRpcmVjdGlvbiB0aGF0IGRlc2Vy dmVzIG91ciBleHBsb3JhdGlvbi4NCiANClRoYW5rcywNCkRvbmd4aW4NCkNoaW5hIFRlbGVjb20N CiANCkZyb206IExpbmRhIER1bmJhcg0KRGF0ZTogMjAxNi0wNC0xNSAwNDo0Nw0KVG86IFN1c2Fu IEhhcmVzOyB0cmlsbEBpZXRmLm9yZw0KQ0M6ICdEb25hbGQgRWFzdGxha2UnOyAnSm9uIEh1ZHNv bicNClN1YmplY3Q6IFJlOiBbdHJpbGxdIGRyYWZ0LXpoYW5nLXRyaWxsLW11bHRpbGV2ZWwtdW5p cXVlLW5pY2tuYW1lLTAwIC0gV0cgYWRvcHRpb24gKDQvMTEgdG8gNC8yNSkNCkkgaGF2ZSByZWFk IHRoZSBkb2N1bWVudCBhbmQgc3VwcG9ydCB0aGUgV0cgYWRvcHRpb24uIA0KIA0KTGluZGENCiAN CkZyb206IHRyaWxsIFttYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFN1c2FuIEhhcmVzDQpTZW50OiBNb25kYXksIEFwcmlsIDExLCAyMDE2IDE6NTcgUE0NClRvOiB0 cmlsbEBpZXRmLm9yZw0KQ2M6ICdEb25hbGQgRWFzdGxha2UnOyAnSm9uIEh1ZHNvbicNClN1Ympl Y3Q6IFt0cmlsbF0gZHJhZnQtemhhbmctdHJpbGwtbXVsdGlsZXZlbC11bmlxdWUtbmlja25hbWUt MDAgLSBXRyBhZG9wdGlvbiAoNC8xMSB0byA0LzI1KQ0KIA0KVGhpcyBiZWdpbnMgYSAyIHdlZWsg V29ya2luZyBHcm91cCBhZG9wdGlvbiBjYWxsIGZvcjogZHJhZnQtemhhbmctdHJpbGwtbXVsdGkt bGV2ZWwtdW5pcXVlLW5pY2tuYW1lLiANCiANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXpoYW5nLXRyaWxsLW11bHRpbGV2ZWwtdW5pcXVlLW5pY2tuYW1lLw0KIA0KICAg VFJJTEwgcm91dGluZyBjYW4gYmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSBsZXZlbHMg YnkgYnVpbGRpbmcNCiAgIG9uIHRoZSBtdWx0aWxldmVsIGZlYXR1cmUgb2YgSVMtSVMgcm91dGlu Zy4gRGVwZW5kaW5nIG9uIGhvdw0KICAgbmlja25hbWVzIGFyZSBtYW5hZ2VkLCB0aGVyZSBhcmUg dHdvIHByaW1hcnkgYWx0ZXJuYXRpdmVzIHRvIHJlYWxpemUNCiAgIFRSSUxMIG11bHRpbGV2ZWw6 IHRoZSB1bmlxdWUgbmlja25hbWUgYXBwcm9hY2ggYW5kIHRoZSBhZ2dyZWdhdGVkDQogICBOaWNr bmFtZS4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSB1bmlxdWUgbmlja25hbWUgYXBwcm9h Y2guDQogDQpJbiB5b3VyIGNvbW1lbnRzIHBsZWFzZSBpbmRpY2F0ZTogDQoxKSAgICAgIERvIHlv dSB0aGluayB0aGUgbmlja25hbWUgYXBwcm9hY2ggaXMgdXNlZnVsIGluIGRlcGxveW1lbnRzIG9m IFRSSUxMLCANCjIpICAgICAgRG8geW91IGZlZWwgdGhpcyBkcmFmdCBwcm92aWRlcyBhIGdvb2Qg c29sdXRpb24gZm9yIHRoZSB1bmlxdWUgbmlja25hbWUgYXBwcm9hY2guIA0KIA0KIA0KU3VlIEhh cmVzIGFuZCBKb24gSHVkc29uIA0K ------=_001_NextPart230654572622_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A=0A

I support for adop= tion.

This = approach is useful in deployment since it promises a scalable TRILL.

As an operator, I = think multilevel also benefits the scalability of security schemes. This m= ight be a direction that deserves our exploration.

Thanks,

Do= ngxin

China Telecom

=0A

&nbs= p;
From: Susan Hares; trill@ietf.or= g
CC: 'Donald Eastlake'; 'Jon Hudson'
Subject: Re: [trill] dr= aft-zhang-trill-multilevel-unique-nickname-00 - WG adoption (4/11 to 4/25)=
=0A=0A
=0A
I have read the document and support the WG adoption.=0A
=0A
&= nbsp;
=0A
Linda
=0A

=0A
=0A
=0A<= p class=3D"MsoNormal" style=3D"margin: 0px 0in; font-size: 11pt; font-fami= ly: Calibri, sans-serif;">From: tr= ill [mailto:trill-bounces@ietf.org]=0AOn Behalf Of Susan Hares
= =0ASent: Monday, April 11, 2016 1:57 PM
=0ATo: trill@ietf= .org
=0ACc: 'Donald Eastlake'; 'Jon Hudson'
=0ASubject: [trill] draft-zhang-trill-multilevel-unique-nickname-00 - WG adoption (4= /11 to 4/25)
=0A
=0A
=0A

=0A
This begins a 2= week Working Group adoption call for: draft-zhang-trill-multi-level-uniqu= e-nickname.=0A
=0A

=0A
https://datatracker.ietf.org/doc/draft-zhang= -trill-multilevel-unique-nickname/
=0A

=0A
   T= RILL routing can be extended to support multiple levels by building
=0A
   on the multilevel featu= re of IS-IS routing. Depending on how
=0A
   nicknames are managed, there are two primary alternat= ives to realize
=0A
   T= RILL multilevel: the unique nickname approach and the aggregated
=0A
   Nickname. This docum= ent specifies the unique nickname approach.
=0A

=0A
In your c= omments please indicate:
=0A
1)    = =0ADo you think the nickname approach is useful in dep= loyments of TRILL,=0A
=0A
2)    &nbs= p;=0ADo you feel this draft provides a good solution for the= unique nickname approach.=0A
=0A
=
=0A

= =0A
Sue Hares and Jon Hudson
=0A<= /div>=0A

=0A ------=_001_NextPart230654572622_=------ From nobody Mon Apr 18 15:23:56 2016 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 5868D12E42E; Mon, 18 Apr 2016 15:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 7-XWJ7vTNW0B; Mon, 18 Apr 2016 15:23:41 -0700 (PDT) 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 09A3B12E8A5; Mon, 18 Apr 2016 15:23:40 -0700 (PDT) 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 CHU78404; Mon, 18 Apr 2016 22:23:39 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 18 Apr 2016 23:23:38 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Mon, 18 Apr 2016 15:23:27 -0700 From: Linda Dunbar To: trill , "trill@ietf.org" Thread-Topic: =?gb2312?B?W3RyaWxsXSC08Li0OiBSZTogIGRyYWZ0LWlldGYtdHJpbGwtNjQzOWJpcyBX?= =?gb2312?Q?G_LC_[3/17_to_4/5/2016)?= Thread-Index: AQHRiyC+GUdVLzwOTEmXD1bTDY17lZ+QaDxQgAADFyA= Date: Mon, 18 Apr 2016 22:23:27 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E74C85@dfweml501-mbb> References: <019e01d1807b$4daf93a0$e90ebae0$@ndzh.com> <9ba21b99a1940eb675e7690d23ae3983@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.250] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E74C85dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Donald Eastlake , Susan Hares , Liyizhou , 'Jon Hudson' Subject: Re: [trill] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXRyaWxsLTY0Mzli?= =?gb2312?b?aXMgV0cgTEMgWzMvMTcgdG8gNC81LzIwMTYp?= 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, 18 Apr 2016 22:23:55 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E74C85dfweml501mbb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNClN1cHBvcnQsDQoNCkxpbmRhIER1bmJhcg0KDQoNCkZyb206IHRyaWxsIFttYWlsdG86dHJp bGwtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBTdXNhbiBIYXJlcw0KU2VudDogRnJpZGF5LCBNYXJjaCAxOCwgMjAxNiAxMjowMiBB TQ0KVG86IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4NCkNjOiAnRG9uYWxk IEVhc3RsYWtlJzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT47IGh1LmZhbmd3ZWlAeHp0ZS5jb20uY248bWFpbHRvOmh1LmZh bmd3ZWlAeHp0ZS5jb20uY24+OyAnTGl5aXpob3UnOyBheWFiYW5lckBjaXNjby5vbTxtYWlsdG86 YXlhYmFuZXJAY2lzY28ub20+DQpTdWJqZWN0OiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwtNjQz OWJpcyBXRyBMQyBbMy8xNyB0byA0LzUvMjAxNikNCg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cg TEMgZm9yIGRyYWZ0LWlldGYtcmZjNjQzOWJpcy0wMS50eHQuICBJbiB5b3VyIGRpc2N1c3Npb24s IHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgYmVsaWV2ZToNCg0KMSkgICAgICBUaGlzIHVwZGF0ZSB0 byBSRkM2NDM5IGlzIG5lY2Vzc2FyeSB0byB1cGRhdGUgYW5kIGNsYXJpZnkgUkZDNjQzOSwNCjIp ICAgICAgSWYgeW91IGZlZWwgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgV0cgYWRvcHRpb24u DQoNClN1ZSBIYXJlcyBhbmQgSm9uIEh1ZHNvbg0KDQouX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5v cmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmlsbA0K --_000_4A95BA014132FF49AE685FAB4B9F17F657E74C85dfweml501mbb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

<= /p>
Support,

Linda Dunbar

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, March 18, 2016 12:02 AM
To: trill@ietf.org=
Cc: 'Donald Eastlake'; mohamed.= boucadair@orange.com; hu.fangwei@xzt= e.com.cn; 'Liyizhou'; ayabaner@cisco.om
Subject: [trill] draft-ietf-trill-6439bis WG LC [3/1= 7 to 4/5/2016)

This begins a 2 week WG LC for draft-ietf-rfc6439bis-01.txt.&n= bsp; In your discussion, please indicate if you believe:

1) This update to RFC6439 is nec= essary to update and clarify RFC6439,
2) If you feel this document is = ready for WG adoption.

Sue Hares and Jon Hudson

._____________________________________= __________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill=

--_000_4A95BA014132FF49AE685FAB4B9F17F657E74C85dfweml501mbb_-- From nobody Tue Apr 19 07:57:18 2016 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 C4DEF12DD9E for ; Tue, 19 Apr 2016 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 WGHkjhfrheeh for ; Tue, 19 Apr 2016 07:57:14 -0700 (PDT) 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 0111E12DC9C for ; Tue, 19 Apr 2016 07:57:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMQ52013; Tue, 19 Apr 2016 14:57:11 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 19 Apr 2016 15:57:07 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 19 Apr 2016 07:57:02 -0700 From: Linda Dunbar To: Donald Eastlake , "trill@ietf.org" Thread-Topic: WG LC for draft-ietf-trill-mtu-negotiation (3/17 to 4/5/2016) Thread-Index: AQHRmkOSQCtLonf/a0yWz/dpLKv1Bp+RYsUA Date: Tue, 19 Apr 2016 14:57:02 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E76C14@dfweml501-mbb> References: <01d701d1807e$439b7070$cad25150$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E76C14dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57164748.00C6, 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: 5f4fdf162fcf17d43c07b10ba3cadf52 Archived-At: Cc: Susan Hares , 'Jon Hudson' Subject: Re: [trill] WG LC for draft-ietf-trill-mtu-negotiation (3/17 to 4/5/2016) 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, 19 Apr 2016 14:57:17 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E76C14dfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KTGluZGENCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0t LS0tDQpGcm9tOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6 aC5jb20+Pg0KRGF0ZTogVGh1LCBNYXIgMTcsIDIwMTYgYXQgMjo1MyBQTQ0KU3ViamVjdDogV0cg TEMgZm9yIGRyYWZ0LWlldGYtdHJpbGwtbXR1LW5lZ290aWF0aW9uICgzLzE3IHRvIDQvNS8yMDE2 KQ0KVG86IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4NCkNjOiB0cmlsbC1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnRyaWxsLWNoYWlyc0B0b29scy5pZXRmLm9yZz4s IERvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbTxtYWlsdG86ZDNlM2UzQGdtYWlsLmNv bT4+DQoNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExDIGZvciBkcmFmdC10cmlsbC1tdHUtbmVn b3RpYXRpb24gZnJvbSAzLzE3LzIwMTYgdG8gNC81LzIwMTYuDQoNCkluIHlvdXIgcmV2aWV3LCBw bGVhc2UgY29tbWVudCBvbiB0aGUgZm9sbG93aW5nOg0KDQoxKSAgICAgIElzIHRoaXMgc3BlY2lm aWNhdGlvbiByZWFkeSBmb3IgcHVibGljYXRpb24/DQoNCjIpICAgICAgRG9lcyB0aGUgZG9jdW1l bnQgaGF2ZSBhbnkgdGVjaG5pY2FsIG9yIGVkaXRvcmlhbCBlcnJvcnM/DQoNCjMpICAgICAgSXMg TVRVIG5lZ290aWF0aW9uIHVzZWZ1bCBpbiB0aGUgZGVwbG95bWVudHMgb2YgdHJpbGwgb24gVFJJ TEwgY2FtcHVzZXMgZm9yIGxpbmsgcGFja2V0cyB0aGF0IGV4Y2VlZCB0aGUgVFJJTEwgY2FtcHVz IE1UVT8gIFdpbGwgdGhpcyBtYWtlIGRlcGxveW1lbnRzIGVhc2llcj8NCg0KU3VlIEhhcmVzIGFu ZCBKb24gSHVkc29uDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657E76C14dfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1cHBvcnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpbmRhDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0t LS0tLS0tPGJyPg0KRnJvbTogPGI+U3VzYW4gSGFyZXM8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86 c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0Ozxicj4NCkRhdGU6IFRodSwg TWFyIDE3LCAyMDE2IGF0IDI6NTMgUE08YnI+DQpTdWJqZWN0OiBXRyBMQyBmb3IgZHJhZnQtaWV0 Zi10cmlsbC1tdHUtbmVnb3RpYXRpb24gKDMvMTcgdG8gNC81LzIwMTYpPGJyPg0KVG86IDxhIGhy ZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+dHJpbGxAaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IDxh IGhyZWY9Im1haWx0bzp0cmlsbC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPnRyaWxsLWNoYWlyc0B0 b29scy5pZXRmLm9yZzwvYT4sIERvbmFsZCBFYXN0bGFrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmQz ZTNlM0BnbWFpbC5jb20iPmQzZTNlM0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgYmVn aW5zIGEgMiB3ZWVrIFdHIExDIGZvciBkcmFmdC10cmlsbC1tdHUtbmVnb3RpYXRpb24gZnJvbSAz LzE3LzIwMTYgdG8gNC81LzIwMTYuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHlv dXIgcmV2aWV3LCBwbGVhc2UgY29tbWVudCBvbiB0aGUgZm9sbG93aW5nOg0KPG86cD48L286cD48 L3A+DQo8cD4xKTxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+SXMgdGhpcyBzcGVjaWZpY2F0aW9uIHJlYWR5IGZvciBwdWJs aWNhdGlvbj8NCjxvOnA+PC9vOnA+PC9wPg0KPHA+Mik8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkRvZXMgdGhlIGRvY3Vt ZW50IGhhdmUgYW55IHRlY2huaWNhbCBvciBlZGl0b3JpYWwgZXJyb3JzPw0KPG86cD48L286cD48 L3A+DQo8cD4zKTxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+SXMgTVRVIG5lZ290aWF0aW9uIHVzZWZ1bCBpbiB0aGUgZGVw bG95bWVudHMgb2YgdHJpbGwgb24gVFJJTEwgY2FtcHVzZXMgZm9yIGxpbmsgcGFja2V0cyB0aGF0 IGV4Y2VlZCB0aGUgVFJJTEwgY2FtcHVzIE1UVT8mbmJzcDsgV2lsbCB0aGlzIG1ha2UgZGVwbG95 bWVudHMgZWFzaWVyPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdWUgSGFyZXMgYW5k IEpvbiBIdWRzb24NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657E76C14dfweml501mbb_-- From nobody Tue Apr 19 08:22:31 2016 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 86B5812DA6D; Tue, 19 Apr 2016 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.139 X-Spam-Level: *** X-Spam-Status: No, score=3.139 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 b7IpecAJedPn; Tue, 19 Apr 2016 08:22:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 B2AB712DF76; Tue, 19 Apr 2016 08:16:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: Date: Tue, 19 Apr 2016 11:16:05 -0400 Message-ID: <04ef01d19a4e$655b1690$301143b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F0_01D19A2C.DE4AFD30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGaTeywgargpFQSQYyq7gDOQ0XHjw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: hu.fangwei@xzte.com.cn, 'Mohammed Umair' , ayabaner@cisco.com, draft-ietf-trill-rfc6439bis@ietf.org, d3e3e3@gmail.com, 'Liyizhou' , 'Jon Hudson' Subject: [trill] IPR draft-ietf-trill-rfc6439bis - Will the authors please post their IPR statement 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, 19 Apr 2016 15:22:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F0_01D19A2C.DE4AFD30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The authors should post the IPR statements to the WG on draft-ietf-trill-rfc6439bis-01.txt (which is WG LC). There are two IPR statements regarding this draft: https://datatracker.ietf.org/ipr/2685/ https://datatracker.ietf.org/ipr/2585/ The WG groups should indicate if these IPR Statements cause the WG to reconsider publishing draft-ietf-trill-rfc6439bis-01.txt. Sue Hares and Jon Hudson ------=_NextPart_000_04F0_01D19A2C.DE4AFD30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The = authors should post the IPR statements to the WG on = draft-ietf-trill-rfc6439bis-01.txt (which is WG LC). =

There are two IPR statements regarding this = draft:

https://datatracker.ietf.= org/ipr/2685/
https://datatracker.ietf.= org/ipr/2585/

The WG = groups should indicate if these IPR Statements cause the WG to = reconsider publishing = draft-ietf-trill-rfc6439bis-01.txt.

Sue Hares = and Jon Hudson

------=_NextPart_000_04F0_01D19A2C.DE4AFD30-- From nobody Tue Apr 19 08:29:57 2016 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 F143E12D97B; Tue, 19 Apr 2016 08:29:56 -0700 (PDT) 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, HTML_MESSAGE=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 Qf1DsUjhSENM; Tue, 19 Apr 2016 08:29:55 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 7644412D969; Tue, 19 Apr 2016 08:29:55 -0700 (PDT) Received: by mail-ob0-x236.google.com with SMTP id bg3so16404077obb.1; Tue, 19 Apr 2016 08:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7WCssIdWmZVTJWZca9cxDWyi8w2LlB4li2UxgWbNVs8=; b=YL371Bl7m5cjS+CCVV0Ao2erYRQxwWK4ge6eMDefThjdJBuatQ+/mzGybZ4laTeF3Y KbZFd75+af8lVBexEW4rGbVJf0S2zzWZ7OiFyvkWeKligL7zpOs6hwvDkR6ov8CIbvvl gxT+oddEecqG8lveyNOzhRsymRHXT4T5XTdakd6onSK7KZnAjQg9cLZxweA2ghUHyS0p u6CRCPmyiux00YloTwSRn+TWQ//tNFXrvoz+6xou8NSCKWQZOmgFoAWPxg2F7AAqwwZg Gap6vsQJlKrUkA5Lr0pCdH0l5jA8Av/dhqyimWgrb11N+B/Y8HlyeFfBo5pI1fvvXJR0 k+FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7WCssIdWmZVTJWZca9cxDWyi8w2LlB4li2UxgWbNVs8=; b=mniS4znPzNSetdIyBBOO1NRb0usF1cl2y0bVGi3Sm6NkurBRsV4rxHimDulOHSjLyI laoqAEYCpt3L+ONSZT1N1p0YiSXjChIEcF95RhevQhOoKkKer+WMqkZgN92DXMGoGNjF NmxpbTiOlLft8sLR2bsBs7gkDy9qSFwEQqW7qcl/4a4mpveavqXZxk+Yignbzl0vqB+t lAqRneTTHUU8uV8cjzBqlVhIO8MZ08+L88iH9rDngaCPt4wrq8aCyLN4v/iiArODLPT2 +1XSXnKPMBtO0dwV8d2JnL3bnOgewPprjLwAZVmOcaY26kbayt4yHnK53tUWci2nuKcf jf+w== X-Gm-Message-State: AOPr4FU4VUkCWH8RnKLg6FL5QtXRxLS8lGQD1thfviRXrQxg+ksW2XQTruPRuQzZo67Rc6E39Ek5pmw0rKGHPA== X-Received: by 10.182.240.232 with SMTP id wd8mr1457258obc.74.1461079794549; Tue, 19 Apr 2016 08:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.250 with HTTP; Tue, 19 Apr 2016 08:29:40 -0700 (PDT) In-Reply-To: <04ef01d19a4e$655b1690$301143b0$@ndzh.com> References: <04ef01d19a4e$655b1690$301143b0$@ndzh.com> From: Donald Eastlake Date: Tue, 19 Apr 2016 11:29:40 -0400 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c2b15224a95b0530d826ce Archived-At: Cc: hu.fangwei@xzte.com.cn, Mohammed Umair , Ayan Banerjee , draft-ietf-trill-rfc6439bis@ietf.org, "trill@ietf.org" , Liyizhou , Jon Hudson Subject: Re: [trill] IPR draft-ietf-trill-rfc6439bis - Will the authors please post their IPR statement 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, 19 Apr 2016 15:29:57 -0000 --001a11c2b15224a95b0530d826ce Content-Type: text/plain; charset=UTF-8 I am not aware of any IPR in this draft that has not already been disclosed to the IETF. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Apr 19, 2016 at 11:16 AM, Susan Hares wrote: > The authors should post the IPR statements to the WG on > draft-ietf-trill-rfc6439bis-01.txt (which is WG LC). > > > > There are two IPR statements regarding this draft: > > > > https://datatracker.ietf.org/ipr/2685/ > > https://datatracker.ietf.org/ipr/2585/ > > > > > > The WG groups should indicate if these IPR Statements cause the WG to > reconsider publishing draft-ietf-trill-rfc6439bis-01.txt. > > > > Sue Hares and Jon Hudson > > > > > > > --001a11c2b15224a95b0530d826ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR in this draft that has not alrea= dy been disclosed to the IETF.

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
=C2= =A0Donald E. Eastlake 3rd=C2=A0=C2=A0 +1-508-333-2270 (cell)
=C2=A0155 B= eaver Street,=C2=A0Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Tue, Apr 19, 2016 at 11:16 AM, Susan Hare= s <shares@ndzh.com> wrote:
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
The authors should post the IPR statements to the WG on draft-ietf-trill= -rfc6439bis-01.txt (which is WG LC).=C2=A0
=C2=A0
There are two IPR s= tatements regarding this draft:=C2=A0
=C2=A0
https://datatracker.ietf.org/i= pr/2685/
https://datatracker.ietf.org= /ipr/2585/
=C2=A0=
=C2=A0
T= he WG groups should indicate if these IPR Statements cause the WG to recons= ider publishing draft-ietf-trill-rfc6439bis-01.txt.
=C2=A0
Sue Hares a= nd Jon Hudson
=C2=A0=
=C2=A0
<= u>=C2=A0