From d3e3e3@gmail.com Sat Nov 3 17:49:27 2012 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 9FEEE21F9C3D for ; Sat, 3 Nov 2012 17:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvTYmg2VKGNk for ; Sat, 3 Nov 2012 17:49:27 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD9A21F9BE1 for ; Sat, 3 Nov 2012 17:49:27 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7397681iec.31 for ; Sat, 03 Nov 2012 17:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=thx8FzdEd756YzeG5z4UwS2pBZlh0aUcJiewYWv6OL0=; b=dIi6H0oDr8n40KDOixm+LwkAUeMn7kmkRBujTpvqvs0B/4cnJ6uDmVpJfD4AdGnU5x QKevTq5XJYpy/Ruh6bjJqypT0finuWPGDJTTzzypjWI8obDv5xkS67tTumOT+fZJJnxx 7ZCnnckxhqyWHvlNO7hhHZvYaKJMKvOZQje7GNqBMRYYja1fw5U7rwGKH0Qzst1MEf3v YXcxrKH+mB/A5AgCX9Cif7ZYsqeCCDI/mOFjWB1mGe3+BaNz2I9FDQkjPi+sU/cQJsc6 M4KwBST49ZE7aJJuYZeU9OlyLjTfx6JpaI4ndaWZfo7suIFANmp8PaJyti6X4bOn5COR kB2g== Received: by 10.50.219.229 with SMTP id pr5mr5808767igc.59.1351990166673; Sat, 03 Nov 2012 17:49:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Sat, 3 Nov 2012 17:49:06 -0700 (PDT) In-Reply-To: <508EE8E5.8050307@acm.org> References: <508B36E7.9040801@sonic.net> <508EE8E5.8050307@acm.org> From: Donald Eastlake Date: Sat, 3 Nov 2012 20:49:06 -0400 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Ralph Droms Subject: Re: [trill] Updated TRILL milestones X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 00:49:27 -0000 See below On Mon, Oct 29, 2012 at 4:36 PM, Erik Nordmark wrote: > > As discussed at the last TRILL meeting, our milestones have gotten out > of date. At our next meeting in Atlanta, we plan to issue a call for > possible Charter updates and milestones adjustments. In the mean > time, we plan to bring the existing milestones up to date as shown > below: > > TRILL Milestones (ignoring those currently marked as Done) > ---------------------------------------------------------- > > First column is current date, second is new date (or "Done"). [Comment > in square brackets not part of milestone.] > > Mar 2011 Done Submit TRILL Header Options to IESG for > publication as Proposed Standard (draft-ietf-trill-rbridge-options) > [draft-ietf-trill-rbridge-extension in RFC Editor's queue.] > > Mar 2011 Done Initial WG draft on RBridge OAM > (draft-bond-trill-rbridge-oam) > > Mar 2011 Mar 2013 Initial WG draft on ARP/ND optimizations > [Potentially based on draft-dunbar-trill-scheme-for-directory-assist] > > Jun 2011 Jul 2013 Submit RBridge support of Data Center Bridging to > IESG for publication as Proposed Standard > (draft-eastlake-trill-rbridge-dcb) > > Jul 2012 Dec 2014 Re-charter or shut down the WG > > > > Finally we currently have one milestone item for > Jul 2011 Submit RBridge OAM to IESG for publication as > Proposed Standard > > But as things have evolved we will have several documents in the OAM > area. Thus we will replace the above one milestone with the > following set: I believe that all of the year's below need to be decremented by one... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Nov 2013 Submit RBridge OAM requirements document to IESG for publication > > Nov 2013 Initial WG framework document on RBridge OAM > > Jan 2014 Submit RBridge OAM framework document to the IESG for > publication > > Jan 2014 Initial WG document on RBridge OAM fault management > > Apr 2014 Initial WG document on RBridge OAM performance management > > --- > > Erik and Donald > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From liyizhou@huawei.com Mon Nov 5 08:15:07 2012 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 8CD9621F8A2F for ; Mon, 5 Nov 2012 08:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHVSBUROS3XD for ; Mon, 5 Nov 2012 08:15:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0268B21F8A1E for ; Mon, 5 Nov 2012 08:15:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AML18393; Mon, 05 Nov 2012 16:15:04 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 16:14:56 +0000 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 00:15:01 +0800 Received: from szxeml547-mbx.china.huawei.com ([169.254.5.218]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 00:14:55 +0800 From: Liyizhou To: Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] draft-mme-trill-fcoe as an independent submission Thread-Index: AQHNrN/3k4Psqu1wE0KrtymmjtB4H5fbhb7G Date: Mon, 5 Nov 2012 16:14:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.6] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [trill] draft-mme-trill-fcoe as an independent submission X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:15:07 -0000 SSBkaWQgbm90IHNlZSBhbnkgbmV3IHRoaW5nIHRvIGJlIHN0YW5kYXJkaXplZCBieSB0aGlzIGRy YWZ0IGZvciBUUklMTCBXRy4gDQpJIGFncmVlIHdpdGggc29tZSBwcmV2aW91cyByZXNwb25zZXMu IEluZGl2aWR1YWwgc3VibWlzc2lvbiBpcyBtb3JlIHJlYXNvbmFibGUgdGhhbiBXRyBhZG9wdGlv biBmb3IgdGhpcyBkcmFmdC4NCg0KDQpZaXpob3UNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCreivP7IyzogdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBbdHJpbGwtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBEb25hbGQgRWFzdGxha2UgW2QzZTNlM0BnbWFpbC5jb21dDQq3 osvNyrG85DogMjAxMsTqMTDUwjE4yNUgMTE6MjMNCrW9OiB0cmlsbEBpZXRmLm9yZw0K1vfM4jog W3RyaWxsXSBkcmFmdC1tbWUtdHJpbGwtZmNvZSBhcyBhbiBpbmRlcGVuZGVudCBzdWJtaXNzaW9u DQoNCkhpLA0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbWUtdHJp bGwtZmNvZS8gd2FzIGJyaWVmbHkNCnByZXNlbnRlZCB0byB0aGUgVFJJTEwgV0cgYXQgdGhlIFF1 ZWJlYyBDaXR5IElFVEYtODEgbWVldGluZy4gSSdsbA0KcGFzdGUgYW4gZXh0cmFjdCBmcm9tIHRo ZSBtaW51dGVzIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbC4NCg0KVGhlcmUgaGF2ZSBiZWVuIHRo cmVlIHJlZmVyZW5jZXMgdG8gdGhpcyBkcmFmdCBvbiB0aGUgVFJJTEwgV0cgbWFpbGluZw0KbGlz dCAoYmVmb3JlIHRoaXMgbWVzc2FnZSksIG5vbmUgb2Ygd2hpY2ggcHJvZHVjZWQgYW55IHJlc3Bv bnNlOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3RyaWxsL2N1cnJlbnQv bXNnMDE0NzMuaHRtbA0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3RyaWxs L2N1cnJlbnQvbXNnMDE0ODkuaHRtbA0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3RyaWxsL2N1cnJlbnQvbXNnMDE2NDMuaHRtbA0KDQpUaGUgZHJhZnQgaXMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZSBSRkMgSW5kZXBlbmRlbnQgU3VibWlzc2lvbnMgRWRpdG9yDQphbmQgaXMg YXdhaXRpbmcgYSBkZXRlcm1pbmF0aW9uIGJ5IHRoZSBJRVNHIGFzIHRvIHdoZXRoZXIgdGhlIGRy YWZ0DQpkb2VzIG9yIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggb25nb2luZyB3b3JrIGluIHRoZSBJ RVRGIHN1Y2ggYXMgdGhhdA0Kb2YgdGhlIFRSSUxMIFdHLiBCYXNlZCBvbiB0aGUgY3VycmVudCBz dGF0ZSBvZiB0aGUgSUVTRyBiYWxsdA0KKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2NvbmZsaWN0LXJldmlldy1tbWUtdHJpbGwtZmNvZS9iYWxsb3QvKSwNCkkgcmVxdWVzdCBmdXJ0 aGVyIFdHIGRpc2N1c3Npb24gb2Ygd2hldGhlciBvciBub3QgdGhpcyBkcmFmdCBzaG91bGQgYmUN CmEgVFJJTEwgV0cgZHJhZnQgYW5kIHdoZXRoZXIgb3Igbm90IGl0IGNvbmZsaWN0cyB3aXRoIHdv cmsgaW4gdGhlDQpUUklMTCBXRy4NCg0KVGhhbmtzLA0KRG9uYWxkDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAg KGNlbGwpDQogMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0KIGQzZTNl M0BnbWFpbC5jb20NCg0KDQpFeHRyYWN0IGZyb20gTWludXRlcyBvZiBUUklMTCBXRyBhdCBJRVRG LTgxOg0KDQpGQ29FIG92ZXIgVFJJTEwsIERhdmlkIE1lbG1hbiAoTWFydmVsbCksIFRhbCBNaXpy YWhpIChNYXJ2ZWxsKQ0KZHJhZnQtbW1lLXRyaWxsLWZjb2UtMDAudHh0DQoNCih2ZXJ5IGxpbWl0 ZWQgdGltZSBiZWNhdXNlIGVhcmxpZXIgcHJlc2VudGF0aW9ucyBhbmQgZGlzY3Vzc2lvbiByYW4N Cm92ZXIpDQoNClRhbCBNaXpyYWhpIChNYXJ2ZWxsKTogVGhpcyBkcmFmdCBpcyBpbnRlbmRlZCBm b3INCmluZm9ybWF0aW9uYWwuIC4uLiBzZWxlY3RlZCBzbGlkZXMgLi4uDQoNCkFub29wIEdoYW53 YW5pOiBBcmUgeW91IGNoYW5naW5nIHRoZSBUUklMTCBoZWFkZXIgaG9wLWJ5LWhvcC4NCg0KRG9u YWxkOiBUaGUgZnJhbWUgaXMgYmVpbmcgVFJJTEwgZW5jYXBzdWxhdGVkIGFuZCBkZWNhcHN1bGF0 ZWQgYXQgZWFjaA0KaG9wLg0KDQpBbm9vcDogU28gdGhlIFRSSUxMIEhlYWRlciBpc24ndCBkb2lu ZyBhbnl0aGluZy4gVGhlIHdob2xlIHBhdGggaXMNCmNvbXB1dGVkIGJ5IEZDU1AuIElmIHlvdSBh cmUgcnVubmluZyBib3RoIGNvbnRyb2wgcGxhbmVzLCB3aHkgaGF2ZSB0aGUNClRSSUxMIEhlYWRl ciBhdCBhbGwuDQoNClRhbDogVGhlcmUgaXMgYSBzbGlkZSBvbiB0aGF0OiBub3QgYWxsIFJCcmlk Z2VzIGFyZSBGQ1JCcy4gSW4gdGhhdA0KY2FzZSwgeW91IHN0aWxsIHdhbnQgdGhlIFRSSUxMIGNs b3VkcyB0byBkbyBvcHRpbWFsIHJvdXRpbmcuDQoNClB1bmVldCBBZ2Fyd2FsIChCcm9hZGNvbSk6 IEkgZG9uJ3Qgc2VlIHdoYXQgdGhpcyBkb2VzIG90aGVyIHRoYW4gc3RhdGUNCnRoZSBvYnZpb3Vz LiBGQ29FIGlzIHJ1bm5pbmcgb3ZlciBUUklMTC4gV2h5IGRvIHlvdSBuZWVkIGEgZHJhZnQgZm9y DQp0aGF0Pw0KDQpUYWw6IFdlIGFyZSBqdXN0IHNob3dpbmcgaG93IHRoZXkgd29yayB0b2dldGhl ci4NCg0KUHVuZWV0OiBTbywgc2hvdWxkIEkgZG8gYSBkcmFmdCBvbiBJUCByb3V0aW5nIG92ZXIg VFJJTEw/DQoNCkRvbmFsZDogSXQgaXMgYSBsaXR0bGUgZGlmZmVyZW50IGJlY2F1c2UgeW91IHdv dWxkIG5vcm1hbGx5IGhhdmUgdGhlDQpyb3V0ZXJzIGF0IHRoZSBlZGdlIGJ1dCBoZXJlIHlvdSBo YXZlIHRoZSBGaWJlciBDaGFubmVsIGRldmljZXMNCmRpc3RyaWJ1dGVkIHRocm91Z2hvdXQgdGhl IFRSSUxMIGNsb3VkIHdpdGggYSBzYXZpbmdzIGluIGNhYmxpbmcgYW5kDQpjYWJpbmV0cnkuIElm IHRoZSBGQyBpcyBleHRlcm5hbCB0byB0aGUgVFJJTEwgY2xvdWQsIHRoZW4gdHlwaWNhbGx5DQp5 b3UgaGF2ZSB0byB0cmFuc2l0IHRoZSBUUklMTCBjbG91ZCB0d2ljZS4gU28sIGl0IGlzIGEgd2F5 IG9mIGRvaW5nDQppdC4gSWYgeW91IHRoaW5rIHRoaXMgZHJhZnQgaGFzIG5vIHZhbHVlLCBzbyBi ZSBpdC4gSWYgdGhlIFdHIHRoaW5rcw0KdGhhdCB3YXksIHRoZW4gaXQgc2hvdWxkbid0IGJlIGEg d29ya2luZyBncm91cCBkcmFmdC4NCg0KUHVuZWV0OiBPSy4gSSBkb24ndCB0aGluayBpdCBzaG91 bGQgYmUgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KDQpEb25hbGQ6IFdlbGwsIHdlIGFyZSBvdXQg b2YgdGltZS4gVGhhbmtzIGV2ZXJ5b25lIGFuZCBzZWUgeW91IGluDQpUYWl3YW4uDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBs aXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmlsbA== From internet-drafts@ietf.org Mon Nov 5 12:34:05 2012 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 1239421F8675; Mon, 5 Nov 2012 12:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7dTZqfph0TZ; Mon, 5 Nov 2012 12:34:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A6021F858C; Mon, 5 Nov 2012 12:34:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105203402.9893.97000.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 12:34:02 -0800 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-oam-req-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:34:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : Requirements for Operations, Administration and Maintena= nce (OAM) in TRILL Author(s) : Tissa Senevirathne David Bond Sam Aldrin Yizhou Li Rohit Watve Filename : draft-ietf-trill-oam-req-03.txt Pages : 13 Date : 2012-11-05 Abstract: OAM (Operations, Administration and Maintenance) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents, OAM Requirements applicable to TRILL. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-oam-req There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-oam-req-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-oam-req-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Tue Nov 6 12:43:03 2012 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 EE60A21F89EE for ; Tue, 6 Nov 2012 12:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8z9KK7aQ8Q6 for ; Tue, 6 Nov 2012 12:43:03 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB1D21F8900 for ; Tue, 6 Nov 2012 12:43:03 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so672395iak.31 for ; Tue, 06 Nov 2012 12:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=7yq21TKgTr00LDzt1zXAhxGv9khOQB11VZcYt8iSM3Y=; b=mkJkKBxA4IqSr2kdit8RVETU3tJWDeN/MwP8WiQ6FAbu9bpG5GAkpmnXsRezOhLMsk nX0X7pVZA9cgsQsTLakP+kAXGyeppjDtCURT+3EyQeeBS8c9EES52sjIdvkSTPRyFmBx OCrMZUmPS/F00XagfjnWmrKhY09lGuO4rzvpxn+r+UwNEeP+9Xqp32+unoo6ymQiupsn 35GzrOhIFvpNLVrH9A2QVMK65Jf3YEq/AlYvxllQRVkSnvbx7dJHDSk+tmVx+H3lcH0I FOKnYJHDoesouCIfQ0ZD2/P9khAczfZm3VX4ayRC73UD3b2mnaBr841TUNkoOxcHuxGH UVYA== Received: by 10.42.97.74 with SMTP id m10mr2147003icn.42.1352234582924; Tue, 06 Nov 2012 12:43:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Tue, 6 Nov 2012 12:42:42 -0800 (PST) From: Donald Eastlake Date: Tue, 6 Nov 2012 15:42:42 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:43:04 -0000 Hi, As announced at the TRILL WG meeting today, this starts a two week WG Last Call on draft-ietf-trill-fine-labeling ending 19 November. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From ghanwani@gmail.com Tue Nov 6 14:39:48 2012 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 781E121F8B86 for ; Tue, 6 Nov 2012 14:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GfrWi0p0tuC for ; Tue, 6 Nov 2012 14:39:47 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8222021F8A60 for ; Tue, 6 Nov 2012 14:39:47 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1026904vbb.31 for ; Tue, 06 Nov 2012 14:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4ABeZvqO+hAXy5jktU16GpUUEOdGNLEvoQnZqbB3cws=; b=oZ7MFi+4USXTBLqSi2u+kpTwx4i6shIQMExKi2nDsRz/cXU8/C8FPrxc4h6617kTof UZGqlLuFPfYw8oH84mDQAHQyDu/jafFVE/vSf8g1P8r2g+HFL4Q2Yk8I7nO6smKuRQGy Vq2fdTwLwf7xDSck4Kmzm9dAMxPM8E54GDv2067OsXw3N++5gtdpC8irvWk43ppbdXwZ IzW/ZEGipWNeC7L+GSzmDFpvSvthBMvFPBzEgXMEif1+baQQ6IR6701m9vvXLdfecN4Y xMLspmtOvDUiMeiYVcRbrBH2F/7R/zZ5XndFY0vPq+agoyKfBw7vWP4KRoRWzxBegGK/ zDHw== MIME-Version: 1.0 Received: by 10.58.249.201 with SMTP id yw9mr2496921vec.10.1352241585410; Tue, 06 Nov 2012 14:39:45 -0800 (PST) Sender: ghanwani@gmail.com Received: by 10.220.143.73 with HTTP; Tue, 6 Nov 2012 14:39:45 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645089230@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F645089230@dfweml505-mbx> Date: Tue, 6 Nov 2012 14:39:45 -0800 X-Google-Sender-Auth: Ll7985zBor2QXCqDSZamXH4N4EA Message-ID: From: Anoop Ghanwani To: Linda Dunbar Content-Type: multipart/alternative; boundary=047d7bacc07e59528904cddb479b Cc: "trill@ietf.org" Subject: Re: [trill] FW: New Version Notification for draft-dunbar-trill-scheme-for-directory-assist-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:39:48 -0000 --047d7bacc07e59528904cddb479b Content-Type: text/plain; charset=ISO-8859-1 I think the draft would benefit from having a section that discussed the implications of this mechanism on the forwarding plane. When directory-assisted forwarding is in use, what happens if there is a miss. I think there are 3 options for that: (a) Discard the packet (because we're supposed to know where everything is, a priori); (b) Punt the packet to the control plane so that the control plane can "pull" the necessary directory entry and discard the frame if the "pull" fails; (c) Flood the frame. My guess is that there are scenarios where all 3 of these would make sense and it would be good to have a description of these in the draft. Anoop On Tue, Oct 23, 2012 at 9:32 AM, Linda Dunbar wrote: > TRILL WG, > > Here is a draft describing the detailed mechanism to achieve Directory > Service for TRILL. We are proposing to re-use ESADI mechanism for directory > servers to distribute mapping information. Your comments and suggestions > are greatly appreciated. > > Thanks, Linda > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 22, 2012 12:12 PM > To: Linda Dunbar > Cc: d3e3e3@gmail.com; radia@alum.mit.edu; Liyizhou; igor@yahoo-inc.com > Subject: New Version Notification for > draft-dunbar-trill-scheme-for-directory-assist-03.txt > > > A new version of I-D, draft-dunbar-trill-scheme-for-directory-assist-03.txt > has been successfully submitted by Linda Dunbar and posted to the > IETF repository. > > Filename: draft-dunbar-trill-scheme-for-directory-assist > Revision: 03 > Title: Mechanisms for Directory Assisting TRILL > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-dunbar-trill-scheme-for-directory-assist-03.txt > Status: > http://datatracker.ietf.org/doc/draft-dunbar-trill-scheme-for-directory-assist > Htmlized: > http://tools.ietf.org/html/draft-dunbar-trill-scheme-for-directory-assist-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-dunbar-trill-scheme-for-directory-assist-03 > > Abstract: > This draft describes the mechanisms of using directory server(s) to > assist TRILL (Transparent Interconnection of Lots of Links) edge > switches in reducing ARP/ND and unknown unicast flooding across > TRILL domain in data center environment. > > Conventions used in this document > > The term ''Subnet'' and ''VLAN'' are used interchangeably in this > document because it is common to map one subnet to one VLAN. The > term ''TRILL switch'' and ''RBridge'' are used interchangeably in this > document. > > > > The IETF Secretariat > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --047d7bacc07e59528904cddb479b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the draft would benefit from having a section that discussed
th= e implications of this mechanism on the forwarding plane. =A0When
directory-assisted forwarding is in use, what happens if there is a miss.<= /div>
I think there are 3 options for that:

(a) Dis= card the packet (because we're supposed to know where everything
<= div>is, a priori);

(b) Punt the packet to the cont= rol plane so that the control plane can "pull"
the necessary directory entry and discard the frame if the "pull&= quot; fails;

(c) Flood the frame.

My guess is that there are scenarios where all 3 of these would ma= ke=A0
sense and it would be good to have a description of these in the draft= .

Anoop

O= n Tue, Oct 23, 2012 at 9:32 AM, Linda Dunbar <linda.dunbar@huawei.c= om> wrote:
TRILL WG,

Here is a draft describing the detailed mechanism to achieve Directory Serv= ice for TRILL. We are proposing to re-use ESADI mechanism for directory ser= vers to distribute mapping information. Your comments and suggestions are g= reatly appreciated.

Thanks, Linda

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, October 22, 2012 12:12 PM
To: Linda Dunbar
Cc: d3e3e3@gmail.com; radia@alum.mit.edu; Liyizhou; igor@yahoo-inc.com
Subject: New Version Notification for draft-dunbar-trill-scheme-for-directo= ry-assist-03.txt


A new version of I-D, draft-dunbar-trill-scheme-for-directory-assist-03.txt=
has been successfully submitted by Linda Dunbar and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dunbar-trill-scheme-for-directory-assist
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 Mechanisms for Directory Assisting TRILL
Creation date: =A0 2012-10-22
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 13
URL: =A0 =A0 =A0 =A0 =A0 =A0 h= ttp://www.ietf.org/internet-drafts/draft-dunbar-trill-scheme-for-directory-= assist-03.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatra= cker.ietf.org/doc/draft-dunbar-trill-scheme-for-directory-assist
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.= org/html/draft-dunbar-trill-scheme-for-directory-assist-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-dunbar-trill-scheme-for-directory-assist= -03

Abstract:
=A0 =A0This draft describes the mechanisms of using directory server(s) to<= br> =A0 =A0assist TRILL (Transparent Interconnection of Lots of Links) edge
=A0 =A0switches in reducing ARP/ND and unknown unicast flooding across
=A0 =A0TRILL domain in data center environment.

Conventions used in this document

=A0 =A0The term ''Subnet'' and ''VLAN'' are= used interchangeably in this
=A0 =A0document because it is common to map one subnet to one VLAN. The
=A0 =A0term ''TRILL switch'' and ''RBridge''= ; are used interchangeably in this
=A0 =A0document.



The IETF Secretariat

_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--047d7bacc07e59528904cddb479b-- From linda.dunbar@huawei.com Tue Nov 6 15:09:21 2012 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 5A55821F8BBA for ; Tue, 6 Nov 2012 15:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ43++Czupuy for ; Tue, 6 Nov 2012 15:09:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE821F8BB6 for ; Tue, 6 Nov 2012 15:09:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMM29063; Tue, 06 Nov 2012 23:09:17 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 23:09:07 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 07:09:16 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 15:09:10 -0800 From: Linda Dunbar To: Anoop Ghanwani Thread-Topic: [trill] FW: New Version Notification for draft-dunbar-trill-scheme-for-directory-assist-03.txt Thread-Index: AQHNvG+kmnaYOz9QLkugT9TjeHuBx5fdbgHA Date: Tue, 6 Nov 2012 23:09:10 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F64509396E@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F645089230@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.241] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F64509396Edfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] FW: New Version Notification for draft-dunbar-trill-scheme-for-directory-assist-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:09:21 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F64509396Edfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anoop, Thank you very much for the suggestion. Radia had similar suggestion, i.e. = RBridge needs to have the policy to drop packet ( or flood the packet) if t= he Directory doesn't have the Egress RBridge information for the Target. We will add it to the next revision. Linda From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop Gha= nwani Sent: Tuesday, November 06, 2012 5:40 PM To: Linda Dunbar Cc: trill@ietf.org Subject: Re: [trill] FW: New Version Notification for draft-dunbar-trill-sc= heme-for-directory-assist-03.txt I think the draft would benefit from having a section that discussed the implications of this mechanism on the forwarding plane. When directory-assisted forwarding is in use, what happens if there is a miss. I think there are 3 options for that: (a) Discard the packet (because we're supposed to know where everything is, a priori); (b) Punt the packet to the control plane so that the control plane can "pul= l" the necessary directory entry and discard the frame if the "pull" fails; (c) Flood the frame. My guess is that there are scenarios where all 3 of these would make sense and it would be good to have a description of these in the draft. Anoop On Tue, Oct 23, 2012 at 9:32 AM, Linda Dunbar > wrote: TRILL WG, Here is a draft describing the detailed mechanism to achieve Directory Serv= ice for TRILL. We are proposing to re-use ESADI mechanism for directory ser= vers to distribute mapping information. Your comments and suggestions are g= reatly appreciated. Thanks, Linda -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, October 22, 2012 12:12 PM To: Linda Dunbar Cc: d3e3e3@gmail.com; radia@alum.mit.edu; Liyizhou; igor@yahoo-inc.com Subject: New Version Notification for draft-dunbar-trill-scheme-for-directo= ry-assist-03.txt A new version of I-D, draft-dunbar-trill-scheme-for-directory-assist-03.txt has been successfully submitted by Linda Dunbar and posted to the IETF repository. Filename: draft-dunbar-trill-scheme-for-directory-assist Revision: 03 Title: Mechanisms for Directory Assisting TRILL Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-dunbar-trill-sch= eme-for-directory-assist-03.txt Status: http://datatracker.ietf.org/doc/draft-dunbar-trill-scheme-= for-directory-assist Htmlized: http://tools.ietf.org/html/draft-dunbar-trill-scheme-for-d= irectory-assist-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-dunbar-trill-sche= me-for-directory-assist-03 Abstract: This draft describes the mechanisms of using directory server(s) to assist TRILL (Transparent Interconnection of Lots of Links) edge switches in reducing ARP/ND and unknown unicast flooding across TRILL domain in data center environment. Conventions used in this document The term ''Subnet'' and ''VLAN'' are used interchangeably in this document because it is common to map one subnet to one VLAN. The term ''TRILL switch'' and ''RBridge'' are used interchangeably in this document. The IETF Secretariat _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --_000_4A95BA014132FF49AE685FAB4B9F17F64509396Edfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anoop,

 <= /p>

Thank you very much for t= he suggestion. Radia had similar suggestion, i.e. RBridge needs to have the= policy to drop packet ( or flood the packet) if the Directory doesn’t have the Egress RBridge information for the Target.

 <= /p>

We will add it to the nex= t revision.

 <= /p>

Linda

 <= /p>

From: ghanwani= @gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop Ghanwani
Sent: Tuesday, November 06, 2012 5:40 PM
To: Linda Dunbar
Cc: trill@ietf.org
Subject: Re: [trill] FW: New Version Notification for draft-dunbar-t= rill-scheme-for-directory-assist-03.txt

 

I think the draft would benefit from having a sectio= n that discussed

the implications of this mechanism on the forwarding= plane.  When

directory-assisted forwarding is in use, what happen= s if there is a miss.

I think there are 3 options for that:

 

(a) Discard the packet (because we're supposed to kn= ow where everything

is, a priori);

 

(b) Punt the packet to the control plane so that the= control plane can "pull"

the necessary directory entry and discard the frame = if the "pull" fails;

 

(c) Flood the frame.

 

My guess is that there are scenarios where all 3 of = these would make 

sense and it would be good to have a description of = these in the draft.

 

Anoop

 

On Tue, Oct 23, 2012 at 9:32 AM, Linda Dunbar <linda.dunbar@hua= wei.com> wrote:

TRILL WG,

Here is a draft describing the detailed mechanism to achieve Directory Serv= ice for TRILL. We are proposing to re-use ESADI mechanism for directory ser= vers to distribute mapping information. Your comments and suggestions are g= reatly appreciated.

Thanks, Linda

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, October 22, 2012 12:12 PM
To: Linda Dunbar
Cc: d3e3e3@gmail.com; radia@alum.mit.edu; Liyizhou; igo= r@yahoo-inc.com
Subject: New Version Notification for draft-dunbar-trill-scheme-for-directo= ry-assist-03.txt


A new version of I-D, draft-dunbar-trill-scheme-for-directory-assist-03.txt=
has been successfully submitted by Linda Dunbar and posted to the
IETF repository.

Filename:        draft-dunbar-trill-scheme-for-director= y-assist
Revision:        03
Title:           Mechanisms for Directory Assistin= g TRILL
Creation date:   2012-10-22
WG ID:           Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-dunbar-trill-scheme-for-directory= -assist-03.txt
Status:          http://datatracker.ietf.org/doc/draft-dunbar-trill-scheme-for-directory-as= sist
Htmlized:        http:/= /tools.ietf.org/html/draft-dunbar-trill-scheme-for-directory-assist-03<= br> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-dunbar-trill-scheme-fo= r-directory-assist-03

Abstract:
   This draft describes the mechanisms of using directory server(= s) to
   assist TRILL (Transparent Interconnection of Lots of Links) ed= ge
   switches in reducing ARP/ND and unknown unicast flooding acros= s
   TRILL domain in data center environment.

Conventions used in this document

   The term ''Subnet'' and ''VLAN'' are used interchangeably in t= his
   document because it is common to map one subnet to one VLAN. T= he
   term ''TRILL switch'' and ''RBridge'' are used interchangeably= in this
   document.



The IETF Secretariat

_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 

--_000_4A95BA014132FF49AE685FAB4B9F17F64509396Edfweml505mbx_-- From ghanwani@gmail.com Tue Nov 6 15:09:51 2012 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 8F4DA21F8BB6 for ; Tue, 6 Nov 2012 15:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kop4ZF6Qn7If for ; Tue, 6 Nov 2012 15:09:51 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C96C721F8BBA for ; Tue, 6 Nov 2012 15:09:50 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so1035044vcb.31 for ; Tue, 06 Nov 2012 15:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=JlAUNQMlzotx69z088/xnH9xjWHVWQg4VH2q7YZYRqw=; b=CjR3JeDU0wJDQW0mWmzgmTubx7Uc7o+OwrEtObQF31bBQYTHFzKIktf6b+436vdLGr KjQEsXF2q7H+3FulFRUdQtJ6wx1MxkO/GEAYSq/RSyCxGlWP5BmR30rWeYMZ1QCTX2D2 Wg/stwXKxZSwt1o0vc9CYZVlzPJbXM3L0w1tT3AUHhv0Etrz9TYpB31kOwwek+gnak0c tY4gqIPiAhcg+S12YCJJfbpvdahiwOQzcAstUNWeA5sVAtbK/07MiHQ5eucioe5KI9ir EXRCKSAV33JVZOPLOHdaLi5/yowaWO0EnHpVVBdDc7MaOkrMx1QJxRXw81BC/O4L21GU 9Bog== MIME-Version: 1.0 Received: by 10.58.137.229 with SMTP id ql5mr2571202veb.11.1352243390316; Tue, 06 Nov 2012 15:09:50 -0800 (PST) Sender: ghanwani@gmail.com Received: by 10.220.143.73 with HTTP; Tue, 6 Nov 2012 15:09:50 -0800 (PST) Date: Tue, 6 Nov 2012 15:09:50 -0800 X-Google-Sender-Auth: Eyea-gHo8ZsDQK9IOgEJtubitcs Message-ID: From: Anoop Ghanwani To: trill@ietf.org Content-Type: multipart/alternative; boundary=047d7b677816edff9e04cddbb2ab Subject: [trill] MD-levels and TRILL X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:09:51 -0000 --047d7b677816edff9e04cddbb2ab Content-Type: text/plain; charset=ISO-8859-1 There are a couple of challenges that I see with trying to define the use of MD-levels with TRILL. MD-levels in the IEEE world were used to creates multiple levels at which CFM can be run. For example, if I buy a service from a provider and start running CFM, only my boxes (my network and the edges of the provider network) will see and respond to those CFM messages. Maybe this type of service model doesn't make sense for TRILL because, if the provider implements the transport using RBridges, then the customer and provider will have to make sure they assign their nicknames from the same space. But let's leave that issue aside for now... The first challenge is that TRILL depends on the Hop Count for some of the OAM messages to decide whether they are processed by an RBridge. This means that it is not possible to send these messages in a way that is transparent to set of RBridges. So pretty much all OAM messages must be processed by all RBridges along a path regardless of level. So I'm not sure what the concept of MD-level would buy us. At best it may be used for filtering and that too in the control plane, but I personally don't see much value there. The second challenge is related to accessing the MD-level withing the frame to know whether or not to process it. Because the MD-level would follow the 128-byte entropy, I am not sure that existing silicon, and maybe even emerging silicon, will be able to access those bits, so that level of filtering may have to be done in software. I think this should be clearly called out in the draft. Anoop --047d7b677816edff9e04cddbb2ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

There are a couple of challenges that I see with trying= to
define the use of MD-levels with TRILL.

<= div>MD-levels in the IEEE world were used to creates multiple
levels at which CFM can be run. =A0For example, if I buy a service from a= =A0
provider and start running CFM, only my boxes (my network and= =A0
the edges of the provider network) will see and respond to th= ose
CFM messages. =A0Maybe this type of service model doesn't
make sense for TRILL because, if the provider implements
the tr= ansport using RBridges, then the customer and provider
will have = to make sure they assign their nicknames from the
same space. =A0But let's leave that issue aside for now...

The first challenge is that TRILL depends on the Hop Coun= t=A0
for some of the OAM messages to decide whether they are=A0
processed by an RBridge. =A0This means that it is not possible
to send these messages in a way that is transparent to
set of = RBridges. =A0So pretty much all OAM messages must
be processed by= all RBridges along a path regardless of=A0
level. =A0So I'm not sure what the concept of MD-level would
=
buy us. =A0At best it may be used for filtering and that too in
<= div>the control plane, but I personally don't see much value there.

The second challenge is related to accessing the MD-lev= el
withing the frame to know whether or not to process it.
<= div>Because the MD-level would follow the 128-byte entropy,=A0
I am not sure that existing silicon, and maybe even emerging
sili= con, will be able to access those bits, so that level of=A0
filte= ring may have to be done in software. =A0I think this should
be c= learly called out in the draft.

Anoop
--047d7b677816edff9e04cddbb2ab-- From nordmark@acm.org Thu Nov 8 07:47:51 2012 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 9FA2C21F89FE for ; Thu, 8 Nov 2012 07:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+XYG1AI2lQu for ; Thu, 8 Nov 2012 07:47:51 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7B921F894E for ; Thu, 8 Nov 2012 07:47:51 -0800 (PST) Received: from [10.21.87.13] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qA8FlkUm014268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 07:47:48 -0800 Message-ID: <509BD422.6000707@acm.org> Date: Thu, 08 Nov 2012 07:47:46 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "trill@ietf.org" References: <509BD3E4.4020407@sonic.net> In-Reply-To: <509BD3E4.4020407@sonic.net> X-Forwarded-Message-Id: <509BD3E4.4020407@sonic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] FYI: there is claimed IPR on draft-ietf-trill-fine-labeling X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:47:51 -0000 I just noticed there is some claimed IPR listed at https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-trill-fine-labeling I just wanted to make sure the WG is aware of that fact. If anybody has questions about how a WG should consider where there is IPR, please review http://www.ietf.org/rfc/rfc3979.txt Erik From internet-drafts@ietf.org Thu Nov 8 10:14:58 2012 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 D55E121F873F; Thu, 8 Nov 2012 10:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnLCF-f1vdb3; Thu, 8 Nov 2012 10:14:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667A921F876D; Thu, 8 Nov 2012 10:14:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121108181458.19202.46828.idtracker@ietfa.amsl.com> Date: Thu, 08 Nov 2012 10:14:58 -0800 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-oam-framework-00.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:14:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : TRILL OAM Framework Author(s) : Samer Salam Tissa Senevirathne Sam Aldrin Donald Eastlake Filename : draft-ietf-trill-oam-framework-00.txt Pages : 24 Date : 2012-11-08 Abstract: This document specifies a reference framework for Operations, Administration and Maintenance (OAM) in TRILL networks. The focus of the document is on the fault and performance management aspects of TRILL OAM. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-oam-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Nov 8 16:13:28 2012 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 A3ACE21F8738; Thu, 8 Nov 2012 16:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWXaEWk6oAAL; Thu, 8 Nov 2012 16:13:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A2D21F855E; Thu, 8 Nov 2012 16:13:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121109001328.20789.51125.idtracker@ietfa.amsl.com> Date: Thu, 08 Nov 2012 16:13:28 -0800 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-cmt-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 00:13:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : Coordinated Multicast Trees (CMT) for TRILL Author(s) : Tissa Senevirathne Janardhanan Pathangi Jon Hudson Filename : draft-ietf-trill-cmt-01.txt Pages : 14 Date : 2012-11-08 Abstract: TRILL facilitates loop free connectivity to non-TRILL legacy networks via choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarder provides VLAN level load sharing with active- standby model. Mission critical operations such as High Performance Data Centers require active-active load sharing model. Active-Active load sharing model can be accomplished by representing any given non-TRILL legacy network with a single virtual RBridge. Virtual representation of the non-TRILL legacy network with a single RBridge poses serious challenges in multi-destination RPF calculations. This document presents the required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT provides flexibility to RBridges to select desired path of association to a given distribution tree. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-cmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-cmt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-cmt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tsenevir@cisco.com Thu Nov 8 16:51:38 2012 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 3834521F8957 for ; Thu, 8 Nov 2012 16:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQExnUiQv-KO for ; Thu, 8 Nov 2012 16:51:37 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE021F8755 for ; Thu, 8 Nov 2012 16:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1524; q=dns/txt; s=iport; t=1352422297; x=1353631897; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+h1lH/GBd3dv9Lu9LcZd2DDMz9LURSphtBqxl3ivF1E=; b=DddHYTVeuUZ2cWTvxI4tVXmVLKugdZ60uwUxhadt96dOgyrna8RVar7Q gnIVX/icK17qJynMZbAzbQApuXdONOSmuKP+w5VZM8O29L6dYRCp1jgHA DIssanOzZ2R+tmhdu/JdxE/67YaPF6r9kD0Hs5oxMdNeh/oF72nEhSqq/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUHAD9SnFCtJXG9/2dsb2JhbABEhhi8OnCBAQeCHgEBAQQSARARUQYBGQQBAQMCBh0DAgQwFAEICQEEEwgBGYdoC5sPgSuNJZJ9gSCKcoU0MmEDkkmETo08gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,741,1344211200"; d="scan'208";a="140409900" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 09 Nov 2012 00:51:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA90pbnp007511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 9 Nov 2012 00:51:37 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 18:51:36 -0600 From: "Tissa Senevirathne (tsenevir)" To: "trill@ietf.org" Thread-Topic: draft-ietf-trill-cmt Thread-Index: Ac2+FF0H+VMAhVydQOe90fdycFINlg== Date: Fri, 9 Nov 2012 00:51:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.167.166] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--27.482600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 00:51:38 -0000 ZHJhZnQtaWV0Zi10cmlsbC1jbXQtMDEgaGFzIGJlZW4gc3VibWl0dGVkLiBUaGlzIGFkZHJlc3Nl cyBjb21tZW50cyBhbmQgZmVlZGJhY2sgcmVjZWl2ZWQgYXMgcGFydCBvZiB0aGUgbGFzdCBjYWxs Lg0KDQpDbXQgZHJhZnQgc3BlY2lmaWNhbGx5IGFkZHJlc3MgdGhlIFJQRiBpc3N1ZXMgYXQgdGhl IGFjdGl2ZS1hY3RpdmUgZWRnZS4NCg0KRmFpbHVyZSBzY2VuYXJpb3MgYW5kIHJlY292ZXJ5IGZy b20gY29uZmlndXJhdGlvbnMgZXJyb3JzIGV0YyBhcmUgYWRkcmVzc2VkIGluIGRyYWZ0LWh1LXRy aWxsLXBzZXVkb25vZGUtbmlja25hbWUgYW5kDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvODUvc2xpZGVzL3NsaWRlcy04NS10cmlsbC03LnBwdHgNCg0KVGhhbmtzDQpUaXNzYQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBU b29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBOb3Zl bWJlciAwOCwgMjAxMiA0OjEzIFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikN ClN1YmplY3Q6IENvbmZpcm1hdGlvbiBmb3IgQXV0by1Qb3N0IG9mIEktRCBkcmFmdC1pZXRmLXRy aWxsLWNtdA0KDQoNCkhpLA0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBkcmFmdCBzdWJtaXNzaW9u IHNlcnZpY2UgaGFzIHJlY2VpdmVkIHlvdXIgZHJhZnQgZHJhZnQtaWV0Zi10cmlsbC1jbXQtMDEs IGFuZCByZXF1aXJlcyBhIGNvbmZpcm1hdGlvbiBzdGVwIGluIG9yZGVyIHRvIGJlIGFibGUgdG8g Y29tcGxldGUgdGhlIHBvc3Rpbmcgb2YgdGhlIGRyYWZ0Lg0KDQpQbGVhc2UgZm9sbG93IHRoaXMg bGluayB0byB0aGUgcGFnZSB3aGVyZSB5b3UgY2FuIGNvbmZpcm0gdGhlIHBvc3Rpbmc6DQpDb25m aXJtYXRpb24gVVJMOiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc3VibWl0L3N0YXR1cy80 NjM3NS9jb25maXJtLzVhNzMzOWY4YmMxZDAyZmJhYjk0MWZjOWU5NmFiZGM1NTcxMTMyN2MvDQoN Cg0KQmVzdCByZWdhcmRzLA0KDQoJVGhlIElFVEYgU2VjcmV0YXJpYXQNCgl0aHJvdWdoIHRoZSBk cmFmdCBzdWJtaXNzaW9uIHNlcnZpY2UNCg0KDQo= From ietf@meetecho.com Fri Nov 9 09:06:55 2012 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 E716321F8780 for ; Fri, 9 Nov 2012 09:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-1.470, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAUE9AmostXj for ; Fri, 9 Nov 2012 09:06:54 -0800 (PST) Received: from smtpdg8.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id 141F521F877B for ; Fri, 9 Nov 2012 09:06:53 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV6q1k00k0ELJoa01V6rvF; Fri, 09 Nov 2012 18:06:51 +0100 Message-ID: <509D3828.4000801@meetecho.com> Date: Fri, 09 Nov 2012 18:06:48 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Meetecho session recording X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:06:56 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From d3e3e3@gmail.com Sat Nov 10 18:12:59 2012 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 3545521F8887 for ; Sat, 10 Nov 2012 18:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTpN8voMo-2N for ; Sat, 10 Nov 2012 18:12:58 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88F7221F88BF for ; Sat, 10 Nov 2012 18:12:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so8410169iec.31 for ; Sat, 10 Nov 2012 18:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cxuxhh9j1l2WK3sIllDl/yxd9WXSacKIoNEL1+In2Lw=; b=DtpRQP2oY3imLRx1sCthRZE0pacjSuhT79c8pHBIgbGSrHJu6hd6oW1QDvP5cCePsE L7cqYg6OnGCv9n+LrYOVrsBlA/FpMufCcFIoK6+CLxaarTs52dZkOfdiCOJKpPQyojxY /MA96NiGjlF/kfbbDiehuauLpc3LvW70p4rMGPA3cuvStDK3AQSuhDOjps/nZeg25M9P KWwQz/sxkANMhrxIhyPseDgN5yRm0OltH7aFUh2aIqNMhCjg8fgMRwB/XMgYsL3+Bvub 2GNHdq5HE07BGVCO0KMhZBHT0naPfpcgRbWDVG/R0KGSFTf8O/LbmAqfX6DpTbf1+Jtr 9cGQ== Received: by 10.50.0.179 with SMTP id 19mr4080237igf.59.1352599978212; Sat, 10 Nov 2012 18:12:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Sat, 10 Nov 2012 18:07:06 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Sat, 10 Nov 2012 21:07:06 -0500 Message-ID: To: Anoop Ghanwani Content-Type: text/plain; charset=ISO-8859-1 Cc: trill@ietf.org Subject: Re: [trill] MD-levels and TRILL X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 02:12:59 -0000 Hi Anoop, On Tue, Nov 6, 2012 at 6:09 PM, Anoop Ghanwani wrote: > > There are a couple of challenges that I see with trying to > define the use of MD-levels with TRILL. I agree that there is still design work to be done. > MD-levels in the IEEE world were used to creates multiple > levels at which CFM can be run. For example, if I buy a service from a > provider and start running CFM, only my boxes (my network and > the edges of the provider network) will see and respond to those > CFM messages. Maybe this type of service model doesn't > make sense for TRILL because, if the provider implements > the transport using RBridges, then the customer and provider > will have to make sure they assign their nicknames from the > same space. But let's leave that issue aside for now... Generally I would expect provider facilities to be transparent to customer TRILL OAM. I can see reasons for 3, possibly 4, different levels within the customer TRILL level. First of all, there is multi-level IS-IS which would yield two levels, traditionally called level 1 and level 2. Then there are ideas like that in draft-wu-trill-lsp-ext-tree-distr-opt which could produce sub-areas within a level 1 area which we might call level 0. Then there are idea like that in draft-ietf-l2vpn-trill-evpn which could lead to a level above level 2, which you could call level 3. Of course, if you were using the MD-leels, you could map these into different numbers in the range 0 to 7. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > The first challenge is that TRILL depends on the Hop Count > for some of the OAM messages to decide whether they are > processed by an RBridge. This means that it is not possible > to send these messages in a way that is transparent to > set of RBridges. So pretty much all OAM messages must > be processed by all RBridges along a path regardless of > level. So I'm not sure what the concept of MD-level would > buy us. At best it may be used for filtering and that too in > the control plane, but I personally don't see much value there. > > The second challenge is related to accessing the MD-level > within the frame to know whether or not to process it. > Because the MD-level would follow the 128-byte entropy, > I am not sure that existing silicon, and maybe even emerging > silicon, will be able to access those bits, so that level of > filtering may have to be done in software. I think this should > be clearly called out in the draft. > > Anoop From eric.gray@ericsson.com Tue Nov 13 15:34:47 2012 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 910F721F8793 for ; Tue, 13 Nov 2012 15:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH+TUpalfwRs for ; Tue, 13 Nov 2012 15:34:46 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A32FD21F87B1 for ; Tue, 13 Nov 2012 15:34:46 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qADNYbt9008558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Nov 2012 17:34:37 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 13 Nov 2012 18:34:36 -0500 Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Tue, 13 Nov 2012 18:34:36 -0500 From: Eric Gray To: Donald Eastlake Thread-Topic: http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 Thread-Index: Ac3B9gCpGTa47RLBQBucEqzXOu6v9Q== Date: Tue, 13 Nov 2012 23:34:35 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF601B20A@EUSAAMB107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF601B20AEUSAAMB107ericsso_" MIME-Version: 1.0 Cc: "Ralph Droms \(rdroms.ietf@gmail.com\)" , TRILL Working Group Subject: [trill] http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:34:47 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF601B20AEUSAAMB107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Donald, I am confused about something. During the TRILL WG meeting, I believe we had a consensus o= f the room to adopt the draft "draft-salam-trill-oam-framework" as a working group dra= ft. It is the case that a "consensus of the room" is not suffic= ient to conclude working group consensus has been achieved. The room consensus needs to be confirmed on the mailing list - usually with a one or two week poll. Yet draft-salam-trill-oam-framework has been posted as a wo= rking group draft (under the name shown in the subject line of this message). I have looked though my mail and do not see an announcement= of any such poll for consensus Did the poll confirming the sense of the room happen, or ha= ve we had a bit of a slip-up? -- Eric --_000_48E1A67CB9CA044EADFEAB87D814BFF601B20AEUSAAMB107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Donald,

 

        &nbs= p;       I am confused about something.<= /o:p>

 

        &nbs= p;       During the TRILL WG meeting, I belie= ve we had a consensus of the room

to adopt the draft "draft-salam-trill-oam-frame= work" as a working group draft.

 

        &nbs= p;       It is the case that a "consensu= s of the room" is not sufficient to conclude

working group consensus has been achieved.  The= room consensus needs to be

confirmed on the mailing list – usually with a= one or two week poll.

 

        &nbs= p;       Yet draft-salam-trill-oam-framework = has been posted as a working group

draft (under the name shown in the subject line of t= his message).

 

        &nbs= p;       I have looked though my mail and do = not see an announcement of any

such poll for consensus

 

        &nbs= p;       Did the poll confirming the sense of= the room happen, or have we had

a bit of a slip-up?

 

--

Eric

--_000_48E1A67CB9CA044EADFEAB87D814BFF601B20AEUSAAMB107ericsso_-- From d3e3e3@gmail.com Tue Nov 13 15:41:37 2012 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 0C66921F8540 for ; Tue, 13 Nov 2012 15:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdglgPqtirtG for ; Tue, 13 Nov 2012 15:41:36 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C44E21F853B for ; Tue, 13 Nov 2012 15:41:35 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so12846250iec.31 for ; Tue, 13 Nov 2012 15:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jAmnV09Vbw1HFoqGQ+YmQszXc5yJ/5Jn+ETD/jccID8=; b=JBilwDWroMtdxLNWwhrE6JUV4zUFD50ihkAflL+NkyD7hRN/O0Q4hbGP/rX8+j+Cjc i1ETt/1kUxt9K/tunWeOxe7OyOF3YRtvAsNjWr3J4XyXRY63zHKUyBlaG4kNH+MwSmtj zKf37qUfdj65/Jg+ymKYhWwbePv4xu+8j6Kpx4nYsb/1MKWHmYEi7Fi6yU9AXzQfZsV8 oE2YwvA9zoK9jsXyBHXLvplxbBLoq5SRj0TdSwfFqFBeJmmNG3dtlfYwGPRupQtzObp4 WgPvXjckBv2GdQecMewxgwshOuIk6z/FmAjuWs87FMTY364TPsJHOit9gUhT/8f+sygA PhTQ== Received: by 10.50.0.179 with SMTP id 19mr87040igf.59.1352850093973; Tue, 13 Nov 2012 15:41:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Tue, 13 Nov 2012 15:41:13 -0800 (PST) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF601B20A@EUSAAMB107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF601B20A@EUSAAMB107.ericsson.se> From: Donald Eastlake Date: Tue, 13 Nov 2012 18:41:13 -0500 Message-ID: To: Eric Gray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Ralph Droms \(rdroms.ietf@gmail.com\)" , TRILL Working Group Subject: Re: [trill] http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:41:37 -0000 Hi Eric, The call by the Chairs to make this OAM framework draft a WG draft was issued here http://www.ietf.org/mail-archive/web/trill/current/msg05348.html Technically, I could argue that there was no need to wait until the WG meeting before making a determination but we did so the consensus in the room merely ratified the consensus on the mailing 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Nov 13, 2012 at 6:34 PM, Eric Gray wrote: > Donald, > > > > I am confused about something. > > > > During the TRILL WG meeting, I believe we had a consensus= of > the room > > to adopt the draft "draft-salam-trill-oam-framework" as a working group > draft. > > > > It is the case that a "consensus of the room" is not > sufficient to conclude > > working group consensus has been achieved. The room consensus needs to b= e > > confirmed on the mailing list =96 usually with a one or two week poll. > > > > Yet draft-salam-trill-oam-framework has been posted as a > working group > > draft (under the name shown in the subject line of this message). > > > > I have looked though my mail and do not see an announceme= nt > of any > > such poll for consensus > > > > Did the poll confirming the sense of the room happen, or > have we had > > a bit of a slip-up? > > > > -- > > Eric From zhangmingui@huawei.com Tue Nov 13 16:56:22 2012 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 6F63621F8481 for ; Tue, 13 Nov 2012 16:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0gCwJAKOJ-E for ; Tue, 13 Nov 2012 16:56:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2E421F8522 for ; Tue, 13 Nov 2012 16:56:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALM69841; Wed, 14 Nov 2012 00:56:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 00:56:06 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 00:56:16 +0000 Received: from SZXEML507-MBX.china.huawei.com ([169.254.8.150]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Wed, 14 Nov 2012 08:56:11 +0800 From: Mingui Zhang To: Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: AQHNvF9VPGjewC7aBke/jqCykHv+iZfoi7bg Date: Wed, 14 Nov 2012 00:56:10 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E73202921E@SZXEML507-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 00:56:22 -0000 Support. Mingui >-----Original Message----- >From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of = Donald >Eastlake >Sent: Wednesday, November 07, 2012 4:43 AM >To: trill@ietf.org >Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > >Hi, > >As announced at the TRILL WG meeting today, this starts a two week WG >Last Call on draft-ietf-trill-fine-labeling ending 19 November. > >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 >_______________________________________________ >trill mailing list >trill@ietf.org >https://www.ietf.org/mailman/listinfo/trill From jon.hudson@gmail.com Tue Nov 13 17:10:07 2012 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 40F8821F84D8 for ; Tue, 13 Nov 2012 17:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tR9MXMaKTXG for ; Tue, 13 Nov 2012 17:10:06 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF04F21F81FF for ; Tue, 13 Nov 2012 17:10:05 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2140165pbc.31 for ; Tue, 13 Nov 2012 17:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=o4uOn2Zlo8mDKQ9hjKioFTkeR87wtQA/TD/H/9V0Nn8=; b=FHRt8VzXgl2HD3rU9WtY3prUhJ95D7R2K8hkXwZZw4q+QFkq70lgk76tqQB9pPdAm3 qibC9Ol7cyOtOWKfUp8XJ9uO9tWpVmUmCJ0E2NdUEqkYsd+7x+I46sV09yANqwQI1dkx ICd2hVKkW5gHxHr4LVICv3Ljr8X+FeP9gwhZDDka5sAUYGSEAwC7rp/Jee4THPBn7DFq 447bmT6RbxaydQMTRFYe+xYbPV5O4l0RNX9uPNdieRGdw+pCH0ZofU5rgOrYe1A0xlDk rtswYfHhQDDYib5P/3Y0VW2BnntfwZeSao9uA/8bfeyF5JaynB26FgAiWrWz1QOWCvcI XVtg== Received: by 10.68.230.2 with SMTP id su2mr40178249pbc.54.1352855403189; Tue, 13 Nov 2012 17:10:03 -0800 (PST) Received: from [172.16.2.229] ([4.53.41.66]) by mx.google.com with ESMTPS id ku7sm6791044pbc.0.2012.11.13.17.10.01 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 17:10:02 -0800 (PST) References: <4552F0907735844E9204A62BBDD325E73202921E@SZXEML507-MBX.china.huawei.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4552F0907735844E9204A62BBDD325E73202921E@SZXEML507-MBX.china.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A525) From: Jon Hudson Date: Tue, 13 Nov 2012 18:09:59 -0700 To: Mingui Zhang Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 01:10:07 -0000 Support!! On Nov 13, 2012, at 5:56 PM, Mingui Zhang wrote: > Support. >=20 > Mingui >=20 >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of= Donald >> Eastlake >> Sent: Wednesday, November 07, 2012 4:43 AM >> To: trill@ietf.org >> Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt >>=20 >> Hi, >>=20 >> As announced at the TRILL WG meeting today, this starts a two week WG >> Last Call on draft-ietf-trill-fine-labeling ending 19 November. >>=20 >> 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 >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From hu.fangwei@zte.com.cn Tue Nov 13 17:12:15 2012 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 6EC3421F85C9; Tue, 13 Nov 2012 17:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihl7Gg05fGfX; Tue, 13 Nov 2012 17:12:15 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB7521F84EC; Tue, 13 Nov 2012 17:12:13 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id BB0E213BCAA6; Wed, 14 Nov 2012 09:13:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qAE1Bwxe027632; Wed, 14 Nov 2012 09:11:58 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: To: Jon Hudson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Wed, 14 Nov 2012 09:11:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-14 09:11:43, Serialize complete at 2012-11-14 09:11:43 Content-Type: multipart/alternative; boundary="=_alternative 000697D948257AB6_=" X-MAIL: mse02.zte.com.cn qAE1Bwxe027632 Cc: Donald Eastlake , Mingui Zhang , trill-bounces@ietf.org, "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 01:12:15 -0000 This is a multipart message in MIME format. --=_alternative 000697D948257AB6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KzEsIFN1cHBvcnQhIA0KDQoNCg0KSm9uIEh1ZHNvbiA8am9uLmh1ZHNvbkBnbWFpbC5jb20+IA0K t6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0xMS0xNCAwOTowOQ0KDQrK1bz+ yMsNCk1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4NCrOty80NCkRvbmFsZCBF YXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbT4sICJ0cmlsbEBpZXRmLm9yZyIgPHRyaWxsQGlldGYu b3JnPg0K1vfM4g0KUmU6IFt0cmlsbF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRyaWxsLWZp bmUtbGFiZWxpbmctMDIudHh0DQoNCg0KDQoNCg0KDQpTdXBwb3J0ISENCg0KT24gTm92IDEzLCAy MDEyLCBhdCA1OjU2IFBNLCBNaW5ndWkgWmhhbmcgPHpoYW5nbWluZ3VpQGh1YXdlaS5jb20+IHdy b3RlOg0KDQo+IFN1cHBvcnQuDQo+IA0KPiBNaW5ndWkNCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRyaWxs LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCk9mIERvbmFsZA0KPj4gRWFzdGxha2UNCj4+ IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDcsIDIwMTIgNDo0MyBBTQ0KPj4gVG86IHRyaWxs QGlldGYub3JnDQo+PiBTdWJqZWN0OiBbdHJpbGxdIFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi10 cmlsbC1maW5lLWxhYmVsaW5nLTAyLnR4dA0KPj4gDQo+PiBIaSwNCj4+IA0KPj4gQXMgYW5ub3Vu Y2VkIGF0IHRoZSBUUklMTCBXRyBtZWV0aW5nIHRvZGF5LCB0aGlzIHN0YXJ0cyBhIHR3byB3ZWVr IFdHDQo+PiBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi10cmlsbC1maW5lLWxhYmVsaW5nIGVuZGlu ZyAxOSBOb3ZlbWJlci4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gRG9uYWxkDQo+PiA9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KPj4gRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsxLTUwOC0z MzMtMjI3MCAoY2VsbCkNCj4+IDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBV U0ENCj4+IGQzZTNlM0BnbWFpbC5jb20NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiB0cmlsbCBtYWlsaW5nIGxpc3QNCj4+IHRyaWxsQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyaWxsIG1h aWxpbmcgbGlzdA0KPiB0cmlsbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RyaWxsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KDQoNCg== --=_alternative 000697D948257AB6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4rMSwgU3VwcG9ydCEgPC90dD48L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Sm9uIEh1ZHNvbiAmbHQ7am9u Lmh1ZHNvbkBnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3RyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMS0xNCAwOTowOTwvZm9u dD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5NaW5n dWkgWmhhbmcgJmx0O3poYW5nbWluZ3VpQGh1YXdlaS5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5Eb25hbGQgRWFzdGxha2UgJmx0O2QzZTNlM0BnbWFpbC5jb20mZ3Q7LA0KJnF1b3Q7dHJpbGxA aWV0Zi5vcmcmcXVvdDsgJmx0O3RyaWxsQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ UmU6IFt0cmlsbF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRyaWxsLWZpbmUtbGFiZWxpbmct MDIudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD5TdXBwb3J0ISE8YnI+DQo8YnI+DQpPbiBOb3YgMTMsIDIwMTIsIGF0IDU6NTYgUE0s IE1pbmd1aSBaaGFuZyAmbHQ7emhhbmdtaW5ndWlAaHVhd2VpLmNvbSZndDsNCndyb3RlOjxicj4N Cjxicj4NCiZndDsgU3VwcG9ydC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTWluZ3VpPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7 IEZyb206IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYu b3JnXSBPbg0KQmVoYWxmIE9mIERvbmFsZDxicj4NCiZndDsmZ3Q7IEVhc3RsYWtlPGJyPg0KJmd0 OyZndDsgU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwNywgMjAxMiA0OjQzIEFNPGJyPg0KJmd0 OyZndDsgVG86IHRyaWxsQGlldGYub3JnPGJyPg0KJmd0OyZndDsgU3ViamVjdDogW3RyaWxsXSBX RyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtdHJpbGwtZmluZS1sYWJlbGluZy0wMi50eHQ8YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBB cyBhbm5vdW5jZWQgYXQgdGhlIFRSSUxMIFdHIG1lZXRpbmcgdG9kYXksIHRoaXMgc3RhcnRzIGEg dHdvDQp3ZWVrIFdHPGJyPg0KJmd0OyZndDsgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdHJpbGwt ZmluZS1sYWJlbGluZyBlbmRpbmcgMTkgTm92ZW1iZXIuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7IERvbmFsZDxicj4NCiZndDsmZ3Q7ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyZndDsgRG9uYWxkIEUuIEVhc3RsYWtlIDNy ZCAmbmJzcDsgKzEtNTA4LTMzMy0yMjcwIChjZWxsKTxicj4NCiZndDsmZ3Q7IDE1NSBCZWF2ZXIg U3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0E8YnI+DQomZ3Q7Jmd0OyBkM2UzZTNAZ21haWwu Y29tPGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyB0 cmlsbEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHJpbGw8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHRy aWxsQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyaWxsPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw8YnI+DQo8L3R0PjwvZm9u dD4NCjxicj4NCg== --=_alternative 000697D948257AB6_=-- From windy_1@skyhighway.com Tue Nov 13 18:03:14 2012 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 B89B521F859D for ; Tue, 13 Nov 2012 18:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPm9uVJHNfHb for ; Tue, 13 Nov 2012 18:03:13 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 01CCA21F851E for ; Tue, 13 Nov 2012 18:03:12 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qAE239ZZ085527 for ; Tue, 13 Nov 2012 18:03:09 -0800 (PST) Message-Id: <201211140203.qAE239ZZ085527@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Nov 2012 18:03:19 -0800 To: trill@ietf.org From: gayle noble In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 02:03:14 -0000 support At 12:42 PM 11/6/2012, Donald Eastlake wrote: >Hi, > >As announced at the TRILL WG meeting today, this starts a two week WG >Last Call on draft-ietf-trill-fine-labeling ending 19 November. > >Thanks, >Donald >============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >_______________________________________________ >trill mailing list >trill@ietf.org >https://www.ietf.org/mailman/listinfo/trill From naveen@broadcom.com Tue Nov 13 20:46:09 2012 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 5589221F867C for ; Tue, 13 Nov 2012 20:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HgCvmitmiVn for ; Tue, 13 Nov 2012 20:46:08 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id D046B21F8674 for ; Tue, 13 Nov 2012 20:46:08 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 13 Nov 2012 20:43:57 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 13 Nov 2012 20:42:37 -0800 Received: from SJEXCHMB06.corp.ad.broadcom.com ( [fe80::65ea:1de7:41c4:e948]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 13 Nov 2012 20:42:16 -0800 From: "Naveen Nimmu" To: "Jon Hudson" , "Mingui Zhang" Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: AQHNvF9bZBwFljSKnkm3VPccr5xFFJfpEwkAgAAD3ID//7UmoA== Date: Wed, 14 Nov 2012 04:42:14 +0000 Message-ID: <8FCD488658FD4040A3A2279ABA0AD4831BCFF583@SJEXCHMB06.corp.ad.broadcom.com> References: <4552F0907735844E9204A62BBDD325E73202921E@SZXEML507-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CBDFEE61QK2328094-17-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 04:46:09 -0000 Support -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of J= on Hudson Sent: Wednesday, November 14, 2012 6:40 AM To: Mingui Zhang Cc: Donald Eastlake; trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Support!! On Nov 13, 2012, at 5:56 PM, Mingui Zhang wrote: > Support. >=20 > Mingui >=20 >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf O= f Donald >> Eastlake >> Sent: Wednesday, November 07, 2012 4:43 AM >> To: trill@ietf.org >> Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt >>=20 >> Hi, >>=20 >> As announced at the TRILL WG meeting today, this starts a two week WG >> Last Call on draft-ietf-trill-fine-labeling ending 19 November. >>=20 >> 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 >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From zhai.hongjun@zte.com.cn Tue Nov 13 21:15:47 2012 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 C014E21F841C; Tue, 13 Nov 2012 21:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.399 X-Spam-Level: X-Spam-Status: No, score=-94.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t1AEMAvW0w0; Tue, 13 Nov 2012 21:15:46 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B6E9421F853F; Tue, 13 Nov 2012 21:15:45 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id BBDB11296FA5; Wed, 14 Nov 2012 13:17:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAE5FVmG098496; Wed, 14 Nov 2012 13:15:31 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: To: Donald Eastlake MIME-Version: 1.0 X-KeepSent: BEA1D300:0BF905ED-48257AB6:001CBA6F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Wed, 14 Nov 2012 13:15:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-14 13:15:16, Serialize complete at 2012-11-14 13:15:16 Content-Type: multipart/alternative; boundary="=_alternative 001D0FDF48257AB6_=" X-MAIL: mse01.zte.com.cn qAE5FVmG098496 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 05:15:47 -0000 This is a multipart message in MIME format. --=_alternative 001D0FDF48257AB6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KDQoNCkJlc3QgUmVnYXJkcywNClpoYWkgSG9uZ2p1bg0KIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi Ig0KIFByb3RvY29sIERldmVsb3BtZW50IERlcHQuVkksIENlbnRyYWwgUiZEIEluc3RpdHV0ZSwg WlRFIENvcnBvcmF0aW9uDQogTm8uIDY4LCBaaWppbmdodWEgUm9hZCwgWXVodWF0YWkgRGlzdHJp Y3QsIE5hbmppbmcsIFAuUi5DaGluYSwgMjEwMDEyDQogDQogWmhhaSBIb25nanVuDQogDQogVGVs OiArODYtMjUtNTI4NzczNDUNCiBFbWFpbDogemhhaS5ob25nanVuQHp0ZS5jb20uY24NCiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiDQoNCg0KDQoNCg0KRG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21haWwuY29tPiAN CreivP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTItMTEtMDcgMDQ6NDINCg0KytW8 /sjLDQp0cmlsbEBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpbdHJpbGxdIFdHIExhc3QgQ2FsbDog ZHJhZnQtaWV0Zi10cmlsbC1maW5lLWxhYmVsaW5nLTAyLnR4dA0KDQoNCg0KDQoNCg0KSGksDQoN CkFzIGFubm91bmNlZCBhdCB0aGUgVFJJTEwgV0cgbWVldGluZyB0b2RheSwgdGhpcyBzdGFydHMg YSB0d28gd2VlayBXRw0KTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdHJpbGwtZmluZS1sYWJlbGlu ZyBlbmRpbmcgMTkgTm92ZW1iZXIuDQoNClRoYW5rcywNCkRvbmFsZA0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCiBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcw IChjZWxsKQ0KIDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0ENCiBkM2Uz ZTNAZ21haWwuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KDQoNCg== --=_alternative 001D0FDF48257AB6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQpCZXN0IFJl Z2FyZHMsPGJyPg0KWmhhaSBIb25nanVuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0K IFByb3RvY29sIERldmVsb3BtZW50IERlcHQuVkksIENlbnRyYWwgUiZhbXA7RCBJbnN0aXR1dGUs IFpURSBDb3Jwb3JhdGlvbjxicj4NCiBOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRhaSBE aXN0cmljdCwgTmFuamluZywgUC5SLkNoaW5hLCAyMTAwMTI8YnI+DQogPGJyPg0KIFpoYWkgSG9u Z2p1bjxicj4NCiA8YnI+DQogVGVsOiArODYtMjUtNTI4NzczNDU8YnI+DQogRW1haWw6IHpoYWku aG9uZ2p1bkB6dGUuY29tLmNuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0K PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjxiPkRvbmFsZCBFYXN0bGFrZSAmbHQ7ZDNlM2UzQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7dHJpbGwt Ym91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4yMDEyLTExLTA3IDA0OjQyPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPnRyaWxsQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bdHJpbGxdIFdHIExhc3QgQ2FsbDog ZHJhZnQtaWV0Zi10cmlsbC1maW5lLWxhYmVsaW5nLTAyLnR4dDwvZm9udD48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGksPGJyPg0KPGJyPg0KQXMg YW5ub3VuY2VkIGF0IHRoZSBUUklMTCBXRyBtZWV0aW5nIHRvZGF5LCB0aGlzIHN0YXJ0cyBhIHR3 byB3ZWVrIFdHPGJyPg0KTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtdHJpbGwtZmluZS1sYWJlbGlu ZyBlbmRpbmcgMTkgTm92ZW1iZXIuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkRvbmFsZDxicj4N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIERvbmFsZCBFLiBFYXN0bGFrZSAz cmQgJm5ic3A7ICsxLTUwOC0zMzMtMjI3MCAoY2VsbCk8YnI+DQogMTU1IEJlYXZlciBTdHJlZXQs IE1pbGZvcmQsIE1BIDAxNzU3IFVTQTxicj4NCiBkM2UzZTNAZ21haWwuY29tPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWls aW5nIGxpc3Q8YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGw8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 001D0FDF48257AB6_=-- From dromasca@avaya.com Wed Nov 14 01:47:24 2012 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 8B7CF21F8622 for ; Wed, 14 Nov 2012 01:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9cLF6RwvuaL for ; Wed, 14 Nov 2012 01:47:24 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id DBE8821F8615 for ; Wed, 14 Nov 2012 01:47:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPsvoFCHCzI1/2dsb2JhbABBA8NVgQiCHgEBAQEDAQEBDwsTCjQLDAQCAQgNAQMEAQEBCgYMCwEGASAGHwkIAQEEARIIARmHVgMPC54nkh8NiVSLLGkagwSCS2EDlCYBgnGEcYUlA4UOgnCBYw X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="376064332" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Nov 2012 04:39:23 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Nov 2012 04:24:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Nov 2012 10:47:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill]http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 Thread-Index: Ac3B+G61s5kDxm3xTzOmtxsUb6YiSQAU+ZXw References: <48E1A67CB9CA044EADFEAB87D814BFF601B20A@EUSAAMB107.ericsson.se> From: "Romascanu, Dan (Dan)" To: "Donald Eastlake" , "Eric Gray" Cc: rdroms.ietf@gmail.com, TRILL Working Group Subject: Re: [trill] http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:47:24 -0000 Hi, I agree with Donald. It looks to me that the proper process was followed here, as the mail list call for consensus issued on 10/26 was asking 'Please indicate whether or not you think this is reasonable as a WG document in the next week or so.' The five responses that followed on the mail list were all in support. The consensus call in the room at IETF-85 can be considered as a last opportunity to express concerns, which again resulted in favorable consensus.=20 Regards, Dan > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Donald Eastlake > Sent: Wednesday, November 14, 2012 1:41 AM > To: Eric Gray > Cc: Ralph Droms (rdroms.ietf@gmail.com); TRILL Working Group > Subject: Re: [trill]http://tools.ietf.org/html/draft-ietf-trill-oam- > framework-00 >=20 > Hi Eric, >=20 > The call by the Chairs to make this OAM framework draft a WG draft was > issued here http://www.ietf.org/mail- > archive/web/trill/current/msg05348.html >=20 > Technically, I could argue that there was no need to wait until the WG > meeting before making a determination but we did so the consensus in the > room merely ratified the consensus on the mailing list. >=20 > 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 >=20 >=20 > On Tue, Nov 13, 2012 at 6:34 PM, Eric Gray > wrote: > > Donald, > > > > > > > > I am confused about something. > > > > > > > > During the TRILL WG meeting, I believe we had a > > consensus of the room > > > > to adopt the draft "draft-salam-trill-oam-framework" as a working > > group draft. > > > > > > > > It is the case that a "consensus of the room" is not > > sufficient to conclude > > > > working group consensus has been achieved. The room consensus needs > > to be > > > > confirmed on the mailing list - usually with a one or two week poll. > > > > > > > > Yet draft-salam-trill-oam-framework has been posted as > > a working group > > > > draft (under the name shown in the subject line of this message). > > > > > > > > I have looked though my mail and do not see an > > announcement of any > > > > such poll for consensus > > > > > > > > Did the poll confirming the sense of the room happen, > > or have we had > > > > a bit of a slip-up? > > > > > > > > -- > > > > Eric > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From sunny.rajagopalan@us.ibm.com Wed Nov 14 09:14:10 2012 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 BDDB921F8771 for ; Wed, 14 Nov 2012 09:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyuncEgcHrU2 for ; Wed, 14 Nov 2012 09:14:09 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id A7DE421F86C9 for ; Wed, 14 Nov 2012 09:14:09 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Nov 2012 10:14:08 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 14 Nov 2012 10:14:06 -0700 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id DBA1E19D8036 for ; Wed, 14 Nov 2012 10:14:04 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAEHDogk189924 for ; Wed, 14 Nov 2012 10:13:50 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAEHDj6S017200 for ; Wed, 14 Nov 2012 10:13:47 -0700 Received: from d03nm127.boulder.ibm.com ([9.16.16.115]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAEHDFXq013986 for ; Wed, 14 Nov 2012 10:13:15 -0700 In-Reply-To: References: To: trill@ietf.org MIME-Version: 1.0 X-KeepSent: E324ED50:077CC66D-87257AB6:005E8D1B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Sunny Rajagopalan Date: Wed, 14 Nov 2012 09:13:13 -0800 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 11/14/2012 10:13:15, Serialize complete at 11/14/2012 10:13:15 Content-Type: multipart/alternative; boundary="=_alternative 005E98F588257AB6_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12111417-3620-0000-0000-0000005CB50E Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:14:10 -0000 This is a multipart message in MIME format. --=_alternative 005E98F588257AB6_= Content-Type: text/plain; charset="US-ASCII" Support! From: Donald Eastlake To: trill@ietf.org, Date: 11/06/2012 12:43 PM Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Sent by: trill-bounces@ietf.org Hi, As announced at the TRILL WG meeting today, this starts a two week WG Last Call on draft-ietf-trill-fine-labeling ending 19 November. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --=_alternative 005E98F588257AB6_= Content-Type: text/html; charset="US-ASCII" Support!



From:        Donald Eastlake <d3e3e3@gmail.com>
To:        trill@ietf.org,
Date:        11/06/2012 12:43 PM
Subject:        [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt
Sent by:        trill-bounces@ietf.org



Hi,

As announced at the TRILL WG meeting today, this starts a two week WG
Last Call on draft-ietf-trill-fine-labeling ending 19 November.

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
--=_alternative 005E98F588257AB6_=-- From radiaperlman@gmail.com Wed Nov 14 09:15:53 2012 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 80BD721F8589 for ; Wed, 14 Nov 2012 09:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF90EjimNCqH for ; Wed, 14 Nov 2012 09:15:53 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 835B221F84FB for ; Wed, 14 Nov 2012 09:15:48 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so760734vcb.31 for ; Wed, 14 Nov 2012 09:15:47 -0800 (PST) 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:content-type; bh=Zanl9+bFvxXP79PXVQ2KMslfWqOMToE23hWnCk9Ozhk=; b=X0Jn6p6i0BoppT1I7cn16KHm4RlO40B2oyJndBaLA22IUewfr3EcawLVu+EZLbAC/v 5EeXPwW2PBIT9KizZsf08qnFI0ymXy7jWkrfUSKysJNdDwF8cweoVtGJDyWxjgSduyGX 6ol/9lTl0AvIvr3sUS8/udTizUzrNvh218nOEYHP9yHZV+jhD9V5Fck0kj67gGIt6duy q3O4gzzojWqzSpBEyhaOY6zGIezUi+baWJQXms4HKbW44BQNYVGLp5dgN5DdndL9UDvr 4HskIhGMDWLhPX3yle2xQJu1zTPKS2KG8StFQFIcJCl26TKQaKOoTb5j9CBix310p+rp h3AQ== MIME-Version: 1.0 Received: by 10.220.152.11 with SMTP id e11mr11813836vcw.61.1352913347702; Wed, 14 Nov 2012 09:15:47 -0800 (PST) Received: by 10.58.85.65 with HTTP; Wed, 14 Nov 2012 09:15:47 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 09:15:47 -0800 Message-ID: From: Radia Perlman To: Donald Eastlake Content-Type: multipart/alternative; boundary=f46d043d64ab806f4f04ce77afe7 Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:15:53 -0000 --f46d043d64ab806f4f04ce77afe7 Content-Type: text/plain; charset=ISO-8859-1 Support! On Tue, Nov 6, 2012 at 12:42 PM, Donald Eastlake wrote: > Hi, > > As announced at the TRILL WG meeting today, this starts a two week WG > Last Call on draft-ietf-trill-fine-labeling ending 19 November. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --f46d043d64ab806f4f04ce77afe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support!
=A0


=A0
On Tue, Nov 6, 2012 at 12:42 PM, Donald Eastlake &= lt;d3e3e3@gmail.com> wrote:
Hi,

As announced at the TRILL WG meeting today, this starts a two week WG
Last Call on draft-ietf-trill-fine-labeling ending 19 November.

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
=A0Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell)
=A0155 Beaver Street, Milford, MA 01757 USA
=A0d3e3e3@gmail.com
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--f46d043d64ab806f4f04ce77afe7-- From eric.gray@ericsson.com Wed Nov 14 09:55:10 2012 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 A3F5C21F851C for ; Wed, 14 Nov 2012 09:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFz3krajTgoS for ; Wed, 14 Nov 2012 09:55:10 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 070A821F851A for ; Wed, 14 Nov 2012 09:55:09 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAEI1KXr002918; Wed, 14 Nov 2012 12:01:22 -0600 Received: from EUSAAHC008.ericsson.se (147.117.188.96) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 14 Nov 2012 12:55:03 -0500 Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 12:55:03 -0500 From: Eric Gray To: Donald Eastlake Thread-Topic: http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 Thread-Index: Ac3B9gCpGTa47RLBQBucEqzXOu6v9QALEXGAABtXeZA= Date: Wed, 14 Nov 2012 17:55:02 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF601B574@EUSAAMB107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF601B20A@EUSAAMB107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ralph Droms \(rdroms.ietf@gmail.com\)" , TRILL Working Group Subject: Re: [trill] http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:55:10 -0000 Donald, Thanks for the clarification. The request for support for adoption was se= nt out on 26 October, looking for responses "in the next week or so." The request was posted by Erik Nordmark and I had missed it. My confusion on this was worsened by the way that the usual procedure had = been=20 "turned around" in seeking confirmation "from the room" of an apparent cons= ensus on the=20 list. =20 As a matter of process, I wonder why the question was asked. I believe th= at the list result would have over-ridden the sense of the room, since the results from= the list are - I believe - expected to be definitive. Ratification by room consensus should= be unnecessary and irrelevant. Asking the question in the room was unusual enough to conform my belief th= at the=20 request to the list had not yet been sent. My apologies for spreading confusion on the issue... -- Eric -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Tuesday, November 13, 2012 6:41 PM To: Eric Gray Cc: TRILL Working Group; Ralph Droms (rdroms.ietf@gmail.com) Subject: Re: http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 Importance: High Hi Eric, The call by the Chairs to make this OAM framework draft a WG draft was issu= ed here http://www.ietf.org/mail-archive/web/trill/current/msg05348.html Technically, I could argue that there was no need to wait until the WG meet= ing before making a determination but we did so the consensus in the room m= erely ratified the consensus on the mailing 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Nov 13, 2012 at 6:34 PM, Eric Gray wrote: > Donald, > > > > I am confused about something. > > > > During the TRILL WG meeting, I believe we had a=20 > consensus of the room > > to adopt the draft "draft-salam-trill-oam-framework" as a working=20 > group draft. > > > > It is the case that a "consensus of the room" is not=20 > sufficient to conclude > > working group consensus has been achieved. The room consensus needs=20 > to be > > confirmed on the mailing list - usually with a one or two week poll. > > > > Yet draft-salam-trill-oam-framework has been posted as=20 > a working group > > draft (under the name shown in the subject line of this message). > > > > I have looked though my mail and do not see an=20 > announcement of any > > such poll for consensus > > > > Did the poll confirming the sense of the room happen,=20 > or have we had > > a bit of a slip-up? > > > > -- > > Eric From nordmark@acm.org Wed Nov 14 13:13:07 2012 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 53E4921F8612 for ; Wed, 14 Nov 2012 13:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQau-1w5YoiF for ; Wed, 14 Nov 2012 13:13:06 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7020921F8521 for ; Wed, 14 Nov 2012 13:13:06 -0800 (PST) Received: from [10.154.212.171] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qAELD3RB006225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 13:13:03 -0800 Message-ID: <50A4095E.80009@acm.org> Date: Wed, 14 Nov 2012 13:13:02 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: trill@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:13:07 -0000 We would really like to she some more explicit indications from WG participants that they have read this document and agree with it. Please include any substantial as well as editorial improvements that result from reviewing the document. Erik On 10/25/12 3:55 PM, Donald Eastlake wrote: > This message begins a TRILL WG two week Last Call on the > draft-ietf-trill-directory-framework draft. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From radiaperlman@gmail.com Wed Nov 14 13:34:33 2012 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 978AA21F86E4 for ; Wed, 14 Nov 2012 13:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SDL0VNpmEew for ; Wed, 14 Nov 2012 13:34:33 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2F1421F851A for ; Wed, 14 Nov 2012 13:34:31 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so1062063vcb.31 for ; Wed, 14 Nov 2012 13:34:31 -0800 (PST) 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:content-type; bh=X6Jk6ZwzGFurKCiYivGAZmXNl9hNlB2YnYmQDQvlsFc=; b=t296hAPJeN1uwLaDvU1x7EfBb8/WRsHrlW9NNyMLzYPjW2XuEJopVeo7Xfuzz3K/eA F+Kirq1HQWF71nSM1NuJxedPBckfTX8I6Z52L9aOJfAM6+aLsUEkcVRLnW7P9vw3lHtw KCdvWPHbIV2VfEV7/5EMN6cUGElggr/vbaWZLmsZX7lgSCHWTXvMuILs9wzH5Kq+y/ir aKcCCgCn16ZLlkd574gsmbqXFX3EkvRhfuLdVpzU+a7NCfFhqOLO9rToTZd2rD4eBmxR eHpH3yXsbCIGIv2/xT9q4haFEPf4ph2XbH1GS/1itEuhpPTRRKoEC+RcIg9UzQBEuJg8 u2dg== MIME-Version: 1.0 Received: by 10.52.27.133 with SMTP id t5mr3695791vdg.111.1352928870976; Wed, 14 Nov 2012 13:34:30 -0800 (PST) Received: by 10.58.85.65 with HTTP; Wed, 14 Nov 2012 13:34:30 -0800 (PST) In-Reply-To: <50A4095E.80009@acm.org> References: <50A4095E.80009@acm.org> Date: Wed, 14 Nov 2012 13:34:30 -0800 Message-ID: From: Radia Perlman To: Erik Nordmark Content-Type: multipart/alternative; boundary=20cf307d06e8c2cdd204ce7b4c08 Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:34:33 -0000 --20cf307d06e8c2cdd204ce7b4c08 Content-Type: text/plain; charset=ISO-8859-1 I've never been fond of "framework" documents, but this is fine for describing the problem. If it's supposed to be complete in some sense (whatever that means for a "framework"), it's missing some things that people suggested last week, e.g., the ability to be informed of an ACL policy, to make, e.g., a hypervisor have an endnode table that has (IP address, MAC address, TRILL switch address, only allowed from this set of MAC addresses). And there might be other information we'd want pushed or pulled, e.g., IPv4 and IPv6 address. Is it clear that the framework document doesn't preclude these extra things even though I don't think they are in the draft? Do we really need a framework document instead of just a single WG document on formats and algorithms that perhaps has a few paragraphs to explain why a directory is useful? Radia On Wed, Nov 14, 2012 at 1:13 PM, Erik Nordmark wrote: > > We would really like to she some more explicit indications from WG > participants that they have read this document and agree with it. > > Please include any substantial as well as editorial improvements that > result from reviewing the document. > > Erik > > > On 10/25/12 3:55 PM, Donald Eastlake wrote: > >> This message begins a TRILL WG two week Last Call on the >> draft-ietf-trill-directory-**framework draft. >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> ______________________________**_________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/**listinfo/trill >> >> > ______________________________**_________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/**listinfo/trill > --20cf307d06e8c2cdd204ce7b4c08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've never been fond of "framework" documents, but this = is fine for describing the problem.=A0 If it's supposed to be complete = in some sense (whatever that means for a "framework"), it's m= issing some things that people suggested last week, e.g., the ability to be= informed of an ACL policy, to make, e.g., a hypervisor have an endnode tab= le that has (IP address, MAC address, TRILL switch address, only allowed fr= om this set of MAC addresses).
=A0
And there might be other information we'd want pushe= d or pulled, e.g., IPv4 and IPv6 address.
=A0
Is it cle= ar that the framework document doesn't preclude these extra things even= though I don't think they are in the draft?
=A0
Do we really need a framework document instead of just a= single WG document on formats and algorithms that perhaps has a few paragr= aphs to explain why a directory is useful?
=A0
Radia
On Wed, Nov 14, 2012 at 1:13 PM, Erik = Nordmark <nordmark@acm.org> wrote:

We would really like to she some more explicit indications from WG particip= ants that they have read this document and agree with it.

Please include any substantial as well as editorial improvements that resul= t from reviewing the document.

=A0 =A0Erik


On 10/25/12 3:55 PM, Donald Eastlake wrote:
This message begins a TRILL WG two week Last Call on the
draft-ietf-trill-directory-framework draft.

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
=A0 Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell)
=A0 155 Beaver Street, Milford, MA 01757 USA
=A0 d3e3e3@gmail.com<= /a>
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill


_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--20cf307d06e8c2cdd204ce7b4c08-- From nordmark@acm.org Wed Nov 14 15:42:26 2012 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 CA82921F862A for ; Wed, 14 Nov 2012 15:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-xBM5tvaXfS for ; Wed, 14 Nov 2012 15:42:26 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 106EC21F85DF for ; Wed, 14 Nov 2012 15:42:26 -0800 (PST) Received: from [10.154.212.171] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qAENgIwG015693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 15:42:19 -0800 Message-ID: <50A42C5A.9060004@acm.org> Date: Wed, 14 Nov 2012 15:42:18 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tina TSOU , Donald Eastlake Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "trill@ietf.org" Subject: [trill] directory cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:42:26 -0000 Some questions and comments on the draft from the perspective of one WG participant (i.e., without my chair hat). Also, I hope this will stimulate some WG discussion and getting more folks to read and comment on the draft. In the abstract (and repeated in the introduction) we have: Edge RBridges currently learn the mapping between MAC addresses and their egress RBridges by observing the data packets traversed through. When an ingress RBridge receives a data frame with its destination address (MAC&VLAN) unknown, the data frame is flooded within the VLAN across the TRILL campus. The above text doesn't take into account the existence of ESADI. It makes sense to reword it to state that data-plane learning is mandatory and ESADI is optional, and that flooding occurs when ESADI is not used. The following sentence (also in the abstract *and* intro) seems unrelated to the topic of the draft, since the draft doesn't talk about changing AF (and I don't see how a directory can change how AF works): When there are more than one RBridge ports connected to one bridged LAN, only one of them can be designated as the Appointed Forwarder port for forwarding/receiving native traffic to/from each VLAN, the other RBridge ports on that LAN have to be disabled for native traffic in that VLAN. In section 5 you list the benefits, but the list doesn't include any benefits related to getting the ARP/ND information from the directory. Shouldn't that be added? [But also see the last comment below] In section 5 you have: [IP, MAC, attached RBridge nickname, {list of interested RBridges}] I suspect VLAN (or FGL) should be added to the above list. I think ESADI allows a or be attached to more than one RBridge, which would imply that a table with the above structure would have multiple attached RBrudge nicknames. Also, a host can definitely have multiple IPv4 and IPv6 addresses on the same network interface, resulting in multiple rows in the above table that only differs in the IP address. It isn't clear to me if the "list of interested RBridges" is needed. It assumes that it is cost-effective to track everybody that might have cached the information and do selective update of those RBridges, as opposed to sending updates to any RBridge interested in that VLAN. In any case, the list of interested only applies to a pull model. In Table 1 there are no IP addresses; I would assume that they would be pushed as well. In section 5.3 there is a description of how RBridges cache the information from the directory, but there is no discussion of how that cached information would be updated should the destination (IP, MAC, VLAN) change. There should at least be a sentence saying that there needs to be a mechanism for the directory to invalidate or update cached information when that information is stale due to a change in the directory content. Finally I was under the impression that the draft would reduce ARP/ND traffic by leveraging getting IP->MAC address bindings from the directory. But I don't see any text about this for push nor pull. As currently specified the document doesn't reduce any ARP/ND traffic - it merely optionally uses ARP/ND packets to trigger directory lookups. Hence I'm a bit confused about the scope of the draft. I was assuming that the draft would specify that an ingress rbridge would intercept ARP requests (and Neighbor Solicitations) and use the information from the directory (whether push or pull) to unicast the ARP/NS to the egress rbridge, thereby avoid flooding the ARP/ND to all the rbridges in the VLAN. Erik From nordmark@acm.org Wed Nov 14 15:55:37 2012 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 4064821F84DF for ; Wed, 14 Nov 2012 15:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DwaoqK60765 for ; Wed, 14 Nov 2012 15:55:36 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id B2AC421F85DF for ; Wed, 14 Nov 2012 15:55:36 -0800 (PST) Received: from [10.154.212.171] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qAENtWBO026589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 15:55:33 -0800 Message-ID: <50A42F74.4090202@acm.org> Date: Wed, 14 Nov 2012 15:55:32 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Radia Perlman References: <50A4095E.80009@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:55:37 -0000 On 11/14/12 1:34 PM, Radia Perlman wrote: > I've never been fond of "framework" documents, but this is fine for > describing the problem. If it's supposed to be complete in some sense > (whatever that means for a "framework"), it's missing some things that > people suggested last week, e.g., the ability to be informed of an ACL > policy, to make, e.g., a hypervisor have an endnode table that has (IP > address, MAC address, TRILL switch address, only allowed from this set > of MAC addresses). > And there might be other information we'd want pushed or pulled, e.g., > IPv4 and IPv6 address. > Is it clear that the framework document doesn't preclude these extra > things even though I don't think they are in the draft? The reason for having the separate framework document is to enable the WG to discuss and get consensus around the general direction - the set of problems to solve and how they fit with current TRILL - without getting into details such as which protocol to use to pull information out the directory. > Do we really need a framework document instead of just a single WG > document on formats and algorithms that perhaps has a few paragraphs to > explain why a directory is useful? If there was more WG discussion around the directory assisted approach and the discussion indicated a clear direction, then we might be able to simplify this into one draft. Regards, Erik > Radia > > On Wed, Nov 14, 2012 at 1:13 PM, Erik Nordmark > wrote: > > > We would really like to she some more explicit indications from WG > participants that they have read this document and agree with it. > > Please include any substantial as well as editorial improvements > that result from reviewing the document. > > Erik > > > On 10/25/12 3:55 PM, Donald Eastlake wrote: > > This message begins a TRILL WG two week Last Call on the > draft-ietf-trill-directory-__framework draft. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 > (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _________________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/__listinfo/trill > > > > _________________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/__listinfo/trill > > > From nordmark@acm.org Wed Nov 14 16:03:18 2012 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 D480021F854E for ; Wed, 14 Nov 2012 16:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbq3ruhmDM7j for ; Wed, 14 Nov 2012 16:03:18 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC5321F853F for ; Wed, 14 Nov 2012 16:03:18 -0800 (PST) Received: from [10.154.212.171] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qAF03FLb001668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 16:03:15 -0800 Message-ID: <50A43143.6000209@acm.org> Date: Wed, 14 Nov 2012 16:03:15 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "trill@ietf.org" References: <50A42C5A.9060004@acm.org> In-Reply-To: <50A42C5A.9060004@acm.org> X-Forwarded-Message-Id: <50A42C5A.9060004@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Comments on draft-ietf-trill-directory-framework-01 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 00:03:18 -0000 [Resent with a better subject to make it easier to correlated emails to internet-drafts. Please respond to this email.] Some questions and comments on the draft from the perspective of one WG participant (i.e., without my chair hat). Also, I hope this will stimulate some WG discussion and getting more folks to read and comment on the draft. In the abstract (and repeated in the introduction) we have: Edge RBridges currently learn the mapping between MAC addresses and their egress RBridges by observing the data packets traversed through. When an ingress RBridge receives a data frame with its destination address (MAC&VLAN) unknown, the data frame is flooded within the VLAN across the TRILL campus. The above text doesn't take into account the existence of ESADI. It makes sense to reword it to state that data-plane learning is mandatory and ESADI is optional, and that flooding occurs when ESADI is not used. The following sentence (also in the abstract *and* intro) seems unrelated to the topic of the draft, since the draft doesn't talk about changing AF (and I don't see how a directory can change how AF works): When there are more than one RBridge ports connected to one bridged LAN, only one of them can be designated as the Appointed Forwarder port for forwarding/receiving native traffic to/from each VLAN, the other RBridge ports on that LAN have to be disabled for native traffic in that VLAN. In section 5 you list the benefits, but the list doesn't include any benefits related to getting the ARP/ND information from the directory. Shouldn't that be added? [But also see the last comment below] In section 5 you have: [IP, MAC, attached RBridge nickname, {list of interested RBridges}] I suspect VLAN (or FGL) should be added to the above list. I think ESADI allows a or be attached to more than one RBridge, which would imply that a table with the above structure would have multiple attached RBrudge nicknames. Also, a host can definitely have multiple IPv4 and IPv6 addresses on the same network interface, resulting in multiple rows in the above table that only differs in the IP address. It isn't clear to me if the "list of interested RBridges" is needed. It assumes that it is cost-effective to track everybody that might have cached the information and do selective update of those RBridges, as opposed to sending updates to any RBridge interested in that VLAN. In any case, the list of interested only applies to a pull model. In Table 1 there are no IP addresses; I would assume that they would be pushed as well. In section 5.3 there is a description of how RBridges cache the information from the directory, but there is no discussion of how that cached information would be updated should the destination (IP, MAC, VLAN) change. There should at least be a sentence saying that there needs to be a mechanism for the directory to invalidate or update cached information when that information is stale due to a change in the directory content. Finally I was under the impression that the draft would reduce ARP/ND traffic by leveraging getting IP->MAC address bindings from the directory. But I don't see any text about this for push nor pull. As currently specified the document doesn't reduce any ARP/ND traffic - it merely optionally uses ARP/ND packets to trigger directory lookups. Hence I'm a bit confused about the scope of the draft. I was assuming that the draft would specify that an ingress rbridge would intercept ARP requests (and Neighbor Solicitations) and use the information from the directory (whether push or pull) to unicast the ARP/NS to the egress rbridge, thereby avoid flooding the ARP/ND to all the rbridges in the VLAN. Erik From rmanur@broadcom.com Wed Nov 14 16:19:45 2012 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 8847E21F8701 for ; Wed, 14 Nov 2012 16:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09wd+gJgtPbr for ; Wed, 14 Nov 2012 16:19:45 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 11C7B21F86E9 for ; Wed, 14 Nov 2012 16:19:45 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 14 Nov 2012 16:16:52 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 14 Nov 2012 16:19:29 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Wed, 14 Nov 2012 16:19:08 -0800 From: "Rajeev Manur" To: "trill@ietf.org" Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: AQHNvF9b8N8Z4Y4Mh0+/6OtzlkwgxpfqDw1g Date: Thu, 15 Nov 2012 00:19:07 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED1BDF057C@SJEXCHMB12.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CBAEBFE3R02638832-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 00:19:45 -0000 Support! I have the following editorial comments, * Section 4.0 -- First line in third paragraph : FLG should be changed to FGL -- Similar typo needs to be fixed in the 4th paragraph, LFG should be c= hanged to FGL * Section 5.0 -- Suggest changing the following sentence as below make the intent mor= e explicit and remove ambiguity, Current: "The FGL ingress process MUST place the priority and DEI associate= d with an ingressed native frame in upper 4 bits of the Inner.Label Low Ord= er part." New: "The FGL ingress process MUST copy the priority and DEI from an ingres= sed native frame to upper 4 bits of the Inner.Label Low Order part." * Section 7.0 -- I see reference to first and second part of FGL. In previous section= s same fields are referred to as High and Low parts of FGL. It may be bette= r to use one name consistently across the doc. Thanks! --Rajeev -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Tuesday, November 06, 2012 12:43 PM To: trill@ietf.org Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi, As announced at the TRILL WG meeting today, this starts a two week WG Last Call on draft-ietf-trill-fine-labeling ending 19 November. 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 _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From liyizhou@huawei.com Wed Nov 14 16:53:28 2012 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 9054421F865C for ; Wed, 14 Nov 2012 16:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=2.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VfuDMvlufSU for ; Wed, 14 Nov 2012 16:53:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AD72021F86D1 for ; Wed, 14 Nov 2012 16:53:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALN59607; Thu, 15 Nov 2012 00:53:26 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 00:53:12 +0000 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 00:53:25 +0000 Received: from l63746 (10.138.122.33) by smtpscn.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 08:53:21 +0800 From: Yizhou Li To: "'Donald Eastlake'" , References: In-Reply-To: Date: Thu, 15 Nov 2012 08:53:21 +0800 Message-ID: <075001cdc2cb$9c240b90$d46c22b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac28X1SMW+GNMQPsTiWJ922FyZlyCwGbDwXw Content-Language: zh-cn X-Originating-IP: [10.138.122.33] X-CFilter-Loop: Reflected Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 00:53:28 -0000 Support Yizhou -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake Sent: Wednesday, November 07, 2012 4:43 AM To: trill@ietf.org Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi, As announced at the TRILL WG meeting today, this starts a two week WG Last Call on draft-ietf-trill-fine-labeling ending 19 November. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From internet-drafts@ietf.org Thu Nov 15 08:45:13 2012 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 83E6521F8934; Thu, 15 Nov 2012 08:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGsaB+VUjlOw; Thu, 15 Nov 2012 08:45:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242E721F86D1; Thu, 15 Nov 2012 08:45:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121115164513.4119.98269.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 08:45:13 -0800 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-oam-req-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:45:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : Requirements for Operations, Administration and Maintena= nce (OAM) in TRILL (Transparent Interconnection of Lots of Links) Author(s) : Tissa Senevirathne David Bond Sam Aldrin Yizhou Li Rohit Watve Filename : draft-ietf-trill-oam-req-04.txt Pages : 14 Date : 2012-11-15 Abstract: OAM (Operations, Administration and Maintenance) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents, OAM Requirements applicable to TRILL. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-oam-req There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-oam-req-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-oam-req-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From linda.dunbar@huawei.com Thu Nov 15 12:32:09 2012 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 42DE421F85CD for ; Thu, 15 Nov 2012 12:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt+l2g163nJx for ; Thu, 15 Nov 2012 12:32:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCED21F8568 for ; Thu, 15 Nov 2012 12:32:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALP48457; Thu, 15 Nov 2012 20:32:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 20:31:49 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 20:32:02 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 12:31:57 -0800 From: Linda Dunbar To: Radia Perlman , Erik Nordmark Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt Thread-Index: AQHNwqzc/scuXvCj5EaZk4DoqUzctJfqYGsAgADuh7A= Date: Thu, 15 Nov 2012 20:31:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645097F20@dfweml505-mbx> References: <50A4095E.80009@acm.org> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.168] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645097F20dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:32:09 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645097F20dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Radia, Thanks for the comments. Want to clarify that "draft-ietf-trill-directory-framework" is only intende= d to describe the benefits of directory assistance for TRILL network and th= e high level stuff (e.g. basic Pull/Push models). The draft is not intended= for describing the detailed mechanism. The mechanism which we discussed last week is described in "draft-dunbar-tr= ill-scheme-for-directory-assist" (which is still a personal draft). I think it is necessary to have the framework document so that we don't hav= e to justify why directory assistance is needed for TRILL. We already spent= 3 IETF meeting cycles to justify why we need directory assistance. It will= be more productive to separate justification from the mechanisms, so the d= iscussion can be focused. As for describing policy (or ACL in your email), we discussed to add as res= ponses to Pull request to the detailed mechanism. I can add a simple statem= ent in the framework to indicate that Policy can be added and leave the det= ails to the mechanism draft. Linda From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of R= adia Perlman Sent: Wednesday, November 14, 2012 3:35 PM To: Erik Nordmark Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.= txt I've never been fond of "framework" documents, but this is fine for describ= ing the problem. If it's supposed to be complete in some sense (whatever t= hat means for a "framework"), it's missing some things that people suggeste= d last week, e.g., the ability to be informed of an ACL policy, to make, e.= g., a hypervisor have an endnode table that has (IP address, MAC address, T= RILL switch address, only allowed from this set of MAC addresses). And there might be other information we'd want pushed or pulled, e.g., IPv4= and IPv6 address. Is it clear that the framework document doesn't preclude these extra things= even though I don't think they are in the draft? Do we really need a framework document instead of just a single WG document= on formats and algorithms that perhaps has a few paragraphs to explain why= a directory is useful? Radia On Wed, Nov 14, 2012 at 1:13 PM, Erik Nordmark > wrote: We would really like to she some more explicit indications from WG particip= ants that they have read this document and agree with it. Please include any substantial as well as editorial improvements that resul= t from reviewing the document. Erik On 10/25/12 3:55 PM, Donald Eastlake wrote: This message begins a TRILL WG two week Last Call on the draft-ietf-trill-directory-framework draft. 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 _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --_000_4A95BA014132FF49AE685FAB4B9F17F645097F20dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Radia,

 <= /p>

Thanks for the comments.

Want to clarify that R= 20;draft-ietf-trill-directory-framework” is only intended to describe= the benefits of directory assistance for TRILL network and the high level stuff (e.g. basic Pull/Push models). The draft is not intended for d= escribing the detailed mechanism.

 <= /p>

The mechanism which we di= scussed last week is described in “draft-dunbar-trill-scheme-for-dire= ctory-assist” (which is still a personal draft).

 <= /p>

I think it is necessary t= o have the framework document so that we don’t have to justify why di= rectory assistance is needed for TRILL. We already spent 3 IETF meeting cycles to justify why we need directory assistance. It will be mor= e productive to separate justification from the mechanisms, so the discussi= on can be focused.

 <= /p>

As for describing policy = (or ACL in your email), we discussed to add as responses to Pull request to= the detailed mechanism. I can add a simple statement in the framework to indicate that Policy can be added and leave the details t= o the mechanism draft.

 <= /p>

 <= /p>

Linda

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: trill-bo= unces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Radia Perlman
Sent: Wednesday, November 14, 2012 3:35 PM
To: Erik Nordmark
Cc: trill@ietf.org
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framew= ork-01.txt

 

I've never been fond of "framework" docume= nts, but this is fine for describing the problem.  If it's supposed to= be complete in some sense (whatever that means for a "framework"= ), it's missing some things that people suggested last week, e.g., the ability to be informed of an ACL policy, to make, e.g., a hyperv= isor have an endnode table that has (IP address, MAC address, TRILL switch = address, only allowed from this set of MAC addresses).

 

And there might be other information we'd want pushe= d or pulled, e.g., IPv4 and IPv6 address.

 

Is it clear that the framework document doesn't prec= lude these extra things even though I don't think they are in the draft?

 

Do we really need a framework document instead of ju= st a single WG document on formats and algorithms that perhaps has a few pa= ragraphs to explain why a directory is useful?

 

Radia

On Wed, Nov 14, 2012 at 1:13 PM, Erik Nordmark <<= a href=3D"mailto:nordmark@acm.org" target=3D"_blank">nordmark@acm.org&g= t; wrote:


We would really like to she some more explicit indications from WG particip= ants that they have read this document and agree with it.

Please include any substantial as well as editorial improvements that resul= t from reviewing the document.

   Erik



On 10/25/12 3:55 PM, Donald Eastlake wrote:

This message begins a= TRILL WG two week Last Call on the
draft-ietf-trill-directory-framework draft.

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.c= om
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill


_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645097F20dfweml505mbx_-- From eric.gray@ericsson.com Thu Nov 15 12:47:20 2012 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 0849B21F89F2 for ; Thu, 15 Nov 2012 12:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN7KYK73vB0d for ; Thu, 15 Nov 2012 12:47:19 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F73B21F8447 for ; Thu, 15 Nov 2012 12:47:19 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAFKrB8g016885; Thu, 15 Nov 2012 14:53:38 -0600 Received: from EUSAAHC001.ericsson.se (147.117.188.75) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 15:46:58 -0500 Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 15:46:58 -0500 From: Eric Gray To: "Romascanu, Dan (Dan)" , Donald Eastlake Thread-Topic: [trill]http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 Thread-Index: Ac3B9gCpGTa47RLBQBucEqzXOu6v9QALEXGAABUrGwAAL1FQEA== Date: Thu, 15 Nov 2012 20:46:57 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF601BC7C@EUSAAMB107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF601B20A@EUSAAMB107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rdroms.ietf@gmail.com" , TRILL Working Group Subject: Re: [trill] http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:47:20 -0000 Dan, Thanks! As explained in separate mail, I was confused by the order of the process = in this case (apparently using the meeting to confirm the - somewhat feeble - = support from the mailing list), in combination with having entirely missed the cons= ensus call on the mailing list. I also agree that the process was followed, if in a somewhat contorted way= . -- Eric -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Wednesday, November 14, 2012 4:47 AM To: Donald Eastlake; Eric Gray Cc: rdroms.ietf@gmail.com; TRILL Working Group Subject: RE: [trill]http://tools.ietf.org/html/draft-ietf-trill-oam-framewo= rk-00 Importance: High Hi, I agree with Donald. It looks to me that the proper process was followed he= re, as the mail list call for consensus issued on 10/26 was asking 'Please = indicate whether or not you think this is reasonable as a WG document in th= e next week or so.' The five responses that followed on the mail list were = all in support. The consensus call in the room at IETF-85 can be considered as a last opportunity to express concerns, which = again resulted in favorable consensus.=20 Regards, Dan > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf=20 > Of Donald Eastlake > Sent: Wednesday, November 14, 2012 1:41 AM > To: Eric Gray > Cc: Ralph Droms (rdroms.ietf@gmail.com); TRILL Working Group > Subject: Re: [trill]http://tools.ietf.org/html/draft-ietf-trill-oam- > framework-00 >=20 > Hi Eric, >=20 > The call by the Chairs to make this OAM framework draft a WG draft was=20 > issued here http://www.ietf.org/mail-=20 > archive/web/trill/current/msg05348.html >=20 > Technically, I could argue that there was no need to wait until the WG=20 > meeting before making a determination but we did so the consensus in the > room merely ratified the consensus on the mailing list. >=20 > 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 >=20 >=20 > On Tue, Nov 13, 2012 at 6:34 PM, Eric Gray > wrote: > > Donald, > > > > > > > > I am confused about something. > > > > > > > > During the TRILL WG meeting, I believe we had a=20 > > consensus of the room > > > > to adopt the draft "draft-salam-trill-oam-framework" as a working=20 > > group draft. > > > > > > > > It is the case that a "consensus of the room" is not=20 > > sufficient to conclude > > > > working group consensus has been achieved. The room consensus needs=20 > > to be > > > > confirmed on the mailing list - usually with a one or two week poll. > > > > > > > > Yet draft-salam-trill-oam-framework has been posted as > > a working group > > > > draft (under the name shown in the subject line of this message). > > > > > > > > I have looked though my mail and do not see an=20 > > announcement of any > > > > such poll for consensus > > > > > > > > Did the poll confirming the sense of the room happen, > > or have we had > > > > a bit of a slip-up? > > > > > > > > -- > > > > Eric > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From linda.dunbar@huawei.com Thu Nov 15 12:49:24 2012 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 C844721F8AD7 for ; Thu, 15 Nov 2012 12:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2CfxytLa1Pi for ; Thu, 15 Nov 2012 12:49:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3189421F89E2 for ; Thu, 15 Nov 2012 12:49:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALP49153; Thu, 15 Nov 2012 20:49:20 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 20:49:06 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 20:49:19 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 12:49:10 -0800 From: Linda Dunbar To: Erik Nordmark , Tina TSOU , Donald Eastlake Thread-Topic: [trill] directory cmt Thread-Index: AQHNwsG6YiEyy62m6EKBZwcNpKY1uZfrTEHQ Date: Thu, 15 Nov 2012 20:49:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645097F5F@dfweml505-mbx> References: <50A42C5A.9060004@acm.org> In-Reply-To: <50A42C5A.9060004@acm.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] directory cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:49:24 -0000 Erik,=20 Thanks for the comments.=20 Replies and answers are inserted below: > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Erik Nordmark > Sent: Wednesday, November 14, 2012 5:42 PM > To: Tina TSOU; Donald Eastlake > Cc: trill@ietf.org > Subject: [trill] directory cmt >=20 >=20 > Some questions and comments on the draft from the perspective of one WG > participant (i.e., without my chair hat). >=20 > Also, I hope this will stimulate some WG discussion and getting more > folks to read and comment on the draft. >=20 > In the abstract (and repeated in the introduction) we have: > Edge RBridges currently learn the mapping between MAC addresses and > their egress RBridges by observing the data packets traversed > through. When an ingress RBridge receives a data frame with its > destination address (MAC&VLAN) unknown, the data frame is flooded > within the VLAN across the TRILL campus. > The above text doesn't take into account the existence of ESADI. It > makes sense to reword it to state that data-plane learning is mandatory > and ESADI is optional, and that flooding occurs when ESADI is not used. >=20 [Linda] Flooding still occurs for unknown DA even when ESADI is used. Just = that the chance for unknown DA is less when ESADI is used.=20 > The following sentence (also in the abstract *and* intro) seems > unrelated to the topic of the draft, since the draft doesn't talk about > changing AF (and I don't see how a directory can change how AF works): > When there are more than > one RBridge ports connected to one bridged LAN, only one of them > can > be designated as the Appointed Forwarder port for > forwarding/receiving native traffic to/from each VLAN, the other > RBridge ports on that LAN have to be disabled for native traffic in > that VLAN. [Linda] The description was intended for the feasibility of AF port being r= emoved when data frames are pre-encapsulated by directory assisted smart en= d nodes. It was later suggested to separate Smart Node pre-encapsulation to= a separate draft. I will clean this part.=20 >=20 > In section 5 you list the benefits, but the list doesn't include any > benefits related to getting the ARP/ND information from the directory. > Shouldn't that be added? [But also see the last comment below] [Linda] will add.=20 >=20 > In section 5 you have: > [IP, MAC, attached RBridge nickname, {list of interested RBridges}] > I suspect VLAN (or FGL) should be added to the above list. [Linda] will add.=20 > I think ESADI allows a or be attached to more than > one RBridge, which would imply that a table with the above structure > would have multiple attached RBrudge nicknames. [Linda] good catch. Will add. > Also, a host can definitely have multiple IPv4 and IPv6 addresses on > the > same network interface, resulting in multiple rows in the above table > that only differs in the IP address. >=20 [Linda] When a host has multiple IP addresses, there would be multiple entr= ies in the table. Those different IP Addresses are viewed as different targ= ets by remote notes, what needs to be said here? =20 If those addresses are in different VLANs, then there will be multiple VLAN= ids.=20 > It isn't clear to me if the "list of interested RBridges" is needed. It > assumes that it is cost-effective to track everybody that might have > cached the information and do selective update of those RBridges, as > opposed to sending updates to any RBridge interested in that VLAN. In > any case, the list of interested only applies to a pull model. >=20 [Linda] they should be applicable to Push model too because directory only = need to push them to interested RBridges instead of all.=20 >=20 > In Table 1 there are no IP addresses; I would assume that they would be > pushed as well. [Linda] Yes.=20 >=20 > In section 5.3 there is a description of how RBridges cache the > information from the directory, but there is no discussion of how that > cached information would be updated should the destination (IP, MAC, > VLAN) change. There should at least be a sentence saying that there > needs to be a mechanism for the directory to invalidate or update > cached > information when that information is stale due to a change in the > directory content. [Linda] The detailed mechanism draft has the description of "aging timer" f= or entries being pulled or pushed.=20 >=20 > Finally I was under the impression that the draft would reduce ARP/ND > traffic by leveraging getting IP->MAC address bindings from the > directory. But I don't see any text about this for push nor pull. > As currently specified the document doesn't reduce any ARP/ND traffic - > it merely optionally uses ARP/ND packets to trigger directory lookups. > Hence I'm a bit confused about the scope of the draft. [Linda] Yes.=20 >=20 > I was assuming that the draft would specify that an ingress rbridge > would intercept ARP requests (and Neighbor Solicitations) and use the > information from the directory (whether push or pull) to unicast the > ARP/NS to the egress rbridge, thereby avoid flooding the ARP/ND to all > the rbridges in the VLAN. [Linda] this is described in the detailed mechanism. I can add this descrip= tion in the framework too if it is beneficial. ( but I don't want to repeat= too much information in both drafts).=20 >=20 > Erik >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Thu Nov 15 13:21:01 2012 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 5A8D721F849A for ; Thu, 15 Nov 2012 13:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVx3ThnKoCeQ for ; Thu, 15 Nov 2012 13:21:00 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6187021F8495 for ; Thu, 15 Nov 2012 13:21:00 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so2961970iec.31 for ; Thu, 15 Nov 2012 13:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tLmSDx51vxsEUUOVi7QNiWFzVS4qkUqVYRQrSavZIlQ=; b=MPki7aPQCyz5zCef99VSfB+W1M826Lq8VAdVHzfPSc62LPTP1LY8xW6WnEoreYLvlS EG/P/LFo4Fi6s0Z9Q43pwAOxIpRAcU0OZ3ZS6iEOk8aKoQMEBU/vaL63w4rNsWN8L2uq mGmKSzfQaTZxFmUb1CmN/i+pgBu4T0JUGsaP7DeC5mMCevoSGTSsjiSoe0csVVGRDNLR gUKohEObzZdGu4cZysKb6q8+5szXCDZY5QATetRnbga9KLuu8eFzZ25pnIgIkzFZGd/l VhgmIqpgn1Ik+aHtjYZhrQajKgtmEka0a/d8GBMWQVNOZ1ND5nFXZwWwXeSpaFtXNRWJ FB/Q== Received: by 10.50.0.179 with SMTP id 19mr1193269igf.59.1353014459970; Thu, 15 Nov 2012 13:20:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Thu, 15 Nov 2012 13:20:38 -0800 (PST) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF601B574@EUSAAMB107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF601B20A@EUSAAMB107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF601B574@EUSAAMB107.ericsson.se> From: Donald Eastlake Date: Thu, 15 Nov 2012 16:20:38 -0500 Message-ID: To: Eric Gray Content-Type: text/plain; charset=ISO-8859-1 Cc: "Ralph Droms \(rdroms.ietf@gmail.com\)" , TRILL Working Group Subject: Re: [trill] http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:21:01 -0000 Hi Eric, On Wed, Nov 14, 2012 at 12:55 PM, Eric Gray wrote: > Donald, > > Thanks for the clarification. The request for support for adoption was sent out on > 26 October, looking for responses "in the next week or so." > > The request was posted by Erik Nordmark and I had missed it. I believe, when I went over draft status at the beginning of the meeting, I mentioned that a call to make this a working group draft had gone out. But whether I did or not, I should probably have mentioned this later in the meeting when it came up. > My confusion on this was worsened by the way that the usual procedure had been > "turned around" in seeking confirmation "from the room" of an apparent consensus on the > list. > > As a matter of process, I wonder why the question was asked. I believe that the list > result would have over-ridden the sense of the room, since the results from the list are - I > believe - expected to be definitive. Ratification by room consensus should be unnecessary > and irrelevant. Well, a couple of points: In making a consensus judgement, WG Chairs can take into account both the mailing list and the opinion of open WG meetings. A call for opinions/comments on the mailing list that either begins or ends with determining the opinion of an open meeting is fine. So far as I am aware, there is no IETF rule requiring a formal consensus determination to make a draft a WG draft. We more or less operate that way in the TRILL WG, at least requiring a clear preference, and people seem to be happy with the procedure. But, while it is less common recently, there have been IETF WGs in the past that operated in what might be called a promiscuous mode where numerous drafts were made WG drafts just by the action of the Chair, frequently including mutually contradictory drafts. Of course, such WGs only ever progressed a fraction of their WG drafts to RFC. > Asking the question in the room was unusual enough to conform my belief that the > request to the list had not yet been sent. Different IETF WGs differ in this regard. For example, the procedure of asking for an opinion and/or discussing a personal draft on the mailing list followed by taking the opinion of an open meeting and making the draft a WG draft if that meeting opinion is favorable is the common process in the IETF DHC WG, at least as far as I have observed. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > My apologies for spreading confusion on the issue... > > -- > Eric > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, November 13, 2012 6:41 PM > To: Eric Gray > Cc: TRILL Working Group; Ralph Droms (rdroms.ietf@gmail.com) > Subject: Re: http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00 > Importance: High > > Hi Eric, > > The call by the Chairs to make this OAM framework draft a WG draft was issued here http://www.ietf.org/mail-archive/web/trill/current/msg05348.html > > Technically, I could argue that there was no need to wait until the WG meeting before making a determination but we did so the consensus in the room merely ratified the consensus on the mailing list. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > > > On Tue, Nov 13, 2012 at 6:34 PM, Eric Gray wrote: >> Donald, >> >> >> >> I am confused about something. >> >> >> >> During the TRILL WG meeting, I believe we had a >> consensus of the room >> >> to adopt the draft "draft-salam-trill-oam-framework" as a working >> group draft. >> >> >> >> It is the case that a "consensus of the room" is not >> sufficient to conclude >> >> working group consensus has been achieved. The room consensus needs >> to be >> >> confirmed on the mailing list - usually with a one or two week poll. >> >> >> >> Yet draft-salam-trill-oam-framework has been posted as >> a working group >> >> draft (under the name shown in the subject line of this message). >> >> >> >> I have looked though my mail and do not see an >> announcement of any >> >> such poll for consensus >> >> >> >> Did the poll confirming the sense of the room happen, >> or have we had >> >> a bit of a slip-up? >> >> >> >> -- >> >> Eric From sujay.ietf@gmail.com Fri Nov 16 02:18:19 2012 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 C5FEC21F8694 for ; Fri, 16 Nov 2012 02:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd1AC9XKuVyE for ; Fri, 16 Nov 2012 02:18:18 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B324B21F867F for ; Fri, 16 Nov 2012 02:18:18 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1859918pbc.31 for ; Fri, 16 Nov 2012 02:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5X6vH3kkKfrPuW70E2ar5NndPSsEQSQiY0W6ewZTT+0=; b=Idi2ARp7otAbU1mtxCDvT1GvFtMShjTECRXGRPioJqs1IjHGEDkfYBJ1wClOHleYTn AyUZQ+a/cRWtZn/O/0SmWTCVTqRWexn+qw/894O0hEeJc3G1wTOvvxR/JB+VwulrOd8T fcemL5guxYRWZ0e8sm1pgAfL5Zy4p8di5Mjk6oXym8ZFhxEBYDERS312WMfLuBFGSPZi n2dLE02UZJKJfk531RS6JVAJebW9O6lsVD1zupFms2GsJeC5ZncjA0zZWwM1YNwKv2hO lzEZfqDmZnENQ2yH7YJ9wWtd4ksXdRfWPv0DpHWQkhX6FnN4UQ6Eq8ziakjtquVqCNRB +lig== Received: by 10.68.216.73 with SMTP id oo9mr7658226pbc.80.1353061098516; Fri, 16 Nov 2012 02:18:18 -0800 (PST) Received: from [10.12.6.82] ([115.112.61.194]) by mx.google.com with ESMTPS id kc4sm1020675pbc.23.2012.11.16.02.18.16 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 02:18:17 -0800 (PST) Message-ID: <50A612E4.4090806@gmail.com> Date: Fri, 16 Nov 2012 15:48:12 +0530 From: Sujay Gupta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Donald Eastlake References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:18:20 -0000 Support. On 07-11-2012 02:12, Donald Eastlake wrote: > Hi, > > As announced at the TRILL WG meeting today, this starts a two week WG > Last Call on draft-ietf-trill-fine-labeling ending 19 November. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Fri Nov 16 09:40:54 2012 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 33F2521F84E4 for ; Fri, 16 Nov 2012 09:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMh1+P820Hti for ; Fri, 16 Nov 2012 09:40:53 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3D0921F84D8 for ; Fri, 16 Nov 2012 09:40:53 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so3242322obb.31 for ; Fri, 16 Nov 2012 09:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ancgt2f0b/JwLKPH+/gzbxXP1XYW1pSGbz1nhZUxkLc=; b=ZhO6WRlyYWk2hAIr18rleYXSJtfv8Jyzcbwp96s04migVFaja0BQbhIT+q0MyLaQEE Qvc54vp6dqvUuQjAnkYwzkdTd4P7qO6M8myFw4qQujDe6LYDDoRAsu9oYHmivDWD7J5k 9mUfSTPUoRSKi4kP1OklTMTTYyDjPZXkn8CO6GMkxgXWKMWjxmnx1nRewbo9X/KnVVug /j+Dh6un4V6hXBqgn7vaFr7/unTzHOJB+PctsaraC7yn25CeZtFlAH+7rzzGM2TM7BRS Egxr42LY2h8i7yMhhhzBkhdpVggezDD+SQycwjx6aIDDZtDgBn8OlVOUCJz5Rsm5lxDI NZZw== Received: by 10.60.10.162 with SMTP id j2mr4373831oeb.142.1353087653164; Fri, 16 Nov 2012 09:40:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.169.207 with HTTP; Fri, 16 Nov 2012 09:40:32 -0800 (PST) In-Reply-To: <1E714095C88C9D408749A723A59CF6ED1BDF057C@SJEXCHMB12.corp.ad.broadcom.com> References: <1E714095C88C9D408749A723A59CF6ED1BDF057C@SJEXCHMB12.corp.ad.broadcom.com> From: Donald Eastlake Date: Fri, 16 Nov 2012 12:40:32 -0500 Message-ID: To: Rajeev Manur Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 17:40:54 -0000 Hi Rajeev, On Wed, Nov 14, 2012 at 7:19 PM, Rajeev Manur wrote: > Support! > > I have the following editorial comments, > > * Section 4.0 > -- First line in third paragraph : FLG should be changed to FGL > -- Similar typo needs to be fixed in the 4th paragraph, LFG should be changed to FGL > * Section 5.0 It would be sort of interesting to try to include all possible permutations in the draft, but I think you are right and these should be fixed. > -- Suggest changing the following sentence as below make the intent more explicit and remove ambiguity, > > Current: "The FGL ingress process MUST place the priority and DEI associated with an ingressed native frame in upper 4 bits of the Inner.Label Low Order part." > > New: "The FGL ingress process MUST copy the priority and DEI from an ingressed native frame to upper 4 bits of the Inner.Label Low Order part." OK. > * Section 7.0 > -- I see reference to first and second part of FGL. In previous sections same fields are referred to as High and Low parts of FGL. It may be better to use one name consistently across the doc. OK. Thanks for the review and comments, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thanks! > --Rajeev > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake > Sent: Tuesday, November 06, 2012 12:43 PM > To: trill@ietf.org > Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > Hi, > > As announced at the TRILL WG meeting today, this starts a two week WG > Last Call on draft-ietf-trill-fine-labeling ending 19 November. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From ALim@extremenetworks.com Fri Nov 16 12:01:23 2012 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 9926C21F8A74 for ; Fri, 16 Nov 2012 12:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRGLk6361LlL for ; Fri, 16 Nov 2012 12:01:23 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id DC63521F8459 for ; Fri, 16 Nov 2012 12:01:12 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Fri, 16 Nov 2012 12:01:12 -0800 From: Arnel Lim To: "trill@ietf.org" Date: Fri, 16 Nov 2012 12:01:11 -0800 Thread-Topic: MTU Testing on P2P Links? Thread-Index: Ac3ENR++XNFVCnYwT5WwKmaTJqg4Ng== Message-ID: <6738A78F51650A4FAEDCF6844B26C21401B5D8ED01BF@USEXCHANGE.corp.extremenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6738A78F51650A4FAEDCF6844B26C21401B5D8ED01BFUSEXCHANGEc_" MIME-Version: 1.0 Subject: [trill] MTU Testing on P2P Links? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 20:01:23 -0000 --_000_6738A78F51650A4FAEDCF6844B26C21401B5D8ED01BFUSEXCHANGEc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is MTU Testing only done on Broadcast link types? Seems like all the ref= erences to MTU matching reference TRILL Hellos vs P2P Hellos. ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and propriet= ary material and is solely for the use of the intended recipient. Any revie= w, use, disclosure, distribution or copying of this transmittal is prohibit= ed except by or on behalf of the intended recipient. If you have received t= his transmittal in error, please notify the sender and destroy this e-mail = and any attachments and all copies, whether electronic or printed. --_000_6738A78F51650A4FAEDCF6844B26C21401B5D8ED01BFUSEXCHANGEc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is MTU Testing only done on Broadcast link types?&nb= sp;   Seems like all the references to MTU matching reference TRI= LL Hellos vs P2P Hellos.


DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet= ary material and is solely for the use of the intended recipient. Any revie= w, use, disclosure, distribution or copying of this transmittal is prohibit= ed except by or on behalf of the intended recipient. If you have received this transmittal in error, please= notify the sender and destroy this e-mail and any attachments and all copi= es, whether electronic or printed.
 --_000_6738A78F51650A4FAEDCF6844B26C21401B5D8ED01BFUSEXCHANGEc_-- From d3e3e3@gmail.com Fri Nov 16 12:10:11 2012 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 0074421F8516 for ; Fri, 16 Nov 2012 12:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BOAe7hE4r-m for ; Fri, 16 Nov 2012 12:10:10 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B74121F8477 for ; Fri, 16 Nov 2012 12:10:10 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so2158623iaf.31 for ; Fri, 16 Nov 2012 12:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1yrCuj5xfcDeKKw/QFo3YPve0YHnopite2HYVTzaUV8=; b=xlRdp0DrCWF7UaFcP3tH+S8/bUn+gzgnJTawxjfxo75TzXRLNgU389tfJ2IBvaWPJq N5Su6E6O9hmmRo29HEfhRgpCl79zhOl9X7Myz87WDlD5eBiT41R2f0AVndTIWtjFLS1P dFR588wTc/LfHSD3y7fZIEkfxJw1Ko+Zh1z6Qa2mY4GEmLXs2t5CYssWV49ydUPYQU3m IOtZgu67EtmWMdqVd9Z74k7aj4FvUj3K2olwwjlwIOTdBrSH1DnXHZdJVNkbSb4pjEYc emseOk4UzZ/fqtngIadu3nRN1Wlpvwl03axRSlT7ZE0HQIeMWLAJ7Gh39rKAJ5m2jWYT x4lg== Received: by 10.50.36.138 with SMTP id q10mr4680727igj.0.1353096610048; Fri, 16 Nov 2012 12:10:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Fri, 16 Nov 2012 12:09:49 -0800 (PST) In-Reply-To: <6738A78F51650A4FAEDCF6844B26C21401B5D8ED01BF@USEXCHANGE.corp.extremenetworks.com> References: <6738A78F51650A4FAEDCF6844B26C21401B5D8ED01BF@USEXCHANGE.corp.extremenetworks.com> From: Donald Eastlake Date: Fri, 16 Nov 2012 15:09:49 -0500 Message-ID: To: Arnel Lim Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] MTU Testing on P2P Links? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 20:10:11 -0000 Hi Amel, I believe you are correct and we should start work soon on an rfc6327bis. It should include optional MTU testing on point-to-point links and could also take into account other developments such as the support of one-hop BFD. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Nov 16, 2012 at 3:01 PM, Arnel Lim wrote: > Is MTU Testing only done on Broadcast link types? Seems like all the > references to MTU matching reference TRILL Hellos vs P2P Hellos. > > > ________________________________ > DISCLAIMER: > This e-mail and any attachments to it may contain confidential and > proprietary material and is solely for the use of the intended recipient. > Any review, use, disclosure, distribution or copying of this transmittal is > prohibited except by or on behalf of the intended recipient. If you have > received this transmittal in error, please notify the sender and destroy > this e-mail and any attachments and all copies, whether electronic or > printed. > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From aldrin.ietf@gmail.com Fri Nov 16 12:30:25 2012 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 56AEA21F85DF for ; Fri, 16 Nov 2012 12:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI7Wx4nTjRfB for ; Fri, 16 Nov 2012 12:30:24 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3121F852B for ; Fri, 16 Nov 2012 12:30:24 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2188063pbc.31 for ; Fri, 16 Nov 2012 12:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=avQKuWWuChcu3piLgwVbi5q2thp6dAu6FwA7t3zNmW8=; b=bHO62rZhKZDkNXoCioGcdf9gOAH8G4U3gsG8Sgzfg2mf3duMWxtaG7eMFebDeXUFd8 ZhwiOr23rzSJU1dwrA/Oa/+4rYeu7EG7Gr4fY5BU5Gv+tUZF3IJxe6Bon+gexZF3ZR8M T0ExtMREtL5RuVxgKwBi1V5s7e2/FrN8YdK56yAa1Gs9uMGFOJLgVbP6Er+hunCKXKDB ArAzxFstMeAlp3lnGz+dz6DxLIEGcu+Q8fa3f0czdin3BKWtesDnK6lotaB1DSc/0qNl IXQYjtIWCwkfOOK8IcwaKcpxZmdrrUosBMJpxhVJtiG2OstVA5UOrlry1WhHUE8UcRAq 89/w== Received: by 10.68.200.10 with SMTP id jo10mr18541435pbc.45.1353097824017; Fri, 16 Nov 2012 12:30:24 -0800 (PST) Received: from [192.168.253.206] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id b6sm1571216pav.33.2012.11.16.12.30.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 12:30:22 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_EBB8DFD7-5EE9-41AA-8A31-6FDB02C4A8B8" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: Date: Fri, 16 Nov 2012 12:30:21 -0800 Message-Id: <562590D1-B25A-475F-9EB5-BA2BA7F8A35B@gmail.com> References: To: Donald Eastlake X-Mailer: Apple Mail (2.1499) Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 20:30:25 -0000 --Apple-Mail=_EBB8DFD7-5EE9-41AA-8A31-6FDB02C4A8B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Authors, Please find my detailed comments (with %sam) regarding this draft. cheers -sam 1. =93This draft describes why and how Data Center TRILL networks can = be optimized by utilizing a directory assisted approach.=94. %sam =96 'How' is part of the solution document isn=92t it? =20 2. Sec 3 =96 =93Unnecessary filling of slots in MAC table of edge = RBridges RB1, due to RB1 receiving broadcast/multicast traffic (e.g. ARP/ND, cluster multicast, etc.) from end stations under other edge RBridges that are not actually communicating with any end stations attached to RB1.=94 %sam - Where is RB1? It is not indicated in the picture.=20 3. Sec 4 =96 =93If the application location information can be fed to RBridge edge nodes, in some form of Directory Service, then RBridge edge nodes won't need to flood data frames with unknown DA across the TRILL campus.=94 %sam =96 You may want to clarify here - Does flooding happen when the DA = is not present in the Directory. If not, I see a problem. How do you = account for the dropped frames. In traditional model, the frames are = broadcasted and not dropped. 4. Sec 4 =96 =93It can trust the directory to tell it where the DA is or it will discard the frame if the directory says the DA does not exist in the campus.=94 %sam- Little confused and same concern as above . Are you saying that = the frame is dropped if the DA is not present in the directory. = Shouldn=92t it flood just like in regular case? 5. Sec5 =96 =93The {list of interested RBridges} would get populated = when an RBridge queries for information, or pushed down from management systems.=94 %sam =96 Is the document describing the framework for how and when a = specific model should be used to populated. Could both pull and push = exist at the same time? 6. Sec 5.3=93Under this model, it is recommended that the ingress = RBridge simply drops a data packet (instead of flooding to TRILL campus) if the packet's destination address can't be found in the MAC&VLAN<->Egress RBridge mapping table.=94 %sam =96 What is the rationale for this recommendation? How do you know = the Directory server has upto date dB that it pushes down to RBridge? If = the dB is not consistent, wouldn=92t the unknown unicast frames get = dropped as per the above? 7. =93The detailed method and hand-shake mechanism between RBridge and = Directory Server(s) is beyond the scope of this framework draft.=94 %sam =96 How does the Directory server know whether to push, full or = partial info to an RBridge, if there is no handshake mechanism? FW = should identify those requirements. 8. %Sam - On the same lines,If there exists more than one directory = server, what are the requirements for both Push and pull models. For ex: = How does RBridge know from where to pull the data or which dir server = know to push the entries onto the RBridge? 9. For words like should, must, could you use caps SHOULD, MUST etc. = Think there is a RFC for the same. 10. Sec 5.3 "There are several options to trigger the pulling process. For example, the RBridge edge node can send a pull request whenever it receives an unknown DA, or the RBridge edge node can simply intercept all ARP/ND requests and forward them to the Directory Server(s) that has the information on where the target stations are located." %Sam - I think the options when to pull should clearly be identified and = listed, rather than as an example. 11. Sec 6. "Therefore, we suggest TRILL consider directory assisted = approach(es). This draft only describes the basic framework of using directory assisted approach for RBridge edge nodes. More complete mechanisms will be described in separate drafts." %sam - Are you saying, there are complicated mechanisms for Directory = assisted approach? What do you mean by basic FW? 12. %sam - Security considerations should take into account of securing = the dB of the directory server as well. 13. %sam - May be I am missing the bigger picture for the scope of this = draft. Draft describes two different models for directory assisted TRILL = N/w. What I fail to see in the draft is the list for requirements for = each of those. Should all the requirements be clearly identified and = laid out in the draft as well? I do not think the requirements belong in = solution document. For example: In Pull model, requirement for 'what = should happen when the request time-out? What are the requirements when = Directory server reboots? etc. I fail to see those things clearly = identified in the document. On Oct 25, 2012, at 3:55 PM, Donald Eastlake wrote: > This message begins a TRILL WG two week Last Call on the > draft-ietf-trill-directory-framework draft. >=20 > 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 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill --Apple-Mail=_EBB8DFD7-5EE9-41AA-8A31-6FDB02C4A8B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252   =93This draft describes why and how = Data Center TRILL networks can be
   optimized by utilizing = a directory assisted approach.=94.
%sam =96 'How' is part of the = solution document isn=92t it?
 
2.  =
Sec 3 =96 =93Unnecessary filling of slots in MAC table of edge =
RBridges RB1,
        =
RBridges that are not actually communicating with any =
end
%sam =
- Where is RB1? It is not indicated in the picture. =


3.  Sec 4 =96 =93If the application location =
information can
%sam =96 You may want to clarify =
here - Does flooding happen when the DA is not present in the Directory. =
If not, I see a problem. How do you account for the dropped frames. In =
traditional model, the frames are broadcasted and not =
dropped.
4.  Sec 4 =96 =93It can =
trust the directory to tell it where
         =
the DA is or it will discard the frame if the directory =
says
%sam- Little confused and same concern as above . Are you =
saying that the frame is dropped if the DA is not present in the =
directory. Shouldn=92t it flood just like in regular =
case?

5.  Sec5 =96 =93The {list of interested RBridges} =
would get populated when an
   RBridge queries for information, or pushed down =
from management
%sam =96 Is the document describing the framework for how and =
when a specific model should be used to populated. Could both pull and =
push exist at the same time?

6.  Sec 5.3=93Under =
this model, it is recommended that the ingress RBridge =
simply
   RBridge mapping table.=94
%sam =96 What is the rationale for =
this recommendation? How do you know the Directory server has upto date =
dB that it pushes down to RBridge? If the dB is not consistent, wouldn=92t=
 the unknown unicast frames get dropped as per the =
above?
7.  =93The detailed method =
and hand-shake mechanism between RBridge and Directory Server(s) is =
beyond the scope of this framework draft.=94
%sam =96 How does the Directory =
server know whether to push, full or partial info to an RBridge, if =
there is no handshake mechanism? FW should identify those =
requirements.
8.  %Sam - On the =
same lines,If there exists more than one directory server, what are the =
requirements for both Push and pull models. For ex: How does RBridge =
know from where to pull the data or which dir server know to push the =
entries onto the RBridge?

9. For =
words like should, must, could you use caps SHOULD, MUST etc. Think =
there is a RFC for the same.

10. Sec =
5.3 "There are several =
options to trigger the pulling process.
   For example, the RBridge edge node can send a pull =
request whenever
   it receives an unknown DA, or the RBridge edge node can simply
   intercept all ARP/ND requests and forward them to the Directory
   Server(s) that has the information on where the target stations are
   located."
%Sam - I think the options when =
to pull should clearly be identified and listed, rather than as an =
example.

11. Sec 6. "    This draft only =
describes the basic framework of using directory
    assisted approach for RBridge edge nodes. More complete mechanisms
    will be described in separate drafts."

%sam - Are you saying, there are complicated =
mechanisms for Directory assisted approach? What do you mean by basic =
FW?

12. %sam - Security considerations should take into =
account of securing the dB of the directory server as well.

13. %sam - May =
be I am missing the bigger picture for the scope of this draft. Draft =
describes two different models for directory assisted TRILL N/w. What I =
fail to see in the draft is the list for requirements for each of those. =
Should all the requirements be clearly identified and laid out in the =
draft as well? I do not think the requirements belong in solution =
document. For example: In Pull model, requirement for 'what should =
happen when the request time-out? What are the requirements when =
Directory server reboots? etc. I fail to see those things clearly =
identified in the =
document.


On Oct 25, 2012, = at 3:55 PM, Donald Eastlake <d3e3e3@gmail.com> = wrote:

This message begins a TRILL WG two week Last Call on = the
draft-ietf-trill-directory-framework = draft.

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
_________________= ______________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/= mailman/listinfo/trill

= --Apple-Mail=_EBB8DFD7-5EE9-41AA-8A31-6FDB02C4A8B8-- From ostokes@extremenetworks.com Sun Nov 18 09:27:34 2012 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 6AC6121F84ED for ; Sun, 18 Nov 2012 09:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6hjwwkpkC+L for ; Sun, 18 Nov 2012 09:27:33 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2869F21F84E9 for ; Sun, 18 Nov 2012 09:27:33 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p1.corp.extremenetworks.com ([10.0.4.73]) with mapi; Sun, 18 Nov 2012 09:27:32 -0800 From: Olen Stokes To: Donald Eastlake , "trill@ietf.org" Date: Sun, 18 Nov 2012 09:27:33 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3Fsf2XzNfBso/3QF2MrqC5PyYwFQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 17:27:34 -0000 Comparing the -01 and the -02 versions of this draft shows some very important changes. I understand the desire to finalize this draft. However, I am concerned that the changes in the -02 version may have created some inconsistencies in the document. There may also be opportunities to more clearly state some of the implications of the changes. =20 Section 1.1 still defines a FGL RBridge as a =B3TRILL switch that support[s= ] both FGL and VL=B2. However, Section 9 states, =B3no TRILL data frames can= be exchanged between VL and FGL RBridges=B2. It would be helpful to better describe scenarios where a FGL RBridge needs to support a VL mode of operation if a FGL RBridge cannot exchange packets with a VL RBridge. =20 Section 3 states that the default port configuration for a FGL RBridge port is VL. A scenario where this is utilized would also be helpful. =20 Otherwise, if a FGL RBridge does not have to support a VL mode of operation, a specific statement to that effect would be appropriate. =20 Section 7, Item 2, only discusses =B3Silicon Considerations=B2 from an ingress/egress point of view. It does not discuss it from a transit RBridge perspective. =20 However, there appears to be several statements in the draft that could have important effects on how existing silicon could be used for transit FGL RBridge operation. Section 5.1 states: =20 =B3An FGL ingress RBridge MAY serially TRILL unicast a multi-destination TRILL Data frame to the relevant egress TRILL switches after encapsulating it as a TRILL known unicast data frame (M=3D0)=B2. =20 This would appear to allow silicon that can TRILL forward unicast FGL packets to operate as a TRILL transit FGL node regardless of whether it can TRILL forward FGL multi-destination packets. If that is the intent, it would be helpful to state that in Section 7, Item 2. =20 Section 5.2.2 states: =20 =B3Pruning is an optimization. If a transit TRILL switch does less pruning than it could, there may be greater link utilization than strictly necessary but the campus will still operate correctly.=B2 =20 This would appear to allow silicon that can TRILL forward FGL multi-destination packets to operate as a TRILL transit FGL node regardless of whether it can prune FGL packets. If that is the intent, it would be helpful to state that in Section 7, Item 2. =20 Section 5.2.2 also discusses pruning based only on the High Part or the Low Part of a FGL. A statement about silicon that can prune based only on half of a FGL would also be helpful in Section 7, Item 2. =20 Thanks for any consideration of these items. Cheers, Olen =20 On 11/6/12 3:42 PM, "Donald Eastlake" wrote: >Hi, > >As announced at the TRILL WG meeting today, this starts a two week WG >Last Call on draft-ietf-trill-fine-labeling ending 19 November. > >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 >_______________________________________________ >trill mailing list >trill@ietf.org >https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Sun Nov 18 15:47:06 2012 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 B0E5B21F8206 for ; Sun, 18 Nov 2012 15:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v+8i0SkSsS9 for ; Sun, 18 Nov 2012 15:47:05 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7E21F8200 for ; Sun, 18 Nov 2012 15:47:05 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so6598397iec.31 for ; Sun, 18 Nov 2012 15:47:05 -0800 (PST) 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 :content-type; bh=mUW9dedP9SWcGCIo1KRwDAyZg3HhBZX+m8JXR2XjTKU=; b=q14WPGd8DqXc8fnfVYCNLbh+Td5RF6TpY7s+uTyKQ4m4DUB1BoX6mDpJL9IfatYlo3 cAqQgS8ZbmKDQTLi4BNDl+ud0XhF1qP+2pu61MbzCKHmaDy7/xjgL/pclZdfg4bVRfUM 6lHlKHQdzaSFrdmBTLe6dtYf4Smny3QI0PG/+viXe3erXZilH+VoCQ7KC3JWZd3/Nwi3 Ia7lmpd7zFGflWAWpqoEFXViqzoFes5kenuVankYoXuhQE4kIK0/fuwSt74E5HZiDeKW tqlN4qc1buf+W+QxqmGmtXauVhThDOsbOLGopx/+o5f4yQ2M9SLcMFRsyLxr8Z4291HB nipQ== Received: by 10.50.40.201 with SMTP id z9mr5178127igk.59.1353282425153; Sun, 18 Nov 2012 15:47:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Sun, 18 Nov 2012 15:46:45 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Sun, 18 Nov 2012 18:46:45 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] Fwd: Publication Requested: draft-ietf-trill-oam-req-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 23:47:06 -0000 ---------- Forwarded message ---------- From: Donald Eastlake Date: Sun, Nov 18, 2012 at 5:17 PM Subject: Publication Requested: draft-ietf-trill-oam-req-04 To: IESG Secretary , Ralph Droms Cc: trill-chairs@tools.ietf.org Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links) draft-ietf-trill-oam-req-04 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Informational, as indicated on the title page. This is a requirements documents, not a technical specification, but does include RFC 2119 language to indicate the requirements for a specification or specifications satisfying the requirements. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. The approval announcement contains the following sections: Technical Summary: The TRILL protocol current supports SNMP and BFD but those provide only limited OAM facilities. This document is the first in a planned series of documents to provide more complete OAM facilities. It gives requirements for those OAM facilities and is expected to be followed by an OAM Framework document (currently a TRILL WG draft) which is in turn expected to be followed by two detailed specifications: Fault Management (current a personal draft) and Performance Management (no draft posted at this time). While the current direction of TRILL OAM is to parallel IEEE 802.1ag, this requirement document is general independent of OAM technology and does not constrain that direction. Working Group Summary: This document originated in the TRILL OAM design team. It was adopted by a strong consensus and reviewed by the WG. Changes were made based on review in the working group and there was a good consensus to forward it for publication. Document Quality: There is significant vendor interest in more complete OAM facilities for TRILL. This document has been thoroughly reviewed. It was originated in the TRILL OAM design team and has also been reviewed by a number of IEEE 802.1 voting members who volunteered to do so in their individual capacity. In addition, it was closely reviewed several times by Thomas Narten, a former Internet Area Director. Personnel: The Document Shepherd is Donald Eastlake. The Responsible Area Director is Ralph Droms. (3) Briefly describe the review of this document that was performed by the Document Shepherd. I read through the draft carefully right after reading the "Checklist for Internet-Drafts (IDs) submitted for RFC publication". I have found only few editorial glitches that have now been fixed and the nits listed in item 11 below. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? Operations Directorate review will be helpful and has been explicitly requested, as this is an OAM requirements document. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No special concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes. (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Not every TRILL WG participant is interested in or knowledgeable about OAM but there was wide support for the document. There has been explicit support by over a dozen WG participants and no one has posted either opposing the document as a whole or opposing advancement of the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are three minor nits: [RFC4377] in not referenced in the body and should be removed from the references section. "draft-ietf-opsawg-oam-overview-06" in the references section is an old version -- probably the version number should just be removed from the partial file name. Lastly, the nits checker doesn't like it that the Authors' Addresses section is called "Contributing Authors". Also some of the entries in the Contributing Authors section are not separated by blank lines. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No. (15) Are there downward normative references (see RFC 3967)? No. This is an informational document. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. This is a requirements document and requires no IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None required. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From haoweiguo@huawei.com Mon Nov 19 01:23:54 2012 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 E992321F849F for ; Mon, 19 Nov 2012 01:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.449 X-Spam-Level: ** X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqYSgwjCGnoI for ; Mon, 19 Nov 2012 01:23:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1221F8466 for ; Mon, 19 Nov 2012 01:23:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALR74005; Mon, 19 Nov 2012 09:23:52 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 09:23:23 +0000 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 17:23:48 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.104]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 17:23:09 +0800 From: Haoweiguo To: Sujay Gupta , Donald Eastlake Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: AQHNxDUO2XdBzDCA7UC9fb45SQs5YJfw5oTv Date: Mon, 19 Nov 2012 09:23:09 +0000 Message-ID: References: , <50A612E4.4090806@gmail.com> In-Reply-To: <50A612E4.4090806@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.22.156] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: [trill] =?gb2312?b?tPC4tDogIFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi10?= =?gb2312?b?cmlsbC1maW5lLWxhYmVsaW5nLTAyLnR4dA==?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 09:23:55 -0000 U3VwcG9ydC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8 /sjLOiBTdWpheSBHdXB0YSBbc3VqYXkuaWV0ZkBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxMsTq MTHUwjE2yNUgMTg6MTgNCrW9OiBEb25hbGQgRWFzdGxha2UNCkNjOiB0cmlsbEBpZXRmLm9yZw0K 1vfM4jogUmU6IFt0cmlsbF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRyaWxsLWZpbmUtbGFi ZWxpbmctMDIudHh0DQoNClN1cHBvcnQuDQoNCg0KT24gMDctMTEtMjAxMiAwMjoxMiwgRG9uYWxk IEVhc3RsYWtlIHdyb3RlOg0KPiBIaSwNCj4NCj4gQXMgYW5ub3VuY2VkIGF0IHRoZSBUUklMTCBX RyBtZWV0aW5nIHRvZGF5LCB0aGlzIHN0YXJ0cyBhIHR3byB3ZWVrIFdHDQo+IExhc3QgQ2FsbCBv biBkcmFmdC1pZXRmLXRyaWxsLWZpbmUtbGFiZWxpbmcgZW5kaW5nIDE5IE5vdmVtYmVyLg0KPg0K PiBUaGFua3MsDQo+IERvbmFsZA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiAg IERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQo+ICAgMTU1 IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0KPiAgIGQzZTNlM0BnbWFpbC5j b20NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g dHJpbGwgbWFpbGluZyBsaXN0DQo+IHRyaWxsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw= From narten@us.ibm.com Mon Nov 19 06:59:46 2012 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 C040B21F8671 for ; Mon, 19 Nov 2012 06:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.669 X-Spam-Level: X-Spam-Status: No, score=-109.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te9GOp6OHikR for ; Mon, 19 Nov 2012 06:59:45 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4A21F85D5 for ; Mon, 19 Nov 2012 06:59:45 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Nov 2012 09:59:44 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Nov 2012 09:59:42 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 4B7CC6E8047 for ; Mon, 19 Nov 2012 09:59:41 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAJExfWM306236 for ; Mon, 19 Nov 2012 09:59:41 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAJExe5W019988 for ; Mon, 19 Nov 2012 09:59:40 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-150-139.mts.ibm.com [9.49.150.139]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAJExaXA019551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 09:59:37 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qAJExZdv001769; Mon, 19 Nov 2012 09:59:35 -0500 Message-Id: <201211191459.qAJExZdv001769@cichlid.raleigh.ibm.com> To: Erik Nordmark In-reply-to: <50A4095E.80009@acm.org> References: <50A4095E.80009@acm.org> Comments: In-reply-to Erik Nordmark message dated "Wed, 14 Nov 2012 13:13:02 -0800." Date: Mon, 19 Nov 2012 09:59:35 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12111914-7182-0000-0000-000003455351 Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 14:59:46 -0000 I have read the document, and want to raise some basic questions about this document. An original premise for this document was that it would use the same Ethertype=0x8100 encoding for the inner header as the the base protocol. This was done for backwards-compatability with base RBs and to allow non-FGL aware RBs to forward FGL frames. Under this assumption, having the labels split into two different parts using separate fields made sense. However, with the -01 revision, the above assumption has been thrown out. FGLs now use a different ethertype encoding, and various parts of the document make it clear that an RB operates in either FGL or VL mode, with no overlap or backwards compatability. RBs implementing VL are not supposed to receive or process FGL formatted TRILL data frames. Given that, I do not see a compelling justification for retaining the "double tagging" encoding format the current document supports. Specifically, I'd suggest: 1) not having separate high-order and low-order FGL fields; just define one field that is 24 bits long. 2) Remove the second ethertype=0x893B field completely. We are just wasting 2 bytes. (the field serves no useful purpose and must always hold the value of 0x893B.) 3) While I don't have a strong opinion either way, I would also like to see a justification for having an "Alternate Priority" field. The base TRILL protocol doesn't have one. Why is it needed for FGLs? Under the previous encapsulation format, we got the extra priority "for free" since it was part of the TAG, but I'd like to see the rational/use case for having this extra field stand on its own merits. Is this just a "what the heck, why not" field? Or is there a compelling use case for it? I am also uncomfortable with some of the wording in the document regarding "silicon". > 2. Silicon Considerations > > Fine-grained labeling (FGL) should, to the extent practical, use > existing features, processing, and fields that are already > supported in at least some fast path silicon implementations that > currently support the TRILL base protocol. This makes sense. We do not want to pick encodings that will be problematatic for silicon (generally). However, we also need to balance such a desire against not restricting our design solely to favor, say, one particular implementation. (I am not suggesting that is being done here, just pointing out that if the current encoding does favor certain implementations, we need to be upfront about that, and discuss the implications openly.) > 2. Silicon Considerations: Existing TRILL fast path silicon chips can > perform base TRILL Header insertion and removal to support ingress > and egress. In addition, it is believed that most such silicon > chips can also perform the native frame to FGL mapping and the > encoding of the FGL as specified herein, as well as the inverse > decoding and mapping. Some existing silicon can perform only one > of these operations on a frame in the fast path and is thus not > suitable to implement fast path TRILL FGL processing; however, > other existing chips are believed to be able to perform both > operations on the same frame in the fast path and are suitable for > FGL implementation. My impression in talking to folk familiar with silicon implementations is that silicon has gotten pretty good at being able to extract fields from fixed arbitrary offsets into a packet. Thus, while they may be able to extract the two separate labels and combine them (as the current proposal calls for), they can just as easily extract a single label of 24 bits. If we are going to stick with the current encoding, I'd like to hear directly from the silicon implementors why that is *necessary* and why they cannot support the more natural/obvious format for 24-bit labels. I have additional comments on the draft, but they may not be relevant depending on how the above points are resolved. Thomas From narten@us.ibm.com Mon Nov 19 07:39:32 2012 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 218C221F86A4 for ; Mon, 19 Nov 2012 07:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.289 X-Spam-Level: X-Spam-Status: No, score=-110.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-KnrAqjp+kf for ; Mon, 19 Nov 2012 07:39:31 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3C97B21F8683 for ; Mon, 19 Nov 2012 07:39:31 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Nov 2012 10:39:29 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Nov 2012 10:39:27 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 78240C90052 for ; Mon, 19 Nov 2012 10:39:26 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAJFdQGv273212 for ; Mon, 19 Nov 2012 10:39:26 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAJFdQBR006717 for ; Mon, 19 Nov 2012 10:39:26 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-150-139.mts.ibm.com [9.49.150.139]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAJFdO0e006542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 10:39:25 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qAJFYBqh002610; Mon, 19 Nov 2012 10:34:11 -0500 Message-Id: <201211191534.qAJFYBqh002610@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: Comments: In-reply-to Donald Eastlake message dated "Tue, 06 Nov 2012 15:42:42 -0500." Date: Mon, 19 Nov 2012 10:34:11 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12111915-7182-0000-0000-00000345C469 Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:39:32 -0000 (repost with proper subject) I have read the document, and want to raise some basic questions about this document. An original premise for this document was that it would use the same Ethertype=0x8100 encoding for the inner header as the the base protocol. This was done for backwards-compatability with base RBs and to allow non-FGL aware RBs to forward FGL frames. Under this assumption, having the labels split into two different parts using separate fields made sense. However, with the -01 revision, the above assumption has been thrown out. FGLs now use a different ethertype encoding, and various parts of the document make it clear that an RB operates in either FGL or VL mode, with no overlap or backwards compatability. RBs implementing VL are not supposed to receive or process FGL formatted TRILL data frames. Given that, I do not see a compelling justification for retaining the "double tagging" encoding format the current document supports. Specifically, I'd suggest: 1) not having separate high-order and low-order FGL fields; just define one field that is 24 bits long. 2) Remove the second ethertype=0x893B field completely. We are just wasting 2 bytes. (the field serves no useful purpose and must always hold the value of 0x893B.) 3) While I don't have a strong opinion either way, I would also like to see a justification for having an "Alternate Priority" field. The base TRILL protocol doesn't have one. Why is it needed for FGLs? Under the previous encapsulation format, we got the extra priority "for free" since it was part of the TAG, but I'd like to see the rational/use case for having this extra field stand on its own merits. Is this just a "what the heck, why not" field? Or is there a compelling use case for it? I am also uncomfortable with some of the wording in the document regarding "silicon". > 2. Silicon Considerations > > Fine-grained labeling (FGL) should, to the extent practical, use > existing features, processing, and fields that are already > supported in at least some fast path silicon implementations that > currently support the TRILL base protocol. This makes sense. We do not want to pick encodings that will be problematatic for silicon (generally). However, we also need to balance such a desire against not restricting our design solely to favor, say, one particular implementation. (I am not suggesting that is being done here, just pointing out that if the current encoding does favor certain implementations, we need to be upfront about that, and discuss the implications openly.) > 2. Silicon Considerations: Existing TRILL fast path silicon chips can > perform base TRILL Header insertion and removal to support ingress > and egress. In addition, it is believed that most such silicon > chips can also perform the native frame to FGL mapping and the > encoding of the FGL as specified herein, as well as the inverse > decoding and mapping. Some existing silicon can perform only one > of these operations on a frame in the fast path and is thus not > suitable to implement fast path TRILL FGL processing; however, > other existing chips are believed to be able to perform both > operations on the same frame in the fast path and are suitable for > FGL implementation. My impression in talking to folk familiar with silicon implementations is that silicon has gotten pretty good at being able to extract fields from fixed arbitrary offsets into a packet. Thus, while they may be able to extract the two separate labels and combine them (as the current proposal calls for), they can just as easily extract a single label of 24 bits. If we are going to stick with the current encoding, I'd like to hear directly from the silicon implementors why that is *necessary* and why they cannot support the more natural/obvious format for 24-bit labels. I have additional comments on the draft, but they may not be relevant depending on how the above points are resolved. Thomas From linda.dunbar@huawei.com Mon Nov 19 09:49:11 2012 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 DA5C821F859D for ; Mon, 19 Nov 2012 09:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvwMn-AsdVXh for ; Mon, 19 Nov 2012 09:49:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06221F86A8 for ; Mon, 19 Nov 2012 09:49:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS13178; Mon, 19 Nov 2012 17:49:03 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 17:48:33 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 17:48:59 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 09:48:57 -0800 From: Linda Dunbar To: Sam Aldrin , Donald Eastlake Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt Thread-Index: AQHNxDky/scuXvCj5EaZk4DoqUzctJfxX8OQ Date: Mon, 19 Nov 2012 17:48:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645098B90@dfweml505-mbx> References: <562590D1-B25A-475F-9EB5-BA2BA7F8A35B@gmail.com> In-Reply-To: <562590D1-B25A-475F-9EB5-BA2BA7F8A35B@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.180] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645098B90dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 17:49:12 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645098B90dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, Thanks for the comments. Answers are inserted below: From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of S= am Aldrin Sent: Friday, November 16, 2012 2:30 PM To: Donald Eastlake Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.= txt Authors, Please find my detailed comments (with %sam) regarding this draft. cheers -sam 1. "This draft describes why and how Data Center TRILL networks can be optimized by utilizing a directory assisted approach.". %sam - 'How' is part of the solution document isn't it? [Linda] Yes. We will change the text accordingly. 2. Sec 3 - "Unnecessary filling of slots in MAC table of edge RBridges RB1= , due to RB1 receiving broadcast/multicast traffic (e.g. ARP/ND, cluster multicast, etc.) from end stations under other edge RBridges that are not actually communicating with any end stations attached to RB1." %sam - Where is RB1? It is not indicated in the picture. [Linda] RB1 is just an example, how about changing the wording to "Unnecessary filling of slots in MAC table of edge RBridges, e.g. RB1, due to RB1 receiving broadcast/multicast traffic (e.g. ARP/ND, cluster multicast, etc.) from end stations under other edge RBridges that are not actually communicating with any end stations attached to RB1." 3. Sec 4 - "If the application location information can be fed to RBridge edge nodes, in some form of Directory Service, then RBridge edge nodes won't need to flood data frames with unknown DA across the TRILL campus." %sam - You may want to clarify here - Does flooding happen when the DA is n= ot present in the Directory. If not, I see a problem. How do you account fo= r the dropped frames. In traditional model, the frames are broadcasted and = not dropped. [Linda] The solution draft will specify the policy of dropping frames with = unknown DA or flooding. This paragraph is mainly to say that there is less = chance of receiving data frames with unknown DA with directory service. Wil= l change the wording accordingly. 4. Sec 4 - "It can trust the directory to tell it where the DA is or it will discard the frame if the directory says the DA does not exist in the campus." %sam- Little confused and same concern as above . Are you saying that the f= rame is dropped if the DA is not present in the directory. Shouldn't it flo= od just like in regular case? [Linda] The policy to drop or flood when entry is not in the directory shou= ld be configured as stated earlier. 5. Sec5 - "The {list of interested RBridges} would get populated when an RBridge queries for information, or pushed down from management systems." %sam - Is the document describing the framework for how and when a specific= model should be used to populated. Could both pull and push exist at the s= ame time? [Linda] Yes, both pull and push can co-exist. It is up to the configuration= . 6. Sec 5.3"Under this model, it is recommended that the ingress RBridge si= mply drops a data packet (instead of flooding to TRILL campus) if the packet's destination address can't be found in the MAC&VLAN<->Egress RBridge mapping table." %sam - What is the rationale for this recommendation? How do you know the D= irectory server has upto date dB that it pushes down to RBridge? If the dB = is not consistent, wouldn't the unknown unicast frames get dropped as per t= he above? [Linda] How about changing the wording to "it is operator's decision on if= a frame with unknown DA should be dropped or flooded when the DA doesn't e= xist in the directory" ? 7. "The detailed method and hand-shake mechanism between RBridge and Direc= tory Server(s) is beyond the scope of this framework draft." %sam - How does the Directory server know whether to push, full or partial = info to an RBridge, if there is no handshake mechanism? FW should identify = those requirements. [Linda] The detailed description is in "draft-dunbar-trill-scheme-for-direc= tory-assist-01". Do you have any suggestion on what should be described in = the framework draft? 8. %Sam - On the same lines,If there exists more than one directory server= , what are the requirements for both Push and pull models. For ex: How does= RBridge know from where to pull the data or which dir server know to push = the entries onto the RBridge? 9. For words like should, must, could you use caps SHOULD, MUST etc. Think = there is a RFC for the same. [Linda] OK 10. Sec 5.3 "There are several options to trigger the pulling process. For example, the RBridge edge node can send a pull request whenever it receives an unknown DA, or the RBridge edge node can simply intercept all ARP/ND requests and forward them to the Directory Server(s) that has the information on where the target stations are located." %Sam - I think the options when to pull should clearly be identified and li= sted, rather than as an example. [Linda] OK. Will change wording accordingly. 11. Sec 6. "Therefore, we suggest TRILL consider directory assisted approac= h(es). This draft only describes the basic framework of using directory assisted approach for RBridge edge nodes. More complete mechanisms will be described in separate drafts." %sam - Are you saying, there are complicated mechanisms for Directory assis= ted approach? What do you mean by basic FW? [Linda] Is it OK to use "more detailed mechanisms"? 12. %sam - Security considerations should take into account of securing the= dB of the directory server as well. 13. %sam - May be I am missing the bigger picture for the scope of this dra= ft. Draft describes two different models for directory assisted TRILL N/w. = What I fail to see in the draft is the list for requirements for each of th= ose. Should all the requirements be clearly identified and laid out in the = draft as well? I do not think the requirements belong in solution document.= For example: In Pull model, requirement for 'what should happen when the r= equest time-out? What are the requirements when Directory server reboots? e= tc. I fail to see those things clearly identified in the document. [Linda] We can add those requirement. Thanks. Linda On Oct 25, 2012, at 3:55 PM, Donald Eastlake > wrote: This message begins a TRILL WG two week Last Call on the draft-ietf-trill-directory-framework draft. 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 _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --_000_4A95BA014132FF49AE685FAB4B9F17F645098B90dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,

 <= /p>

Thanks for the comments. = Answers are inserted below:

 <= /p>

 <= /p>

From: trill-bo= unces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Friday, November 16, 2012 2:30 PM
To: Donald Eastlake
Cc: trill@ietf.org
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framew= ork-01.txt

 

Authors,

 

Please find my detailed comments (with %sam) regardi= ng this draft.

 

cheers

-sam

 

1.<= span style=3D"font-size:7.0pt">  “This draft describes why= and how Data Center TRILL networks can be

   optimized by uti= lizing a directory assisted approach.”.

%sam – 'How' is part of= the solution document isn’t it?

 

[Linda] Yes. We will change the text accordingly.

 

2.  Sec 3 – “Unnecessary filling of slots=
 in MAC table of edge RBridges RB1,
       &nbs=
p;due to RB1 receiving broadcast/multicast traffic (e.g. ARP/ND,=

       =
; cluster multicast, etc.) from end stations under other edge

       =
; RBridges that are not actually communicating with any end

       =
; stations attached to RB1.”


%sam - Where is RB1? It is not indicated =
in the picture. 


 


[Linda] RB1 is=
 just an example, how about changing the wording to 

̶=
0;Unnecessary filling of slots in MAC table of edge RBridges, e.g. RB=
1,


       &nbs=
p;due to RB1 receiving broadcast/multicast traffic (e.g. ARP/ND,=



       =
; cluster multicast, etc.) from end stations under other edge

       =
; RBridges that are not actually communicating with any end

       =
; stations attached to RB1.”


 


 


3.  Sec 4 – “If the application location =
information can


   be fed to RBridge edge nodes=
, in some form of Directory Service,


   then RBridge edge nodes won'=
t need to flood data frames with unknown


   DA across the TRILL campus.&=
#8221;


%sam – You may want to clarify here=
 - Does flooding happen when the DA is not present in the Directory. If not=
, I see a problem. How do you account for the dropped frames. In traditiona=
l model, the frames are broadcasted and not dropped.


 


[Linda] The so=
lution draft will specify the policy of dropping frames with unknown DA or =
flooding. This paragraph is mainly to say that there is less chance of rece=
iving data frames with unknown DA with directory service. Will change the w=
ording accordingly. 


 


 


4.  Sec 4 – “It can trust the directory t=
o tell it where


       =
;  the DA is or it will discard the frame if the directory says


       =
;  the DA does not exist in the campus.”


%sam- Little confused and same concern as=
 above . Are you saying that the frame is dropped if the DA is not present =
in the directory. Shouldn’t it flood just like in regular case?<=
/o:p>


 


[Linda] The po=
licy to drop or flood when entry is not in the directory should be configur=
ed as stated earlier. 


 


5.  Sec5 – “The {list of interested RBrid=
ges} would get populated when an


   RBridge queries for informat=
ion, or pushed down from management


   systems.”

%sam – Is the document describing t=
he framework for how and when a specific model should be used to populated.=
 Could both pull and push exist at the same time?


 =



[Linda] Yes, b=
oth pull and push can co-exist. It is up to the configuration. <=
/span>


 


6.  Sec 5.3“Under this model, it is recommended=
 that the ingress RBridge simply


   drops a data packet (instead=
 of flooding to TRILL campus) if the


   packet's destination address=
 can't be found in the MAC&VLAN<->Egress


   RBridge mapping table.”=
;


%sam – What is the rationale for th=
is recommendation? How do you know the Directory server has upto date dB th=
at it pushes down to RBridge? If the dB is not consistent, wouldn’t t=
he unknown unicast frames get dropped as per the above?


 


[Linda] How ab=
out changing  the wording to “it is operator’s decision on=
 if a frame with unknown DA should be dropped or flooded when the DA doesn&=
#8217;t exist in the directory” ?


 


 


7.  “The detailed method and hand-shake mechani=
sm between RBridge and Directory Server(s) is beyond the scope of this fram=
ework draft.”


%sam – How does the Directory serve=
r know whether to push, full or partial info to an RBridge, if there is no =
handshake mechanism? FW should identify those requirements.

 


[Linda] The de=
tailed description is in “draft-dunbar-trill-scheme-for-directory-ass=
ist-01”. Do you have any suggestion on what should be described in th=
e framework draft? 


 


8.  %Sam - On the same lines,If there exists mor=
e than one directory server, what are the requirements for both Push and pu=
ll models. For ex: How does RBridge know from where to pull the data or whi=
ch dir server know to push the entries onto the RBridge?



<=
br>


9. Fo=
r words like should, must, could you use caps SHOULD, MUST etc. Think there=
 is a RFC for the same.


 


[Linda] OK



<=
br>


10. S=
ec 5.3 "There are several options to trigger the pulling process.=



 &nb=
sp; For example, the RBridge edge node can send a pull request whenever


 &nb=
sp; it receives an unknown DA, or the RBridge edge node can simply


 &nb=
sp; intercept all ARP/ND requests and forward them to the Directory


 &nb=
sp; Server(s) that has the information on where the target stations are


 &nb=
sp; located."


%Sam - I =
think the options when to pull should clearly be identified and listed, rat=
her than as an example.


 


[Linda] OK. Wi=
ll change wording accordingly. 


 


11. Sec 6=
. "Therefore, we suggest TRILL consider directory assisted approach(es=
).


 &nb=
sp;  This draft only describes the basic framework of using directory<=
o:p>


 &nb=
sp;  assisted approach for RBridge edge nodes. More complete mechanism=
s


 &nb=
sp;  will be described in separate drafts."

%sam - Ar=
e you saying, there are complicated mechanisms for Directory assisted appro=
ach? What do you mean by basic FW?


 


[Linda] Is it =
OK to use “more detailed mechanisms”? 


&nbs=
p;


12. %sam =
- Security considerations should take into account of securing the dB of th=
e directory server as well.


&nbs=
p;


13. %sam =
- May be I am missing the bigger picture for the scope of this draft. Draft=
 describes two different models for directory assisted TRILL N/w. What I fa=
il to see in the draft is the list for requirements for each of those. Shou=
ld all the requirements be clearly identified and laid out in the draft as =
well? I do not think the requirements belong in solution document. For exam=
ple: In Pull model, requirement for 'what should happen when the request ti=
me-out? What are the requirements when Directory server reboots? etc. I fai=
l to see those things clearly identified in the document.=





 


[Linda] We can add those =
requirement. Thanks.



 <=
/p>

Linda







 








On Oct 25, 2012, at 3:55 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:=












This message begins a TRILL WG two week Last Call on=
 the

draft-ietf-trill-directory-framework draft.



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

_______________________________________________

trill mailing list

trill@ietf.org

https://www.ietf.org/mailman/listinfo/trill




 
--_000_4A95BA014132FF49AE685FAB4B9F17F645098B90dfweml505mbx_-- From linda.dunbar@huawei.com Mon Nov 19 12:53:18 2012 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 CD95D21F8753 for ; Mon, 19 Nov 2012 12:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryDUKAUfDjND for ; Mon, 19 Nov 2012 12:53:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C249921F8768 for ; Mon, 19 Nov 2012 12:53:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMY36101; Mon, 19 Nov 2012 20:53:12 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 20:52:42 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 20:53:09 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 12:53:06 -0800 From: Linda Dunbar To: Thomas Narten , Erik Nordmark Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt Thread-Index: AQHNwqzc/scuXvCj5EaZk4DoqUzctJfxzbyA///cWTA= Date: Mon, 19 Nov 2012 20:53:05 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645098C4C@dfweml505-mbx> References: <50A4095E.80009@acm.org> <201211191459.qAJExZdv001769@cichlid.raleigh.ibm.com> In-Reply-To: <201211191459.qAJExZdv001769@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:53:18 -0000 Thomas,=20 Your comments are for "fine labeling" draft but not to "directory framework= ", is it?=20 Linda > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Thomas Narten > Sent: Monday, November 19, 2012 9:00 AM > To: Erik Nordmark > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory- > framework-01.txt >=20 > I have read the document, and want to raise some basic questions about > this document. >=20 > An original premise for this document was that it would use the same > Ethertype=3D0x8100 encoding for the inner header as the the base > protocol. This was done for backwards-compatability with base RBs and > to allow non-FGL aware RBs to forward FGL frames. Under this > assumption, having the labels split into two different parts using > separate fields made sense. >=20 > However, with the -01 revision, the above assumption has been thrown > out. FGLs now use a different ethertype encoding, and various parts of > the document make it clear that an RB operates in either FGL or VL > mode, with no overlap or backwards compatability. RBs implementing VL > are not supposed to receive or process FGL formatted TRILL data > frames. >=20 > Given that, I do not see a compelling justification for retaining the > "double tagging" encoding format the current document > supports. Specifically, I'd suggest: >=20 > 1) not having separate high-order and low-order FGL fields; just > define one field that is 24 bits long. >=20 > 2) Remove the second ethertype=3D0x893B field completely. We are just > wasting 2 bytes. (the field serves no useful purpose and must always > hold the value of 0x893B.) >=20 > 3) While I don't have a strong opinion either way, I would also like > to see a justification for having an "Alternate Priority" field. The > base TRILL protocol doesn't have one. Why is it needed for FGLs? >=20 > Under the previous encapsulation format, we got the extra priority > "for free" since it was part of the TAG, but I'd like to see the > rational/use case for having this extra field stand on its own > merits. Is this just a "what the heck, why not" field? Or is there a > compelling use case for it? >=20 > I am also uncomfortable with some of the wording in the document > regarding "silicon". >=20 > > 2. Silicon Considerations > > > > Fine-grained labeling (FGL) should, to the extent practical, > use > > existing features, processing, and fields that are already > > supported in at least some fast path silicon implementations > that > > currently support the TRILL base protocol. >=20 > This makes sense. We do not want to pick encodings that will be > problematatic for silicon (generally). However, we also need to > balance such a desire against not restricting our design solely to > favor, say, one particular implementation. (I am not suggesting that > is being done here, just pointing out that if the current encoding > does favor certain implementations, we need to be upfront about that, > and discuss the implications openly.) >=20 > > 2. Silicon Considerations: Existing TRILL fast path silicon chips > can > > perform base TRILL Header insertion and removal to support > ingress > > and egress. In addition, it is believed that most such silicon > > chips can also perform the native frame to FGL mapping and the > > encoding of the FGL as specified herein, as well as the inverse > > decoding and mapping. Some existing silicon can perform only > one > > of these operations on a frame in the fast path and is thus not > > suitable to implement fast path TRILL FGL processing; however, > > other existing chips are believed to be able to perform both > > operations on the same frame in the fast path and are suitable > for > > FGL implementation. >=20 > My impression in talking to folk familiar with silicon implementations > is that silicon has gotten pretty good at being able to extract fields > from fixed arbitrary offsets into a packet. Thus, while they may be > able to extract the two separate labels and combine them (as the > current proposal calls for), they can just as easily extract a single > label of 24 bits. >=20 > If we are going to stick with the current encoding, I'd like to hear > directly from the silicon implementors why that is *necessary* and why > they cannot support the more natural/obvious format for 24-bit labels. >=20 > I have additional comments on the draft, but they may not be relevant > depending on how the above points are resolved. >=20 > Thomas >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From narten@us.ibm.com Mon Nov 19 14:09:14 2012 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 BD56721F84FC for ; Mon, 19 Nov 2012 14:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.367 X-Spam-Level: X-Spam-Status: No, score=-110.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfSkRStBIYJu for ; Mon, 19 Nov 2012 14:09:14 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 0489521F84F9 for ; Mon, 19 Nov 2012 14:09:13 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Nov 2012 17:09:08 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Nov 2012 17:08:50 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 938E56E8036 for ; Mon, 19 Nov 2012 17:08:49 -0500 (EST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAJM8mND192616 for ; Mon, 19 Nov 2012 17:08:49 -0500 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAJM8l3C011592 for ; Mon, 19 Nov 2012 15:08:47 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-150-139.mts.ibm.com [9.49.150.139]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAJM8gBY011366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 15:08:44 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qAJM87O1007297; Mon, 19 Nov 2012 17:08:07 -0500 Message-Id: <201211192208.qAJM87O1007297@cichlid.raleigh.ibm.com> To: "Tissa Senevirathne (tsenevir)" In-reply-to: References: Comments: In-reply-to "Tissa Senevirathne (tsenevir)" message dated "Fri, 09 Nov 2012 00:51:35 +0000." Date: Mon, 19 Nov 2012 17:08:07 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12111922-9360-0000-0000-00000CF9A261 Cc: "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 22:09:14 -0000 Hi. I've got a fairly basic question about this document. What exact customer/deployment scenario is it trying to address? It says: > This document specifies a concept of Affinity sub-TLV to solve > associated RPF issues at the active-active edge. Specific methods in > this document for making use of the Affinity sub-TLV are applicable > where multiple RBridges are connected to an edge device through link > aggregation or to a multiport server or some similar arrangement > where the RBridges cannot see each other's Hellos. I view Link Aggregation Groups (LAGs) as an L2 construct that would be hidden from TRILL. I.e., in Ethernet, LAG is used to "hide" the presence of multiple links between a pair of switches from STP, so STP only sees one link (the LAG) rather than the individual links. Thus, I would expect RBs to want to only know of a single link (i.e., the LAG) and not have any understanding that the link may actually be a LAG. Moreover, Figure 1 is not describing LAG, but multi-chassis LAG (MLAG). MLAG is not standardized (all implementations are proprietary and there is no interoperability between vendors). Moreover, MLAG implementations are pretty restricted -- last I checked, MLAG products were limited to only 2 switches. So the figure in the document showing MLAG involving an arbitrary number of "N" switches seems a stretch. Do I have the right understanding of what is meant by "LAG" in the draft? The idea that RBs would be aware of individual links within a LAG kind of defeats the purpose of having LAGs. Is that really what is being proposed? Thomas From iesg-secretary@ietf.org Mon Nov 19 16:19:26 2012 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 4436C21E804A; Mon, 19 Nov 2012 16:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvY61gehACwz; Mon, 19 Nov 2012 16:19:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A3121E8048; Mon, 19 Nov 2012 16:19:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121120001925.2282.74416.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 16:19:25 -0800 Cc: trill mailing list , trill chair , RFC Editor Subject: [trill] Protocol Action: 'Definitions of Managed Objects for RBridges (Routing Bridges)' to Proposed Standard (draft-ietf-trill-rbridge-mib-09.txt) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 00:19:26 -0000 The IESG has approved the following document: - 'Definitions of Managed Objects for RBridges (Routing Bridges)' (draft-ietf-trill-rbridge-mib-09.txt) as Proposed Standard This document is the product of the Transparent Interconnection of Lots of Links Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/ Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing RBridges, which are devices that implement the TRILL base protocol standard. Working Group Summary There was some controversy on the WG mailing list concerning MIB structure but this turned out to be a misunderstanding and has been resolved. The document now has WG consensus. Document Quality This document has been reviewed by Dan Romascanu and revised according to his review. Dan is now satisfied with the document. Personnel Donald Eastlake is the Document Shepherd. Ralph Droms is the responsible Area Director. From d3e3e3@gmail.com Mon Nov 19 17:19:23 2012 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 C3A8421F863A for ; Mon, 19 Nov 2012 17:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggeHpR0d7Ikt for ; Mon, 19 Nov 2012 17:19:22 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEEC821E8045 for ; Mon, 19 Nov 2012 17:19:22 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so348817ieb.31 for ; Mon, 19 Nov 2012 17:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=drx5RdE+tEyIx34Y9S285r8QnICIzmoa2zzk8AaSJmA=; b=PaOH9SRobY6o87/IR2EJBiqBJ0gRO6DiPG40kog9OV1KAilIX425RS5fgIm+Fy/d1r GpAcx7z+OUpZPpV1cA/bIc1BjGt8vzqKZCRyBjDYyd5ck5dD6uM9X9/RCulGKHqrZB7q tBetYpF0mK5uf5NQgPDyhM8MhD9o6JOzVJzu3vREYXiD1U4JhIGykhrgB6+KBDrNsB+K oiCvQ5AKVxHz9Hvgg/c9Bo2Kv32aRaccnv5MSIl/8LDBK/O5PjUQ6G2ZD4Vk0cz8iMHF izietFG8QjmrhCy4qY1jdIfWQKqZVuM6nOraMXx/iY6zphj4gepsfifv7PftsX5xAUP+ KLpw== Received: by 10.50.42.132 with SMTP id o4mr8435707igl.73.1353374362151; Mon, 19 Nov 2012 17:19:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Mon, 19 Nov 2012 17:19:01 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Mon, 19 Nov 2012 20:19:01 -0500 Message-ID: To: Olen Stokes Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 01:19:23 -0000 Hi Olen, Thanks for the comments. See responses below. On Sun, Nov 18, 2012 at 12:27 PM, Olen Stokes wrote: > > Comparing the -01 and the -02 versions of this draft shows some very > important changes. I agree. > I understand the desire to finalize this draft. > However, I am concerned that the changes in the -02 version may have > created some inconsistencies in the document. There may also be > opportunities to more clearly state some of the implications of the > changes. I don't think there are any inconsistencies. However, it is certainly possible that some clarifications and/or editorial changes would improve the draft. > Section 1.1 still defines a FGL RBridge as a "TRILL switch that > support[s] both FGL and VL". However, Section 9 states, "no TRILL > data frames can be exchanged between VL and FGL RBridges". It would > be helpful to better describe scenarios where a FGL RBridge needs to > support a VL mode of operation if a FGL RBridge cannot exchange > packets with a VL RBridge. Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and support VLAN Labeling (VL) as the inner data label. In other words, an FGL RBridge must be able to ingress a native frame to an FGL TRILL data frame, handle an FGL TRILL data frame as a transit switch, and egress an FGL TRILL data frame to a native frame. In addition, an FGL RBridge must be able to ingress a native frame to a VL TRILL data frame, handle a VL TRILL data frame as a transit switch, and egress a VL TRILL data frame as a native frame, all this VL stuff as described in the TRILL base protocol RFC 6325. So an FGL RBridge can safely handle VL data traffic. But if you give an FGL data frame to a VL RBridge, it is very likely to be mishandled. This problem with VL RBridges, which by definition are FGL ignorant, is the reason for not allowing TRILL data traffic between FGL and VL RBridges. > Section 3 states that the default port configuration for a FGL > RBridge port is VL. A scenario where this is utilized would also be > helpful. Here are three uses that come to mine immediately: - If you are upgrading a campus from VL to FGL RBridges, it might be some time, if ever, before you configured connectivity between all end stations to make use of FGL. In the mean time, you would want VL to continue working. - It would be possible to standardize data connection between VL and FGL RBridges if it was specified how to do multi-topology. You could then have one topology with just FGL RBridges and a second topology with all RBridges. As long as FGL frames were limited to the FGL topology and that topology was fully connected, all would be well. Requiring FGL RBridges to support VL maintains this as a future possibility by merely adding multi-topology. Otherwise you would have to both add multi-topology and retro-fit VL support. - Due to the way TRILL works, it appears that it will be desirable to have a maintenance VLAN in which all RBridges in a campus indicate interest (see, for example, draft-ietf-trill-oam-framework). You could, I suppose, have a maintenance FGL but it might as well work the same way for a VL campus as for an FGL campus. > Otherwise, if a FGL RBridge does not have to support a VL mode of > operation, a specific statement to that effect would be appropriate. The current FGL draft, just like all previous versions of the FGL WG and preceeding personal draft, does require support of VL by FGL RBridges. Since you specifically talk about -01 to -02 changes, you might not it is not a change that just appeared in the current version. > Section 7, Item 2, only discusses "Silicon Considerations" from an > ingress/egress point of view. It does not discuss it from a transit > RBridge perspective. Good point, transit processing should be mentioned briefly in Section 7, Item 2. However, the items in Section 7 are parallel with the same number items in Section 2.1 and are just intended to discuss the extent to which the goals in 2.1 are met, not to be a complete discussion or summary of the named topics... Perhpas "Silicon Considerations" should be replaced with "Silicon Goal". > However, there appears to be several statements in the draft that > could have important effects on how existing silicon could be used > for transit FGL RBridge operation. Section 5.1 states: > > "An FGL ingress RBridge MAY serially TRILL unicast a > multi-destination TRILL Data frame to the relevant egress TRILL > switches after encapsulating it as a TRILL known unicast data frame > (M=0)". > > This would appear to allow silicon that can TRILL forward unicast > FGL packets to operate as a TRILL transit FGL node regardless of > whether it can TRILL forward FGL multi-destination packets. If that > is the intent, it would be helpful to state that in Section 7, Item > 2. Your statement seems a odd to me. I don't understand what you mean when you say "regardless of whether it can TRILL forward FGL multi-destination packets". If it can't do that, I don't think it is an FGL RBridge. An FGL RBridge is required to be able to forward known unicast data that is TRILL unicast (M=0), multi-destination data that is TRILL multicast (M=1), and, due to the text you quote, multi-destination data that is TRILL unicast (M=0). Since your specifically talk about -01 to -02 changes, you might note that this has been required in all previous versions of the FGL WG draft and preceeding personal draft. It is not a change that just appeared in the current -02 version. > Section 5.2.2 states: > > "Pruning is an optimization. If a transit TRILL switch does less > pruning than it could, there may be greater link utilization than > strictly necessary but the campus will still operate correctly." > > This would appear to allow silicon that can TRILL forward FGL > multi-destination packets to operate as a TRILL transit FGL node > regardless of whether it can prune FGL packets. If that is the > intent, it would be helpful to state that in Section 7, Item 2. Pruning is a SHOULD in the base TRILL protocol standard and it is the same here. The provisions here are similar to those in the base standard for VL pruning. I don't see any problem adding something to clarify although I don't think Section 7, Item 2, is the best place. How about just adding, at the end of the last sentence in Section 5.2.2, the following words "or not prune FGL frames at all"? > Section 5.2.2 also discusses pruning based only on the High Part or > the Low Part of a FGL. A statement about silicon that can prune > based only on half of a FGL would also be helpful in Section 7, Item > 2. But the whole point is that, since pruning is just a SHOULD optimization, the silicon could prune on whatever subset of FGL bits it feels like and still be conformant. For example, it could prune on just the highest order bit or just the highest order byte of the FGL or something. How about, including the addition above, changing "For example, a transit TRILL switch could prune based on only part of the FGL such as only the High Part or only the Low Part." to "A transit TRILL switch could prune based on an arbitrary subset of the FGL label bits, such as only the High Part or only the Low Part, or not prune FGL frames at all." Actually an RBridge could adopte even more strange or exotic pruning methods, although I can't see why it would want to. For example, it could prune based on the data label value modulo some arbitrary integer divisor less than the maximum label value...sort of a ridiculous thing to do but frames would still be routed correctly so I believe such behavior is allowed. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thanks for any consideration of these items. > > Cheers, > Olen > > > > On 11/6/12 3:42 PM, "Donald Eastlake" wrote: > >>Hi, >> >>As announced at the TRILL WG meeting today, this starts a two week WG >>Last Call on draft-ietf-trill-fine-labeling ending 19 November. >> >>Thanks, >>Donald >>============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com From d3e3e3@gmail.com Mon Nov 19 17:23:58 2012 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 C7CA821F87EA for ; Mon, 19 Nov 2012 17:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BuFGvRmkU1M for ; Mon, 19 Nov 2012 17:23:58 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5012B21E803C for ; Mon, 19 Nov 2012 17:23:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so353291ieb.31 for ; Mon, 19 Nov 2012 17:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Dj7PdEHVaTNnR7kgpEA1ris//7/wlVoESG2LU2uO/6A=; b=pQyCJKd+jcbCkRJjvvbyFTN1Fn/0c+e7U/1aG3veEkwnqivZqvhznYFZ/LoW2bWdAx mBG7sTsH2IeddnRfSSYn/isIT0pMLyt0z4AVzjTxCSlT1GZVauCiaKfgYpJur0PfFyLa WV2gaBgbSqX3kZZsO2A2P3XfwhyAreYT91PSQeztQNi4k4Rf9T/bMLLAAxEanbyD0NvU uGzV5HSBJ6ImXRRmlugsE44bR7gZ27wkl69tR697I3qFzhx7g4Wbtq4TF6bblsI1RMrP aTtGnXGG5z96cqnqzWMvq/e2osoFh2DDnzbpxUNGMFThL1ZNhbttUSaTkuxmRx6uctk8 yY3A== Received: by 10.50.159.229 with SMTP id xf5mr8633980igb.0.1353374637955; Mon, 19 Nov 2012 17:23:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Mon, 19 Nov 2012 17:23:37 -0800 (PST) From: Donald Eastlake Date: Mon, 19 Nov 2012 20:23:37 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] Ethertype for RBridge Channel has been assigned X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 01:23:58 -0000 Note that the IEEE Registration Authority has assigned the following as the Ethertype used in draft-ietf-trill-rbridge-channel for RBridge Channel. 0x8946 Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From narten@us.ibm.com Mon Nov 19 17:40:59 2012 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 4F89321F8790 for ; Mon, 19 Nov 2012 17:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NowgnUxfBtmQ for ; Mon, 19 Nov 2012 17:40:58 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4624121F8794 for ; Mon, 19 Nov 2012 17:40:58 -0800 (PST) Received: from /spool/local by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Nov 2012 20:40:56 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e2.ny.us.ibm.com (192.168.1.102) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Nov 2012 20:40:35 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3BCC438C8042 for ; Mon, 19 Nov 2012 20:40:35 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAK1eYtI277836 for ; Mon, 19 Nov 2012 20:40:34 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAK1eXbH005655 for ; Mon, 19 Nov 2012 23:40:34 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-49-150-139.mts.ibm.com [9.49.150.139]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAK1eV5o005535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 23:40:32 -0200 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qAK1eSD0011029; Mon, 19 Nov 2012 20:40:28 -0500 Message-Id: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: Comments: In-reply-to Donald Eastlake message dated "Mon, 19 Nov 2012 20:19:01 -0500." Date: Mon, 19 Nov 2012 20:40:27 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112001-5112-0000-0000-00000EBEC955 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 01:40:59 -0000 Hi. Donald Eastlake writes: > Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and > support VLAN Labeling (VL) as the inner data label. In other words, an > FGL RBridge must be able to ingress a native frame to an FGL TRILL > data frame, handle an FGL TRILL data frame as a transit switch, and > egress an FGL TRILL data frame to a native frame. In addition, an FGL > RBridge must be able to ingress a native frame to a VL TRILL data > frame, handle a VL TRILL data frame as a transit switch, and egress a > VL TRILL data frame as a native frame, all this VL stuff as described > in the TRILL base protocol RFC 6325. I'm still a bit confused by this discussion. My understanding (from reading the draft earlier today) was that an RB either operates in FGL mode or VL mode. It doesn't mix and match. I.e., you don't have an RB with some ports understanding FGL and others VL. (To do that, you'd an RB would have to convert between the the two formats which could result in loss of information...) And the way to look at VL mode, is that it is the fallback for the case where not all of the RBs in the compus are FGL capable. Is my understanding correct? Skimming the document again, this could perhaps be clearer. I.e., what is supposed o happen in a campus where some RBs say they do FGL and others do not? Is the intention that one TRILL campus gets formed with all nodes falling back to VL mode? Thomas From d3e3e3@gmail.com Mon Nov 19 19:24:51 2012 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 B90F621F881D for ; Mon, 19 Nov 2012 19:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKT-MQsMKXkF for ; Mon, 19 Nov 2012 19:24:51 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D15221F881C for ; Mon, 19 Nov 2012 19:24:51 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so467166ieb.31 for ; Mon, 19 Nov 2012 19:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zcrHDWJRur4aCL2SPM5Aox3lQ8xkDFp7ucz0aTYwk8Q=; b=ErM66XwzDcydnLITq9dGsN4c6WWPrnkjs276H9+NhxDlqPQeWdcR1CJSPvLBGm+uOO fnGtGOGaNUPp1UGUyYbAmXvkzlxIL25hrpPbwsYmfUZDucCOqlY4UcKvLMLHyodETHcC IQ2ekSA3ajRfJg/dV0cVkBLYLk//B1RY+bJbnoaz4nRvm+jkka5iVKXjBTbqcKFgUcnF jOjJLZ9W1KwAQqapPpL8G9Ng08Ah1hwOXzIHXPQimMHDHoQr9LI5GoTGX8F8xbr+VqjG CdTUy5inM0fxCSMZsRuYIxRK7Jh9fovE1BHYWXjR5YxfHJkTo5FxPLJHLDRSMS0nBzih u78g== Received: by 10.50.159.229 with SMTP id xf5mr8840023igb.0.1353381890536; Mon, 19 Nov 2012 19:24:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Mon, 19 Nov 2012 19:24:29 -0800 (PST) In-Reply-To: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Mon, 19 Nov 2012 22:24:29 -0500 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 03:24:51 -0000 Hi Thomas, I guess the draft is not as clear as I thought it was. On Mon, Nov 19, 2012 at 8:40 PM, Thomas Narten wrote: > Hi. > > Donald Eastlake writes: > >> Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and >> support VLAN Labeling (VL) as the inner data label. In other words, an >> FGL RBridge must be able to ingress a native frame to an FGL TRILL >> data frame, handle an FGL TRILL data frame as a transit switch, and >> egress an FGL TRILL data frame to a native frame. In addition, an FGL >> RBridge must be able to ingress a native frame to a VL TRILL data >> frame, handle a VL TRILL data frame as a transit switch, and egress a >> VL TRILL data frame as a native frame, all this VL stuff as described >> in the TRILL base protocol RFC 6325. > > I'm still a bit confused by this discussion. > > My understanding (from reading the draft earlier today) was that an RB > either operates in FGL mode or VL mode. It doesn't mix and > match. I.e., you don't have an RB with some ports understanding FGL > and others VL. (To do that, you'd an RB would have to convert between > the the two formats which could result in loss of information...) So what exactly did you think text like the following meant: "An FGL RBridge MAY be configured, on one or more ports, to ingress native frames as FGL. Any ports not so configured that accepts a native frame perform the previously specified VL ingress processing on native frames [RFC6325]." I also can't see why you would think that the ability to ingress, transit, and egress both VL and FGL frames implies having to "convert" between those formats. The whole idea of data labeling is separation/isolation. Why would you convert between them anymore than you would convert between a random pair of different VLANs? Anyway, the intent is that ports operate in either VL or FGL mode. And all the ports of a VL RBridge are VL ports. But an FGL RBridge is required to support an arbitrary mix of VL and FGL ports. VL and FGL frames are ships in the night just like VL frames for different VLANs for FGL frames for different FGLs. > And the way to look at VL mode, is that it is the fallback for the > case where not all of the RBs in the compus are FGL capable. The word "mode" does not occur anywhere in the body of the draft. FGL RBridges are supersets. FGL RBridges can handle VL frames fine. It is just that VL RBridges can't handle FGL frames and it is very hard to guarantee that an FGL frame will never be routed to a VL RBridge without either multi-topology (which is not yet fully specified for TRILL) or stopping all data flow between VL and FGL RBridges (whcih is what this draft does). > Is my understanding correct? See above. > Skimming the document again, this could perhaps be clearer. I guess so. > I.e., what is supposed o happen in a campus where some RBs say they do > FGL and others do not? Is the intention that one TRILL campus gets > formed with all nodes falling back to VL mode? As stated in the draft, the assumption in that case is that you wanted a completely FGL campus and whatever VL RBridges are present are isolated misconfigurations. So the provisions are that all the RBridges peer for control but VL and FGL RBridges do not peer for data. You don't want the attachment of one RBridge misconfigured to be a VL RBridge to kill your whole FGL campus. You can't "fall back" a port configured for FGL without violating security policy. Maybe clarifying text should be added and the "FGL RBridges" should be referred to as "FGLVL RBridges". Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thomas > From radiaperlman@gmail.com Mon Nov 19 20:13:37 2012 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 BA68521F8950 for ; Mon, 19 Nov 2012 20:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naXeB9nyHVOb for ; Mon, 19 Nov 2012 20:13:36 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40E6821F8835 for ; Mon, 19 Nov 2012 20:13:36 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6395245vbb.31 for ; Mon, 19 Nov 2012 20:13:35 -0800 (PST) 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:content-type; bh=ZxgMSU3SudoizQDTBStZQHKQpOsxap0QGXXO3Fb6dls=; b=dJtlXjmj9KpOv7zZG0ZgIBdXgCd8H/OKWfD2F5nBCVM7xm+GTS7laVLEi+aNbxOVbO W1wfCwe3/YIrLd5+5KqYkojdvy4kjh5/rldYwQFiRdnp7uw3o6/6e6iA5PzL3RYru2Pn uJjt24v3xUeMyQvS3h1vow/luk3Gh8KVo3vZTb9IVZRITP0EnvgecDVhDJtoGdHZX5da Go8AnAnH11rlehLN0bcqXRlEEY+zW5YMspb+L4v2jypL27FMOL37C/LS1nPTmkAv1fPn 1M5hNulxxXlS5JOAhaqhi8YpmPXb9BaPNaR2+2dqYC4ip5eHtuuKBVnX4LIkY4UPIknq oKPA== MIME-Version: 1.0 Received: by 10.52.22.240 with SMTP id h16mr600933vdf.82.1353384815633; Mon, 19 Nov 2012 20:13:35 -0800 (PST) Received: by 10.58.85.65 with HTTP; Mon, 19 Nov 2012 20:13:35 -0800 (PST) In-Reply-To: References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> Date: Mon, 19 Nov 2012 20:13:35 -0800 Message-ID: From: Radia Perlman To: Donald Eastlake Content-Type: multipart/alternative; boundary=20cf3079bb0a2e23b904cee57550 Cc: Thomas Narten , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 04:13:37 -0000 --20cf3079bb0a2e23b904cee57550 Content-Type: text/plain; charset=ISO-8859-1 Ah. So the intent is that an FGL RBridge must be able to parse either VL or FGL, which would allow an edge RB that only supports VL to work OK, and to have some number of VLANs (4000 of them) that would be reachable via old edge RBs? And we're assuming that old edge RBs that only do VL will know to drop something tagged with FGL? Radia On Mon, Nov 19, 2012 at 7:24 PM, Donald Eastlake wrote: > Hi Thomas, > > I guess the draft is not as clear as I thought it was. > > On Mon, Nov 19, 2012 at 8:40 PM, Thomas Narten wrote: > > Hi. > > > > Donald Eastlake writes: > > > >> Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and > >> support VLAN Labeling (VL) as the inner data label. In other words, an > >> FGL RBridge must be able to ingress a native frame to an FGL TRILL > >> data frame, handle an FGL TRILL data frame as a transit switch, and > >> egress an FGL TRILL data frame to a native frame. In addition, an FGL > >> RBridge must be able to ingress a native frame to a VL TRILL data > >> frame, handle a VL TRILL data frame as a transit switch, and egress a > >> VL TRILL data frame as a native frame, all this VL stuff as described > >> in the TRILL base protocol RFC 6325. > > > > I'm still a bit confused by this discussion. > > > > My understanding (from reading the draft earlier today) was that an RB > > either operates in FGL mode or VL mode. It doesn't mix and > > match. I.e., you don't have an RB with some ports understanding FGL > > and others VL. (To do that, you'd an RB would have to convert between > > the the two formats which could result in loss of information...) > > So what exactly did you think text like the following meant: > "An FGL RBridge MAY be configured, on one or more ports, to ingress > native frames as FGL. Any ports not so configured that accepts a > native frame perform the previously specified VL ingress processing > on native frames [RFC6325]." > > I also can't see why you would think that the ability to ingress, > transit, and egress both VL and FGL frames implies having to "convert" > between those formats. The whole idea of data labeling is > separation/isolation. Why would you convert between them anymore than > you would convert between a random pair of different VLANs? > > Anyway, the intent is that ports operate in either VL or FGL mode. And > all the ports of a VL RBridge are VL ports. But an FGL RBridge is > required to support an arbitrary mix of VL and FGL ports. VL and FGL > frames are ships in the night just like VL frames for different VLANs > for FGL frames for different FGLs. > > > And the way to look at VL mode, is that it is the fallback for the > > case where not all of the RBs in the compus are FGL capable. > > The word "mode" does not occur anywhere in the body of the draft. FGL > RBridges are supersets. FGL RBridges can handle VL frames fine. It is > just that VL RBridges can't handle FGL frames and it is very hard to > guarantee that an FGL frame will never be routed to a VL RBridge > without either multi-topology (which is not yet fully specified for > TRILL) or stopping all data flow between VL and FGL RBridges (whcih is > what this draft does). > > > Is my understanding correct? > > See above. > > > Skimming the document again, this could perhaps be clearer. > > I guess so. > > > I.e., what is supposed o happen in a campus where some RBs say they do > > FGL and others do not? Is the intention that one TRILL campus gets > > formed with all nodes falling back to VL mode? > > As stated in the draft, the assumption in that case is that you wanted > a completely FGL campus and whatever VL RBridges are present are > isolated misconfigurations. So the provisions are that all the > RBridges peer for control but VL and FGL RBridges do not peer for > data. You don't want the attachment of one RBridge misconfigured to be > a VL RBridge to kill your whole FGL campus. You can't "fall back" a > port configured for FGL without violating security policy. > > Maybe clarifying text should be added and the "FGL RBridges" should be > referred to as "FGLVL RBridges". > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > Thomas > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --20cf3079bb0a2e23b904cee57550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ah.=A0 So the intent is that an FGL RBridge must be able to parse eith= er VL or FGL, which would allow an edge RB that only supports VL to work OK= , and to have some number of VLANs (4000 of them) that would be reachable v= ia old edge RBs?
=A0
And we're assuming that old edge RBs that only do VL= will know to drop something tagged=A0with FGL?
=A0
Rad= ia

On Mon, Nov 19, 2012 at 7:24 PM,= Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi Thomas,

I guess the draft is not as clear as I thought it was.

On Mon, Nov 19, 2012 at 8:40 PM, Thomas Narten <narten@us.ibm.com> wrote:
> Hi.
>
> Donald Eastlake <d3e3e3@gmail.c= om> writes:
>
>> Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and >> support VLAN Labeling (VL) as the inner data label. In other words= , an
>> FGL RBridge must be able to ingress a native frame to an FGL TRILL=
>> data frame, handle an FGL TRILL data frame as a transit switch, an= d
>> egress an FGL TRILL data frame to a native frame. In addition, an = FGL
>> RBridge must be able to ingress a native frame to a VL TRILL data<= br> >> frame, handle a VL TRILL data frame as a transit switch, and egres= s a
>> VL TRILL data frame as a native frame, all this VL stuff as descri= bed
>> in the TRILL base protocol RFC 6325.
>
> I'm still a bit confused by this discussion.
>
> My understanding (from reading the draft earlier today) was that an RB=
> either operates in FGL mode or VL mode. It doesn't mix and
> match. I.e., you don't have an RB with some ports understanding FG= L
> and others VL. =A0(To do that, you'd an RB would have to convert b= etween
> the the two formats which could result in loss of information...)

So what exactly did you think text like the following meant:
=A0 =A0"An FGL RBridge MAY be configured, on one or more ports, to ing= ress
=A0 =A0native frames as FGL. Any ports not so configured that accepts a
=A0 =A0native frame perform the previously specified VL ingress processing<= br> =A0 =A0on native frames [RFC6325]."

I also can't see why you would think that the ability to ingress,
transit, and egress both VL and FGL frames implies having to "convert&= quot;
between those formats. The whole idea of data labeling is
separation/isolation. Why would you convert between them anymore than
you would convert between a random pair of different VLANs?

Anyway, the intent is that ports operate in either VL or FGL mode. And
all the ports of a VL RBridge are VL ports. But an FGL RBridge is
required to support an arbitrary mix of VL and FGL ports. VL and FGL
frames are ships in the night just like VL frames for different VLANs
for FGL frames for different FGLs.

> And the way to look at VL mode, is that it is the fallback for the
> case where not all of the RBs in the compus are FGL capable.

The word "mode" does not occur anywhere in the body of the = draft. FGL
RBridges are supersets. FGL RBridges can handle VL frames fine. It is
just that VL RBridges can't handle FGL frames and it is very hard to guarantee that an FGL frame will never be routed to a VL RBridge
without either multi-topology (which is not yet fully specified for
TRILL) or stopping all data flow between VL and FGL RBridges (whcih is
what this draft does).

> Is my understanding correct?

See above.

> Skimming the document again, this could perhaps be clearer.

I guess so.

> I.e., what is supposed o happen in a campus where some RBs say they do=
> FGL and others do not? Is the intention that one TRILL campus gets
> formed with all nodes falling back to VL mode?

As stated in the draft, the assumption in that case is that you wante= d
a completely FGL campus and whatever VL RBridges are present are
isolated misconfigurations. So the provisions are that all the
RBridges peer for control but VL and FGL RBridges do not peer for
data. You don't want the attachment of one RBridge misconfigured to be<= br> a VL RBridge to kill your whole FGL campus. You can't "fall back&q= uot; a
port configured for FGL without violating security policy.

Maybe clarifying text should be added and the "FGL RBridges" shou= ld be
referred to as "FGLVL RBridges".

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

> Thomas
>
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--20cf3079bb0a2e23b904cee57550-- From d3e3e3@gmail.com Mon Nov 19 20:30:09 2012 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 7ECCB21F8720 for ; Mon, 19 Nov 2012 20:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGxOxpsJEQAS for ; Mon, 19 Nov 2012 20:30:08 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7B21F87EA for ; Mon, 19 Nov 2012 20:30:08 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so524947ieb.31 for ; Mon, 19 Nov 2012 20:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dNyeLa5ivZnw1ojlVcePmr5oAVilHoGQgnIBW/i0VHY=; b=PuWcSY1emQFWzhs+R3d4oBxxGbG0pEJc3nMgaDdK2Jmlsn8VTRq3hyngCp1vIlLfWM iUz0ywoR+HfL6n3M4itYoFBs64vKRG3Yct5/GYSfSpNenVY/vmsT0Od3VWPbPZg4Jfey sZb0Cd/EbdDSUPUzn13FiCeTfJWHV9yWejxeF2YjL/YSw3uKCvknRK1IzWYRuZQBXQHA pF0LhWUam52Oti0Fw2zrruvQxb0TYnTYxMwij2ysMazVczIo8x6NZqg1IGZ2r7AC1IHr o5Xl/zMG1OfZBfNqgO8M1phP2a+QQ+zqM7ryFZjK6DomvmNvhAt/NC94dxbjKLiyUaOA xo4Q== Received: by 10.50.36.138 with SMTP id q10mr8941085igj.0.1353385807891; Mon, 19 Nov 2012 20:30:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Mon, 19 Nov 2012 20:29:47 -0800 (PST) In-Reply-To: References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Mon, 19 Nov 2012 23:29:47 -0500 Message-ID: To: Radia Perlman Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 04:30:09 -0000 Hi Radia, On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman wrote: > Ah. So the intent is that an FGL RBridge must be able to parse either VL or > FGL, which would allow an edge RB that only supports VL to work OK, and to > have some number of VLANs (4000 of them) that would be reachable via old > edge RBs? Yes on parsing. But it is hard to be sure no FGL frame can get to a VL RBridge. Say you have VLRB1 connected to the campus through FGLRB2. And FGLRB2 is connected to FGLRB3. What if connectivity appears between VLRB1 and FGLRB3 and perhaps the link between FGLRB2 and FGLRB3 breaks? How can you stop FGL frames from going between FGLRB2 and FGLRB3 via VLRB1 keeping in mind that you have to assume no changes in the old VL RBridges? (Without multi-topology. With multi-topology, it's relatively easy.) > And we're assuming that old edge RBs that only do VL will know to drop > something tagged with FGL? A VL RBridge should, in my opinion, drop an FGL frame based on RFC 6325. However, if it did not, it would presumably mean it was ignoring the 0x893B value where it should be requiring 0x8100. As a result, it would believe the FGL frame was in some VLAN and might egress it to the wrong end-stations, violating security policy. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Radia > > On Mon, Nov 19, 2012 at 7:24 PM, Donald Eastlake wrote: >> >> Hi Thomas, >> >> I guess the draft is not as clear as I thought it was. >> >> On Mon, Nov 19, 2012 at 8:40 PM, Thomas Narten wrote: >> > Hi. >> > >> > Donald Eastlake writes: >> > >> >> Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and >> >> support VLAN Labeling (VL) as the inner data label. In other words, an >> >> FGL RBridge must be able to ingress a native frame to an FGL TRILL >> >> data frame, handle an FGL TRILL data frame as a transit switch, and >> >> egress an FGL TRILL data frame to a native frame. In addition, an FGL >> >> RBridge must be able to ingress a native frame to a VL TRILL data >> >> frame, handle a VL TRILL data frame as a transit switch, and egress a >> >> VL TRILL data frame as a native frame, all this VL stuff as described >> >> in the TRILL base protocol RFC 6325. >> > >> > I'm still a bit confused by this discussion. >> > >> > My understanding (from reading the draft earlier today) was that an RB >> > either operates in FGL mode or VL mode. It doesn't mix and >> > match. I.e., you don't have an RB with some ports understanding FGL >> > and others VL. (To do that, you'd an RB would have to convert between >> > the the two formats which could result in loss of information...) >> >> So what exactly did you think text like the following meant: >> "An FGL RBridge MAY be configured, on one or more ports, to ingress >> native frames as FGL. Any ports not so configured that accepts a >> native frame perform the previously specified VL ingress processing >> on native frames [RFC6325]." >> >> I also can't see why you would think that the ability to ingress, >> transit, and egress both VL and FGL frames implies having to "convert" >> between those formats. The whole idea of data labeling is >> separation/isolation. Why would you convert between them anymore than >> you would convert between a random pair of different VLANs? >> >> Anyway, the intent is that ports operate in either VL or FGL mode. And >> all the ports of a VL RBridge are VL ports. But an FGL RBridge is >> required to support an arbitrary mix of VL and FGL ports. VL and FGL >> frames are ships in the night just like VL frames for different VLANs >> for FGL frames for different FGLs. >> >> > And the way to look at VL mode, is that it is the fallback for the >> > case where not all of the RBs in the compus are FGL capable. >> >> The word "mode" does not occur anywhere in the body of the draft. FGL >> RBridges are supersets. FGL RBridges can handle VL frames fine. It is >> just that VL RBridges can't handle FGL frames and it is very hard to >> guarantee that an FGL frame will never be routed to a VL RBridge >> without either multi-topology (which is not yet fully specified for >> TRILL) or stopping all data flow between VL and FGL RBridges (whcih is >> what this draft does). >> >> > Is my understanding correct? >> >> See above. >> >> > Skimming the document again, this could perhaps be clearer. >> >> I guess so. >> >> > I.e., what is supposed o happen in a campus where some RBs say they do >> > FGL and others do not? Is the intention that one TRILL campus gets >> > formed with all nodes falling back to VL mode? >> >> As stated in the draft, the assumption in that case is that you wanted >> a completely FGL campus and whatever VL RBridges are present are >> isolated misconfigurations. So the provisions are that all the >> RBridges peer for control but VL and FGL RBridges do not peer for >> data. You don't want the attachment of one RBridge misconfigured to be >> a VL RBridge to kill your whole FGL campus. You can't "fall back" a >> port configured for FGL without violating security policy. >> >> Maybe clarifying text should be added and the "FGL RBridges" should be >> referred to as "FGLVL RBridges". >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> > Thomas >> > >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > > From d3e3e3@gmail.com Mon Nov 19 20:58:41 2012 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 8D1B621F8901 for ; Mon, 19 Nov 2012 20:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFfQgZJkJqa1 for ; Mon, 19 Nov 2012 20:58:41 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C865E21F8866 for ; Mon, 19 Nov 2012 20:58:40 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so4317342iaf.31 for ; Mon, 19 Nov 2012 20:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OypYl8UZNY2Rg1Huf/teRylETjXgge+4tNV5zOPJcwU=; b=sdgJJSL9N2/5eOdUChgGnJZlPwf+VQvwIK7NcLM1gFTnuixRI46H+rqkgZdBsyn6dr +3fM+qCREs45e3K6GJAo9Et6JP00wgQtGW6NLEd+jU60MLfbVUwkY59hUZCVDtZw6IBG NY+bxusVV7g+NRNNzIxqq4rR971jagmwYU1ZFT5xGk/PJa5wr+o8ATE9AkPAxmdCG5se x3vj5QG93/V7X7THSL+koka7OkTlxr8qO1/gzSJ6ZqTGJYC5YrHR9K536Y9fqE/3G814 DWHDAo8Hszjjrjz7kwh5HO5eTdbyUIgdnuC8EcjF0+PQ5mMqzJfvlGewUKYge/qJ9qha RbeA== Received: by 10.50.40.201 with SMTP id z9mr8892704igk.59.1353387520275; Mon, 19 Nov 2012 20:58:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.176.134 with HTTP; Mon, 19 Nov 2012 20:58:20 -0800 (PST) In-Reply-To: <201211192208.qAJM87O1007297@cichlid.raleigh.ibm.com> References: <201211192208.qAJM87O1007297@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Mon, 19 Nov 2012 23:58:20 -0500 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 04:58:41 -0000 Hi Thomas, Let me describe what I think it going on. On Mon, Nov 19, 2012 at 5:08 PM, Thomas Narten wrote: > Hi. > > I've got a fairly basic question about this document. > > What exact customer/deployment scenario is it trying to address? Scenarios in which customer wants active-active end station connectivity. TRILL can provide ECMP and multi-pathing and rapid fail-over in the links between RBridges. This draft is aimed at specifying a building block (the Affinity sub-TLV) and giving an example of use of that building block towards getting the same capabilities for end station connectivity to the campus.. > It says: > >> This document specifies a concept of Affinity sub-TLV to solve >> associated RPF issues at the active-active edge. Specific methods in >> this document for making use of the Affinity sub-TLV are applicable >> where multiple RBridges are connected to an edge device through link >> aggregation or to a multiport server or some similar arrangement >> where the RBridges cannot see each other's Hellos. > > I view Link Aggregation Groups (LAGs) as an L2 construct that would be > hidden from TRILL. I.e., in Ethernet, LAG is used to "hide" the > presence of multiple links between a pair of switches from STP, so STP > only sees one link (the LAG) rather than the individual links. Thus, I > would expect RBs to want to only know of a single link (i.e., the LAG) > and not have any understanding that the link may actually be a LAG. There are various references in various TRILL documents that agree with you that the classic two end-point LAG appears to TRILL as a single link with a single port at each end. This draft gives, as examples of the use of the Affinity sub-TLV, multi-port servers which do not forward frames between those ports, and what is usually called multi-chassis LAG (MC-LAG) where you have one device (such as a bridge) on one end and multiple devices on the other end that conspire to act like one device. (MC-LAG is commonly supported but using proprietary methods. There is a project in IEEE 802.1, 802.1AX-REV, that is seeking to extend LAG to allow more than one device on each side.) draft-hu-trill-pseudonode-nickname is an example of another use of the Affinity sub-TLV not related to LAG. If I recall correctly, at the Atlanta meeting I repeatedly paired the trill-pseudonode-nickname draft with the trill-cmt draft and suggested people consider them together. > Moreover, Figure 1 is not describing LAG, but multi-chassis LAG > (MLAG). MLAG is not standardized (all implementations are proprietary > and there is no interoperability between vendors). Moreover, MLAG > implementations are pretty restricted -- last I checked, MLAG products > were limited to only 2 switches. So the figure in the document showing > MLAG involving an arbitrary number of "N" switches seems a stretch. I'm not sure the number of RBridges in the edge group matters so much or that you know about all MC-LAG implementations. In any case, a multi-port server could have more than two ports. > Do I have the right understanding of what is meant by "LAG" in the > draft? I think so -- that is, you correctly understood that in this draft it actually means MC-LAG. > The idea that RBs would be aware of individual links within a LAG > kind of defeats the purpose of having LAGs. Is that really what is > being proposed? The draft is intended to specify the Affinity sub-TLV and to provide an example where an edge group of RBridges cannot see each other's Hellos. For the sub-part of the example using MC-LAG, rather than a multi-port server, I would say the MC-LAG is doing exactly what the purpose of MC-LAG is. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thomas From jon.hudson@gmail.com Mon Nov 19 22:23:40 2012 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 E0BAA21F8977 for ; Mon, 19 Nov 2012 22:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4elKn+ghMaQH for ; Mon, 19 Nov 2012 22:23:40 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E491821F8E08 for ; Mon, 19 Nov 2012 22:23:39 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so4005376pbc.31 for ; Mon, 19 Nov 2012 22:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=gYrQk1eOPeOAURmO76sOOS7Jp3jLHp67Uv+c8dzMC4c=; b=W8AQw0/zQIt7lPr1+HokEF8aAnfCSAeFxmNiL2QjJ/htfBO91UKpRXyPGkAfVUeT/C zaPXkbL1DcxPcoZ6BizRu75MCJHP2T5Zm4Keu+KIH0BuQ9WyBdqUlYn7P2Q/PeEEdq+G Wg3bOFdULqaDOdlXzIELqsBt45gc+tce/pHVgYQnM4e9EYadPKzz4BHQl+hYdOPhNniA m/iitv8WtsZrYfw1he2k997/3vOXktNI0Eh5UBJ0NApeBhygRvrQqWGtnYR9GXN3gjNi tRnnSoeX3HNQxp/CTagsMugmkY8x9IuzWcfDUvnDZ7fSTwvNsoLcuLN3Liu+ORALYJbg Lm/Q== Received: by 10.68.230.105 with SMTP id sx9mr46233588pbc.44.1353392619023; Mon, 19 Nov 2012 22:23:39 -0800 (PST) Received: from [10.0.1.11] (c-98-234-218-27.hsd1.ca.comcast.net. [98.234.218.27]) by mx.google.com with ESMTPS id yi9sm7523024pbc.39.2012.11.19.22.23.37 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 22:23:38 -0800 (PST) References: <201211192208.qAJM87O1007297@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A525) From: Jon Hudson Date: Mon, 19 Nov 2012 22:23:35 -0800 To: Donald Eastlake Cc: Thomas Narten , "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 06:23:41 -0000 Just to add to what Donald said... This is a case where the draft came out of a need that kept appearing while d= iscussing and trying to solve other challenges ( like a/a host based connect= ions). As apposed to a "draft if search of a problem" this is really a case of a dr= aft providing a building block that by not existing would prevent other solu= tions from coming forward. Now as to the terminology. There is much confusion in the market and with cu= stomers as to when something is or is not LAG. One if of the limitations today of host based LAGs is that they have to go t= o the same physical switch unless the target switch is part if a proprietary= MCT pair, and that the MCT group is itself only a pair. What many customers want (and is provided today by other proprietary solutio= ns) is N active links to N top of rack switches where the initial common two= configs would be two links to two TOR switches from one host, or four activ= e links from a host to four different TOR switches. This maybe a cause of the confusion caused by the document saying N switches= . And is part of the value since as you stated most MLAG solutions are only i= n a pair, and subpar as a result.=20 J On Nov 19, 2012, at 8:58 PM, Donald Eastlake wrote: > Hi Thomas, >=20 > Let me describe what I think it going on. >=20 > On Mon, Nov 19, 2012 at 5:08 PM, Thomas Narten wrote: >> Hi. >>=20 >> I've got a fairly basic question about this document. >>=20 >> What exact customer/deployment scenario is it trying to address? >=20 > Scenarios in which customer wants active-active end station connectivity. >=20 > TRILL can provide ECMP and multi-pathing and rapid fail-over in the > links between RBridges. This draft is aimed at specifying a building > block (the Affinity sub-TLV) and giving an example of use of that > building block towards getting the same capabilities for end station > connectivity to the campus.. >=20 >> It says: >>=20 >>> This document specifies a concept of Affinity sub-TLV to solve >>> associated RPF issues at the active-active edge. Specific methods in >>> this document for making use of the Affinity sub-TLV are applicable >>> where multiple RBridges are connected to an edge device through link >>> aggregation or to a multiport server or some similar arrangement >>> where the RBridges cannot see each other's Hellos. >>=20 >> I view Link Aggregation Groups (LAGs) as an L2 construct that would be >> hidden from TRILL. I.e., in Ethernet, LAG is used to "hide" the >> presence of multiple links between a pair of switches from STP, so STP >> only sees one link (the LAG) rather than the individual links. Thus, I >> would expect RBs to want to only know of a single link (i.e., the LAG) >> and not have any understanding that the link may actually be a LAG. >=20 > There are various references in various TRILL documents that agree > with you that the classic two end-point LAG appears to TRILL as a > single link with a single port at each end. This draft gives, as > examples of the use of the Affinity sub-TLV, multi-port servers which > do not forward frames between those ports, and what is usually called > multi-chassis LAG (MC-LAG) where you have one device (such as a > bridge) on one end and multiple devices on the other end that conspire > to act like one device. (MC-LAG is commonly supported but using > proprietary methods. There is a project in IEEE 802.1, 802.1AX-REV, > that is seeking to extend LAG to allow more than one device on each > side.) >=20 > draft-hu-trill-pseudonode-nickname is an example of another use of the > Affinity sub-TLV not related to LAG. If I recall correctly, at the > Atlanta meeting I repeatedly paired the trill-pseudonode-nickname > draft with the trill-cmt draft and suggested people consider them > together. >=20 >> Moreover, Figure 1 is not describing LAG, but multi-chassis LAG >> (MLAG). MLAG is not standardized (all implementations are proprietary >> and there is no interoperability between vendors). Moreover, MLAG >> implementations are pretty restricted -- last I checked, MLAG products >> were limited to only 2 switches. So the figure in the document showing >> MLAG involving an arbitrary number of "N" switches seems a stretch. >=20 > I'm not sure the number of RBridges in the edge group matters so much > or that you know about all MC-LAG implementations. In any case, a > multi-port server could have more than two ports. >=20 >> Do I have the right understanding of what is meant by "LAG" in the >> draft? >=20 > I think so -- that is, you correctly understood that in this draft it > actually means MC-LAG. >=20 >> The idea that RBs would be aware of individual links within a LAG >> kind of defeats the purpose of having LAGs. Is that really what is >> being proposed? >=20 > The draft is intended to specify the Affinity sub-TLV and to provide > an example where an edge group of RBridges cannot see each other's > Hellos. For the sub-part of the example using MC-LAG, rather than a > multi-port server, I would say the MC-LAG is doing exactly what the > purpose of MC-LAG is. >=20 > 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 >=20 >> Thomas > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From liyizhou@huawei.com Mon Nov 19 22:25:44 2012 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 18F8321F846B for ; Mon, 19 Nov 2012 22:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jid0AnxqxEV3 for ; Mon, 19 Nov 2012 22:25:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2821F84B9 for ; Mon, 19 Nov 2012 22:25:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS49503; Tue, 20 Nov 2012 06:25:41 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 06:25:14 +0000 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 06:25:39 +0000 Received: from l63746 (10.138.122.33) by smtpscn.huawei.com (10.82.67.154) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 14:25:32 +0800 From: Yizhou Li To: "'Donald Eastlake'" , References: In-Reply-To: Date: Tue, 20 Nov 2012 14:25:31 +0800 Message-ID: <013801cdc6e7$d7def2b0$879cd810$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2zA95Vn+XSlzhUR3C3yoKmFALcPwTwB+IA Content-Language: zh-cn X-Originating-IP: [10.138.122.33] X-CFilter-Loop: Reflected Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 06:25:44 -0000 Some comments: 1. "Push request" and "Pull request" are explicitly used in section 5.2 & 5.3. I would like to suggest to add what are the mandatory parameters for each request. Push request is for retrieving full set of mappings and pull request is for retrieving a particular mapping. Therefore push request should include the requesting RB and optionally VLAN list. Pull request should include the requesting RB and queried IP or MAC. 2. Table 1 does not contain IP info. I think IP address is mandatory info in directory server. Otherwise section 5.3 pull request triggered by ARP/ND would be problematic. The draft uses MAC&VLAN<->Egress RBridge to describe the mapping entry overall which ignores IP info. Suggest to add IP too. 3. Some of the contents in draft draft-dunbar-trill-scheme-for-directory-assist and/or slides presented in last meeting, I kind of think should be included in the framework, e.g., section 5 Push-Pull Hybrid Model in draft-dunbar-trill-scheme-for-directory-assist and slide 3 on potential types of directory servers. They are more framework focused, especially the location correlation of directory server and RBridge. Thanks, Yizhou -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake Sent: Friday, October 26, 2012 6:55 AM To: trill@ietf.org Subject: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt This message begins a TRILL WG two week Last Call on the draft-ietf-trill-directory-framework draft. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From narten@us.ibm.com Tue Nov 20 04:38:15 2012 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 D535621F85AA for ; Tue, 20 Nov 2012 04:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwKv2nmwbCPS for ; Tue, 20 Nov 2012 04:38:14 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8F21F85A3 for ; Tue, 20 Nov 2012 04:38:13 -0800 (PST) Received: from /spool/local by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 20 Nov 2012 07:38:06 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e2.ny.us.ibm.com (192.168.1.102) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 20 Nov 2012 07:35:40 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 001DD38C8042 for ; Tue, 20 Nov 2012 07:35:33 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAKCZWWs298724 for ; Tue, 20 Nov 2012 07:35:32 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAKCZWvI009930 for ; Tue, 20 Nov 2012 07:35:32 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-144-143.mts.ibm.com [9.49.144.143]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qAKCZQDa009605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 07:35:27 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qAKCZPrh015017; Tue, 20 Nov 2012 07:35:25 -0500 Message-Id: <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> Comments: In-reply-to Donald Eastlake message dated "Mon, 19 Nov 2012 22:24:29 -0500." Date: Tue, 20 Nov 2012 07:35:25 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112012-5112-0000-0000-00000EC259D3 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 12:38:15 -0000 Hi Donald. Donald Eastlake writes: > > My understanding (from reading the draft earlier today) was that an RB > > either operates in FGL mode or VL mode. It doesn't mix and > > match. I.e., you don't have an RB with some ports understanding FGL > > and others VL. (To do that, you'd an RB would have to convert between > > the the two formats which could result in loss of information...) > So what exactly did you think text like the following meant: > "An FGL RBridge MAY be configured, on one or more ports, to ingress > native frames as FGL. Any ports not so configured that accepts a > native frame perform the previously specified VL ingress processing > on native frames [RFC6325]." Personally, I thought the wording was somewhat odd, and made a note to figure out what the real intention was. :-) Also, "MAY" means it's not part of the spec, but not being disallowed either. That is not the same thing as saying it is something that implementations would want or need to do. > I also can't see why you would think that the ability to ingress, > transit, and egress both VL and FGL frames implies having to "convert" > between those formats. The whole idea of data labeling is > separation/isolation. Why would you convert between them anymore than > you would convert between a random pair of different VLANs? No disagreement. My assumption had been that if you have an RB that understands both VL and FGL, that such a mode would only be useful if one was converting from one format to the other, or if one fell back from from FGL to VL mode if it didn't make sense to operate in FGL mode. But I wasn't 100% sure what the draft's intention was... But on rereading parts of the draft, it seems that a single TRILL campus can actually consist of a mixture of both VL and FGL-capable RBs. And that campus is effectively partitioned, where some of the links/RBs operate in FGL mode (only) and the rest operate in VL mode (only) with the data planes of the "two networks" operating likes ships in the night. You can even have a single RB supporting both modes (on some links). E.g., you could have RB1 with links L1 and L2 operating in VL mode and links L3 and L4 operating in FGL mode. Right? (This is because it is the individual links that operate in a given mode, not the RB per se.) If so, let me push back on this model. The document says: The usual DRB election operates on a link with mixed FLG and VL ports. If an FGL RBridge port is DRB, it MUST handle all native traffic or appoint only other FGL ports as forwarder for one or more VLANs, so that all end stations will get service to the FGL campus. If a VL RBridge port is DRB, it will not understand that FGL RBridge ports are different. To the extent that a VL DRB handles native frames or appoints other VL ports on a link to handle native frames for one or more VLANs, the end stations sending and receiving those native frames will be isolated from the FGL campus. To the extent that a VL DRB happens to appoint an FGL port as Appointed Forwarder for one or more VLANs, the end stations sending and receiving native frames in those VLANs will get service to the FGL campus. This somewhat odd corner case behavior is considered acceptable because it is assumed that VL TRILL switches in an FGL campus are infrequent misconfigurations. I would not just call this a "corner case" that can be ignored. What it seems to mean is that you can deply TRILL, but get disconnected VLAN islands. That is, C-VID X at one edge is processed by FGL RBs (say RB1), but elsewhere on the network, only VL RBs connect to C-VID X (say via RB2). Because the VL and FGL networks are isolated from each other, the result is that devices in VLAN X connected to RB1 will be unable to communicated with devices in VLAN X connected to RB2. Right? I wouldn't consider that a "corner case" to be ignored. I'd consider that an operational nightmare that can't be allowed to happen (by default). > Anyway, the intent is that ports operate in either VL or FGL mode. And > all the ports of a VL RBridge are VL ports. But an FGL RBridge is > required to support an arbitrary mix of VL and FGL ports. VL and FGL > frames are ships in the night just like VL frames for different VLANs > for FGL frames for different FGLs. Why must FGL capable devices be required to support VL? I understand that it is probably a good thing to do (so you can support either mode, depending on what other RBs are capable of). But does the FGL *protocol* require this in order to work correctly? Does proper operation of FGL require being able to support VL as well? Or is the real intent just to allow a graceful way to "fall back" into VL mode to intereperate with non FGL-aware RBs? (I think that is a fine thing to require, btw.) > > And the way to look at VL mode, is that it is the fallback for the > > case where not all of the RBs in the compus are FGL capable. > The word "mode" does not occur anywhere in the body of the draft. FGL > RBridges are supersets. FGL RBridges can handle VL frames fine. It is > just that VL RBridges can't handle FGL frames and it is very hard to > guarantee that an FGL frame will never be routed to a VL RBridge > without either multi-topology (which is not yet fully specified for > TRILL) or stopping all data flow between VL and FGL RBridges (whcih is > what this draft does). IMO, this spec should not say anything about multi-topology (that is future work) and should ensure that a standards compliant implementation cannot and will not forward FGL packets to VL-only RBs. Anything else will likely lead to operational problems... > > I.e., what is supposed o happen in a campus where some RBs say they do > > FGL and others do not? Is the intention that one TRILL campus gets > > formed with all nodes falling back to VL mode? > As stated in the draft, the assumption in that case is that you wanted > a completely FGL campus and whatever VL RBridges are present are > isolated misconfigurations. I think this is an unreasonable assumption. You will get deployments that have both. Accidents can happen, etc. I think we'd be better off with very clear ways for the operator to specify what they want to have happen in a mixed mode. We can have a default mode, but the operator needs to be able to override the defaults. I.e., if only one (or a small number of) switches supports FGL, you want the default mode to be to have the entire TRILL campus to try to use FGL? I'm not sure. > So the provisions are that all the RBridges peer for control but VL > and FGL RBridges do not peer for data. You don't want the attachment > of one RBridge misconfigured to be a VL RBridge to kill your whole > FGL campus. You can't "fall back" a port configured for FGL without > violating security policy. I don't understand the "security policy" reference here. > Maybe clarifying text should be added and the "FGL RBridges" should be > referred to as "FGLVL RBridges". No. The issue isn't terminology. The text needs to be clearer what the intention is. For me, it's sometimes hard to pull out the overriding intention from the specific rules that are layed out in the document. Thomas From ghanwani@gmail.com Tue Nov 20 11:20:01 2012 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 5F52621F8809 for ; Tue, 20 Nov 2012 11:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ2T-FcKl03y for ; Tue, 20 Nov 2012 11:20:00 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23721F880B for ; Tue, 20 Nov 2012 11:20:00 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7286274vbb.31 for ; Tue, 20 Nov 2012 11:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bH2Rgxl/54YPvsHgYUfPBrRSiIDgwXERgGk2NBFOov4=; b=uKAnVg1Gylv6m8N1BFW7hgFLpjFyYZuu83RG3iJg29IEeev3JPOKVXf9Dw9kVmnhAD bqFVRGu9FQTS+ieBVtk9rE9FsQ3AHjt9Cer58e7sCLxK8sm3WdINT2B7qjflDp8WqvAO HySQkH+tYXD/YzhvoQwe0RctQ8fBengLb5rQ4I9tUm70/RmRF1GI2YGkfFgERz0oKl4m i8AMJssJsSawl0eYl69/2f5SqvAW7EjMc0JWX2viuPAxCzQU2Qd0yQU71RNMODwoliac L1LMur6GDxjiCyFTmoIMFJQbof3Vja9uieT3ewVasHxDCavlY2YXKXAOg5yN/pZadY66 0gIA== MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr20051328vdb.95.1353439199799; Tue, 20 Nov 2012 11:19:59 -0800 (PST) Sender: ghanwani@gmail.com Received: by 10.220.143.73 with HTTP; Tue, 20 Nov 2012 11:19:59 -0800 (PST) In-Reply-To: References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> Date: Tue, 20 Nov 2012 11:19:59 -0800 X-Google-Sender-Auth: 8YHsiCYagZouYUyJFYyQek_gFGk Message-ID: From: Anoop Ghanwani To: Donald Eastlake Content-Type: multipart/alternative; boundary=20cf3071c69cbaaae104cef21e88 Cc: Radia Perlman , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 19:20:01 -0000 --20cf3071c69cbaaae104cef21e88 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake wrote: > Hi Radia, > > On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman > wrote: > > Ah. So the intent is that an FGL RBridge must be able to parse either > VL or > > FGL, which would allow an edge RB that only supports VL to work OK, and > to > > have some number of VLANs (4000 of them) that would be reachable via old > > edge RBs? > > Yes on parsing. But it is hard to be sure no FGL frame can get to a VL > RBridge. Say you have VLRB1 connected to the campus through FGLRB2. > And FGLRB2 is connected to FGLRB3. What if connectivity appears > between VLRB1 and FGLRB3 and perhaps the link between FGLRB2 and > FGLRB3 breaks? How can you stop FGL frames from going between FGLRB2 > and FGLRB3 via VLRB1 keeping in mind that you have to assume no > changes in the old VL RBridges? (Without multi-topology. With > multi-topology, it's relatively easy.) > FGL frames should never be forwarded to an RB that doesn't support FGL. This is easy to figure out since IS-IS can tell us what the capabilities of an RBridge are before forwarding to that RBridge begins. And as a result of this requirement, we should probably disallow FGL and non-FGL bridges being reachable from the same RBridge port, otherwise it would be challenging to implement this control for multicast frames. > > And we're assuming that old edge RBs that only do VL will know to drop > > something tagged with FGL? > > A VL RBridge should, in my opinion, drop an FGL frame based on RFC > 6325. However, if it did not, it would presumably mean it was ignoring > the 0x893B value where it should be requiring 0x8100. As a result, it > would believe the FGL frame was in some VLAN and might egress it to > the wrong end-stations, violating security policy. We need to make the spec clear on this aspect; i.e. FGL or non-FGL RBridges must discard a received frame if the inner tag (FGL or VLAN depending on what mode the port is operating in) is absent. Anoop --20cf3071c69cbaaae104cef21e88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake <= d3e3e3@gmail.com&= gt; wrote:
Hi Radia,

On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman <radiaperlman@gmail.com> wrote:
> Ah. =A0So the intent is that an FGL RBridge must be able to parse eith= er VL or
> FGL, which would allow an edge RB that only supports VL to work OK, an= d to
> have some number of VLANs (4000 of them) that would be reachable via o= ld
> edge RBs?

Yes on parsing. But it is hard to be sure no FGL frame can get to a V= L
RBridge. Say you have VLRB1 connected to the campus through FGLRB2.
And FGLRB2 is connected to FGLRB3. What if connectivity appears
between VLRB1 and FGLRB3 and perhaps the link between FGLRB2 and
FGLRB3 breaks? How can you stop FGL frames from going between FGLRB2
and FGLRB3 via VLRB1 keeping in mind that you have to assume no
changes in the old VL RBridges? (Without multi-topology. With
multi-topology, it's relatively easy.)

<= div>FGL frames should never be forwarded to an RB that doesn't
support FGL. =A0This is easy to figure out since IS-IS can tell us=A0
what the capabilities of an RBridge are before forwarding to
that RBridge begins. =A0And as a result of this requirement, we
= should probably disallow FGL and non-FGL bridges being=A0
reachab= le from the same RBridge port, otherwise it would be=A0
challenging to implement this control for multicast frames.=A0


> And we're assuming that old edge RBs that only do VL will know to = drop
> something tagged with FGL?

A VL RBridge should, in my opinion, drop an FGL frame based on RFC 6325. However, if it did not, it would presumably mean it was ignoring
the 0x893B value where it should be requiring 0x8100. As a result, it
would believe the FGL frame was in some VLAN and might egress it to
the wrong end-stations, violating security policy.

We need to make the spec clear on this aspect; i.e. FGL or non-FGL<= /div>
RBridges must discard a received frame if the inner tag (FGL or V= LAN=A0
depending=A0on what mode the port is operating in) is absent.

Anoop=A0
--20cf3071c69cbaaae104cef21e88-- From pkoganti@Brocade.COM Tue Nov 20 11:29:48 2012 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 47BB521F882F for ; Tue, 20 Nov 2012 11:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok6NYo3AYkER for ; Tue, 20 Nov 2012 11:29:46 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 087C921F8828 for ; Tue, 20 Nov 2012 11:29:45 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id qAKJR6Ns029356; Tue, 20 Nov 2012 11:29:34 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 18qsdpgsb7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Nov 2012 11:29:33 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 20 Nov 2012 11:30:05 -0800 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 20 Nov 2012 11:29:32 -0800 From: Phanidhar Koganti To: Anoop Ghanwani , Donald Eastlake Date: Tue, 20 Nov 2012 11:29:30 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3HVB/O9xRzfh+yTQWfXlqPdnWXogAAIEXQ Message-ID: <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82FHQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-20_04:2012-11-20, 2012-11-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1211200175 Cc: Radia Perlman , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 19:29:48 -0000 --_000_6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82FHQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of A= noop Ghanwani Sent: Wednesday, November 21, 2012 12:50 AM To: Donald Eastlake Cc: Radia Perlman; trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake > wrote: Hi Radia, On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman > wrote: > Ah. So the intent is that an FGL RBridge must be able to parse either VL= or > FGL, which would allow an edge RB that only supports VL to work OK, and t= o > have some number of VLANs (4000 of them) that would be reachable via old > edge RBs? Yes on parsing. But it is hard to be sure no FGL frame can get to a VL RBridge. Say you have VLRB1 connected to the campus through FGLRB2. And FGLRB2 is connected to FGLRB3. What if connectivity appears between VLRB1 and FGLRB3 and perhaps the link between FGLRB2 and FGLRB3 breaks? How can you stop FGL frames from going between FGLRB2 and FGLRB3 via VLRB1 keeping in mind that you have to assume no changes in the old VL RBridges? (Without multi-topology. With multi-topology, it's relatively easy.) FGL frames should never be forwarded to an RB that doesn't support FGL. This is easy to figure out since IS-IS can tell us what the capabilities of an RBridge are before forwarding to that RBridge begins. And as a result of this requirement, we should probably disallow FGL and non-FGL bridges being reachable from the same RBridge port, otherwise it would be challenging to implement this control for multicast frames. [Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as transit n= odes? Why can't the transit nodes just rely on TRILL SA/DA to forward. Agre= e there will be issues for multicast in terms of the optimal pruned forward= ing as a non-FGL RB will not have access to the inner IP header or VLAN (FG= L based). However isn't this an optimization for multicast pruning? The tra= nsit RBs can forward based on the non-pruned multicast tree. > And we're assuming that old edge RBs that only do VL will know to drop > something tagged with FGL? A VL RBridge should, in my opinion, drop an FGL frame based on RFC 6325. However, if it did not, it would presumably mean it was ignoring the 0x893B value where it should be requiring 0x8100. As a result, it would believe the FGL frame was in some VLAN and might egress it to the wrong end-stations, violating security policy. We need to make the spec clear on this aspect; i.e. FGL or non-FGL RBridges must discard a received frame if the inner tag (FGL or VLAN depending on what mode the port is operating in) is absent. Anoop --_000_6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82FHQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:= tri= ll-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Ano= op Ghanwani
Sent: Wednesday, November 21, 2012 12:50 AM
To:= Donald Eastlake
Cc: Radia Perlman; trill@ietf.org
Subj= ect: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

 


On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake <d3e3e3@gmail.com> w= rote:

Yes on parsing. But it is hard to be sure no FG= L frame can get to a VL
RBridge. Say you have VLRB1 connected to the cam= pus through FGLRB2.
And FGLRB2 is connected to FGLRB3. What if connectiv= ity appears
between VLRB1 and FGLRB3 and perhaps the link between FGLRB2= and
FGLRB3 breaks? How can you stop FGL frames from going between FGLRB= 2
and FGLRB3 via VLRB1 keeping in mind that you have to assume no
cha= nges in the old VL RBridges? (Without multi-topology. With
multi-topolog= y, it's relatively easy.)

A VL RBridge should, in my opinion, drop an FGL frame based on RFC
= 6325. However, if it did not, it would presumably mean it was ignoring
t= he 0x893B value where it should be requiring 0x8100. As a result, it
wou= ld believe the FGL frame was in some VLAN and might egress it to
the wro= ng end-stations, violating security policy.

 

Anoop 

<= /html>= --_000_6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82FHQ1EXCH02corp_-- From ghanwani@gmail.com Tue Nov 20 13:53:20 2012 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 9563321F8807 for ; Tue, 20 Nov 2012 13:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xNb7sR+XusK for ; Tue, 20 Nov 2012 13:53:20 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8A8721F87F3 for ; Tue, 20 Nov 2012 13:53:19 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7453200vbb.31 for ; Tue, 20 Nov 2012 13:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=be+9TfgkDtBL23aHbFh/nlcfnsOh9BCuuHM2Ey77GHM=; b=ZYB9hfuy8m5SYGT3sUqvOs0RY0aELsRGEYYzNfGSui8kXvJorRE2ff8FOUVKg2VAWV 7HslRQDgG6ZwC/7G3xwPta6T17LJQ3CgOrvT1YTpD3AzUPnux+YFyYo/7RhAQhnk4Sjp JHEi13JuI1tSF8iosritE3FqD8lQSMIWcHj2GaG7siK4XaPhpKfsCGIplw2W48Amz9JA 3LxR0yFfXk4gQEMVr0rsYMPNmrnmqhigmJ3OCFN+OaFvB3nsrcsYDn/1vmbA6/3an6K1 EoXXTwkFtX7W85j9Lqr46kPQNavTlvmxhTVzbDTG9DFLTsEsgR9ltqCgs3wop3wQw58P 9T2Q== MIME-Version: 1.0 Received: by 10.58.243.166 with SMTP id wz6mr24174148vec.28.1353448398961; Tue, 20 Nov 2012 13:53:18 -0800 (PST) Sender: ghanwani@gmail.com Received: by 10.220.143.73 with HTTP; Tue, 20 Nov 2012 13:53:18 -0800 (PST) In-Reply-To: <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> Date: Tue, 20 Nov 2012 13:53:18 -0800 X-Google-Sender-Auth: eSdoyHwvRTG1kvDF6gyi1RzO_fw Message-ID: From: Anoop Ghanwani To: Phanidhar Koganti Content-Type: multipart/alternative; boundary=047d7b86f4b20aba8804cef4434e Cc: Donald Eastlake , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 21:53:20 -0000 --047d7b86f4b20aba8804cef4434e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2012 at 11:29 AM, Phanidhar Koganti w= rote: > Yes on parsing. But it is hard to be sure no FGL frame can get to a VL > RBridge. Say you have VLRB1 connected to the campus through FGLRB2. > And FGLRB2 is connected to FGLRB3. What if connectivity appears > between VLRB1 and FGLRB3 and perhaps the link between FGLRB2 and > FGLRB3 breaks? How can you stop FGL frames from going between FGLRB2 > and FGLRB3 via VLRB1 keeping in mind that you have to assume no > changes in the old VL RBridges? (Without multi-topology. With > multi-topology, it's relatively easy.)**** > > ** ** > > FGL frames should never be forwarded to an RB that doesn't**** > > support FGL. This is easy to figure out since IS-IS can tell us **** > > what the capabilities of an RBridge are before forwarding to**** > > that RBridge begins. And as a result of this requirement, we**** > > should probably disallow FGL and non-FGL bridges being **** > > reachable from the same RBridge port, otherwise it would be **** > > challenging to implement this control for multicast frames. **** > > *[Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as > transit nodes? Why can=92t the transit nodes just rely on TRILL SA/DA to > forward. Agree there will be issues for multicast in terms of the optimal > pruned forwarding as a non-FGL RB will not have access to the inner IP > header or VLAN (FGL based). However isn=92t this an optimization for > multicast pruning? The transit RBs can forward based on the non-pruned > multicast tree.***** > > ** > There are security issues as pointed out by Donald. If the device that we thought was going to be just a transit device, but it also had edge ports, it could end up leaking these frames on edge ports. The other option would be for the FGL spec to update RFC 6325 to say that if the inner VLAN tag is not present then the frame must not be egressed in native form, and to state that if one wants to use a non-FGL RBridge as a transit device, then it must support this behavior. Anoop --047d7b86f4b20aba8804cef4434e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2012 at 11:29 AM, Phanidhar Koganti <<= a href=3D"mailto:pkoganti@brocade.com" target=3D"_blank">pkoganti@brocade.c= om> wrote:

Yes on parsing. B= ut it is hard to be sure no FGL frame can get to a VL
RBridge. Say you have VLRB1 connected to the campus through FGLRB2.
And = FGLRB2 is connected to FGLRB3. What if connectivity appears
between VLRB= 1 and FGLRB3 and perhaps the link between FGLRB2 and
FGLRB3 breaks? How = can you stop FGL frames from going between FGLRB2
and FGLRB3 via VLRB1 keeping in mind that you have to assume no
changes = in the old VL RBridges? (Without multi-topology. With
multi-topology, it= 's relatively easy.)

=A0

FGL frames should ne= ver be forwarded to an RB that doesn't

support FGL. =A0This is easy to figure out since IS-IS c= an tell us=A0

what the capabilities of an RBridge are b= efore forwarding to

that= RBridge begins. =A0And as a result of this requirement, we

should probably disallow FGL and non-FGL = bridges being=A0

reachab= le from the same RBridge port, otherwise it would be=A0

challenging to implement this control for multi= cast frames.=A0

[Phanidhar Koganti] Does this mean non-FGL RBridges cannot = act as transit nodes? Why can=92t the transit nodes just rely on TRILL SA/D= A to forward. Agree there will be issues for multicast in terms of the opti= mal pruned forwarding as a non-FGL RB will not have access to the inner IP = header or VLAN (FGL based). However isn=92t this an optimization for multic= ast pruning? The transit RBs can forward based on the non-pruned multicast = tree.

=A0


There are security issues as pointed out by Donald.= =A0If the device that
we thought was going to be just a transit = device, but it also had edge
ports, it could end up leaking these frames on edge ports. =A0

The other option would be for the FGL spec to update RFC = 6325 to=A0
say that if the inner=A0VLAN tag is not present then t= he frame must not be=A0
egressed in native=A0form, and to state that if one wants to use a non= -FGL
RBridge as a transit device, then it must support this behav= ior.

Anoop
--047d7b86f4b20aba8804cef4434e-- From pthaler@broadcom.com Tue Nov 20 17:07:13 2012 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 D017221F877A for ; Tue, 20 Nov 2012 17:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGscoqnFAgwB for ; Tue, 20 Nov 2012 17:07:11 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id A637821F8773 for ; Tue, 20 Nov 2012 17:07:11 -0800 (PST) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 20 Nov 2012 17:02:54 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS01.corp.ad.broadcom.com (10.16.192.31) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 20 Nov 2012 17:07:04 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by sjexchcas01.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 20 Nov 2012 17:07:04 -0800 From: "Pat Thaler" To: "Jon Hudson" , "Donald Eastlake" Thread-Topic: [trill] draft-ietf-trill-cmt Thread-Index: AQHNx1QVodkXkqiQ+kSKjCvVQ4TKqpfzb/Iw Date: Wed, 21 Nov 2012 01:07:03 +0000 Message-ID: References: <201211192208.qAJM87O1007297@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CB2F7B43P86676412-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 01:07:13 -0000 Jon and Donald I'm skeptical about a "building block" to use in future solutions in genera= l and especially for link aggregation or teaming. It's a fairly difficult t= o generically make a group of bridges pretend to be a single bridge and one= should start with an architecture for solution, IMO, rather than starting = with pieces that you hope to pull into a future solution.=20 "A typical deployment scenario, depicted in Figure 1, which may have either End Stations and/or Legacy bridges attached to the RBridges. These Legacy devices typically are multi-homed to several RBridges and treat all of the uplinks as a single Link Aggregation (LAG) bundle [802.1AX]." End stations support many forms of teaming so they don't "typically" use an= y one form. For instance, one is a bridge-independent form of active-activ= e teaming where the end station load balances traffic to various links with= different MAC addresses on each link. They generally can't treat links to = separate bridges as a single 802.1AX LAG unless the bridges cooperate to su= pport a proprietary multi-chassis LAG.=20 LAG is defined by 802.1AX and that term shouldn't be used for other mechani= sms for using multiple links. It's better to use something else like "teami= ng" when one wants to include both 802.1AX and non-802.1AX mechanisms. The = groupings identified as LAGs in Figure 1 will not be LAGs unless the bridge= s are presenting them as a single bridge to the end stations which isn't tr= ivial to get right and is currently proprietary. DRNI (dual resilient network interconnect) - the capability being added in = the 802.1AX-Rev project has a focused objective of defining a mechanism for= using a LAG between two provider networks (that's why it's called a "netwo= rk interconnect") where the links end in more than one bridge (probably two= or three bridges) on each side of the aggregation. End node attachment to= a multi-bridge LAG host isn't an objective. Pat -----Original Message----- From: Jon Hudson [mailto:jon.hudson@gmail.com]=20 Sent: Monday, November 19, 2012 10:24 PM To: Donald Eastlake Cc: Thomas Narten; Tissa Senevirathne (tsenevir); trill@ietf.org Subject: Re: [trill] draft-ietf-trill-cmt Just to add to what Donald said... This is a case where the draft came out of a need that kept appearing while= discussing and trying to solve other challenges ( like a/a host based conn= ections). As apposed to a "draft if search of a problem" this is really a case of a d= raft providing a building block that by not existing would prevent other so= lutions from coming forward. Now as to the terminology. There is much confusion in the market and with c= ustomers as to when something is or is not LAG. One if of the limitations today of host based LAGs is that they have to go = to the same physical switch unless the target switch is part if a proprieta= ry MCT pair, and that the MCT group is itself only a pair. What many customers want (and is provided today by other proprietary soluti= ons) is N active links to N top of rack switches where the initial common t= wo configs would be two links to two TOR switches from one host, or four ac= tive links from a host to four different TOR switches. This maybe a cause of the confusion caused by the document saying N switche= s. And is part of the value since as you stated most MLAG solutions are onl= y in a pair, and subpar as a result.=20 J On Nov 19, 2012, at 8:58 PM, Donald Eastlake wrote: > Hi Thomas, >=20 > Let me describe what I think it going on. >=20 > On Mon, Nov 19, 2012 at 5:08 PM, Thomas Narten wrote: >> Hi. >>=20 >> I've got a fairly basic question about this document. >>=20 >> What exact customer/deployment scenario is it trying to address? >=20 > Scenarios in which customer wants active-active end station connectivity. >=20 > TRILL can provide ECMP and multi-pathing and rapid fail-over in the > links between RBridges. This draft is aimed at specifying a building > block (the Affinity sub-TLV) and giving an example of use of that > building block towards getting the same capabilities for end station > connectivity to the campus.. >=20 >> It says: >>=20 >>> This document specifies a concept of Affinity sub-TLV to solve >>> associated RPF issues at the active-active edge. Specific methods in >>> this document for making use of the Affinity sub-TLV are applicable >>> where multiple RBridges are connected to an edge device through link >>> aggregation or to a multiport server or some similar arrangement >>> where the RBridges cannot see each other's Hellos. >>=20 >> I view Link Aggregation Groups (LAGs) as an L2 construct that would be >> hidden from TRILL. I.e., in Ethernet, LAG is used to "hide" the >> presence of multiple links between a pair of switches from STP, so STP >> only sees one link (the LAG) rather than the individual links. Thus, I >> would expect RBs to want to only know of a single link (i.e., the LAG) >> and not have any understanding that the link may actually be a LAG. >=20 > There are various references in various TRILL documents that agree > with you that the classic two end-point LAG appears to TRILL as a > single link with a single port at each end. This draft gives, as > examples of the use of the Affinity sub-TLV, multi-port servers which > do not forward frames between those ports, and what is usually called > multi-chassis LAG (MC-LAG) where you have one device (such as a > bridge) on one end and multiple devices on the other end that conspire > to act like one device. (MC-LAG is commonly supported but using > proprietary methods. There is a project in IEEE 802.1, 802.1AX-REV, > that is seeking to extend LAG to allow more than one device on each > side.) >=20 > draft-hu-trill-pseudonode-nickname is an example of another use of the > Affinity sub-TLV not related to LAG. If I recall correctly, at the > Atlanta meeting I repeatedly paired the trill-pseudonode-nickname > draft with the trill-cmt draft and suggested people consider them > together. >=20 >> Moreover, Figure 1 is not describing LAG, but multi-chassis LAG >> (MLAG). MLAG is not standardized (all implementations are proprietary >> and there is no interoperability between vendors). Moreover, MLAG >> implementations are pretty restricted -- last I checked, MLAG products >> were limited to only 2 switches. So the figure in the document showing >> MLAG involving an arbitrary number of "N" switches seems a stretch. >=20 > I'm not sure the number of RBridges in the edge group matters so much > or that you know about all MC-LAG implementations. In any case, a > multi-port server could have more than two ports. >=20 >> Do I have the right understanding of what is meant by "LAG" in the >> draft? >=20 > I think so -- that is, you correctly understood that in this draft it > actually means MC-LAG. >=20 >> The idea that RBs would be aware of individual links within a LAG >> kind of defeats the purpose of having LAGs. Is that really what is >> being proposed? >=20 > The draft is intended to specify the Affinity sub-TLV and to provide > an example where an edge group of RBridges cannot see each other's > Hellos. For the sub-part of the example using MC-LAG, rather than a > multi-port server, I would say the MC-LAG is doing exactly what the > purpose of MC-LAG is. >=20 > 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 >=20 >> Thomas > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From ostokes@extremenetworks.com Tue Nov 20 21:07:44 2012 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 6435821F8755 for ; Tue, 20 Nov 2012 21:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1eys5N6Yzpf for ; Tue, 20 Nov 2012 21:07:43 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3221F86FE for ; Tue, 20 Nov 2012 21:07:43 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Tue, 20 Nov 2012 21:07:40 -0800 From: Olen Stokes To: Thomas Narten , Donald Eastlake Date: Tue, 20 Nov 2012 21:07:37 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3HpiFRQzT7uC79STWH0/Y+ZMsiqw== Message-ID: In-Reply-To: <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 05:07:44 -0000 Trying NOT to add anything more in line=8A It seems that multiple different people have multiple different migration scenarios in mind. I think that several of us could benefit from something that better spells out what scenario(s) the authors have in mind. Donald's scenarios described in his response to my previous email would have helped the draft. We can then discuss if there are others that need to be considered. We seem to be discussing three types of nodes: 1) VL-only capable RBridges 2) VL and FGL capable RBridges 3) FGL-only capable Rbridges For the third (FGL-only) type, remember that at some point people will want to drop support for the VL RBridges. There may also be silicon out that that can operate in VL mode or in FGL mode but not both at the same time. Note, I am not a silicon person. If these three types are intended, a more clear statement of the requirements for each time might be of benefit. The requirements should describe ingress, egress, transit, and transit plus egress RBridges. If one of these types is not intended, then a clear statement that it is not supported may be in order. It could then be debated. I believe that Donald has described that the second type above (VL and FGL capable RBridge) is a requirement. To me, the best case for that requirement is in a multi-topolgy environment. Stating that use case would have made the document and that requirement more clear to me. I leave it to others to figure out how to reference something that might be defined in another draft (at some point in the future). Note that to me, a "VL and FGL capable" node acting only as a VL node is just a VL RBridge. Cheers, Olen=20 On 11/20/12 7:35 AM, "Thomas Narten" wrote: >Hi Donald. > >Donald Eastlake writes: > > >> > My understanding (from reading the draft earlier today) was that an RB >> > either operates in FGL mode or VL mode. It doesn't mix and >> > match. I.e., you don't have an RB with some ports understanding FGL >> > and others VL. (To do that, you'd an RB would have to convert between >> > the the two formats which could result in loss of information...) > >> So what exactly did you think text like the following meant: >> "An FGL RBridge MAY be configured, on one or more ports, to ingress >> native frames as FGL. Any ports not so configured that accepts a >> native frame perform the previously specified VL ingress processing >> on native frames [RFC6325]." > >Personally, I thought the wording was somewhat odd, and made a note to >figure out what the real intention was. :-) Also, "MAY" means it's not >part of the spec, but not being disallowed either. That is not the >same thing as saying it is something that implementations would want >or need to do. > >> I also can't see why you would think that the ability to ingress, >> transit, and egress both VL and FGL frames implies having to "convert" >> between those formats. The whole idea of data labeling is >> separation/isolation. Why would you convert between them anymore than >> you would convert between a random pair of different VLANs? > >No disagreement. My assumption had been that if you have an RB that >understands both VL and FGL, that such a mode would only be useful if >one was converting from one format to the other, or if one fell back >from from FGL to VL mode if it didn't make sense to operate in FGL >mode. But I wasn't 100% sure what the draft's intention was... > >But on rereading parts of the draft, it seems that a single TRILL >campus can actually consist of a mixture of both VL and FGL-capable >RBs. And that campus is effectively partitioned, where some of the >links/RBs operate in FGL mode (only) and the rest operate in VL mode >(only) with the data planes of the "two networks" operating likes >ships in the night. > >You can even have a single RB supporting both modes (on some >links). E.g., you could have RB1 with links L1 and L2 operating in VL >mode and links L3 and L4 operating in FGL mode. Right? (This is >because it is the individual links that operate in a given mode, not >the RB per se.) > >If so, let me push back on this model. The document says: > > The usual DRB election operates on a link with mixed FLG and VL > ports. If an FGL RBridge port is DRB, it MUST handle all native > traffic or appoint only other FGL ports as forwarder for one or more > VLANs, so that all end stations will get service to the FGL campus. > If a VL RBridge port is DRB, it will not understand that FGL RBridge > ports are different. To the extent that a VL DRB handles native > frames or appoints other VL ports on a link to handle native frames > for one or more VLANs, the end stations sending and receiving those > native frames will be isolated from the FGL campus. To the extent > that a VL DRB happens to appoint an FGL port as Appointed Forwarder > for one or more VLANs, the end stations sending and receiving native > frames in those VLANs will get service to the FGL campus. This > somewhat odd corner case behavior is considered acceptable because it > is assumed that VL TRILL switches in an FGL campus are infrequent > misconfigurations. > >I would not just call this a "corner case" that can be ignored. What >it seems to mean is that you can deply TRILL, but get disconnected >VLAN islands. That is, C-VID X at one edge is processed by FGL RBs >(say RB1), but elsewhere on the network, only VL RBs connect to C-VID >X (say via RB2). Because the VL and FGL networks are isolated from >each other, the result is that devices in VLAN X connected to RB1 will >be unable to communicated with devices in VLAN X connected to >RB2. Right? > >I wouldn't consider that a "corner case" to be ignored. I'd consider >that an operational nightmare that can't be allowed to happen (by >default). > >> Anyway, the intent is that ports operate in either VL or FGL mode. And >> all the ports of a VL RBridge are VL ports. But an FGL RBridge is >> required to support an arbitrary mix of VL and FGL ports. VL and FGL >> frames are ships in the night just like VL frames for different VLANs >> for FGL frames for different FGLs. > >Why must FGL capable devices be required to support VL? I understand >that it is probably a good thing to do (so you can support either >mode, depending on what other RBs are capable of). But does the FGL >*protocol* require this in order to work correctly? Does proper >operation of FGL require being able to support VL as well? Or is the >real intent just to allow a graceful way to "fall back" into VL mode >to intereperate with non FGL-aware RBs? (I think that is a fine thing >to require, btw.) > >> > And the way to look at VL mode, is that it is the fallback for the >> > case where not all of the RBs in the compus are FGL capable. > >> The word "mode" does not occur anywhere in the body of the draft. FGL >> RBridges are supersets. FGL RBridges can handle VL frames fine. It is >> just that VL RBridges can't handle FGL frames and it is very hard to >> guarantee that an FGL frame will never be routed to a VL RBridge >> without either multi-topology (which is not yet fully specified for >> TRILL) or stopping all data flow between VL and FGL RBridges (whcih is >> what this draft does). > >IMO, this spec should not say anything about multi-topology (that is >future work) and should ensure that a standards compliant >implementation cannot and will not forward FGL packets to VL-only >RBs. Anything else will likely lead to operational problems... > >> > I.e., what is supposed o happen in a campus where some RBs say they do >> > FGL and others do not? Is the intention that one TRILL campus gets >> > formed with all nodes falling back to VL mode? > >> As stated in the draft, the assumption in that case is that you wanted >> a completely FGL campus and whatever VL RBridges are present are >> isolated misconfigurations. > >I think this is an unreasonable assumption. You will get deployments >that have both. Accidents can happen, etc. I think we'd be better off >with very clear ways for the operator to specify what they want to >have happen in a mixed mode. We can have a default mode, but the >operator needs to be able to override the defaults. > >I.e., if only one (or a small number of) switches supports FGL, you >want the default mode to be to have the entire TRILL campus to try to >use FGL? I'm not sure. > >> So the provisions are that all the RBridges peer for control but VL >> and FGL RBridges do not peer for data. You don't want the attachment >> of one RBridge misconfigured to be a VL RBridge to kill your whole >> FGL campus. You can't "fall back" a port configured for FGL without >> violating security policy. > >I don't understand the "security policy" reference here. > >> Maybe clarifying text should be added and the "FGL RBridges" should be >> referred to as "FGLVL RBridges". > >No. The issue isn't terminology. The text needs to be clearer what the >intention is. For me, it's sometimes hard to pull out the overriding >intention from the specific rules that are layed out in the document. > >Thomas > >_______________________________________________ >trill mailing list >trill@ietf.org >https://www.ietf.org/mailman/listinfo/trill From rmanur@broadcom.com Wed Nov 21 11:26:41 2012 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 AFCA921F883A for ; Wed, 21 Nov 2012 11:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOm15+nnrDp9 for ; Wed, 21 Nov 2012 11:26:40 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 976A821F87F1 for ; Wed, 21 Nov 2012 11:26:40 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 21 Nov 2012 11:23:23 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.15) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 21 Nov 2012 11:25:15 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Wed, 21 Nov 2012 11:24:54 -0800 From: "Rajeev Manur" To: "ostokes@extremenetworks.com" , "Thomas Narten" , "Donald Eastlake" Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: AQHNvF9b8N8Z4Y4Mh0+/6OtzlkwgxpfwcVqAgAIWDoCAAAX9gIAAHRGAgACZ7oCAARU4gIAARHBA Date: Wed, 21 Nov 2012 19:24:54 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED1BE017A6@SJEXCHMB12.corp.ad.broadcom.com> References: <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CB3F5A33R06789094-18-01 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:26:41 -0000 My understanding is we have only 2 modes, VL-mode and FGL-mode (superset mo= de supporting both VL and FGL). I feel it would be useful to add more text = to clarify the processing/compliance requirements for ingress / transit / e= gress RB contexts separately for each of these two modes. This will help im= plementations they may want to support transit only functions and still be = compliant. For example, it is not clear to me when an RB wants to operate as transit-o= nly RB, VL/FGL capability can be configured per port or all ports on that R= B must be configured to operate in the same mode? I am assuming it is the l= atter. Thanks! --Rajeev -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of O= len Stokes Sent: Tuesday, November 20, 2012 9:08 PM To: Thomas Narten; Donald Eastlake Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Trying NOT to add anything more in line=A9 It seems that multiple different people have multiple different migration scenarios in mind. I think that several of us could benefit from something that better spells out what scenario(s) the authors have in mind. Donald's scenarios described in his response to my previous email would have helped the draft. We can then discuss if there are others that need to be considered. We seem to be discussing three types of nodes: 1) VL-only capable RBridges 2) VL and FGL capable RBridges 3) FGL-only capable Rbridges For the third (FGL-only) type, remember that at some point people will want to drop support for the VL RBridges. There may also be silicon out that that can operate in VL mode or in FGL mode but not both at the same time. Note, I am not a silicon person. If these three types are intended, a more clear statement of the requirements for each time might be of benefit. The requirements should describe ingress, egress, transit, and transit plus egress RBridges. If one of these types is not intended, then a clear statement that it is not supported may be in order. It could then be debated. I believe that Donald has described that the second type above (VL and FGL capable RBridge) is a requirement. To me, the best case for that requirement is in a multi-topolgy environment. Stating that use case would have made the document and that requirement more clear to me. I leave it to others to figure out how to reference something that might be defined in another draft (at some point in the future). Note that to me, a "VL and FGL capable" node acting only as a VL node is just a VL RBridge. Cheers, Olen=20 On 11/20/12 7:35 AM, "Thomas Narten" wrote: >Hi Donald. > >Donald Eastlake writes: > > >> > My understanding (from reading the draft earlier today) was that an RB >> > either operates in FGL mode or VL mode. It doesn't mix and >> > match. I.e., you don't have an RB with some ports understanding FGL >> > and others VL. (To do that, you'd an RB would have to convert between >> > the the two formats which could result in loss of information...) > >> So what exactly did you think text like the following meant: >> "An FGL RBridge MAY be configured, on one or more ports, to ingress >> native frames as FGL. Any ports not so configured that accepts a >> native frame perform the previously specified VL ingress processing >> on native frames [RFC6325]." > >Personally, I thought the wording was somewhat odd, and made a note to >figure out what the real intention was. :-) Also, "MAY" means it's not >part of the spec, but not being disallowed either. That is not the >same thing as saying it is something that implementations would want >or need to do. > >> I also can't see why you would think that the ability to ingress, >> transit, and egress both VL and FGL frames implies having to "convert" >> between those formats. The whole idea of data labeling is >> separation/isolation. Why would you convert between them anymore than >> you would convert between a random pair of different VLANs? > >No disagreement. My assumption had been that if you have an RB that >understands both VL and FGL, that such a mode would only be useful if >one was converting from one format to the other, or if one fell back >from from FGL to VL mode if it didn't make sense to operate in FGL >mode. But I wasn't 100% sure what the draft's intention was... > >But on rereading parts of the draft, it seems that a single TRILL >campus can actually consist of a mixture of both VL and FGL-capable >RBs. And that campus is effectively partitioned, where some of the >links/RBs operate in FGL mode (only) and the rest operate in VL mode >(only) with the data planes of the "two networks" operating likes >ships in the night. > >You can even have a single RB supporting both modes (on some >links). E.g., you could have RB1 with links L1 and L2 operating in VL >mode and links L3 and L4 operating in FGL mode. Right? (This is >because it is the individual links that operate in a given mode, not >the RB per se.) > >If so, let me push back on this model. The document says: > > The usual DRB election operates on a link with mixed FLG and VL > ports. If an FGL RBridge port is DRB, it MUST handle all native > traffic or appoint only other FGL ports as forwarder for one or more > VLANs, so that all end stations will get service to the FGL campus. > If a VL RBridge port is DRB, it will not understand that FGL RBridge > ports are different. To the extent that a VL DRB handles native > frames or appoints other VL ports on a link to handle native frames > for one or more VLANs, the end stations sending and receiving those > native frames will be isolated from the FGL campus. To the extent > that a VL DRB happens to appoint an FGL port as Appointed Forwarder > for one or more VLANs, the end stations sending and receiving native > frames in those VLANs will get service to the FGL campus. This > somewhat odd corner case behavior is considered acceptable because it > is assumed that VL TRILL switches in an FGL campus are infrequent > misconfigurations. > >I would not just call this a "corner case" that can be ignored. What >it seems to mean is that you can deply TRILL, but get disconnected >VLAN islands. That is, C-VID X at one edge is processed by FGL RBs >(say RB1), but elsewhere on the network, only VL RBs connect to C-VID >X (say via RB2). Because the VL and FGL networks are isolated from >each other, the result is that devices in VLAN X connected to RB1 will >be unable to communicated with devices in VLAN X connected to >RB2. Right? > >I wouldn't consider that a "corner case" to be ignored. I'd consider >that an operational nightmare that can't be allowed to happen (by >default). > >> Anyway, the intent is that ports operate in either VL or FGL mode. And >> all the ports of a VL RBridge are VL ports. But an FGL RBridge is >> required to support an arbitrary mix of VL and FGL ports. VL and FGL >> frames are ships in the night just like VL frames for different VLANs >> for FGL frames for different FGLs. > >Why must FGL capable devices be required to support VL? I understand >that it is probably a good thing to do (so you can support either >mode, depending on what other RBs are capable of). But does the FGL >*protocol* require this in order to work correctly? Does proper >operation of FGL require being able to support VL as well? Or is the >real intent just to allow a graceful way to "fall back" into VL mode >to intereperate with non FGL-aware RBs? (I think that is a fine thing >to require, btw.) > >> > And the way to look at VL mode, is that it is the fallback for the >> > case where not all of the RBs in the compus are FGL capable. > >> The word "mode" does not occur anywhere in the body of the draft. FGL >> RBridges are supersets. FGL RBridges can handle VL frames fine. It is >> just that VL RBridges can't handle FGL frames and it is very hard to >> guarantee that an FGL frame will never be routed to a VL RBridge >> without either multi-topology (which is not yet fully specified for >> TRILL) or stopping all data flow between VL and FGL RBridges (whcih is >> what this draft does). > >IMO, this spec should not say anything about multi-topology (that is >future work) and should ensure that a standards compliant >implementation cannot and will not forward FGL packets to VL-only >RBs. Anything else will likely lead to operational problems... > >> > I.e., what is supposed o happen in a campus where some RBs say they do >> > FGL and others do not? Is the intention that one TRILL campus gets >> > formed with all nodes falling back to VL mode? > >> As stated in the draft, the assumption in that case is that you wanted >> a completely FGL campus and whatever VL RBridges are present are >> isolated misconfigurations. > >I think this is an unreasonable assumption. You will get deployments >that have both. Accidents can happen, etc. I think we'd be better off >with very clear ways for the operator to specify what they want to >have happen in a mixed mode. We can have a default mode, but the >operator needs to be able to override the defaults. > >I.e., if only one (or a small number of) switches supports FGL, you >want the default mode to be to have the entire TRILL campus to try to >use FGL? I'm not sure. > >> So the provisions are that all the RBridges peer for control but VL >> and FGL RBridges do not peer for data. You don't want the attachment >> of one RBridge misconfigured to be a VL RBridge to kill your whole >> FGL campus. You can't "fall back" a port configured for FGL without >> violating security policy. > >I don't understand the "security policy" reference here. > >> Maybe clarifying text should be added and the "FGL RBridges" should be >> referred to as "FGLVL RBridges". > >No. The issue isn't terminology. The text needs to be clearer what the >intention is. For me, it's sometimes hard to pull out the overriding >intention from the specific rules that are layed out in the document. > >Thomas > >_______________________________________________ >trill mailing list >trill@ietf.org >https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From radiaperlman@gmail.com Wed Nov 21 15:28:36 2012 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 6FF5321F8555 for ; Wed, 21 Nov 2012 15:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c47FJQIrwpam for ; Wed, 21 Nov 2012 15:28:34 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 549AA21F8516 for ; Wed, 21 Nov 2012 15:28:34 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so8775842vbb.31 for ; Wed, 21 Nov 2012 15:28:33 -0800 (PST) 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:content-type; bh=wn/mBm23LsiTr0BYqiOkQ901oln6MEuvjDz743eKil0=; b=BM+Uku5qWpJbH+ORjn+pPAiLzg46lH3FzXHXYTTA8dJ2/q3MKd5evt73s62SJDsSfu J7B727PpbTjD8le0Bv7eX00HdLWC3Lh/KowxbZ0eAIIru8KzrkQ+mfsv6WCSoQ/a5fzg hqwJAN0/BloPSc+hlVmfG78JaKV+ODaxCqCv7A2UVPHHCRzDJ7N49rsXcPozJ6e/vYhV TPhCZq3DaYrc0GJJS/TUK1n29YvUW+BeZtNvmEDOVMAjNi4QWe3e9vPHMcqdZ7Y+Q4J6 lYT/Dcnkpb4Cn3GdMHiZ31eKvSJtMcQ1u0G6mu7wEiIIlOfJnw/1i7enoS/1FvJBBfyh wk4w== MIME-Version: 1.0 Received: by 10.58.74.40 with SMTP id q8mr29726960vev.36.1353540513687; Wed, 21 Nov 2012 15:28:33 -0800 (PST) Received: by 10.58.207.138 with HTTP; Wed, 21 Nov 2012 15:28:33 -0800 (PST) In-Reply-To: <1E714095C88C9D408749A723A59CF6ED1BE017A6@SJEXCHMB12.corp.ad.broadcom.com> References: <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> <1E714095C88C9D408749A723A59CF6ED1BE017A6@SJEXCHMB12.corp.ad.broadcom.com> Date: Wed, 21 Nov 2012 15:28:33 -0800 Message-ID: From: Radia Perlman To: Rajeev Manur Content-Type: multipart/alternative; boundary=047d7b6d7ab481e87104cf09b54c Cc: Thomas Narten , Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 23:28:36 -0000 --047d7b6d7ab481e87104cf09b54c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd think it ought to be possible to have a really simple transit-only RB R that doesn't bother looking beyond the TRILL header...so doesn't care what VLAN or FGL it is...R won't do any filtering, but filtering is only an optimization, except at the edges, where it is mandatory. Anyway...back to two tags vs a single 24-bit tag...we really have to pick one and go with it. Either one works, and although one tag might be a bit more elegant, I've informally asked some implementers and some of them said they don't care, and others say they prefer two 12-bit pieces in two tags, so I vote that we stick with that. As for the spec...yeah, as people pointed out, there are places where the spec could be clarified, and we should do that. Of the combinations possible, which should be described in the spec? I think FGL+VL, and VL definitely. And the base spec already describes VL-only. We might also want to mention neither FGL nor VL (transit only, no filtering). We might also want to mention eventually dropping support for VL, and allowing a mixture of FGL+VL and FGL-only. But for simplicity, I think we should not describe that variant at that point, and only describe (in this document), FGL+VL and its interoperability with VL-only. Does anyone have any strong opinions? Radia On Wed, Nov 21, 2012 at 11:24 AM, Rajeev Manur wrote: > > My understanding is we have only 2 modes, VL-mode and FGL-mode (superset > mode supporting both VL and FGL). I feel it would be useful to add more > text to clarify the processing/compliance requirements for ingress / > transit / egress RB contexts separately for each of these two modes. This > will help implementations they may want to support transit only functions > and still be compliant. > > For example, it is not clear to me when an RB wants to operate as > transit-only RB, VL/FGL capability can be configured per port or all port= s > on that RB must be configured to operate in the same mode? I am assuming = it > is the latter. > > Thanks! > --Rajeev > > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of > Olen Stokes > Sent: Tuesday, November 20, 2012 9:08 PM > To: Thomas Narten; Donald Eastlake > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > > Trying NOT to add anything more in line=C5=A0 > > It seems that multiple different people have multiple different migration > scenarios in mind. I think that several of us could benefit from > something that better spells out what scenario(s) the authors have in > mind. Donald's scenarios described in his response to my previous email > would have helped the draft. We can then discuss if there are others tha= t > need to be considered. > > We seem to be discussing three types of nodes: > > 1) VL-only capable RBridges > 2) VL and FGL capable RBridges > 3) FGL-only capable Rbridges > > For the third (FGL-only) type, remember that at some point people will > want to drop support for the VL RBridges. There may also be silicon out > that that can operate in VL mode or in FGL mode but not both at the same > time. Note, I am not a silicon person. > > If these three types are intended, a more clear statement of the > requirements for each time might be of benefit. The requirements should > describe ingress, egress, transit, and transit plus egress RBridges. If > one of these types is not intended, then a clear statement that it is not > supported may be in order. It could then be debated. > > I believe that Donald has described that the second type above (VL and FG= L > capable RBridge) is a requirement. To me, the best case for that > requirement is in a multi-topolgy environment. Stating that use case > would have made the document and that requirement more clear to me. I > leave it to others to figure out how to reference something that might be > defined in another draft (at some point in the future). Note that to me, > a "VL and FGL capable" node acting only as a VL node is just a VL RBridge= . > > Cheers, > Olen > > > On 11/20/12 7:35 AM, "Thomas Narten" wrote: > > >Hi Donald. > > > >Donald Eastlake writes: > > > > > >> > My understanding (from reading the draft earlier today) was that an = RB > >> > either operates in FGL mode or VL mode. It doesn't mix and > >> > match. I.e., you don't have an RB with some ports understanding FGL > >> > and others VL. (To do that, you'd an RB would have to convert betwe= en > >> > the the two formats which could result in loss of information...) > > > >> So what exactly did you think text like the following meant: > >> "An FGL RBridge MAY be configured, on one or more ports, to ingress > >> native frames as FGL. Any ports not so configured that accepts a > >> native frame perform the previously specified VL ingress processing > >> on native frames [RFC6325]." > > > >Personally, I thought the wording was somewhat odd, and made a note to > >figure out what the real intention was. :-) Also, "MAY" means it's not > >part of the spec, but not being disallowed either. That is not the > >same thing as saying it is something that implementations would want > >or need to do. > > > >> I also can't see why you would think that the ability to ingress, > >> transit, and egress both VL and FGL frames implies having to "convert" > >> between those formats. The whole idea of data labeling is > >> separation/isolation. Why would you convert between them anymore than > >> you would convert between a random pair of different VLANs? > > > >No disagreement. My assumption had been that if you have an RB that > >understands both VL and FGL, that such a mode would only be useful if > >one was converting from one format to the other, or if one fell back > >from from FGL to VL mode if it didn't make sense to operate in FGL > >mode. But I wasn't 100% sure what the draft's intention was... > > > >But on rereading parts of the draft, it seems that a single TRILL > >campus can actually consist of a mixture of both VL and FGL-capable > >RBs. And that campus is effectively partitioned, where some of the > >links/RBs operate in FGL mode (only) and the rest operate in VL mode > >(only) with the data planes of the "two networks" operating likes > >ships in the night. > > > >You can even have a single RB supporting both modes (on some > >links). E.g., you could have RB1 with links L1 and L2 operating in VL > >mode and links L3 and L4 operating in FGL mode. Right? (This is > >because it is the individual links that operate in a given mode, not > >the RB per se.) > > > >If so, let me push back on this model. The document says: > > > > The usual DRB election operates on a link with mixed FLG and VL > > ports. If an FGL RBridge port is DRB, it MUST handle all native > > traffic or appoint only other FGL ports as forwarder for one or more > > VLANs, so that all end stations will get service to the FGL campus. > > If a VL RBridge port is DRB, it will not understand that FGL RBridge > > ports are different. To the extent that a VL DRB handles native > > frames or appoints other VL ports on a link to handle native frames > > for one or more VLANs, the end stations sending and receiving those > > native frames will be isolated from the FGL campus. To the extent > > that a VL DRB happens to appoint an FGL port as Appointed Forwarder > > for one or more VLANs, the end stations sending and receiving native > > frames in those VLANs will get service to the FGL campus. This > > somewhat odd corner case behavior is considered acceptable because it > > is assumed that VL TRILL switches in an FGL campus are infrequent > > misconfigurations. > > > >I would not just call this a "corner case" that can be ignored. What > >it seems to mean is that you can deply TRILL, but get disconnected > >VLAN islands. That is, C-VID X at one edge is processed by FGL RBs > >(say RB1), but elsewhere on the network, only VL RBs connect to C-VID > >X (say via RB2). Because the VL and FGL networks are isolated from > >each other, the result is that devices in VLAN X connected to RB1 will > >be unable to communicated with devices in VLAN X connected to > >RB2. Right? > > > >I wouldn't consider that a "corner case" to be ignored. I'd consider > >that an operational nightmare that can't be allowed to happen (by > >default). > > > >> Anyway, the intent is that ports operate in either VL or FGL mode. And > >> all the ports of a VL RBridge are VL ports. But an FGL RBridge is > >> required to support an arbitrary mix of VL and FGL ports. VL and FGL > >> frames are ships in the night just like VL frames for different VLANs > >> for FGL frames for different FGLs. > > > >Why must FGL capable devices be required to support VL? I understand > >that it is probably a good thing to do (so you can support either > >mode, depending on what other RBs are capable of). But does the FGL > >*protocol* require this in order to work correctly? Does proper > >operation of FGL require being able to support VL as well? Or is the > >real intent just to allow a graceful way to "fall back" into VL mode > >to intereperate with non FGL-aware RBs? (I think that is a fine thing > >to require, btw.) > > > >> > And the way to look at VL mode, is that it is the fallback for the > >> > case where not all of the RBs in the compus are FGL capable. > > > >> The word "mode" does not occur anywhere in the body of the draft. FGL > >> RBridges are supersets. FGL RBridges can handle VL frames fine. It is > >> just that VL RBridges can't handle FGL frames and it is very hard to > >> guarantee that an FGL frame will never be routed to a VL RBridge > >> without either multi-topology (which is not yet fully specified for > >> TRILL) or stopping all data flow between VL and FGL RBridges (whcih is > >> what this draft does). > > > >IMO, this spec should not say anything about multi-topology (that is > >future work) and should ensure that a standards compliant > >implementation cannot and will not forward FGL packets to VL-only > >RBs. Anything else will likely lead to operational problems... > > > >> > I.e., what is supposed o happen in a campus where some RBs say they = do > >> > FGL and others do not? Is the intention that one TRILL campus gets > >> > formed with all nodes falling back to VL mode? > > > >> As stated in the draft, the assumption in that case is that you wanted > >> a completely FGL campus and whatever VL RBridges are present are > >> isolated misconfigurations. > > > >I think this is an unreasonable assumption. You will get deployments > >that have both. Accidents can happen, etc. I think we'd be better off > >with very clear ways for the operator to specify what they want to > >have happen in a mixed mode. We can have a default mode, but the > >operator needs to be able to override the defaults. > > > >I.e., if only one (or a small number of) switches supports FGL, you > >want the default mode to be to have the entire TRILL campus to try to > >use FGL? I'm not sure. > > > >> So the provisions are that all the RBridges peer for control but VL > >> and FGL RBridges do not peer for data. You don't want the attachment > >> of one RBridge misconfigured to be a VL RBridge to kill your whole > >> FGL campus. You can't "fall back" a port configured for FGL without > >> violating security policy. > > > >I don't understand the "security policy" reference here. > > > >> Maybe clarifying text should be added and the "FGL RBridges" should be > >> referred to as "FGLVL RBridges". > > > >No. The issue isn't terminology. The text needs to be clearer what the > >intention is. For me, it's sometimes hard to pull out the overriding > >intention from the specific rules that are layed out in the document. > > > >Thomas > > > >_______________________________________________ > >trill mailing list > >trill@ietf.org > >https://www.ietf.org/mailman/listinfo/trill > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --047d7b6d7ab481e87104cf09b54c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd think it ought to be possible to have a really simple transit-= only RB R=C2=A0that doesn't bother looking beyond the TRILL header...so= doesn't care what VLAN or FGL it is...R won't do any filtering, bu= t filtering is only an optimization, except at the edges, where it is manda= tory.
=C2=A0
Anyway...back to two tags vs a single 24-bit tag...we= really have to pick one and go with it.=C2=A0 Either one works, and althou= gh one tag might be a bit more elegant, I've informally asked some impl= ementers and some of them said they don't care, and others say they pre= fer two 12-bit pieces in two tags, so I vote that we stick with that.
=C2=A0
As for the spec...yeah, as people pointed out, there = are places where the spec could be clarified, and we should do that.
<= div>=C2=A0
Of the combinations possible, which should be describe= d in the spec?
=C2=A0
I think FGL+VL, and VL definitely.=C2=A0 And the base= spec already describes VL-only.
=C2=A0
We might also w= ant to mention neither FGL nor VL (transit only, no filtering).
= =C2=A0
We might also want to mention eventually dropping support for VL, and allow= ing a mixture of FGL+VL and FGL-only.=C2=A0 But for simplicity, I think we = should not describe that variant at that point, and only describe (in this = document), FGL+VL and its interoperability with VL-only.
=C2=A0
Does anyone have any strong opinions?
=C2= =A0
Radia

On Wed, Nov 21,= 2012 at 11:24 AM, Rajeev Manur <rmanur@broadcom.com> wrot= e:

My understanding is we have only 2 modes, VL-mode and FGL-mode (superset mo= de supporting both VL and FGL). I feel it would be useful to add more text = to clarify the processing/compliance requirements for ingress / transit / e= gress RB contexts separately for each of these two modes. This will help im= plementations they may want to support transit only functions and still be = compliant.

For example, it is not clear to me when an RB wants to operate as transit-o= nly RB, VL/FGL capability can be configured per port or all ports on that R= B must be configured to operate in the same mode? I am assuming it is the l= atter.

Thanks!
--Rajeev


-----Original Message-----
From: trill-bounces@ietf.org = [mailto:trill-bounces@ietf.org] On Behalf Of Olen Stokes
Sent: Tuesday, November 20, 2012 9:08 PM
To: Thomas Narten; Donald Eastlake
Cc: trill@ietf.org
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

Trying NOT to add anything mo= re in line=C5=A0

It seems that multiple different people have multiple different migration scenarios in mind. =C2=A0I think that several of us could benefit from
something that better spells out what scenario(s) the authors have in
mind. =C2=A0Donald's scenarios described in his response to my previous= email
would have helped the draft. =C2=A0We can then discuss if there are others = that
need to be considered.

We seem to be discussing three types of nodes:

1) VL-only capable RBridges
2) VL and FGL capable RBridges
3) FGL-only capable Rbridges

For the third (FGL-only) type, remember that at some point people will
want to drop support for the VL RBridges. =C2=A0There may also be silicon o= ut
that that can operate in VL mode or in FGL mode but not both at the same time. =C2=A0Note, I am not a silicon person.

If these three types are intended, a more clear statement of the
requirements for each time might be of benefit. =C2=A0The requirements shou= ld
describe ingress, egress, transit, and transit plus egress RBridges. If
one of these types is not intended, then a clear statement that it is not supported may be in order. =C2=A0It could then be debated.

I believe that Donald has described that the second type above (VL and FGL<= br> capable RBridge) is a requirement. =C2=A0To me, the best case for that
requirement is in a multi-topolgy environment. =C2=A0Stating that use case<= br> would have made the document and that requirement more clear to me. =C2=A0I=
leave it to others to figure out how to reference something that might be defined in another draft (at some point in the future). =C2=A0Note that to = me,
a "VL and FGL capable" node acting only as a VL node is just a VL= RBridge.

Cheers,
Olen


On 11/20/12 7:35 AM, "Thomas Narten" <narten@us.ibm.com> wrote:

>Hi Donald.
>
>Donald Eastlake <d3e3e3@gmail.co= m> writes:
>
>
>> > My understanding (from reading the draft earlier today) was t= hat an RB
>> > either operates in FGL mode or VL mode. It doesn't mix an= d
>> > match. I.e., you don't have an RB with some ports underst= anding FGL
>> > and others VL. =C2=A0(To do that, you'd an RB would have = to convert between
>> > the the two formats which could result in loss of information= ...)
>
>> So what exactly did you think text like the following meant:
>> =C2=A0 =C2=A0"An FGL RBridge MAY be configured, on one or mor= e ports, to ingress
>> =C2=A0 =C2=A0native frames as FGL. Any ports not so configured tha= t accepts a
>> =C2=A0 =C2=A0native frame perform the previously specified VL ingr= ess processing
>> =C2=A0 =C2=A0on native frames [RFC6325]."
>
>Personally, I thought the wording was somewhat odd, and made a note to<= br> >figure out what the real intention was. :-) Also, "MAY" means= it's not
>part of the spec, but not being disallowed either. That is not the
>same thing as saying it is something that implementations would want >or need to do.
>
>> I also can't see why you would think that the ability to ingre= ss,
>> transit, and egress both VL and FGL frames implies having to "= ;convert"
>> between those formats. The whole idea of data labeling is
>> separation/isolation. Why would you convert between them anymore t= han
>> you would convert between a random pair of different VLANs?
>
>No disagreement. My assumption had been that if you have an RB that
>understands both VL and FGL, that such a mode would only be useful if >one was converting from one format to the other, or if one fell back >from from FGL to VL mode if it didn't make sense to operate in FGL<= br> >mode. But I wasn't 100% sure what the draft's intention was...<= br> >
>But on rereading parts of the draft, it seems that a single TRILL
>campus can actually consist of a mixture of both VL and FGL-capable
>RBs. And that campus is effectively partitioned, where some of the
>links/RBs operate in FGL mode (only) and the rest operate in VL mode >(only) with the data planes of the "two networks" operating l= ikes
>ships in the night.
>
>You can even have a single RB supporting both modes (on some
>links). E.g., you could have RB1 with links L1 and L2 operating in VL >mode and links L3 and L4 operating in FGL mode. Right? (This is
>because it is the individual links that operate in a given mode, not >the RB per se.)
>
>If so, let me push back on this model. =C2=A0The document says:
>
> =C2=A0 The usual DRB election operates on a link with mixed FLG and VL=
> =C2=A0 ports. If an FGL RBridge port is DRB, it MUST handle all native=
> =C2=A0 traffic or appoint only other FGL ports as forwarder for one or= more
> =C2=A0 VLANs, so that all end stations will get service to the FGL cam= pus.
> =C2=A0 If a VL RBridge port is DRB, it will not understand that FGL RB= ridge
> =C2=A0 ports are different. To the extent that a VL DRB handles native=
> =C2=A0 frames or appoints other VL ports on a link to handle native fr= ames
> =C2=A0 for one or more VLANs, the end stations sending and receiving t= hose
> =C2=A0 native frames will be isolated from the FGL campus. To the exte= nt
> =C2=A0 that a VL DRB happens to appoint an FGL port as Appointed Forwa= rder
> =C2=A0 for one or more VLANs, the end stations sending and receiving n= ative
> =C2=A0 frames in those VLANs will get service to the FGL campus. This<= br> > =C2=A0 somewhat odd corner case behavior is considered acceptable beca= use it
> =C2=A0 is assumed that VL TRILL switches in an FGL campus are infreque= nt
> =C2=A0 misconfigurations.
>
>I would not just call this a "corner case" that can be ignore= d. What
>it seems to mean is that you can deply TRILL, but get disconnected
>VLAN islands. That is, C-VID X at one edge is processed by FGL RBs
>(say RB1), but elsewhere on the network, only VL RBs connect to C-VID >X (say via RB2). Because the VL and FGL networks are isolated from
>each other, the result is that devices in VLAN X connected to RB1 will<= br> >be unable to communicated with devices in VLAN X connected to
>RB2. Right?
>
>I wouldn't consider that a "corner case" to be ignored. I= 'd consider
>that an operational nightmare that can't be allowed to happen (by >default).
>
>> Anyway, the intent is that ports operate in either VL or FGL mode.= And
>> all the ports of a VL RBridge are VL ports. But an FGL RBridge is<= br> >> required to support an arbitrary mix of VL and FGL ports. VL and F= GL
>> frames are ships in the night just like VL frames for different VL= ANs
>> for FGL frames for different FGLs.
>
>Why must FGL capable devices be required to support VL? I understand >that it is probably a good thing to do (so you can support either
>mode, depending on what other RBs are capable of). But does the FGL
>*protocol* require this in order to work correctly? Does proper
>operation of FGL require being able to support VL as well? Or is the >real intent just to allow a graceful way to "fall back" into = VL mode
>to intereperate with non FGL-aware RBs? (I think that is a fine thing >to require, btw.)
>
>> > And the way to look at VL mode, is that it is the fallback fo= r the
>> > case where not all of the RBs in the compus are FGL capable.<= br> >
>> The word "mode" does not occur anywhere in the body of t= he draft. FGL
>> RBridges are supersets. FGL RBridges can handle VL frames fine. It= is
>> just that VL RBridges can't handle FGL frames and it is very h= ard to
>> guarantee that an FGL frame will never be routed to a VL RBridge >> without either multi-topology (which is not yet fully specified fo= r
>> TRILL) or stopping all data flow between VL and FGL RBridges (whci= h is
>> what this draft does).
>
>IMO, this spec should not say anything about multi-topology (that is >future work) and should ensure that a standards compliant
>implementation cannot and will not forward FGL packets to VL-only
>RBs. Anything else will likely lead to operational problems...
>
>> > I.e., what is supposed o happen in a campus where some RBs sa= y they do
>> > FGL and others do not? Is the intention that one TRILL campus= gets
>> > formed with all nodes falling back to VL mode?
>
>> As stated in the draft, the assumption in that case is that you wa= nted
>> a completely FGL campus and whatever VL RBridges are present are >> isolated misconfigurations.
>
>I think this is an unreasonable assumption. You will get deployments >that have both. Accidents can happen, etc. I think we'd be better o= ff
>with very clear ways for the operator to specify what they want to
>have happen in a mixed mode. We can have a default mode, but the
>operator needs to be able to override the defaults.
>
>I.e., if only one (or a small number of) switches supports FGL, you
>want the default mode to be to have the entire TRILL campus to try to >use FGL? I'm not sure.
>
>> So the provisions are that all the RBridges peer for control but V= L
>> and FGL RBridges do not peer for data. You don't want the atta= chment
>> of one RBridge misconfigured to be a VL RBridge to kill your whole=
>> FGL campus. You can't "fall back" a port configured = for FGL without
>> violating security policy.
>
>I don't understand the "security policy" reference here.<= br> >
>> Maybe clarifying text should be added and the "FGL RBridges&q= uot; should be
>> referred to as "FGLVL RBridges".
>
>No. The issue isn't terminology. The text needs to be clearer what = the
>intention is. For me, it's sometimes hard to pull out the overridin= g
>intention from the specific rules that are layed out in the document. >
>Thomas
>
>_______________________________________________
>trill mailing list
>trill@ietf.org
>https://www.ietf.org/mailman/listinfo/trill

_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill


_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--047d7b6d7ab481e87104cf09b54c-- From d3e3e3@gmail.com Wed Nov 21 17:14:36 2012 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 1E58121E8044 for ; Wed, 21 Nov 2012 17:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfOgvAQHNEKo for ; Wed, 21 Nov 2012 17:14:34 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB03821E8034 for ; Wed, 21 Nov 2012 17:14:34 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4078042ieb.31 for ; Wed, 21 Nov 2012 17:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oVbRTZyUqmT0Nd4Re/GDjC2zBxruiH03qlN1EzaLdJw=; b=WOYfYbq/4hMF41+LvqzWlshPJjqExfXmpvJDgTyBB2GJuQHs1m0Ajev3oo5qGeSpDE 2yk/ZDmqec8uytvWzrUfQIT4+HyPd4pJSH+SwoUuV21md3vitESJpE2tQRzmrQDpTtAx agHQvBTNaDP2Tvq/yvJHVQF0dQoP7lqclHoW8DKlre6Tpw9EetI48jXiqos9hq8U6quj Uw8BHQJDH2kGYSpyzjCfdaygL/yH4EAvzbX04kmG5HLui2ednm/5zyJ1tdoD5eHyGeOJ EdECbo5suX/eC2wjyXY7MxQYbEoVc7vEILd3acOh+XynwXdlva9GOsvigKuLfXmCUU2R fjNQ== Received: by 10.50.140.74 with SMTP id re10mr1062374igb.55.1353546874288; Wed, 21 Nov 2012 17:14:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.102.164 with HTTP; Wed, 21 Nov 2012 17:14:14 -0800 (PST) In-Reply-To: <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Wed, 21 Nov 2012 20:14:14 -0500 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 01:14:36 -0000 Hi Thomas, On Tue, Nov 20, 2012 at 7:35 AM, Thomas Narten wrote: > Hi Donald. > > Donald Eastlake writes: > >> > My understanding (from reading the draft earlier today) was that >> > an RB either operates in FGL mode or VL mode. It doesn't mix and >> > match. I.e., you don't have an RB with some ports understanding >> > FGL and others VL. (To do that, you'd an RB would have to >> > convert between the the two formats which could result in loss of >> > information...) If it's an FGL RBridge, all ports must understand FGL TRILL Data frames and VL TRILL Data frames. It also may be able to ingress/egress native frames to/from FGL TRILL Data frames but must be able to ingress/egress native frames to/from VL TRILL Data frames. If it's a VL RBridges, all port must understand VL TRILL Data frames and none of its ports will understand FGL TRILL Data frames. It also must be able to ingress/egress native frames to/from VL TRILL Data frames but will be unable to ingress/egress native frames to/from FGL TRILL Data frames. >> So what exactly did you think text like the following meant: "An >> FGL RBridge MAY be configured, on one or more ports, to ingress >> native frames as FGL. Any ports not so configured that accepts a >> native frame perform the previously specified VL ingress >> processing on native frames [RFC6325]." > > > Personally, I thought the wording was somewhat odd, and made a note > to figure out what the real intention was. :-) Also, "MAY" means > it's not part of the spec, but not being disallowed either. That is > not the same thing as saying it is something that implementations > would want or need to do. So, I think it should be MAY because the way "FGL RBridge" is used in this draft, an RBridge that can only correctly transit FGL frames but can't ingress or egress them still counts as an FGL RBridge. This would probably be a legacy RBridge of some sort that had been upgraded and whose silicon can handle transit (perhaps it simplifies the transit problem by not doing an pruning of multi-destinaiton FGL frames) but whose silicon isn't up to the additional requirements to ingress/egress FGL. >> I also can't see why you would think that the ability to ingress, >> transit, and egress both VL and FGL frames implies having to >> "convert" between those formats. The whole idea of data labeling is >> separation/isolation. Why would you convert between them anymore >> than you would convert between a random pair of different VLANs? > > No disagreement. My assumption had been that if you have an RB that > understands both VL and FGL, that such a mode would only be useful > if one was converting from one format to the other, or if one fell > back from from FGL to VL mode if it didn't make sense to operate in > FGL mode. But I wasn't 100% sure what the draft's intention was... > > But on rereading parts of the draft, it seems that a single TRILL > campus can actually consist of a mixture of both VL and FGL-capable > RBs. And that campus is effectively partitioned, where some of the > links/RBs operate in FGL mode (only) and the rest operate in VL mode > (only) with the data planes of the "two networks" operating likes > ships in the night. There are no "modes". I think that word is just confusing. Obviously, you can have a campus of mixed VL and FGL RBridges, just plug the cables in and there you are. But, as it says in the draft, the assumption is that, in that situation, you wanted an FGL campus and there are just a few misconfigured/whatever VL RBridges, so they are data isolated (but still peer in the control plane). VL RBridges can only handle VL frames. FGL RBridges handle both. In the future, some extension of TRILL such as multi-topoogy, may permit data connectivity between VL and FGL RBridges. If you update a VL RBridge so that it can do FGL transit, but not FGL ingress/egress, then it becomes a (limiated) FGL RBridge and is fully inter connected. Furthermore, end stations attached to such a limited FGL RBridge can communicate with end stations attached to full FGL RBridges (ones that can to ingress/egress as well as transit), they just have to use VL frames for that communication. > You can even have a single RB supporting both modes (on some > links). E.g., you could have RB1 with links L1 and L2 operating in VL > mode and links L3 and L4 operating in FGL mode. Right? (This is > because it is the individual links that operate in a given mode, not > the RB per se.) There are no "modes". A link can be just a piece of wire. It can't be VL or FGL. However, a port can be VL or FGL. Note that the VLAN label or FG label is hidden inside the frame. If the link happens to be an Ethernet link, then frames on it can also have an outer VL -- but if that frame is a TRILL Data frame, this outer VL doesn't have anything to do with whether the payload inside is VL or FGL or what its label value is. > If so, let me push back on this model. The document says: > > The usual DRB election operates on a link with mixed FGL and VL > ports. If an FGL RBridge port is DRB, it MUST handle all native > traffic or appoint only other FGL ports as forwarder for one or more > VLANs, so that all end stations will get service to the FGL campus. > If a VL RBridge port is DRB, it will not understand that FGL RBridge > ports are different. To the extent that a VL DRB handles native > frames or appoints other VL ports on a link to handle native frames > for one or more VLANs, the end stations sending and receiving those > native frames will be isolated from the FGL campus. To the extent > that a VL DRB happens to appoint an FGL port as Appointed Forwarder > for one or more VLANs, the end stations sending and receiving native > frames in those VLANs will get service to the FGL campus. This > somewhat odd corner case behavior is considered acceptable because it > is assumed that VL TRILL switches in an FGL campus are infrequent > misconfigurations. > > I would not just call this a "corner case" that can be ignored. What > it seems to mean is that you can deploy TRILL, but get disconnected > VLAN islands. That is, C-VID X at one edge is processed by FGL RBs > (say RB1), but elsewhere on the network, only VL RBs connect to C-VID > X (say via RB2). Because the VL and FGL networks are isolated from > each other, the result is that devices in VLAN X connected to RB1 will > be unable to communicated with devices in VLAN X connected to > RB2. Right? Yes. If you want full connectivity and you want to be able to use fine grained labels, you need all your RBridges to be FGL RBridges (at least "limited" FGL RBridges as used above). The assumption is that you want an FGL campus and that any VL RBridges are isolated misconfigurations. Since VL RBridges cannot safely handle traffic from FGL RBridges, which might contain FGL frames, the VL and FGL RBridges can't talk to each other in the data plane. As long as you have only a few scattered VL RBridges in an FGL campus, things will work pretty well except that those VL RBridges (and any end stations attached to them) will be data isolated. (And the inverse is also true. If you have only a few scattered FGL RBridges in a VL campus, the FGL RBridges will be data isolated. If you have a random mix, you're screwed because they cannot safely talk to each other and connectivity will probably be pretty poor if they are randomly intermingled.) > I wouldn't consider that a "corner case" to be ignored. I'd consider > that an operational nightmare that can't be allowed to happen (by > default). Come on. People all the time assume you update all the switches in some network simultaneously. Furthermore the mixed VL and FGL RBridges still have control connectivity so you can see in the limk state exactly what is going on. The isolation of VL and FGL RBridges is only for the flow of TRILL Data frames. Sure, you can get an "operational nightmare" is you grossly misconfigure a TRILL network just like you can by grossly misconfiguring a wide variety of other networks. >> Anyway, the intent is that ports operate in either VL or FGL mode. And >> all the ports of a VL RBridge are VL ports. But an FGL RBridge is >> required to support an arbitrary mix of VL and FGL ports. VL and FGL >> frames are ships in the night just like VL frames for different VLANs >> for FGL frames for different FGLs. > > Why must FGL capable devices be required to support VL? I understand > that it is probably a good thing to do (so you can support either > mode, depending on what other RBs are capable of). But does the FGL > *protocol* require this in order to work correctly? Does proper > operation of FGL require being able to support VL as well? Or is the > real intent just to allow a graceful way to "fall back" into VL mode > to intereperate with non FGL-aware RBs? (I think that is a fine thing > to require, btw.) Given the assumption is that you want an FGL campus and that any VL RBridges are isolated misconfigurations, if the presence of one or more VL RBridges (due to misconfiguriaton) forced a fall back, you would be screwed. Why is it that you want to break VL handling in FGL RBridges just because they can handloe FGL? In the future, with a variety of TRILL extensions, it will be possible to have data connectivity from legacy VL RBridges to FGL RBridges. One such extension is multi-topology with one topology for all RBridges and one for just FGL RBridges. Assuming the FGL RBridges are fully connected with each other and that you put FGL frames on the FGL topology and VL frames on the all RBridges topology, everything would work fine. Another possible extension would be multi-level IS-IS TRILL. As long as a level 1 area was all VL or all FGL and level 2 was FGL (and you don't try to heal level 2 partitions by sending frames through a random level 1) then it will all work fine. And in both cases, end stations attached to legacy VL RBridge could talk to end stations attached to FGL RBridges as long as they talk only with VL frames. >> > And the way to look at VL mode, is that it is the fallback for >> > the case where not all of the RBs in the compus are FGL capable. > >> The word "mode" does not occur anywhere in the body of the >> draft. FGL RBridges are supersets. FGL RBridges can handle VL >> frames fine. It is just that VL RBridges can't handle FGL frames >> and it is very hard to guarantee that an FGL frame will never be >> routed to a VL RBridge without either multi-topology (which is not >> yet fully specified for TRILL) or stopping all data flow between VL >> and FGL RBridges (whcih is what this draft does). > > IMO, this spec should not say anything about multi-topology (that is > future work) and should ensure that a standards compliant > implementation cannot and will not forward FGL packets to VL-only > RBs. Anything else will likely lead to operational problems... "Multi-topology" is not mentioned anywhere in the draft but given this conversation, it seems essential to mention the possibility of future enhancements such as multi-topology as the motivation for requiring FGL RBridges to be capable of handling VL frames. If you are going to treat FGL and VL frames differently for what is permitted between some ports on a link, then you pretty much need multi-topology. In particular, consider the problems of computing distribution trees. >> > I.e., what is supposed to happen in a campus where some RBs say >> > they do FGL and others do not? Is the intention that one TRILL >> > campus gets formed with all nodes falling back to VL mode? > >> As stated in the draft, the assumption in that case is that you >> wanted a completely FGL campus and whatever VL RBridges are present >> are isolated misconfigurations. > > I think this is an unreasonable assumption. You will get deployments > that have both. Accidents can happen, etc. I think we'd be better > off with very clear ways for the operator to specify what they want > to have happen in a mixed mode. We can have a default mode, but the > operator needs to be able to override the defaults. A random mixture of VL and FGL RBridges is not going to work well at all. A goal of TRILL is to be zero/minimal configuration. It might be a good idea to have a should/must requirement that FGL RBridges can be configured to act exactly like a VL RBridge. Then, if you really wanted a VL campus, you just configure your FGL RBridges to be VL RBridges. This shouldn't be too hard given that FGL is a superset of VL. > I.e., if only one (or a small number of) switches supports FGL, you > want the default mode to be to have the entire TRILL campus to try to > use FGL? I'm not sure. Well, in fact, if you have only few scattered RBridges that are FGL RBridges, the provisions currently in the draft work fine and data isolate those FGL RBridges because, at that level, they are symmetric. Because all they do is disable TRILL Data transfer between ports on a link if one or more port is on a VL RBridge and the one or more port is on an FGL RBridge. Everything else works fine including TRILL Data transfer if all are on VL RBridges or all are on FGL RBridges. And the TRILL IS-IS control plane works fine no matter which type of RBridges the ports are on. If you had, say, one compact area of VL RBridges and another compact area of FGL RBridges, with links between them, each would work fine internally, there just wouldn't be any data transfer between them (in the absence of future TRILL extensions such a multi-topology or multi-level). It's only if you have a random mixture of intermingled VL and FGL RBridges that things really don't work. >> So the provisions are that all the RBridges peer for control but VL >> and FGL RBridges do not peer for data. You don't want the >> attachment of one RBridge misconfigured to be a VL RBridge to kill >> your whole FGL campus. You can't "fall back" a port configured for >> FGL without violating security policy. > > I don't understand the "security policy" reference here. Deliverying data by egressing to a port not labeled with the VL or FGL of the data is a violation of security policy. If a port was configured to ingress VLAN-Y native frames to FGL-X, "falling back" so the port ingresses them as VLAN-Y would, in general, violate security policy because they could then be egress through VLAN-Y labeled ports rather than just FLG-X labeled ports. >> Maybe clarifying text should be added and the "FGL RBridges" should be >> referred to as "FGLVL RBridges". > > No. The issue isn't terminology. That's why I said "clarifying text should be added". . > The text needs to be clearer what the > intention is. For me, it's sometimes hard to pull out the overriding > intention from the specific rules that are layed out in the document. I agree that clarification is needed. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thomas From d3e3e3@gmail.com Wed Nov 21 18:56:17 2012 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 2D11521E8053 for ; Wed, 21 Nov 2012 18:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxYC1mo9rFNG for ; Wed, 21 Nov 2012 18:56:15 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0821E8048 for ; Wed, 21 Nov 2012 18:56:15 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4170836ieb.31 for ; Wed, 21 Nov 2012 18:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+RY6HGVBq3x29OQ+gsZ68dx+v7CvGqhBRXgGM6F9yh8=; b=loyTdfLGuMiDFfSgABezP7Srq16kFz79c+bgHebCCeiExaiJQ9CyudUfinwzFSt95C 2C1SJkYwxLW0WXh33JSkopzsJzou7Im746gVzXd3glBD9OphakNB1g0acaxY52hLpEF4 tKWAu37kTPXeIwfc7mxK9AvaGhKDgoQRWTgA8pEmEVsPfjIqXyQOSt3SwKwZijZLdGt4 htYTU+HQe5T9MdDcOQF1A8RfFD9b1rHs1e2XdpHOe+Z6gvsGvt6wos9KDXVdEKnMLPDb 00gVqSNKxGfvzJ/CGKep1bvesrEm3lCY+EF42PMrgprBSXvjSdU+7NdHHwKc7Re9XD6g vCWA== Received: by 10.42.180.10 with SMTP id bs10mr18811062icb.39.1353552975338; Wed, 21 Nov 2012 18:56:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.102.164 with HTTP; Wed, 21 Nov 2012 18:55:55 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075729D3@szxeml525-mbx.china.huawei.com> References: <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> <1E714095C88C9D408749A723A59CF6ED1BE017A6@SJEXCHMB12.corp.ad.broadcom.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075729D3@szxeml525-mbx.china.huawei.com> From: Donald Eastlake Date: Wed, 21 Nov 2012 21:55:55 -0500 Message-ID: To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 02:56:17 -0000 On Wed, Nov 21, 2012 at 9:09 PM, Xuxiaohu wrote: > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: trill-bounces@ietf.org [mailto:trill-bounces= @ietf.org] =E4=BB=A3=E8=A1=A8 Radia Perlman > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B411=E6=9C=8822=E6=97=A5= 7:29 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Rajeev Manur > =E6=8A=84=E9=80=81: Thomas Narten; Donald Eastlake; trill@ietf.org > =E4=B8=BB=E9=A2=98: Re: [trill] WG Last Call: draft-ietf-trill-fine-label= ing-02.txt > > > I'd think it ought to be possible to have a really simple transit-only RB= R > that doesn't bother looking beyond the TRILL header...so doesn't care wha= t > VLAN or FGL it is...R won't do any filtering, but filtering is only an > optimization, except at the edges, where it is mandatory. > > > > Does it ought to have another type of transit RB which needs to do filter= ing > but can=E2=80=99t do it based on the full FGL due to some reasons (e.g. t= he lack of > enough hardware memory capability)? For example, it could do a > coarse-grained filtering based on partial bits in the FGL. In other words= , > The transit RB could have a flexibility to determine how many bits (0~24)= in > the FGL would be used for filtering. > > > > Anyway...back to two tags vs a single 24-bit tag...we really have to pick > one and go with it. Either one works, and although one tag might be a bi= t > more elegant, I've informally asked some implementers and some of them sa= id > they don't care, and others say they prefer two 12-bit pieces in two tags= , > so I vote that we stick with that. > > > > Since there is no need to worry about the backwards compatibility anymore= , > could you please explain why others prefer two 12-bit tags to a single > 24-bit tag? Already existing silicon. 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 > Best regards, > > Xiaohu > > > > As for the spec...yeah, as people pointed out, there are places where the > spec could be clarified, and we should do that. > > > > Of the combinations possible, which should be described in the spec? > > > > I think FGL+VL, and VL definitely. And the base spec already describes > VL-only. > > > > We might also want to mention neither FGL nor VL (transit only, no > filtering). > > > > We might also want to mention eventually dropping support for VL, and > allowing a mixture of FGL+VL and FGL-only. But for simplicity, I think w= e > should not describe that variant at that point, and only describe (in thi= s > document), FGL+VL and its interoperability with VL-only. > > > > Does anyone have any strong opinions? > > > > Radia > > On Wed, Nov 21, 2012 at 11:24 AM, Rajeev Manur wrot= e: > > > My understanding is we have only 2 modes, VL-mode and FGL-mode (superset > mode supporting both VL and FGL). I feel it would be useful to add more t= ext > to clarify the processing/compliance requirements for ingress / transit / > egress RB contexts separately for each of these two modes. This will help > implementations they may want to support transit only functions and still= be > compliant. > > For example, it is not clear to me when an RB wants to operate as > transit-only RB, VL/FGL capability can be configured per port or all port= s > on that RB must be configured to operate in the same mode? I am assuming = it > is the latter. > > Thanks! > --Rajeev > > > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of > Olen Stokes > Sent: Tuesday, November 20, 2012 9:08 PM > To: Thomas Narten; Donald Eastlake > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > Trying NOT to add anything more in line=C5=A0 > > It seems that multiple different people have multiple different migration > scenarios in mind. I think that several of us could benefit from > something that better spells out what scenario(s) the authors have in > mind. Donald's scenarios described in his response to my previous email > would have helped the draft. We can then discuss if there are others tha= t > need to be considered. > > We seem to be discussing three types of nodes: > > 1) VL-only capable RBridges > 2) VL and FGL capable RBridges > 3) FGL-only capable Rbridges > > For the third (FGL-only) type, remember that at some point people will > want to drop support for the VL RBridges. There may also be silicon out > that that can operate in VL mode or in FGL mode but not both at the same > time. Note, I am not a silicon person. > > If these three types are intended, a more clear statement of the > requirements for each time might be of benefit. The requirements should > describe ingress, egress, transit, and transit plus egress RBridges. If > one of these types is not intended, then a clear statement that it is not > supported may be in order. It could then be debated. > > I believe that Donald has described that the second type above (VL and FG= L > capable RBridge) is a requirement. To me, the best case for that > requirement is in a multi-topolgy environment. Stating that use case > would have made the document and that requirement more clear to me. I > leave it to others to figure out how to reference something that might be > defined in another draft (at some point in the future). Note that to me, > a "VL and FGL capable" node acting only as a VL node is just a VL RBridge= . > > Cheers, > Olen > > > On 11/20/12 7:35 AM, "Thomas Narten" wrote: > >>Hi Donald. >> >>Donald Eastlake writes: >> >> >>> > My understanding (from reading the draft earlier today) was that an R= B >>> > either operates in FGL mode or VL mode. It doesn't mix and >>> > match. I.e., you don't have an RB with some ports understanding FGL >>> > and others VL. (To do that, you'd an RB would have to convert betwee= n >>> > the the two formats which could result in loss of information...) >> >>> So what exactly did you think text like the following meant: >>> "An FGL RBridge MAY be configured, on one or more ports, to ingress >>> native frames as FGL. Any ports not so configured that accepts a >>> native frame perform the previously specified VL ingress processing >>> on native frames [RFC6325]." >> >>Personally, I thought the wording was somewhat odd, and made a note to >>figure out what the real intention was. :-) Also, "MAY" means it's not >>part of the spec, but not being disallowed either. That is not the >>same thing as saying it is something that implementations would want >>or need to do. >> >>> I also can't see why you would think that the ability to ingress, >>> transit, and egress both VL and FGL frames implies having to "convert" >>> between those formats. The whole idea of data labeling is >>> separation/isolation. Why would you convert between them anymore than >>> you would convert between a random pair of different VLANs? >> >>No disagreement. My assumption had been that if you have an RB that >>understands both VL and FGL, that such a mode would only be useful if >>one was converting from one format to the other, or if one fell back >>from from FGL to VL mode if it didn't make sense to operate in FGL >>mode. But I wasn't 100% sure what the draft's intention was... >> >>But on rereading parts of the draft, it seems that a single TRILL >>campus can actually consist of a mixture of both VL and FGL-capable >>RBs. And that campus is effectively partitioned, where some of the >>links/RBs operate in FGL mode (only) and the rest operate in VL mode >>(only) with the data planes of the "two networks" operating likes >>ships in the night. >> >>You can even have a single RB supporting both modes (on some >>links). E.g., you could have RB1 with links L1 and L2 operating in VL >>mode and links L3 and L4 operating in FGL mode. Right? (This is >>because it is the individual links that operate in a given mode, not >>the RB per se.) >> >>If so, let me push back on this model. The document says: >> >> The usual DRB election operates on a link with mixed FLG and VL >> ports. If an FGL RBridge port is DRB, it MUST handle all native >> traffic or appoint only other FGL ports as forwarder for one or more >> VLANs, so that all end stations will get service to the FGL campus. >> If a VL RBridge port is DRB, it will not understand that FGL RBridge >> ports are different. To the extent that a VL DRB handles native >> frames or appoints other VL ports on a link to handle native frames >> for one or more VLANs, the end stations sending and receiving those >> native frames will be isolated from the FGL campus. To the extent >> that a VL DRB happens to appoint an FGL port as Appointed Forwarder >> for one or more VLANs, the end stations sending and receiving native >> frames in those VLANs will get service to the FGL campus. This >> somewhat odd corner case behavior is considered acceptable because it >> is assumed that VL TRILL switches in an FGL campus are infrequent >> misconfigurations. >> >>I would not just call this a "corner case" that can be ignored. What >>it seems to mean is that you can deply TRILL, but get disconnected >>VLAN islands. That is, C-VID X at one edge is processed by FGL RBs >>(say RB1), but elsewhere on the network, only VL RBs connect to C-VID >>X (say via RB2). Because the VL and FGL networks are isolated from >>each other, the result is that devices in VLAN X connected to RB1 will >>be unable to communicated with devices in VLAN X connected to >>RB2. Right? >> >>I wouldn't consider that a "corner case" to be ignored. I'd consider >>that an operational nightmare that can't be allowed to happen (by >>default). >> >>> Anyway, the intent is that ports operate in either VL or FGL mode. And >>> all the ports of a VL RBridge are VL ports. But an FGL RBridge is >>> required to support an arbitrary mix of VL and FGL ports. VL and FGL >>> frames are ships in the night just like VL frames for different VLANs >>> for FGL frames for different FGLs. >> >>Why must FGL capable devices be required to support VL? I understand >>that it is probably a good thing to do (so you can support either >>mode, depending on what other RBs are capable of). But does the FGL >>*protocol* require this in order to work correctly? Does proper >>operation of FGL require being able to support VL as well? Or is the >>real intent just to allow a graceful way to "fall back" into VL mode >>to intereperate with non FGL-aware RBs? (I think that is a fine thing >>to require, btw.) >> >>> > And the way to look at VL mode, is that it is the fallback for the >>> > case where not all of the RBs in the compus are FGL capable. >> >>> The word "mode" does not occur anywhere in the body of the draft. FGL >>> RBridges are supersets. FGL RBridges can handle VL frames fine. It is >>> just that VL RBridges can't handle FGL frames and it is very hard to >>> guarantee that an FGL frame will never be routed to a VL RBridge >>> without either multi-topology (which is not yet fully specified for >>> TRILL) or stopping all data flow between VL and FGL RBridges (whcih is >>> what this draft does). >> >>IMO, this spec should not say anything about multi-topology (that is >>future work) and should ensure that a standards compliant >>implementation cannot and will not forward FGL packets to VL-only >>RBs. Anything else will likely lead to operational problems... >> >>> > I.e., what is supposed o happen in a campus where some RBs say they d= o >>> > FGL and others do not? Is the intention that one TRILL campus gets >>> > formed with all nodes falling back to VL mode? >> >>> As stated in the draft, the assumption in that case is that you wanted >>> a completely FGL campus and whatever VL RBridges are present are >>> isolated misconfigurations. >> >>I think this is an unreasonable assumption. You will get deployments >>that have both. Accidents can happen, etc. I think we'd be better off >>with very clear ways for the operator to specify what they want to >>have happen in a mixed mode. We can have a default mode, but the >>operator needs to be able to override the defaults. >> >>I.e., if only one (or a small number of) switches supports FGL, you >>want the default mode to be to have the entire TRILL campus to try to >>use FGL? I'm not sure. >> >>> So the provisions are that all the RBridges peer for control but VL >>> and FGL RBridges do not peer for data. You don't want the attachment >>> of one RBridge misconfigured to be a VL RBridge to kill your whole >>> FGL campus. You can't "fall back" a port configured for FGL without >>> violating security policy. >> >>I don't understand the "security policy" reference here. >> >>> Maybe clarifying text should be added and the "FGL RBridges" should be >>> referred to as "FGLVL RBridges". >> >>No. The issue isn't terminology. The text needs to be clearer what the >>intention is. For me, it's sometimes hard to pull out the overriding >>intention from the specific rules that are layed out in the document. >> >>Thomas >> >>_______________________________________________ >>trill mailing list >>trill@ietf.org >>https://www.ietf.org/mailman/listinfo/trill > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > From xuxiaohu@huawei.com Wed Nov 21 19:07:07 2012 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 BCC3B21E8053 for ; Wed, 21 Nov 2012 19:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.453 X-Spam-Level: X-Spam-Status: No, score=-4.453 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Jig14eEP--y for ; Wed, 21 Nov 2012 19:07:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 17A9521E8048 for ; Wed, 21 Nov 2012 19:07:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALU23213; Thu, 22 Nov 2012 03:07:02 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Nov 2012 03:06:31 +0000 Received: from SZXEML445-HUB.china.huawei.com (10.82.67.183) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Nov 2012 03:07:01 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.161]) by szxeml445-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.01.0323.003; Thu, 22 Nov 2012 11:06:55 +0800 From: Xuxiaohu To: Radia Perlman , Rajeev Manur Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: AQHNxr0FxDvtfuGaikaziXngrO0R1pfxbHKAgAAdEYCAAJntgIABFTiAgADvhgCAAEQTgIAApzJAgAAb1pA= Date: Thu, 22 Nov 2012 03:06:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07572A1D@szxeml525-mbx.china.huawei.com> References: <201211201235.qAKCZPrh015017@cichlid.raleigh.ibm.com> <1E714095C88C9D408749A723A59CF6ED1BE017A6@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07572A1Dszxeml525mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , Donald Eastlake , "trill@ietf.org" Subject: [trill] =?utf-8?b?562U5aSNOiAgV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRm?= =?utf-8?q?-trill-fine-labeling-02=2Etxt?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 03:07:07 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07572A1Dszxeml525mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCuWPkeS7tuS6ujogWHV4aWFvaHUNCuWPkemAgeaXtumXtDogMjAxMuW5tDEx5pyIMjLml6Ug MTA6MTANCuaUtuS7tuS6ujogJ1JhZGlhIFBlcmxtYW4nOyBSYWplZXYgTWFudXINCuaKhOmAgTog VGhvbWFzIE5hcnRlbjsgRG9uYWxkIEVhc3RsYWtlOyB0cmlsbEBpZXRmLm9yZw0K5Li76aKYOiBy ZTogW3RyaWxsXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtdHJpbGwtZmluZS1sYWJlbGluZy0w Mi50eHQNCg0KDQoNCuWPkeS7tuS6ujogdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRy aWxsLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBSYWRpYSBQZXJsbWFuDQrlj5HpgIHml7bpl7Q6 IDIwMTLlubQxMeaciDIy5pelIDc6MjkNCuaUtuS7tuS6ujogUmFqZWV2IE1hbnVyDQrmioTpgIE6 IFRob21hcyBOYXJ0ZW47IERvbmFsZCBFYXN0bGFrZTsgdHJpbGxAaWV0Zi5vcmcNCuS4u+mimDog UmU6IFt0cmlsbF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRyaWxsLWZpbmUtbGFiZWxpbmct MDIudHh0DQoNCkknZCB0aGluayBpdCBvdWdodCB0byBiZSBwb3NzaWJsZSB0byBoYXZlIGEgcmVh bGx5IHNpbXBsZSB0cmFuc2l0LW9ubHkgUkIgUiB0aGF0IGRvZXNuJ3QgYm90aGVyIGxvb2tpbmcg YmV5b25kIHRoZSBUUklMTCBoZWFkZXIuLi5zbyBkb2Vzbid0IGNhcmUgd2hhdCBWTEFOIG9yIEZH TCBpdCBpcy4uLlIgd29uJ3QgZG8gYW55IGZpbHRlcmluZywgYnV0IGZpbHRlcmluZyBpcyBvbmx5 IGFuIG9wdGltaXphdGlvbiwgZXhjZXB0IGF0IHRoZSBlZGdlcywgd2hlcmUgaXQgaXMgbWFuZGF0 b3J5Lg0KDQpEb2VzIGl0IG91Z2h0IHRvIGhhdmUgYW5vdGhlciB0eXBlIG9mIHRyYW5zaXQgUkIg d2hpY2ggbmVlZHMgdG8gZG8gZmlsdGVyaW5nIGJ1dCBjYW7igJl0IGRvIGl0IGJhc2VkIG9uIHRo ZSBmdWxsIEZHTCBkdWUgdG8gc29tZSByZWFzb25zIChlLmcuIHRoZSBsYWNrIG9mIGVub3VnaCBo YXJkd2FyZSBtZW1vcnkgY2FwYWJpbGl0eSk/IEZvciBleGFtcGxlLCBpdCBjb3VsZCBkbyBhIGNv YXJzZS1ncmFpbmVkIGZpbHRlcmluZyBiYXNlZCBvbiBwYXJ0aWFsIGJpdHMgaW4gdGhlIEZHTC4g SW4gb3RoZXIgd29yZHMsIFRoZSB0cmFuc2l0IFJCIGNvdWxkIGhhdmUgYSBmbGV4aWJpbGl0eSB0 byBkZXRlcm1pbmUgaG93IG1hbnkgYml0cyAoMH4yNCkgaW4gdGhlIEZHTCB3b3VsZCBiZSB1c2Vk IGZvciBmaWx0ZXJpbmcuDQoNCkFueXdheS4uLmJhY2sgdG8gdHdvIHRhZ3MgdnMgYSBzaW5nbGUg MjQtYml0IHRhZy4uLndlIHJlYWxseSBoYXZlIHRvIHBpY2sgb25lIGFuZCBnbyB3aXRoIGl0LiAg RWl0aGVyIG9uZSB3b3JrcywgYW5kIGFsdGhvdWdoIG9uZSB0YWcgbWlnaHQgYmUgYSBiaXQgbW9y ZSBlbGVnYW50LCBJJ3ZlIGluZm9ybWFsbHkgYXNrZWQgc29tZSBpbXBsZW1lbnRlcnMgYW5kIHNv bWUgb2YgdGhlbSBzYWlkIHRoZXkgZG9uJ3QgY2FyZSwgYW5kIG90aGVycyBzYXkgdGhleSBwcmVm ZXIgdHdvIDEyLWJpdCBwaWVjZXMgaW4gdHdvIHRhZ3MsIHNvIEkgdm90ZSB0aGF0IHdlIHN0aWNr IHdpdGggdGhhdC4NCg0KU2luY2UgdGhlcmUgaXMgbm8gbmVlZCB0byB3b3JyeSBhYm91dCB0aGUg YmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYW55bW9yZSwgY291bGQgeW91IHBsZWFzZSBleHBsYWlu IHdoeSBvdGhlcnMgcHJlZmVyIHR3byAxMi1iaXQgdGFncyB0byBhIHNpbmdsZSAyNC1iaXQgdGFn Pw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KQXMgZm9yIHRoZSBzcGVjLi4ueWVhaCwgYXMg cGVvcGxlIHBvaW50ZWQgb3V0LCB0aGVyZSBhcmUgcGxhY2VzIHdoZXJlIHRoZSBzcGVjIGNvdWxk IGJlIGNsYXJpZmllZCwgYW5kIHdlIHNob3VsZCBkbyB0aGF0Lg0KDQpPZiB0aGUgY29tYmluYXRp b25zIHBvc3NpYmxlLCB3aGljaCBzaG91bGQgYmUgZGVzY3JpYmVkIGluIHRoZSBzcGVjPw0KDQpJ IHRoaW5rIEZHTCtWTCwgYW5kIFZMIGRlZmluaXRlbHkuICBBbmQgdGhlIGJhc2Ugc3BlYyBhbHJl YWR5IGRlc2NyaWJlcyBWTC1vbmx5Lg0KDQpXZSBtaWdodCBhbHNvIHdhbnQgdG8gbWVudGlvbiBu ZWl0aGVyIEZHTCBub3IgVkwgKHRyYW5zaXQgb25seSwgbm8gZmlsdGVyaW5nKS4NCg0KV2UgbWln aHQgYWxzbyB3YW50IHRvIG1lbnRpb24gZXZlbnR1YWxseSBkcm9wcGluZyBzdXBwb3J0IGZvciBW TCwgYW5kIGFsbG93aW5nIGEgbWl4dHVyZSBvZiBGR0wrVkwgYW5kIEZHTC1vbmx5LiAgQnV0IGZv ciBzaW1wbGljaXR5LCBJIHRoaW5rIHdlIHNob3VsZCBub3QgZGVzY3JpYmUgdGhhdCB2YXJpYW50 IGF0IHRoYXQgcG9pbnQsIGFuZCBvbmx5IGRlc2NyaWJlIChpbiB0aGlzIGRvY3VtZW50KSwgRkdM K1ZMIGFuZCBpdHMgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIFZMLW9ubHkuDQoNCkRvZXMgYW55b25l IGhhdmUgYW55IHN0cm9uZyBvcGluaW9ucz8NCg0KUmFkaWENCk9uIFdlZCwgTm92IDIxLCAyMDEy IGF0IDExOjI0IEFNLCBSYWplZXYgTWFudXIgPHJtYW51ckBicm9hZGNvbS5jb208bWFpbHRvOnJt YW51ckBicm9hZGNvbS5jb20+PiB3cm90ZToNCg0KTXkgdW5kZXJzdGFuZGluZyBpcyB3ZSBoYXZl IG9ubHkgMiBtb2RlcywgVkwtbW9kZSBhbmQgRkdMLW1vZGUgKHN1cGVyc2V0IG1vZGUgc3VwcG9y dGluZyBib3RoIFZMIGFuZCBGR0wpLiBJIGZlZWwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGFkZCBt b3JlIHRleHQgdG8gY2xhcmlmeSB0aGUgcHJvY2Vzc2luZy9jb21wbGlhbmNlIHJlcXVpcmVtZW50 cyBmb3IgaW5ncmVzcyAvIHRyYW5zaXQgLyBlZ3Jlc3MgUkIgY29udGV4dHMgc2VwYXJhdGVseSBm b3IgZWFjaCBvZiB0aGVzZSB0d28gbW9kZXMuIFRoaXMgd2lsbCBoZWxwIGltcGxlbWVudGF0aW9u cyB0aGV5IG1heSB3YW50IHRvIHN1cHBvcnQgdHJhbnNpdCBvbmx5IGZ1bmN0aW9ucyBhbmQgc3Rp bGwgYmUgY29tcGxpYW50Lg0KDQpGb3IgZXhhbXBsZSwgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdo ZW4gYW4gUkIgd2FudHMgdG8gb3BlcmF0ZSBhcyB0cmFuc2l0LW9ubHkgUkIsIFZML0ZHTCBjYXBh YmlsaXR5IGNhbiBiZSBjb25maWd1cmVkIHBlciBwb3J0IG9yIGFsbCBwb3J0cyBvbiB0aGF0IFJC IG11c3QgYmUgY29uZmlndXJlZCB0byBvcGVyYXRlIGluIHRoZSBzYW1lIG1vZGU/IEkgYW0gYXNz dW1pbmcgaXQgaXMgdGhlIGxhdHRlci4NCg0KVGhhbmtzIQ0KLS1SYWplZXYNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHJpbGwtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 dHJpbGwtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE9sZW4gU3Rva2VzDQpT ZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyMCwgMjAxMiA5OjA4IFBNDQpUbzogVGhvbWFzIE5hcnRl bjsgRG9uYWxkIEVhc3RsYWtlDQpDYzogdHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFt0cmlsbF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRyaWxs LWZpbmUtbGFiZWxpbmctMDIudHh0DQpUcnlpbmcgTk9UIHRvIGFkZCBhbnl0aGluZyBtb3JlIGlu IGxpbmXFoA0KDQpJdCBzZWVtcyB0aGF0IG11bHRpcGxlIGRpZmZlcmVudCBwZW9wbGUgaGF2ZSBt dWx0aXBsZSBkaWZmZXJlbnQgbWlncmF0aW9uDQpzY2VuYXJpb3MgaW4gbWluZC4gIEkgdGhpbmsg dGhhdCBzZXZlcmFsIG9mIHVzIGNvdWxkIGJlbmVmaXQgZnJvbQ0Kc29tZXRoaW5nIHRoYXQgYmV0 dGVyIHNwZWxscyBvdXQgd2hhdCBzY2VuYXJpbyhzKSB0aGUgYXV0aG9ycyBoYXZlIGluDQptaW5k LiAgRG9uYWxkJ3Mgc2NlbmFyaW9zIGRlc2NyaWJlZCBpbiBoaXMgcmVzcG9uc2UgdG8gbXkgcHJl dmlvdXMgZW1haWwNCndvdWxkIGhhdmUgaGVscGVkIHRoZSBkcmFmdC4gIFdlIGNhbiB0aGVuIGRp c2N1c3MgaWYgdGhlcmUgYXJlIG90aGVycyB0aGF0DQpuZWVkIHRvIGJlIGNvbnNpZGVyZWQuDQoN CldlIHNlZW0gdG8gYmUgZGlzY3Vzc2luZyB0aHJlZSB0eXBlcyBvZiBub2RlczoNCg0KMSkgVkwt b25seSBjYXBhYmxlIFJCcmlkZ2VzDQoyKSBWTCBhbmQgRkdMIGNhcGFibGUgUkJyaWRnZXMNCjMp IEZHTC1vbmx5IGNhcGFibGUgUmJyaWRnZXMNCg0KRm9yIHRoZSB0aGlyZCAoRkdMLW9ubHkpIHR5 cGUsIHJlbWVtYmVyIHRoYXQgYXQgc29tZSBwb2ludCBwZW9wbGUgd2lsbA0Kd2FudCB0byBkcm9w IHN1cHBvcnQgZm9yIHRoZSBWTCBSQnJpZGdlcy4gIFRoZXJlIG1heSBhbHNvIGJlIHNpbGljb24g b3V0DQp0aGF0IHRoYXQgY2FuIG9wZXJhdGUgaW4gVkwgbW9kZSBvciBpbiBGR0wgbW9kZSBidXQg bm90IGJvdGggYXQgdGhlIHNhbWUNCnRpbWUuICBOb3RlLCBJIGFtIG5vdCBhIHNpbGljb24gcGVy c29uLg0KDQpJZiB0aGVzZSB0aHJlZSB0eXBlcyBhcmUgaW50ZW5kZWQsIGEgbW9yZSBjbGVhciBz dGF0ZW1lbnQgb2YgdGhlDQpyZXF1aXJlbWVudHMgZm9yIGVhY2ggdGltZSBtaWdodCBiZSBvZiBi ZW5lZml0LiAgVGhlIHJlcXVpcmVtZW50cyBzaG91bGQNCmRlc2NyaWJlIGluZ3Jlc3MsIGVncmVz cywgdHJhbnNpdCwgYW5kIHRyYW5zaXQgcGx1cyBlZ3Jlc3MgUkJyaWRnZXMuIElmDQpvbmUgb2Yg dGhlc2UgdHlwZXMgaXMgbm90IGludGVuZGVkLCB0aGVuIGEgY2xlYXIgc3RhdGVtZW50IHRoYXQg aXQgaXMgbm90DQpzdXBwb3J0ZWQgbWF5IGJlIGluIG9yZGVyLiAgSXQgY291bGQgdGhlbiBiZSBk ZWJhdGVkLg0KDQpJIGJlbGlldmUgdGhhdCBEb25hbGQgaGFzIGRlc2NyaWJlZCB0aGF0IHRoZSBz ZWNvbmQgdHlwZSBhYm92ZSAoVkwgYW5kIEZHTA0KY2FwYWJsZSBSQnJpZGdlKSBpcyBhIHJlcXVp cmVtZW50LiAgVG8gbWUsIHRoZSBiZXN0IGNhc2UgZm9yIHRoYXQNCnJlcXVpcmVtZW50IGlzIGlu IGEgbXVsdGktdG9wb2xneSBlbnZpcm9ubWVudC4gIFN0YXRpbmcgdGhhdCB1c2UgY2FzZQ0Kd291 bGQgaGF2ZSBtYWRlIHRoZSBkb2N1bWVudCBhbmQgdGhhdCByZXF1aXJlbWVudCBtb3JlIGNsZWFy IHRvIG1lLiAgSQ0KbGVhdmUgaXQgdG8gb3RoZXJzIHRvIGZpZ3VyZSBvdXQgaG93IHRvIHJlZmVy ZW5jZSBzb21ldGhpbmcgdGhhdCBtaWdodCBiZQ0KZGVmaW5lZCBpbiBhbm90aGVyIGRyYWZ0IChh dCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUpLiAgTm90ZSB0aGF0IHRvIG1lLA0KYSAiVkwgYW5k IEZHTCBjYXBhYmxlIiBub2RlIGFjdGluZyBvbmx5IGFzIGEgVkwgbm9kZSBpcyBqdXN0IGEgVkwg UkJyaWRnZS4NCg0KQ2hlZXJzLA0KT2xlbg0KDQoNCk9uIDExLzIwLzEyIDc6MzUgQU0sICJUaG9t YXMgTmFydGVuIiA8bmFydGVuQHVzLmlibS5jb208bWFpbHRvOm5hcnRlbkB1cy5pYm0uY29tPj4g d3JvdGU6DQoNCj5IaSBEb25hbGQuDQo+DQo+RG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21haWwu Y29tPG1haWx0bzpkM2UzZTNAZ21haWwuY29tPj4gd3JpdGVzOg0KPg0KPg0KPj4gPiBNeSB1bmRl cnN0YW5kaW5nIChmcm9tIHJlYWRpbmcgdGhlIGRyYWZ0IGVhcmxpZXIgdG9kYXkpIHdhcyB0aGF0 IGFuIFJCDQo+PiA+IGVpdGhlciBvcGVyYXRlcyBpbiBGR0wgbW9kZSBvciBWTCBtb2RlLiBJdCBk b2Vzbid0IG1peCBhbmQNCj4+ID4gbWF0Y2guIEkuZS4sIHlvdSBkb24ndCBoYXZlIGFuIFJCIHdp dGggc29tZSBwb3J0cyB1bmRlcnN0YW5kaW5nIEZHTA0KPj4gPiBhbmQgb3RoZXJzIFZMLiAgKFRv IGRvIHRoYXQsIHlvdSdkIGFuIFJCIHdvdWxkIGhhdmUgdG8gY29udmVydCBiZXR3ZWVuDQo+PiA+ IHRoZSB0aGUgdHdvIGZvcm1hdHMgd2hpY2ggY291bGQgcmVzdWx0IGluIGxvc3Mgb2YgaW5mb3Jt YXRpb24uLi4pDQo+DQo+PiBTbyB3aGF0IGV4YWN0bHkgZGlkIHlvdSB0aGluayB0ZXh0IGxpa2Ug dGhlIGZvbGxvd2luZyBtZWFudDoNCj4+ICAgICJBbiBGR0wgUkJyaWRnZSBNQVkgYmUgY29uZmln dXJlZCwgb24gb25lIG9yIG1vcmUgcG9ydHMsIHRvIGluZ3Jlc3MNCj4+ICAgIG5hdGl2ZSBmcmFt ZXMgYXMgRkdMLiBBbnkgcG9ydHMgbm90IHNvIGNvbmZpZ3VyZWQgdGhhdCBhY2NlcHRzIGENCj4+ ICAgIG5hdGl2ZSBmcmFtZSBwZXJmb3JtIHRoZSBwcmV2aW91c2x5IHNwZWNpZmllZCBWTCBpbmdy ZXNzIHByb2Nlc3NpbmcNCj4+ICAgIG9uIG5hdGl2ZSBmcmFtZXMgW1JGQzYzMjVdLiINCj4NCj5Q ZXJzb25hbGx5LCBJIHRob3VnaHQgdGhlIHdvcmRpbmcgd2FzIHNvbWV3aGF0IG9kZCwgYW5kIG1h ZGUgYSBub3RlIHRvDQo+ZmlndXJlIG91dCB3aGF0IHRoZSByZWFsIGludGVudGlvbiB3YXMuIDot KSBBbHNvLCAiTUFZIiBtZWFucyBpdCdzIG5vdA0KPnBhcnQgb2YgdGhlIHNwZWMsIGJ1dCBub3Qg YmVpbmcgZGlzYWxsb3dlZCBlaXRoZXIuIFRoYXQgaXMgbm90IHRoZQ0KPnNhbWUgdGhpbmcgYXMg c2F5aW5nIGl0IGlzIHNvbWV0aGluZyB0aGF0IGltcGxlbWVudGF0aW9ucyB3b3VsZCB3YW50DQo+ b3IgbmVlZCB0byBkby4NCj4NCj4+IEkgYWxzbyBjYW4ndCBzZWUgd2h5IHlvdSB3b3VsZCB0aGlu ayB0aGF0IHRoZSBhYmlsaXR5IHRvIGluZ3Jlc3MsDQo+PiB0cmFuc2l0LCBhbmQgZWdyZXNzIGJv dGggVkwgYW5kIEZHTCBmcmFtZXMgaW1wbGllcyBoYXZpbmcgdG8gImNvbnZlcnQiDQo+PiBiZXR3 ZWVuIHRob3NlIGZvcm1hdHMuIFRoZSB3aG9sZSBpZGVhIG9mIGRhdGEgbGFiZWxpbmcgaXMNCj4+ IHNlcGFyYXRpb24vaXNvbGF0aW9uLiBXaHkgd291bGQgeW91IGNvbnZlcnQgYmV0d2VlbiB0aGVt IGFueW1vcmUgdGhhbg0KPj4geW91IHdvdWxkIGNvbnZlcnQgYmV0d2VlbiBhIHJhbmRvbSBwYWly IG9mIGRpZmZlcmVudCBWTEFOcz8NCj4NCj5ObyBkaXNhZ3JlZW1lbnQuIE15IGFzc3VtcHRpb24g aGFkIGJlZW4gdGhhdCBpZiB5b3UgaGF2ZSBhbiBSQiB0aGF0DQo+dW5kZXJzdGFuZHMgYm90aCBW TCBhbmQgRkdMLCB0aGF0IHN1Y2ggYSBtb2RlIHdvdWxkIG9ubHkgYmUgdXNlZnVsIGlmDQo+b25l IHdhcyBjb252ZXJ0aW5nIGZyb20gb25lIGZvcm1hdCB0byB0aGUgb3RoZXIsIG9yIGlmIG9uZSBm ZWxsIGJhY2sNCj5mcm9tIGZyb20gRkdMIHRvIFZMIG1vZGUgaWYgaXQgZGlkbid0IG1ha2Ugc2Vu c2UgdG8gb3BlcmF0ZSBpbiBGR0wNCj5tb2RlLiBCdXQgSSB3YXNuJ3QgMTAwJSBzdXJlIHdoYXQg dGhlIGRyYWZ0J3MgaW50ZW50aW9uIHdhcy4uLg0KPg0KPkJ1dCBvbiByZXJlYWRpbmcgcGFydHMg b2YgdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGEgc2luZ2xlIFRSSUxMDQo+Y2FtcHVzIGNhbiBh Y3R1YWxseSBjb25zaXN0IG9mIGEgbWl4dHVyZSBvZiBib3RoIFZMIGFuZCBGR0wtY2FwYWJsZQ0K PlJCcy4gQW5kIHRoYXQgY2FtcHVzIGlzIGVmZmVjdGl2ZWx5IHBhcnRpdGlvbmVkLCB3aGVyZSBz b21lIG9mIHRoZQ0KPmxpbmtzL1JCcyBvcGVyYXRlIGluIEZHTCBtb2RlIChvbmx5KSBhbmQgdGhl IHJlc3Qgb3BlcmF0ZSBpbiBWTCBtb2RlDQo+KG9ubHkpIHdpdGggdGhlIGRhdGEgcGxhbmVzIG9m IHRoZSAidHdvIG5ldHdvcmtzIiBvcGVyYXRpbmcgbGlrZXMNCj5zaGlwcyBpbiB0aGUgbmlnaHQu DQo+DQo+WW91IGNhbiBldmVuIGhhdmUgYSBzaW5nbGUgUkIgc3VwcG9ydGluZyBib3RoIG1vZGVz IChvbiBzb21lDQo+bGlua3MpLiBFLmcuLCB5b3UgY291bGQgaGF2ZSBSQjEgd2l0aCBsaW5rcyBM MSBhbmQgTDIgb3BlcmF0aW5nIGluIFZMDQo+bW9kZSBhbmQgbGlua3MgTDMgYW5kIEw0IG9wZXJh dGluZyBpbiBGR0wgbW9kZS4gUmlnaHQ/IChUaGlzIGlzDQo+YmVjYXVzZSBpdCBpcyB0aGUgaW5k aXZpZHVhbCBsaW5rcyB0aGF0IG9wZXJhdGUgaW4gYSBnaXZlbiBtb2RlLCBub3QNCj50aGUgUkIg cGVyIHNlLikNCj4NCj5JZiBzbywgbGV0IG1lIHB1c2ggYmFjayBvbiB0aGlzIG1vZGVsLiAgVGhl IGRvY3VtZW50IHNheXM6DQo+DQo+ICAgVGhlIHVzdWFsIERSQiBlbGVjdGlvbiBvcGVyYXRlcyBv biBhIGxpbmsgd2l0aCBtaXhlZCBGTEcgYW5kIFZMDQo+ICAgcG9ydHMuIElmIGFuIEZHTCBSQnJp ZGdlIHBvcnQgaXMgRFJCLCBpdCBNVVNUIGhhbmRsZSBhbGwgbmF0aXZlDQo+ICAgdHJhZmZpYyBv ciBhcHBvaW50IG9ubHkgb3RoZXIgRkdMIHBvcnRzIGFzIGZvcndhcmRlciBmb3Igb25lIG9yIG1v cmUNCj4gICBWTEFOcywgc28gdGhhdCBhbGwgZW5kIHN0YXRpb25zIHdpbGwgZ2V0IHNlcnZpY2Ug dG8gdGhlIEZHTCBjYW1wdXMuDQo+ICAgSWYgYSBWTCBSQnJpZGdlIHBvcnQgaXMgRFJCLCBpdCB3 aWxsIG5vdCB1bmRlcnN0YW5kIHRoYXQgRkdMIFJCcmlkZ2UNCj4gICBwb3J0cyBhcmUgZGlmZmVy ZW50LiBUbyB0aGUgZXh0ZW50IHRoYXQgYSBWTCBEUkIgaGFuZGxlcyBuYXRpdmUNCj4gICBmcmFt ZXMgb3IgYXBwb2ludHMgb3RoZXIgVkwgcG9ydHMgb24gYSBsaW5rIHRvIGhhbmRsZSBuYXRpdmUg ZnJhbWVzDQo+ICAgZm9yIG9uZSBvciBtb3JlIFZMQU5zLCB0aGUgZW5kIHN0YXRpb25zIHNlbmRp bmcgYW5kIHJlY2VpdmluZyB0aG9zZQ0KPiAgIG5hdGl2ZSBmcmFtZXMgd2lsbCBiZSBpc29sYXRl ZCBmcm9tIHRoZSBGR0wgY2FtcHVzLiBUbyB0aGUgZXh0ZW50DQo+ICAgdGhhdCBhIFZMIERSQiBo YXBwZW5zIHRvIGFwcG9pbnQgYW4gRkdMIHBvcnQgYXMgQXBwb2ludGVkIEZvcndhcmRlcg0KPiAg IGZvciBvbmUgb3IgbW9yZSBWTEFOcywgdGhlIGVuZCBzdGF0aW9ucyBzZW5kaW5nIGFuZCByZWNl aXZpbmcgbmF0aXZlDQo+ICAgZnJhbWVzIGluIHRob3NlIFZMQU5zIHdpbGwgZ2V0IHNlcnZpY2Ug dG8gdGhlIEZHTCBjYW1wdXMuIFRoaXMNCj4gICBzb21ld2hhdCBvZGQgY29ybmVyIGNhc2UgYmVo YXZpb3IgaXMgY29uc2lkZXJlZCBhY2NlcHRhYmxlIGJlY2F1c2UgaXQNCj4gICBpcyBhc3N1bWVk IHRoYXQgVkwgVFJJTEwgc3dpdGNoZXMgaW4gYW4gRkdMIGNhbXB1cyBhcmUgaW5mcmVxdWVudA0K PiAgIG1pc2NvbmZpZ3VyYXRpb25zLg0KPg0KPkkgd291bGQgbm90IGp1c3QgY2FsbCB0aGlzIGEg ImNvcm5lciBjYXNlIiB0aGF0IGNhbiBiZSBpZ25vcmVkLiBXaGF0DQo+aXQgc2VlbXMgdG8gbWVh biBpcyB0aGF0IHlvdSBjYW4gZGVwbHkgVFJJTEwsIGJ1dCBnZXQgZGlzY29ubmVjdGVkDQo+VkxB TiBpc2xhbmRzLiBUaGF0IGlzLCBDLVZJRCBYIGF0IG9uZSBlZGdlIGlzIHByb2Nlc3NlZCBieSBG R0wgUkJzDQo+KHNheSBSQjEpLCBidXQgZWxzZXdoZXJlIG9uIHRoZSBuZXR3b3JrLCBvbmx5IFZM IFJCcyBjb25uZWN0IHRvIEMtVklEDQo+WCAoc2F5IHZpYSBSQjIpLiBCZWNhdXNlIHRoZSBWTCBh bmQgRkdMIG5ldHdvcmtzIGFyZSBpc29sYXRlZCBmcm9tDQo+ZWFjaCBvdGhlciwgdGhlIHJlc3Vs dCBpcyB0aGF0IGRldmljZXMgaW4gVkxBTiBYIGNvbm5lY3RlZCB0byBSQjEgd2lsbA0KPmJlIHVu YWJsZSB0byBjb21tdW5pY2F0ZWQgd2l0aCBkZXZpY2VzIGluIFZMQU4gWCBjb25uZWN0ZWQgdG8N Cj5SQjIuIFJpZ2h0Pw0KPg0KPkkgd291bGRuJ3QgY29uc2lkZXIgdGhhdCBhICJjb3JuZXIgY2Fz ZSIgdG8gYmUgaWdub3JlZC4gSSdkIGNvbnNpZGVyDQo+dGhhdCBhbiBvcGVyYXRpb25hbCBuaWdo dG1hcmUgdGhhdCBjYW4ndCBiZSBhbGxvd2VkIHRvIGhhcHBlbiAoYnkNCj5kZWZhdWx0KS4NCj4N Cj4+IEFueXdheSwgdGhlIGludGVudCBpcyB0aGF0IHBvcnRzIG9wZXJhdGUgaW4gZWl0aGVyIFZM IG9yIEZHTCBtb2RlLiBBbmQNCj4+IGFsbCB0aGUgcG9ydHMgb2YgYSBWTCBSQnJpZGdlIGFyZSBW TCBwb3J0cy4gQnV0IGFuIEZHTCBSQnJpZGdlIGlzDQo+PiByZXF1aXJlZCB0byBzdXBwb3J0IGFu IGFyYml0cmFyeSBtaXggb2YgVkwgYW5kIEZHTCBwb3J0cy4gVkwgYW5kIEZHTA0KPj4gZnJhbWVz IGFyZSBzaGlwcyBpbiB0aGUgbmlnaHQganVzdCBsaWtlIFZMIGZyYW1lcyBmb3IgZGlmZmVyZW50 IFZMQU5zDQo+PiBmb3IgRkdMIGZyYW1lcyBmb3IgZGlmZmVyZW50IEZHTHMuDQo+DQo+V2h5IG11 c3QgRkdMIGNhcGFibGUgZGV2aWNlcyBiZSByZXF1aXJlZCB0byBzdXBwb3J0IFZMPyBJIHVuZGVy c3RhbmQNCj50aGF0IGl0IGlzIHByb2JhYmx5IGEgZ29vZCB0aGluZyB0byBkbyAoc28geW91IGNh biBzdXBwb3J0IGVpdGhlcg0KPm1vZGUsIGRlcGVuZGluZyBvbiB3aGF0IG90aGVyIFJCcyBhcmUg Y2FwYWJsZSBvZikuIEJ1dCBkb2VzIHRoZSBGR0wNCj4qcHJvdG9jb2wqIHJlcXVpcmUgdGhpcyBp biBvcmRlciB0byB3b3JrIGNvcnJlY3RseT8gRG9lcyBwcm9wZXINCj5vcGVyYXRpb24gb2YgRkdM IHJlcXVpcmUgYmVpbmcgYWJsZSB0byBzdXBwb3J0IFZMIGFzIHdlbGw/IE9yIGlzIHRoZQ0KPnJl YWwgaW50ZW50IGp1c3QgdG8gYWxsb3cgYSBncmFjZWZ1bCB3YXkgdG8gImZhbGwgYmFjayIgaW50 byBWTCBtb2RlDQo+dG8gaW50ZXJlcGVyYXRlIHdpdGggbm9uIEZHTC1hd2FyZSBSQnM/IChJIHRo aW5rIHRoYXQgaXMgYSBmaW5lIHRoaW5nDQo+dG8gcmVxdWlyZSwgYnR3LikNCj4NCj4+ID4gQW5k IHRoZSB3YXkgdG8gbG9vayBhdCBWTCBtb2RlLCBpcyB0aGF0IGl0IGlzIHRoZSBmYWxsYmFjayBm b3IgdGhlDQo+PiA+IGNhc2Ugd2hlcmUgbm90IGFsbCBvZiB0aGUgUkJzIGluIHRoZSBjb21wdXMg YXJlIEZHTCBjYXBhYmxlLg0KPg0KPj4gVGhlIHdvcmQgIm1vZGUiIGRvZXMgbm90IG9jY3VyIGFu eXdoZXJlIGluIHRoZSBib2R5IG9mIHRoZSBkcmFmdC4gRkdMDQo+PiBSQnJpZGdlcyBhcmUgc3Vw ZXJzZXRzLiBGR0wgUkJyaWRnZXMgY2FuIGhhbmRsZSBWTCBmcmFtZXMgZmluZS4gSXQgaXMNCj4+ IGp1c3QgdGhhdCBWTCBSQnJpZGdlcyBjYW4ndCBoYW5kbGUgRkdMIGZyYW1lcyBhbmQgaXQgaXMg dmVyeSBoYXJkIHRvDQo+PiBndWFyYW50ZWUgdGhhdCBhbiBGR0wgZnJhbWUgd2lsbCBuZXZlciBi ZSByb3V0ZWQgdG8gYSBWTCBSQnJpZGdlDQo+PiB3aXRob3V0IGVpdGhlciBtdWx0aS10b3BvbG9n eSAod2hpY2ggaXMgbm90IHlldCBmdWxseSBzcGVjaWZpZWQgZm9yDQo+PiBUUklMTCkgb3Igc3Rv cHBpbmcgYWxsIGRhdGEgZmxvdyBiZXR3ZWVuIFZMIGFuZCBGR0wgUkJyaWRnZXMgKHdoY2loIGlz DQo+PiB3aGF0IHRoaXMgZHJhZnQgZG9lcykuDQo+DQo+SU1PLCB0aGlzIHNwZWMgc2hvdWxkIG5v dCBzYXkgYW55dGhpbmcgYWJvdXQgbXVsdGktdG9wb2xvZ3kgKHRoYXQgaXMNCj5mdXR1cmUgd29y aykgYW5kIHNob3VsZCBlbnN1cmUgdGhhdCBhIHN0YW5kYXJkcyBjb21wbGlhbnQNCj5pbXBsZW1l bnRhdGlvbiBjYW5ub3QgYW5kIHdpbGwgbm90IGZvcndhcmQgRkdMIHBhY2tldHMgdG8gVkwtb25s eQ0KPlJCcy4gQW55dGhpbmcgZWxzZSB3aWxsIGxpa2VseSBsZWFkIHRvIG9wZXJhdGlvbmFsIHBy b2JsZW1zLi4uDQo+DQo+PiA+IEkuZS4sIHdoYXQgaXMgc3VwcG9zZWQgbyBoYXBwZW4gaW4gYSBj YW1wdXMgd2hlcmUgc29tZSBSQnMgc2F5IHRoZXkgZG8NCj4+ID4gRkdMIGFuZCBvdGhlcnMgZG8g bm90PyBJcyB0aGUgaW50ZW50aW9uIHRoYXQgb25lIFRSSUxMIGNhbXB1cyBnZXRzDQo+PiA+IGZv cm1lZCB3aXRoIGFsbCBub2RlcyBmYWxsaW5nIGJhY2sgdG8gVkwgbW9kZT8NCj4NCj4+IEFzIHN0 YXRlZCBpbiB0aGUgZHJhZnQsIHRoZSBhc3N1bXB0aW9uIGluIHRoYXQgY2FzZSBpcyB0aGF0IHlv dSB3YW50ZWQNCj4+IGEgY29tcGxldGVseSBGR0wgY2FtcHVzIGFuZCB3aGF0ZXZlciBWTCBSQnJp ZGdlcyBhcmUgcHJlc2VudCBhcmUNCj4+IGlzb2xhdGVkIG1pc2NvbmZpZ3VyYXRpb25zLg0KPg0K PkkgdGhpbmsgdGhpcyBpcyBhbiB1bnJlYXNvbmFibGUgYXNzdW1wdGlvbi4gWW91IHdpbGwgZ2V0 IGRlcGxveW1lbnRzDQo+dGhhdCBoYXZlIGJvdGguIEFjY2lkZW50cyBjYW4gaGFwcGVuLCBldGMu IEkgdGhpbmsgd2UnZCBiZSBiZXR0ZXIgb2ZmDQo+d2l0aCB2ZXJ5IGNsZWFyIHdheXMgZm9yIHRo ZSBvcGVyYXRvciB0byBzcGVjaWZ5IHdoYXQgdGhleSB3YW50IHRvDQo+aGF2ZSBoYXBwZW4gaW4g YSBtaXhlZCBtb2RlLiBXZSBjYW4gaGF2ZSBhIGRlZmF1bHQgbW9kZSwgYnV0IHRoZQ0KPm9wZXJh dG9yIG5lZWRzIHRvIGJlIGFibGUgdG8gb3ZlcnJpZGUgdGhlIGRlZmF1bHRzLg0KPg0KPkkuZS4s IGlmIG9ubHkgb25lIChvciBhIHNtYWxsIG51bWJlciBvZikgc3dpdGNoZXMgc3VwcG9ydHMgRkdM LCB5b3UNCj53YW50IHRoZSBkZWZhdWx0IG1vZGUgdG8gYmUgdG8gaGF2ZSB0aGUgZW50aXJlIFRS SUxMIGNhbXB1cyB0byB0cnkgdG8NCj51c2UgRkdMPyBJJ20gbm90IHN1cmUuDQo+DQo+PiBTbyB0 aGUgcHJvdmlzaW9ucyBhcmUgdGhhdCBhbGwgdGhlIFJCcmlkZ2VzIHBlZXIgZm9yIGNvbnRyb2wg YnV0IFZMDQo+PiBhbmQgRkdMIFJCcmlkZ2VzIGRvIG5vdCBwZWVyIGZvciBkYXRhLiBZb3UgZG9u J3Qgd2FudCB0aGUgYXR0YWNobWVudA0KPj4gb2Ygb25lIFJCcmlkZ2UgbWlzY29uZmlndXJlZCB0 byBiZSBhIFZMIFJCcmlkZ2UgdG8ga2lsbCB5b3VyIHdob2xlDQo+PiBGR0wgY2FtcHVzLiBZb3Ug Y2FuJ3QgImZhbGwgYmFjayIgYSBwb3J0IGNvbmZpZ3VyZWQgZm9yIEZHTCB3aXRob3V0DQo+PiB2 aW9sYXRpbmcgc2VjdXJpdHkgcG9saWN5Lg0KPg0KPkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgInNl Y3VyaXR5IHBvbGljeSIgcmVmZXJlbmNlIGhlcmUuDQo+DQo+PiBNYXliZSBjbGFyaWZ5aW5nIHRl eHQgc2hvdWxkIGJlIGFkZGVkIGFuZCB0aGUgIkZHTCBSQnJpZGdlcyIgc2hvdWxkIGJlDQo+PiBy ZWZlcnJlZCB0byBhcyAiRkdMVkwgUkJyaWRnZXMiLg0KPg0KPk5vLiBUaGUgaXNzdWUgaXNuJ3Qg dGVybWlub2xvZ3kuIFRoZSB0ZXh0IG5lZWRzIHRvIGJlIGNsZWFyZXIgd2hhdCB0aGUNCj5pbnRl bnRpb24gaXMuIEZvciBtZSwgaXQncyBzb21ldGltZXMgaGFyZCB0byBwdWxsIG91dCB0aGUgb3Zl cnJpZGluZw0KPmludGVudGlvbiBmcm9tIHRoZSBzcGVjaWZpYyBydWxlcyB0aGF0IGFyZSBsYXll ZCBvdXQgaW4gdGhlIGRvY3VtZW50Lg0KPg0KPlRob21hcw0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+dHJpbGwgbWFpbGluZyBsaXN0DQo+dHJp bGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmc8bWFp bHRvOnRyaWxsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmlsbA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07572A1Dszxeml525mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56 Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hk u7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IFh1eGlhb2h1DQo8YnI+DQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4gMjAxMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0 PHNwYW4gbGFuZz0iRU4tVVMiPjExPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMjwvc3Bh bj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDEwOjEwPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxz cGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ICdSYWRpYSBQ ZXJsbWFuJzsgUmFqZWV2IE1hbnVyPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFRob21hcyBOYXJ0ZW47IERvbmFs ZCBFYXN0bGFrZTsgdHJpbGxAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gcmU6IFt0cmlsbF0gV0cg TGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRyaWxsLWZpbmUtbGFiZWxpbmctMDIudHh0PG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4gdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRyaWxsLWJvdW5j ZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS7 o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+UmFkaWEgUGVybG1hbjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDEyPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3Nw YW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIyPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4g NzoyOTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSYWplZXYgTWFudXI8YnI+DQo8L3NwYW4+PGI+5oqE6YCB PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gVGhvbWFz IE5hcnRlbjsgRG9uYWxkIEVhc3RsYWtlOyB0cmlsbEBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7k uLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBS ZTogW3RyaWxsXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtdHJpbGwtZmluZS1sYWJlbGluZy0w Mi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkn ZCB0aGluayBpdCBvdWdodCB0byBiZSBwb3NzaWJsZSB0byBoYXZlIGEgcmVhbGx5IHNpbXBsZSB0 cmFuc2l0LW9ubHkgUkIgUiZuYnNwO3RoYXQgZG9lc24ndCBib3RoZXIgbG9va2luZyBiZXlvbmQg dGhlIFRSSUxMIGhlYWRlci4uLnNvIGRvZXNuJ3QgY2FyZSB3aGF0IFZMQU4gb3IgRkdMIGl0IGlz Li4uUiB3b24ndCBkbyBhbnkgZmlsdGVyaW5nLCBidXQgZmlsdGVyaW5nIGlzIG9ubHkNCiBhbiBv cHRpbWl6YXRpb24sIGV4Y2VwdCBhdCB0aGUgZWRnZXMsIHdoZXJlIGl0IGlzIG1hbmRhdG9yeS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG9lcyBpdCBvdWdodCB0byBoYXZl IGFub3RoZXIgdHlwZSBvZiB0cmFuc2l0IFJCIHdoaWNoIG5lZWRzIHRvIGRvIGZpbHRlcmluZyBi dXQgY2Fu4oCZdCBkbyBpdCBiYXNlZCBvbiB0aGUgZnVsbCBGR0wgZHVlIHRvIHNvbWUgcmVhc29u cyAoZS5nLiB0aGUNCiBsYWNrIG9mIGVub3VnaCBoYXJkd2FyZSBtZW1vcnkgY2FwYWJpbGl0eSk/ IEZvciBleGFtcGxlLCBpdCBjb3VsZCBkbyBhIGNvYXJzZS1ncmFpbmVkIGZpbHRlcmluZyBiYXNl ZCBvbiBwYXJ0aWFsIGJpdHMgaW4gdGhlIEZHTC4gSW4gb3RoZXIgd29yZHMsIFRoZSB0cmFuc2l0 IFJCIGNvdWxkIGhhdmUgYSBmbGV4aWJpbGl0eSB0byBkZXRlcm1pbmUgaG93IG1hbnkgYml0cyAo MH4yNCkgaW4gdGhlIEZHTCB3b3VsZCBiZSB1c2VkIGZvciBmaWx0ZXJpbmcuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFueXdheS4uLmJhY2sgdG8g dHdvIHRhZ3MgdnMgYSBzaW5nbGUgMjQtYml0IHRhZy4uLndlIHJlYWxseSBoYXZlIHRvIHBpY2sg b25lIGFuZCBnbyB3aXRoIGl0LiZuYnNwOyBFaXRoZXIgb25lIHdvcmtzLCBhbmQgYWx0aG91Z2gg b25lIHRhZyBtaWdodCBiZSBhIGJpdCBtb3JlIGVsZWdhbnQsIEkndmUgaW5mb3JtYWxseSBhc2tl ZCBzb21lIGltcGxlbWVudGVycyBhbmQgc29tZSBvZiB0aGVtDQogc2FpZCB0aGV5IGRvbid0IGNh cmUsIGFuZCBvdGhlcnMgc2F5IHRoZXkgcHJlZmVyIHR3byAxMi1iaXQgcGllY2VzIGluIHR3byB0 YWdzLCBzbyBJIHZvdGUgdGhhdCB3ZSBzdGljayB3aXRoIHRoYXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHRoZXJlIGlzIG5vIG5lZWQgdG8gd29ycnkgYWJvdXQg dGhlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFueW1vcmUsIGNvdWxkIHlvdSBwbGVhc2UgZXhw bGFpbiB3aHkgb3RoZXJzIHByZWZlciB0d28gMTItYml0IHRhZ3MgdG8gYSBzaW5nbGUNCiAyNC1i aXQgdGFnPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5YaWFvaHU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGZvciB0aGUgc3Bl Yy4uLnllYWgsIGFzIHBlb3BsZSBwb2ludGVkIG91dCwgdGhlcmUgYXJlIHBsYWNlcyB3aGVyZSB0 aGUgc3BlYyBjb3VsZCBiZSBjbGFyaWZpZWQsIGFuZCB3ZSBzaG91bGQgZG8gdGhhdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9mIHRoZSBjb21iaW5h dGlvbnMgcG9zc2libGUsIHdoaWNoIHNob3VsZCBiZSBkZXNjcmliZWQgaW4gdGhlIHNwZWM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIEZH TCYjNDM7VkwsIGFuZCBWTCBkZWZpbml0ZWx5LiZuYnNwOyBBbmQgdGhlIGJhc2Ugc3BlYyBhbHJl YWR5IGRlc2NyaWJlcyBWTC1vbmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+V2UgbWlnaHQgYWxzbyB3YW50IHRvIG1lbnRpb24gbmVpdGhlciBGR0wg bm9yIFZMICh0cmFuc2l0IG9ubHksIG5vIGZpbHRlcmluZykuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBtaWdodCBhbHNvIHdhbnQgdG8gbWVudGlv biBldmVudHVhbGx5IGRyb3BwaW5nIHN1cHBvcnQgZm9yIFZMLCBhbmQgYWxsb3dpbmcgYSBtaXh0 dXJlIG9mIEZHTCYjNDM7VkwgYW5kIEZHTC1vbmx5LiZuYnNwOyBCdXQgZm9yIHNpbXBsaWNpdHks IEkgdGhpbmsgd2Ugc2hvdWxkIG5vdCBkZXNjcmliZSB0aGF0IHZhcmlhbnQgYXQgdGhhdCBwb2lu dCwgYW5kIG9ubHkgZGVzY3JpYmUgKGluIHRoaXMNCiBkb2N1bWVudCksIEZHTCYjNDM7VkwgYW5k IGl0cyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggVkwtb25seS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRvZXMgYW55b25lIGhhdmUgYW55IHN0cm9uZyBv cGluaW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmFkaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ T24gV2VkLCBOb3YgMjEsIDIwMTIgYXQgMTE6MjQgQU0sIFJhamVldiBNYW51ciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJtYW51ckBicm9hZGNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5ybWFudXJAYnJv YWRjb20uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCk15IHVuZGVyc3RhbmRpbmcgaXMg d2UgaGF2ZSBvbmx5IDIgbW9kZXMsIFZMLW1vZGUgYW5kIEZHTC1tb2RlIChzdXBlcnNldCBtb2Rl IHN1cHBvcnRpbmcgYm90aCBWTCBhbmQgRkdMKS4gSSBmZWVsIGl0IHdvdWxkIGJlIHVzZWZ1bCB0 byBhZGQgbW9yZSB0ZXh0IHRvIGNsYXJpZnkgdGhlIHByb2Nlc3NpbmcvY29tcGxpYW5jZSByZXF1 aXJlbWVudHMgZm9yIGluZ3Jlc3MgLyB0cmFuc2l0IC8gZWdyZXNzIFJCIGNvbnRleHRzIHNlcGFy YXRlbHkgZm9yDQogZWFjaCBvZiB0aGVzZSB0d28gbW9kZXMuIFRoaXMgd2lsbCBoZWxwIGltcGxl bWVudGF0aW9ucyB0aGV5IG1heSB3YW50IHRvIHN1cHBvcnQgdHJhbnNpdCBvbmx5IGZ1bmN0aW9u cyBhbmQgc3RpbGwgYmUgY29tcGxpYW50Ljxicj4NCjxicj4NCkZvciBleGFtcGxlLCBpdCBpcyBu b3QgY2xlYXIgdG8gbWUgd2hlbiBhbiBSQiB3YW50cyB0byBvcGVyYXRlIGFzIHRyYW5zaXQtb25s eSBSQiwgVkwvRkdMIGNhcGFiaWxpdHkgY2FuIGJlIGNvbmZpZ3VyZWQgcGVyIHBvcnQgb3IgYWxs IHBvcnRzIG9uIHRoYXQgUkIgbXVzdCBiZSBjb25maWd1cmVkIHRvIG9wZXJhdGUgaW4gdGhlIHNh bWUgbW9kZT8gSSBhbSBhc3N1bWluZyBpdCBpcyB0aGUgbGF0dGVyLjxicj4NCjxicj4NClRoYW5r cyE8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ LS1SYWplZXY8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IDxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj50cmlsbC1ib3VuY2VzQGll dGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3Jn Ij50cmlsbC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE9sZW4gU3Rva2VzPGJy Pg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjAsIDIwMTIgOTowOCBQTTxicj4NClRvOiBUaG9t YXMgTmFydGVuOyBEb25hbGQgRWFzdGxha2U8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnRyaWxs QGlldGYub3JnIj50cmlsbEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW3RyaWxsXSBX RyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtdHJpbGwtZmluZS1sYWJlbGluZy0wMi50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRyeWluZyBOT1QgdG8gYWRkIGFueXRoaW5nIG1vcmUgaW4g bGluZTwvc3Bhbj7FoDxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpJdCBzZWVtcyB0aGF0 IG11bHRpcGxlIGRpZmZlcmVudCBwZW9wbGUgaGF2ZSBtdWx0aXBsZSBkaWZmZXJlbnQgbWlncmF0 aW9uPGJyPg0Kc2NlbmFyaW9zIGluIG1pbmQuICZuYnNwO0kgdGhpbmsgdGhhdCBzZXZlcmFsIG9m IHVzIGNvdWxkIGJlbmVmaXQgZnJvbTxicj4NCnNvbWV0aGluZyB0aGF0IGJldHRlciBzcGVsbHMg b3V0IHdoYXQgc2NlbmFyaW8ocykgdGhlIGF1dGhvcnMgaGF2ZSBpbjxicj4NCm1pbmQuICZuYnNw O0RvbmFsZCdzIHNjZW5hcmlvcyBkZXNjcmliZWQgaW4gaGlzIHJlc3BvbnNlIHRvIG15IHByZXZp b3VzIGVtYWlsPGJyPg0Kd291bGQgaGF2ZSBoZWxwZWQgdGhlIGRyYWZ0LiAmbmJzcDtXZSBjYW4g dGhlbiBkaXNjdXNzIGlmIHRoZXJlIGFyZSBvdGhlcnMgdGhhdDxicj4NCm5lZWQgdG8gYmUgY29u c2lkZXJlZC48YnI+DQo8YnI+DQpXZSBzZWVtIHRvIGJlIGRpc2N1c3NpbmcgdGhyZWUgdHlwZXMg b2Ygbm9kZXM6PGJyPg0KPGJyPg0KMSkgVkwtb25seSBjYXBhYmxlIFJCcmlkZ2VzPGJyPg0KMikg VkwgYW5kIEZHTCBjYXBhYmxlIFJCcmlkZ2VzPGJyPg0KMykgRkdMLW9ubHkgY2FwYWJsZSBSYnJp ZGdlczxicj4NCjxicj4NCkZvciB0aGUgdGhpcmQgKEZHTC1vbmx5KSB0eXBlLCByZW1lbWJlciB0 aGF0IGF0IHNvbWUgcG9pbnQgcGVvcGxlIHdpbGw8YnI+DQp3YW50IHRvIGRyb3Agc3VwcG9ydCBm b3IgdGhlIFZMIFJCcmlkZ2VzLiAmbmJzcDtUaGVyZSBtYXkgYWxzbyBiZSBzaWxpY29uIG91dDxi cj4NCnRoYXQgdGhhdCBjYW4gb3BlcmF0ZSBpbiBWTCBtb2RlIG9yIGluIEZHTCBtb2RlIGJ1dCBu b3QgYm90aCBhdCB0aGUgc2FtZTxicj4NCnRpbWUuICZuYnNwO05vdGUsIEkgYW0gbm90IGEgc2ls aWNvbiBwZXJzb24uPGJyPg0KPGJyPg0KSWYgdGhlc2UgdGhyZWUgdHlwZXMgYXJlIGludGVuZGVk LCBhIG1vcmUgY2xlYXIgc3RhdGVtZW50IG9mIHRoZTxicj4NCnJlcXVpcmVtZW50cyBmb3IgZWFj aCB0aW1lIG1pZ2h0IGJlIG9mIGJlbmVmaXQuICZuYnNwO1RoZSByZXF1aXJlbWVudHMgc2hvdWxk PGJyPg0KZGVzY3JpYmUgaW5ncmVzcywgZWdyZXNzLCB0cmFuc2l0LCBhbmQgdHJhbnNpdCBwbHVz IGVncmVzcyBSQnJpZGdlcy4gSWY8YnI+DQpvbmUgb2YgdGhlc2UgdHlwZXMgaXMgbm90IGludGVu ZGVkLCB0aGVuIGEgY2xlYXIgc3RhdGVtZW50IHRoYXQgaXQgaXMgbm90PGJyPg0Kc3VwcG9ydGVk IG1heSBiZSBpbiBvcmRlci4gJm5ic3A7SXQgY291bGQgdGhlbiBiZSBkZWJhdGVkLjxicj4NCjxi cj4NCkkgYmVsaWV2ZSB0aGF0IERvbmFsZCBoYXMgZGVzY3JpYmVkIHRoYXQgdGhlIHNlY29uZCB0 eXBlIGFib3ZlIChWTCBhbmQgRkdMPGJyPg0KY2FwYWJsZSBSQnJpZGdlKSBpcyBhIHJlcXVpcmVt ZW50LiAmbmJzcDtUbyBtZSwgdGhlIGJlc3QgY2FzZSBmb3IgdGhhdDxicj4NCnJlcXVpcmVtZW50 IGlzIGluIGEgbXVsdGktdG9wb2xneSBlbnZpcm9ubWVudC4gJm5ic3A7U3RhdGluZyB0aGF0IHVz ZSBjYXNlPGJyPg0Kd291bGQgaGF2ZSBtYWRlIHRoZSBkb2N1bWVudCBhbmQgdGhhdCByZXF1aXJl bWVudCBtb3JlIGNsZWFyIHRvIG1lLiAmbmJzcDtJPGJyPg0KbGVhdmUgaXQgdG8gb3RoZXJzIHRv IGZpZ3VyZSBvdXQgaG93IHRvIHJlZmVyZW5jZSBzb21ldGhpbmcgdGhhdCBtaWdodCBiZTxicj4N CmRlZmluZWQgaW4gYW5vdGhlciBkcmFmdCAoYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlKS4g Jm5ic3A7Tm90ZSB0aGF0IHRvIG1lLDxicj4NCmEgJnF1b3Q7VkwgYW5kIEZHTCBjYXBhYmxlJnF1 b3Q7IG5vZGUgYWN0aW5nIG9ubHkgYXMgYSBWTCBub2RlIGlzIGp1c3QgYSBWTCBSQnJpZGdlLjxi cj4NCjxicj4NCkNoZWVycyw8YnI+DQpPbGVuPGJyPg0KPGJyPg0KPGJyPg0KT24gMTEvMjAvMTIg NzozNSBBTSwgJnF1b3Q7VGhvbWFzIE5hcnRlbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5h cnRlbkB1cy5pYm0uY29tIj5uYXJ0ZW5AdXMuaWJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxi cj4NCiZndDtIaSBEb25hbGQuPGJyPg0KJmd0Ozxicj4NCiZndDtEb25hbGQgRWFzdGxha2UgJmx0 OzxhIGhyZWY9Im1haWx0bzpkM2UzZTNAZ21haWwuY29tIj5kM2UzZTNAZ21haWwuY29tPC9hPiZn dDsgd3JpdGVzOjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBNeSB1bmRl cnN0YW5kaW5nIChmcm9tIHJlYWRpbmcgdGhlIGRyYWZ0IGVhcmxpZXIgdG9kYXkpIHdhcyB0aGF0 IGFuIFJCPGJyPg0KJmd0OyZndDsgJmd0OyBlaXRoZXIgb3BlcmF0ZXMgaW4gRkdMIG1vZGUgb3Ig VkwgbW9kZS4gSXQgZG9lc24ndCBtaXggYW5kPGJyPg0KJmd0OyZndDsgJmd0OyBtYXRjaC4gSS5l LiwgeW91IGRvbid0IGhhdmUgYW4gUkIgd2l0aCBzb21lIHBvcnRzIHVuZGVyc3RhbmRpbmcgRkdM PGJyPg0KJmd0OyZndDsgJmd0OyBhbmQgb3RoZXJzIFZMLiAmbmJzcDsoVG8gZG8gdGhhdCwgeW91 J2QgYW4gUkIgd291bGQgaGF2ZSB0byBjb252ZXJ0IGJldHdlZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 IHRoZSB0aGUgdHdvIGZvcm1hdHMgd2hpY2ggY291bGQgcmVzdWx0IGluIGxvc3Mgb2YgaW5mb3Jt YXRpb24uLi4pPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IFNvIHdoYXQgZXhhY3RseSBkaWQgeW91 IHRoaW5rIHRleHQgbGlrZSB0aGUgZm9sbG93aW5nIG1lYW50Ojxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDsmcXVvdDtBbiBGR0wgUkJyaWRnZSBNQVkgYmUgY29uZmlndXJlZCwgb24gb25lIG9y IG1vcmUgcG9ydHMsIHRvIGluZ3Jlc3M8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7bmF0aXZl IGZyYW1lcyBhcyBGR0wuIEFueSBwb3J0cyBub3Qgc28gY29uZmlndXJlZCB0aGF0IGFjY2VwdHMg YTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtuYXRpdmUgZnJhbWUgcGVyZm9ybSB0aGUgcHJl dmlvdXNseSBzcGVjaWZpZWQgVkwgaW5ncmVzcyBwcm9jZXNzaW5nPGJyPg0KJmd0OyZndDsgJm5i c3A7ICZuYnNwO29uIG5hdGl2ZSBmcmFtZXMgW1JGQzYzMjVdLiZxdW90Ozxicj4NCiZndDs8YnI+ DQomZ3Q7UGVyc29uYWxseSwgSSB0aG91Z2h0IHRoZSB3b3JkaW5nIHdhcyBzb21ld2hhdCBvZGQs IGFuZCBtYWRlIGEgbm90ZSB0bzxicj4NCiZndDtmaWd1cmUgb3V0IHdoYXQgdGhlIHJlYWwgaW50 ZW50aW9uIHdhcy4gOi0pIEFsc28sICZxdW90O01BWSZxdW90OyBtZWFucyBpdCdzIG5vdDxicj4N CiZndDtwYXJ0IG9mIHRoZSBzcGVjLCBidXQgbm90IGJlaW5nIGRpc2FsbG93ZWQgZWl0aGVyLiBU aGF0IGlzIG5vdCB0aGU8YnI+DQomZ3Q7c2FtZSB0aGluZyBhcyBzYXlpbmcgaXQgaXMgc29tZXRo aW5nIHRoYXQgaW1wbGVtZW50YXRpb25zIHdvdWxkIHdhbnQ8YnI+DQomZ3Q7b3IgbmVlZCB0byBk by48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgSSBhbHNvIGNhbid0IHNlZSB3aHkgeW91IHdvdWxk IHRoaW5rIHRoYXQgdGhlIGFiaWxpdHkgdG8gaW5ncmVzcyw8YnI+DQomZ3Q7Jmd0OyB0cmFuc2l0 LCBhbmQgZWdyZXNzIGJvdGggVkwgYW5kIEZHTCBmcmFtZXMgaW1wbGllcyBoYXZpbmcgdG8gJnF1 b3Q7Y29udmVydCZxdW90Ozxicj4NCiZndDsmZ3Q7IGJldHdlZW4gdGhvc2UgZm9ybWF0cy4gVGhl IHdob2xlIGlkZWEgb2YgZGF0YSBsYWJlbGluZyBpczxicj4NCiZndDsmZ3Q7IHNlcGFyYXRpb24v aXNvbGF0aW9uLiBXaHkgd291bGQgeW91IGNvbnZlcnQgYmV0d2VlbiB0aGVtIGFueW1vcmUgdGhh bjxicj4NCiZndDsmZ3Q7IHlvdSB3b3VsZCBjb252ZXJ0IGJldHdlZW4gYSByYW5kb20gcGFpciBv ZiBkaWZmZXJlbnQgVkxBTnM/PGJyPg0KJmd0Ozxicj4NCiZndDtObyBkaXNhZ3JlZW1lbnQuIE15 IGFzc3VtcHRpb24gaGFkIGJlZW4gdGhhdCBpZiB5b3UgaGF2ZSBhbiBSQiB0aGF0PGJyPg0KJmd0 O3VuZGVyc3RhbmRzIGJvdGggVkwgYW5kIEZHTCwgdGhhdCBzdWNoIGEgbW9kZSB3b3VsZCBvbmx5 IGJlIHVzZWZ1bCBpZjxicj4NCiZndDtvbmUgd2FzIGNvbnZlcnRpbmcgZnJvbSBvbmUgZm9ybWF0 IHRvIHRoZSBvdGhlciwgb3IgaWYgb25lIGZlbGwgYmFjazxicj4NCiZndDtmcm9tIGZyb20gRkdM IHRvIFZMIG1vZGUgaWYgaXQgZGlkbid0IG1ha2Ugc2Vuc2UgdG8gb3BlcmF0ZSBpbiBGR0w8YnI+ DQomZ3Q7bW9kZS4gQnV0IEkgd2Fzbid0IDEwMCUgc3VyZSB3aGF0IHRoZSBkcmFmdCdzIGludGVu dGlvbiB3YXMuLi48YnI+DQomZ3Q7PGJyPg0KJmd0O0J1dCBvbiByZXJlYWRpbmcgcGFydHMgb2Yg dGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGEgc2luZ2xlIFRSSUxMPGJyPg0KJmd0O2NhbXB1cyBj YW4gYWN0dWFsbHkgY29uc2lzdCBvZiBhIG1peHR1cmUgb2YgYm90aCBWTCBhbmQgRkdMLWNhcGFi bGU8YnI+DQomZ3Q7UkJzLiBBbmQgdGhhdCBjYW1wdXMgaXMgZWZmZWN0aXZlbHkgcGFydGl0aW9u ZWQsIHdoZXJlIHNvbWUgb2YgdGhlPGJyPg0KJmd0O2xpbmtzL1JCcyBvcGVyYXRlIGluIEZHTCBt b2RlIChvbmx5KSBhbmQgdGhlIHJlc3Qgb3BlcmF0ZSBpbiBWTCBtb2RlPGJyPg0KJmd0Oyhvbmx5 KSB3aXRoIHRoZSBkYXRhIHBsYW5lcyBvZiB0aGUgJnF1b3Q7dHdvIG5ldHdvcmtzJnF1b3Q7IG9w ZXJhdGluZyBsaWtlczxicj4NCiZndDtzaGlwcyBpbiB0aGUgbmlnaHQuPGJyPg0KJmd0Ozxicj4N CiZndDtZb3UgY2FuIGV2ZW4gaGF2ZSBhIHNpbmdsZSBSQiBzdXBwb3J0aW5nIGJvdGggbW9kZXMg KG9uIHNvbWU8YnI+DQomZ3Q7bGlua3MpLiBFLmcuLCB5b3UgY291bGQgaGF2ZSBSQjEgd2l0aCBs aW5rcyBMMSBhbmQgTDIgb3BlcmF0aW5nIGluIFZMPGJyPg0KJmd0O21vZGUgYW5kIGxpbmtzIEwz IGFuZCBMNCBvcGVyYXRpbmcgaW4gRkdMIG1vZGUuIFJpZ2h0PyAoVGhpcyBpczxicj4NCiZndDti ZWNhdXNlIGl0IGlzIHRoZSBpbmRpdmlkdWFsIGxpbmtzIHRoYXQgb3BlcmF0ZSBpbiBhIGdpdmVu IG1vZGUsIG5vdDxicj4NCiZndDt0aGUgUkIgcGVyIHNlLik8YnI+DQomZ3Q7PGJyPg0KJmd0O0lm IHNvLCBsZXQgbWUgcHVzaCBiYWNrIG9uIHRoaXMgbW9kZWwuICZuYnNwO1RoZSBkb2N1bWVudCBz YXlzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyBUaGUgdXN1YWwgRFJCIGVsZWN0aW9uIG9w ZXJhdGVzIG9uIGEgbGluayB3aXRoIG1peGVkIEZMRyBhbmQgVkw8YnI+DQomZ3Q7ICZuYnNwOyBw b3J0cy4gSWYgYW4gRkdMIFJCcmlkZ2UgcG9ydCBpcyBEUkIsIGl0IE1VU1QgaGFuZGxlIGFsbCBu YXRpdmU8YnI+DQomZ3Q7ICZuYnNwOyB0cmFmZmljIG9yIGFwcG9pbnQgb25seSBvdGhlciBGR0wg cG9ydHMgYXMgZm9yd2FyZGVyIGZvciBvbmUgb3IgbW9yZTxicj4NCiZndDsgJm5ic3A7IFZMQU5z LCBzbyB0aGF0IGFsbCBlbmQgc3RhdGlvbnMgd2lsbCBnZXQgc2VydmljZSB0byB0aGUgRkdMIGNh bXB1cy48YnI+DQomZ3Q7ICZuYnNwOyBJZiBhIFZMIFJCcmlkZ2UgcG9ydCBpcyBEUkIsIGl0IHdp bGwgbm90IHVuZGVyc3RhbmQgdGhhdCBGR0wgUkJyaWRnZTxicj4NCiZndDsgJm5ic3A7IHBvcnRz IGFyZSBkaWZmZXJlbnQuIFRvIHRoZSBleHRlbnQgdGhhdCBhIFZMIERSQiBoYW5kbGVzIG5hdGl2 ZTxicj4NCiZndDsgJm5ic3A7IGZyYW1lcyBvciBhcHBvaW50cyBvdGhlciBWTCBwb3J0cyBvbiBh IGxpbmsgdG8gaGFuZGxlIG5hdGl2ZSBmcmFtZXM8YnI+DQomZ3Q7ICZuYnNwOyBmb3Igb25lIG9y IG1vcmUgVkxBTnMsIHRoZSBlbmQgc3RhdGlvbnMgc2VuZGluZyBhbmQgcmVjZWl2aW5nIHRob3Nl PGJyPg0KJmd0OyAmbmJzcDsgbmF0aXZlIGZyYW1lcyB3aWxsIGJlIGlzb2xhdGVkIGZyb20gdGhl IEZHTCBjYW1wdXMuIFRvIHRoZSBleHRlbnQ8YnI+DQomZ3Q7ICZuYnNwOyB0aGF0IGEgVkwgRFJC IGhhcHBlbnMgdG8gYXBwb2ludCBhbiBGR0wgcG9ydCBhcyBBcHBvaW50ZWQgRm9yd2FyZGVyPGJy Pg0KJmd0OyAmbmJzcDsgZm9yIG9uZSBvciBtb3JlIFZMQU5zLCB0aGUgZW5kIHN0YXRpb25zIHNl bmRpbmcgYW5kIHJlY2VpdmluZyBuYXRpdmU8YnI+DQomZ3Q7ICZuYnNwOyBmcmFtZXMgaW4gdGhv c2UgVkxBTnMgd2lsbCBnZXQgc2VydmljZSB0byB0aGUgRkdMIGNhbXB1cy4gVGhpczxicj4NCiZn dDsgJm5ic3A7IHNvbWV3aGF0IG9kZCBjb3JuZXIgY2FzZSBiZWhhdmlvciBpcyBjb25zaWRlcmVk IGFjY2VwdGFibGUgYmVjYXVzZSBpdDxicj4NCiZndDsgJm5ic3A7IGlzIGFzc3VtZWQgdGhhdCBW TCBUUklMTCBzd2l0Y2hlcyBpbiBhbiBGR0wgY2FtcHVzIGFyZSBpbmZyZXF1ZW50PGJyPg0KJmd0 OyAmbmJzcDsgbWlzY29uZmlndXJhdGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDtJIHdvdWxkIG5v dCBqdXN0IGNhbGwgdGhpcyBhICZxdW90O2Nvcm5lciBjYXNlJnF1b3Q7IHRoYXQgY2FuIGJlIGln bm9yZWQuIFdoYXQ8YnI+DQomZ3Q7aXQgc2VlbXMgdG8gbWVhbiBpcyB0aGF0IHlvdSBjYW4gZGVw bHkgVFJJTEwsIGJ1dCBnZXQgZGlzY29ubmVjdGVkPGJyPg0KJmd0O1ZMQU4gaXNsYW5kcy4gVGhh dCBpcywgQy1WSUQgWCBhdCBvbmUgZWRnZSBpcyBwcm9jZXNzZWQgYnkgRkdMIFJCczxicj4NCiZn dDsoc2F5IFJCMSksIGJ1dCBlbHNld2hlcmUgb24gdGhlIG5ldHdvcmssIG9ubHkgVkwgUkJzIGNv bm5lY3QgdG8gQy1WSUQ8YnI+DQomZ3Q7WCAoc2F5IHZpYSBSQjIpLiBCZWNhdXNlIHRoZSBWTCBh bmQgRkdMIG5ldHdvcmtzIGFyZSBpc29sYXRlZCBmcm9tPGJyPg0KJmd0O2VhY2ggb3RoZXIsIHRo ZSByZXN1bHQgaXMgdGhhdCBkZXZpY2VzIGluIFZMQU4gWCBjb25uZWN0ZWQgdG8gUkIxIHdpbGw8 YnI+DQomZ3Q7YmUgdW5hYmxlIHRvIGNvbW11bmljYXRlZCB3aXRoIGRldmljZXMgaW4gVkxBTiBY IGNvbm5lY3RlZCB0bzxicj4NCiZndDtSQjIuIFJpZ2h0Pzxicj4NCiZndDs8YnI+DQomZ3Q7SSB3 b3VsZG4ndCBjb25zaWRlciB0aGF0IGEgJnF1b3Q7Y29ybmVyIGNhc2UmcXVvdDsgdG8gYmUgaWdu b3JlZC4gSSdkIGNvbnNpZGVyPGJyPg0KJmd0O3RoYXQgYW4gb3BlcmF0aW9uYWwgbmlnaHRtYXJl IHRoYXQgY2FuJ3QgYmUgYWxsb3dlZCB0byBoYXBwZW4gKGJ5PGJyPg0KJmd0O2RlZmF1bHQpLjxi cj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBBbnl3YXksIHRoZSBpbnRlbnQgaXMgdGhhdCBwb3J0cyBv cGVyYXRlIGluIGVpdGhlciBWTCBvciBGR0wgbW9kZS4gQW5kPGJyPg0KJmd0OyZndDsgYWxsIHRo ZSBwb3J0cyBvZiBhIFZMIFJCcmlkZ2UgYXJlIFZMIHBvcnRzLiBCdXQgYW4gRkdMIFJCcmlkZ2Ug aXM8YnI+DQomZ3Q7Jmd0OyByZXF1aXJlZCB0byBzdXBwb3J0IGFuIGFyYml0cmFyeSBtaXggb2Yg VkwgYW5kIEZHTCBwb3J0cy4gVkwgYW5kIEZHTDxicj4NCiZndDsmZ3Q7IGZyYW1lcyBhcmUgc2hp cHMgaW4gdGhlIG5pZ2h0IGp1c3QgbGlrZSBWTCBmcmFtZXMgZm9yIGRpZmZlcmVudCBWTEFOczxi cj4NCiZndDsmZ3Q7IGZvciBGR0wgZnJhbWVzIGZvciBkaWZmZXJlbnQgRkdMcy48YnI+DQomZ3Q7 PGJyPg0KJmd0O1doeSBtdXN0IEZHTCBjYXBhYmxlIGRldmljZXMgYmUgcmVxdWlyZWQgdG8gc3Vw cG9ydCBWTD8gSSB1bmRlcnN0YW5kPGJyPg0KJmd0O3RoYXQgaXQgaXMgcHJvYmFibHkgYSBnb29k IHRoaW5nIHRvIGRvIChzbyB5b3UgY2FuIHN1cHBvcnQgZWl0aGVyPGJyPg0KJmd0O21vZGUsIGRl cGVuZGluZyBvbiB3aGF0IG90aGVyIFJCcyBhcmUgY2FwYWJsZSBvZikuIEJ1dCBkb2VzIHRoZSBG R0w8YnI+DQomZ3Q7KnByb3RvY29sKiByZXF1aXJlIHRoaXMgaW4gb3JkZXIgdG8gd29yayBjb3Jy ZWN0bHk/IERvZXMgcHJvcGVyPGJyPg0KJmd0O29wZXJhdGlvbiBvZiBGR0wgcmVxdWlyZSBiZWlu ZyBhYmxlIHRvIHN1cHBvcnQgVkwgYXMgd2VsbD8gT3IgaXMgdGhlPGJyPg0KJmd0O3JlYWwgaW50 ZW50IGp1c3QgdG8gYWxsb3cgYSBncmFjZWZ1bCB3YXkgdG8gJnF1b3Q7ZmFsbCBiYWNrJnF1b3Q7 IGludG8gVkwgbW9kZTxicj4NCiZndDt0byBpbnRlcmVwZXJhdGUgd2l0aCBub24gRkdMLWF3YXJl IFJCcz8gKEkgdGhpbmsgdGhhdCBpcyBhIGZpbmUgdGhpbmc8YnI+DQomZ3Q7dG8gcmVxdWlyZSwg YnR3Lik8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBBbmQgdGhlIHdheSB0byBsb29rIGF0 IFZMIG1vZGUsIGlzIHRoYXQgaXQgaXMgdGhlIGZhbGxiYWNrIGZvciB0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IGNhc2Ugd2hlcmUgbm90IGFsbCBvZiB0aGUgUkJzIGluIHRoZSBjb21wdXMgYXJlIEZH TCBjYXBhYmxlLjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgd29yZCAmcXVvdDttb2RlJnF1 b3Q7IGRvZXMgbm90IG9jY3VyIGFueXdoZXJlIGluIHRoZSBib2R5IG9mIHRoZSBkcmFmdC4gRkdM PGJyPg0KJmd0OyZndDsgUkJyaWRnZXMgYXJlIHN1cGVyc2V0cy4gRkdMIFJCcmlkZ2VzIGNhbiBo YW5kbGUgVkwgZnJhbWVzIGZpbmUuIEl0IGlzPGJyPg0KJmd0OyZndDsganVzdCB0aGF0IFZMIFJC cmlkZ2VzIGNhbid0IGhhbmRsZSBGR0wgZnJhbWVzIGFuZCBpdCBpcyB2ZXJ5IGhhcmQgdG88YnI+ DQomZ3Q7Jmd0OyBndWFyYW50ZWUgdGhhdCBhbiBGR0wgZnJhbWUgd2lsbCBuZXZlciBiZSByb3V0 ZWQgdG8gYSBWTCBSQnJpZGdlPGJyPg0KJmd0OyZndDsgd2l0aG91dCBlaXRoZXIgbXVsdGktdG9w b2xvZ3kgKHdoaWNoIGlzIG5vdCB5ZXQgZnVsbHkgc3BlY2lmaWVkIGZvcjxicj4NCiZndDsmZ3Q7 IFRSSUxMKSBvciBzdG9wcGluZyBhbGwgZGF0YSBmbG93IGJldHdlZW4gVkwgYW5kIEZHTCBSQnJp ZGdlcyAod2hjaWggaXM8YnI+DQomZ3Q7Jmd0OyB3aGF0IHRoaXMgZHJhZnQgZG9lcykuPGJyPg0K Jmd0Ozxicj4NCiZndDtJTU8sIHRoaXMgc3BlYyBzaG91bGQgbm90IHNheSBhbnl0aGluZyBhYm91 dCBtdWx0aS10b3BvbG9neSAodGhhdCBpczxicj4NCiZndDtmdXR1cmUgd29yaykgYW5kIHNob3Vs ZCBlbnN1cmUgdGhhdCBhIHN0YW5kYXJkcyBjb21wbGlhbnQ8YnI+DQomZ3Q7aW1wbGVtZW50YXRp b24gY2Fubm90IGFuZCB3aWxsIG5vdCBmb3J3YXJkIEZHTCBwYWNrZXRzIHRvIFZMLW9ubHk8YnI+ DQomZ3Q7UkJzLiBBbnl0aGluZyBlbHNlIHdpbGwgbGlrZWx5IGxlYWQgdG8gb3BlcmF0aW9uYWwg cHJvYmxlbXMuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBJLmUuLCB3aGF0IGlzIHN1 cHBvc2VkIG8gaGFwcGVuIGluIGEgY2FtcHVzIHdoZXJlIHNvbWUgUkJzIHNheSB0aGV5IGRvPGJy Pg0KJmd0OyZndDsgJmd0OyBGR0wgYW5kIG90aGVycyBkbyBub3Q/IElzIHRoZSBpbnRlbnRpb24g dGhhdCBvbmUgVFJJTEwgY2FtcHVzIGdldHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGZvcm1lZCB3aXRo IGFsbCBub2RlcyBmYWxsaW5nIGJhY2sgdG8gVkwgbW9kZT88YnI+DQomZ3Q7PGJyPg0KJmd0OyZn dDsgQXMgc3RhdGVkIGluIHRoZSBkcmFmdCwgdGhlIGFzc3VtcHRpb24gaW4gdGhhdCBjYXNlIGlz IHRoYXQgeW91IHdhbnRlZDxicj4NCiZndDsmZ3Q7IGEgY29tcGxldGVseSBGR0wgY2FtcHVzIGFu ZCB3aGF0ZXZlciBWTCBSQnJpZGdlcyBhcmUgcHJlc2VudCBhcmU8YnI+DQomZ3Q7Jmd0OyBpc29s YXRlZCBtaXNjb25maWd1cmF0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0O0kgdGhpbmsgdGhpcyBp cyBhbiB1bnJlYXNvbmFibGUgYXNzdW1wdGlvbi4gWW91IHdpbGwgZ2V0IGRlcGxveW1lbnRzPGJy Pg0KJmd0O3RoYXQgaGF2ZSBib3RoLiBBY2NpZGVudHMgY2FuIGhhcHBlbiwgZXRjLiBJIHRoaW5r IHdlJ2QgYmUgYmV0dGVyIG9mZjxicj4NCiZndDt3aXRoIHZlcnkgY2xlYXIgd2F5cyBmb3IgdGhl IG9wZXJhdG9yIHRvIHNwZWNpZnkgd2hhdCB0aGV5IHdhbnQgdG88YnI+DQomZ3Q7aGF2ZSBoYXBw ZW4gaW4gYSBtaXhlZCBtb2RlLiBXZSBjYW4gaGF2ZSBhIGRlZmF1bHQgbW9kZSwgYnV0IHRoZTxi cj4NCiZndDtvcGVyYXRvciBuZWVkcyB0byBiZSBhYmxlIHRvIG92ZXJyaWRlIHRoZSBkZWZhdWx0 cy48YnI+DQomZ3Q7PGJyPg0KJmd0O0kuZS4sIGlmIG9ubHkgb25lIChvciBhIHNtYWxsIG51bWJl ciBvZikgc3dpdGNoZXMgc3VwcG9ydHMgRkdMLCB5b3U8YnI+DQomZ3Q7d2FudCB0aGUgZGVmYXVs dCBtb2RlIHRvIGJlIHRvIGhhdmUgdGhlIGVudGlyZSBUUklMTCBjYW1wdXMgdG8gdHJ5IHRvPGJy Pg0KJmd0O3VzZSBGR0w/IEknbSBub3Qgc3VyZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgU28g dGhlIHByb3Zpc2lvbnMgYXJlIHRoYXQgYWxsIHRoZSBSQnJpZGdlcyBwZWVyIGZvciBjb250cm9s IGJ1dCBWTDxicj4NCiZndDsmZ3Q7IGFuZCBGR0wgUkJyaWRnZXMgZG8gbm90IHBlZXIgZm9yIGRh dGEuIFlvdSBkb24ndCB3YW50IHRoZSBhdHRhY2htZW50PGJyPg0KJmd0OyZndDsgb2Ygb25lIFJC cmlkZ2UgbWlzY29uZmlndXJlZCB0byBiZSBhIFZMIFJCcmlkZ2UgdG8ga2lsbCB5b3VyIHdob2xl PGJyPg0KJmd0OyZndDsgRkdMIGNhbXB1cy4gWW91IGNhbid0ICZxdW90O2ZhbGwgYmFjayZxdW90 OyBhIHBvcnQgY29uZmlndXJlZCBmb3IgRkdMIHdpdGhvdXQ8YnI+DQomZ3Q7Jmd0OyB2aW9sYXRp bmcgc2VjdXJpdHkgcG9saWN5Ljxicj4NCiZndDs8YnI+DQomZ3Q7SSBkb24ndCB1bmRlcnN0YW5k IHRoZSAmcXVvdDtzZWN1cml0eSBwb2xpY3kmcXVvdDsgcmVmZXJlbmNlIGhlcmUuPGJyPg0KJmd0 Ozxicj4NCiZndDsmZ3Q7IE1heWJlIGNsYXJpZnlpbmcgdGV4dCBzaG91bGQgYmUgYWRkZWQgYW5k IHRoZSAmcXVvdDtGR0wgUkJyaWRnZXMmcXVvdDsgc2hvdWxkIGJlPGJyPg0KJmd0OyZndDsgcmVm ZXJyZWQgdG8gYXMgJnF1b3Q7RkdMVkwgUkJyaWRnZXMmcXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZn dDtOby4gVGhlIGlzc3VlIGlzbid0IHRlcm1pbm9sb2d5LiBUaGUgdGV4dCBuZWVkcyB0byBiZSBj bGVhcmVyIHdoYXQgdGhlPGJyPg0KJmd0O2ludGVudGlvbiBpcy4gRm9yIG1lLCBpdCdzIHNvbWV0 aW1lcyBoYXJkIHRvIHB1bGwgb3V0IHRoZSBvdmVycmlkaW5nPGJyPg0KJmd0O2ludGVudGlvbiBm cm9tIHRoZSBzcGVjaWZpYyBydWxlcyB0aGF0IGFyZSBsYXllZCBvdXQgaW4gdGhlIGRvY3VtZW50 Ljxicj4NCiZndDs8YnI+DQomZ3Q7VGhvbWFzPGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDt0cmlsbCBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJlZj0ibWFpbHRvOnRyaWxsQGlldGYub3JnIj50cmlsbEBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmlsbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGw8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPnRyaWxsQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC9h Pjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRy aWxsQGlldGYub3JnIj50cmlsbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07572A1Dszxeml525mbxchi_-- From liao.ting@zte.com.cn Thu Nov 22 22:05:08 2012 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 6CF0221F86C8; Thu, 22 Nov 2012 22:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.245 X-Spam-Level: X-Spam-Status: No, score=-98.245 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Er6OjN8t3aN; Thu, 22 Nov 2012 22:05:08 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A9D7F21F86A4; Thu, 22 Nov 2012 22:05:07 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 3C68B124BC16; Fri, 23 Nov 2012 14:06:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAN64rrv079441; Fri, 23 Nov 2012 14:04:53 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) In-Reply-To: To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liao.ting@zte.com.cn Date: Fri, 23 Nov 2012 14:04:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-23 14:04:46, Serialize complete at 2012-11-23 14:04:46 Content-Type: multipart/alternative; boundary="=_alternative 0021682748257ABF_=" X-MAIL: mse01.zte.com.cn qAN64rrv079441 Cc: trill-bounces@ietf.org, "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 06:05:08 -0000 This is a multipart message in MIME format. --=_alternative 0021682748257ABF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksVGlzc2ENCg0KU2VjdGlvbiA1LjEgcHJvdmlkZXMgYSBzaW1wbGUgZ2VuZXJhbCBtZXRob2Qg dG8gYXNzaWduIGRpZmZlcmVudCB0cmVlcyB0byANCmRpZmZlcmVudCBtZW1iZXJzIGFuZCBpdCBp cyBlYXN5IHRvIGVtcGxveS4NCkJ1dCBpbiBteSBvcGluaW9uLCBpdCBjb3VsZCBiZSBiZXR0ZXIg dG8gYWxsb3cgY28tZXhpc3RlbmNlIG9mIGRlZmF1bHQgDQptYW5uZXKjqGNtdKOpIGFuZCBtYW51 YWwgY29uZmlndXJhdGlvbiANCmZvciBkaXN0cmlidXRpb24gdHJlZSBjaG9vc2luZ6Osb3RoZXJ3 aXNlIGlmIHNvbWUgbWVtYmVyIFJCcyBhcmUgbWFudWFsbHkgDQpjb25maWd1cmVkIGFuZCBvdGhl cnMgYXJlIG5vdCBjb25maWd1cmVkIGF0IGFsbCwgDQpjb21wYXRpYmlsaXR5IHByb2JsZW0gd2l0 aCB0aGUgY3VycmVudCBhbGdvcml0aG0gY291bGQgb2NjdXIuDQpTbywgbWF5YmUgd2Ugc2hvdWxk IHByb3ZpZGUgYSB1bmlmaWVkIHRyZWUgZGlzdHJpYnV0aW9uIG1ldGhvZCB3aGljaCBpcyANCmNv bXBhdGlibGUgDQp3aXRoIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBjYW4gZW5zdXJlIGRpZmZl cmVudCBtZW1iZXIgUkJzIG9idGFpbiANCmRpZmZlcmVudCAgZGlzdHJpYnV0aW9uIHRyZWU/IA0K DQpUaGFua3MsDQpUaW5hDQo= --=_alternative 0021682748257ABF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLFRpc3NhPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mj5TZWN0aW9uIDUuMSBwcm92aWRlcyBhIHNpbXBsZSBnZW5lcmFs IG1ldGhvZCB0byBhc3NpZ24NCmRpZmZlcmVudCB0cmVlcyB0byBkaWZmZXJlbnQgbWVtYmVycyBh bmQgaXQgaXMgZWFzeSB0byBlbXBsb3kuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5CdXQgaW4g bXkgb3BpbmlvbiwgaXQgY291bGQgYmUgYmV0dGVyIHRvIGFsbG93IGNvLWV4aXN0ZW5jZQ0Kb2Yg ZGVmYXVsdCBtYW5uZXKjqGNtdKOpIGFuZCBtYW51YWwgY29uZmlndXJhdGlvbiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yPmZvciBkaXN0cmlidXRpb24gdHJlZSBjaG9vc2luZ6Osb3RoZXJ3aXNl IGlmIHNvbWUgbWVtYmVyDQpSQnMgYXJlIG1hbnVhbGx5IGNvbmZpZ3VyZWQgYW5kIG90aGVycyBh cmUgbm90IGNvbmZpZ3VyZWQgYXQgYWxsLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPmNvbXBh dGliaWxpdHkgcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGFsZ29yaXRobSBjb3VsZA0Kb2NjdXIu PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5TbywgbWF5YmUgd2Ugc2hvdWxkIHByb3ZpZGUgYSB1 bmlmaWVkIHRyZWUgZGlzdHJpYnV0aW9uDQptZXRob2Qgd2hpY2ggaXMgY29tcGF0aWJsZSA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPndpdGggbWFudWFsIGNvbmZpZ3VyYXRpb24gYW5kIGNhbiBl bnN1cmUgZGlmZmVyZW50IG1lbWJlcg0KUkJzIG9idGFpbiBkaWZmZXJlbnQgJm5ic3A7ZGlzdHJp YnV0aW9uIHRyZWU/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KVGhhbmtzLDxicj4NClRpbmE8L2ZvbnQ+DQo= --=_alternative 0021682748257ABF_=-- From d3e3e3@gmail.com Fri Nov 23 11:39:46 2012 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 1A95321F861B for ; Fri, 23 Nov 2012 11:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrOZ-TzPZN-r for ; Fri, 23 Nov 2012 11:39:45 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 579FE21F8617 for ; Fri, 23 Nov 2012 11:39:45 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6939444ieb.31 for ; Fri, 23 Nov 2012 11:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=vEOGExs/wH1FQa76pXaE9lxjr83pPSq9mifQT7GHBsY=; b=PWC0vEL4gj/OXAONgG76R2f1yFL0124mlFDBf3XkpnXL1VcgzR6FAOvPFT71iv/0+Z gVRZ0DWdk4lF1R9VsX8TNu8i8XKBNANIu+PZgpp6yECwouMk7Zz3dho1ZDnfrI137RO4 apJlilqvOf/TGDJISqiZsnKUn+i5GRwwKTuIKFo6gCa7sYLxCBy3lgTxP5L8/uTd2k0I SpXHp2JhoYbunb406LVtWWKZX8tmdgEGZi/2zp+FRA4I/ycNgYmveRYyUPgsqK7A0bj2 ikOTs/H0VHfsA4GN8+QxQuqLRGiVvBIv/uk7dR1JRsuf51E9w0OowjVej1R5FbWMYWjt et8w== Received: by 10.50.150.175 with SMTP id uj15mr7002044igb.52.1353699584756; Fri, 23 Nov 2012 11:39:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Fri, 23 Nov 2012 11:39:24 -0800 (PST) In-Reply-To: <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> From: Donald Eastlake Date: Fri, 23 Nov 2012 14:39:24 -0500 Message-ID: To: Phanidhar Koganti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Anoop Ghanwani , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 19:39:46 -0000 Hi Phanidhar, On Tue, Nov 20, 2012 at 2:29 PM, Phanidhar Koganti wrote: > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Anoop Ghanwani > Sent: Wednesday, November 21, 2012 12:50 AM > To: Donald Eastlake > Cc: Radia Perlman; trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > > On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake wrote: > > Hi Radia, > > On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman wrote: >> Ah. So the intent is that an FGL RBridge must be able to parse >> either VL or FGL, which would allow an edge RB that only supports >> VL to work OK, and to have some number of VLANs (4000 of them) that >> would be reachable via old edge RBs? > > > Yes on parsing. But it is hard to be sure no FGL frame can > get to a VL RBridge. Say you have VLRB1 connected to the campus > through FGLRB2. And FGLRB2 is connected to FGLRB3. What if > connectivity appears between VLRB1 and FGLRB3 and perhaps the link > between FGLRB2 and FGLRB3 breaks? How can you stop FGL frames from > going between FGLRB2 and FGLRB3 via VLRB1 keeping in mind that you > have to assume no changes in the old VL RBridges? (Without > multi-topology. With multi-topology, it's relatively easy.) > > FGL frames should never be forwarded to an RB that doesn't > support FGL. This is easy to figure out since IS-IS can tell us > what the capabilities of an RBridge are before forwarding to that > RBridge begins. And as a result of this requirement, we should > probably disallow FGL and non-FGL RBridges being reachable from the > same RBridge port, otherwise it would be challenging to implement > this control for multicast frames. I am not sure what you mean by "disallow" but if some physical topology is trivially realizable by someone plugging in the wrong cables, you have to take it into account and say what happens. In this case, where FGL and non-FGL RBridges are on the same link, the FGL RBridges just refuse to report any adjacencies on the link, thus excommunicating the link for TRILL Data traffic. > [Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as > transit nodes? Why can=92t the transit nodes just rely on TRILL SA/DA > to forward. Agree there will be issues for multicast in terms of > the optimal pruned forwarding as a non-FGL RB will not have access > to the inner IP header or VLAN (FGL based). However isn=92t this an > optimization for multicast pruning? The transit RBs can forward > based on the non-pruned multicast tree. If an RBridge has been modified from existing legacy VL RBridge so that you can safely use it as a transit node, then it *is* an FGL RBridge (even if it is a limited FGL RBridge that can't do FGL ingress and egress). If it has not been so modified, then it remains a VL RBridge and will likely mishandle or discard and FGL frames it receives. >> And we're assuming that old edge RBs that only do VL will >> know to drop something tagged with FGL? I believe they should but it does not seem wise to depend on that. > A VL RBridge should, in my opinion, drop an FGL frame based > on RFC 6325. However, if it did not, it would presumably mean it was > ignoring the 0x893B value where it should be requiring 0x8100. As a > result, it would believe the FGL frame was in some VLAN and might > egress it to the wrong end-stations, violating security policy. > > We need to make the spec clear on this aspect; i.e. FGL or > non-FGL RBridges must discard a received frame if the inner tag (FGL > or VLAN depending on what mode the port is operating in) is absent. In the draft, ports have an FGL/VL configuration "mode" for ingressing/egressing native frames but that don't have any "mode" for TRILL Data frames. If they are a VL RBridge, they can only handle VL TRILL Data frames. If they are an FGL RBridge, the can handle both VL and FGL TRILL Data frames. > Anoop 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 From pkoganti@Brocade.COM Fri Nov 23 18:10:30 2012 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 3239421F8612 for ; Fri, 23 Nov 2012 18:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUU9KqGHg-HI for ; Fri, 23 Nov 2012 18:10:29 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 548EE21F8689 for ; Fri, 23 Nov 2012 18:10:28 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id qAO2970X011456; Fri, 23 Nov 2012 18:10:27 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 18tdfu88hf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Nov 2012 18:10:27 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 23 Nov 2012 18:11:00 -0800 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 23 Nov 2012 18:11:00 -0800 From: Phanidhar Koganti To: Donald Eastlake Date: Fri, 23 Nov 2012 18:10:21 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3JsmC+bX9JWts5QzWycUmgXrrDJAAM19ig Message-ID: <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE9C0@HQ1-EXCH02.corp.brocade.com> References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-23_16:2012-11-23, 2012-11-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1211230347 Cc: Anoop Ghanwani , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 02:10:30 -0000 Hi Donald, Please see below inline -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Saturday, November 24, 2012 1:09 AM To: Phanidhar Koganti Cc: Anoop Ghanwani; trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi Phanidhar, On Tue, Nov 20, 2012 at 2:29 PM, Phanidhar Koganti w= rote: > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Anoop Ghanwani > Sent: Wednesday, November 21, 2012 12:50 AM > To: Donald Eastlake > Cc: Radia Perlman; trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > > On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake wrote: > > Hi Radia, > > On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman wrote: >> Ah. So the intent is that an FGL RBridge must be able to parse=20 >> either VL or FGL, which would allow an edge RB that only supports VL=20 >> to work OK, and to have some number of VLANs (4000 of them) that=20 >> would be reachable via old edge RBs? > > > Yes on parsing. But it is hard to be sure no FGL frame can=20 > get to a VL RBridge. Say you have VLRB1 connected to the campus=20 > through FGLRB2. And FGLRB2 is connected to FGLRB3. What if=20 > connectivity appears between VLRB1 and FGLRB3 and perhaps the link=20 > between FGLRB2 and FGLRB3 breaks? How can you stop FGL frames from=20 > going between FGLRB2 and FGLRB3 via VLRB1 keeping in mind that you=20 > have to assume no changes in the old VL RBridges? (Without=20 > multi-topology. With multi-topology, it's relatively easy.) > > FGL frames should never be forwarded to an RB that doesn't=20 > support FGL. This is easy to figure out since IS-IS can tell us what=20 > the capabilities of an RBridge are before forwarding to that RBridge=20 > begins. And as a result of this requirement, we should probably=20 > disallow FGL and non-FGL RBridges being reachable from the same=20 > RBridge port, otherwise it would be challenging to implement this=20 > control for multicast frames. I am not sure what you mean by "disallow" but if some physical topology is = trivially realizable by someone plugging in the wrong cables, you have to t= ake it into account and say what happens. In this case, where FGL and non-F= GL RBridges are on the same link, the FGL RBridges just refuse to report an= y adjacencies on the link, thus excommunicating the link for TRILL Data tra= ffic. > [Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as=20 > transit nodes? Why can't the transit nodes just rely on TRILL SA/DA to=20 > forward. Agree there will be issues for multicast in terms of the=20 > optimal pruned forwarding as a non-FGL RB will not have access to the=20 > inner IP header or VLAN (FGL based). However isn't this an=20 > optimization for multicast pruning? The transit RBs can forward based=20 > on the non-pruned multicast tree. If an RBridge has been modified from existing legacy VL RBridge so that you= can safely use it as a transit node, then it *is* an FGL RBridge (even if = it is a limited FGL RBridge that can't do FGL ingress and egress). If it ha= s not been so modified, then it remains a VL RBridge and will likely mishan= dle or discard and FGL frames it receives. [Phanidhar Koganti] Understand and my concern is to strictly state that a V= L only RBridge will never become a transit RB. There can be deployments whe= re customers might want to reuse their older hardware for transit only wher= e table sizes or VLAN aware might not be necessary. The transit VL-RBs need= not have any non-TRILL ports.=20 >> And we're assuming that old edge RBs that only do VL will=20 >> know to drop something tagged with FGL? [Phanidhar Koganti] Yes or there are no non-TRILL ports so the VL-RB is onl= y a pure transit RB. I believe they should but it does not seem wise to depend on that. [Phanidhar Koganti] True we cannot generalize and make such assumptions but= on the goal to fit into existing VL-RB environments, should we not give so= me room for VL only RB hardwares that are potentially capable of such selec= tive drops?=20 > A VL RBridge should, in my opinion, drop an FGL frame based=20 > on RFC 6325. However, if it did not, it would presumably mean it was=20 > ignoring the 0x893B value where it should be requiring 0x8100. As a=20 > result, it would believe the FGL frame was in some VLAN and might=20 > egress it to the wrong end-stations, violating security policy. > > We need to make the spec clear on this aspect; i.e. FGL or=20 > non-FGL RBridges must discard a received frame if the inner tag (FGL=20 > or VLAN depending on what mode the port is operating in) is absent. In the draft, ports have an FGL/VL configuration "mode" for ingressing/egre= ssing native frames but that don't have any "mode" for TRILL Data frames. I= f they are a VL RBridge, they can only handle VL TRILL Data frames. If they= are an FGL RBridge, the can handle both VL and FGL TRILL Data frames. > Anoop 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 From talmi@marvell.com Fri Nov 23 21:48:26 2012 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 899D721F853B for ; Fri, 23 Nov 2012 21:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywKWDkZjJQPX for ; Fri, 23 Nov 2012 21:48:21 -0800 (PST) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5B421F84E0 for ; Fri, 23 Nov 2012 21:48:17 -0800 (PST) From: Tal Mizrahi To: Donald Eastlake , "trill@ietf.org" Date: Sat, 24 Nov 2012 07:48:02 +0200 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac28X1YFpzZQsyxwSwqCcAxDwej+9gNp9R3A Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F8F40B44@IL-MB01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 05:48:26 -0000 Support. (sorry for late response). Tal. -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Tuesday, November 06, 2012 10:43 PM To: trill@ietf.org Subject: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi, As announced at the TRILL WG meeting today, this starts a two week WG Last = Call on draft-ietf-trill-fine-labeling ending 19 November. 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 _______________= ________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From david.black@emc.com Sat Nov 24 12:28:58 2012 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 D9CB521F84F9 for ; Sat, 24 Nov 2012 12:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOH-UuMz4UF5 for ; Sat, 24 Nov 2012 12:28:58 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 100E321F84F5 for ; Sat, 24 Nov 2012 12:28:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAOKSsYH006711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2012 15:28:54 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 24 Nov 2012 15:28:45 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAOKSiQ1025357; Sat, 24 Nov 2012 15:28:44 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Sat, 24 Nov 2012 15:28:43 -0500 From: "Black, David" To: "trill@ietf.org" , Linda Dunbar Date: Sat, 24 Nov 2012 15:28:42 -0500 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt Thread-Index: Ac3CrWgm/VxKoubUThyzi08klgddGwHzWwYg Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284D3FF0C@MX15A.corp.emc.com> References: <50A4095E.80009@acm.org> In-Reply-To: <50A4095E.80009@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 20:28:59 -0000 Hi Linda, Here are some (somewhat tardy) comments on this WG Last Call. (1) As noted by some of the others who commented, more functionality details would be good to add, especially on mixing of the push and pull models in Section 5. Cache consistency needs to be covered, at least its invalidation portion, as relying solely on aging out entries can black-hole traffic that uses a stale entry that hasn't aged out yet. (2) I also agree with Erik's earlier comment about not understanding why Appointed Forwarders are in this draft. If use of a directory can relax Appointed Forwarder restrictions without causing problems (e.g., loops), that needs to be explained somewhere, probably in Section 4. Otherwise, Appointed Forwarders should not be discussed. (3) On the comment about capitalizing MUST, SHOULD and MAY, the=20 applicable RFC is RFC 2119, but those terms are not ordinarily used in requirements documents. An explanation that these keywords express requirements on protocol development should be provided in order to use the upper case versions of these keywords. Here are some more detailed comments: Abstract: Edge RBridges currently learn the mapping between MAC addresses and their egress RBridges by observing the data packets traversed through. Change to: ... by observing traffic that traverses the RBridge. Section 1, 1st paragraph: (This ''blocked'' state has no effect of TRILL Data or IS-IS frames, which can still be sent and received. It only affects native frames.) "of TRILL data" -> "on TRILL Data" in second line above. In item 2 in the list, I'd change "usually" to "often": 2. Topology is usually based on racks and rows. In item 3 in the list, explain that server reload can change the MAC address and why that change may be needed or desirable, because Section 4 appears to assert that the MAC address can change. If that wasn't intended, this text in Section 4 needs attention for physical servers (it's ok for VMs): When a VM is moved to a new location or a server is loaded with a new application with different IP/MAC addresses, it is more likely that the DA of data packets sent out from those VMs are unknown to their attached edge RBridges. =20 Item 4 should follow up on the mention of subnets in item 3 and observe that multiple subnets on the same port at the same time is common for server virtualization and the change rate is higher than for physical servers. In the definition of "Bridge", change "draft" to "document". Section 3, p.6, first bullet - change both instances of "RB1" to "an RBridge" as there's no RB1 in figure 1. The last bullet in Section 3.1 is a bit sloppy about its use of the word "entries". It needs to explain exactly what is in an "entry" - it might be possible to do this in an introduction by stating that the presence of an entry (and list what it contains) avoids flooding of inbound frames that match the entry. Section 3.2, Scenario #1 - The use of the word "uplink" is confusing, overly constraining and not necessary. The important concept is how many ToR switches are in each rack. It's quite feasible for a server or switch in a rack to have multiple uplinks to the same ToR (e.g., when the links are 1 Gigabit Ethernet). Section 4, first sentence: OLD In data center environment, applications placement to servers, racks, and rows is orchestrated by Server (or VM) Management System(s). NEW In a data center environment, the assignment of applications to servers, including rack and row selection, is orchestrated by Server (or VM) Management System(s). END I'd suggest deleting Section 6 (Conclusion and Recommendations), as it's important for considering what the WG will do, but may not have much value in a published RFC. Thanks, --David > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of= Erik > Nordmark > Sent: Wednesday, November 14, 2012 4:13 PM > To: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-0= 1.txt >=20 >=20 > We would really like to she some more explicit indications from WG > participants that they have read this document and agree with it. >=20 > Please include any substantial as well as editorial improvements that > result from reviewing the document. >=20 > Erik >=20 > On 10/25/12 3:55 PM, Donald Eastlake wrote: > > This message begins a TRILL WG two week Last Call on the > > draft-ietf-trill-directory-framework draft. > > > > 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 > > _______________________________________________ > > trill mailing list > > trill@ietf.org > > https://www.ietf.org/mailman/listinfo/trill > > >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From tsenevir@cisco.com Sun Nov 25 08:50:24 2012 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 D1FA521F8609 for ; Sun, 25 Nov 2012 08:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqfZhAJ0q4Pl for ; Sun, 25 Nov 2012 08:50:23 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B366921F8607 for ; Sun, 25 Nov 2012 08:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6597; q=dns/txt; s=iport; t=1353862222; x=1355071822; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3ns3FGXFIc4TnTm6dK+vmFrlJ+BQy02OcxNAkP7GQe8=; b=Lni+E6V+CHlmaqhKWsZMC/lf+vqu/MDE7SDhfQY1XW4d3AscorLYXlsi EbxABbbXNTYtLA0i6Ov/V7QrvyiDCmUKoDvBXceWb6HbErAKcRJWDayxM YCa9330HBLqHzCdZCLfmbTjosKyqlSoeUlNlFPyIAd44s5+sUnqWzCs9G Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4JAMVLslCtJV2Z/2dsb2JhbABEgkmDX7oYFmwHgh4BAQEEIQELTBACAQgRBAEBCwUYAgMCMhQJCAEBBA4FCIgFq0wBkVuMN4MrNWEDpkWCb4Id X-IronPort-AV: E=McAfee;i="5400,1158,6907"; a="145956172" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 25 Nov 2012 16:50:22 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAPGoMFk004889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Nov 2012 16:50:22 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.133]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Sun, 25 Nov 2012 10:50:21 -0600 From: "Tissa Senevirathne (tsenevir)" To: "liao.ting@zte.com.cn" Thread-Topic: [trill] draft-ietf-trill-cmt Thread-Index: Ac2+FF0H+VMAhVydQOe90fdycFINlgLXltQAAG52p5A= Date: Sun, 25 Nov 2012 16:50:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.120.94] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562886B03Exmbrcdx08ciscoc_" MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 16:50:24 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562886B03Exmbrcdx08ciscoc_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Tina I am not sure I completely understand your question. Are you referring to a= scenario where some of the members (e.g. RB1 ) are using some manual confi= guration and other is using the proposed method (e.g. RB2) in the CMT draft= ? PS: Both RB1 and RB2 are members of the virtual RBridge RBv From: liao.ting@zte.com.cn [mailto:liao.ting@zte.com.cn] Sent: Thursday, November 22, 2012 10:05 PM To: Tissa Senevirathne (tsenevir) Cc: trill@ietf.org; trill-bounces@ietf.org Subject: Re: [trill] draft-ietf-trill-cmt Hi,Tissa Section 5.1 provides a simple general method to assign different trees to d= ifferent members and it is easy to employ. But in my opinion, it could be better to allow co-existence of default mann= er=1B$B!J=1B(Bcmt=1B$B!K=1B(B and manual configuration for distribution tree choosing=1B$B!$=1B(Botherwise if some member RBs are = manually configured and others are not configured at all, compatibility problem with the current algorithm could occur. So, maybe we should provide a unified tree distribution method which is com= patible with manual configuration and can ensure different member RBs obtain differ= ent distribution tree? Thanks, Tina --_000_FBEA3E19AA24F847BA3AE74E2FE193562886B03Exmbrcdx08ciscoc_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Tina=

 <= /p>

I am not sure I completel= y understand your question. Are you referring to a scenario where some of t= he members (e.g. RB1 ) are using some manual configuration and other is using the proposed method (e.g. RB2) in the CMT draft ?<= /o:p>

 <= /p>

PS: Both RB1 and RB2 are = members of the virtual RBridge RBv

 <= /p>

From: liao.tin= g@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt

 


Hi,Tissa

Section 5.1 provides a simple general meth= od to assign different trees to different members and it is easy to employ.=
But in my opinion, it could be better to a= llow co-existence of default manner=1B$B!J=1B(B= cmt=1B$B!K=1B(B and manual configuration
for distribution tree choosing=1B$B!$=1B(Botherwise if some member RBs are manually con= figured and others are not configured at all,
compatibility problem with the current alg= orithm could occur.
So, maybe we should provide a unified tree= distribution method which is compatible
with manual configuration and can ensure d= ifferent member RBs obtain different  distribution tree?

Thanks,
Tina

--_000_FBEA3E19AA24F847BA3AE74E2FE193562886B03Exmbrcdx08ciscoc_-- From liao.ting@zte.com.cn Sun Nov 25 17:19:58 2012 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 7D52021F8668; Sun, 25 Nov 2012 17:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.753 X-Spam-Level: X-Spam-Status: No, score=-94.753 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_BASE64_TEXT=2.796, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE0PLz4F7MTp; Sun, 25 Nov 2012 17:19:58 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 443E721F855A; Sun, 25 Nov 2012 17:19:51 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id ACB0C441443; Mon, 26 Nov 2012 09:21:19 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id C9C0217BB560; Mon, 26 Nov 2012 09:17:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAQ1JTj0070921; Mon, 26 Nov 2012 09:19:29 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) In-Reply-To: To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-KeepSent: EF810EE3:52F5AE7A-48257AC2:0005CA21; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liao.ting@zte.com.cn Date: Mon, 26 Nov 2012 09:19:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-26 09:19:17, Serialize complete at 2012-11-26 09:19:17 Content-Type: multipart/alternative; boundary="=_alternative 0007471548257AC2_=" X-MAIL: mse01.zte.com.cn qAQ1JTj0070921 Cc: trill-bounces@ietf.org, "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 01:19:58 -0000 This is a multipart message in MIME format. --=_alternative 0007471548257AC2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksVGlzc2ENCg0KWWVzo6x0aGF0J3MgZXhhY3RseSB3aGF0IEkgbWVhbi4gOikNClNob3VsZCB0 aGUgQ01UIHRha2UgdGhpcyBzY2VuYXJpbyBpbnRvIGFjY291bnSjvw0KDQpUaGFua3MsDQpUaW5h DQoNCg0KDQoiVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNjby5j b20+IA0Kt6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0xMS0yNiAwMDo1MA0K DQrK1bz+yMsNCiJsaWFvLnRpbmdAenRlLmNvbS5jbiIgPGxpYW8udGluZ0B6dGUuY29tLmNuPg0K s63LzQ0KInRyaWxsQGlldGYub3JnIiA8dHJpbGxAaWV0Zi5vcmc+DQrW98ziDQpSZTogW3RyaWxs XSBkcmFmdC1pZXRmLXRyaWxsLWNtdA0KDQoNCg0KDQoNCg0KSGkgVGluYQ0KIA0KSSBhbSBub3Qg c3VyZSBJIGNvbXBsZXRlbHkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uLiBBcmUgeW91IHJlZmVy cmluZyB0byANCmEgc2NlbmFyaW8gd2hlcmUgc29tZSBvZiB0aGUgbWVtYmVycyAoZS5nLiBSQjEg KSBhcmUgdXNpbmcgc29tZSBtYW51YWwgDQpjb25maWd1cmF0aW9uIGFuZCBvdGhlciBpcyB1c2lu ZyB0aGUgcHJvcG9zZWQgbWV0aG9kIChlLmcuIFJCMikgaW4gdGhlIENNVCANCmRyYWZ0ID8NCiAN ClBTOiBCb3RoIFJCMSBhbmQgUkIyIGFyZSBtZW1iZXJzIG9mIHRoZSB2aXJ0dWFsIFJCcmlkZ2Ug UkJ2DQogDQpGcm9tOiBsaWFvLnRpbmdAenRlLmNvbS5jbiBbbWFpbHRvOmxpYW8udGluZ0B6dGUu Y29tLmNuXSANClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyMiwgMjAxMiAxMDowNSBQTQ0KVG86 IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogdHJpbGxAaWV0Zi5vcmc7IHRyaWxs LWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwt Y210DQogDQoNCkhpLFRpc3NhIA0KDQpTZWN0aW9uIDUuMSBwcm92aWRlcyBhIHNpbXBsZSBnZW5l cmFsIG1ldGhvZCB0byBhc3NpZ24gZGlmZmVyZW50IHRyZWVzIHRvIA0KZGlmZmVyZW50IG1lbWJl cnMgYW5kIGl0IGlzIGVhc3kgdG8gZW1wbG95LiANCkJ1dCBpbiBteSBvcGluaW9uLCBpdCBjb3Vs ZCBiZSBiZXR0ZXIgdG8gYWxsb3cgY28tZXhpc3RlbmNlIG9mIGRlZmF1bHQgDQptYW5uZXKjqGNt dKOpIGFuZCBtYW51YWwgY29uZmlndXJhdGlvbiANCmZvciBkaXN0cmlidXRpb24gdHJlZSBjaG9v c2luZ6Osb3RoZXJ3aXNlIGlmIHNvbWUgbWVtYmVyIFJCcyBhcmUgbWFudWFsbHkgDQpjb25maWd1 cmVkIGFuZCBvdGhlcnMgYXJlIG5vdCBjb25maWd1cmVkIGF0IGFsbCwgDQpjb21wYXRpYmlsaXR5 IHByb2JsZW0gd2l0aCB0aGUgY3VycmVudCBhbGdvcml0aG0gY291bGQgb2NjdXIuIA0KU28sIG1h eWJlIHdlIHNob3VsZCBwcm92aWRlIGEgdW5pZmllZCB0cmVlIGRpc3RyaWJ1dGlvbiBtZXRob2Qg d2hpY2ggaXMgDQpjb21wYXRpYmxlIA0Kd2l0aCBtYW51YWwgY29uZmlndXJhdGlvbiBhbmQgY2Fu IGVuc3VyZSBkaWZmZXJlbnQgbWVtYmVyIFJCcyBvYnRhaW4gDQpkaWZmZXJlbnQgIGRpc3RyaWJ1 dGlvbiB0cmVlPyANCg0KVGhhbmtzLA0KVGluYSBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KDQoNCg== --=_alternative 0007471548257AC2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLFRpc3NhPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ZZXOjrHRoYXQncyBleGFjdGx5 IHdoYXQgSSBtZWFuLiA6KTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+U2hvdWxkIHRoZSBDTVQgdGFrZSB0aGlzIDwvZm9udD48Zm9udCBzaXplPTI+c2NlbmFyaW8N CmludG8gYWNjb3VudKO/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpUaGFua3MsPGJyPg0KVGluYTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUNCih0c2VuZXZp cikmcXVvdDsgJmx0O3RzZW5ldmlyQGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDt0cmlsbC1ib3VuY2VzQGll dGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMTEt MjYgMDA6NTA8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+JnF1b3Q7bGlhby50aW5nQHp0ZS5jb20uY24mcXVvdDsgJmx0O2xpYW8udGluZ0B6 dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7dHJpbGxAaWV0Zi5vcmcmcXVv dDsgJmx0O3RyaWxsQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmlsbF0g ZHJhZnQtaWV0Zi10cmlsbC1jbXQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5IaSBUaW5hPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5J IGFtIG5vdCBzdXJlIEkgY29tcGxldGVseQ0KdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uLiBBcmUg eW91IHJlZmVycmluZyB0byBhIHNjZW5hcmlvIHdoZXJlIHNvbWUgb2YNCnRoZSBtZW1iZXJzIChl LmcuIFJCMSApIGFyZSB1c2luZyBzb21lIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBvdGhlciBp cw0KdXNpbmcgdGhlIHByb3Bvc2VkIG1ldGhvZCAoZS5nLiBSQjIpIGluIHRoZSBDTVQgZHJhZnQg PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+UFM6IEJvdGggUkIxIGFuZCBSQjIgYXJlDQptZW1iZXJzIG9mIHRoZSB2aXJ0dWFsIFJCcmlk Z2UgUkJ2PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9t OjwvYj4gbGlhby50aW5nQHp0ZS5jb20uY24gW21haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbl0N CjxiPjxicj4NClNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMjIsIDIwMTIgMTA6MDUgUE08 Yj48YnI+DQpUbzo8L2I+IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpPGI+PGJyPg0KQ2M6 PC9iPiB0cmlsbEBpZXRmLm9yZzsgdHJpbGwtYm91bmNlc0BpZXRmLm9yZzxiPjxicj4NClN1Ympl Y3Q6PC9iPiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KSGksVGlzc2E8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NClNlY3Rpb24gNS4xIHByb3ZpZGVzIGEgc2ltcGxlIGdlbmVyYWwgbWV0aG9kIHRvIGFzc2ln biBkaWZmZXJlbnQgdHJlZXMNCnRvIGRpZmZlcmVudCBtZW1iZXJzIGFuZCBpdCBpcyBlYXN5IHRv IGVtcGxveS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpCdXQgaW4gbXkgb3BpbmlvbiwgaXQg Y291bGQgYmUgYmV0dGVyIHRvIGFsbG93IGNvLWV4aXN0ZW5jZSBvZiBkZWZhdWx0DQptYW5uZXKj qGNtdKOpIGFuZCBtYW51YWwgY29uZmlndXJhdGlvbiA8YnI+DQpmb3IgZGlzdHJpYnV0aW9uIHRy ZWUgY2hvb3NpbmejrG90aGVyd2lzZSBpZiBzb21lIG1lbWJlciBSQnMgYXJlIG1hbnVhbGx5DQpj b25maWd1cmVkIGFuZCBvdGhlcnMgYXJlIG5vdCBjb25maWd1cmVkIGF0IGFsbCwgPGJyPg0KY29t cGF0aWJpbGl0eSBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgYWxnb3JpdGhtIGNvdWxkIG9jY3Vy LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClNvLCBtYXliZSB3ZSBzaG91bGQgcHJvdmlkZSBh IHVuaWZpZWQgdHJlZSBkaXN0cmlidXRpb24gbWV0aG9kIHdoaWNoIGlzDQpjb21wYXRpYmxlIDxi cj4NCndpdGggbWFudWFsIGNvbmZpZ3VyYXRpb24gYW5kIGNhbiBlbnN1cmUgZGlmZmVyZW50IG1l bWJlciBSQnMgb2J0YWluIGRpZmZlcmVudA0KJm5ic3A7ZGlzdHJpYnV0aW9uIHRyZWU/IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpUaW5h PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjx0dD48Zm9udCBz aXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQp0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4N Cg== --=_alternative 0007471548257AC2_=-- From d3e3e3@gmail.com Sun Nov 25 20:33:13 2012 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 F04C221F85D6 for ; Sun, 25 Nov 2012 20:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4udLaRXT-xZ for ; Sun, 25 Nov 2012 20:33:13 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 801F421F85D2 for ; Sun, 25 Nov 2012 20:33:13 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so8415456iaf.31 for ; Sun, 25 Nov 2012 20:33:13 -0800 (PST) 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 :content-type; bh=6WtV0H4HKJnKw/QKJQkX/kbvyPpwkrvqQmFkQY8sDIQ=; b=Q13tQBi/iGBDWRqKCnygktqLmyaLaWF1H2GBWJxiftY8SH7oaTR020KQ7Ml5w5FYgs 1vRb7HlyX3qq5+kUzzZA3Bpr1tAv5CZLqM9jkauQxNJXjiTi2w/ujsH/aqPabZAisyP3 iEOUtUwXUqNwkQ1MaCVoYAhEdi73zjgWdJUThEZSIE42ze4AsJVJ6knVapfuyxcnfGpy FP1uMQ9hvvoYkm0yP9rDm2iBJ9anDwrhDmmoeIPxxrSXGawyjhmQbv8bdRxdlK0oQvbg B2Zvmftpq2fGcKyWSfqNoPn6L47yBUAIFTUA08riyjyof9IP5DnXbS6KmRoGfPGFpEX6 Ay5g== Received: by 10.50.150.175 with SMTP id uj15mr12337154igb.52.1353904393150; Sun, 25 Nov 2012 20:33:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Sun, 25 Nov 2012 20:32:53 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Sun, 25 Nov 2012 23:32:53 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] on vacation this coming week X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 04:33:14 -0000 HI, I'm on vacation this coming week and so will be less active but will check email daily. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From ostokes@extremenetworks.com Mon Nov 26 07:09:12 2012 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 EDEEB21F85AF for ; Mon, 26 Nov 2012 07:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2mtHTMMEZHf for ; Mon, 26 Nov 2012 07:09:12 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 42A6421F84FE for ; Mon, 26 Nov 2012 07:09:12 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Mon, 26 Nov 2012 07:09:11 -0800 From: Olen Stokes To: Donald Eastlake , Phanidhar Koganti Date: Mon, 26 Nov 2012 07:09:10 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3Jsl/68l1kvSy3SJ6UWXPhjR9y6ACMIJRw Message-ID: References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Anoop Ghanwani , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:09:13 -0000 >From Donald below: "If an RBridge has been modified from existing legacy VL RBridge so that yo= u can safely use it as a transit node, then it *is* an FGL RBridge (even if= it is a limited FGL RBridge that can't do FGL ingress and egress). If it h= as not been so modified, then it remains a VL RBridge and will likely misha= ndle or discard and FGL frames it receives." We seem to be moving in the direction where RBridges with differing capabil= ities are all considered to be FGL RBridges. Do we need to consider advert= ising the differences in capabilities in the ISIS extensions for FGL? =20 Cheers, Olen -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Friday, November 23, 2012 2:39 PM To: Phanidhar Koganti Cc: Anoop Ghanwani; trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi Phanidhar, On Tue, Nov 20, 2012 at 2:29 PM, Phanidhar Koganti w= rote: > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Anoop Ghanwani > Sent: Wednesday, November 21, 2012 12:50 AM > To: Donald Eastlake > Cc: Radia Perlman; trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > > On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake wrote: > > Hi Radia, > > On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman wrote: >> Ah. So the intent is that an FGL RBridge must be able to parse=20 >> either VL or FGL, which would allow an edge RB that only supports VL=20 >> to work OK, and to have some number of VLANs (4000 of them) that=20 >> would be reachable via old edge RBs? > > > Yes on parsing. But it is hard to be sure no FGL frame can=20 > get to a VL RBridge. Say you have VLRB1 connected to the campus=20 > through FGLRB2. And FGLRB2 is connected to FGLRB3. What if=20 > connectivity appears between VLRB1 and FGLRB3 and perhaps the link=20 > between FGLRB2 and FGLRB3 breaks? How can you stop FGL frames from=20 > going between FGLRB2 and FGLRB3 via VLRB1 keeping in mind that you=20 > have to assume no changes in the old VL RBridges? (Without=20 > multi-topology. With multi-topology, it's relatively easy.) > > FGL frames should never be forwarded to an RB that doesn't=20 > support FGL. This is easy to figure out since IS-IS can tell us what=20 > the capabilities of an RBridge are before forwarding to that RBridge=20 > begins. And as a result of this requirement, we should probably=20 > disallow FGL and non-FGL RBridges being reachable from the same=20 > RBridge port, otherwise it would be challenging to implement this=20 > control for multicast frames. I am not sure what you mean by "disallow" but if some physical topology is = trivially realizable by someone plugging in the wrong cables, you have to t= ake it into account and say what happens. In this case, where FGL and non-F= GL RBridges are on the same link, the FGL RBridges just refuse to report an= y adjacencies on the link, thus excommunicating the link for TRILL Data tra= ffic. > [Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as=20 > transit nodes? Why can't the transit nodes just rely on TRILL SA/DA to=20 > forward. Agree there will be issues for multicast in terms of the=20 > optimal pruned forwarding as a non-FGL RB will not have access to the=20 > inner IP header or VLAN (FGL based). However isn't this an=20 > optimization for multicast pruning? The transit RBs can forward based=20 > on the non-pruned multicast tree. If an RBridge has been modified from existing legacy VL RBridge so that you= can safely use it as a transit node, then it *is* an FGL RBridge (even if = it is a limited FGL RBridge that can't do FGL ingress and egress). If it ha= s not been so modified, then it remains a VL RBridge and will likely mishan= dle or discard and FGL frames it receives. >> And we're assuming that old edge RBs that only do VL will=20 >> know to drop something tagged with FGL? I believe they should but it does not seem wise to depend on that. > A VL RBridge should, in my opinion, drop an FGL frame based=20 > on RFC 6325. However, if it did not, it would presumably mean it was=20 > ignoring the 0x893B value where it should be requiring 0x8100. As a=20 > result, it would believe the FGL frame was in some VLAN and might=20 > egress it to the wrong end-stations, violating security policy. > > We need to make the spec clear on this aspect; i.e. FGL or=20 > non-FGL RBridges must discard a received frame if the inner tag (FGL=20 > or VLAN depending on what mode the port is operating in) is absent. In the draft, ports have an FGL/VL configuration "mode" for ingressing/egre= ssing native frames but that don't have any "mode" for TRILL Data frames. I= f they are a VL RBridge, they can only handle VL TRILL Data frames. If they= are an FGL RBridge, the can handle both VL and FGL TRILL Data frames. > Anoop 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 _______________= ________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From ostokes@extremenetworks.com Mon Nov 26 07:31:45 2012 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 F38C721F8594 for ; Mon, 26 Nov 2012 07:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDOmUN+ZZvSE for ; Mon, 26 Nov 2012 07:31:44 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1301A21F8588 for ; Mon, 26 Nov 2012 07:31:44 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Mon, 26 Nov 2012 07:31:43 -0800 From: Olen Stokes To: Donald Eastlake Date: Mon, 26 Nov 2012 07:31:41 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3GvRNA2q1AHPx2QmO+sjJSskwY6QFK12Dg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:31:45 -0000 Since the two emails below were written about a week ago, there has been a = lot of discussion about the RBridge capabilities required to be classified = as an FGL RBridge. I am still unclear about one part of the exchange below= . There is a discussion about the implications of a TRILL ingress RBridge ser= ially unicasting "a multi-destination TRILL Data frame to the relevant egre= ss TRILL switches after encapsulating it as a TRILL known unicast data fram= e (M=3D0)".=20 What is the use case envisioned when there is more than one "relevant egres= s FGL RBridge"? FWIW, Donald noted below that this provision has been in all of the previou= s versions. I agree. I did not mean to imply otherwise.=20 Cheers, Olen -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Monday, November 19, 2012 8:19 PM To: Olen Stokes Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi Olen, Thanks for the comments. See responses below. On Sun, Nov 18, 2012 at 12:27 PM, Olen Stokes = wrote: > > Comparing the -01 and the -02 versions of this draft shows some very=20 > important changes. I agree. > I understand the desire to finalize this draft. > However, I am concerned that the changes in the -02 version may have=20 > created some inconsistencies in the document. There may also be=20 > opportunities to more clearly state some of the implications of the=20 > changes. I don't think there are any inconsistencies. However, it is certainly possi= ble that some clarifications and/or editorial changes would improve the dra= ft. > Section 1.1 still defines a FGL RBridge as a "TRILL switch that=20 > support[s] both FGL and VL". However, Section 9 states, "no TRILL=20 > data frames can be exchanged between VL and FGL RBridges". It would=20 > be helpful to better describe scenarios where a FGL RBridge needs to=20 > support a VL mode of operation if a FGL RBridge cannot exchange=20 > packets with a VL RBridge. Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and support VL= AN Labeling (VL) as the inner data label. In other words, an FGL RBridge mu= st be able to ingress a native frame to an FGL TRILL data frame, handle an = FGL TRILL data frame as a transit switch, and egress an FGL TRILL data fram= e to a native frame. In addition, an FGL RBridge must be able to ingress a = native frame to a VL TRILL data frame, handle a VL TRILL data frame as a tr= ansit switch, and egress a VL TRILL data frame as a native frame, all this = VL stuff as described in the TRILL base protocol RFC 6325. So an FGL RBridge can safely handle VL data traffic. But if you give an FGL= data frame to a VL RBridge, it is very likely to be mishandled. This problem with VL RBridges, which by definition are FGL ignorant, is the= reason for not allowing TRILL data traffic between FGL and VL RBridges. > Section 3 states that the default port configuration for a FGL RBridge=20 > port is VL. A scenario where this is utilized would also be helpful. Here are three uses that come to mine immediately: - If you are upgrading a campus from VL to FGL RBridges, it might be some time, if ever, before you configured connectivity between all end stations to make use of FGL. In the mean time, you would want VL to continue working. - It would be possible to standardize data connection between VL and FGL RBridges if it was specified how to do multi-topology. You could then have one topology with just FGL RBridges and a second topology with all RBridges. As long as FGL frames were limited to the FGL topology and that topology was fully connected, all would be well. Requiring FGL RBridges to support VL maintains this as a future possibility by merely adding multi-topology. Otherwise you would have to both add multi-topology and retro-fit VL support. - Due to the way TRILL works, it appears that it will be desirable to have a maintenance VLAN in which all RBridges in a campus indicate interest (see, for example, draft-ietf-trill-oam-framework). You could, I suppose, have a maintenance FGL but it might as well work the same way for a VL campus as for an FGL campus. > Otherwise, if a FGL RBridge does not have to support a VL mode of=20 > operation, a specific statement to that effect would be appropriate. The current FGL draft, just like all previous versions of the FGL WG and pr= eceeding personal draft, does require support of VL by FGL RBridges. Since = you specifically talk about -01 to -02 changes, you might not it is not a c= hange that just appeared in the current version. > Section 7, Item 2, only discusses "Silicon Considerations" from an=20 > ingress/egress point of view. It does not discuss it from a transit=20 > RBridge perspective. Good point, transit processing should be mentioned briefly in Section 7, It= em 2. However, the items in Section 7 are parallel with the same number ite= ms in Section 2.1 and are just intended to discuss the extent to which the = goals in 2.1 are met, not to be a complete discussion or summary of the nam= ed topics... Perhpas "Silicon Considerations" should be replaced with "Sili= con Goal". > However, there appears to be several statements in the draft that=20 > could have important effects on how existing silicon could be used for=20 > transit FGL RBridge operation. Section 5.1 states: > > "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination=20 > TRILL Data frame to the relevant egress TRILL switches after=20 > encapsulating it as a TRILL known unicast data frame (M=3D0)". > > This would appear to allow silicon that can TRILL forward unicast FGL=20 > packets to operate as a TRILL transit FGL node regardless of whether=20 > it can TRILL forward FGL multi-destination packets. If that is the=20 > intent, it would be helpful to state that in Section 7, Item 2. Your statement seems a odd to me. I don't understand what you mean when yo= u say "regardless of whether it can TRILL forward FGL multi-destination pac= kets". If it can't do that, I don't think it is an FGL RBridge. An FGL RBridge is required to be able to forward known unicast data that is= TRILL unicast (M=3D0), multi-destination data that is TRILL multicast (M= =3D1), and, due to the text you quote, multi-destination data that is TRILL= unicast (M=3D0). Since your specifically talk about -01 to -02 changes, you might note that this has been required in all previ= ous versions of the FGL WG draft and preceeding personal draft. It is not a change that just appeared in the current -02 version. > Section 5.2.2 states: > > "Pruning is an optimization. If a transit TRILL switch does less=20 > pruning than it could, there may be greater link utilization than=20 > strictly necessary but the campus will still operate correctly." > > This would appear to allow silicon that can TRILL forward FGL=20 > multi-destination packets to operate as a TRILL transit FGL node=20 > regardless of whether it can prune FGL packets. If that is the=20 > intent, it would be helpful to state that in Section 7, Item 2. Pruning is a SHOULD in the base TRILL protocol standard and it is the same = here. The provisions here are similar to those in the base standard for VL = pruning. I don't see any problem adding something to clarify although I don= 't think Section 7, Item 2, is the best place. How about just adding, at the end of the last sentence in Section 5.2.2, th= e following words "or not prune FGL frames at all"? > Section 5.2.2 also discusses pruning based only on the High Part or=20 > the Low Part of a FGL. A statement about silicon that can prune based=20 > only on half of a FGL would also be helpful in Section 7, Item 2. But the whole point is that, since pruning is just a SHOULD optimization, t= he silicon could prune on whatever subset of FGL bits it feels like and sti= ll be conformant. For example, it could prune on just the highest order bit= or just the highest order byte of the FGL or something. How about, includi= ng the addition above, changing "For example, a transit TRILL switch could prune based on only part of the = FGL such as only the High Part or only the Low Part." to "A transit TRILL switch could prune based on an arbitrary subset of the FGL= label bits, such as only the High Part or only the Low Part, or not prune = FGL frames at all." Actually an RBridge could adopte even more strange or exotic pruning method= s, although I can't see why it would want to. For example, it could prune b= ased on the data label value modulo some arbitrary integer divisor less tha= n the maximum label value...sort of a ridiculous thing to do but frames wou= ld still be routed correctly so I believe such behavior is allowed. 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 > Thanks for any consideration of these items. > > Cheers, > Olen > > > > On 11/6/12 3:42 PM, "Donald Eastlake" wrote: > >>Hi, >> >>As announced at the TRILL WG meeting today, this starts a two week WG=20 >>Last Call on draft-ietf-trill-fine-labeling ending 19 November. >> >>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 From tsenevir@cisco.com Mon Nov 26 07:44:38 2012 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 463EA21F85B1 for ; Mon, 26 Nov 2012 07:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aroy+lz4wkmj for ; Mon, 26 Nov 2012 07:44:37 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2D29021F859D for ; Mon, 26 Nov 2012 07:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16226; q=dns/txt; s=iport; t=1353944677; x=1355154277; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gAPDeusfK7kcyrygJevRaNN4pf4VKkkJMqi1DPLK3nc=; b=mere+sb7vClkl6SQbDlUqtuJLosBzGlpX3m3Qk7wLMYX3O1hMwK+IKSm OcGxX9Z35TppBFVwmcWsF/H4Fn06mc4SjYD68bEd7g8U+DRZpJgw68qSb iWibo1ntDblngYLoB/ejzxpYC+NGHXf9J7nxHw7bttf1eji42G7KTXXj7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPiNs1CtJXG//2dsb2JhbABEgkmDX7kFdRZzgh4BAQEEAQEBKkELEAIBBgIRBAEBCwsSBQICJQsUCQgBAQQOBQiIBQytIgiSRASMN4EOghw2YQOmRYJvgh0 X-IronPort-AV: E=McAfee;i="5400,1158,6907"; a="146011950" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 26 Nov 2012 15:44:19 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAQFiJNj025919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Nov 2012 15:44:19 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.130]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 09:44:18 -0600 From: "Tissa Senevirathne (tsenevir)" To: "liao.ting@zte.com.cn" Thread-Topic: [trill] draft-ietf-trill-cmt Thread-Index: Ac2+FF0H+VMAhVydQOe90fdycFINlgLXltQAAG52p5AAHnL5AAARf38A Date: Mon, 26 Nov 2012 15:44:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.17] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE1935628873461xmbrcdx08ciscoc_" MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:44:38 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE1935628873461xmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGluYQ0KDQpBbnN3ZXIgaXMgbm8gbmVlZCBhbmQgaXQgaXMgYWxyZWFkeSBidWlsdCBpbi4g SGVyZSBpcyB3aHkuIFdlIHByb3Bvc2UgdG8gYW5ub3VuY2UgdGhlIEFmZmluaXR5IENhcGFiaWxp dHkuICBDTVQgc3BlY2lmaWNhdGlvbiBpcyB0aGF0IFJCcmlkZ2UgYW5ub3VuY2luZyB0aGF0IGNh cGFiaWxpdHkgbXVzdCBmb2xsb3cgdGhlIHNwZWNpZmllZCB0cmVlIGFsbG9jYXRpb24uIElmIHNv bWUgUkJyaWRnZSBpcyBhbm5vdW5jaW5nIHRoZSBhZmZpbml0eSBjYXBhYmlsaXR5IGFuZCB5ZXQg ZG9pbmcgbWFudWFsIGFsbG9jYXRpb24gdGhlbiBpdCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBlcnJv ciBvciBsb2NhbCBwb2xpY3kvYWRtaW5pc3RyYXRpdmUgbWF0dGVyLg0KDQpUaGFua3MNClRpc3Nh DQoNCkZyb206IGxpYW8udGluZ0B6dGUuY29tLmNuIFttYWlsdG86bGlhby50aW5nQHp0ZS5jb20u Y25dDQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDI1LCAyMDEyIDU6MTkgUE0NClRvOiBUaXNzYSBT ZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHRyaWxsQGlldGYub3JnOyB0cmlsbC1ib3VuY2Vz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdA0KDQoN CkhpLFRpc3NhDQoNClllc6OsdGhhdCdzIGV4YWN0bHkgd2hhdCBJIG1lYW4uIDopDQpTaG91bGQg dGhlIENNVCB0YWtlIHRoaXMgc2NlbmFyaW8gaW50byBhY2NvdW50o78NCg0KVGhhbmtzLA0KVGlu YQ0KDQoiVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNjby5jb208 bWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbT4+DQq3orz+yMs6ICB0cmlsbC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPg0KDQoyMDEyLTExLTI2IDAwOjUwDQoN CsrVvP7Iyw0KDQoibGlhby50aW5nQHp0ZS5jb20uY248bWFpbHRvOmxpYW8udGluZ0B6dGUuY29t LmNuPiIgPGxpYW8udGluZ0B6dGUuY29tLmNuPG1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj4+ DQoNCrOty80NCg0KInRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4iIDx0cmls bEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJlOiBbdHJpbGxd IGRyYWZ0LWlldGYtdHJpbGwtY210DQoNCg0KDQoNCg0KDQoNCkhpIFRpbmENCg0KSSBhbSBub3Qg c3VyZSBJIGNvbXBsZXRlbHkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uLiBBcmUgeW91IHJlZmVy cmluZyB0byBhIHNjZW5hcmlvIHdoZXJlIHNvbWUgb2YgdGhlIG1lbWJlcnMgKGUuZy4gUkIxICkg YXJlIHVzaW5nIHNvbWUgbWFudWFsIGNvbmZpZ3VyYXRpb24gYW5kIG90aGVyIGlzIHVzaW5nIHRo ZSBwcm9wb3NlZCBtZXRob2QgKGUuZy4gUkIyKSBpbiB0aGUgQ01UIGRyYWZ0ID8NCg0KUFM6IEJv dGggUkIxIGFuZCBSQjIgYXJlIG1lbWJlcnMgb2YgdGhlIHZpcnR1YWwgUkJyaWRnZSBSQnYNCg0K RnJvbTogbGlhby50aW5nQHp0ZS5jb20uY248bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPiBb bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIy LCAyMDEyIDEwOjA1IFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiB0 cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyB0cmlsbC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmlsbF0g ZHJhZnQtaWV0Zi10cmlsbC1jbXQNCg0KDQpIaSxUaXNzYQ0KDQpTZWN0aW9uIDUuMSBwcm92aWRl cyBhIHNpbXBsZSBnZW5lcmFsIG1ldGhvZCB0byBhc3NpZ24gZGlmZmVyZW50IHRyZWVzIHRvIGRp ZmZlcmVudCBtZW1iZXJzIGFuZCBpdCBpcyBlYXN5IHRvIGVtcGxveS4NCkJ1dCBpbiBteSBvcGlu aW9uLCBpdCBjb3VsZCBiZSBiZXR0ZXIgdG8gYWxsb3cgY28tZXhpc3RlbmNlIG9mIGRlZmF1bHQg bWFubmVyo6hjbXSjqSBhbmQgbWFudWFsIGNvbmZpZ3VyYXRpb24NCmZvciBkaXN0cmlidXRpb24g dHJlZSBjaG9vc2luZ6Osb3RoZXJ3aXNlIGlmIHNvbWUgbWVtYmVyIFJCcyBhcmUgbWFudWFsbHkg Y29uZmlndXJlZCBhbmQgb3RoZXJzIGFyZSBub3QgY29uZmlndXJlZCBhdCBhbGwsDQpjb21wYXRp YmlsaXR5IHByb2JsZW0gd2l0aCB0aGUgY3VycmVudCBhbGdvcml0aG0gY291bGQgb2NjdXIuDQpT bywgbWF5YmUgd2Ugc2hvdWxkIHByb3ZpZGUgYSB1bmlmaWVkIHRyZWUgZGlzdHJpYnV0aW9uIG1l dGhvZCB3aGljaCBpcyBjb21wYXRpYmxlDQp3aXRoIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBj YW4gZW5zdXJlIGRpZmZlcmVudCBtZW1iZXIgUkJzIG9idGFpbiBkaWZmZXJlbnQgIGRpc3RyaWJ1 dGlvbiB0cmVlPw0KDQpUaGFua3MsDQpUaW5hIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnPG1h aWx0bzp0cmlsbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJpbGwNCg== --_000_FBEA3E19AA24F847BA3AE74E2FE1935628873461xmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Tina=

 <= /p>

Answer is no need and it = is already built in. Here is why. We propose to announce the Affinity Capab= ility.  CMT specification is that RBridge announcing that capability must follow the specified tree allocation. If some RBridge is a= nnouncing the affinity capability and yet doing manual allocation then it i= s an implementation error or local policy/administrative matter.=

 <= /p>

Thanks<= /p>

Tissa

 <= /p>

From: liao.tin= g@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Sunday, November 25, 2012 5:19 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt

 


Hi,Tissa

Yes=A3=AC= that's exactly what I mean. :)
Should the CMT take this scenario into account=A3=BF

Thanks,
Tina

"Tissa Senevirathne (tsenevir)&quo= t; <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf= .org

2012-11-26 00:50

=CA=D5=BC=FE=C8=CB<= /p>

"liao.ting@zte.com.cn" <liao.ting@zte.com.cn>

=B3=AD=CB=CD

"tr= ill@ietf.org" <trill@ietf.org= >

=D6=F7=CC=E2

Re: [trill] draft-ietf-trill-cmt

 




Hi Tina
 
I am not sure I completely understand your quest= ion. Are you referring to a scenario where some of the members (e.g. RB1 ) = are using some manual configuration and other is using the proposed method (e.g. RB2) in the CMT draft ?
 
PS: Both RB1 and RB2 are members of the virtual = RBridge RBv
 
From: liao.ting@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt
 =

Hi,Tissa

Section 5.1 provides a simple general method to assign different trees to d= ifferent members and it is easy to employ.
But in my opinion, it could be better to allow co-existence of default mann= er=A3=A8cmt=A3=A9 and manual configuration
for distribution tree choosing=A3=ACotherwise if some member RBs are manually= configured and others are not configured at all,
compatibility problem with the current algorithm could occur.
So, maybe we should provide a unified tree distribution method which is com= patible
with manual configuration and can ensure different member RBs obtain differ= ent  distribution tree?

Thanks,
Tina _________________________= ______________________
trill mailing list
trill@ietf.org
https://www.iet= f.org/mailman/listinfo/trill

--_000_FBEA3E19AA24F847BA3AE74E2FE1935628873461xmbrcdx08ciscoc_-- From liao.ting@zte.com.cn Tue Nov 27 01:22:21 2012 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 5DC2D21F84E4; Tue, 27 Nov 2012 01:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.574 X-Spam-Level: X-Spam-Status: No, score=-96.574 tagged_above=-999 required=5 tests=[AWL=1.821, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC2kVthvad+s; Tue, 27 Nov 2012 01:22:06 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DB74921F8548; Tue, 27 Nov 2012 01:22:03 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id ECD641288087; Tue, 27 Nov 2012 17:23:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qAR9Lj6c008992; Tue, 27 Nov 2012 17:21:45 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) In-Reply-To: To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-KeepSent: 0A26078A:F80E1226-48257AC3:000788BA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liao.ting@zte.com.cn Date: Tue, 27 Nov 2012 17:21:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-27 17:21:34, Serialize complete at 2012-11-27 17:21:34 Content-Type: multipart/alternative; boundary="=_alternative 00336FA948257AC3_=" X-MAIL: mse02.zte.com.cn qAR9Lj6c008992 Cc: trill-bounces@ietf.org, "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 09:22:22 -0000 This is a multipart message in MIME format. --=_alternative 00336FA948257AC3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksVGlzc2ENCg0KTWF5YmUgdGhlIENNVCBpcyBqdXN0IHRvIGFubm91bmNlIHRoZSBBZmZpbml0 eSBDYXBhYmlsaXR5LCBJTU8sIHRoZSBDTVQgaXMgDQp1c2VkIHRvIHNvbHZlIHRoZSB0cmVlIGFs bG9jYXRpb24gcHJvYmxlbSBpbiBSQnYuDQpTdWNoIGFzIHRoZSBmaWd1cmUgZGVzY3JpYmVkIGlu IFJGQzYzMjUgUDkzIGZvciBleGFtcGxlOiB0aGUgbmV0d29yayANCm1hbmFnZXIgbWF5IGJlIHdh bnQgdG8gZG8gc29tZSBtYW51YWwgY29uZmlndXJhdGlvbiBpbiB0aGUgc2l0dWF0aW9uLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHxSQnl8LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLSsgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8g IHwgIFwgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgfCAg ICBcICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgICB8ICAgICAg XCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICArLS0tKyAgICstLS0r ICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICB8UkIxfC0tLXxSQjJ8LS0tfFJCM3wgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICstLS0rICAgKy0tLSsgICArLS0tK1wgICAgICB8 DQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICBcICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICArLS0tKyAgICstLS0rICAgKy0tLSsgICAgXCstLS0rDQogICAg ICAgICAgICAgICAgICAgICAgfFJCNHwtLS18UkI1fC0tLXxSQjZ8LS0tLS18UkJ6fA0KICAgICAg ICAgICAgICAgICAgICAgICstLS0rICAgKy0tLSsgICArLS0tKyAgICAvKy0tLSsNCiAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgIC8NCiAgICAgICAgICAgICAgICAg ICAgICArLS0tKyAgICstLS0rICAgKy0tLSsvDQogICAgICAgICAgICAgICAgICAgICAgfFJCN3wt LS18UkI4fC0tLXxSQjl8DQogICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICArLS0tKyAgICst LS0rDQpUaGVyZSBhcmUgdHdvIGRpc3RyaWJ1dGlvbiB0cmVlcyBpbiB0aGUgbmV0d29yaywgb25l IHJvb3RlZCBhdCBSQnkgd2lsbCANCnByZWRvbWluYW50bHkgdXNlIHRoZSB2ZXJ0aWNhbCBsaW5r cyBhbW9uZyBSQjEgdGhyb3VnaCBSQjkgDQp3aGlsZSBhbm90aGVyIHJvb3RlZCBhdCBSQnogd2ls bCBwcmVkb21pbmFudGx5IHVzZSB0aGUgaG9yaXpvbnRhbC4NClJCMVxSQjRcUkI3XFJCOFxSQjkg YXJlIGFsbCBlZGdlIFJCcywgYnkgZGVmYXVsdCwgZWFjaCB3aWxsIGNob29zZSB0aGUgDQpzaG9y dGVzdCBwYXRooa9zIHRyZWUgcm9vdCB0byB1c2UsDQphbmQgZWFjaCBtYXkgdXNlIHRoZSB0d28g dHJlZXMgdG8gbXVsdGlwYXRoaW5nIG11bHRpLWRlc3RpbmF0aW9uIHRyYWZmaWMgDQphdCB0aGUg c2FtZSB0aW1lLiANCkJ1dCBpZiB3ZSBoYXZlIFJCMSBhbmQgUkI3IGluIGEgUkJ2LCB0aGVuIHdl IGhhdmUgdG8gYWxsb2NhdGUgZGlmZmVyZW50IA0KdHJlZXMgYmV0d2VlbiBSQjEgYW5kIFJCNy4N CldpdGggdGhlIGN1cnJlbnQgQ01UIG1hbm5lciwgbWF5YmUgUkJ6IGlzIGFsbG9jYXRlZCB0byBS QjEsIFJCeSBpcyANCmFsbG9jYXRlZCB0byBSQjcuDQpPYnZpb3VzbHksUkIxIGlzIGNsb3NlciB0 byBSQnksIHNvIHRoZSBuZXR3b3JrIG1hbmFnZXIgbWF5IHdhbnQgdG8gDQptYW51YWxseSBjb25m aWd1cmUgUkJ5IHRvIFJCMSBhcyBhbiBhbGdvcml0aG0gaW50ZXJ2ZW50aW9uLg0KDQpBcyB0aGUg bG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlIG1hdHRlciwgaG93IHRvIGNvbXBhdGlibGUgd2l0 aCBtYW51YWwgDQpjb25maWd1cmF0aW9uLCBtYXliZSBpdCBpcyBhIHF1ZXN0aW9uIHdpdGhpbiB0 aGUgUkJ2J3MgdHJlZSBhbGxvY2F0aW9uPw0KDQpJIHRoaW5rIHRoaXMgbWF5IGJlIHNvbHZlZCBi eSBjaG9vc2luZyBhIG1lbWJlciBSQiwgd2hpY2ggaXMgdXNlZCB0byANCmNvbGxlY3QgY29uZmln dXJhdGlvbiBpbmZvcm1hdGlvbiBvZiBSQnYsDQphbmQgZXhlY3V0ZSBhbiB1bmlmaWVkIGFsZ29y aXRobSB0byBhbGxvY2F0ZSB0cmVlcyBmb3IgYWxsIG1lbWJlcnMgd2l0aGluIA0KdGhlIHNhbWUg UkJ2LiANClRoZXJlIGFyZSB0d28gYmVuZWZpdHMgYnkgZG9pbmcgc286IGZpcnN0LCBpdCBpcyBj b21wYXRpYmxlLCBzZWNvbmQgdGhlcmUgDQppcyBubyBuZWVkIGZvciBhbGwgb3RoZXIgbWVtYmVy IFJCcyB0byBleGVjdXRlIHRoZSBhbGdvcml0aG0uDQoNClRoYW5rcywNClRpbmENCg0KDQoNCg0K IlRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPiANCrei vP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTItMTEtMjYgMjM6NDQNCg0KytW8/sjL DQoibGlhby50aW5nQHp0ZS5jb20uY24iIDxsaWFvLnRpbmdAenRlLmNvbS5jbj4NCrOty80NCiJ0 cmlsbEBpZXRmLm9yZyIgPHRyaWxsQGlldGYub3JnPg0K1vfM4g0KUmU6IFt0cmlsbF0gZHJhZnQt aWV0Zi10cmlsbC1jbXQNCg0KDQoNCg0KDQoNCkhpIFRpbmENCiANCkFuc3dlciBpcyBubyBuZWVk IGFuZCBpdCBpcyBhbHJlYWR5IGJ1aWx0IGluLiBIZXJlIGlzIHdoeS4gV2UgcHJvcG9zZSB0byAN CmFubm91bmNlIHRoZSBBZmZpbml0eSBDYXBhYmlsaXR5LiAgQ01UIHNwZWNpZmljYXRpb24gaXMg dGhhdCBSQnJpZGdlIA0KYW5ub3VuY2luZyB0aGF0IGNhcGFiaWxpdHkgbXVzdCBmb2xsb3cgdGhl IHNwZWNpZmllZCB0cmVlIGFsbG9jYXRpb24uIElmIA0Kc29tZSBSQnJpZGdlIGlzIGFubm91bmNp bmcgdGhlIGFmZmluaXR5IGNhcGFiaWxpdHkgYW5kIHlldCBkb2luZyBtYW51YWwgDQphbGxvY2F0 aW9uIHRoZW4gaXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZXJyb3Igb3IgbG9jYWwgDQpwb2xpY3kv YWRtaW5pc3RyYXRpdmUgbWF0dGVyLg0KIA0KVGhhbmtzDQpUaXNzYQ0KIA0KRnJvbTogbGlhby50 aW5nQHp0ZS5jb20uY24gW21haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbl0gDQpTZW50OiBTdW5k YXksIE5vdmVtYmVyIDI1LCAyMDEyIDU6MTkgUE0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKQ0KQ2M6IHRyaWxsQGlldGYub3JnOyB0cmlsbC1ib3VuY2VzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdA0KIA0KDQpIaSxUaXNzYSANCg0K WWVzo6x0aGF0J3MgZXhhY3RseSB3aGF0IEkgbWVhbi4gOikgDQpTaG91bGQgdGhlIENNVCB0YWtl IHRoaXMgc2NlbmFyaW8gaW50byBhY2NvdW50o78gDQoNClRoYW5rcywNClRpbmEgDQoNCg0KIlRp c3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPiANCreivP7I yzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEyLTExLTI2IDAwOjUwIA0KDQoNCsrVvP7I yw0KImxpYW8udGluZ0B6dGUuY29tLmNuIiA8bGlhby50aW5nQHp0ZS5jb20uY24+IA0Ks63LzQ0K InRyaWxsQGlldGYub3JnIiA8dHJpbGxAaWV0Zi5vcmc+IA0K1vfM4g0KUmU6IFt0cmlsbF0gZHJh ZnQtaWV0Zi10cmlsbC1jbXQNCiANCg0KDQoNCg0KDQoNCg0KDQpIaSBUaW5hIA0KICANCkkgYW0g bm90IHN1cmUgSSBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gQXJlIHlvdSBy ZWZlcnJpbmcgdG8gDQphIHNjZW5hcmlvIHdoZXJlIHNvbWUgb2YgdGhlIG1lbWJlcnMgKGUuZy4g UkIxICkgYXJlIHVzaW5nIHNvbWUgbWFudWFsIA0KY29uZmlndXJhdGlvbiBhbmQgb3RoZXIgaXMg dXNpbmcgdGhlIHByb3Bvc2VkIG1ldGhvZCAoZS5nLiBSQjIpIGluIHRoZSBDTVQgDQpkcmFmdCA/ IA0KICANClBTOiBCb3RoIFJCMSBhbmQgUkIyIGFyZSBtZW1iZXJzIG9mIHRoZSB2aXJ0dWFsIFJC cmlkZ2UgUkJ2IA0KICANCkZyb206IGxpYW8udGluZ0B6dGUuY29tLmNuIFttYWlsdG86bGlhby50 aW5nQHp0ZS5jb20uY25dIA0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIyLCAyMDEyIDEwOjA1 IFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiB0cmlsbEBpZXRmLm9y ZzsgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmlsbF0gZHJhZnQtaWV0 Zi10cmlsbC1jbXQgDQogIA0KDQpIaSxUaXNzYSANCg0KU2VjdGlvbiA1LjEgcHJvdmlkZXMgYSBz aW1wbGUgZ2VuZXJhbCBtZXRob2QgdG8gYXNzaWduIGRpZmZlcmVudCB0cmVlcyB0byANCmRpZmZl cmVudCBtZW1iZXJzIGFuZCBpdCBpcyBlYXN5IHRvIGVtcGxveS4gDQpCdXQgaW4gbXkgb3Bpbmlv biwgaXQgY291bGQgYmUgYmV0dGVyIHRvIGFsbG93IGNvLWV4aXN0ZW5jZSBvZiBkZWZhdWx0IA0K bWFubmVyo6hjbXSjqSBhbmQgbWFudWFsIGNvbmZpZ3VyYXRpb24gDQpmb3IgZGlzdHJpYnV0aW9u IHRyZWUgY2hvb3NpbmejrG90aGVyd2lzZSBpZiBzb21lIG1lbWJlciBSQnMgYXJlIG1hbnVhbGx5 IA0KY29uZmlndXJlZCBhbmQgb3RoZXJzIGFyZSBub3QgY29uZmlndXJlZCBhdCBhbGwsIA0KY29t cGF0aWJpbGl0eSBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgYWxnb3JpdGhtIGNvdWxkIG9jY3Vy LiANClNvLCBtYXliZSB3ZSBzaG91bGQgcHJvdmlkZSBhIHVuaWZpZWQgdHJlZSBkaXN0cmlidXRp b24gbWV0aG9kIHdoaWNoIGlzIA0KY29tcGF0aWJsZSANCndpdGggbWFudWFsIGNvbmZpZ3VyYXRp b24gYW5kIGNhbiBlbnN1cmUgZGlmZmVyZW50IG1lbWJlciBSQnMgb2J0YWluIA0KZGlmZmVyZW50 ICBkaXN0cmlidXRpb24gdHJlZT8gDQoNClRoYW5rcywNClRpbmEgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWls aW5nIGxpc3QNCnRyaWxsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyaWxsDQoNCg0K --=_alternative 00336FA948257AC3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLFRpc3NhPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mj5NYXliZSB0aGUgQ01UIGlzIGp1c3QgdG8gYW5ub3VuY2UgdGhl IEFmZmluaXR5IENhcGFiaWxpdHksDQpJTU8sIHRoZSBDTVQgaXMgdXNlZCB0byBzb2x2ZSB0aGUg dHJlZSBhbGxvY2F0aW9uIHByb2JsZW0gaW4gUkJ2LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ U3VjaCBhcyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBmaWd1cmUN CmRlc2NyaWJlZCBpbiBSRkM2MzI1IFA5MyBmb3IgZXhhbXBsZTo8L2ZvbnQ+PGZvbnQgc2l6ZT0y PiB0aGUgbmV0d29yayBtYW5hZ2VyDQptYXkgYmUgd2FudCB0byBkbyBzb21lIG1hbnVhbCBjb25m aWd1cmF0aW9uIGluIHRoZSBzaXR1YXRpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgKy0tLSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8UkJ5fC0tLS0t LS0tLS0tLS0tLSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tKyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7fA0KJm5ic3A7XCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOy8gJm5ic3A7ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDtcICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZu YnNwOyAmbmJzcDt8DQombmJzcDsgJm5ic3A7ICZuYnNwO1wgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstLS0rICZuYnNwOyArLS0tKyAmbmJzcDsgKy0tLSsgJm5i c3A7DQombmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHxSQjF8LS0tfFJCMnwtLS18UkIzfCAmbmJzcDsg Jm5ic3A7DQombmJzcDsgfDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyArLS0tK1wg Jm5ic3A7DQombmJzcDsgJm5ic3A7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7XCAmbmJzcDsgJm5ic3A7 fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyArLS0tKyAmbmJzcDsNCiZuYnNwO1wr LS0tKzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfFJCNHwtLS18UkI1fC0tLXxSQjZ8LS0tLS18UkJ6fDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLSsg Jm5ic3A7ICstLS0rICZuYnNwOyArLS0tKyAmbmJzcDsNCiZuYnNwOy8rLS0tKzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7LzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyArLS0tKy88L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHxSQjd8LS0tfFJCOHwtLS18UkI5fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyAr LS0tKzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlcmUgYXJl IHR3byBkaXN0cmlidXRpb24gdHJlZXMgaW4NCnRoZSBuZXR3b3JrLCBvbmUgcm9vdGVkIGF0IFJC eSB3aWxsIHByZWRvbWluYW50bHkgdXNlIHRoZSB2ZXJ0aWNhbCBsaW5rcw0KYW1vbmcgUkIxIHRo cm91Z2ggUkI5IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+d2hp bGUgYW5vdGhlciByb290ZWQgYXQgUkJ6IHdpbGwgcHJlZG9taW5hbnRseQ0KdXNlIHRoZSBob3Jp em9udGFsLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UkIxXFJC NFxSQjdcUkI4XFJCOSBhcmUgYWxsIGVkZ2UgUkJzLA0KYnkgZGVmYXVsdCwgZWFjaCB3aWxsIGNo b29zZSB0aGUgc2hvcnRlc3QgcGF0aKGvcyB0cmVlIHJvb3QgdG8gdXNlLDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW5kIGVhY2ggbWF5IHVzZSB0aGUgdHdvIHRy ZWVzIHRvIG11bHRpcGF0aGluZw0KbXVsdGktZGVzdGluYXRpb24gdHJhZmZpYyBhdCB0aGUgc2Ft ZSB0aW1lLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkJ1dCBpZiB3ZSBoYXZlIFJCMSBhbmQgUkI3IGluIGEgUkJ2LA0KdGhlbiB3ZSBoYXZlIHRvIGFs bG9jYXRlIGRpZmZlcmVudCB0cmVlcyBiZXR3ZWVuIFJCMSBhbmQgUkI3LjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2l0aCB0aGUgY3VycmVudCBDTVQgbWFubmVy LCBtYXliZSBSQnoNCmlzIGFsbG9jYXRlZCB0byBSQjEsIFJCeSBpcyBhbGxvY2F0ZWQgdG8gUkI3 LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+T2J2aW91c2x5LFJC MSBpcyBjbG9zZXIgdG8gUkJ5LDwvZm9udD48Zm9udCBzaXplPTI+DQpzbyB0aGUgbmV0d29yayBt YW5hZ2VyIG1heSB3YW50IHRvPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4N Cm1hbnVhbGx5IGNvbmZpZ3VyZSBSQnkgdG8gUkIxIGFzIGFuIGFsZ29yaXRobSBpbnRlcnZlbnRp b24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BcyB0 aGUgbG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlIG1hdHRlciwNCjwvZm9udD48Zm9udCBzaXpl PTI+aG93IHRvIGNvbXBhdGlibGUgd2l0aCBtYW51YWwgY29uZmlndXJhdGlvbiwgbWF5YmUNCml0 IGlzIGEgcXVlc3Rpb24gd2l0aGluIHRoZSBSQnYncyB0cmVlIGFsbG9jYXRpb24/PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9Mj5JIHRoaW5rIHRoaXMgbWF5IGJlIHNvbHZlZCBieSBjaG9v c2luZyBhIG1lbWJlciBSQiwgd2hpY2gNCmlzIHVzZWQgdG8gY29sbGVjdCBjb25maWd1cmF0aW9u IGluZm9ybWF0aW9uIG9mIFJCdiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPmFuZCBleGVjdXRl IGFuIHVuaWZpZWQgYWxnb3JpdGhtIHRvIGFsbG9jYXRlIHRyZWVzIGZvcg0KYWxsIG1lbWJlcnMg d2l0aGluIHRoZSBzYW1lIFJCdi4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5UaGVyZSBhcmUg dHdvIGJlbmVmaXRzIGJ5IGRvaW5nIHNvOiBmaXJzdCwgaXQgaXMgY29tcGF0aWJsZSwNCnNlY29u ZCB0aGVyZSBpcyBubyBuZWVkIGZvciBhbGwgb3RoZXIgbWVtYmVyIFJCcyB0byBleGVjdXRlIHRo ZSBhbGdvcml0aG0uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQpUaGFua3MsPGJyPg0KVGluYTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUNCih0c2Vu ZXZpcikmcXVvdDsgJmx0O3RzZW5ldmlyQGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDt0cmlsbC1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTIt MTEtMjYgMjM6NDQ8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7bGlhby50aW5nQHp0ZS5jb20uY24mcXVvdDsgJmx0O2xpYW8udGlu Z0B6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7dHJpbGxAaWV0Zi5vcmcm cXVvdDsgJmx0O3RyaWxsQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmls bF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5IaSBUaW5h PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij5BbnN3ZXIgaXMgbm8gbmVlZCBhbmQgaXQNCmlzIGFscmVhZHkgYnVpbHQgaW4uIEhlcmUgaXMg d2h5LiBXZSBwcm9wb3NlIHRvIGFubm91bmNlIHRoZSBBZmZpbml0eSBDYXBhYmlsaXR5Lg0KJm5i c3A7Q01UIHNwZWNpZmljYXRpb24gaXMgdGhhdCBSQnJpZGdlIGFubm91bmNpbmcgdGhhdCBjYXBh YmlsaXR5IG11c3QNCmZvbGxvdyB0aGUgc3BlY2lmaWVkIHRyZWUgYWxsb2NhdGlvbi4gSWYgc29t ZSBSQnJpZGdlIGlzIGFubm91bmNpbmcgdGhlDQphZmZpbml0eSBjYXBhYmlsaXR5IGFuZCB5ZXQg ZG9pbmcgbWFudWFsIGFsbG9jYXRpb24gdGhlbiBpdCBpcyBhbiBpbXBsZW1lbnRhdGlvbg0KZXJy b3Igb3IgbG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlIG1hdHRlci48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoYW5rczwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5UaXNzYTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IGxpYW8u dGluZ0B6dGUuY29tLmNuIFttYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY25dDQo8Yj48YnI+DQpT ZW50OjwvYj4gU3VuZGF5LCBOb3ZlbWJlciAyNSwgMjAxMiA1OjE5IFBNPGI+PGJyPg0KVG86PC9i PiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj4NCkNjOjwvYj4gdHJpbGxAaWV0 Zi5vcmc7IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFt0 cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCkhpLFRpc3NhPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KWWVzPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj6jrDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPnRoYXQncw0KZXhhY3RseSB3aGF0IEkgbWVhbi4gOik8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpT aG91bGQgdGhlIENNVCB0YWtlIHRoaXMgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5zY2VuYXJpbw0KaW50byBhY2NvdW50o788L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KVGluYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxi cj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD01MyU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mcXVvdDtUaXNzYSBTZW5l dmlyYXRobmUgKHRzZW5ldmlyKSZxdW90Ow0KJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86 dHNlbmV2aXJAY2lzY28uY29tPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48 Yj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZh Y2U9IkFyaWFsIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQq3orz+yMs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj46ICZuYnNw OzwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6 ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjIwMTItMTEtMjYgMDA6NTA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTQ2JT4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTIlPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250Pjwv ZGl2Pg0KPHRkIHdpZHRoPTg3JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90OzwvZm9u dD48YSBocmVmPW1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9 Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0 bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlh bCI+PHU+bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFj ZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+JnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxm b250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT50cmlsbEBpZXRmLm9yZzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7DQombHQ7PC9mb250Pjxh IGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNl PSJBcmlhbCI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9IkFyaWFsIj5SZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdDwvZm9udD48L3RhYmxl Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAl Pg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpIaSBUaW5hPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+ DQpJIGFtIG5vdCBzdXJlIEkgY29tcGxldGVseSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24uIEFy ZSB5b3UgcmVmZXJyaW5nDQp0byBhIHNjZW5hcmlvIHdoZXJlIHNvbWUgb2YgdGhlIG1lbWJlcnMg KGUuZy4gUkIxICkgYXJlIHVzaW5nIHNvbWUgbWFudWFsDQpjb25maWd1cmF0aW9uIGFuZCBvdGhl ciBpcyB1c2luZyB0aGUgcHJvcG9zZWQgbWV0aG9kIChlLmcuIFJCMikgaW4gdGhlDQpDTVQgZHJh ZnQgPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KUFM6IEJvdGggUkIxIGFuZCBSQjIgYXJlIG1lbWJl cnMgb2YgdGhlIHZpcnR1YWwgUkJyaWRnZSBSQnY8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpGcm9tOjwvYj4gPC9mb250 PjxhIGhyZWY9bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IlRhaG9tYSI+PHU+bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bGlhby50 aW5nQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5t YWlsdG86bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFj ZT0iVGFob21hIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDIyLCAy MDEyIDEwOjA1IFBNPGI+PGJyPg0KVG86PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmly KTxiPjxicj4NCkNjOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47DQo8L2ZvbnQ+PGEgaHJlZj0i bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IlRhaG9tYSI+PHU+dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW3RyaWxsXSBk cmFmdC1pZXRmLXRyaWxsLWNtdDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQogPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQo8YnI+DQpIaSxUaXNzYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwi PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpTZWN0aW9uIDUu MSBwcm92aWRlcyBhIHNpbXBsZSBnZW5lcmFsIG1ldGhvZCB0byBhc3NpZ24gZGlmZmVyZW50IHRy ZWVzDQp0byBkaWZmZXJlbnQgbWVtYmVycyBhbmQgaXQgaXMgZWFzeSB0byBlbXBsb3kuPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQpCdXQgaW4gbXkgb3BpbmlvbiwgaXQgY291bGQgYmUgYmV0dGVyIHRvIGFsbG93 IGNvLWV4aXN0ZW5jZSBvZiBkZWZhdWx0DQptYW5uZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPqOoPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Y210PC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj6jqTwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPg0KYW5kIG1hbnVhbCBjb25maWd1cmF0aW9uIDxicj4NCmZvciBkaXN0cmlidXRp b24gdHJlZSBjaG9vc2luZzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+o6w8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5vdGhlcndpc2UNCmlmIHNvbWUgbWVtYmVy IFJCcyBhcmUgbWFudWFsbHkgY29uZmlndXJlZCBhbmQgb3RoZXJzIGFyZSBub3QgY29uZmlndXJl ZA0KYXQgYWxsLCA8YnI+DQpjb21wYXRpYmlsaXR5IHByb2JsZW0gd2l0aCB0aGUgY3VycmVudCBh bGdvcml0aG0gY291bGQgb2NjdXIuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpTbywgbWF5YmUgd2Ugc2hvdWxk IHByb3ZpZGUgYSB1bmlmaWVkIHRyZWUgZGlzdHJpYnV0aW9uIG1ldGhvZCB3aGljaCBpcw0KY29t cGF0aWJsZSA8YnI+DQp3aXRoIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBjYW4gZW5zdXJlIGRp ZmZlcmVudCBtZW1iZXIgUkJzIG9idGFpbiBkaWZmZXJlbnQNCiZuYnNwO2Rpc3RyaWJ1dGlvbiB0 cmVlPyA8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KVGluYTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iQXJpYWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGlu ZyBsaXN0PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1 Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+ DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmlsbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC91PjwvZm9udD48L2E+PHR0 Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlzdDxicj4NCnRyaWxsQGlldGYub3JnPGJyPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDxicj4NCjwvZm9udD48L3R0 Pg0KPGJyPg0K --=_alternative 00336FA948257AC3_=-- From tsenevir@cisco.com Tue Nov 27 07:34:51 2012 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 3EA3721F8B70; Tue, 27 Nov 2012 07:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8vrpkPfrhzI; Tue, 27 Nov 2012 07:34:50 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6F98321F8A78; Tue, 27 Nov 2012 07:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42074; q=dns/txt; s=iport; t=1354030489; x=1355240089; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+GdADUkpb1ZkZz/XPFpWkuglTZezBbnDS0rrW3yYKX8=; b=hGPCzc7FhrrA7K8Ja3dJ0QsYN46HOaUSfJy0BXYSP84m9uzLhLkRpshL vWsw2UR1HypzQuWkiOnKP3ml7VpLsccwnX9Q8HiKowgDCJIYwWF4FA9sy mLFSXVfSXMhNhsxnQ9AnftXAkR/YWe9gfv3ZnJ4hUydpjt/V35Nd3SqFI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMLAB/dtFCtJV2c/2dsb2JhbABEgkmDYLh7eoECB4IeAQEBBAEBASpBCxACAQYCEQQBAQsLCwEGBQICJQsUCQgCBA4FCIgFDK12CII9kEkEjDqBDoIcNmEDpkWCcIIg X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146459089" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 27 Nov 2012 15:34:47 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qARFYkNa028541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 15:34:46 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.130]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 09:34:46 -0600 From: "Tissa Senevirathne (tsenevir)" To: "liao.ting@zte.com.cn" Thread-Topic: [trill] draft-ietf-trill-cmt Thread-Index: Ac2+FF0H+VMAhVydQOe90fdycFINlgLXltQAAG52p5AAHnL5AAARf38AADGjD4AAACHO8A== Date: Tue, 27 Nov 2012 15:34:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.93.226] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE1935628875C0Fxmbrcdx08ciscoc_" MIME-Version: 1.0 Cc: "trill-bounces@ietf.org" , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:34:51 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE1935628875C0Fxmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGluYQ0KDQpXaGF0IHlvdSBhcmUgbG9va2luZyBhdCBpcyBhIGxvY2FsIGFkbWluaXN0cmF0 aXZlIHBvbGljeSwgSSBhbSBub3QgY2xlYXIgd2hhdCB0byBiZSBzcGVjaWZpZWQgaW4gYSBzdGFu ZGFyZC4gQWRkaXRpb25hbGx5IG1hbnVhbCBjb25maWd1cmF0aW9ucyBkb2VzIG5vdCBwcm92aWRl IGZhaWxvdmVyIHByb3RlY3Rpb24uIEkgdGhpbmsgaXQgaXMgYmVzdCB0byBsZWF2ZSB0aGUgYWRt aW5pc3RyYXRpdmUgcG9saWNpZXMgdG8gcGxhdGZvcm1zLg0KDQpBZGRpdGlvbmFsbHksIHdoZW4g bXVsdGlwbGUgdHJlZSBhbGxvY2F0aW9uIGFsZ29yaXRobXMgYXJlIHByZXNlbnQsIHdlIG5lZWQg dG8gZW5zdXJlIHRoYXQgYWxsIG9mIHRoZSBSQnYgYXJlIHVzaW5nIHRoZSBleGFjdCBzYW1lIGFs Z29yaXRobSwgd2hpY2ggd2lsbCBtYWtlIG1hdHRlcnMgY29tcGxpY2F0ZWQuIFNvIGluIHNob3J0 LCBpZiBvbmUgd291bGQgbGlrZSB0byB1c2UgYSBkaWZmZXJlbnQgYWxnb3JpdGhtIHRoYW4gd2hh dCBpcyBzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkLCBpdCBpcyB1cCB0byB0aGVtIHRvIGRvIHNv IGFuZCBlbnN1cmUgdGhhdCB0aGV5IG1lZXQNCg0KDQoxLiAgICAgICBGYWlsb3ZlciByZXF1aXJl bWVudHMNCg0KMi4gICAgICAgQWxnb3JpdGhtIGNvbnNpc3RlbmN5IGJldHdlZW4gbWVtYmVycw0K DQoNClRoYW5rcw0KVGlzc2ENCg0KDQpGcm9tOiBsaWFvLnRpbmdAenRlLmNvbS5jbiBbbWFpbHRv OmxpYW8udGluZ0B6dGUuY29tLmNuXQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjcsIDIwMTIg MToyMiBBTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogdHJpbGxAaWV0 Zi5vcmc7IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJpbGxdIGRyYWZ0 LWlldGYtdHJpbGwtY210DQoNCg0KSGksVGlzc2ENCg0KTWF5YmUgdGhlIENNVCBpcyBqdXN0IHRv IGFubm91bmNlIHRoZSBBZmZpbml0eSBDYXBhYmlsaXR5LCBJTU8sIHRoZSBDTVQgaXMgdXNlZCB0 byBzb2x2ZSB0aGUgdHJlZSBhbGxvY2F0aW9uIHByb2JsZW0gaW4gUkJ2Lg0KU3VjaCBhcyB0aGUg ZmlndXJlIGRlc2NyaWJlZCBpbiBSRkM2MzI1IFA5MyBmb3IgZXhhbXBsZTogdGhlIG5ldHdvcmsg bWFuYWdlciBtYXkgYmUgd2FudCB0byBkbyBzb21lIG1hbnVhbCBjb25maWd1cmF0aW9uIGluIHRo ZSBzaXR1YXRpb24uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfFJCeXwtLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLyAgfCAgXCAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgLyAgICB8ICAgIFwgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAg ICAgLyAgICAgIHwgICAgICBcICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICArLS0t KyAgICstLS0rICAgKy0tLSsgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgIHxSQjF8LS0t fFJCMnwtLS18UkIzfCAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICArLS0t KyAgICstLS0rXCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAg ICB8ICAgIFwgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICstLS0rICAgKy0tLSsgICArLS0t KyAgICBcKy0tLSsNCiAgICAgICAgICAgICAgICAgICAgICB8UkI0fC0tLXxSQjV8LS0tfFJCNnwt LS0tLXxSQnp8DQogICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICArLS0tKyAgICstLS0rICAg IC8rLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAgLw0K ICAgICAgICAgICAgICAgICAgICAgICstLS0rICAgKy0tLSsgICArLS0tKy8NCiAgICAgICAgICAg ICAgICAgICAgICB8UkI3fC0tLXxSQjh8LS0tfFJCOXwNCiAgICAgICAgICAgICAgICAgICAgICAr LS0tKyAgICstLS0rICAgKy0tLSsNClRoZXJlIGFyZSB0d28gZGlzdHJpYnV0aW9uIHRyZWVzIGlu IHRoZSBuZXR3b3JrLCBvbmUgcm9vdGVkIGF0IFJCeSB3aWxsIHByZWRvbWluYW50bHkgdXNlIHRo ZSB2ZXJ0aWNhbCBsaW5rcyBhbW9uZyBSQjEgdGhyb3VnaCBSQjkNCndoaWxlIGFub3RoZXIgcm9v dGVkIGF0IFJCeiB3aWxsIHByZWRvbWluYW50bHkgdXNlIHRoZSBob3Jpem9udGFsLg0KUkIxXFJC NFxSQjdcUkI4XFJCOSBhcmUgYWxsIGVkZ2UgUkJzLCBieSBkZWZhdWx0LCBlYWNoIHdpbGwgY2hv b3NlIHRoZSBzaG9ydGVzdCBwYXRooa9zIHRyZWUgcm9vdCB0byB1c2UsDQphbmQgZWFjaCBtYXkg dXNlIHRoZSB0d28gdHJlZXMgdG8gbXVsdGlwYXRoaW5nIG11bHRpLWRlc3RpbmF0aW9uIHRyYWZm aWMgYXQgdGhlIHNhbWUgdGltZS4NCkJ1dCBpZiB3ZSBoYXZlIFJCMSBhbmQgUkI3IGluIGEgUkJ2 LCB0aGVuIHdlIGhhdmUgdG8gYWxsb2NhdGUgZGlmZmVyZW50IHRyZWVzIGJldHdlZW4gUkIxIGFu ZCBSQjcuDQpXaXRoIHRoZSBjdXJyZW50IENNVCBtYW5uZXIsIG1heWJlIFJCeiBpcyBhbGxvY2F0 ZWQgdG8gUkIxLCBSQnkgaXMgYWxsb2NhdGVkIHRvIFJCNy4NCk9idmlvdXNseSxSQjEgaXMgY2xv c2VyIHRvIFJCeSwgc28gdGhlIG5ldHdvcmsgbWFuYWdlciBtYXkgd2FudCB0byBtYW51YWxseSBj b25maWd1cmUgUkJ5IHRvIFJCMSBhcyBhbiBhbGdvcml0aG0gaW50ZXJ2ZW50aW9uLg0KDQpBcyB0 aGUgbG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlIG1hdHRlciwgaG93IHRvIGNvbXBhdGlibGUg d2l0aCBtYW51YWwgY29uZmlndXJhdGlvbiwgbWF5YmUgaXQgaXMgYSBxdWVzdGlvbiB3aXRoaW4g dGhlIFJCdidzIHRyZWUgYWxsb2NhdGlvbj8NCg0KSSB0aGluayB0aGlzIG1heSBiZSBzb2x2ZWQg YnkgY2hvb3NpbmcgYSBtZW1iZXIgUkIsIHdoaWNoIGlzIHVzZWQgdG8gY29sbGVjdCBjb25maWd1 cmF0aW9uIGluZm9ybWF0aW9uIG9mIFJCdiwNCmFuZCBleGVjdXRlIGFuIHVuaWZpZWQgYWxnb3Jp dGhtIHRvIGFsbG9jYXRlIHRyZWVzIGZvciBhbGwgbWVtYmVycyB3aXRoaW4gdGhlIHNhbWUgUkJ2 Lg0KVGhlcmUgYXJlIHR3byBiZW5lZml0cyBieSBkb2luZyBzbzogZmlyc3QsIGl0IGlzIGNvbXBh dGlibGUsIHNlY29uZCB0aGVyZSBpcyBubyBuZWVkIGZvciBhbGwgb3RoZXIgbWVtYmVyIFJCcyB0 byBleGVjdXRlIHRoZSBhbGdvcml0aG0uDQoNClRoYW5rcywNClRpbmENCg0KDQoiVGlzc2EgU2Vu ZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNjby5jb208bWFpbHRvOnRzZW5ldmly QGNpc2NvLmNvbT4+DQq3orz+yMs6ICB0cmlsbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmls bC1ib3VuY2VzQGlldGYub3JnPg0KDQoyMDEyLTExLTI2IDIzOjQ0DQoNCsrVvP7Iyw0KDQoibGlh by50aW5nQHp0ZS5jb20uY248bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPiIgPGxpYW8udGlu Z0B6dGUuY29tLmNuPG1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj4+DQoNCrOty80NCg0KInRy aWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4iIDx0cmlsbEBpZXRmLm9yZzxtYWls dG86dHJpbGxAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJlOiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJp bGwtY210DQoNCg0KDQoNCg0KDQoNCkhpIFRpbmENCg0KQW5zd2VyIGlzIG5vIG5lZWQgYW5kIGl0 IGlzIGFscmVhZHkgYnVpbHQgaW4uIEhlcmUgaXMgd2h5LiBXZSBwcm9wb3NlIHRvIGFubm91bmNl IHRoZSBBZmZpbml0eSBDYXBhYmlsaXR5LiAgQ01UIHNwZWNpZmljYXRpb24gaXMgdGhhdCBSQnJp ZGdlIGFubm91bmNpbmcgdGhhdCBjYXBhYmlsaXR5IG11c3QgZm9sbG93IHRoZSBzcGVjaWZpZWQg dHJlZSBhbGxvY2F0aW9uLiBJZiBzb21lIFJCcmlkZ2UgaXMgYW5ub3VuY2luZyB0aGUgYWZmaW5p dHkgY2FwYWJpbGl0eSBhbmQgeWV0IGRvaW5nIG1hbnVhbCBhbGxvY2F0aW9uIHRoZW4gaXQgaXMg YW4gaW1wbGVtZW50YXRpb24gZXJyb3Igb3IgbG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlIG1h dHRlci4NCg0KVGhhbmtzDQpUaXNzYQ0KDQpGcm9tOiBsaWFvLnRpbmdAenRlLmNvbS5jbjxtYWls dG86bGlhby50aW5nQHp0ZS5jb20uY24+IFttYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY25dDQpT ZW50OiBTdW5kYXksIE5vdmVtYmVyIDI1LCAyMDEyIDU6MTkgUE0NClRvOiBUaXNzYSBTZW5ldmly YXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9y Zz47IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdA0KDQoNCkhpLFRpc3Nh DQoNClllc6OsdGhhdCdzIGV4YWN0bHkgd2hhdCBJIG1lYW4uIDopDQpTaG91bGQgdGhlIENNVCB0 YWtlIHRoaXMgc2NlbmFyaW8gaW50byBhY2NvdW50o78NCg0KVGhhbmtzLA0KVGluYQ0KIlRpc3Nh IFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPG1haWx0bzp0c2Vu ZXZpckBjaXNjby5jb20+Pg0Kt6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 dHJpbGwtYm91bmNlc0BpZXRmLm9yZz4NCg0KMjAxMi0xMS0yNiAwMDo1MA0KDQoNCsrVvP7Iyw0K DQoibGlhby50aW5nQHp0ZS5jb20uY248bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPiIgPGxp YW8udGluZ0B6dGUuY29tLmNuPG1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj4+DQoNCrOty80N Cg0KInRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4iIDx0cmlsbEBpZXRmLm9y ZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJlOiBbdHJpbGxdIGRyYWZ0LWll dGYtdHJpbGwtY210DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGkgVGluYQ0KDQpJIGFtIG5vdCBz dXJlIEkgY29tcGxldGVseSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24uIEFyZSB5b3UgcmVmZXJy aW5nIHRvIGEgc2NlbmFyaW8gd2hlcmUgc29tZSBvZiB0aGUgbWVtYmVycyAoZS5nLiBSQjEgKSBh cmUgdXNpbmcgc29tZSBtYW51YWwgY29uZmlndXJhdGlvbiBhbmQgb3RoZXIgaXMgdXNpbmcgdGhl IHByb3Bvc2VkIG1ldGhvZCAoZS5nLiBSQjIpIGluIHRoZSBDTVQgZHJhZnQgPw0KDQpQUzogQm90 aCBSQjEgYW5kIFJCMiBhcmUgbWVtYmVycyBvZiB0aGUgdmlydHVhbCBSQnJpZGdlIFJCdg0KDQpG cm9tOiBsaWFvLnRpbmdAenRlLmNvbS5jbjxtYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY24+IFtt YWlsdG86bGlhby50aW5nQHp0ZS5jb20uY25dDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjIs IDIwMTIgMTA6MDUgUE0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHRy aWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IHRyaWxsLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RyaWxsXSBk cmFmdC1pZXRmLXRyaWxsLWNtdA0KDQoNCkhpLFRpc3NhDQoNClNlY3Rpb24gNS4xIHByb3ZpZGVz IGEgc2ltcGxlIGdlbmVyYWwgbWV0aG9kIHRvIGFzc2lnbiBkaWZmZXJlbnQgdHJlZXMgdG8gZGlm ZmVyZW50IG1lbWJlcnMgYW5kIGl0IGlzIGVhc3kgdG8gZW1wbG95Lg0KQnV0IGluIG15IG9waW5p b24sIGl0IGNvdWxkIGJlIGJldHRlciB0byBhbGxvdyBjby1leGlzdGVuY2Ugb2YgZGVmYXVsdCBt YW5uZXKjqGNtdKOpIGFuZCBtYW51YWwgY29uZmlndXJhdGlvbg0KZm9yIGRpc3RyaWJ1dGlvbiB0 cmVlIGNob29zaW5no6xvdGhlcndpc2UgaWYgc29tZSBtZW1iZXIgUkJzIGFyZSBtYW51YWxseSBj b25maWd1cmVkIGFuZCBvdGhlcnMgYXJlIG5vdCBjb25maWd1cmVkIGF0IGFsbCwNCmNvbXBhdGli aWxpdHkgcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGFsZ29yaXRobSBjb3VsZCBvY2N1ci4NClNv LCBtYXliZSB3ZSBzaG91bGQgcHJvdmlkZSBhIHVuaWZpZWQgdHJlZSBkaXN0cmlidXRpb24gbWV0 aG9kIHdoaWNoIGlzIGNvbXBhdGlibGUNCndpdGggbWFudWFsIGNvbmZpZ3VyYXRpb24gYW5kIGNh biBlbnN1cmUgZGlmZmVyZW50IG1lbWJlciBSQnMgb2J0YWluIGRpZmZlcmVudCAgZGlzdHJpYnV0 aW9uIHRyZWU/DQoNClRoYW5rcywNClRpbmEgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmc8bWFp bHRvOnRyaWxsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmlsbF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0 cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg== --_000_FBEA3E19AA24F847BA3AE74E2FE1935628875C0Fxmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Tina=

 <= /p>

What you are looking at i= s a local administrative policy, I am not clear what to be specified in a s= tandard. Additionally manual configurations does not provide failover protection. I think it is best to leave the administrative polici= es to platforms.

 <= /p>

Additionally, when multip= le tree allocation algorithms are present, we need to ensure that all of th= e RBv are using the exact same algorithm, which will make matters complicated. So in short, if one would like to use a different alg= orithm than what is specified in the standard, it is up to them to do so an= d ensure that they meet

 <= /p>

1. = ;      Failover requirem= ents

2. = ;      Algorithm consist= ency between members

 <= /span>

Thanks<= /p>

Tissa

 <= /p>

 <= /p>

From: liao.tin= g@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Tuesday, November 27, 2012 1:22 AM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt

 


Hi,Tissa

Maybe the CMT is just to announce the Affi= nity Capability, IMO, the CMT is used to solve the tree allocation problem = in RBv.
Such as the figure descr= ibed in RFC6325 P93 for example: th= e network manager may be want to do some manual configuration in the situation.
                  &= nbsp;           +---+
                  &= nbsp;           |RBy|---------------+
                  &= nbsp;           +---+      =         |
                  &= nbsp;          /  |  \     &nb= sp;        |
                  &= nbsp;        /    |    \   &nb= sp;        |
                  &= nbsp;      /      |      \ &nb= sp;        |
                  &= nbsp;   +---+   +---+   +---+  =     |
                  &= nbsp;   |RB1|---|RB2|---|RB3|       |
                  &= nbsp;   +---+   +---+   +---+\  = ;    |
                  &= nbsp;     |       |       |   =  \    |
                  &= nbsp;   +---+   +---+   +---+  =  \+---+
                  &= nbsp;   |RB4|---|RB5|---|RB6|-----|RBz|
                  &= nbsp;   +---+   +---+   +---+  =  /+---+
                  &= nbsp;     |       |       |   =  /
                  &= nbsp;   +---+   +---+   +---+/
                  &= nbsp;   |RB7|---|RB8|---|RB9|
                  &= nbsp;   +---+   +---+   +---+
There are two distribution trees in the network, one rooted at R= By will predominantly use the vertical links among RB1 through RB9
while another rooted at RBz will predominantly use the horizonta= l.
RB1\RB4\RB7\RB8\RB9 are all edge RBs, by default, each will choo= se the shortest path=A1=AFs tree root to use,
and each may use the two trees to multipathing multi-destination= traffic at the same time.  
But if we have RB1 and RB7 in a RBv, then we have to allocate di= fferent trees between RB1 and RB7.
With the current CMT manner, maybe RBz is allocated to RB1, RBy = is allocated to RB7.
Obviously,RB1 is closer to RBy, so the network manager may want to manually confi= gure RBy to RB1 as an algorithm intervention.

As the local policy/administrative matter, how to compatible with manual confi= guration, maybe it is a question within the RBv's tree allocation?

I think this may be solved by choosing a m= ember RB, which is used to collect configuration information of RBv,
and execute an unified algorithm to alloca= te trees for all members within the same RBv.
There are two benefits by doing so: first,= it is compatible, second there is no need for all other member RBs to exec= ute the algorithm.

Thanks,
Tina


"Tissa Senevirathne (tsenevir)&quo= t; <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf= .org

2012-11-26 23:44

=CA=D5=BC=FE=C8=CB<= /p>

"liao.ting@zte.com.cn" <liao.ting@zte.com.cn>

=B3=AD=CB=CD

"tr= ill@ietf.org" <trill@ietf.org= >

=D6=F7=CC=E2

Re: [trill] draft-ietf-trill-cmt

 




Hi Tina
 
Answer is no need and it is already built in. He= re is why. We propose to announce the Affinity Capability.  CMT specif= ication is that RBridge announcing that capability must follow the specified tree allocation. If some RBridge is announcing the affinity = capability and yet doing manual allocation then it is an implementation err= or or local policy/administrative matter.
 
Thanks
Tissa
 
From: liao.ting@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Sunday, November 25, 2012 5:19 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt
 =

Hi,Tissa

Yes=A3=ACthat's exactly what I mean. :)
Should the CMT take this scenario into account=A3=BF

Thanks,
Tina

"Tissa Senevirathne (tsenevir)&quo= t; <tsenev= ir@cisco.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf.org

2012-11-26 00:50

 

=CA=D5=BC=FE=C8=CB<= /p>

"liao.ting@zte.com.cn" <liao.ting@zte= .com.cn>

=B3=AD=CB=CD

"trill@ietf.org" <trill@ietf.org>

=D6=F7=CC=E2

Re: [trill] draft-ietf-trill-cmt


 =

 





Hi Tina
 
I am not sure I completely understand your question. Are you referring to a= scenario where some of the members (e.g. RB1 ) are using some manual confi= guration and other is using the proposed method (e.g. RB2) in the CMT draft= ?
 
PS: Both RB1 and RB2 are members of the virtual RBridge RBv
 
From: liao.ting@zte.co= m.cn [mailto:liao.ting@zte.com.cn]
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org= ; trill-bounces@= ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt
 

Hi,Tissa

Section 5.1 provides a simple general method to assign different trees to d= ifferent members and it is easy to employ.
But in my opinion, it could be better to allow co-existence of default mann= er=A3=A8cmt=A3=A9 and manual configuration
for distribution tree choosing=A3=ACotherwise if some member RBs are manually= configured and others are not configured at all,
compatibility problem with the current algorithm could occur.
So, maybe we should provide a unified tree distribution method which is com= patible
with manual configuration and can ensure different member RBs obtain differ= ent  distribution tree?

Thanks,
Tina _______________________________________________
trill mailing list
trill@ietf.o= rg
https://www.ietf.org/mailman/listinfo/trill_______________________________________________
trill mailing list
trill@ietf.org
https://www.iet= f.org/mailman/listinfo/trill

--_000_FBEA3E19AA24F847BA3AE74E2FE1935628875C0Fxmbrcdx08ciscoc_-- From linda.dunbar@huawei.com Tue Nov 27 08:11:23 2012 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 1338D21F8559 for ; Tue, 27 Nov 2012 08:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CNRGbiy2iqB for ; Tue, 27 Nov 2012 08:11:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E823B21F8557 for ; Tue, 27 Nov 2012 08:11:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALY63579; Tue, 27 Nov 2012 16:11:19 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 16:11:09 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 16:11:16 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Tue, 27 Nov 2012 08:11:12 -0800 From: Linda Dunbar To: "Black, David" , "trill@ietf.org" Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt Thread-Index: AQHNyoJb9IC4oPdPSEevrN5yYyHkN5f92axA Date: Tue, 27 Nov 2012 16:11:11 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450B6042@dfweml505-mbx> References: <50A4095E.80009@acm.org> <8D3D17ACE214DC429325B2B98F3AE71284D3FF0C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284D3FF0C@MX15A.corp.emc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 16:11:23 -0000 David,=20 Thank you very much for the detailed comments. I will incorporate them in t= he next revision.=20 Some answers to your comments are inserted below: > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Saturday, November 24, 2012 2:29 PM > To: trill@ietf.org; Linda Dunbar > Subject: RE: [trill] WG Last Call: draft-ietf-trill-directory- > framework-01.txt >=20 > Hi Linda, >=20 > Here are some (somewhat tardy) comments on this WG Last Call. >=20 > (1) As noted by some of the others who commented, more functionality > details would be good to add, especially on mixing of the push and > pull models in Section 5. Cache consistency needs to be covered, > at least its invalidation portion, as relying solely on aging out > entries can black-hole traffic that uses a stale entry that hasn't > aged out yet. >=20 [Linda] This framework is mainly to cover the benefits of directory service= . I will add some high level description, however I will try not to repeat = the description in the mechanism draft which covers the details of caching = and policy of pull/push.=20 > (2) I also agree with Erik's earlier comment about not understanding > why Appointed Forwarders are in this draft. If use of a directory > can relax Appointed Forwarder restrictions without causing problems > (e.g., loops), that needs to be explained somewhere, probably in > Section 4. Otherwise, Appointed Forwarders should not be discussed. [Linda] Agree. Will change accordingly.=20 >=20 > (3) On the comment about capitalizing MUST, SHOULD and MAY, the > applicable RFC is RFC 2119, but those terms are not ordinarily used > in requirements documents. An explanation that these keywords > express requirements on protocol development should be provided in > order to use the upper case versions of these keywords. >=20 [Linda] Will change per you comments. Thanks.=20 > Here are some more detailed comments: >=20 > Abstract: > Edge RBridges currently learn the mapping between MAC addresses and > their egress RBridges by observing the data packets traversed > through. >=20 > Change to: ... by observing traffic that traverses the RBridge. >=20 > Section 1, 1st paragraph: >=20 > (This ''blocked'' state > has no effect of TRILL Data or IS-IS frames, which can still be sent > and received. It only affects native frames.) >=20 > "of TRILL data" -> "on TRILL Data" in second line above. >=20 > In item 2 in the list, I'd change "usually" to "often": > 2. Topology is usually based on racks and rows. >=20 > In item 3 in the list, explain that server reload can change the MAC > address and why that change may be needed or desirable, because > Section 4 appears to assert that the MAC address can change. If > that wasn't intended, this text in Section 4 needs attention for > physical servers (it's ok for VMs): >=20 > When a VM is moved to a new > location or a server is loaded with a new application with different > IP/MAC addresses, it is more likely that the DA of data packets sent > out from those VMs are unknown to their attached edge RBridges. >=20 > Item 4 should follow up on the mention of subnets in item 3 and > observe that multiple subnets on the same port at the same time is > common for server virtualization and the change rate is higher than > for physical servers. >=20 > In the definition of "Bridge", change "draft" to "document". >=20 > Section 3, p.6, first bullet - change both instances of "RB1" to > "an RBridge" as there's no RB1 in figure 1. >=20 > The last bullet in Section 3.1 is a bit sloppy about its use of the > word "entries". It needs to explain exactly what is in an "entry" - > it might be possible to do this in an introduction by stating that > the presence of an entry (and list what it contains) avoids flooding > of inbound frames that match the entry. >=20 > Section 3.2, Scenario #1 - The use of the word "uplink" is confusing, > overly constraining and not necessary. The important concept is how > many ToR switches are in each rack. It's quite feasible for a server > or switch in a rack to have multiple uplinks to the same ToR (e.g., > when the links are 1 Gigabit Ethernet). >=20 > Section 4, first sentence: > OLD > In data center environment, applications placement to servers, > racks, and rows is orchestrated by Server (or VM) Management > System(s). > NEW > In a data center environment, the assignment of applications > to servers, including rack and row selection, is orchestrated > by Server (or VM) Management System(s). > END >=20 > I'd suggest deleting Section 6 (Conclusion and Recommendations), > as it's important for considering what the WG will do, but may not > have much value in a published RFC. >=20 >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On > Behalf Of Erik > > Nordmark > > Sent: Wednesday, November 14, 2012 4:13 PM > > To: trill@ietf.org > > Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory- > framework-01.txt > > > > > > We would really like to she some more explicit indications from WG > > participants that they have read this document and agree with it. > > > > Please include any substantial as well as editorial improvements that > > result from reviewing the document. > > > > Erik > > > > On 10/25/12 3:55 PM, Donald Eastlake wrote: > > > This message begins a TRILL WG two week Last Call on the > > > draft-ietf-trill-directory-framework draft. > > > > > > 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 > > > _______________________________________________ > > > trill mailing list > > > trill@ietf.org > > > https://www.ietf.org/mailman/listinfo/trill > > > > > > > _______________________________________________ > > trill mailing list > > trill@ietf.org > > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Tue Nov 27 19:00:15 2012 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 0ECE721F855A for ; Tue, 27 Nov 2012 19:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEJSuA2IWhZa for ; Tue, 27 Nov 2012 19:00:14 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E996721F8557 for ; Tue, 27 Nov 2012 19:00:13 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so12986017ieb.31 for ; Tue, 27 Nov 2012 19:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=j8E9WWXHOzB9KDLEoPE96KnGVcmWqq82NuyxnJP5XjA=; b=lHrv1DFzrrDM0dWUBtCxyKyAv07HPd/Sbkctr33mFLlRytzuXOJfrefKBsgX6oHT+R TgtYwL56I5V30RbMvLuWH7zgmb1MfEEsEW5sMV5MzScrDtcjAxU6V0AdKRD+WSLzYXCU 84dd1ZzNIsW4cSSO5z7PMnK9tTJ1KQ2/MgD0lnsBHkpkfbGQ6/f+U2HMl406IazsFXwP 951fzaUamwZzSxF4BylUQKeLprC3fkmcoFJ290UnXybhXAHDqIh9tAA67KdsuS6s40lX STtWUjWAEqftZGuRhWVMzoSxqkhb9ZWYRYWEr2/jqEZKinZuudIQj54Go5vHPs2L8mkL dS8g== Received: by 10.50.194.131 with SMTP id hw3mr17319920igc.71.1354071613393; Tue, 27 Nov 2012 19:00:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Tue, 27 Nov 2012 18:59:52 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Tue, 27 Nov 2012 21:59:52 -0500 Message-ID: To: Olen Stokes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:00:15 -0000 HI Olen, On Mon, Nov 26, 2012 at 10:31 AM, Olen Stokes wrote: > Since the two emails below were written about a week ago, there has been = a lot of discussion about the RBridge capabilities required to be classifie= d as an FGL RBridge. I am still unclear about one part of the exchange bel= ow. > > There is a discussion about the implications of a TRILL ingress RBridge s= erially unicasting "a multi-destination TRILL Data frame to the relevant eg= ress TRILL switches after encapsulating it as a TRILL known unicast data fr= ame (M=3D0)". > > What is the use case envisioned when there is more than one "relevant egr= ess FGL RBridge"? We are talking about multi-destination TRILL Data frames. That is, frames where the Inner.MacDA is the broadcast address, a multicast address, or a unicast address who egress TRILL switch is unknown to the ingress TRILL switch. In such cases, all TRILL switches indicating interest in the frame's VLAN are potentially relevant although in the multicast case this should be further limited to TRILL switches where a listener for the multicast group or a multicast router is attached. 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 > FWIW, Donald noted below that this provision has been in all of the previ= ous versions. I agree. I did not mean to imply otherwise. > > Cheers, > Olen > > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Monday, November 19, 2012 8:19 PM > To: Olen Stokes > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > Hi Olen, > > Thanks for the comments. See responses below. > > On Sun, Nov 18, 2012 at 12:27 PM, Olen Stokes wrote: >> >> Comparing the -01 and the -02 versions of this draft shows some very >> important changes. > > I agree. > >> I understand the desire to finalize this draft. >> However, I am concerned that the changes in the -02 version may have >> created some inconsistencies in the document. There may also be >> opportunities to more clearly state some of the implications of the >> changes. > > I don't think there are any inconsistencies. However, it is certainly pos= sible that some clarifications and/or editorial changes would improve the d= raft. > >> Section 1.1 still defines a FGL RBridge as a "TRILL switch that >> support[s] both FGL and VL". However, Section 9 states, "no TRILL >> data frames can be exchanged between VL and FGL RBridges". It would >> be helpful to better describe scenarios where a FGL RBridge needs to >> support a VL mode of operation if a FGL RBridge cannot exchange >> packets with a VL RBridge. > > Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and support = VLAN Labeling (VL) as the inner data label. In other words, an FGL RBridge = must be able to ingress a native frame to an FGL TRILL data frame, handle a= n FGL TRILL data frame as a transit switch, and egress an FGL TRILL data fr= ame to a native frame. In addition, an FGL RBridge must be able to ingress = a native frame to a VL TRILL data frame, handle a VL TRILL data frame as a = transit switch, and egress a VL TRILL data frame as a native frame, all thi= s VL stuff as described in the TRILL base protocol RFC 6325. > > So an FGL RBridge can safely handle VL data traffic. But if you give an F= GL data frame to a VL RBridge, it is very likely to be mishandled. > This problem with VL RBridges, which by definition are FGL ignorant, is t= he reason for not allowing TRILL data traffic between FGL and VL RBridges. > >> Section 3 states that the default port configuration for a FGL RBridge >> port is VL. A scenario where this is utilized would also be helpful. > > Here are three uses that come to mine immediately: > > - If you are upgrading a campus from VL to FGL RBridges, it might be > some time, if ever, before you configured connectivity between all > end stations to make use of FGL. In the mean time, you would want VL > to continue working. > > - It would be possible to standardize data connection between VL and > FGL RBridges if it was specified how to do multi-topology. You could > then have one topology with just FGL RBridges and a second topology > with all RBridges. As long as FGL frames were limited to the FGL > topology and that topology was fully connected, all would be > well. Requiring FGL RBridges to support VL maintains this as a > future possibility by merely adding multi-topology. Otherwise you > would have to both add multi-topology and retro-fit VL support. > > - Due to the way TRILL works, it appears that it will be desirable to > have a maintenance VLAN in which all RBridges in a campus indicate > interest (see, for example, draft-ietf-trill-oam-framework). You > could, I suppose, have a maintenance FGL but it might as well work > the same way for a VL campus as for an FGL campus. > >> Otherwise, if a FGL RBridge does not have to support a VL mode of >> operation, a specific statement to that effect would be appropriate. > > The current FGL draft, just like all previous versions of the FGL WG and = preceeding personal draft, does require support of VL by FGL RBridges. Sinc= e you specifically talk about -01 to -02 changes, you might not it is not a= change that just appeared in the current version. > >> Section 7, Item 2, only discusses "Silicon Considerations" from an >> ingress/egress point of view. It does not discuss it from a transit >> RBridge perspective. > > Good point, transit processing should be mentioned briefly in Section 7, = Item 2. However, the items in Section 7 are parallel with the same number i= tems in Section 2.1 and are just intended to discuss the extent to which th= e goals in 2.1 are met, not to be a complete discussion or summary of the n= amed topics... Perhpas "Silicon Considerations" should be replaced with "Si= licon Goal". > >> However, there appears to be several statements in the draft that >> could have important effects on how existing silicon could be used for >> transit FGL RBridge operation. Section 5.1 states: >> >> "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination >> TRILL Data frame to the relevant egress TRILL switches after >> encapsulating it as a TRILL known unicast data frame (M=3D0)". >> >> This would appear to allow silicon that can TRILL forward unicast FGL >> packets to operate as a TRILL transit FGL node regardless of whether >> it can TRILL forward FGL multi-destination packets. If that is the >> intent, it would be helpful to state that in Section 7, Item 2. > > Your statement seems a odd to me. I don't understand what you mean when = you say "regardless of whether it can TRILL forward FGL multi-destination p= ackets". If it can't do that, I don't think it is an FGL RBridge. > > An FGL RBridge is required to be able to forward known unicast data that = is TRILL unicast (M=3D0), multi-destination data that is TRILL multicast (M= =3D1), and, due to the text you quote, multi-destination data that is TRILL= unicast (M=3D0). Since your specifically talk about > -01 to -02 changes, you might note that this has been required in all pre= vious versions of the FGL WG draft and preceeding personal draft. > It is not a change that just appeared in the current -02 version. > >> Section 5.2.2 states: >> >> "Pruning is an optimization. If a transit TRILL switch does less >> pruning than it could, there may be greater link utilization than >> strictly necessary but the campus will still operate correctly." >> >> This would appear to allow silicon that can TRILL forward FGL >> multi-destination packets to operate as a TRILL transit FGL node >> regardless of whether it can prune FGL packets. If that is the >> intent, it would be helpful to state that in Section 7, Item 2. > > Pruning is a SHOULD in the base TRILL protocol standard and it is the sam= e here. The provisions here are similar to those in the base standard for V= L pruning. I don't see any problem adding something to clarify although I d= on't think Section 7, Item 2, is the best place. > How about just adding, at the end of the last sentence in Section 5.2.2, = the following words "or not prune FGL frames at all"? > >> Section 5.2.2 also discusses pruning based only on the High Part or >> the Low Part of a FGL. A statement about silicon that can prune based >> only on half of a FGL would also be helpful in Section 7, Item 2. > > But the whole point is that, since pruning is just a SHOULD optimization,= the silicon could prune on whatever subset of FGL bits it feels like and s= till be conformant. For example, it could prune on just the highest order b= it or just the highest order byte of the FGL or something. How about, inclu= ding the addition above, changing > > "For example, a transit TRILL switch could prune based on only part of th= e FGL such as only the High Part or only the Low Part." > > to > > "A transit TRILL switch could prune based on an arbitrary subset of the F= GL label bits, such as only the High Part or only the Low Part, or not prun= e FGL frames at all." > > Actually an RBridge could adopte even more strange or exotic pruning meth= ods, although I can't see why it would want to. For example, it could prune= based on the data label value modulo some arbitrary integer divisor less t= han the maximum label value...sort of a ridiculous thing to do but frames w= ould still be routed correctly so I believe such behavior is allowed. > > 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 > >> Thanks for any consideration of these items. >> >> Cheers, >> Olen >> >> >> >> On 11/6/12 3:42 PM, "Donald Eastlake" wrote: >> >>>Hi, >>> >>>As announced at the TRILL WG meeting today, this starts a two week WG >>>Last Call on draft-ietf-trill-fine-labeling ending 19 November. >>> >>>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 From d3e3e3@gmail.com Tue Nov 27 19:01:15 2012 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 7E7E121E8030 for ; Tue, 27 Nov 2012 19:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.066 X-Spam-Level: X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DugsEQVv2WYj for ; Tue, 27 Nov 2012 19:01:14 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01E21F85FE for ; Tue, 27 Nov 2012 19:01:14 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so12986994ieb.31 for ; Tue, 27 Nov 2012 19:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ZoEVctJ2r0zo0ymY1bEST+ZxGDy0IuoWs18uthf0UgQ=; b=PgaNCbFkjBnOmViuIUDI1d2LMJ7MWBYbdaIjm/MmWhYFEEHZEYvvXQpHYWmZLRu68I uaYLEwRBw6++7UNBCMajLcebD8c+a333MF/5GKQqNn94wzXxBToKtDCnz2sWOLbnt9CZ Mmy1wsAV2bwKMkC6z7EylZOOFi9z984WbNg/Eo56Wez4KxtvOlyPf2oYJyFnxvENcuxS 20cxESFDnQfyQ1TnA0cWcDv0dmjZS97BIUNzU6vWbiGAUYfJfvXONZDymeYhXa+0YXrS 9vR4KQ0G1B/qT4emkInmOMoGfsa+AaV770a4SQTJRPJDZXskCfPJzI95Iv+6Aq8xWiUk 6lGQ== Received: by 10.50.34.201 with SMTP id b9mr17707754igj.55.1354071671928; Tue, 27 Nov 2012 19:01:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Tue, 27 Nov 2012 19:00:51 -0800 (PST) In-Reply-To: References: <201211200140.qAK1eSD0011029@cichlid.raleigh.ibm.com> <6895EAE0CA8DEE40B92D7CA88BB521F32413DAE82F@HQ1-EXCH02.corp.brocade.com> From: Donald Eastlake Date: Tue, 27 Nov 2012 22:00:51 -0500 Message-ID: To: Olen Stokes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:01:15 -0000 Hi Olen, On Mon, Nov 26, 2012 at 10:09 AM, Olen Stokes wrote: > From Donald below: > > "If an RBridge has been modified from existing legacy VL RBridge so that = you can safely use it as a transit node, then it *is* an FGL RBridge (even = if it is a limited FGL RBridge that can't do FGL ingress and egress). If it= has not been so modified, then it remains a VL RBridge and will likely mis= handle or discard and FGL frames it receives." > > We seem to be moving in the direction where RBridges with differing capab= ilities are all considered to be FGL RBridges. Do we need to consider adve= rtising the differences in capabilities in the ISIS extensions for FGL? I don't think so in this case. It seems to me that there isn't a need to distinguish a limited FGL TRILL switch (FGL transit only) from a full FGL TRILL switch (FGL ingress, transit, and egress) in the link state. A port doesn't ingress to FGL unless it is configured to do so and you can't configure a port of a limited FGL TRILL switch that way. And an FGL TRILL Data frame can't be egressed at a port unless the port is labeled with the same FGL label as the frame which can't be done with a limited FLG TRILL switch. 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 > Cheers, > Olen > > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of= Donald Eastlake > Sent: Friday, November 23, 2012 2:39 PM > To: Phanidhar Koganti > Cc: Anoop Ghanwani; trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > Hi Phanidhar, > > On Tue, Nov 20, 2012 at 2:29 PM, Phanidhar Koganti = wrote: >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On > Behalf Of Anoop Ghanwani >> Sent: Wednesday, November 21, 2012 12:50 AM >> To: Donald Eastlake >> Cc: Radia Perlman; trill@ietf.org >> Subject: Re: [trill] WG Last Call: > draft-ietf-trill-fine-labeling-02.txt >> >> >> On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake > wrote: >> >> Hi Radia, >> >> On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman > wrote: >>> Ah. So the intent is that an FGL RBridge must be able to parse >>> either VL or FGL, which would allow an edge RB that only supports VL >>> to work OK, and to have some number of VLANs (4000 of them) that >>> would be reachable via old edge RBs? > >> >> Yes on parsing. But it is hard to be sure no FGL frame can >> get to a VL RBridge. Say you have VLRB1 connected to the campus >> through FGLRB2. And FGLRB2 is connected to FGLRB3. What if >> connectivity appears between VLRB1 and FGLRB3 and perhaps the link >> between FGLRB2 and FGLRB3 breaks? How can you stop FGL frames from >> going between FGLRB2 and FGLRB3 via VLRB1 keeping in mind that you >> have to assume no changes in the old VL RBridges? (Without >> multi-topology. With multi-topology, it's relatively easy.) >> >> FGL frames should never be forwarded to an RB that doesn't >> support FGL. This is easy to figure out since IS-IS can tell us what >> the capabilities of an RBridge are before forwarding to that RBridge >> begins. And as a result of this requirement, we should probably >> disallow FGL and non-FGL RBridges being reachable from the same >> RBridge port, otherwise it would be challenging to implement this >> control for multicast frames. > > I am not sure what you mean by "disallow" but if some physical topology i= s trivially realizable by someone plugging in the wrong cables, you have to= take it into account and say what happens. In this case, where FGL and non= -FGL RBridges are on the same link, the FGL RBridges just refuse to report = any adjacencies on the link, thus excommunicating the link for TRILL Data t= raffic. > >> [Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as >> transit nodes? Why can't the transit nodes just rely on TRILL SA/DA to >> forward. Agree there will be issues for multicast in terms of the >> optimal pruned forwarding as a non-FGL RB will not have access to the >> inner IP header or VLAN (FGL based). However isn't this an >> optimization for multicast pruning? The transit RBs can forward based >> on the non-pruned multicast tree. > > If an RBridge has been modified from existing legacy VL RBridge so that y= ou can safely use it as a transit node, then it *is* an FGL RBridge (even i= f it is a limited FGL RBridge that can't do FGL ingress and egress). If it = has not been so modified, then it remains a VL RBridge and will likely mish= andle or discard and FGL frames it receives. > >>> And we're assuming that old edge RBs that only do VL will >>> know to drop something tagged with FGL? > > I believe they should but it does not seem wise to depend on that. > >> A VL RBridge should, in my opinion, drop an FGL frame based >> on RFC 6325. However, if it did not, it would presumably mean it was >> ignoring the 0x893B value where it should be requiring 0x8100. As a >> result, it would believe the FGL frame was in some VLAN and might >> egress it to the wrong end-stations, violating security policy. >> >> We need to make the spec clear on this aspect; i.e. FGL or >> non-FGL RBridges must discard a received frame if the inner tag (FGL >> or VLAN depending on what mode the port is operating in) is absent. > > In the draft, ports have an FGL/VL configuration "mode" for ingressing/eg= ressing native frames but that don't have any "mode" for TRILL Data frames.= If they are a VL RBridge, they can only handle VL TRILL Data frames. If th= ey are an FGL RBridge, the can handle both VL and FGL TRILL Data frames. > >> Anoop > > 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 _____________= __________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From liao.ting@zte.com.cn Tue Nov 27 19:16:21 2012 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 E0A8321E803D; Tue, 27 Nov 2012 19:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.824 X-Spam-Level: X-Spam-Status: No, score=-95.824 tagged_above=-999 required=5 tests=[AWL=-2.274, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI4EXXBmgXCw; Tue, 27 Nov 2012 19:16:20 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1CA21E8030; Tue, 27 Nov 2012 19:16:11 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id CA44B1269E53; Wed, 28 Nov 2012 11:17:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAS3Fwea027998; Wed, 28 Nov 2012 11:15:58 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) In-Reply-To: To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-KeepSent: B6D0E97A:AA5BE496-48257AC4:00056B68; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liao.ting@zte.com.cn Date: Wed, 28 Nov 2012 11:15:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-28 11:15:43, Serialize complete at 2012-11-28 11:15:43 Content-Type: multipart/alternative; boundary="=_alternative 0011F17348257AC4_=" X-MAIL: mse01.zte.com.cn qAS3Fwea027998 Cc: "trill-bounces@ietf.org" , "trill@ietf.org" Subject: [trill] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXRyaWxsLWNtdA==?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:16:22 -0000 This is a multipart message in MIME format. --=_alternative 0011F17348257AC4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksVGlzc2ENCg0KSU1PLCBtYXliZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9ucyBzaG91bGQg YmUgc3RhbmRhcmRlZDogDQoxo6lob3cgdG8gY2hvb3NlIHRoZSBtZW1iZXIgUkINCjKjqWhvdyB0 aGUgY2hvc2VuIG1lbWJlciBSQiAgdG8gY29sbGVjdCB0aGUgdHJlZSBjb25maWd1cmVkIGluZm9y bWF0aW9uIA0KM6OpaG93IHRvIGFubm91bmNlIHRoZSB0cmVlIGFsbG9jYXRpb24gaW5mb3JtYXRp b24NCg0KQW5kIHdpdGggcmVnYXJkIHRvIGZhaWxvdmVyIHByb3RlY3Rpb24sIHdoZW4gYW55IG90 aGVyIG1lbWJlciBSQiBmYWlscywgDQp0aGUgZmFpbHVyZSBpbmZvcm1hdGlvbiBzaG91bGQgYmUg dHJhbnNtaXR0ZWQgdG8gdGhlIGNob3NlbiBtZW1iZXIgUkIsIA0KYW5kIHRoZSBjaG9zZW4gbWVt YmVyIFJCIHdpbGwgcmVhbGxvY2F0ZSB0cmVlcyBhbW9uZyBtZW1iZXIgUkJzIGV4Y2VwdCB0aGUg DQpmYWlsZWQgb25lLiANCklmIHRoZSBjaG9zZW4gbWVtYmVyIFJCIGhhZCBmYWlsdXJlLCB0aGVy ZSBzaG91bGQgYmUgYSBzbGF2ZSBjaG9zZW4gbWVtYmVyIA0KUkIgZWxlY3RlZCB0byBiZSB0aGUg bWFzdGVyLg0KDQpPSywgbWF5YmUgdGhhdCB3aWxsIGJlIHRvbyBjb21wbGV4LCBhbmQgbW9yZSBs aWtlbHkgdG8gYmUgYSBsb2NhbCANCmFkbWluaXN0cmF0aXZlIHBvbGljeSwgYnV0IGlmIHRoZSBD TVQgbWVudGlvbiBhYm91dCB0aGF0LCBpdCB3aWxsIGJlIG1vcmUgDQppbXBlY2NhYmxlLiA6KQ0K DQpUaGFua3MsDQpUaW5hDQoNCg0KDQoNCiJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIg PHRzZW5ldmlyQGNpc2NvLmNvbT4gDQq3orz+yMs6ICB0cmlsbC1ib3VuY2VzQGlldGYub3JnDQoy MDEyLTExLTI3IDIzOjM0DQoNCsrVvP7Iyw0KImxpYW8udGluZ0B6dGUuY29tLmNuIiA8bGlhby50 aW5nQHp0ZS5jb20uY24+DQqzrcvNDQoidHJpbGwtYm91bmNlc0BpZXRmLm9yZyIgPHRyaWxsLWJv dW5jZXNAaWV0Zi5vcmc+LCAidHJpbGxAaWV0Zi5vcmciIA0KPHRyaWxsQGlldGYub3JnPg0K1vfM 4g0KUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQNCg0KDQoNCg0KDQoNCkhpIFRpbmEN CiANCldoYXQgeW91IGFyZSBsb29raW5nIGF0IGlzIGEgbG9jYWwgYWRtaW5pc3RyYXRpdmUgcG9s aWN5LCBJIGFtIG5vdCBjbGVhciANCndoYXQgdG8gYmUgc3BlY2lmaWVkIGluIGEgc3RhbmRhcmQu IEFkZGl0aW9uYWxseSBtYW51YWwgY29uZmlndXJhdGlvbnMgDQpkb2VzIG5vdCBwcm92aWRlIGZh aWxvdmVyIHByb3RlY3Rpb24uIEkgdGhpbmsgaXQgaXMgYmVzdCB0byBsZWF2ZSB0aGUgDQphZG1p bmlzdHJhdGl2ZSBwb2xpY2llcyB0byBwbGF0Zm9ybXMuDQogDQpBZGRpdGlvbmFsbHksIHdoZW4g bXVsdGlwbGUgdHJlZSBhbGxvY2F0aW9uIGFsZ29yaXRobXMgYXJlIHByZXNlbnQsIHdlIA0KbmVl ZCB0byBlbnN1cmUgdGhhdCBhbGwgb2YgdGhlIFJCdiBhcmUgdXNpbmcgdGhlIGV4YWN0IHNhbWUg YWxnb3JpdGhtLCANCndoaWNoIHdpbGwgbWFrZSBtYXR0ZXJzIGNvbXBsaWNhdGVkLiBTbyBpbiBz aG9ydCwgaWYgb25lIHdvdWxkIGxpa2UgdG8gdXNlIA0KYSBkaWZmZXJlbnQgYWxnb3JpdGhtIHRo YW4gd2hhdCBpcyBzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkLCBpdCBpcyB1cCB0byANCnRoZW0g dG8gZG8gc28gYW5kIGVuc3VyZSB0aGF0IHRoZXkgbWVldA0KIA0KMS4gICAgICAgRmFpbG92ZXIg cmVxdWlyZW1lbnRzDQoyLiAgICAgICBBbGdvcml0aG0gY29uc2lzdGVuY3kgYmV0d2VlbiBtZW1i ZXJzDQogDQpUaGFua3MNClRpc3NhDQogDQogDQpGcm9tOiBsaWFvLnRpbmdAenRlLmNvbS5jbiBb bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI3 LCAyMDEyIDE6MjIgQU0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHRy aWxsQGlldGYub3JnOyB0cmlsbC1ib3VuY2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyaWxs XSBkcmFmdC1pZXRmLXRyaWxsLWNtdA0KIA0KDQpIaSxUaXNzYSANCg0KTWF5YmUgdGhlIENNVCBp cyBqdXN0IHRvIGFubm91bmNlIHRoZSBBZmZpbml0eSBDYXBhYmlsaXR5LCBJTU8sIHRoZSBDTVQg aXMgDQp1c2VkIHRvIHNvbHZlIHRoZSB0cmVlIGFsbG9jYXRpb24gcHJvYmxlbSBpbiBSQnYuIA0K U3VjaCBhcyB0aGUgZmlndXJlIGRlc2NyaWJlZCBpbiBSRkM2MzI1IFA5MyBmb3IgZXhhbXBsZTog dGhlIG5ldHdvcmsgDQptYW5hZ2VyIG1heSBiZSB3YW50IHRvIGRvIHNvbWUgbWFudWFsIGNvbmZp Z3VyYXRpb24gaW4gdGhlIHNpdHVhdGlvbi4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tKyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxSQnl8LS0tLS0tLS0tLS0t LS0tKyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0rICAgICAgICAgICAgICAg fCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyAgfCAgXCAgICAgICAgICAgICAgfCAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgfCAgICBcICAgICAgICAgICAgfCANCiAg ICAgICAgICAgICAgICAgICAgICAgICAvICAgICAgfCAgICAgIFwgICAgICAgICAgfCANCiAgICAg ICAgICAgICAgICAgICAgICArLS0tKyAgICstLS0rICAgKy0tLSsgICAgICAgfCANCiAgICAgICAg ICAgICAgICAgICAgICB8UkIxfC0tLXxSQjJ8LS0tfFJCM3wgICAgICAgfCANCiAgICAgICAgICAg ICAgICAgICAgICArLS0tKyAgICstLS0rICAgKy0tLStcICAgICAgfCANCiAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgIFwgICAgfCANCiAgICAgICAgICAgICAgICAg ICAgICArLS0tKyAgICstLS0rICAgKy0tLSsgICAgXCstLS0rIA0KICAgICAgICAgICAgICAgICAg ICAgIHxSQjR8LS0tfFJCNXwtLS18UkI2fC0tLS0tfFJCenwgDQogICAgICAgICAgICAgICAgICAg ICAgKy0tLSsgICArLS0tKyAgICstLS0rICAgIC8rLS0tKyANCiAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgfCAgICAgICB8ICAgIC8gDQogICAgICAgICAgICAgICAgICAgICAgKy0tLSsg ICArLS0tKyAgICstLS0rLyANCiAgICAgICAgICAgICAgICAgICAgICB8UkI3fC0tLXxSQjh8LS0t fFJCOXwgDQogICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICArLS0tKyAgICstLS0rIA0KVGhl cmUgYXJlIHR3byBkaXN0cmlidXRpb24gdHJlZXMgaW4gdGhlIG5ldHdvcmssIG9uZSByb290ZWQg YXQgUkJ5IHdpbGwgDQpwcmVkb21pbmFudGx5IHVzZSB0aGUgdmVydGljYWwgbGlua3MgYW1vbmcg UkIxIHRocm91Z2ggUkI5IA0Kd2hpbGUgYW5vdGhlciByb290ZWQgYXQgUkJ6IHdpbGwgcHJlZG9t aW5hbnRseSB1c2UgdGhlIGhvcml6b250YWwuIA0KUkIxXFJCNFxSQjdcUkI4XFJCOSBhcmUgYWxs IGVkZ2UgUkJzLCBieSBkZWZhdWx0LCBlYWNoIHdpbGwgY2hvb3NlIHRoZSANCnNob3J0ZXN0IHBh dGihr3MgdHJlZSByb290IHRvIHVzZSwgDQphbmQgZWFjaCBtYXkgdXNlIHRoZSB0d28gdHJlZXMg dG8gbXVsdGlwYXRoaW5nIG11bHRpLWRlc3RpbmF0aW9uIHRyYWZmaWMgDQphdCB0aGUgc2FtZSB0 aW1lLiAgIA0KQnV0IGlmIHdlIGhhdmUgUkIxIGFuZCBSQjcgaW4gYSBSQnYsIHRoZW4gd2UgaGF2 ZSB0byBhbGxvY2F0ZSBkaWZmZXJlbnQgDQp0cmVlcyBiZXR3ZWVuIFJCMSBhbmQgUkI3LiANCldp dGggdGhlIGN1cnJlbnQgQ01UIG1hbm5lciwgbWF5YmUgUkJ6IGlzIGFsbG9jYXRlZCB0byBSQjEs IFJCeSBpcyANCmFsbG9jYXRlZCB0byBSQjcuIA0KT2J2aW91c2x5LFJCMSBpcyBjbG9zZXIgdG8g UkJ5LCBzbyB0aGUgbmV0d29yayBtYW5hZ2VyIG1heSB3YW50IHRvIA0KbWFudWFsbHkgY29uZmln dXJlIFJCeSB0byBSQjEgYXMgYW4gYWxnb3JpdGhtIGludGVydmVudGlvbi4gDQoNCkFzIHRoZSBs b2NhbCBwb2xpY3kvYWRtaW5pc3RyYXRpdmUgbWF0dGVyLCBob3cgdG8gY29tcGF0aWJsZSB3aXRo IG1hbnVhbCANCmNvbmZpZ3VyYXRpb24sIG1heWJlIGl0IGlzIGEgcXVlc3Rpb24gd2l0aGluIHRo ZSBSQnYncyB0cmVlIGFsbG9jYXRpb24/IA0KDQpJIHRoaW5rIHRoaXMgbWF5IGJlIHNvbHZlZCBi eSBjaG9vc2luZyBhIG1lbWJlciBSQiwgd2hpY2ggaXMgdXNlZCB0byANCmNvbGxlY3QgY29uZmln dXJhdGlvbiBpbmZvcm1hdGlvbiBvZiBSQnYsIA0KYW5kIGV4ZWN1dGUgYW4gdW5pZmllZCBhbGdv cml0aG0gdG8gYWxsb2NhdGUgdHJlZXMgZm9yIGFsbCBtZW1iZXJzIHdpdGhpbiANCnRoZSBzYW1l IFJCdi4gDQpUaGVyZSBhcmUgdHdvIGJlbmVmaXRzIGJ5IGRvaW5nIHNvOiBmaXJzdCwgaXQgaXMg Y29tcGF0aWJsZSwgc2Vjb25kIHRoZXJlIA0KaXMgbm8gbmVlZCBmb3IgYWxsIG90aGVyIG1lbWJl ciBSQnMgdG8gZXhlY3V0ZSB0aGUgYWxnb3JpdGhtLiANCg0KVGhhbmtzLA0KVGluYSANCg0KDQoN CiJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4gDQq3 orz+yMs6ICB0cmlsbC1ib3VuY2VzQGlldGYub3JnIA0KMjAxMi0xMS0yNiAyMzo0NCANCg0KDQrK 1bz+yMsNCiJsaWFvLnRpbmdAenRlLmNvbS5jbiIgPGxpYW8udGluZ0B6dGUuY29tLmNuPiANCrOt y80NCiJ0cmlsbEBpZXRmLm9yZyIgPHRyaWxsQGlldGYub3JnPiANCtb3zOINClJlOiBbdHJpbGxd IGRyYWZ0LWlldGYtdHJpbGwtY210DQogDQoNCg0KDQoNCg0KDQoNCg0KSGkgVGluYSANCiAgDQpB bnN3ZXIgaXMgbm8gbmVlZCBhbmQgaXQgaXMgYWxyZWFkeSBidWlsdCBpbi4gSGVyZSBpcyB3aHku IFdlIHByb3Bvc2UgdG8gDQphbm5vdW5jZSB0aGUgQWZmaW5pdHkgQ2FwYWJpbGl0eS4gIENNVCBz cGVjaWZpY2F0aW9uIGlzIHRoYXQgUkJyaWRnZSANCmFubm91bmNpbmcgdGhhdCBjYXBhYmlsaXR5 IG11c3QgZm9sbG93IHRoZSBzcGVjaWZpZWQgdHJlZSBhbGxvY2F0aW9uLiBJZiANCnNvbWUgUkJy aWRnZSBpcyBhbm5vdW5jaW5nIHRoZSBhZmZpbml0eSBjYXBhYmlsaXR5IGFuZCB5ZXQgZG9pbmcg bWFudWFsIA0KYWxsb2NhdGlvbiB0aGVuIGl0IGlzIGFuIGltcGxlbWVudGF0aW9uIGVycm9yIG9y IGxvY2FsIA0KcG9saWN5L2FkbWluaXN0cmF0aXZlIG1hdHRlci4gDQogIA0KVGhhbmtzIA0KVGlz c2EgDQogIA0KRnJvbTogbGlhby50aW5nQHp0ZS5jb20uY24gW21haWx0bzpsaWFvLnRpbmdAenRl LmNvbS5jbl0gDQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDI1LCAyMDEyIDU6MTkgUE0NClRvOiBU aXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHRyaWxsQGlldGYub3JnOyB0cmlsbC1i b3VuY2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNt dCANCiAgDQoNCkhpLFRpc3NhIA0KDQpZZXOjrHRoYXQncyBleGFjdGx5IHdoYXQgSSBtZWFuLiA6 KSANClNob3VsZCB0aGUgQ01UIHRha2UgdGhpcyBzY2VuYXJpbyBpbnRvIGFjY291bnSjvyANCg0K VGhhbmtzLA0KVGluYSANCg0KIlRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNlbmV2 aXJAY2lzY28uY29tPiANCreivP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEyLTEx LTI2IDAwOjUwIA0KIA0KDQoNCsrVvP7Iyw0KImxpYW8udGluZ0B6dGUuY29tLmNuIiA8bGlhby50 aW5nQHp0ZS5jb20uY24+IA0Ks63LzQ0KInRyaWxsQGlldGYub3JnIiA8dHJpbGxAaWV0Zi5vcmc+ IA0K1vfM4g0KUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQNCg0KICANCiANCg0KDQoN Cg0KDQoNCg0KDQoNCkhpIFRpbmEgDQogDQpJIGFtIG5vdCBzdXJlIEkgY29tcGxldGVseSB1bmRl cnN0YW5kIHlvdXIgcXVlc3Rpb24uIEFyZSB5b3UgcmVmZXJyaW5nIHRvIA0KYSBzY2VuYXJpbyB3 aGVyZSBzb21lIG9mIHRoZSBtZW1iZXJzIChlLmcuIFJCMSApIGFyZSB1c2luZyBzb21lIG1hbnVh bCANCmNvbmZpZ3VyYXRpb24gYW5kIG90aGVyIGlzIHVzaW5nIHRoZSBwcm9wb3NlZCBtZXRob2Qg KGUuZy4gUkIyKSBpbiB0aGUgQ01UIA0KZHJhZnQgPyANCiANClBTOiBCb3RoIFJCMSBhbmQgUkIy IGFyZSBtZW1iZXJzIG9mIHRoZSB2aXJ0dWFsIFJCcmlkZ2UgUkJ2IA0KIA0KRnJvbTogbGlhby50 aW5nQHp0ZS5jb20uY24gW21haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbl0gDQpTZW50OiBUaHVy c2RheSwgTm92ZW1iZXIgMjIsIDIwMTIgMTA6MDUgUE0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUg KHRzZW5ldmlyKQ0KQ2M6IHRyaWxsQGlldGYub3JnOyB0cmlsbC1ib3VuY2VzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdCANCiANCg0KSGksVGlzc2Eg DQoNClNlY3Rpb24gNS4xIHByb3ZpZGVzIGEgc2ltcGxlIGdlbmVyYWwgbWV0aG9kIHRvIGFzc2ln biBkaWZmZXJlbnQgdHJlZXMgdG8gDQpkaWZmZXJlbnQgbWVtYmVycyBhbmQgaXQgaXMgZWFzeSB0 byBlbXBsb3kuIA0KQnV0IGluIG15IG9waW5pb24sIGl0IGNvdWxkIGJlIGJldHRlciB0byBhbGxv dyBjby1leGlzdGVuY2Ugb2YgZGVmYXVsdCANCm1hbm5lcqOoY210o6kgYW5kIG1hbnVhbCBjb25m aWd1cmF0aW9uIA0KZm9yIGRpc3RyaWJ1dGlvbiB0cmVlIGNob29zaW5no6xvdGhlcndpc2UgaWYg c29tZSBtZW1iZXIgUkJzIGFyZSBtYW51YWxseSANCmNvbmZpZ3VyZWQgYW5kIG90aGVycyBhcmUg bm90IGNvbmZpZ3VyZWQgYXQgYWxsLCANCmNvbXBhdGliaWxpdHkgcHJvYmxlbSB3aXRoIHRoZSBj dXJyZW50IGFsZ29yaXRobSBjb3VsZCBvY2N1ci4gDQpTbywgbWF5YmUgd2Ugc2hvdWxkIHByb3Zp ZGUgYSB1bmlmaWVkIHRyZWUgZGlzdHJpYnV0aW9uIG1ldGhvZCB3aGljaCBpcyANCmNvbXBhdGli bGUgDQp3aXRoIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBjYW4gZW5zdXJlIGRpZmZlcmVudCBt ZW1iZXIgUkJzIG9idGFpbiANCmRpZmZlcmVudCAgZGlzdHJpYnV0aW9uIHRyZWU/IA0KDQpUaGFu a3MsDQpUaW5hIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJp bGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwN Cg0KDQo= --=_alternative 0011F17348257AC4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLFRpc3NhPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mj5JTU8sIG1heWJlIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb25z IHNob3VsZCBiZSBzdGFuZGFyZGVkOg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4xo6lob3cg dG8gY2hvb3NlIHRoZSBtZW1iZXIgUkI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjKjqWhvdyB0 aGUgY2hvc2VuIG1lbWJlciBSQiAmbmJzcDt0byBjb2xsZWN0IHRoZSB0cmVlDQpjb25maWd1cmVk IGluZm9ybWF0aW9uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+M6OpaG93IHRvIGFubm91bmNl IHRoZSB0cmVlIGFsbG9jYXRpb24gaW5mb3JtYXRpb248L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yPkFuZCB3aXRoIHJlZ2FyZCB0byBmYWlsb3ZlciBwcm90ZWN0aW9uLCB3aGVuIGFueSBv dGhlcg0KbWVtYmVyIFJCIGZhaWxzLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPnRoZSBmYWls dXJlIGluZm9ybWF0aW9uIHNob3VsZCBiZSB0cmFuc21pdHRlZCB0byB0aGUgY2hvc2VuDQptZW1i ZXIgUkIsIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+YW5kIHRoZSBjaG9zZW4gbWVtYmVyIFJC IHdpbGwgcmVhbGxvY2F0ZSB0cmVlcyBhbW9uZyBtZW1iZXINClJCcyBleGNlcHQgdGhlIGZhaWxl ZCBvbmUuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+SWYgdGhlIGNob3NlbiBtZW1iZXIgUkIg aGFkIGZhaWx1cmUsIHRoZXJlIHNob3VsZCBiZSBhDQpzbGF2ZSBjaG9zZW4gbWVtYmVyIFJCIGVs ZWN0ZWQgdG8gYmUgdGhlIG1hc3Rlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPk9LLCBtYXliZSB0aGF0IHdpbGwgYmUgdG9vIGNvbXBsZXgsDQphbmQg bW9yZSBsaWtlbHkgdG8gYmUgYSBsb2NhbCBhZG1pbmlzdHJhdGl2ZSBwb2xpY3ksIGJ1dCBpZiB0 aGUgQ01UIG1lbnRpb24NCmFib3V0IHRoYXQsIGl0IHdpbGwgYmUgbW9yZSBpbXBlY2NhYmxlLiA8 L2ZvbnQ+PGEgaHJlZj1hcHA6ZHM6aW1wZWNjYWJsZSB0YXJnZXQ9X3NlbGY+PC9hPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj46KTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KVGhhbmtzLDxicj4NClRpbmE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7VGlzc2EgU2VuZXZp cmF0aG5lDQoodHNlbmV2aXIpJnF1b3Q7ICZsdDt0c2VuZXZpckBjaXNjby5jb20mZ3Q7PC9iPiA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7 dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDEyLTExLTI3IDIzOjM0PC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2xpYW8udGluZ0B6dGUuY29tLmNuJnF1b3Q7 ICZsdDtsaWFvLnRpbmdAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3Ry aWxsLWJvdW5jZXNAaWV0Zi5vcmcmcXVvdDsgJmx0O3RyaWxsLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 LA0KJnF1b3Q7dHJpbGxAaWV0Zi5vcmcmcXVvdDsgJmx0O3RyaWxsQGlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj5IaSBUaW5hPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5XaGF0IHlvdSBhcmUgbG9va2luZyBhdCBpcw0KYSBs b2NhbCBhZG1pbmlzdHJhdGl2ZSBwb2xpY3ksIEkgYW0gbm90IGNsZWFyIHdoYXQgdG8gYmUgc3Bl Y2lmaWVkIGluIGENCnN0YW5kYXJkLiBBZGRpdGlvbmFsbHkgbWFudWFsIGNvbmZpZ3VyYXRpb25z IGRvZXMgbm90IHByb3ZpZGUgZmFpbG92ZXINCnByb3RlY3Rpb24uIEkgdGhpbmsgaXQgaXMgYmVz dCB0byBsZWF2ZSB0aGUgYWRtaW5pc3RyYXRpdmUgcG9saWNpZXMgdG8NCnBsYXRmb3Jtcy48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkFk ZGl0aW9uYWxseSwgd2hlbiBtdWx0aXBsZQ0KdHJlZSBhbGxvY2F0aW9uIGFsZ29yaXRobXMgYXJl IHByZXNlbnQsIHdlIG5lZWQgdG8gZW5zdXJlIHRoYXQgYWxsIG9mIHRoZQ0KUkJ2IGFyZSB1c2lu ZyB0aGUgZXhhY3Qgc2FtZSBhbGdvcml0aG0sIHdoaWNoIHdpbGwgbWFrZSBtYXR0ZXJzIGNvbXBs aWNhdGVkLg0KU28gaW4gc2hvcnQsIGlmIG9uZSB3b3VsZCBsaWtlIHRvIHVzZSBhIGRpZmZlcmVu dCBhbGdvcml0aG0gdGhhbiB3aGF0IGlzDQpzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkLCBpdCBp cyB1cCB0byB0aGVtIHRvIGRvIHNvIGFuZCBlbnN1cmUgdGhhdCB0aGV5DQptZWV0PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4xLiAmbmJz cDsgJm5ic3A7ICZuYnNwOyBGYWlsb3Zlcg0KcmVxdWlyZW1lbnRzPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjIuICZuYnNwOyAmbmJzcDsgJm5i c3A7IEFsZ29yaXRobQ0KY29uc2lzdGVuY3kgYmV0d2VlbiBtZW1iZXJzPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5UaGFua3M8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+VGlzc2E8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4g bGlhby50aW5nQHp0ZS5jb20uY24gW21haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbl0NCjxiPjxi cj4NClNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMiAxOjIyIEFNPGI+PGJyPg0K VG86PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj4NCkNjOjwvYj4gdHJp bGxAaWV0Zi5vcmc7IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4g UmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NCkhpLFRpc3NhPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpNYXli ZSB0aGUgQ01UIGlzIGp1c3QgdG8gYW5ub3VuY2UgdGhlIEFmZmluaXR5IENhcGFiaWxpdHksIElN TywgdGhlIENNVA0KaXMgdXNlZCB0byBzb2x2ZSB0aGUgdHJlZSBhbGxvY2F0aW9uIHByb2JsZW0g aW4gUkJ2LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClN1Y2ggYXMgPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+dGhlIGZpZ3VyZSBkZXNjcmliZWQgaW4gUkZDNjMyNQ0KUDkzIGZv ciBleGFtcGxlOjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+IHRoZSBuZXR3 b3JrIG1hbmFnZXINCm1heSBiZSB3YW50IHRvIGRvIHNvbWUgbWFudWFsIGNvbmZpZ3VyYXRpb24g aW4gdGhlIHNpdHVhdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0K PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOystLS0rPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8UkJ5fC0t LS0tLS0tLS0tLS0tLSs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOystLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwO3wgJm5ic3A7XCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IC8gJm5ic3A7ICZu YnNwO3wgJm5ic3A7ICZuYnNwO1wgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7fDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg LyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDtcICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOystLS0rICZuYnNwOyArLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDt8UkIxfC0t LXxSQjJ8LS0tfFJCM3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsrLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rXCAm bmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwOyAmbmJzcDtcDQombmJzcDsgJm5ic3A7fDwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOystLS0rICZuYnNwOyArLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7 ICZuYnNwO1wrLS0tKzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDt8 UkI0fC0tLXxSQjV8LS0tfFJCNnwtLS0tLXxSQnp8PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOystLS0rICZuYnNwOyArLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7ICZu YnNwOy8rLS0tKzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 ICZuYnNwOy88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7Ky0tLSsg Jm5ic3A7ICstLS0rICZuYnNwOyArLS0tKy88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7fFJCN3wtLS18UkI4fC0tLXxSQjl8PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7Ky0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyArLS0tKzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpUaGVyZSBhcmUgdHdvIGRpc3RyaWJ1dGlvbiB0cmVlcyBpbiB0aGUgbmV0 d29yaywgb25lIHJvb3RlZCBhdCBSQnkgd2lsbA0KcHJlZG9taW5hbnRseSB1c2UgdGhlIHZlcnRp Y2FsIGxpbmtzIGFtb25nIFJCMSB0aHJvdWdoIFJCOSA8YnI+DQp3aGlsZSBhbm90aGVyIHJvb3Rl ZCBhdCBSQnogd2lsbCBwcmVkb21pbmFudGx5IHVzZSB0aGUgaG9yaXpvbnRhbC48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KUkIxXFJCNFxSQjdcUkI4XFJCOSBhcmUgYWxsIGVkZ2UgUkJzLCBieSBkZWZh dWx0LCBlYWNoIHdpbGwgY2hvb3NlIHRoZQ0Kc2hvcnRlc3QgcGF0aKGvcyB0cmVlIHJvb3QgdG8g dXNlLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphbmQgZWFjaCBtYXkgdXNlIHRoZSB0d28gdHJlZXMg dG8gbXVsdGlwYXRoaW5nIG11bHRpLWRlc3RpbmF0aW9uIHRyYWZmaWMNCmF0IHRoZSBzYW1lIHRp bWUuICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkJ1dCBpZiB3ZSBoYXZlIFJCMSBhbmQgUkI3 IGluIGEgUkJ2LCB0aGVuIHdlIGhhdmUgdG8gYWxsb2NhdGUgZGlmZmVyZW50DQp0cmVlcyBiZXR3 ZWVuIFJCMSBhbmQgUkI3LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCldpdGggdGhlIGN1cnJlbnQgQ01U IG1hbm5lciwgbWF5YmUgUkJ6IGlzIGFsbG9jYXRlZCB0byBSQjEsIFJCeSBpcyBhbGxvY2F0ZWQN CnRvIFJCNy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpPYnZpb3VzbHksUkIxIGlzIGNsb3NlciB0byBS QnksPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4gc28NCnRoZSBuZXR3b3Jr IG1hbmFnZXIgbWF5IHdhbnQgdG88L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4gbWFu dWFsbHkNCmNvbmZpZ3VyZSBSQnkgdG8gUkIxIGFzIGFuIGFsZ29yaXRobSBpbnRlcnZlbnRpb24u PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFzIHRoZSBsb2NhbCBwb2xpY3kvYWRtaW5pc3Ry YXRpdmUgbWF0dGVyLCA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhvdw0K dG8gY29tcGF0aWJsZSB3aXRoIG1hbnVhbCBjb25maWd1cmF0aW9uLCBtYXliZSBpdCBpcyBhIHF1 ZXN0aW9uIHdpdGhpbg0KdGhlIFJCdidzIHRyZWUgYWxsb2NhdGlvbj88L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCkkgdGhpbmsgdGhpcyBtYXkgYmUgc29sdmVkIGJ5IGNob29zaW5nIGEg bWVtYmVyIFJCLCB3aGljaCBpcyB1c2VkIHRvIGNvbGxlY3QNCmNvbmZpZ3VyYXRpb24gaW5mb3Jt YXRpb24gb2YgUkJ2LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCmFuZCBleGVjdXRlIGFuIHVu aWZpZWQgYWxnb3JpdGhtIHRvIGFsbG9jYXRlIHRyZWVzIGZvciBhbGwgbWVtYmVycyB3aXRoaW4N CnRoZSBzYW1lIFJCdi4gPGJyPg0KVGhlcmUgYXJlIHR3byBiZW5lZml0cyBieSBkb2luZyBzbzog Zmlyc3QsIGl0IGlzIGNvbXBhdGlibGUsIHNlY29uZCB0aGVyZQ0KaXMgbm8gbmVlZCBmb3IgYWxs IG90aGVyIG1lbWJlciBSQnMgdG8gZXhlY3V0ZSB0aGUgYWxnb3JpdGhtLjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KVGluYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MyU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFs Ij48Yj4mcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSZxdW90Ow0KJmx0OzwvYj48 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHNlbmV2aXJAY2lzY28uY29tPjxmb250IHNpemU9MSBjb2xv cj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9iPjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQq3orz+yMs8L2ZvbnQ+PGZvbnQgc2l6ZT0x IGZhY2U9IkFyaWFsIj46ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNl c0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnRyaWxs LWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjIwMTItMTEtMjYg MjM6NDQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRk IHdpZHRoPTQ2JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MTIlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg3JT48Zm9udCBzaXplPTEgZmFj ZT0iQXJpYWwiPiZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5j bj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+bGlhby50aW5nQHp0ZS5j b20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0 OzwvZm9udD48YSBocmVmPW1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTEg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7PC9mb250PjxhIGhyZWY9bWFp bHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48 dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNp emU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5SZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRy aWxsLWNtdDwvZm9udD48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpIaSBUaW5h PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpBbnN3ZXIgaXMgbm8gbmVlZCBhbmQgaXQgaXMgYWxyZWFk eSBidWlsdCBpbi4gSGVyZSBpcyB3aHkuIFdlIHByb3Bvc2UgdG8NCmFubm91bmNlIHRoZSBBZmZp bml0eSBDYXBhYmlsaXR5LiAmbmJzcDtDTVQgc3BlY2lmaWNhdGlvbiBpcyB0aGF0IFJCcmlkZ2UN CmFubm91bmNpbmcgdGhhdCBjYXBhYmlsaXR5IG11c3QgZm9sbG93IHRoZSBzcGVjaWZpZWQgdHJl ZSBhbGxvY2F0aW9uLiBJZg0Kc29tZSBSQnJpZGdlIGlzIGFubm91bmNpbmcgdGhlIGFmZmluaXR5 IGNhcGFiaWxpdHkgYW5kIHlldCBkb2luZyBtYW51YWwNCmFsbG9jYXRpb24gdGhlbiBpdCBpcyBh biBpbXBsZW1lbnRhdGlvbiBlcnJvciBvciBsb2NhbCBwb2xpY3kvYWRtaW5pc3RyYXRpdmUNCm1h dHRlci48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NClRoYW5rczwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQpUaXNzYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQog PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KRnJvbTo8L2I+IDwvZm9udD48YSBocmVmPW1h aWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJU YWhvbWEiPjx1PmxpYW8udGluZ0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y IGZhY2U9IlRhaG9tYSI+DQpbPC9mb250PjxhIGhyZWY9bWFpbHRvOmxpYW8udGluZ0B6dGUuY29t LmNuPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmxpYW8u dGluZ0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ XQ0KPGI+PGJyPg0KU2VudDo8L2I+IFN1bmRheSwgTm92ZW1iZXIgMjUsIDIwMTIgNToxOSBQTTxi Pjxicj4NClRvOjwvYj4gVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik8Yj48YnI+DQpDYzo8 L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KPC9mb250PjxhIGhyZWY9Im1haWx0bzp0cmlsbC1i b3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1 PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmls bC1jbXQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJy Pg0KSGksVGlzc2E8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KWWVzPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj6jrDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPnRoYXQn cw0KZXhhY3RseSB3aGF0IEkgbWVhbi4gOik8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU2hvdWxkIHRoZSBDTVQg dGFrZSB0aGlzIHNjZW5hcmlvIGludG8gYWNjb3VudDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+o788L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpUaW5hPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MyU+PGZvbnQgc2l6ZT0xIGZhY2U9 IkFyaWFsIj48Yj4mcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSZxdW90Ow0KJmx0 OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHNlbmV2aXJAY2lzY28uY29tPjxmb250IHNpemU9 MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9i PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mZ3Q7PC9iPg0KPC9mb250 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQq3orz+yMs8L2ZvbnQ+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj46ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwt Ym91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1 PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i QXJpYWwiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4yMDEyLTExLTI2 IDAwOjUwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+DQo8dGQgd2lk dGg9NDYlPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTIl Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg3JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZx dW90OzwvZm9udD48YSBocmVmPW1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48Zm9udCBzaXpl PTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBo cmVmPW1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+PHU+bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4N CjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0iQXJpYWwiPiZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9y Zz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+dHJpbGxAaWV0Zi5vcmc8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9u dD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEg ZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0iQXJpYWwiPlJlOiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwtY210PC9mb250PjwvdGFibGU+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPGJy Pg0KSGkgVGluYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiA8YnI+DQogPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkkgYW0gbm90 IHN1cmUgSSBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gQXJlIHlvdSByZWZl cnJpbmcNCnRvIGEgc2NlbmFyaW8gd2hlcmUgc29tZSBvZiB0aGUgbWVtYmVycyAoZS5nLiBSQjEg KSBhcmUgdXNpbmcgc29tZSBtYW51YWwNCmNvbmZpZ3VyYXRpb24gYW5kIG90aGVyIGlzIHVzaW5n IHRoZSBwcm9wb3NlZCBtZXRob2QgKGUuZy4gUkIyKSBpbiB0aGUNCkNNVCBkcmFmdCA/PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KUFM6IEJvdGggUkIxIGFuZCBSQjIgYXJl IG1lbWJlcnMgb2YgdGhlIHZpcnR1YWwgUkJyaWRnZSBSQnY8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkFyaWFsIj4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+ PGJyPg0KRnJvbTo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5j bj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmxpYW8udGluZ0B6dGUu Y29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+DQpbPC9mb250 PjxhIGhyZWY9bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IFRo dXJzZGF5LCBOb3ZlbWJlciAyMiwgMjAxMiAxMDowNSBQTTxiPjxicj4NClRvOjwvYj4gVGlzc2Eg U2VuZXZpcmF0aG5lICh0c2VuZXZpcik8Yj48YnI+DQpDYzo8L2I+IDwvZm9udD48YSBocmVmPW1h aWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi Pjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9t YSI+Ow0KPC9mb250PjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5v cmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpTdWJq ZWN0OjwvYj4gUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQ8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkFyaWFsIj4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQo8YnI+DQpIaSxUaXNzYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpTZWN0aW9uIDUuMSBw cm92aWRlcyBhIHNpbXBsZSBnZW5lcmFsIG1ldGhvZCB0byBhc3NpZ24gZGlmZmVyZW50IHRyZWVz DQp0byBkaWZmZXJlbnQgbWVtYmVycyBhbmQgaXQgaXMgZWFzeSB0byBlbXBsb3kuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpCdXQgaW4gbXkgb3BpbmlvbiwgaXQgY291bGQgYmUgYmV0dGVyIHRvIGFsbG93IGNv LWV4aXN0ZW5jZSBvZiBkZWZhdWx0DQptYW5uZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPqOoPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Y210PC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj6jqTwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPg0KYW5kIG1hbnVhbCBjb25maWd1cmF0aW9uIDxicj4NCmZvciBkaXN0cmlidXRpb24g dHJlZSBjaG9vc2luZzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+o6w8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5vdGhlcndpc2UNCmlmIHNvbWUgbWVtYmVyIFJC cyBhcmUgbWFudWFsbHkgY29uZmlndXJlZCBhbmQgb3RoZXJzIGFyZSBub3QgY29uZmlndXJlZA0K YXQgYWxsLCA8YnI+DQpjb21wYXRpYmlsaXR5IHByb2JsZW0gd2l0aCB0aGUgY3VycmVudCBhbGdv cml0aG0gY291bGQgb2NjdXIuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpTbywgbWF5YmUgd2Ugc2hvdWxkIHBy b3ZpZGUgYSB1bmlmaWVkIHRyZWUgZGlzdHJpYnV0aW9uIG1ldGhvZCB3aGljaCBpcw0KY29tcGF0 aWJsZSA8YnI+DQp3aXRoIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBjYW4gZW5zdXJlIGRpZmZl cmVudCBtZW1iZXIgUkJzIG9idGFpbiBkaWZmZXJlbnQNCiZuYnNwO2Rpc3RyaWJ1dGlvbiB0cmVl PyA8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KVGluYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i QXJpYWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlzdDwv Zm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8 L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9IkFyaWFsIj48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+ PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyaWxsPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxA aWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+dHJp bGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmlsbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxs PC91PjwvZm9udD48L2E+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlzdDxicj4NCnRyaWxs QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmls bDxicj4NCjwvZm9udD48L3R0Pg0KPHA+DQo= --=_alternative 0011F17348257AC4_=-- From d3e3e3@gmail.com Tue Nov 27 19:30:07 2012 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 3D1F421F8761 for ; Tue, 27 Nov 2012 19:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.279 X-Spam-Level: X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvs3eRPsDhap for ; Tue, 27 Nov 2012 19:30:06 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED8221F8762 for ; Tue, 27 Nov 2012 19:30:06 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so10350776iaf.31 for ; Tue, 27 Nov 2012 19:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=XokaGXmBZ4SLM44t2qVjzvDZ2V0PsIdkVjhWuREONHc=; b=mlWX02Vbv4MuGXSAVP1akSMSh4EZFp3UsMPEARmhYfj3uOGw1ACHCpg809GV9lu2bi 2699syOndlhrVJgMx7Zyy+jTa2nB/Pn7dXBv+j70UVHhQtDm8ogXV821hUTBmCTgY3CE lYPxyyZUZaoQVW4c6iZmLx/7O0mppPdi9GRw08N8SBzGBigrHXzL1+tLA+5J5XFQUGAc IjQfuLw0xCnbW2TSSh8QxaplwlaeP/QDGwsyqyZR1d5O2ShrWLuehuV8rroFExAv9pid oAwOdA22XcyRVpIaDjvnumxIR9Nn48qMrv+ElYMqAsVhvjZ+zCn3VIqqISzXe5uxBPOK 74DQ== Received: by 10.42.180.10 with SMTP id bs10mr15359817icb.39.1354073406166; Tue, 27 Nov 2012 19:30:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Tue, 27 Nov 2012 19:29:45 -0800 (PST) From: Donald Eastlake Date: Tue, 27 Nov 2012 22:29:45 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] Updated Milestones Posted X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:30:07 -0000 The updated milestones for the TRILL WG that were discussed in Atlanta and posted to the WG mailing list have been posted to the TRILL Charter page and are now in effect. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From dai.xuehui@zte.com.cn Tue Nov 27 19:41:32 2012 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 A85BC21F87BD for ; Tue, 27 Nov 2012 19:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wTYCeVHz9Nn for ; Tue, 27 Nov 2012 19:41:31 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8851221F87B9 for ; Tue, 27 Nov 2012 19:41:31 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id C6103126A34D for ; Wed, 28 Nov 2012 11:43:04 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 95E72725312; Wed, 28 Nov 2012 11:39:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qAS3fJbL018463; Wed, 28 Nov 2012 11:41:19 +0800 (GMT-8) (envelope-from dai.xuehui@zte.com.cn) To: ssalam@cisco.com, tsenevir@cisco.com, sam.aldrin@gmail.com, d3e3e3@gmail.com MIME-Version: 1.0 X-KeepSent: 8FF920A5:093B3D0B-48257AC4:00121DD9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: dai.xuehui@zte.com.cn Date: Wed, 28 Nov 2012 11:41:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-28 11:41:04, Serialize complete at 2012-11-28 11:41:04 Content-Type: multipart/alternative; boundary="=_alternative 001442E148257AC4_=" X-MAIL: mse02.zte.com.cn qAS3fJbL018463 Cc: "trill@ietf.org" Subject: [trill] cc in "draft-ietf-trill-oam-framework-00" X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:41:32 -0000 This is a multipart message in MIME format. --=_alternative 001442E148257AC4_= Content-Type: text/plain; charset="US-ASCII" Hi, all trill-oam-framework authors I have some troubles on understanding cc function described in section 4.1.1 in draft-ietf-trill-oam-framework-00, wish you can help me for more clear understanding. 1. 4.1.1 Fault Detection (Continuity Check) "..... The proactive fault detection function must detect the following types of defects: - Loss of continuity (LoC) to one or more remote MEPs - Unexpected connectivity between isolated VLANs (mismerge) - Unexpected connectivity to one or more remote MEPs - Period mis-configuration" In my mind, maybe the sencond and third types of defects should be defects detected by CV ? 2. 4.1.2.1 Forward Defect Indication "...... a simple network comprising of four RBridges connected in tandem: RB1, RB2, RB3 and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a forward defect indication towards RB1 while RB3 sends a forward defect indication towards RB4......" my question is how to detect the link faliure between RB2 and RB3 , through TRILL oam? such as one hop TRILL BFD? 3.Does CC should be supported on sections? if it is, how the ingress and egress nickname be set? the same as CV on sections( see the last paragraph in section 4.2.1.1 in trill-oam-framework)? please correct me if I have some misunderstanding :) Best Regards, xuehui --=_alternative 001442E148257AC4_= Content-Type: text/html; charset="US-ASCII"
Hi, all trill-oam-framework authors

I have some troubles on understanding cc function described in section 4.1.1 in draft-ietf-trill-oam-framework-00, wish you can help me for more clear understanding.

1. 4.1.1 Fault Detection (Continuity Check)
".....
The proactive fault detection function must detect the following
  types of defects:

  - Loss of continuity (LoC) to one or more remote MEPs
  - Unexpected connectivity between isolated VLANs (mismerge)
  - Unexpected connectivity to one or more remote MEPs
  - Period mis-configuration"

In my mind, maybe the sencond and third types of  defects should be defects detected by CV ?

2. 4.1.2.1 Forward Defect Indication

"......
a simple network comprising of four RBridges connected in tandem: RB1, RB2, RB3 and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a forward defect indication towards RB1 while RB3 sends a forward defect indication towards RB4......"

my question is how to detect the link faliure between RB2 and RB3 , through TRILL oam? such as one hop TRILL BFD?

3.Does CC should be supported on sections? if it is, how the ingress and egress nickname be set? the same as CV on sections( see the last paragraph in section 4.2.1.1 in trill-oam-framework)?


please correct me if I have some misunderstanding :)


Best Regards,
xuehui


--=_alternative 001442E148257AC4_=-- From tsenevir@cisco.com Tue Nov 27 19:45:45 2012 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 C348A21E8030; Tue, 27 Nov 2012 19:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDBRW8y9Cld4; Tue, 27 Nov 2012 19:45:44 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 95BFB21F8449; Tue, 27 Nov 2012 19:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56680; q=dns/txt; s=iport; t=1354074343; x=1355283943; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CqLd8cukwlH1FucxoqIm8rwBKmVke5IYof6aVj+xkXc=; b=fYpLi+a3xflx6E58aWHLv+6Zox4/pT3dabJ2K1OCdtrRsmxH/ZHM3EGS ViSXmtoidDKyBJ0Ti1bADb541VNZGrXoawfIZDcCf4aX8kUMHq1TBmfvP lAHisN5BoYPMvX/XkHYqTNe67yvMdud+Ezp+vJqQAWOCRC2oilHe2639y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsMALOHtVCtJV2Z/2dsb2JhbABFgkmDYLh/exZsB4IeAQEBBAEBASpBCxACAQYCEQQBAQsLCwEGBQICJQsUCQgCBA4FCBOHcgysRgiETo4PBIw6gQ6CHDZhA6ZFgmMNgiA X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146913206" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 28 Nov 2012 03:45:42 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAS3jgrO000758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 03:45:42 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.130]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 21:45:42 -0600 From: "Tissa Senevirathne (tsenevir)" To: "liao.ting@zte.com.cn" Thread-Topic: Re: [trill] draft-ietf-trill-cmt Thread-Index: Ac2+FF0H+VMAhVydQOe90fdycFINlgLXltQAAG52p5AAHnL5AAARf38AADGjD4AAACHO8AAlYbKAAAvGWQA= Date: Wed, 28 Nov 2012 03:45:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.101] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE19356288761EDxmbrcdx08ciscoc_" MIME-Version: 1.0 Cc: "trill-bounces@ietf.org" , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:45:45 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE19356288761EDxmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGluYQ0KDQpJIG11c3QgYWRtaXQsIEkgZGlkIG5vdCBmdWxseSB1bmRlcnN0YW5kIHdoYXQg eW91IG1lYW4gYnkgc29tZSBvZiB0aGUgaXRlbXMgYmVsb3cNCg0KMaOpaG93IHRvIGNob29zZSB0 aGUgbWVtYmVyIFJCDQpDdXJyZW50IHByb3Bvc2FsIGlzIHRvIGNvbnNpZGVyIGFsbCBSQnJpZGdl cyBhbm5vdW5jaW5nIG5pY2tuYW1lIFJCdiB0byBiZSBtZW1iZXJzLg0KMqOpaG93IHRoZSBjaG9z ZW4gbWVtYmVyIFJCICB0byBjb2xsZWN0IHRoZSB0cmVlIGNvbmZpZ3VyZWQgaW5mb3JtYXRpb24N Cltub3QgY2xlYXIgd2l0aCB3aGF0IHlvdSBtZWFudF0NCjOjqWhvdyB0byBhbm5vdW5jZSB0aGUg dHJlZSBhbGxvY2F0aW9uIGluZm9ybWF0aW9uDQpbY3VycmVudGx5LCBlYWNoIFJCcmlkZ2UgdXNl IGEgc3RhbmRhcmQgYWxnb3JpdGhtIGFuZCBhbGwgUkJyaWRnZXMgY2FuIGRlZHVjZSB0aGUgdHJl ZXMgdXNlZCBieSBtZW1iZXIgUkJyaWRnZXMgUkJ2XQ0KDQpJZiB5b3Ugd2FudCBtb3JlIGNvbXBs ZXggYW5kIGV4dGVuc2libGUgc29sdXRpb24sIEkgdGhpbmsgaXQgaXMgYmVzdCB0byB3cml0ZSBh IHNlcGFyYXRlIGRyYWZ0Lg0KDQpUaGFua3MNClRpc3NhDQpGcm9tOiBsaWFvLnRpbmdAenRlLmNv bS5jbiBbbWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuXQ0KU2VudDogVHVlc2RheSwgTm92ZW1i ZXIgMjcsIDIwMTIgNzoxNiBQTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpD YzogdHJpbGxAaWV0Zi5vcmc7IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6 IFJlOiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwtY210DQoNCg0KSGksVGlzc2ENCg0KSU1PLCBt YXliZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9ucyBzaG91bGQgYmUgc3RhbmRhcmRlZDoNCjGj qWhvdyB0byBjaG9vc2UgdGhlIG1lbWJlciBSQg0KMqOpaG93IHRoZSBjaG9zZW4gbWVtYmVyIFJC ICB0byBjb2xsZWN0IHRoZSB0cmVlIGNvbmZpZ3VyZWQgaW5mb3JtYXRpb24NCjOjqWhvdyB0byBh bm5vdW5jZSB0aGUgdHJlZSBhbGxvY2F0aW9uIGluZm9ybWF0aW9uDQoNCkFuZCB3aXRoIHJlZ2Fy ZCB0byBmYWlsb3ZlciBwcm90ZWN0aW9uLCB3aGVuIGFueSBvdGhlciBtZW1iZXIgUkIgZmFpbHMs DQp0aGUgZmFpbHVyZSBpbmZvcm1hdGlvbiBzaG91bGQgYmUgdHJhbnNtaXR0ZWQgdG8gdGhlIGNo b3NlbiBtZW1iZXIgUkIsDQphbmQgdGhlIGNob3NlbiBtZW1iZXIgUkIgd2lsbCByZWFsbG9jYXRl IHRyZWVzIGFtb25nIG1lbWJlciBSQnMgZXhjZXB0IHRoZSBmYWlsZWQgb25lLg0KSWYgdGhlIGNo b3NlbiBtZW1iZXIgUkIgaGFkIGZhaWx1cmUsIHRoZXJlIHNob3VsZCBiZSBhIHNsYXZlIGNob3Nl biBtZW1iZXIgUkIgZWxlY3RlZCB0byBiZSB0aGUgbWFzdGVyLg0KDQpPSywgbWF5YmUgdGhhdCB3 aWxsIGJlIHRvbyBjb21wbGV4LCBhbmQgbW9yZSBsaWtlbHkgdG8gYmUgYSBsb2NhbCBhZG1pbmlz dHJhdGl2ZSBwb2xpY3ksIGJ1dCBpZiB0aGUgQ01UIG1lbnRpb24gYWJvdXQgdGhhdCwgaXQgd2ls bCBiZSBtb3JlIGltcGVjY2FibGUuIDopDQoNClRoYW5rcywNClRpbmENCg0KDQoiVGlzc2EgU2Vu ZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNjby5jb208bWFpbHRvOnRzZW5ldmly QGNpc2NvLmNvbT4+DQq3orz+yMs6ICB0cmlsbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmls bC1ib3VuY2VzQGlldGYub3JnPg0KDQoyMDEyLTExLTI3IDIzOjM0DQoNCsrVvP7Iyw0KDQoibGlh by50aW5nQHp0ZS5jb20uY248bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPiIgPGxpYW8udGlu Z0B6dGUuY29tLmNuPG1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj4+DQoNCrOty80NCg0KInRy aWxsLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+IiA8dHJp bGwtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZz4+LCAidHJp bGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPiIgPHRyaWxsQGlldGYub3JnPG1haWx0 bzp0cmlsbEBpZXRmLm9yZz4+DQoNCtb3zOINCg0KUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmls bC1jbXQNCg0KDQoNCg0KDQoNCg0KSGkgVGluYQ0KDQpXaGF0IHlvdSBhcmUgbG9va2luZyBhdCBp cyBhIGxvY2FsIGFkbWluaXN0cmF0aXZlIHBvbGljeSwgSSBhbSBub3QgY2xlYXIgd2hhdCB0byBi ZSBzcGVjaWZpZWQgaW4gYSBzdGFuZGFyZC4gQWRkaXRpb25hbGx5IG1hbnVhbCBjb25maWd1cmF0 aW9ucyBkb2VzIG5vdCBwcm92aWRlIGZhaWxvdmVyIHByb3RlY3Rpb24uIEkgdGhpbmsgaXQgaXMg YmVzdCB0byBsZWF2ZSB0aGUgYWRtaW5pc3RyYXRpdmUgcG9saWNpZXMgdG8gcGxhdGZvcm1zLg0K DQpBZGRpdGlvbmFsbHksIHdoZW4gbXVsdGlwbGUgdHJlZSBhbGxvY2F0aW9uIGFsZ29yaXRobXMg YXJlIHByZXNlbnQsIHdlIG5lZWQgdG8gZW5zdXJlIHRoYXQgYWxsIG9mIHRoZSBSQnYgYXJlIHVz aW5nIHRoZSBleGFjdCBzYW1lIGFsZ29yaXRobSwgd2hpY2ggd2lsbCBtYWtlIG1hdHRlcnMgY29t cGxpY2F0ZWQuIFNvIGluIHNob3J0LCBpZiBvbmUgd291bGQgbGlrZSB0byB1c2UgYSBkaWZmZXJl bnQgYWxnb3JpdGhtIHRoYW4gd2hhdCBpcyBzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkLCBpdCBp cyB1cCB0byB0aGVtIHRvIGRvIHNvIGFuZCBlbnN1cmUgdGhhdCB0aGV5IG1lZXQNCg0KMS4gICAg ICAgRmFpbG92ZXIgcmVxdWlyZW1lbnRzDQoyLiAgICAgICBBbGdvcml0aG0gY29uc2lzdGVuY3kg YmV0d2VlbiBtZW1iZXJzDQoNClRoYW5rcw0KVGlzc2ENCg0KDQpGcm9tOiBsaWFvLnRpbmdAenRl LmNvbS5jbjxtYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY24+IFttYWlsdG86bGlhby50aW5nQHp0 ZS5jb20uY25dDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMiAxOjIyIEFNDQpUbzog VGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiB0cmlsbEBpZXRmLm9yZzxtYWlsdG86 dHJpbGxAaWV0Zi5vcmc+OyB0cmlsbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmlsbC1ib3Vu Y2VzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQN Cg0KDQpIaSxUaXNzYQ0KDQpNYXliZSB0aGUgQ01UIGlzIGp1c3QgdG8gYW5ub3VuY2UgdGhlIEFm ZmluaXR5IENhcGFiaWxpdHksIElNTywgdGhlIENNVCBpcyB1c2VkIHRvIHNvbHZlIHRoZSB0cmVl IGFsbG9jYXRpb24gcHJvYmxlbSBpbiBSQnYuDQpTdWNoIGFzIHRoZSBmaWd1cmUgZGVzY3JpYmVk IGluIFJGQzYzMjUgUDkzIGZvciBleGFtcGxlOiB0aGUgbmV0d29yayBtYW5hZ2VyIG1heSBiZSB3 YW50IHRvIGRvIHNvbWUgbWFudWFsIGNvbmZpZ3VyYXRpb24gaW4gdGhlIHNpdHVhdGlvbi4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfFJCeXwtLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstLS0rICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gIHwg IFwgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgLyAgICB8ICAgIFwg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAvICAgICAgfCAgICAgIFwgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICArLS0tKyAgICstLS0rICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgIHxSQjF8LS0tfFJCMnwtLS18UkIzfCAgICAgICB8DQog ICAgICAgICAgICAgICAgICAgICArLS0tKyAgICstLS0rICAgKy0tLStcICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICBcICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICstLS0rICAgKy0tLSsgICArLS0tKyAgICBcKy0tLSsNCiAgICAgICAgICAgICAg ICAgICAgIHxSQjR8LS0tfFJCNXwtLS18UkI2fC0tLS0tfFJCenwNCiAgICAgICAgICAgICAgICAg ICAgICstLS0rICAgKy0tLSsgICArLS0tKyAgICAvKy0tLSsNCiAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICB8ICAgICAgIHwgICAgLw0KICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICAr LS0tKyAgICstLS0rLw0KICAgICAgICAgICAgICAgICAgICAgfFJCN3wtLS18UkI4fC0tLXxSQjl8 DQogICAgICAgICAgICAgICAgICAgICArLS0tKyAgICstLS0rICAgKy0tLSsNClRoZXJlIGFyZSB0 d28gZGlzdHJpYnV0aW9uIHRyZWVzIGluIHRoZSBuZXR3b3JrLCBvbmUgcm9vdGVkIGF0IFJCeSB3 aWxsIHByZWRvbWluYW50bHkgdXNlIHRoZSB2ZXJ0aWNhbCBsaW5rcyBhbW9uZyBSQjEgdGhyb3Vn aCBSQjkNCndoaWxlIGFub3RoZXIgcm9vdGVkIGF0IFJCeiB3aWxsIHByZWRvbWluYW50bHkgdXNl IHRoZSBob3Jpem9udGFsLg0KUkIxXFJCNFxSQjdcUkI4XFJCOSBhcmUgYWxsIGVkZ2UgUkJzLCBi eSBkZWZhdWx0LCBlYWNoIHdpbGwgY2hvb3NlIHRoZSBzaG9ydGVzdCBwYXRooa9zIHRyZWUgcm9v dCB0byB1c2UsDQphbmQgZWFjaCBtYXkgdXNlIHRoZSB0d28gdHJlZXMgdG8gbXVsdGlwYXRoaW5n IG11bHRpLWRlc3RpbmF0aW9uIHRyYWZmaWMgYXQgdGhlIHNhbWUgdGltZS4NCkJ1dCBpZiB3ZSBo YXZlIFJCMSBhbmQgUkI3IGluIGEgUkJ2LCB0aGVuIHdlIGhhdmUgdG8gYWxsb2NhdGUgZGlmZmVy ZW50IHRyZWVzIGJldHdlZW4gUkIxIGFuZCBSQjcuDQpXaXRoIHRoZSBjdXJyZW50IENNVCBtYW5u ZXIsIG1heWJlIFJCeiBpcyBhbGxvY2F0ZWQgdG8gUkIxLCBSQnkgaXMgYWxsb2NhdGVkIHRvIFJC Ny4NCk9idmlvdXNseSxSQjEgaXMgY2xvc2VyIHRvIFJCeSwgc28gdGhlIG5ldHdvcmsgbWFuYWdl ciBtYXkgd2FudCB0byBtYW51YWxseSBjb25maWd1cmUgUkJ5IHRvIFJCMSBhcyBhbiBhbGdvcml0 aG0gaW50ZXJ2ZW50aW9uLg0KDQpBcyB0aGUgbG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlIG1h dHRlciwgaG93IHRvIGNvbXBhdGlibGUgd2l0aCBtYW51YWwgY29uZmlndXJhdGlvbiwgbWF5YmUg aXQgaXMgYSBxdWVzdGlvbiB3aXRoaW4gdGhlIFJCdidzIHRyZWUgYWxsb2NhdGlvbj8NCg0KSSB0 aGluayB0aGlzIG1heSBiZSBzb2x2ZWQgYnkgY2hvb3NpbmcgYSBtZW1iZXIgUkIsIHdoaWNoIGlz IHVzZWQgdG8gY29sbGVjdCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIG9mIFJCdiwNCmFuZCBl eGVjdXRlIGFuIHVuaWZpZWQgYWxnb3JpdGhtIHRvIGFsbG9jYXRlIHRyZWVzIGZvciBhbGwgbWVt YmVycyB3aXRoaW4gdGhlIHNhbWUgUkJ2Lg0KVGhlcmUgYXJlIHR3byBiZW5lZml0cyBieSBkb2lu ZyBzbzogZmlyc3QsIGl0IGlzIGNvbXBhdGlibGUsIHNlY29uZCB0aGVyZSBpcyBubyBuZWVkIGZv ciBhbGwgb3RoZXIgbWVtYmVyIFJCcyB0byBleGVjdXRlIHRoZSBhbGdvcml0aG0uDQoNClRoYW5r cywNClRpbmENCiJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2Nv LmNvbTxtYWlsdG86dHNlbmV2aXJAY2lzY28uY29tPj4NCreivP7IyzogIHRyaWxsLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+DQoNCjIwMTItMTEtMjYgMjM6 NDQNCg0KDQrK1bz+yMsNCg0KImxpYW8udGluZ0B6dGUuY29tLmNuPG1haWx0bzpsaWFvLnRpbmdA enRlLmNvbS5jbj4iIDxsaWFvLnRpbmdAenRlLmNvbS5jbjxtYWlsdG86bGlhby50aW5nQHp0ZS5j b20uY24+Pg0KDQqzrcvNDQoNCiJ0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+ IiA8dHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPj4NCg0K1vfM4g0KDQpSZTog W3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhpIFRp bmENCg0KQW5zd2VyIGlzIG5vIG5lZWQgYW5kIGl0IGlzIGFscmVhZHkgYnVpbHQgaW4uIEhlcmUg aXMgd2h5LiBXZSBwcm9wb3NlIHRvIGFubm91bmNlIHRoZSBBZmZpbml0eSBDYXBhYmlsaXR5LiAg Q01UIHNwZWNpZmljYXRpb24gaXMgdGhhdCBSQnJpZGdlIGFubm91bmNpbmcgdGhhdCBjYXBhYmls aXR5IG11c3QgZm9sbG93IHRoZSBzcGVjaWZpZWQgdHJlZSBhbGxvY2F0aW9uLiBJZiBzb21lIFJC cmlkZ2UgaXMgYW5ub3VuY2luZyB0aGUgYWZmaW5pdHkgY2FwYWJpbGl0eSBhbmQgeWV0IGRvaW5n IG1hbnVhbCBhbGxvY2F0aW9uIHRoZW4gaXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZXJyb3Igb3Ig bG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlIG1hdHRlci4NCg0KVGhhbmtzDQpUaXNzYQ0KDQpG cm9tOiBsaWFvLnRpbmdAenRlLmNvbS5jbjxtYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY24+IFtt YWlsdG86bGlhby50aW5nQHp0ZS5jb20uY25dDQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDI1LCAy MDEyIDU6MTkgUE0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHRyaWxs QGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RyaWxsXSBkcmFm dC1pZXRmLXRyaWxsLWNtdA0KDQoNCkhpLFRpc3NhDQoNClllc6OsdGhhdCdzIGV4YWN0bHkgd2hh dCBJIG1lYW4uIDopDQpTaG91bGQgdGhlIENNVCB0YWtlIHRoaXMgc2NlbmFyaW8gaW50byBhY2Nv dW50o78NCg0KVGhhbmtzLA0KVGluYQ0KIlRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8 dHNlbmV2aXJAY2lzY28uY29tPG1haWx0bzp0c2VuZXZpckBjaXNjby5jb20+Pg0Kt6K8/sjLOiAg dHJpbGwtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZz4NCg0K MjAxMi0xMS0yNiAwMDo1MA0KDQoNCg0KDQrK1bz+yMsNCg0KImxpYW8udGluZ0B6dGUuY29tLmNu PG1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj4iIDxsaWFvLnRpbmdAenRlLmNvbS5jbjxtYWls dG86bGlhby50aW5nQHp0ZS5jb20uY24+Pg0KDQqzrcvNDQoNCiJ0cmlsbEBpZXRmLm9yZzxtYWls dG86dHJpbGxAaWV0Zi5vcmc+IiA8dHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3Jn Pj4NCg0K1vfM4g0KDQpSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdA0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCkhpIFRpbmENCg0KSSBhbSBub3Qgc3VyZSBJIGNvbXBsZXRlbHkg dW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uLiBBcmUgeW91IHJlZmVycmluZyB0byBhIHNjZW5hcmlv IHdoZXJlIHNvbWUgb2YgdGhlIG1lbWJlcnMgKGUuZy4gUkIxICkgYXJlIHVzaW5nIHNvbWUgbWFu dWFsIGNvbmZpZ3VyYXRpb24gYW5kIG90aGVyIGlzIHVzaW5nIHRoZSBwcm9wb3NlZCBtZXRob2Qg KGUuZy4gUkIyKSBpbiB0aGUgQ01UIGRyYWZ0ID8NCg0KUFM6IEJvdGggUkIxIGFuZCBSQjIgYXJl IG1lbWJlcnMgb2YgdGhlIHZpcnR1YWwgUkJyaWRnZSBSQnYNCg0KRnJvbTogbGlhby50aW5nQHp0 ZS5jb20uY248bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPiBbbWFpbHRvOmxpYW8udGluZ0B6 dGUuY29tLmNuXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIyLCAyMDEyIDEwOjA1IFBNDQpU bzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiB0cmlsbEBpZXRmLm9yZzxtYWls dG86dHJpbGxAaWV0Zi5vcmc+OyB0cmlsbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmlsbC1i b3VuY2VzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1j bXQNCg0KDQpIaSxUaXNzYQ0KDQpTZWN0aW9uIDUuMSBwcm92aWRlcyBhIHNpbXBsZSBnZW5lcmFs IG1ldGhvZCB0byBhc3NpZ24gZGlmZmVyZW50IHRyZWVzIHRvIGRpZmZlcmVudCBtZW1iZXJzIGFu ZCBpdCBpcyBlYXN5IHRvIGVtcGxveS4NCkJ1dCBpbiBteSBvcGluaW9uLCBpdCBjb3VsZCBiZSBi ZXR0ZXIgdG8gYWxsb3cgY28tZXhpc3RlbmNlIG9mIGRlZmF1bHQgbWFubmVyo6hjbXSjqSBhbmQg bWFudWFsIGNvbmZpZ3VyYXRpb24NCmZvciBkaXN0cmlidXRpb24gdHJlZSBjaG9vc2luZ6Osb3Ro ZXJ3aXNlIGlmIHNvbWUgbWVtYmVyIFJCcyBhcmUgbWFudWFsbHkgY29uZmlndXJlZCBhbmQgb3Ro ZXJzIGFyZSBub3QgY29uZmlndXJlZCBhdCBhbGwsDQpjb21wYXRpYmlsaXR5IHByb2JsZW0gd2l0 aCB0aGUgY3VycmVudCBhbGdvcml0aG0gY291bGQgb2NjdXIuDQpTbywgbWF5YmUgd2Ugc2hvdWxk IHByb3ZpZGUgYSB1bmlmaWVkIHRyZWUgZGlzdHJpYnV0aW9uIG1ldGhvZCB3aGljaCBpcyBjb21w YXRpYmxlDQp3aXRoIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBjYW4gZW5zdXJlIGRpZmZlcmVu dCBtZW1iZXIgUkJzIG9idGFpbiBkaWZmZXJlbnQgIGRpc3RyaWJ1dGlvbiB0cmVlPw0KDQpUaGFu a3MsDQpUaW5hIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGxfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0 DQp0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmc8bWFp bHRvOnRyaWxsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmlsbA0K --_000_FBEA3E19AA24F847BA3AE74E2FE19356288761EDxmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Tina=

 <= /p>

I must admit, I did not f= ully understand what you mean by some of the items below<= /p>

 <= /p>

1=A3=A9how to choose the member RB

Current proposal is to consider all RBridges announc= ing nickname RBv to be members.
2=A3=A9how the= chosen member RB  to collect the tree configured information

[not clear with wha= t you meant]
3=A3=A9how to = announce the tree allocation information<= o:p>

[currently, each RBridge = use a standard algorithm and all RBridges can deduce the trees used by memb= er RBridges RBv]

 <= /p>

If you want more complex = and extensible solution, I think it is best to write a separate draft.

 <= /p>

Thanks<= /p>

Tissa

From: liao.tin= g@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Tuesday, November 27, 2012 7:16 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: =B4= =F0=B8=B4: Re: [trill] draft-ietf-trill-cmt

 


Hi,Tissa

IMO, maybe the following informations shou= ld be standarded:
1=A3=A9how to = choose the member RB
2=A3=A9how the= chosen member RB  to collect the tree configured information
3=A3=A9how to = announce the tree allocation information

And with regard to failover protection, wh= en any other member RB fails,
the failure information should be transmit= ted to the chosen member RB,
and the chosen member RB will reallocate t= rees among member RBs except the failed one.
If the chosen member RB had failure, there= should be a slave chosen member RB elected to be the master.

OK, maybe that will be too complex, and more likely to be a loca= l administrative policy, but if the CMT mention about that, it will be more= impeccable. :)

Thanks,
Tina


"Tissa Senevirathne (tsenevir)&quo= t; <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf= .org

2012-11-27 23:34

=CA=D5=BC=FE=C8=CB<= /p>

"liao.ting@zte.com.cn" <liao.ting@zte.com.cn>

=B3=AD=CB=CD

"trill-bounces@ietf.org" <trill-bounces@ietf.org>, "trill@ietf.org" <trill@ietf.org> <= /o:p>

=D6=F7=CC=E2

Re: [trill] draft-ietf-trill-cmt

 




Hi Tina
 
What you are looking at is a local administrativ= e policy, I am not clear what to be specified in a standard. Additionally m= anual configurations does not provide failover protection. I think it is best to leave the administrative policies to platforms.
 
Additionally, when multiple tree allocation algo= rithms are present, we need to ensure that all of the RBv are using the exa= ct same algorithm, which will make matters complicated. So in short, if one would like to use a different algorithm than what is s= pecified in the standard, it is up to them to do so and ensure that they me= et
 
1.       Failover requirements
2.       Algorithm consistency be= tween members
 
Thanks
Tissa
 
 
From: liao.ting@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Tuesday, November 27, 2012 1:22 AM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt
 =

Hi,Tissa

Maybe the CMT is just to announce the Affinity Capability, IMO, the CMT is = used to solve the tree allocation problem in RBv.
Such as the figure described in RFC6325 P93 for example: the network manage= r may be want to do some manual configuration in the situation.
                     = ;        +---+
                     = ;        |RBy|---------------+
                     = ;        +---+         &nbs= p;     |
                     = ;       /  |  \          =    |
                     = ;     /    |    \        =    |
                     = ;   /      |      \      =    |
                     = ;+---+   +---+   +---+     &nbs= p; |
                     = ;|RB1|---|RB2|---|RB3|       |
                     = ;+---+   +---+   +---+\     &nb= sp;|
                     = ;  |       |       |    \ &nbs= p;  |
                     = ;+---+   +---+   +---+    \+= ;---+
                     = ;|RB4|---|RB5|---|RB6|-----|RBz|
                     = ;+---+   +---+   +---+    /+= ;---+
                     = ;  |       |       |    /
                     = ;+---+   +---+   +---+/
                     = ;|RB7|---|RB8|---|RB9|
                     = ;+---+   +---+   +---+
There are two distribution trees in the network, one rooted at RBy will pre= dominantly use the vertical links among RB1 through RB9
while another rooted at RBz will predominantly use the horizontal.
RB1\RB4\RB7\RB8\RB9 are all edge RBs, by default, each will choose the shor= test path=A1=AFs tree root to use,
and each may use the two trees to multipathing multi-destination traffic at= the same time.  
But if we have RB1 and RB7 in a RBv, then we have to allocate different tre= es between RB1 and RB7.
With the current CMT manner, maybe RBz is allocated to RB1, RBy is allocate= d to RB7.
Obviously,RB1 is closer to RBy, so the network manager may want to manually= configure RBy to RB1 as an algorithm intervention.

As the local policy/administrative matter, how to compatible with manual co= nfiguration, maybe it is a question within the RBv's tree allocation?

I think this may be solved by choosing a member RB, which is used to collec= t configuration information of RBv,
and execute an unified algorithm to allocate trees for all members within t= he same RBv.
There are two benefits by doing so: first, it is compatible, second there i= s no need for all other member RBs to execute the algorithm.

Thanks,
Tina

"Tissa Senevirathne (tsenevir)&quo= t; <tsenev= ir@cisco.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf.org

2012-11-26 23:44

 

=CA=D5=BC=FE=C8=CB<= /p>

"liao.ting@zte.com.cn" <liao.ting@zte= .com.cn>

=B3=AD=CB=CD

"trill@ietf.org" <trill@ietf.org>

=D6=F7=CC=E2

Re: [trill] draft-ietf-trill-cmt


 =

 





Hi Tina
 
Answer is no need and it is already built in. Here is why. We propose to an= nounce the Affinity Capability.  CMT specification is that RBridge ann= ouncing that capability must follow the specified tree allocation. If some = RBridge is announcing the affinity capability and yet doing manual allocation then it is an implementation error or loca= l policy/administrative matter.
 
Thanks
Tissa
 
From: liao.ting@zte.co= m.cn [mailto:liao.ting@zte.com.cn]
Sent: Sunday, November 25, 2012 5:19 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org= ; trill-bounces@= ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt
 

Hi,Tissa

Yes=A3=ACthat's exactly what I mean. :)
Should the CMT take this scenario into account=A3=BF

Thanks,
Tina

"Tissa Senevirathne (tsenevir)&quo= t; <tsenev= ir@cisco.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf.org

2012-11-26 00:50

 

 

=CA=D5=BC=FE=C8=CB<= /p>

"liao.ting@zte.com.cn" <liao.ting@zte= .com.cn>

=B3=AD=CB=CD

"trill@ietf.org" <trill@ietf.org>

=D6=F7=CC=E2

Re: [trill] draft-ietf-trill-cmt



 

&nb= sp;

 




Hi Tina

I am not sure I completely understand your question. Are you referring to a= scenario where some of the members (e.g. RB1 ) are using some manual confi= guration and other is using the proposed method (e.g. RB2) in the CMT draft= ?

PS: Both RB1 and RB2 are members of the virtual RBridge RBv

From: liao.ting@zte.co= m.cn [mailto:liao.ting@zte.com.cn]
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org= ; trill-bounces@= ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt


Hi,Tissa

Section 5.1 provides a simple general method to assign different trees to d= ifferent members and it is easy to employ.
But in my opinion, it could be better to allow co-existence of default mann= er=A3=A8cmt=A3=A9 and manual configuration
for distribution tree choosing=A3=ACotherwise if some member RBs are manually= configured and others are not configured at all,
compatibility problem with the current algorithm could occur.
So, maybe we should provide a unified tree distribution method which is com= patible
with manual configuration and can ensure different member RBs obtain differ= ent  distribution tree?

Thanks,
Tina _______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill_______= ________________________________________
trill mailing list
trill@ietf.o= rg
https://www.ietf.org/mailman/listinfo/trill_______________________________________________
trill mailing list
trill@ietf.org
https://www.iet= f.org/mailman/listinfo/trill

--_000_FBEA3E19AA24F847BA3AE74E2FE19356288761EDxmbrcdx08ciscoc_-- From liao.ting@zte.com.cn Tue Nov 27 22:20:54 2012 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 94D2321F8464; Tue, 27 Nov 2012 22:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.678 X-Spam-Level: X-Spam-Status: No, score=-97.678 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMl4l1bEk4xi; Tue, 27 Nov 2012 22:20:53 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 65DE421F8461; Tue, 27 Nov 2012 22:20:52 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id BC655126C3BC; Wed, 28 Nov 2012 14:22:25 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 90F935F7C52; Wed, 28 Nov 2012 14:18:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qAS6KcWX052056; Wed, 28 Nov 2012 14:20:38 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) In-Reply-To: To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-KeepSent: 43F2AED5:6EDBEF46-48257AC4:0014EA56; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liao.ting@zte.com.cn Date: Wed, 28 Nov 2012 14:20:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-28 14:20:23, Serialize complete at 2012-11-28 14:20:23 Content-Type: multipart/alternative; boundary="=_alternative 0022D98648257AC4_=" X-MAIL: mse01.zte.com.cn qAS6KcWX052056 Cc: "trill-bounces@ietf.org" , "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 06:20:54 -0000 This is a multipart message in MIME format. --=_alternative 0022D98648257AC4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksVGlzc2ENCg0KVGhhbmsgeW91IGZvciB5b3VyIHF1aWNrIHJlcGx5LiA6KQ0KQW5kIG1heWJl IG15IGRpc2NyaXB0aW9uIGlzIG5vdCBjbGVhciwganVzdCBhcyB5b3Ugc2FpZCwgaXQncyBhIGJp dCANCmNvbXBsaWNhdGVkLg0KDQpUaGFua3MsDQpUaW5hDQoNCg0KDQoNCiJUaXNzYSBTZW5ldmly YXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4gDQq3orz+yMs6ICB0cmlsbC1i b3VuY2VzQGlldGYub3JnDQoyMDEyLTExLTI4IDExOjQ1DQoNCsrVvP7Iyw0KImxpYW8udGluZ0B6 dGUuY29tLmNuIiA8bGlhby50aW5nQHp0ZS5jb20uY24+DQqzrcvNDQoidHJpbGwtYm91bmNlc0Bp ZXRmLm9yZyIgPHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+LCAidHJpbGxAaWV0Zi5vcmciIA0KPHRy aWxsQGlldGYub3JnPg0K1vfM4g0KUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQNCg0K DQoNCg0KDQoNCkhpIFRpbmENCiANCkkgbXVzdCBhZG1pdCwgSSBkaWQgbm90IGZ1bGx5IHVuZGVy c3RhbmQgd2hhdCB5b3UgbWVhbiBieSBzb21lIG9mIHRoZSANCml0ZW1zIGJlbG93DQogDQoxo6lo b3cgdG8gY2hvb3NlIHRoZSBtZW1iZXIgUkIgDQpDdXJyZW50IHByb3Bvc2FsIGlzIHRvIGNvbnNp ZGVyIGFsbCBSQnJpZGdlcyBhbm5vdW5jaW5nIG5pY2tuYW1lIFJCdiB0byBiZSANCm1lbWJlcnMu DQoyo6lob3cgdGhlIGNob3NlbiBtZW1iZXIgUkIgIHRvIGNvbGxlY3QgdGhlIHRyZWUgY29uZmln dXJlZCBpbmZvcm1hdGlvbg0KW25vdCBjbGVhciB3aXRoIHdoYXQgeW91IG1lYW50XSANCjOjqWhv dyB0byBhbm5vdW5jZSB0aGUgdHJlZSBhbGxvY2F0aW9uIGluZm9ybWF0aW9uDQpbY3VycmVudGx5 LCBlYWNoIFJCcmlkZ2UgdXNlIGEgc3RhbmRhcmQgYWxnb3JpdGhtIGFuZCBhbGwgUkJyaWRnZXMg Y2FuIA0KZGVkdWNlIHRoZSB0cmVlcyB1c2VkIGJ5IG1lbWJlciBSQnJpZGdlcyBSQnZdDQogDQpJ ZiB5b3Ugd2FudCBtb3JlIGNvbXBsZXggYW5kIGV4dGVuc2libGUgc29sdXRpb24sIEkgdGhpbmsg aXQgaXMgYmVzdCB0byANCndyaXRlIGEgc2VwYXJhdGUgZHJhZnQuIA0KIA0KVGhhbmtzDQpUaXNz YQ0KRnJvbTogbGlhby50aW5nQHp0ZS5jb20uY24gW21haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5j bl0gDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMiA3OjE2IFBNDQpUbzogVGlzc2Eg U2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiB0cmlsbEBpZXRmLm9yZzsgdHJpbGwtYm91bmNl c0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1j bXQNCiANCg0KSGksVGlzc2EgDQoNCklNTywgbWF5YmUgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlv bnMgc2hvdWxkIGJlIHN0YW5kYXJkZWQ6IA0KMaOpaG93IHRvIGNob29zZSB0aGUgbWVtYmVyIFJC IA0KMqOpaG93IHRoZSBjaG9zZW4gbWVtYmVyIFJCICB0byBjb2xsZWN0IHRoZSB0cmVlIGNvbmZp Z3VyZWQgaW5mb3JtYXRpb24gDQozo6lob3cgdG8gYW5ub3VuY2UgdGhlIHRyZWUgYWxsb2NhdGlv biBpbmZvcm1hdGlvbiANCg0KQW5kIHdpdGggcmVnYXJkIHRvIGZhaWxvdmVyIHByb3RlY3Rpb24s IHdoZW4gYW55IG90aGVyIG1lbWJlciBSQiBmYWlscywgDQp0aGUgZmFpbHVyZSBpbmZvcm1hdGlv biBzaG91bGQgYmUgdHJhbnNtaXR0ZWQgdG8gdGhlIGNob3NlbiBtZW1iZXIgUkIsIA0KYW5kIHRo ZSBjaG9zZW4gbWVtYmVyIFJCIHdpbGwgcmVhbGxvY2F0ZSB0cmVlcyBhbW9uZyBtZW1iZXIgUkJz IGV4Y2VwdCB0aGUgDQpmYWlsZWQgb25lLiANCklmIHRoZSBjaG9zZW4gbWVtYmVyIFJCIGhhZCBm YWlsdXJlLCB0aGVyZSBzaG91bGQgYmUgYSBzbGF2ZSBjaG9zZW4gbWVtYmVyIA0KUkIgZWxlY3Rl ZCB0byBiZSB0aGUgbWFzdGVyLiANCg0KT0ssIG1heWJlIHRoYXQgd2lsbCBiZSB0b28gY29tcGxl eCwgYW5kIG1vcmUgbGlrZWx5IHRvIGJlIGEgbG9jYWwgDQphZG1pbmlzdHJhdGl2ZSBwb2xpY3ks IGJ1dCBpZiB0aGUgQ01UIG1lbnRpb24gYWJvdXQgdGhhdCwgaXQgd2lsbCBiZSBtb3JlIA0KaW1w ZWNjYWJsZS4gOikgDQoNClRoYW5rcywNClRpbmEgDQoNCg0KDQoiVGlzc2EgU2VuZXZpcmF0aG5l ICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNjby5jb20+IA0Kt6K8/sjLOiAgdHJpbGwtYm91bmNl c0BpZXRmLm9yZyANCjIwMTItMTEtMjcgMjM6MzQgDQoNCg0KytW8/sjLDQoibGlhby50aW5nQHp0 ZS5jb20uY24iIDxsaWFvLnRpbmdAenRlLmNvbS5jbj4gDQqzrcvNDQoidHJpbGwtYm91bmNlc0Bp ZXRmLm9yZyIgPHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+LCAidHJpbGxAaWV0Zi5vcmciIDwNCnRy aWxsQGlldGYub3JnPiANCtb3zOINClJlOiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwtY210DQog DQoNCg0KDQoNCg0KDQoNCg0KSGkgVGluYSANCiAgDQpXaGF0IHlvdSBhcmUgbG9va2luZyBhdCBp cyBhIGxvY2FsIGFkbWluaXN0cmF0aXZlIHBvbGljeSwgSSBhbSBub3QgY2xlYXIgDQp3aGF0IHRv IGJlIHNwZWNpZmllZCBpbiBhIHN0YW5kYXJkLiBBZGRpdGlvbmFsbHkgbWFudWFsIGNvbmZpZ3Vy YXRpb25zIA0KZG9lcyBub3QgcHJvdmlkZSBmYWlsb3ZlciBwcm90ZWN0aW9uLiBJIHRoaW5rIGl0 IGlzIGJlc3QgdG8gbGVhdmUgdGhlIA0KYWRtaW5pc3RyYXRpdmUgcG9saWNpZXMgdG8gcGxhdGZv cm1zLiANCiAgDQpBZGRpdGlvbmFsbHksIHdoZW4gbXVsdGlwbGUgdHJlZSBhbGxvY2F0aW9uIGFs Z29yaXRobXMgYXJlIHByZXNlbnQsIHdlIA0KbmVlZCB0byBlbnN1cmUgdGhhdCBhbGwgb2YgdGhl IFJCdiBhcmUgdXNpbmcgdGhlIGV4YWN0IHNhbWUgYWxnb3JpdGhtLCANCndoaWNoIHdpbGwgbWFr ZSBtYXR0ZXJzIGNvbXBsaWNhdGVkLiBTbyBpbiBzaG9ydCwgaWYgb25lIHdvdWxkIGxpa2UgdG8g dXNlIA0KYSBkaWZmZXJlbnQgYWxnb3JpdGhtIHRoYW4gd2hhdCBpcyBzcGVjaWZpZWQgaW4gdGhl IHN0YW5kYXJkLCBpdCBpcyB1cCB0byANCnRoZW0gdG8gZG8gc28gYW5kIGVuc3VyZSB0aGF0IHRo ZXkgbWVldCANCiAgDQoxLiAgICAgICBGYWlsb3ZlciByZXF1aXJlbWVudHMgDQoyLiAgICAgICBB bGdvcml0aG0gY29uc2lzdGVuY3kgYmV0d2VlbiBtZW1iZXJzIA0KICANClRoYW5rcyANClRpc3Nh IA0KICANCiAgDQpGcm9tOiBsaWFvLnRpbmdAenRlLmNvbS5jbiBbbWFpbHRvOmxpYW8udGluZ0B6 dGUuY29tLmNuXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEyIDE6MjIgQU0NClRv OiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHRyaWxsQGlldGYub3JnOyB0cmls bC1ib3VuY2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxs LWNtdCANCiAgDQoNCkhpLFRpc3NhIA0KDQpNYXliZSB0aGUgQ01UIGlzIGp1c3QgdG8gYW5ub3Vu Y2UgdGhlIEFmZmluaXR5IENhcGFiaWxpdHksIElNTywgdGhlIENNVCBpcyANCnVzZWQgdG8gc29s dmUgdGhlIHRyZWUgYWxsb2NhdGlvbiBwcm9ibGVtIGluIFJCdi4gDQpTdWNoIGFzIHRoZSBmaWd1 cmUgZGVzY3JpYmVkIGluIFJGQzYzMjUgUDkzIGZvciBleGFtcGxlOiB0aGUgbmV0d29yayANCm1h bmFnZXIgbWF5IGJlIHdhbnQgdG8gZG8gc29tZSBtYW51YWwgY29uZmlndXJhdGlvbiBpbiB0aGUg c2l0dWF0aW9uLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSsgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHxSQnl8LS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC8gIHwgIFwgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAg ICAgICAgIC8gICAgfCAgICBcICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAgICAg IC8gICAgICB8ICAgICAgXCAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgKy0tLSsg ICArLS0tKyAgICstLS0rICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgICB8UkIxfC0tLXxS QjJ8LS0tfFJCM3wgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAgICstLS0rICAgKy0tLSsg ICArLS0tK1wgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAg fCAgICBcICAgIHwgDQogICAgICAgICAgICAgICAgICAgICArLS0tKyAgICstLS0rICAgKy0tLSsg ICAgXCstLS0rIA0KICAgICAgICAgICAgICAgICAgICAgfFJCNHwtLS18UkI1fC0tLXxSQjZ8LS0t LS18UkJ6fCANCiAgICAgICAgICAgICAgICAgICAgICstLS0rICAgKy0tLSsgICArLS0tKyAgICAv Ky0tLSsgDQogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgIC8gDQog ICAgICAgICAgICAgICAgICAgICArLS0tKyAgICstLS0rICAgKy0tLSsvIA0KICAgICAgICAgICAg ICAgICAgICAgfFJCN3wtLS18UkI4fC0tLXxSQjl8IA0KICAgICAgICAgICAgICAgICAgICAgKy0t LSsgICArLS0tKyAgICstLS0rIA0KVGhlcmUgYXJlIHR3byBkaXN0cmlidXRpb24gdHJlZXMgaW4g dGhlIG5ldHdvcmssIG9uZSByb290ZWQgYXQgUkJ5IHdpbGwgDQpwcmVkb21pbmFudGx5IHVzZSB0 aGUgdmVydGljYWwgbGlua3MgYW1vbmcgUkIxIHRocm91Z2ggUkI5IA0Kd2hpbGUgYW5vdGhlciBy b290ZWQgYXQgUkJ6IHdpbGwgcHJlZG9taW5hbnRseSB1c2UgdGhlIGhvcml6b250YWwuIA0KUkIx XFJCNFxSQjdcUkI4XFJCOSBhcmUgYWxsIGVkZ2UgUkJzLCBieSBkZWZhdWx0LCBlYWNoIHdpbGwg Y2hvb3NlIHRoZSANCnNob3J0ZXN0IHBhdGihr3MgdHJlZSByb290IHRvIHVzZSwgDQphbmQgZWFj aCBtYXkgdXNlIHRoZSB0d28gdHJlZXMgdG8gbXVsdGlwYXRoaW5nIG11bHRpLWRlc3RpbmF0aW9u IHRyYWZmaWMgDQphdCB0aGUgc2FtZSB0aW1lLiAgIA0KQnV0IGlmIHdlIGhhdmUgUkIxIGFuZCBS QjcgaW4gYSBSQnYsIHRoZW4gd2UgaGF2ZSB0byBhbGxvY2F0ZSBkaWZmZXJlbnQgDQp0cmVlcyBi ZXR3ZWVuIFJCMSBhbmQgUkI3LiANCldpdGggdGhlIGN1cnJlbnQgQ01UIG1hbm5lciwgbWF5YmUg UkJ6IGlzIGFsbG9jYXRlZCB0byBSQjEsIFJCeSBpcyANCmFsbG9jYXRlZCB0byBSQjcuIA0KT2J2 aW91c2x5LFJCMSBpcyBjbG9zZXIgdG8gUkJ5LCBzbyB0aGUgbmV0d29yayBtYW5hZ2VyIG1heSB3 YW50IHRvIA0KbWFudWFsbHkgY29uZmlndXJlIFJCeSB0byBSQjEgYXMgYW4gYWxnb3JpdGhtIGlu dGVydmVudGlvbi4gDQoNCkFzIHRoZSBsb2NhbCBwb2xpY3kvYWRtaW5pc3RyYXRpdmUgbWF0dGVy LCBob3cgdG8gY29tcGF0aWJsZSB3aXRoIG1hbnVhbCANCmNvbmZpZ3VyYXRpb24sIG1heWJlIGl0 IGlzIGEgcXVlc3Rpb24gd2l0aGluIHRoZSBSQnYncyB0cmVlIGFsbG9jYXRpb24/IA0KDQpJIHRo aW5rIHRoaXMgbWF5IGJlIHNvbHZlZCBieSBjaG9vc2luZyBhIG1lbWJlciBSQiwgd2hpY2ggaXMg dXNlZCB0byANCmNvbGxlY3QgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBvZiBSQnYsIA0KYW5k IGV4ZWN1dGUgYW4gdW5pZmllZCBhbGdvcml0aG0gdG8gYWxsb2NhdGUgdHJlZXMgZm9yIGFsbCBt ZW1iZXJzIHdpdGhpbiANCnRoZSBzYW1lIFJCdi4gDQpUaGVyZSBhcmUgdHdvIGJlbmVmaXRzIGJ5 IGRvaW5nIHNvOiBmaXJzdCwgaXQgaXMgY29tcGF0aWJsZSwgc2Vjb25kIHRoZXJlIA0KaXMgbm8g bmVlZCBmb3IgYWxsIG90aGVyIG1lbWJlciBSQnMgdG8gZXhlY3V0ZSB0aGUgYWxnb3JpdGhtLiAN Cg0KVGhhbmtzLA0KVGluYSANCg0KIlRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNl bmV2aXJAY2lzY28uY29tPiANCreivP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEy LTExLTI2IDIzOjQ0IA0KIA0KDQoNCsrVvP7Iyw0KImxpYW8udGluZ0B6dGUuY29tLmNuIiA8bGlh by50aW5nQHp0ZS5jb20uY24+IA0Ks63LzQ0KInRyaWxsQGlldGYub3JnIiA8dHJpbGxAaWV0Zi5v cmc+IA0K1vfM4g0KUmU6IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQNCg0KICANCiANCg0K DQoNCg0KDQoNCg0KDQoNCkhpIFRpbmEgDQogDQpBbnN3ZXIgaXMgbm8gbmVlZCBhbmQgaXQgaXMg YWxyZWFkeSBidWlsdCBpbi4gSGVyZSBpcyB3aHkuIFdlIHByb3Bvc2UgdG8gDQphbm5vdW5jZSB0 aGUgQWZmaW5pdHkgQ2FwYWJpbGl0eS4gIENNVCBzcGVjaWZpY2F0aW9uIGlzIHRoYXQgUkJyaWRn ZSANCmFubm91bmNpbmcgdGhhdCBjYXBhYmlsaXR5IG11c3QgZm9sbG93IHRoZSBzcGVjaWZpZWQg dHJlZSBhbGxvY2F0aW9uLiBJZiANCnNvbWUgUkJyaWRnZSBpcyBhbm5vdW5jaW5nIHRoZSBhZmZp bml0eSBjYXBhYmlsaXR5IGFuZCB5ZXQgZG9pbmcgbWFudWFsIA0KYWxsb2NhdGlvbiB0aGVuIGl0 IGlzIGFuIGltcGxlbWVudGF0aW9uIGVycm9yIG9yIGxvY2FsIA0KcG9saWN5L2FkbWluaXN0cmF0 aXZlIG1hdHRlci4gDQogDQpUaGFua3MgDQpUaXNzYSANCiANCkZyb206IGxpYW8udGluZ0B6dGUu Y29tLmNuIFttYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY25dIA0KU2VudDogU3VuZGF5LCBOb3Zl bWJlciAyNSwgMjAxMiA1OjE5IFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikN CkNjOiB0cmlsbEBpZXRmLm9yZzsgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFt0cmlsbF0gZHJhZnQtaWV0Zi10cmlsbC1jbXQgDQogDQoNCkhpLFRpc3NhIA0KDQpZZXOjrHRo YXQncyBleGFjdGx5IHdoYXQgSSBtZWFuLiA6KSANClNob3VsZCB0aGUgQ01UIHRha2UgdGhpcyBz Y2VuYXJpbyBpbnRvIGFjY291bnSjvyANCg0KVGhhbmtzLA0KVGluYSANCg0KIlRpc3NhIFNlbmV2 aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPiANCreivP7IyzogIHRyaWxs LWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEyLTExLTI2IDAwOjUwIA0KICANCiANCg0KDQrK1bz+yMsN CiJsaWFvLnRpbmdAenRlLmNvbS5jbiIgPGxpYW8udGluZ0B6dGUuY29tLmNuPiANCrOty80NCiJ0 cmlsbEBpZXRmLm9yZyIgPHRyaWxsQGlldGYub3JnPiANCtb3zOINClJlOiBbdHJpbGxdIGRyYWZ0 LWlldGYtdHJpbGwtY210DQoNCg0KICANCiAgDQogDQoNCg0KDQoNCg0KDQoNCg0KDQpIaSBUaW5h IA0KDQpJIGFtIG5vdCBzdXJlIEkgY29tcGxldGVseSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24u IEFyZSB5b3UgcmVmZXJyaW5nIHRvIA0KYSBzY2VuYXJpbyB3aGVyZSBzb21lIG9mIHRoZSBtZW1i ZXJzIChlLmcuIFJCMSApIGFyZSB1c2luZyBzb21lIG1hbnVhbCANCmNvbmZpZ3VyYXRpb24gYW5k IG90aGVyIGlzIHVzaW5nIHRoZSBwcm9wb3NlZCBtZXRob2QgKGUuZy4gUkIyKSBpbiB0aGUgQ01U IA0KZHJhZnQgPyANCg0KUFM6IEJvdGggUkIxIGFuZCBSQjIgYXJlIG1lbWJlcnMgb2YgdGhlIHZp cnR1YWwgUkJyaWRnZSBSQnYgDQoNCkZyb206IGxpYW8udGluZ0B6dGUuY29tLmNuIFttYWlsdG86 bGlhby50aW5nQHp0ZS5jb20uY25dIA0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIyLCAyMDEy IDEwOjA1IFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiB0cmlsbEBp ZXRmLm9yZzsgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmlsbF0gZHJh ZnQtaWV0Zi10cmlsbC1jbXQgDQoNCg0KSGksVGlzc2EgDQoNClNlY3Rpb24gNS4xIHByb3ZpZGVz IGEgc2ltcGxlIGdlbmVyYWwgbWV0aG9kIHRvIGFzc2lnbiBkaWZmZXJlbnQgdHJlZXMgdG8gDQpk aWZmZXJlbnQgbWVtYmVycyBhbmQgaXQgaXMgZWFzeSB0byBlbXBsb3kuIA0KQnV0IGluIG15IG9w aW5pb24sIGl0IGNvdWxkIGJlIGJldHRlciB0byBhbGxvdyBjby1leGlzdGVuY2Ugb2YgZGVmYXVs dCANCm1hbm5lcqOoY210o6kgYW5kIG1hbnVhbCBjb25maWd1cmF0aW9uIA0KZm9yIGRpc3RyaWJ1 dGlvbiB0cmVlIGNob29zaW5no6xvdGhlcndpc2UgaWYgc29tZSBtZW1iZXIgUkJzIGFyZSBtYW51 YWxseSANCmNvbmZpZ3VyZWQgYW5kIG90aGVycyBhcmUgbm90IGNvbmZpZ3VyZWQgYXQgYWxsLCAN CmNvbXBhdGliaWxpdHkgcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGFsZ29yaXRobSBjb3VsZCBv Y2N1ci4gDQpTbywgbWF5YmUgd2Ugc2hvdWxkIHByb3ZpZGUgYSB1bmlmaWVkIHRyZWUgZGlzdHJp YnV0aW9uIG1ldGhvZCB3aGljaCBpcyANCmNvbXBhdGlibGUgDQp3aXRoIG1hbnVhbCBjb25maWd1 cmF0aW9uIGFuZCBjYW4gZW5zdXJlIGRpZmZlcmVudCBtZW1iZXIgUkJzIG9idGFpbiANCmRpZmZl cmVudCAgZGlzdHJpYnV0aW9uIHRyZWU/IA0KDQpUaGFua3MsDQpUaW5hIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRy aWxsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxs DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwg bWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmlsbA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQoNCg0K --=_alternative 0022D98648257AC4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLFRpc3NhPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuayB5b3UgZm9yIHlvdXIg cXVpY2sgcmVwbHkuIDopPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5BbmQgbWF5YmUgbXkgZGlz Y3JpcHRpb24gaXMgbm90IGNsZWFyLCBqdXN0IGFzIHlvdSBzYWlkLA0KaXQncyBhIGJpdCBjb21w bGljYXRlZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N ClRoYW5rcyw8YnI+DQpUaW5hPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhuZQ0KKHRzZW5ldmly KSZxdW90OyAmbHQ7dHNlbmV2aXJAY2lzY28uY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3RyaWxsLWJvdW5jZXNAaWV0 Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMS0y OCAxMTo0NTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mcXVvdDtsaWFvLnRpbmdAenRlLmNvbS5jbiZxdW90OyAmbHQ7bGlhby50aW5nQHp0 ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDt0cmlsbC1ib3VuY2VzQGlldGYu b3JnJnF1b3Q7ICZsdDt0cmlsbC1ib3VuY2VzQGlldGYub3JnJmd0OywNCiZxdW90O3RyaWxsQGll dGYub3JnJnF1b3Q7ICZsdDt0cmlsbEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwtY210PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ SGkgVGluYTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+SSBtdXN0IGFkbWl0LCBJIGRpZCBub3QgZnVsbHkNCnVuZGVyc3RhbmQgd2hhdCB5 b3UgbWVhbiBieSBzb21lIG9mIHRoZSBpdGVtcyBiZWxvdzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjGjqWhvdyB0byBjaG9vc2UgdGhlIG1lbWJlciBSQjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkN1cnJlbnQgcHJvcG9zYWwgaXMgdG8gY29uc2lkZXIg YWxsDQpSQnJpZGdlcyBhbm5vdW5jaW5nIG5pY2tuYW1lIFJCdiB0byBiZSBtZW1iZXJzLjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KMqOpaG93IHRoZSBjaG9zZW4g bWVtYmVyIFJCICZuYnNwO3RvIGNvbGxlY3QgdGhlIHRyZWUgY29uZmlndXJlZCBpbmZvcm1hdGlv bjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+W25vdCBjbGVhciB3 aXRoIHdoYXQgeW91IG1lYW50XSA8YnI+DQozo6lob3cgdG8gYW5ub3VuY2UgdGhlIHRyZWUgYWxs b2NhdGlvbiBpbmZvcm1hdGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj5bY3VycmVudGx5LCBlYWNoIFJCcmlkZ2UNCnVzZSBhIHN0YW5kYXJk IGFsZ29yaXRobSBhbmQgYWxsIFJCcmlkZ2VzIGNhbiBkZWR1Y2UgdGhlIHRyZWVzIHVzZWQgYnkN Cm1lbWJlciBSQnJpZGdlcyBSQnZdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0 OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5JZiB5b3Ugd2FudCBtb3JlIGNvbXBsZXgNCmFuZCBleHRl bnNpYmxlIHNvbHV0aW9uLCBJIHRoaW5rIGl0IGlzIGJlc3QgdG8gd3JpdGUgYSBzZXBhcmF0ZSBk cmFmdC4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPlRpc3NhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPkZyb206PC9iPiBsaWFvLnRpbmdAenRlLmNvbS5jbiBbbWFpbHRvOmxpYW8udGluZ0B6dGUu Y29tLmNuXQ0KPGI+PGJyPg0KU2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEyIDc6 MTYgUE08Yj48YnI+DQpUbzo8L2I+IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpPGI+PGJy Pg0KQ2M6PC9iPiB0cmlsbEBpZXRmLm9yZzsgdHJpbGwtYm91bmNlc0BpZXRmLm9yZzxiPjxicj4N ClN1YmplY3Q6PC9iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPrTwuLQ8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Og0KUmU6IFt0cmlsbF0gZHJhZnQtaWV0 Zi10cmlsbC1jbXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkhpLFRpc3Nh PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJTU8sIG1heWJlIHRoZSBmb2xsb3dpbmcg aW5mb3JtYXRpb25zIHNob3VsZCBiZSBzdGFuZGFyZGVkOiA8YnI+DQoxo6lob3cgdG8gY2hvb3Nl IHRoZSBtZW1iZXIgUkI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjKjqWhvdyB0aGUgY2hvc2Vu IG1lbWJlciBSQiAmbmJzcDt0byBjb2xsZWN0IHRoZSB0cmVlIGNvbmZpZ3VyZWQgaW5mb3JtYXRp b24NCjxicj4NCjOjqWhvdyB0byBhbm5vdW5jZSB0aGUgdHJlZSBhbGxvY2F0aW9uIGluZm9ybWF0 aW9uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQW5kIHdpdGggcmVnYXJkIHRvIGZh aWxvdmVyIHByb3RlY3Rpb24sIHdoZW4gYW55IG90aGVyIG1lbWJlciBSQiBmYWlscywNCjxicj4N CnRoZSBmYWlsdXJlIGluZm9ybWF0aW9uIHNob3VsZCBiZSB0cmFuc21pdHRlZCB0byB0aGUgY2hv c2VuIG1lbWJlciBSQiwNCjxicj4NCmFuZCB0aGUgY2hvc2VuIG1lbWJlciBSQiB3aWxsIHJlYWxs b2NhdGUgdHJlZXMgYW1vbmcgbWVtYmVyIFJCcyBleGNlcHQNCnRoZSBmYWlsZWQgb25lLiA8YnI+ DQpJZiB0aGUgY2hvc2VuIG1lbWJlciBSQiBoYWQgZmFpbHVyZSwgdGhlcmUgc2hvdWxkIGJlIGEg c2xhdmUgY2hvc2VuIG1lbWJlcg0KUkIgZWxlY3RlZCB0byBiZSB0aGUgbWFzdGVyLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCk9LLCBtYXliZSB0aGF0IHdpbGwgYmUgdG9vIGNvbXBsZXgsIGFu ZCBtb3JlIGxpa2VseSB0byBiZSBhIGxvY2FsIGFkbWluaXN0cmF0aXZlDQpwb2xpY3ksIGJ1dCBp ZiB0aGUgQ01UIG1lbnRpb24gYWJvdXQgdGhhdCwgaXQgd2lsbCBiZSBtb3JlIGltcGVjY2FibGUu DQo6KTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpUaW5hPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPHA+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQyJT48Zm9udCBz aXplPTEgZmFjZT0iQXJpYWwiPjxiPiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIp JnF1b3Q7DQombHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzp0c2VuZXZpckBjaXNjby5jb20+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxiPjx1PnRzZW5ldmlyQGNpc2Nv LmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZndDs8 L2I+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCreivP7Iyzwv Zm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjogJm5ic3A7PC9mb250PjxhIGhyZWY9Im1h aWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+PHU+dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+MjAxMi0xMS0yNyAyMzozNDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NTclPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD03JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MiU+ PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bGlh by50aW5nQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1 PmxpYW8udGluZ0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFy aWFsIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bGlhby50aW5nQHp0ZS5jb20u Y24+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PmxpYW8udGluZ0B6dGUu Y29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ozwv Zm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBo cmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJs dWUgZmFjZT0iQXJpYWwiPjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDssDQomcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWls dG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1 PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4m cXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6 ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlJlOiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJp bGwtY210PC9mb250PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkhpIFRpbmE8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPjxicj4NCldoYXQgeW91IGFyZSBsb29raW5nIGF0IGlzIGEgbG9jYWwg YWRtaW5pc3RyYXRpdmUgcG9saWN5LCBJIGFtIG5vdCBjbGVhcg0Kd2hhdCB0byBiZSBzcGVjaWZp ZWQgaW4gYSBzdGFuZGFyZC4gQWRkaXRpb25hbGx5IG1hbnVhbCBjb25maWd1cmF0aW9ucw0KZG9l cyBub3QgcHJvdmlkZSBmYWlsb3ZlciBwcm90ZWN0aW9uLiBJIHRoaW5rIGl0IGlzIGJlc3QgdG8g bGVhdmUgdGhlIGFkbWluaXN0cmF0aXZlDQpwb2xpY2llcyB0byBwbGF0Zm9ybXMuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQpBZGRpdGlvbmFsbHksIHdoZW4gbXVsdGlwbGUgdHJlZSBhbGxvY2F0aW9u IGFsZ29yaXRobXMgYXJlIHByZXNlbnQsIHdlDQpuZWVkIHRvIGVuc3VyZSB0aGF0IGFsbCBvZiB0 aGUgUkJ2IGFyZSB1c2luZyB0aGUgZXhhY3Qgc2FtZSBhbGdvcml0aG0sDQp3aGljaCB3aWxsIG1h a2UgbWF0dGVycyBjb21wbGljYXRlZC4gU28gaW4gc2hvcnQsIGlmIG9uZSB3b3VsZCBsaWtlIHRv DQp1c2UgYSBkaWZmZXJlbnQgYWxnb3JpdGhtIHRoYW4gd2hhdCBpcyBzcGVjaWZpZWQgaW4gdGhl IHN0YW5kYXJkLCBpdCBpcw0KdXAgdG8gdGhlbSB0byBkbyBzbyBhbmQgZW5zdXJlIHRoYXQgdGhl eSBtZWV0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KMS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmFp bG92ZXIgcmVxdWlyZW1lbnRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQoy LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGdvcml0aG0gY29uc2lzdGVuY3kgYmV0d2VlbiBtZW1i ZXJzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhhbmtzPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPjxicj4NClRpc3NhPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRh aG9tYSI+PGI+PGJyPg0KRnJvbTo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzpsaWFvLnRpbmdA enRlLmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmxpYW8u dGluZ0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ DQpbPC9mb250PjxhIGhyZWY9bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNu PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2Vu dDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEyIDE6MjIgQU08Yj48YnI+DQpUbzo8L2I+ IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpPGI+PGJyPg0KQ2M6PC9iPiA8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i VGFob21hIj48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjsNCjwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9y ZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT50cmlsbC1ib3VuY2Vz QGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJy Pg0KU3ViamVjdDo8L2I+IFJlOiBbdHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwtY210PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i QXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkhpLFRpc3NhPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NCjxicj4NCk1heWJlIHRoZSBDTVQgaXMganVzdCB0byBhbm5vdW5jZSB0aGUg QWZmaW5pdHkgQ2FwYWJpbGl0eSwgSU1PLCB0aGUgQ01UDQppcyB1c2VkIHRvIHNvbHZlIHRoZSB0 cmVlIGFsbG9jYXRpb24gcHJvYmxlbSBpbiBSQnYuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJB cmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpTdWNoIGFzIHRo ZSBmaWd1cmUgZGVzY3JpYmVkIGluIFJGQzYzMjUgUDkzIGZvciBleGFtcGxlOiB0aGUgbmV0d29y ayBtYW5hZ2VyDQptYXkgYmUgd2FudCB0byBkbyBzb21lIG1hbnVhbCBjb25maWd1cmF0aW9uIGlu IHRoZSBzaXR1YXRpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgKy0tLSs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHxSQnl8LS0tLS0tLS0tLS0tLS0tKzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICstLS0rICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgfDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvICZuYnNw O3wgJm5ic3A7XCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7fDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOy8g Jm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwO1wgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7fDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7LyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDtcICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJp YWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQorLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnxSQjF8LS0tfFJCMnwtLS18UkIzfCAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQorLS0tKyAm bmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rXCAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7XCAmbmJzcDsNCiZuYnNwO3w8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KKy0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyArLS0tKyAm bmJzcDsgJm5ic3A7XCstLS0rPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQp8UkI0fC0t LXxSQjV8LS0tfFJCNnwtLS0tLXxSQnp8PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCist LS0rICZuYnNwOyArLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7ICZuYnNwOy8rLS0tKzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsvPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJBcmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQorLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7ICstLS0rLzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQp8UkI3fC0tLXxSQjh8LS0tfFJCOXw8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkFyaWFsIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KKy0tLSsgJm5ic3A7ICstLS0rICZuYnNwOyArLS0tKzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpUaGVyZSBhcmUgdHdvIGRpc3RyaWJ1dGlvbiB0cmVlcyBpbiB0aGUgbmV0d29yaywgb25lIHJv b3RlZCBhdCBSQnkgd2lsbA0KcHJlZG9taW5hbnRseSB1c2UgdGhlIHZlcnRpY2FsIGxpbmtzIGFt b25nIFJCMSB0aHJvdWdoIFJCOSA8YnI+DQp3aGlsZSBhbm90aGVyIHJvb3RlZCBhdCBSQnogd2ls bCBwcmVkb21pbmFudGx5IHVzZSB0aGUgaG9yaXpvbnRhbC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkFyaWFsIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClJCMVxS QjRcUkI3XFJCOFxSQjkgYXJlIGFsbCBlZGdlIFJCcywgYnkgZGVmYXVsdCwgZWFjaCB3aWxsIGNo b29zZSB0aGUNCnNob3J0ZXN0IHBhdGihr3MgdHJlZSByb290IHRvIHVzZSw8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkFyaWFsIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KYW5kIGVhY2ggbWF5IHVzZSB0aGUgdHdvIHRyZWVzIHRvIG11bHRpcGF0aGluZyBtdWx0aS1k ZXN0aW5hdGlvbiB0cmFmZmljDQphdCB0aGUgc2FtZSB0aW1lLiAmbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkFyaWFsIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KQnV0IGlmIHdlIGhhdmUgUkIxIGFuZCBSQjcgaW4gYSBSQnYsIHRoZW4gd2UgaGF2ZSB0byBh bGxvY2F0ZSBkaWZmZXJlbnQNCnRyZWVzIGJldHdlZW4gUkIxIGFuZCBSQjcuPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCldpdGggdGhlIGN1cnJlbnQgQ01UIG1hbm5lciwgbWF5YmUgUkJ6IGlzIGFsbG9jYXRlZCB0 byBSQjEsIFJCeSBpcyBhbGxvY2F0ZWQNCnRvIFJCNy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkFyaWFsIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KT2J2aW91c2x5 LFJCMSBpcyBjbG9zZXIgdG8gUkJ5LCBzbyB0aGUgbmV0d29yayBtYW5hZ2VyIG1heSB3YW50IHRv IG1hbnVhbGx5DQpjb25maWd1cmUgUkJ5IHRvIFJCMSBhcyBhbiBhbGdvcml0aG0gaW50ZXJ2ZW50 aW9uLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KQXMgdGhlIGxvY2FsIHBvbGljeS9hZG1pbmlzdHJh dGl2ZSBtYXR0ZXIsIGhvdyB0byBjb21wYXRpYmxlIHdpdGggbWFudWFsDQpjb25maWd1cmF0aW9u LCBtYXliZSBpdCBpcyBhIHF1ZXN0aW9uIHdpdGhpbiB0aGUgUkJ2J3MgdHJlZSBhbGxvY2F0aW9u PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KSSB0aGluayB0aGlzIG1heSBiZSBzb2x2ZWQgYnkgY2hv b3NpbmcgYSBtZW1iZXIgUkIsIHdoaWNoIGlzIHVzZWQgdG8gY29sbGVjdA0KY29uZmlndXJhdGlv biBpbmZvcm1hdGlvbiBvZiBSQnYsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmFuZCBleGVjdXRlIGFuIHVuaWZp ZWQgYWxnb3JpdGhtIHRvIGFsbG9jYXRlIHRyZWVzIGZvciBhbGwgbWVtYmVycyB3aXRoaW4NCnRo ZSBzYW1lIFJCdi4gPGJyPg0KVGhlcmUgYXJlIHR3byBiZW5lZml0cyBieSBkb2luZyBzbzogZmly c3QsIGl0IGlzIGNvbXBhdGlibGUsIHNlY29uZCB0aGVyZQ0KaXMgbm8gbmVlZCBmb3IgYWxsIG90 aGVyIG1lbWJlciBSQnMgdG8gZXhlY3V0ZSB0aGUgYWxnb3JpdGhtLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K PGJyPg0KVGhhbmtzLDxicj4NClRpbmE8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4g PC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTUzJT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZxdW90O1Rpc3NhIFNlbmV2aXJh dGhuZSAodHNlbmV2aXIpJnF1b3Q7DQombHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzp0c2Vu ZXZpckBjaXNjby5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxiPjx1 PnRzZW5ldmlyQGNpc2NvLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0i QXJpYWwiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCreivP7IyzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjogJm5ic3A7PC9m b250PjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTEg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0iQXJpYWwiPjIwMTItMTEtMjYgMjM6NDQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkFyaWFsIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD00NiU+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xMiU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9ODclPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOmxpYW8u dGluZ0B6dGUuY29tLmNuPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5s aWFvLnRpbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlh bCI+JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNu Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5saWFvLnRpbmdAenRlLmNv bS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7PC9mb250Pjxh IGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNl PSJBcmlhbCI+JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3Jn Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT50cmlsbEBpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+UmU6IFt0cmlsbF0gZHJhZnQtaWV0 Zi10cmlsbC1jbXQ8L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwi Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9u dD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAl Pg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8cD48Zm9udCBzaXplPTMg ZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8YnI+DQpIaSBUaW5hPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJBcmlhbCI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iQ2FsaWJyaSI+PGJyPg0KQW5zd2VyIGlzIG5vIG5lZWQgYW5kIGl0IGlzIGFscmVhZHkgYnVp bHQgaW4uIEhlcmUgaXMgd2h5LiBXZSBwcm9wb3NlIHRvDQphbm5vdW5jZSB0aGUgQWZmaW5pdHkg Q2FwYWJpbGl0eS4gJm5ic3A7Q01UIHNwZWNpZmljYXRpb24gaXMgdGhhdCBSQnJpZGdlDQphbm5v dW5jaW5nIHRoYXQgY2FwYWJpbGl0eSBtdXN0IGZvbGxvdyB0aGUgc3BlY2lmaWVkIHRyZWUgYWxs b2NhdGlvbi4gSWYNCnNvbWUgUkJyaWRnZSBpcyBhbm5vdW5jaW5nIHRoZSBhZmZpbml0eSBjYXBh YmlsaXR5IGFuZCB5ZXQgZG9pbmcgbWFudWFsDQphbGxvY2F0aW9uIHRoZW4gaXQgaXMgYW4gaW1w bGVtZW50YXRpb24gZXJyb3Igb3IgbG9jYWwgcG9saWN5L2FkbWluaXN0cmF0aXZlDQptYXR0ZXIu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhhbmtzPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj48YnI+DQpUaXNzYTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwi PiA8YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkZyb206 PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY24+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5saWFvLnRpbmdAenRlLmNvbS5jbjwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KWzwvZm9udD48YSBocmVmPW1h aWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJU YWhvbWEiPjx1Pm1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPjxicj4NClNlbnQ6PC9iPiBTdW5kYXksIE5vdmVt YmVyIDI1LCAyMDEyIDU6MTkgUE08Yj48YnI+DQpUbzo8L2I+IFRpc3NhIFNlbmV2aXJhdGhuZSAo dHNlbmV2aXIpPGI+PGJyPg0KQ2M6PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0 Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT50cmlsbEBpZXRm Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjsNCjwvZm9udD48 YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iVGFob21hIj48dT50cmlsbC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBb dHJpbGxdIGRyYWZ0LWlldGYtdHJpbGwtY210PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlh bCI+DQo8YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0K SGksVGlzc2E8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KWWVzPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj6jrDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPnRoYXQncw0K ZXhhY3RseSB3aGF0IEkgbWVhbi4gOik8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU2hvdWxkIHRoZSBDTVQgdGFr ZSB0aGlzIHNjZW5hcmlvIGludG8gYWNjb3VudDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+o788L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpUaW5hPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MyU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFy aWFsIj48Yj4mcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSZxdW90Ow0KJmx0Ozwv Yj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHNlbmV2aXJAY2lzY28uY29tPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9iPjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQq3orz+yMs8L2ZvbnQ+PGZvbnQgc2l6 ZT0xIGZhY2U9IkFyaWFsIj46ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91 bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnRy aWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iQXJp YWwiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4yMDEyLTExLTI2IDAw OjUwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9 NDYlPjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MTIlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg3JT48Zm9u dCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzpsaWFvLnRp bmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+bGlh by50aW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwi PiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpsaWFvLnRpbmdAenRlLmNvbS5jbj48 Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+bGlhby50aW5nQHp0ZS5jb20u Y248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90OzwvZm9udD48YSBo cmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJB cmlhbCI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0i QXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48 Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlJlOiBbdHJpbGxdIGRyYWZ0LWlldGYt dHJpbGwtY210PC9mb250PjwvdGFibGU+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxi cj4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8YnI+DQo8YnI+ DQpIaSBUaW5hPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8YnI+DQpJIGFtIG5vdCBz dXJlIEkgY29tcGxldGVseSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24uIEFyZSB5b3UgcmVmZXJy aW5nDQp0byBhIHNjZW5hcmlvIHdoZXJlIHNvbWUgb2YgdGhlIG1lbWJlcnMgKGUuZy4gUkIxICkg YXJlIHVzaW5nIHNvbWUgbWFudWFsDQpjb25maWd1cmF0aW9uIGFuZCBvdGhlciBpcyB1c2luZyB0 aGUgcHJvcG9zZWQgbWV0aG9kIChlLmcuIFJCMikgaW4gdGhlDQpDTVQgZHJhZnQgPzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPGJyPg0KUFM6IEJvdGggUkIxIGFuZCBSQjIgYXJlIG1l bWJlcnMgb2YgdGhlIHZpcnR1YWwgUkJyaWRnZSBSQnY8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkFyaWFsIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQo8YnI+ DQpGcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmxpYW8udGluZ0B6dGUuY29tLmNuPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+bGlhby50aW5nQHp0ZS5jb20u Y248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iVGFob21hIj48dT5tYWlsdG86bGlhby50aW5nQHp0ZS5jb20uY248L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4gVGh1cnNk YXksIE5vdmVtYmVyIDIyLCAyMDEyIDEwOjA1IFBNPGI+PGJyPg0KVG86PC9iPiBUaXNzYSBTZW5l dmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj4NCkNjOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRv OnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47 DQo8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NClN1YmplY3Q6 PC9iPiBSZTogW3RyaWxsXSBkcmFmdC1pZXRmLXRyaWxsLWNtdDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJy Pg0KPGJyPg0KSGksVGlzc2E8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4gPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KU2VjdGlvbiA1LjEgcHJvdmlk ZXMgYSBzaW1wbGUgZ2VuZXJhbCBtZXRob2QgdG8gYXNzaWduIGRpZmZlcmVudCB0cmVlcw0KdG8g ZGlmZmVyZW50IG1lbWJlcnMgYW5kIGl0IGlzIGVhc3kgdG8gZW1wbG95LjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KQnV0IGluIG15IG9waW5pb24sIGl0IGNvdWxkIGJlIGJldHRlciB0byBhbGxvdyBjby1leGlz dGVuY2Ugb2YgZGVmYXVsdA0KbWFubmVyPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj6jqDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPmNtdDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+o6k8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij4NCmFuZCBtYW51YWwgY29uZmlndXJhdGlvbiA8YnI+DQpmb3IgZGlzdHJpYnV0aW9uIHRyZWUg Y2hvb3Npbmc8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPqOsPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+b3RoZXJ3aXNlDQppZiBzb21lIG1lbWJlciBSQnMgYXJl IG1hbnVhbGx5IGNvbmZpZ3VyZWQgYW5kIG90aGVycyBhcmUgbm90IGNvbmZpZ3VyZWQNCmF0IGFs bCwgPGJyPg0KY29tcGF0aWJpbGl0eSBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgYWxnb3JpdGht IGNvdWxkIG9jY3VyLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU28sIG1heWJlIHdlIHNob3VsZCBwcm92aWRl IGEgdW5pZmllZCB0cmVlIGRpc3RyaWJ1dGlvbiBtZXRob2Qgd2hpY2ggaXMNCmNvbXBhdGlibGUg PGJyPg0Kd2l0aCBtYW51YWwgY29uZmlndXJhdGlvbiBhbmQgY2FuIGVuc3VyZSBkaWZmZXJlbnQg bWVtYmVyIFJCcyBvYnRhaW4gZGlmZmVyZW50DQombmJzcDtkaXN0cmlidXRpb24gdHJlZT8gPGJy Pg0KPGJyPg0KVGhhbmtzLDxicj4NClRpbmE8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91Pjwv Zm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJBcmlhbCI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhy ZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmlsbDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmls bCBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48 YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmlsbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhy ZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmlsbDwvdT48L2ZvbnQ+PC9hPjx0dD48Zm9udCBzaXplPTI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5n IGxpc3Q8YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJpbGw8YnI+DQo8L2ZvbnQ+PC90dD4NCjxwPg0K --=_alternative 0022D98648257AC4_=-- From ostokes@extremenetworks.com Wed Nov 28 07:38:46 2012 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 0C59D21F886E for ; Wed, 28 Nov 2012 07:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOMmRJ7UihkU for ; Wed, 28 Nov 2012 07:38:45 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 89DEC21F8894 for ; Wed, 28 Nov 2012 07:38:43 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Wed, 28 Nov 2012 07:38:42 -0800 From: Olen Stokes To: Donald Eastlake Date: Wed, 28 Nov 2012 07:38:41 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3NFH1yi9wECFk5Qgy+Nw+di0UAlAAaQqUw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:38:46 -0000 Thanks. I understand that. I am trying to understand under what circumsta= nces it is being proposed that multiple unicast packets be sent instead of = a single multi-destination packet? In other words, **WHY** would an RBridg= e use this unicast method rather than use the existing multi-destination D-= Tree method? Cheers, Olen -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Tuesday, November 27, 2012 10:00 PM To: Olen Stokes Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt HI Olen, On Mon, Nov 26, 2012 at 10:31 AM, Olen Stokes = wrote: > Since the two emails below were written about a week ago, there has been = a lot of discussion about the RBridge capabilities required to be classifie= d as an FGL RBridge. I am still unclear about one part of the exchange bel= ow. > > There is a discussion about the implications of a TRILL ingress RBridge s= erially unicasting "a multi-destination TRILL Data frame to the relevant eg= ress TRILL switches after encapsulating it as a TRILL known unicast data fr= ame (M=3D0)". > > What is the use case envisioned when there is more than one "relevant egr= ess FGL RBridge"? We are talking about multi-destination TRILL Data frames. That is, frames w= here the Inner.MacDA is the broadcast address, a multicast address, or a un= icast address who egress TRILL switch is unknown to the ingress TRILL switc= h. In such cases, all TRILL switches indicating interest in the frame's VLA= N are potentially relevant although in the multicast case this should be fu= rther limited to TRILL switches where a listener for the multicast group or= a multicast router is attached. 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 > FWIW, Donald noted below that this provision has been in all of the previ= ous versions. I agree. I did not mean to imply otherwise. > > Cheers, > Olen > > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Monday, November 19, 2012 8:19 PM > To: Olen Stokes > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call:=20 > draft-ietf-trill-fine-labeling-02.txt > > Hi Olen, > > Thanks for the comments. See responses below. > > On Sun, Nov 18, 2012 at 12:27 PM, Olen Stokes wrote: >> >> Comparing the -01 and the -02 versions of this draft shows some very=20 >> important changes. > > I agree. > >> I understand the desire to finalize this draft. >> However, I am concerned that the changes in the -02 version may have=20 >> created some inconsistencies in the document. There may also be=20 >> opportunities to more clearly state some of the implications of the=20 >> changes. > > I don't think there are any inconsistencies. However, it is certainly pos= sible that some clarifications and/or editorial changes would improve the d= raft. > >> Section 1.1 still defines a FGL RBridge as a "TRILL switch that=20 >> support[s] both FGL and VL". However, Section 9 states, "no TRILL=20 >> data frames can be exchanged between VL and FGL RBridges". It would=20 >> be helpful to better describe scenarios where a FGL RBridge needs to=20 >> support a VL mode of operation if a FGL RBridge cannot exchange=20 >> packets with a VL RBridge. > > Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and support = VLAN Labeling (VL) as the inner data label. In other words, an FGL RBridge = must be able to ingress a native frame to an FGL TRILL data frame, handle a= n FGL TRILL data frame as a transit switch, and egress an FGL TRILL data fr= ame to a native frame. In addition, an FGL RBridge must be able to ingress = a native frame to a VL TRILL data frame, handle a VL TRILL data frame as a = transit switch, and egress a VL TRILL data frame as a native frame, all thi= s VL stuff as described in the TRILL base protocol RFC 6325. > > So an FGL RBridge can safely handle VL data traffic. But if you give an F= GL data frame to a VL RBridge, it is very likely to be mishandled. > This problem with VL RBridges, which by definition are FGL ignorant, is t= he reason for not allowing TRILL data traffic between FGL and VL RBridges. > >> Section 3 states that the default port configuration for a FGL=20 >> RBridge port is VL. A scenario where this is utilized would also be hel= pful. > > Here are three uses that come to mine immediately: > > - If you are upgrading a campus from VL to FGL RBridges, it might be > some time, if ever, before you configured connectivity between all > end stations to make use of FGL. In the mean time, you would want VL > to continue working. > > - It would be possible to standardize data connection between VL and > FGL RBridges if it was specified how to do multi-topology. You could > then have one topology with just FGL RBridges and a second topology > with all RBridges. As long as FGL frames were limited to the FGL > topology and that topology was fully connected, all would be > well. Requiring FGL RBridges to support VL maintains this as a > future possibility by merely adding multi-topology. Otherwise you > would have to both add multi-topology and retro-fit VL support. > > - Due to the way TRILL works, it appears that it will be desirable to > have a maintenance VLAN in which all RBridges in a campus indicate > interest (see, for example, draft-ietf-trill-oam-framework). You > could, I suppose, have a maintenance FGL but it might as well work > the same way for a VL campus as for an FGL campus. > >> Otherwise, if a FGL RBridge does not have to support a VL mode of=20 >> operation, a specific statement to that effect would be appropriate. > > The current FGL draft, just like all previous versions of the FGL WG and = preceeding personal draft, does require support of VL by FGL RBridges. Sinc= e you specifically talk about -01 to -02 changes, you might not it is not a= change that just appeared in the current version. > >> Section 7, Item 2, only discusses "Silicon Considerations" from an=20 >> ingress/egress point of view. It does not discuss it from a transit=20 >> RBridge perspective. > > Good point, transit processing should be mentioned briefly in Section 7, = Item 2. However, the items in Section 7 are parallel with the same number i= tems in Section 2.1 and are just intended to discuss the extent to which th= e goals in 2.1 are met, not to be a complete discussion or summary of the n= amed topics... Perhpas "Silicon Considerations" should be replaced with "Si= licon Goal". > >> However, there appears to be several statements in the draft that=20 >> could have important effects on how existing silicon could be used=20 >> for transit FGL RBridge operation. Section 5.1 states: >> >> "An FGL ingress RBridge MAY serially TRILL unicast a=20 >> multi-destination TRILL Data frame to the relevant egress TRILL=20 >> switches after encapsulating it as a TRILL known unicast data frame (M= =3D0)". >> >> This would appear to allow silicon that can TRILL forward unicast FGL=20 >> packets to operate as a TRILL transit FGL node regardless of whether=20 >> it can TRILL forward FGL multi-destination packets. If that is the=20 >> intent, it would be helpful to state that in Section 7, Item 2. > > Your statement seems a odd to me. I don't understand what you mean when = you say "regardless of whether it can TRILL forward FGL multi-destination p= ackets". If it can't do that, I don't think it is an FGL RBridge. > > An FGL RBridge is required to be able to forward known unicast data=20 > that is TRILL unicast (M=3D0), multi-destination data that is TRILL=20 > multicast (M=3D1), and, due to the text you quote, multi-destination=20 > data that is TRILL unicast (M=3D0). Since your specifically talk about > -01 to -02 changes, you might note that this has been required in all pre= vious versions of the FGL WG draft and preceeding personal draft. > It is not a change that just appeared in the current -02 version. > >> Section 5.2.2 states: >> >> "Pruning is an optimization. If a transit TRILL switch does less=20 >> pruning than it could, there may be greater link utilization than=20 >> strictly necessary but the campus will still operate correctly." >> >> This would appear to allow silicon that can TRILL forward FGL=20 >> multi-destination packets to operate as a TRILL transit FGL node=20 >> regardless of whether it can prune FGL packets. If that is the=20 >> intent, it would be helpful to state that in Section 7, Item 2. > > Pruning is a SHOULD in the base TRILL protocol standard and it is the sam= e here. The provisions here are similar to those in the base standard for V= L pruning. I don't see any problem adding something to clarify although I d= on't think Section 7, Item 2, is the best place. > How about just adding, at the end of the last sentence in Section 5.2.2, = the following words "or not prune FGL frames at all"? > >> Section 5.2.2 also discusses pruning based only on the High Part or=20 >> the Low Part of a FGL. A statement about silicon that can prune=20 >> based only on half of a FGL would also be helpful in Section 7, Item 2. > > But the whole point is that, since pruning is just a SHOULD=20 > optimization, the silicon could prune on whatever subset of FGL bits=20 > it feels like and still be conformant. For example, it could prune on=20 > just the highest order bit or just the highest order byte of the FGL=20 > or something. How about, including the addition above, changing > > "For example, a transit TRILL switch could prune based on only part of th= e FGL such as only the High Part or only the Low Part." > > to > > "A transit TRILL switch could prune based on an arbitrary subset of the F= GL label bits, such as only the High Part or only the Low Part, or not prun= e FGL frames at all." > > Actually an RBridge could adopte even more strange or exotic pruning meth= ods, although I can't see why it would want to. For example, it could prune= based on the data label value modulo some arbitrary integer divisor less t= han the maximum label value...sort of a ridiculous thing to do but frames w= ould still be routed correctly so I believe such behavior is allowed. > > 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 > >> Thanks for any consideration of these items. >> >> Cheers, >> Olen >> >> >> >> On 11/6/12 3:42 PM, "Donald Eastlake" wrote: >> >>>Hi, >>> >>>As announced at the TRILL WG meeting today, this starts a two week WG=20 >>>Last Call on draft-ietf-trill-fine-labeling ending 19 November. >>> >>>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 From narten@us.ibm.com Wed Nov 28 07:53:25 2012 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 6099B21F88F2 for ; Wed, 28 Nov 2012 07:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btsc4p7Xm26J for ; Wed, 28 Nov 2012 07:53:24 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFAA21F887C for ; Wed, 28 Nov 2012 07:53:24 -0800 (PST) Received: from /spool/local by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Nov 2012 10:53:23 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 28 Nov 2012 10:53:20 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1410F38C8041 for ; Wed, 28 Nov 2012 10:53:20 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qASFrJoa19660998 for ; Wed, 28 Nov 2012 10:53:19 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qASFrIGY017187 for ; Wed, 28 Nov 2012 13:53:19 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-233-237.mts.ibm.com [9.65.233.237]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qASFrBbw016591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2012 13:53:13 -0200 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qASFrAgu013237; Wed, 28 Nov 2012 10:53:11 -0500 Message-Id: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> To: Olen Stokes In-reply-to: References: Comments: In-reply-to Olen Stokes message dated "Wed, 28 Nov 2012 07:38:41 -0800." Date: Wed, 28 Nov 2012 10:53:10 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112815-5930-0000-0000-00000EBE7DA3 Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:53:25 -0000 Olen's original comment was about the following text in the document: > "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination > TRILL Data frame to the relevant egress TRILL switches after encapsulating > it as a TRILL known unicast data frame (M=0)". Does the base TRILL spec forbid the above behavior? Is this sentence even needed? Can we just remove it? (FWIW, it seems to me to be unnecessary.) Thomas From radiaperlman@gmail.com Wed Nov 28 16:48:48 2012 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 3616421F88E0 for ; Wed, 28 Nov 2012 16:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sylKvF4t5RQG for ; Wed, 28 Nov 2012 16:48:47 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83CA121F88DF for ; Wed, 28 Nov 2012 16:48:47 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7048508vbb.31 for ; Wed, 28 Nov 2012 16:48:47 -0800 (PST) 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:content-type; bh=RB8Yh/zyImxJvw8fLZsGmx2+pKy5BIWIWIHhG7zrKdk=; b=kgcbMzU/7CKRBqJkr3WFQWfGRpC0E9x2phQput2UujhL8HFGuToqssP18z3ujtFAeV iakmyoBvyC5i+VAQ8gMjaVzKhi9uEFJBK0ErBTKJ8VdeQGhqGiLihKc4Yg0q6XZrfYGk 9WsFt3KJtEUADlBmsx1l4+gsg8puu+GRdXqMzKcpmvEFW6ExnGDFBl6ezh8/MjtKJrvQ 5EFFxLa+ebdCwFMbSIjpqGIaauoN57ivgQ8C9hambaQFZWTd+jezhIS4QyFnO7NjzrZC ED7SvdgcmL5VaA/LzvKSibC080BiCdCR/neFHQkN1Wn2iy0fmhNY8H2acFa6KciXugPU Zpdg== MIME-Version: 1.0 Received: by 10.220.225.132 with SMTP id is4mr29856909vcb.47.1354150127028; Wed, 28 Nov 2012 16:48:47 -0800 (PST) Received: by 10.58.207.138 with HTTP; Wed, 28 Nov 2012 16:48:46 -0800 (PST) In-Reply-To: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> Date: Thu, 29 Nov 2012 01:48:46 +0100 Message-ID: From: Radia Perlman To: Thomas Narten Content-Type: multipart/alternative; boundary=14dae9ccd52c4b49b704cf97a52f Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 00:48:48 -0000 --14dae9ccd52c4b49b704cf97a52f Content-Type: text/plain; charset=ISO-8859-1 Even if the base spec doesn't preclude doing serial unicast, it might be worth mentioning the possiblity here because if there is a huge campus with so many different FGLs in use that the inner RBridges have trouble filtering, and there's only a few edge guys participating in the FGL, it might wind up being more optimal for the ingress switch to do serial unicast. So saying MAY just gives an implementer the hint that it might be a good thing to allow. At any rate, I don't think it hurts to have that sentence in the FGL spec. Radia On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten wrote: > Olen's original comment was about the following text in the document: > > > "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination > > TRILL Data frame to the relevant egress TRILL switches after > encapsulating > > it as a TRILL known unicast data frame (M=0)". > > Does the base TRILL spec forbid the above behavior? > > Is this sentence even needed? Can we just remove it? (FWIW, it seems > to me to be unnecessary.) > > Thomas > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --14dae9ccd52c4b49b704cf97a52f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Even if the base spec doesn't preclude doing serial unicast, it mi= ght be worth mentioning the possiblity here=A0because if there is a huge ca= mpus with so many different FGLs in use that the inner RBridges have troubl= e filtering, and there's only a few edge guys participating in the FGL,= it might wind up being more optimal for the ingress switch=A0to do serial = unicast.=A0 So saying MAY just gives an implementer the hint that it might = be a good thing to allow.
=A0
At any rate, I don't think it hurts to=A0have that s= entence=A0in the FGL spec.
=A0
Radia
=A0


=A0
On Wed, Nov 28, 2012 at 4= :53 PM, Thomas Narten <narten@us.ibm.com> wrote:
Olen's original comment was about the following text i= n the document:

> "An FGL ingress RBridge MAY serially TRILL unicast a multi-destin= ation
> TRILL Data frame to the relevant egress TRILL switches after encapsula= ting
> it as a TRILL known unicast data frame (M=3D0)".

Does the base TRILL spec forbid the above behavior?

Is this sentence even needed? Can we just remove it? (FWIW, it seems
to me to be unnecessary.)

Thomas

_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--14dae9ccd52c4b49b704cf97a52f-- From d3e3e3@gmail.com Wed Nov 28 20:19:33 2012 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 6F5AD1F0C82 for ; Wed, 28 Nov 2012 20:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.032 X-Spam-Level: X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cacvynN2Insw for ; Wed, 28 Nov 2012 20:19:32 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAE61F0C59 for ; Wed, 28 Nov 2012 20:19:32 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so15127310ieb.31 for ; Wed, 28 Nov 2012 20:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p7FZeuI7eL4zY+FJZaUL4gSSFHpSwulu3H0deGc+u0c=; b=SmYVLmf1c1dALJGkVgy8Y/xn3gzCYeWuN4CA5cDODR3TFlIsFyUm4p17vgA3+XOFoG RIDQ/aUEWaxtm8kWraYxQ1JYHJbZ6G39qtXSMH537v6iNIPxK6fibsjmQenud7tv69KE SZRhzy2qx05FARPvr759ysDDAOqhibCD1uY3r6DYvBX1SkELa8n9jLEKYSSr7lEkrCRh iOP+Be97dmD8XxtO+TrATRtTHt8oHrSXZEn0Fydl0W/pUQi00V2/1075LrsGx8aV9Xk+ wjBj4riFSl4Z+bl0YX5ZC+tk4D5CXETMIDLHALRJXobv8M0gffnQVRhzqq/6a+pWdsDw Jzgg== Received: by 10.50.34.201 with SMTP id b9mr21732554igj.55.1354162772118; Wed, 28 Nov 2012 20:19:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Wed, 28 Nov 2012 20:19:11 -0800 (PST) In-Reply-To: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Wed, 28 Nov 2012 23:19:11 -0500 Message-ID: To: Thomas Narten , Olen Stokes Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 04:19:33 -0000 Hi, In addition to Radia's comment about reducing pruning state, see below: On Wed, Nov 28, 2012 at 10:38 AM, Olen Stokes wrote: > > Thanks. I understand that. I am trying to understand under what > circumstances it is being proposed that multiple unicast packets be > sent instead of a single multi-destination packet? In other words, > **WHY** would an RBridge use this unicast method rather than use the > existing multi-destination D-Tree method? Consider a large TRILL campus in which, say, 100 end stations are in some particular FGL data label. At one extreme, if all 100 end stations were attached to a single TRILL switch, then no other TRILL switch would be advertising interest in that FGL and likely a multidestination (say broadcast) frame from one such end station would, even if put on a distribution tree, because of pruning, not get sent any another TRILL switch. At the other extreme, assume the 100 end stations are attached, one each, to 100 different end stations; in that case you are almost certainly better off using a distribution tree because if you tried to serially unicast you would cause much higher link utilitization, probably have to output some multiple copies through the same port, etc. But what if these 100 end stations are connected to exactly two TRILL switches, say 75 to one and 25 to the other. Using unicast TRILL Data frames between these TRILL switches is better because they will follow least cost paths, possibly with such traffic spread over an arbitrary number of equal cost least cost paths. On the other hand, if one or more distribution trees were used, each frame would be constrained to the tree used for that frame and would likely follow a more circuitous route, depending on where the tree roots are. That's why the draft says "SHOULD" use unicast if there exactly two TRILL switches involed. It's a more complex decision whether to use a distribution tree or serial unicast if the end stations are connected to a "small" number of TRILL switches greater than two. So the draft just says "MAY" in that case. > Cheers, > Olen On Wed, Nov 28, 2012 at 10:53 AM, Thomas Narten wrote: > Olen's original comment was about the following text in the document: > >> "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination >> TRILL Data frame to the relevant egress TRILL switches after encapsulating >> it as a TRILL known unicast data frame (M=0)". > > Does the base TRILL spec forbid the above behavior? While I do not think it has a statement explicitly prohibiting such behavior, it implicitly prohibits it by mandating that multidestination frames be encoded into TRILL Data frames with a TRILL Header having M=1 and sent on the distribution tree indicated by the egress nickname. There is also the corresponding egress statement that requires FGL TRILL switches to be able to egress such multi-destination inner frames encoded with M=0: "FGL TRILL switches MUST accept multi-destination TRILL Data frames that are sent to them as TRILL unicast frames, that is, frames that may have a multicast or broadcast Inner.MacDA (or are being sent to an unknown unicast Inner.MacDA) and the TRILL Header M bit = 0." (Actually, the current standard in effect requires all TRILL switches to be able to egress unknown unicast frames when encoded that way. That's because a destination MAC and VLAN can be known to the ingress TRILL switch, which then encodes the TRILL Data frame with M=0 and unicasts it to the egress, but then turn out to be unknown to that egress switch because its tables of attached MACs have overflowed or the entry has timds out or it has re-booted or whatever.) > Is this sentence even needed? Can we just remove it? (FWIW, it seems > to me to be unnecessary.) What do you mean by "needed"? It is an intentional change in TRILL; as such it does something, causing significant improvement in some cases as in my response to Olen above. But it is just a matter of efficiency so FGL TRILL would still work without it. > Thomas Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Nov 28, 2012 at 7:48 PM, Radia Perlman wrote: > Even if the base spec doesn't preclude doing serial unicast, it might be > worth mentioning the possiblity here because if there is a huge campus with > so many different FGLs in use that the inner RBridges have trouble > filtering, and there's only a few edge guys participating in the FGL, it > might wind up being more optimal for the ingress switch to do serial > unicast. So saying MAY just gives an implementer the hint that it might be > a good thing to allow. > > At any rate, I don't think it hurts to have that sentence in the FGL spec. > > Radia > > > > > On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten wrote: >> >> Olen's original comment was about the following text in the document: >> >> > "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination >> > TRILL Data frame to the relevant egress TRILL switches after >> > encapsulating >> > it as a TRILL known unicast data frame (M=0)". >> >> Does the base TRILL spec forbid the above behavior? >> >> Is this sentence even needed? Can we just remove it? (FWIW, it seems >> to me to be unnecessary.) >> >> Thomas >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > > From d3e3e3@gmail.com Wed Nov 28 20:52:46 2012 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 8D2161F0C80 for ; Wed, 28 Nov 2012 20:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.328 X-Spam-Level: X-Spam-Status: No, score=-103.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj6wIl4b0LAC for ; Wed, 28 Nov 2012 20:52:46 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0662E1F0C59 for ; Wed, 28 Nov 2012 20:52:45 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so15159130ieb.31 for ; Wed, 28 Nov 2012 20:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=50gNphlrv8AiiqLjzDjLAFfSJ5jLwwP48bbs8a2rEWo=; b=HXkl2DNmgit+Bh/2eAu9qcq8OfzyD9x0V63D4U/WiEfoVv7lmFfnvxPNq/LlanaNGS igjxTdkDeBUxcoUt08c0Gc7Mi4kNL9ThQvXucr0Y+8BMd+zWPCvyS8/cvdxI6dAuxb+Y QtowUae8yPOfqmnzw6KKOhmOk9SQX7u4BRnebAlbz3dGaHWPS9FuJJ+/IuG/3EbKI/ds efviX77CrtnBuf/UFw8E2WBGg/t6ZQm5RfZZEbmeXEXbA0udRejoEboCIZUUCPr258Mo hgNLHK+ZzTD6/a9So4GIsen4uOcO7LawY2YN11KZyjQ/NNnPHJ1cfgAoKaW8A86IWdgl mZow== Received: by 10.50.194.196 with SMTP id hy4mr21505365igc.52.1354164765607; Wed, 28 Nov 2012 20:52:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Wed, 28 Nov 2012 20:52:25 -0800 (PST) From: Donald Eastlake Date: Wed, 28 Nov 2012 23:52:25 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] Editorial clarification of draft-ietf-trill-fine-labeling X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 04:52:46 -0000 I believe an editorial revision to clarify the draft without any technical change would be useful and plan to post such a revision. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From Kesava_Vijaya_Krupak@Dell.com Wed Nov 28 22:24:18 2012 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 CFF8821F8A0C for ; Wed, 28 Nov 2012 22:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5v0+BzTQnSh for ; Wed, 28 Nov 2012 22:24:12 -0800 (PST) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6891B21F8A30 for ; Wed, 28 Nov 2012 22:24:06 -0800 (PST) X-Loopcount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="4.84,182,1355119200"; d="scan'208,217";a="25064954" From: To: Date: Thu, 29 Nov 2012 11:53:32 +0530 Thread-Topic: New draft : TRILL Smart Endnodes draft Thread-Index: Ac3N+g3BO6hexVpzQWOBSNOWR00ooQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D450185B52D9AMAAX7MCDC101A_" MIME-Version: 1.0 Cc: d3e3e3@gmail.com, radiaperlman@gmail.com, hu.fangwei@zte.com.cn Subject: [trill] New draft : TRILL Smart Endnodes draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 06:24:18 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D450185B52D9AMAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, TRILL Smart Endnodes draft has been posted as a modification on the origina= l TRILL Cloudlet draft. http://datatracker.ietf.org/doc/draft-perlman-trill-smart-endnodes Kindly have a look and let us know your comments. Cheers, kvk --_000_D5A6F3355F664C40AFB65BB1277D8D450185B52D9AMAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

TRILL = Smart Endnodes draft has been posted as a modification on the original TRIL= L Cloudlet draft.

 

<= p class=3DMsoNormal>http://datatracker.ietf.org/doc/draft-perlman-trill= -smart-endnodes

 

Kindly have a look and let us know your comments.

 

C= heers,

kvk

= --_000_D5A6F3355F664C40AFB65BB1277D8D450185B52D9AMAAX7MCDC101A_-- From narten@us.ibm.com Thu Nov 29 07:45:25 2012 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 5C6AF21F8A95 for ; Thu, 29 Nov 2012 07:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpK-OkcKK0f2 for ; Thu, 29 Nov 2012 07:45:24 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9AA21F8A8F for ; Thu, 29 Nov 2012 07:45:24 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 29 Nov 2012 10:45:23 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 29 Nov 2012 10:45:19 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id DB565C9004C for ; Thu, 29 Nov 2012 10:45:18 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qATFjEMc262378 for ; Thu, 29 Nov 2012 10:45:16 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qATFj3Mu020435 for ; Thu, 29 Nov 2012 13:45:03 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-210-139.mts.ibm.com [9.65.210.139]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qATFj2nV020372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 13:45:03 -0200 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qATFj0YK005513; Thu, 29 Nov 2012 10:45:00 -0500 Message-Id: <201211291545.qATFj0YK005513@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> Comments: In-reply-to Donald Eastlake message dated "Wed, 28 Nov 2012 23:19:11 -0500." Date: Thu, 29 Nov 2012 10:45:00 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112915-9360-0000-0000-00000D4E82BF Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 15:45:25 -0000 I think it is clear that there are circumstances where using unicast rather than multicast would be a useful optimization. What the document would benefit from is text explaining where that might be useful and making it clear that implementations might want to do that - as an optimization under appropriate circumstances. It doesn't have that background, just a couple of MAY/SHOULD statements. Taking some of the explanation in this email thread and putting it into the document would probably help clarify the intent. I suggested pulling out the text because it was apparently confusing, and I didn't think it was necessary. There are lots of optimizations a product might make besides this one. The document surely doesn't aim to cover them all. Thomas From ostokes@extremenetworks.com Thu Nov 29 08:20:41 2012 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 3CEA521F860E for ; Thu, 29 Nov 2012 08:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRyKxPRbcr9H for ; Thu, 29 Nov 2012 08:20:39 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7503221F84BB for ; Thu, 29 Nov 2012 08:20:39 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Thu, 29 Nov 2012 08:20:39 -0800 From: Olen Stokes To: Radia Perlman , Thomas Narten Date: Thu, 29 Nov 2012 08:20:37 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3Ny0tNRjD7Z8ypTTWHNRKjrkw3XAAfkSFA Message-ID: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5026F93470A62USEXCHANGEc_" MIME-Version: 1.0 Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:20:41 -0000 --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5026F93470A62USEXCHANGEc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would seem that in order for an "inner" or transit-only RBridge to impro= ve its scaling by not including the "filtering" for a certain FGL, it would= have to either: 1) Know which FGLs are being sent using multi-destination packets and = which are being sent using multiple unicast packets, or 2) Use a cache driven design which traps on unknown FGL labels and ins= talls "filtering" only when a FGL is seen for the first time. This approac= h also opens up the discussion about knowing when to remove inactive "filte= rs". I believe that the Interested Labels and Spanning Tree Roots sub-TLV in RFC= 6326bis should use a reserved bit to indicate whether multi-destination pac= kets or multiple unicast packets will be used with the indicated label(s). Cheers, Olen From: Radia Perlman [mailto:radiaperlman@gmail.com] Sent: Wednesday, November 28, 2012 7:49 PM To: Thomas Narten Cc: Olen Stokes; Donald Eastlake; trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Even if the base spec doesn't preclude doing serial unicast, it might be wo= rth mentioning the possiblity here because if there is a huge campus with s= o many different FGLs in use that the inner RBridges have trouble filtering= , and there's only a few edge guys participating in the FGL, it might wind = up being more optimal for the ingress switch to do serial unicast. So sayi= ng MAY just gives an implementer the hint that it might be a good thing to = allow. At any rate, I don't think it hurts to have that sentence in the FGL spec. Radia On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten > wrote: Olen's original comment was about the following text in the document: > "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination > TRILL Data frame to the relevant egress TRILL switches after encapsulatin= g > it as a TRILL known unicast data frame (M=3D0)". Does the base TRILL spec forbid the above behavior? Is this sentence even needed? Can we just remove it? (FWIW, it seems to me to be unnecessary.) Thomas _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5026F93470A62USEXCHANGEc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It would = seem that in order for an “inner” or transit-only RBridge to im= prove its scaling by not including the “filtering” for a certai= n FGL, it would have to either:

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

1)&nb= sp;     Know whic= h FGLs are being sent using multi-destination packets and which are being s= ent using multiple unicast packets, or

2)      = Use a cache driven design which traps on unknown FGL label= s and installs “filtering” only when a FGL is seen for the firs= t time.  This approach also opens up the discussion about knowing when= to remove inactive “filters”.

 

I = believe that the Interested Labels and Spanning Tree Roots sub-TLV in RFC63= 26bis should use a reserved bit to indicate whether multi-destination packe= ts or multiple unicast packets will be used with the indicated label(s).

 

=

Cheers,

Olen

 =

From: Radia Perlman [mailto:radiaperlma= n@gmail.com]
Sent: Wednesday, November 28, 2012 7:49 PM
To= : Thomas Narten
Cc: Olen Stokes; Donald Eastlake; trill@ietf.= org
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labe= ling-02.txt

 

=

Even if the base spec doesn't preclude doing seri= al unicast, it might be worth mentioning the possiblity here because i= f there is a huge campus with so many different FGLs in use that the inner = RBridges have trouble filtering, and there's only a few edge guys participa= ting in the FGL, it might wind up being more optimal for the ingress switch=  to do serial unicast.  So saying MAY just gives an implementer t= he hint that it might be a good thing to allow.

 

At = any rate, I don't think it hurts to have that sentence in the FGL= spec.

 

<= /div>

Radia

 



 =

On Wed, Nov 28, 2012 at 4:53= PM, Thomas Narten <narten@us.ibm.com> wrote:

Olen= 's original comment was about the following text in the document:


> &quo= t;An FGL ingress RBridge MAY serially TRILL unicast a multi-destination
= > TRILL Data frame to the relevant egress TRILL switches after encapsula= ting
> it as a TRILL known unicast data frame (M=3D0)".

Does the base TRILL spec forbid the above = behavior?

Is this sentence even needed? Can we just remove it? (FWIW= , it seems
to me to be unnecessary.)
Thomas


_______________________________________________
trill = mailing list
trill@ietf.org
http= s://www.ietf.org/mailman/listinfo/trill

 

= --_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5026F93470A62USEXCHANGEc_-- From ostokes@extremenetworks.com Thu Nov 29 08:53:52 2012 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 4672021F8B0D for ; Thu, 29 Nov 2012 08:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJzy60FZyaTb for ; Thu, 29 Nov 2012 08:53:51 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8382A21F8AE6 for ; Thu, 29 Nov 2012 08:53:51 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Thu, 29 Nov 2012 08:53:51 -0800 From: Olen Stokes To: Donald Eastlake , Thomas Narten Date: Thu, 29 Nov 2012 08:53:49 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3N6LxagffUwOgESAiyzQ+p9Uy8ewAWtDDQ Message-ID: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:53:52 -0000 I am not opposed to the concept, but it does seem to violate the base proto= col. I believe that Section 4.6.2.4 of RFC 6325 would tell an egress VL RB= ridge to discard such a packet. Given that a FGL RBridge is supposed to be= able to forward both VL and FGL packets, should the description indicate t= hat this behavior is to be used only with FGL packets? I agree with Tom that this example should be included in the draft. =20 Cheers, Olen -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Wednesday, November 28, 2012 11:19 PM To: Thomas Narten; Olen Stokes Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi, In addition to Radia's comment about reducing pruning state, see below: On Wed, Nov 28, 2012 at 10:38 AM, Olen Stokes = wrote: > > Thanks. I understand that. I am trying to understand under what=20 > circumstances it is being proposed that multiple unicast packets be=20 > sent instead of a single multi-destination packet? In other words, > **WHY** would an RBridge use this unicast method rather than use the=20 > existing multi-destination D-Tree method? Consider a large TRILL campus in which, say, 100 end stations are in some p= articular FGL data label. At one extreme, if all 100 end stations were attached to a single TRILL swi= tch, then no other TRILL switch would be advertising interest in that FGL a= nd likely a multidestination (say broadcast) frame from one such end statio= n would, even if put on a distribution tree, because of pruning, not get se= nt any another TRILL switch. At the other extreme, assume the 100 end stations are attached, one each, t= o 100 different end stations; in that case you are almost certainly better = off using a distribution tree because if you tried to serially unicast you = would cause much higher link utilitization, probably have to output some mu= ltiple copies through the same port, etc. But what if these 100 end stations are connected to exactly two TRILL switc= hes, say 75 to one and 25 to the other. Using unicast TRILL Data frames bet= ween these TRILL switches is better because they will follow least cost pat= hs, possibly with such traffic spread over an arbitrary number of equal cos= t least cost paths. On the other hand, if one or more distribution trees we= re used, each frame would be constrained to the tree used for that frame an= d would likely follow a more circuitous route, depending on where the tree = roots are. That's why the draft says "SHOULD" use unicast if there exactly = two TRILL switches involed. It's a more complex decision whether to use a distribution tree or serial u= nicast if the end stations are connected to a "small" number of TRILL switc= hes greater than two. So the draft just says "MAY" in that case. > Cheers, > Olen On Wed, Nov 28, 2012 at 10:53 AM, Thomas Narten wrote: > Olen's original comment was about the following text in the document: > >> "An FGL ingress RBridge MAY serially TRILL unicast a=20 >> multi-destination TRILL Data frame to the relevant egress TRILL=20 >> switches after encapsulating it as a TRILL known unicast data frame (M= =3D0)". > > Does the base TRILL spec forbid the above behavior? While I do not think it has a statement explicitly prohibiting such behavio= r, it implicitly prohibits it by mandating that multidestination frames be = encoded into TRILL Data frames with a TRILL Header having M=3D1 and sent on= the distribution tree indicated by the egress nickname. There is also the corresponding egress statement that requires FGL TRILL sw= itches to be able to egress such multi-destination inner frames encoded wit= h M=3D0: "FGL TRILL switches MUST accept multi-destination TRILL Data frames that ar= e sent to them as TRILL unicast frames, that is, frames that may have a mul= ticast or broadcast Inner.MacDA (or are being sent to an unknown unicast In= ner.MacDA) and the TRILL Header M bit =3D 0." (Actually, the current standard in effect requires all TRILL switches to be= able to egress unknown unicast frames when encoded that way. That's becaus= e a destination MAC and VLAN can be known to the ingress TRILL switch, whic= h then encodes the TRILL Data frame with M=3D0 and unicasts it to the egres= s, but then turn out to be unknown to that egress switch because its tables= of attached MACs have overflowed or the entry has timds out or it has re-b= ooted or whatever.) > Is this sentence even needed? Can we just remove it? (FWIW, it seems=20 > to me to be unnecessary.) What do you mean by "needed"? It is an intentional change in TRILL; as such= it does something, causing significant improvement in some cases as in my = response to Olen above. But it is just a matter of efficiency so FGL TRILL = would still work without it. > Thomas 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 On Wed, Nov 28, 2012 at 7:48 PM, Radia Perlman wro= te: > Even if the base spec doesn't preclude doing serial unicast, it might=20 > be worth mentioning the possiblity here because if there is a huge=20 > campus with so many different FGLs in use that the inner RBridges have=20 > trouble filtering, and there's only a few edge guys participating in=20 > the FGL, it might wind up being more optimal for the ingress switch to=20 > do serial unicast. So saying MAY just gives an implementer the hint=20 > that it might be a good thing to allow. > > At any rate, I don't think it hurts to have that sentence in the FGL spec= . > > Radia > > > > > On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten wrote: >> >> Olen's original comment was about the following text in the document: >> >> > "An FGL ingress RBridge MAY serially TRILL unicast a=20 >> > multi-destination TRILL Data frame to the relevant egress TRILL=20 >> > switches after encapsulating it as a TRILL known unicast data frame=20 >> > (M=3D0)". >> >> Does the base TRILL spec forbid the above behavior? >> >> Is this sentence even needed? Can we just remove it? (FWIW, it seems=20 >> to me to be unnecessary.) >> >> Thomas >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > > From d3e3e3@gmail.com Thu Nov 29 21:28:15 2012 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 8C43A21F846E for ; Thu, 29 Nov 2012 21:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.062 X-Spam-Level: X-Spam-Status: No, score=-103.062 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZabdjWlFQVVl for ; Thu, 29 Nov 2012 21:28:14 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDA621F841A for ; Thu, 29 Nov 2012 21:28:14 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so140069ieb.31 for ; Thu, 29 Nov 2012 21:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ly8+mhHqYHSdmASW7SYTaX7CbQ3EfQCMRCOqEoftdHw=; b=mBpqWoSlyJJ6dbYq4CzTZwBZw255r44YAzsJwC/Y9cuMzo/8cbp8IMZAT38hVGNBgj //nhI6TwXcBTJWNW4J897UozCekxSZSLhBqmTjJi+5mJZHiQLbKS76Z2ux160ZLp7e/t Yp5v1e8oj+Iz8a3QVJrrxx6QAGkQE4hOZnmcEdXycUhmEdpnN73alg+bJOi0FgTGmY2d BYSG7DKl0zUcWikGk9wuvd9mke+1D8+s5T+kM1J8Lur8ecaiLxSlopcz8Qq1BubBt8sF 47EcSUthdkAVjVemPB9dvJ3sCFXXlJpEInYUKhRa23RLK4BAu7uOENes/vovcGwqgpc1 3E7g== Received: by 10.50.150.175 with SMTP id uj15mr27575216igb.52.1354253293987; Thu, 29 Nov 2012 21:28:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Thu, 29 Nov 2012 21:27:52 -0800 (PST) In-Reply-To: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Fri, 30 Nov 2012 00:27:52 -0500 Message-ID: To: Olen Stokes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 05:28:15 -0000 Hi Olen, On Thu, Nov 29, 2012 at 11:53 AM, Olen Stokes wrote: > I am not opposed to the concept, but it does seem to violate the base pro= tocol. That's right. Anything that changes the base protocol "violates" provisions of the base protocol. Saying that 0x893B can occur after the Inner.MacSA violates the base protocol specification. That's a common purpose of drafts that update or replace earlier documents. The upper left of the title page of this draft says it updates RFC 6325. However, I do think of FGL capabilities as optional. If it is not clear in the draft, a statement should be added that a VL TRILL switch conformant to RFC 6325 (as updated by RFC 6327 and the Clarifications and Corrections draft) is still a valid implementation of the TRILL protocol. > I believe that Section 4.6.2.4 of RFC 6325 would tell an egress VL RBridg= e to discard such a packet. Correct with the exception, as I pointed out in a previous message, if the Inner.MacDA was unicast because the multi-destination frame being serially unicast was an unknown unicast frame. > Given that a FGL RBridge is supposed to be able to forward both VL and FG= L packets, should the description indicate that this behavior is to be used= only with FGL packets? Given that this is an FGL draft, it would be reasonable to make that clear. The provisions are in sub-sections that are about ingressing, transiting, and egressing FGL TRILL data frames. > I agree with Tom that this example should be included in the draft. I have no problem with adding some material along those lines, but not a lot of material. It seems to me that the decision whether to use a distribution tree or to serially unicast, in cases where there is more than one destination TRILL switch, and the basis for such a decision should be beyond the scope of this draft. Similar examples are the decision of which TRILL switches, if any, to designate as appointed forwarders for which VLANs on a link or where to configure roots for your distribution trees are decisions outside the scope of the TRILL standard. Because the number of factors that could influence making such decisions in an optimal way is essentially unbounded and could extend to specific knowledge of application behavior on specific data sets and the like. 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 > Cheers, > Olen > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Wednesday, November 28, 2012 11:19 PM > To: Thomas Narten; Olen Stokes > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > Hi, > > In addition to Radia's comment about reducing pruning state, see below: > > On Wed, Nov 28, 2012 at 10:38 AM, Olen Stokes wrote: >> >> Thanks. I understand that. I am trying to understand under what >> circumstances it is being proposed that multiple unicast packets be >> sent instead of a single multi-destination packet? In other words, >> **WHY** would an RBridge use this unicast method rather than use the >> existing multi-destination D-Tree method? > > Consider a large TRILL campus in which, say, 100 end stations are in some= particular FGL data label. > > At one extreme, if all 100 end stations were attached to a single TRILL s= witch, then no other TRILL switch would be advertising interest in that FGL= and likely a multidestination (say broadcast) frame from one such end stat= ion would, even if put on a distribution tree, because of pruning, not get = sent any another TRILL switch. > > At the other extreme, assume the 100 end stations are attached, one each,= to 100 different end stations; in that case you are almost certainly bette= r off using a distribution tree because if you tried to serially unicast yo= u would cause much higher link utilitization, probably have to output some = multiple copies through the same port, etc. > > But what if these 100 end stations are connected to exactly two TRILL swi= tches, say 75 to one and 25 to the other. Using unicast TRILL Data frames b= etween these TRILL switches is better because they will follow least cost p= aths, possibly with such traffic spread over an arbitrary number of equal c= ost least cost paths. On the other hand, if one or more distribution trees = were used, each frame would be constrained to the tree used for that frame = and would likely follow a more circuitous route, depending on where the tre= e roots are. That's why the draft says "SHOULD" use unicast if there exactl= y two TRILL switches involed. > > It's a more complex decision whether to use a distribution tree or serial= unicast if the end stations are connected to a "small" number of TRILL swi= tches greater than two. So the draft just says "MAY" in that case. > >> Cheers, >> Olen > > On Wed, Nov 28, 2012 at 10:53 AM, Thomas Narten wrote= : >> Olen's original comment was about the following text in the document: >> >>> "An FGL ingress RBridge MAY serially TRILL unicast a >>> multi-destination TRILL Data frame to the relevant egress TRILL >>> switches after encapsulating it as a TRILL known unicast data frame (M= =3D0)". >> >> Does the base TRILL spec forbid the above behavior? > > While I do not think it has a statement explicitly prohibiting such behav= ior, it implicitly prohibits it by mandating that multidestination frames b= e encoded into TRILL Data frames with a TRILL Header having M=3D1 and sent = on the distribution tree indicated by the egress nickname. > > There is also the corresponding egress statement that requires FGL TRILL = switches to be able to egress such multi-destination inner frames encoded w= ith M=3D0: > > "FGL TRILL switches MUST accept multi-destination TRILL Data frames that = are sent to them as TRILL unicast frames, that is, frames that may have a m= ulticast or broadcast Inner.MacDA (or are being sent to an unknown unicast = Inner.MacDA) and the TRILL Header M bit =3D 0." > > (Actually, the current standard in effect requires all TRILL switches to = be able to egress unknown unicast frames when encoded that way. That's beca= use a destination MAC and VLAN can be known to the ingress TRILL switch, wh= ich then encodes the TRILL Data frame with M=3D0 and unicasts it to the egr= ess, but then turn out to be unknown to that egress switch because its tabl= es of attached MACs have overflowed or the entry has timds out or it has re= -booted or whatever.) > >> Is this sentence even needed? Can we just remove it? (FWIW, it seems >> to me to be unnecessary.) > > What do you mean by "needed"? It is an intentional change in TRILL; as su= ch it does something, causing significant improvement in some cases as in m= y response to Olen above. But it is just a matter of efficiency so FGL TRIL= L would still work without it. > >> Thomas > > 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 > > On Wed, Nov 28, 2012 at 7:48 PM, Radia Perlman w= rote: >> Even if the base spec doesn't preclude doing serial unicast, it might >> be worth mentioning the possiblity here because if there is a huge >> campus with so many different FGLs in use that the inner RBridges have >> trouble filtering, and there's only a few edge guys participating in >> the FGL, it might wind up being more optimal for the ingress switch to >> do serial unicast. So saying MAY just gives an implementer the hint >> that it might be a good thing to allow. >> >> At any rate, I don't think it hurts to have that sentence in the FGL spe= c. >> >> Radia >> >> >> >> >> On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten wrote= : >>> >>> Olen's original comment was about the following text in the document: >>> >>> > "An FGL ingress RBridge MAY serially TRILL unicast a >>> > multi-destination TRILL Data frame to the relevant egress TRILL >>> > switches after encapsulating it as a TRILL known unicast data frame >>> > (M=3D0)". >>> >>> Does the base TRILL spec forbid the above behavior? >>> >>> Is this sentence even needed? Can we just remove it? (FWIW, it seems >>> to me to be unnecessary.) >>> >>> Thomas >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >> >> From d3e3e3@gmail.com Thu Nov 29 21:32:17 2012 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 1CC6B21F85ED for ; Thu, 29 Nov 2012 21:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.355 X-Spam-Level: X-Spam-Status: No, score=-103.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXE2R6eqqTTk for ; Thu, 29 Nov 2012 21:32:16 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 416CA21F8488 for ; Thu, 29 Nov 2012 21:32:16 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so143773ieb.31 for ; Thu, 29 Nov 2012 21:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CnKzJiiraAI+W+PGbNl4eQrr2f+cmWqUo7/PeApok2w=; b=Cp/HqCk1sPkpC0FaGAKrk0KBQ6Kf0QSugFtTEVca0Kuwf5V8feuyc1plKR0sjWvNpr lXCODDrScDzRkn3iBQsb1nzLIIU2LPiPj8hnbSw7Yh+DVMcwWHUt7r+yJMuTKO73MZvY Ojp2zaPoxdzLGbc5rMRHmrvlMI3rciFyjOmxgQDnvJ2JrByaOqcHF3ULlQJGuWtqnHgo L5dacjl1GqcKz6Y45DzMd4iSPYBZbHusdliKA0vVHzZiohRbVzQvFjWFMLSK+nrksmIh v8MCYukqbiG2ltZL+jj+nPdlVCyAr9GJrHpXK8SPKSBDDXJMR395Q2Jsw6xULDAXNmsu jYMw== Received: by 10.50.194.131 with SMTP id hw3mr47063igc.71.1354253535903; Thu, 29 Nov 2012 21:32:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Thu, 29 Nov 2012 21:31:55 -0800 (PST) In-Reply-To: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Fri, 30 Nov 2012 00:31:55 -0500 Message-ID: To: Olen Stokes Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 05:32:17 -0000 Hi Olen, On Thu, Nov 29, 2012 at 11:20 AM, Olen Stokes wrote: > It would seem that in order for an =93inner=94 or transit-only RBridge > to improve its scaling by not including the =93filtering=94 for a > certain FGL, it would have to either: I prefer calling it "pruning", the term that, I believe, is consistently used in the TRILL standard documents, rather than "filtering" which may have other meanings to some people. Note that this aspect of optimization is not something I brought up in connection with serial unicast but something that Radia brought up. I think it is justified based on link utilization, traffic spreading, and latency considerations but saving on pruning state at transit TRILL switches is an additional justification which, as you point out below, probably requires some additional mechanism. > 1) Know which FGLs are being sent using multi-destination packets an= d > which are being sent using multiple unicast packets, or > > 2) Use a cache driven design which traps on unknown FGL labels and > installs =93filtering=94 only when a FGL is seen for the first time. Thi= s > approach also opens up the discussion about knowing when to remove inacti= ve > =93filters=94. Technique 2 seems way too complex to me. Technique 1 is the way I have been thinking about doing it but requires per data label announcement of whether serial multicast is being used for multi-destination traffic and/or per data label announcement by some elected TRILL switch for a data label that all TRILL switches MUST use serial multi-cast for multi-destination for the data label or the like. > I believe that the Interested Labels and Spanning Tree Roots sub-TLV > in RFC6326bis should use a reserved bit to indicate whether > multi-destination packets or multiple unicast packets will be used > with the indicated label(s). Exactly. That's the right place for capability/command information for this sort of thing for FGL and the Interested VLANs sub-TLV for VL data labels. You also want to prune the set of serial unicast transmissions to be made at the source so each possible source for the data label needs to know the multicast listener situation. But it is wasteful of link state space to flood that information everywhere. So you want to distribute it through ESADI if all the TRILL switches interested in a data label are capable of serial unicast and ESADI participants for that data label. So my inclination is to put little about this in the FGL draft and most of this into the ESDAI draft. The current ESADI draft already has material in it about a capability bit for serially unicasting ESADI PDUs which could be generalized to a broader capability for serially unicating multi-destination frames. Since the FGL draft is about FGL, I think the best it should do is as it presently does: FLG TRILL switches MUST be able to receive serially unicast multi-destination FGL frames, MAY transmit such frames, and SHOULD so transmit multi-destination frames if there is only one relevant destination TRILL switch. 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 > Cheers, > Olen > > > > From: Radia Perlman [mailto:radiaperlman@gmail.com] > Sent: Wednesday, November 28, 2012 7:49 PM > To: Thomas Narten > Cc: Olen Stokes; Donald Eastlake; trill@ietf.org > > > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > > > Even if the base spec doesn't preclude doing serial unicast, it might be > worth mentioning the possiblity here because if there is a huge campus wi= th > so many different FGLs in use that the inner RBridges have trouble > filtering, and there's only a few edge guys participating in the FGL, it > might wind up being more optimal for the ingress switch to do serial > unicast. So saying MAY just gives an implementer the hint that it might = be > a good thing to allow. > > > > At any rate, I don't think it hurts to have that sentence in the FGL spec= . > > > > Radia > > > > > > > > On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten wrote: > > Olen's original comment was about the following text in the document: > > >> "An FGL ingress RBridge MAY serially TRILL unicast a multi-destination >> TRILL Data frame to the relevant egress TRILL switches after encapsulati= ng >> it as a TRILL known unicast data frame (M=3D0)". > > Does the base TRILL spec forbid the above behavior? > > Is this sentence even needed? Can we just remove it? (FWIW, it seems > to me to be unnecessary.) > > Thomas From zhangmingui@huawei.com Fri Nov 30 00:18:33 2012 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 014A321F89BB for ; Fri, 30 Nov 2012 00:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAGepfLeSfRz for ; Fri, 30 Nov 2012 00:18:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E30EF21F89B5 for ; Fri, 30 Nov 2012 00:18:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANI83519; Fri, 30 Nov 2012 08:18:29 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 08:18:13 +0000 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 08:18:27 +0000 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.003; Fri, 30 Nov 2012 16:18:09 +0800 From: Mingui Zhang To: "trill@ietf.org" Thread-Topic: TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3O0ux4S0JhVhpwS56Ahgx4dyNymw== Date: Fri, 30 Nov 2012 08:18:08 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: cME= Agae A/jK B0VR DFl5 EdB0 Fsmd GZ4E Hppj IQPv JEYT JMpL JXfF KaMR Kpa8 K9LX; 1; dAByAGkAbABsAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {A93329E7-DA9A-49F3-A8E7-939D7BA4C62D}; egBoAGEAbgBnAG0AaQBuAGcAdQBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 30 Nov 2012 08:15:56 GMT; VABSAEkATABMACAAUgBlAHMAaQBsAGkAZQBuAHQAIABEAGkAcwB0AHIAaQBiAHUAdABpAG8AbgAgAFQAcgBlAGUAcwAsACAAdwBoAG8AIABoAGEAdgBlACAAcgBlAGEAZAAgAGkAdAA/AA== x-cr-puzzleid: {A93329E7-DA9A-49F3-A8E7-939D7BA4C62D} x-originating-ip: [10.111.102.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 08:18:33 -0000 Hi all, When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection= solutions cannot be reused by TRILL because TRILL-multicast is customized = for TRILL. Therefore we composed the draft to provide the multicast protect= ion suitable for TRILL. As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant. We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft?=20 The draft TRILL Resilient Distribution Trees http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ Thanks, Mingui From ostokes@extremenetworks.com Fri Nov 30 12:42:44 2012 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 0C33021F85BB for ; Fri, 30 Nov 2012 12:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW5xfECUHN5e for ; Fri, 30 Nov 2012 12:42:43 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 49C1321F85B4 for ; Fri, 30 Nov 2012 12:42:43 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Fri, 30 Nov 2012 12:42:36 -0800 From: Olen Stokes To: Donald Eastlake Date: Fri, 30 Nov 2012 12:42:36 -0800 Thread-Topic: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Thread-Index: Ac3OvA9zJDr6R2kdQGaXi0HZ+9WW3AAe6TsQ Message-ID: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 20:42:44 -0000 No hang-ups on "pruning" versus "filtering". I just wanted to use the same= term as Radia had used since I was responding to her email. >From below: >"Technique 1 is the way I have been thinking about doing it but requires p= er data label announcement of whether serial multicast is being used for mu= lti->destination traffic and/or per data label announcement by some elected= TRILL switch for a data label that all TRILL switches MUST use serial mult= i-cast for >multi-destination for the data label or the like." It would seem possible that each edge RBridge could use a unique/different = algorithm to determine whether or not it should serially send multi-destina= tion traffic. Therefore, to me, the indication that we are discussing is o= ne that says that a particular edge RBridge is currently using serial trans= mission. In other words, it says that it **IS** using serial transmissions= as opposed to saying that it **CAN**use serial transmission. =20 An individual transit RBridge could then optimize its pruning resources by = detecting whether any edge RBridge has indicated interest in a FGL and has = also indicated that it is not using serial transmission of multi-destinatio= n packets. This would avoid having to elect a RBridge for controlling the = transmission technique to be used for a particular FGL (as well as what to = do when the elected RBridge disappears). Based on your discussion, as the number of RBridges interested in a FGL inc= reases, one or more edge RBridges may decide to switch from serial transmis= sion to the use of normal D-Tree multi-destination transmission. At that p= oint they would change their usage indication. The transit RBridges would = have to detect the change in settings and react accordingly. Cheers, Olen -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Friday, November 30, 2012 12:32 AM To: Olen Stokes Cc: trill@ietf.org Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt Hi Olen, On Thu, Nov 29, 2012 at 11:20 AM, Olen Stokes = wrote: > It would seem that in order for an "inner" or transit-only RBridge to=20 > improve its scaling by not including the "filtering" for a certain=20 > FGL, it would have to either: I prefer calling it "pruning", the term that, I believe, is consistently us= ed in the TRILL standard documents, rather than "filtering" which may have = other meanings to some people. Note that this aspect of optimization is not= something I brought up in connection with serial unicast but something tha= t Radia brought up. I think it is justified based on link utilization, traf= fic spreading, and latency considerations but saving on pruning state at tr= ansit TRILL switches is an additional justification which, as you point out= below, probably requires some additional mechanism. > 1) Know which FGLs are being sent using multi-destination packets an= d > which are being sent using multiple unicast packets, or > > 2) Use a cache driven design which traps on unknown FGL labels and > installs "filtering" only when a FGL is seen for the first time. This=20 > approach also opens up the discussion about knowing when to remove=20 > inactive "filters". Technique 2 seems way too complex to me. Technique 1 is the way I have been thinking about doing it but requires per= data label announcement of whether serial multicast is being used for mult= i-destination traffic and/or per data label announcement by some elected TR= ILL switch for a data label that all TRILL switches MUST use serial multi-c= ast for multi-destination for the data label or the like. > I believe that the Interested Labels and Spanning Tree Roots sub-TLV=20 > in RFC6326bis should use a reserved bit to indicate whether=20 > multi-destination packets or multiple unicast packets will be used=20 > with the indicated label(s). Exactly. That's the right place for capability/command information for this= sort of thing for FGL and the Interested VLANs sub-TLV for VL data labels. You also want to prune the set of serial unicast transmissions to be made a= t the source so each possible source for the data label needs to know the m= ulticast listener situation. But it is wasteful of link state space to floo= d that information everywhere. So you want to distribute it through ESADI i= f all the TRILL switches interested in a data label are capable of serial u= nicast and ESADI participants for that data label. So my inclination is to put little about this in the FGL draft and most of = this into the ESDAI draft. The current ESADI draft already has material in = it about a capability bit for serially unicasting ESADI PDUs which could be= generalized to a broader capability for serially unicating multi-destinati= on frames. Since the FGL draft is about FGL, I think the best it should do is as it pr= esently does: FLG TRILL switches MUST be able to receive serially unicast m= ulti-destination FGL frames, MAY transmit such frames, and SHOULD so transm= it multi-destination frames if there is only one relevant destination TRILL= switch. 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 > Cheers, > Olen > > > > From: Radia Perlman [mailto:radiaperlman@gmail.com] > Sent: Wednesday, November 28, 2012 7:49 PM > To: Thomas Narten > Cc: Olen Stokes; Donald Eastlake; trill@ietf.org > > > Subject: Re: [trill] WG Last Call:=20 > draft-ietf-trill-fine-labeling-02.txt > > > > Even if the base spec doesn't preclude doing serial unicast, it might=20 > be worth mentioning the possiblity here because if there is a huge=20 > campus with so many different FGLs in use that the inner RBridges have=20 > trouble filtering, and there's only a few edge guys participating in=20 > the FGL, it might wind up being more optimal for the ingress switch to=20 > do serial unicast. So saying MAY just gives an implementer the hint=20 > that it might be a good thing to allow. > > > > At any rate, I don't think it hurts to have that sentence in the FGL spec= . > > > > Radia > > > > > > > > On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten wrote: > > Olen's original comment was about the following text in the document: > > >> "An FGL ingress RBridge MAY serially TRILL unicast a=20 >> multi-destination TRILL Data frame to the relevant egress TRILL=20 >> switches after encapsulating it as a TRILL known unicast data frame (M= =3D0)". > > Does the base TRILL spec forbid the above behavior? > > Is this sentence even needed? Can we just remove it? (FWIW, it seems=20 > to me to be unnecessary.) > > Thomas From radiaperlman@gmail.com Fri Nov 30 14:24:01 2012 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 78F2421F883F for ; Fri, 30 Nov 2012 14:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VjnDIcDSIYw for ; Fri, 30 Nov 2012 14:24:00 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id ACE1421F865B for ; Fri, 30 Nov 2012 14:23:59 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so14121990vba.27 for ; Fri, 30 Nov 2012 14:23:58 -0800 (PST) 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:content-type; bh=opme5+5EA47N5p7v2UgmWcTsM2NtbkwIJoAvwi4sSlE=; b=LC8TbZO8E16CwkKkzSyT6cAqsA4COdtXPbCikqxlfc2a7X649zPEoRyKT6J9ZTa98s lMMWjWjDTvC2JY3D7dqOMODB8UzkJLPAygDl9iDYPFUdHqdoXl1YvqVhBRbNrolFytxz i31tMvBkGpLBa44QsBlqzYsTnKaLxRiSWTbY0o/ITmRs+RdROwHZPqWLu9banqZoEaV0 CL0oiMQOPWum0LqL0Ko1bAQRhh98qbMqSa2b7pphWBDcXviYzFaHsC5PjjqbMMnTQ02T hAJ+WBXFuwpZKGLYvue+LHj/P0CX+UrJMemNz6tT32hcz6Ht78tzuoeX1XHvN27+JtqQ DqSw== MIME-Version: 1.0 Received: by 10.59.13.197 with SMTP id fa5mr2340988ved.47.1354314238624; Fri, 30 Nov 2012 14:23:58 -0800 (PST) Received: by 10.58.207.138 with HTTP; Fri, 30 Nov 2012 14:23:58 -0800 (PST) In-Reply-To: References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> Date: Fri, 30 Nov 2012 23:23:58 +0100 Message-ID: From: Radia Perlman To: Olen Stokes Content-Type: multipart/alternative; boundary=089e0118499c1b86c404cfbddb93 Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 22:24:01 -0000 --089e0118499c1b86c404cfbddb93 Content-Type: text/plain; charset=ISO-8859-1 So I think Olen, you are saying that it's useful for an edge RB in FGL #x to say "I'm planning on using serial unicast when transmitting to FGL #x. If all the edge RBs in FGL x say that, then the core RBs don't have to bother storing pruning state about FGL x, since they will never see multidestination frames for FGL x. I don;'t think the draft currently says that, and it does sound useful. Another topic...suppose a transit RB ignores all tags on unicast...in other words, it forwards based solely on the "egress nickname" in the TRILL header...then it seems like it ought to be able to work fine for FGLs that are transmitted as serial unicast. I'd assume all RBs behave that way today (not looking for VLAN tags inside when forwarding TRILL unicast). So it might be another strategy for mixed VL/FGL campuses for FGL edge RBs to MUST serial unicast if there are any transit VL RBs. And furthermore, if an implementation of a transit RB were to be "lazy" about pruning, and not bother looking for VLAN tags, and only transmit on the tree, then it ought to work fine as a transit RB, even if it doesn't know how to parse FGL. Might there be implementations that could more trivially be upgraded to indicate this behavior than to be upgraded to parse FGL? Or if it looked for a VLAN tag, couldn't find it (because there was an FGL), and it decides, because it sees this weird unknown tag, to forward it anyway rather than drop it, then it also would work fine as a transit RB. Do we know how current VL implementations behave if they can't find a VLAN tag? If they all happen to behave in this way (forward frames with no VLAN tag on the tree), then again, it seems like we can say it's fine to have VL RBs as transit. I suppose if it's trivial to upgrade all the current RBs to parse FGL, then it probably doesn't matter... Radia On Fri, Nov 30, 2012 at 9:42 PM, Olen Stokes wrote: > No hang-ups on "pruning" versus "filtering". I just wanted to use the > same term as Radia had used since I was responding to her email. > > From below: > > >"Technique 1 is the way I have been thinking about doing it but requires > per data label announcement of whether serial multicast is being used for > multi->destination traffic and/or per data label announcement by some > elected TRILL switch for a data label that all TRILL switches MUST use > serial multi-cast for >multi-destination for the data label or the like." > > It would seem possible that each edge RBridge could use a unique/different > algorithm to determine whether or not it should serially send > multi-destination traffic. Therefore, to me, the indication that we are > discussing is one that says that a particular edge RBridge is currently > using serial transmission. In other words, it says that it **IS** using > serial transmissions as opposed to saying that it **CAN**use serial > transmission. > > An individual transit RBridge could then optimize its pruning resources by > detecting whether any edge RBridge has indicated interest in a FGL and has > also indicated that it is not using serial transmission of > multi-destination packets. This would avoid having to elect a RBridge for > controlling the transmission technique to be used for a particular FGL (as > well as what to do when the elected RBridge disappears). > > Based on your discussion, as the number of RBridges interested in a FGL > increases, one or more edge RBridges may decide to switch from serial > transmission to the use of normal D-Tree multi-destination transmission. > At that point they would change their usage indication. The transit > RBridges would have to detect the change in settings and react accordingly. > > Cheers, > Olen > > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Friday, November 30, 2012 12:32 AM > To: Olen Stokes > Cc: trill@ietf.org > Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt > > Hi Olen, > > On Thu, Nov 29, 2012 at 11:20 AM, Olen Stokes > wrote: > > It would seem that in order for an "inner" or transit-only RBridge to > > improve its scaling by not including the "filtering" for a certain > > FGL, it would have to either: > > I prefer calling it "pruning", the term that, I believe, is consistently > used in the TRILL standard documents, rather than "filtering" which may > have other meanings to some people. Note that this aspect of optimization > is not something I brought up in connection with serial unicast but > something that Radia brought up. I think it is justified based on link > utilization, traffic spreading, and latency considerations but saving on > pruning state at transit TRILL switches is an additional justification > which, as you point out below, probably requires some additional mechanism. > > > 1) Know which FGLs are being sent using multi-destination packets > and > > which are being sent using multiple unicast packets, or > > > > 2) Use a cache driven design which traps on unknown FGL labels and > > installs "filtering" only when a FGL is seen for the first time. This > > approach also opens up the discussion about knowing when to remove > > inactive "filters". > > Technique 2 seems way too complex to me. > > Technique 1 is the way I have been thinking about doing it but requires > per data label announcement of whether serial multicast is being used for > multi-destination traffic and/or per data label announcement by some > elected TRILL switch for a data label that all TRILL switches MUST use > serial multi-cast for multi-destination for the data label or the like. > > > I believe that the Interested Labels and Spanning Tree Roots sub-TLV > > in RFC6326bis should use a reserved bit to indicate whether > > multi-destination packets or multiple unicast packets will be used > > with the indicated label(s). > > Exactly. That's the right place for capability/command information for > this sort of thing for FGL and the Interested VLANs sub-TLV for VL data > labels. > > You also want to prune the set of serial unicast transmissions to be made > at the source so each possible source for the data label needs to know the > multicast listener situation. But it is wasteful of link state space to > flood that information everywhere. So you want to distribute it through > ESADI if all the TRILL switches interested in a data label are capable of > serial unicast and ESADI participants for that data label. > > So my inclination is to put little about this in the FGL draft and most of > this into the ESDAI draft. The current ESADI draft already has material in > it about a capability bit for serially unicasting ESADI PDUs which could be > generalized to a broader capability for serially unicating > multi-destination frames. > > Since the FGL draft is about FGL, I think the best it should do is as it > presently does: FLG TRILL switches MUST be able to receive serially unicast > multi-destination FGL frames, MAY transmit such frames, and SHOULD so > transmit multi-destination frames if there is only one relevant destination > TRILL switch. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > > > Cheers, > > Olen > > > > > > > > From: Radia Perlman [mailto:radiaperlman@gmail.com] > > Sent: Wednesday, November 28, 2012 7:49 PM > > To: Thomas Narten > > Cc: Olen Stokes; Donald Eastlake; trill@ietf.org > > > > > > Subject: Re: [trill] WG Last Call: > > draft-ietf-trill-fine-labeling-02.txt > > > > > > > > Even if the base spec doesn't preclude doing serial unicast, it might > > be worth mentioning the possiblity here because if there is a huge > > campus with so many different FGLs in use that the inner RBridges have > > trouble filtering, and there's only a few edge guys participating in > > the FGL, it might wind up being more optimal for the ingress switch to > > do serial unicast. So saying MAY just gives an implementer the hint > > that it might be a good thing to allow. > > > > > > > > At any rate, I don't think it hurts to have that sentence in the FGL > spec. > > > > > > > > Radia > > > > > > > > > > > > > > > > On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten > wrote: > > > > Olen's original comment was about the following text in the document: > > > > > >> "An FGL ingress RBridge MAY serially TRILL unicast a > >> multi-destination TRILL Data frame to the relevant egress TRILL > >> switches after encapsulating it as a TRILL known unicast data frame > (M=0)". > > > > Does the base TRILL spec forbid the above behavior? > > > > Is this sentence even needed? Can we just remove it? (FWIW, it seems > > to me to be unnecessary.) > > > > Thomas > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --089e0118499c1b86c404cfbddb93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So I think Olen, you are saying that it's useful for an edge RB in= FGL #x to say "I'm planning on using serial unicast when transmit= ting to FGL #x.=A0 If all the edge RBs in FGL x say that, then the core RBs= don't have to bother=A0storing pruning state about FGL x, since they w= ill never see multidestination frames for FGL x.=A0 I don;'t think the = draft currently says that, and it does sound useful.
=A0
Another topic...suppose a transit RB ignores all tags on= unicast...in other words, it forwards based solely on the "egress nic= kname" in the TRILL header...then it seems like it ought to be able to= work fine for FGLs that are transmitted as serial unicast. I'd assume = all RBs behave that way today (not looking for VLAN tags inside when forwar= ding TRILL unicast). So it might be another strategy for mixed VL/FGL campu= ses for FGL edge RBs to MUST serial unicast if there are any transit VL RBs= .
=A0
And furthermore, if an implementation of a transit RB we= re to be "lazy" about pruning, and not bother looking for VLAN ta= gs, and only transmit on the tree, then it ought to work fine as a transit = RB, even if it doesn't know how to parse FGL. Might there be implementa= tions that could more trivially be upgraded to indicate this behavior than = to be upgraded to parse FGL?
=A0
Or if it looked for a VLAN tag, couldn't find it (be= cause there was an FGL), and it decides, because it sees this weird unknown= tag, to forward it anyway rather than drop it, then it also would work fin= e as a transit RB. Do we know how current VL implementations behave if they= can't find a VLAN tag?=A0 If they all happen to behave in this way (fo= rward frames with no VLAN tag on the tree), then again, it seems like we ca= n say it's fine to have VL RBs as transit.
=A0
I suppose if it's trivial to upgrade all the current= RBs to parse FGL, then it probably doesn't matter...
=A0
Radia
=A0


=A0
On Fri, Nov 30, 2012 at 9:42 PM, Olen Stokes <ostokes@extremene= tworks.com> wrote:
No hang-ups on "pruning" versus "filtering". =A0I just = wanted to use the same term as Radia had used since I was responding to her= email.

>From below:

>"Technique 1 is the way I have been thinking about doing it but re= quires per data label announcement of whether serial multicast is being use= d for multi->destination traffic and/or per data label announcement by s= ome elected TRILL switch for a data label that all TRILL switches MUST use = serial multi-cast for >multi-destination for the data label or the like.= "

It would seem possible that each edge RBridge could use a unique/different = algorithm to determine whether or not it should serially send multi-destina= tion traffic. =A0Therefore, to me, the indication that we are discussing is= one that says that a particular edge RBridge is currently using serial tra= nsmission. =A0In other words, it says that it **IS** using serial transmiss= ions as opposed to saying that it **CAN**use serial transmission.

An individual transit RBridge could then optimize its pruning resources by = detecting whether any edge RBridge has indicated interest in a FGL and has = also indicated that it is not using serial transmission of multi-destinatio= n packets. =A0This would avoid having to elect a RBridge for controlling th= e transmission technique to be used for a particular FGL (as well as what t= o do when the elected RBridge disappears).

Based on your discussion, as the number of RBridges interested in a FGL inc= reases, one or more edge RBridges may decide to switch from serial transmis= sion to the use of normal D-Tree multi-destination transmission. =A0At that= point they would change their usage indication. =A0The transit RBridges wo= uld have to detect the change in settings and react accordingly.

Cheers,
Olen


-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gm= ail.com]
Sent: Friday, November 30, 20= 12 12:32 AM
To: Olen Stokes
Cc: trill@ietf.org
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt
Hi Olen,

On Thu, Nov 29, 2012 at 11:20 AM, Olen Stokes <ostokes@extremenetworks.com> wrote:
> It would seem that in order for an "inner" or transit-only R= Bridge to
> improve its scaling by not including the "filtering" for a c= ertain
> FGL, it would have to either:

I prefer calling it "pruning", the term that, I believe, is consi= stently used in the TRILL standard documents, rather than "filtering&q= uot; which may have other meanings to some people. Note that this aspect of= optimization is not something I brought up in connection with serial unica= st but something that Radia brought up. I think it is justified based on li= nk utilization, traffic spreading, and latency considerations but saving on= pruning state at transit TRILL switches is an additional justification whi= ch, as you point out below, probably requires some additional mechanism.
> 1) =A0 =A0 =A0Know which FGLs are being sent using multi-destination p= ackets and
> which are being sent using multiple unicast packets, or
>
> 2) =A0 =A0 =A0Use a cache driven design which traps on unknown FGL lab= els and
> installs "filtering" only when a FGL is seen for the first t= ime. =A0This
> approach also opens up the discussion about knowing when to remove
> inactive "filters".

Technique 2 seems way too complex to me.

Technique 1 is the way I have been thinking about doing it but requires per= data label announcement of whether serial multicast is being used for mult= i-destination traffic and/or per data label announcement by some elected TR= ILL switch for a data label that all TRILL switches MUST use serial multi-c= ast for multi-destination for the data label or the like.

> I believe that the Interested Labels and Spanning Tree Roots sub-TLV > in RFC6326bis should use a reserved bit to indicate whether
> multi-destination packets or multiple unicast packets will be used
> with the indicated label(s).

Exactly. That's the right place for capability/command information for = this sort of thing for FGL and the Interested VLANs sub-TLV for VL data lab= els.

You also want to prune the set of serial unicast transmissions to be made a= t the source so each possible source for the data label needs to know the m= ulticast listener situation. But it is wasteful of link state space to floo= d that information everywhere. So you want to distribute it through ESADI i= f all the TRILL switches interested in a data label are capable of serial u= nicast and ESADI participants for that data label.

So my inclination is to put little about this in the FGL draft and most of = this into the ESDAI draft. The current ESADI draft already has material in = it about a capability bit for serially unicasting ESADI PDUs which could be= generalized to a broader capability for serially unicating multi-destinati= on frames.

Since the FGL draft is about FGL, I think the best it should do is as it pr= esently does: FLG TRILL switches MUST be able to receive serially unicast m= ulti-destination FGL frames, MAY transmit such frames, and SHOULD so transm= it multi-destination frames if there is only one relevant destination TRILL= switch.

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

> Cheers,
> Olen
>
>
>
> From: Radia Perlman [mailto:= radiaperlman@gmail.com]
> Sent: Wednesday, November 28, 2012 7:49 PM
> To: Thomas Narten
> Cc: Olen Stokes; Donald Eastlake; tr= ill@ietf.org
>
>
> Subject: Re: [trill] WG Last Call:
> draft-ietf-trill-fine-labeling-02.txt
>
>
>
> Even if the base spec doesn't preclude doing serial unicast, it mi= ght
> be worth mentioning the possiblity here because if there is a huge
> campus with so many different FGLs in use that the inner RBridges have=
> trouble filtering, and there's only a few edge guys participating = in
> the FGL, it might wind up being more optimal for the ingress switch to=
> do serial unicast. =A0So saying MAY just gives an implementer the hint=
> that it might be a good thing to allow.
>
>
>
> At any rate, I don't think it hurts to have that sentence in the F= GL spec.
>
>
>
> Radia
>
>
>
>
>
>
>
> On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten <narten@us.ibm.com> wrote:
>
> Olen's original comment was about the following text in the docume= nt:
>
>
>> "An FGL ingress RBridge MAY serially TRILL unicast a
>> multi-destination TRILL Data frame to the relevant egress TRILL >> switches after encapsulating it as a TRILL known unicast data fram= e (M=3D0)".
>
> Does the base TRILL spec forbid the above behavior?
>
> Is this sentence even needed? Can we just remove it? (FWIW, it seems > to me to be unnecessary.)
>
> Thomas
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--089e0118499c1b86c404cfbddb93--