From d3e3e3@gmail.com Tue May 1 12:52: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 6F61821E8403 for ; Tue, 1 May 2012 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.285 X-Spam-Level: X-Spam-Status: No, score=-104.285 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENODdntRFlpM for ; Tue, 1 May 2012 12:52:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9F78921E837C for ; Tue, 1 May 2012 12:52:32 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.213.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q41Jprl0014890 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 May 2012 12:52:02 -0700 (PDT) Received: by yenl4 with SMTP id l4so3408943yen.39 for ; Tue, 01 May 2012 12:51:53 -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:content-transfer-encoding; bh=ff5jjd1qLrG6H/Oi8TZaysgM2JGglr/hiSgC5KtjUNo=; b=foPZukZjYugjeh1PAbzuv5iw5MWHy5mIUjgVNHYsgvvxvA7nQWcNvpgw+tx2iCu/4O MNYApd3EYrwi2RwsJ08khUKynlV0svm4xhK3Gno37P+w1g29O0EkJD6yYjS2QIM0Jp+k 6GsJYiPe43rRpkSujIUCnA7Dv1cVXOcM/CZf/p2MNvh4dDIvMZhwROWiRZAQbse2f9jX 310AFOIHc1Y+EiR37rsPhA0I/7tFAbB6IbXIdDTxEsUk3dGP89V5EMBU7BfIuXmz0JAZ 6/O+zMydYDZJcnlNi9lo5XSbpAgvvlH0rHhLAWKUY1wIfV5qCR3MennX1ZKxh0pP6dRa HsBg== Received: by 10.42.88.135 with SMTP id c7mr19361391icm.57.1335901912825; Tue, 01 May 2012 12:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Tue, 1 May 2012 12:51:32 -0700 (PDT) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5D10826@xmb-sjc-214.amer.cisco.com> References: <344037D7CFEFE84E97E9CC1F56C5F4A5D10826@xmb-sjc-214.amer.cisco.com> From: Donald Eastlake Date: Tue, 1 May 2012 15:51:32 -0400 Message-ID: To: "Tissa Senevirathne (tsenevir)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com Cc: rbridge@postel.org Subject: Re: [trill] [rbridge] TRILL Multi-topology encoding 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: Tue, 01 May 2012 19:52:33 -0000 While this certainly encodes topology into frames, it is not clear to me that the technique using a new tag is generally supported by existing TRILL 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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Mar 26, 2012 at 12:54 PM, Tissa Senevirathne (tsenevir) wrote: > Dear All > > > We have posted draft-tissa-trill-mt-encode-00. This draft discuss methods > that can be used to encode multi topology id without exhausting nickname > space or adding additional control plane extensions to abbreviate absolut= e > topology. Please let us know your comments. > > > > Abstract: > > > > =A0=A0 Two alternative methods of encoding Multi Topology Identifier with= in > > =A0=A0 the TRILL data frames are presented. Methods proposed herein do no= t > > =A0=A0 require overloading TRILL RBridge nickname to encode Multi Topolog= y > > =A0=A0 Identifier. > > > > Thanks > > Tissa > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From tsenevir@cisco.com Tue May 1 16:01: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 C918521E8024 for ; Tue, 1 May 2012 16:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.894 X-Spam-Level: X-Spam-Status: No, score=-6.894 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7jPPWN3EoNa for ; Tue, 1 May 2012 16:01:05 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0721E8042 for ; Tue, 1 May 2012 16:01:04 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q41N0Pk9002661 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 May 2012 16:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=1696; q=dns/txt; s=iport; t=1335913234; x=1337122834; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Og9fX1DwkJSzRQ720KAWDtDcDoroSRCveC90nlg2vhM=; b=lDEc/C/8h0CtP5IB03wZYMoFEq23lqjUaEpCN4Cwcr8LeXGZ7XPN+DFz ZI78yd8mlNayAMidhoZiRSrqsk2+f2nxoyTzsXVLHWoykRTObis+kf8/l ip8gJuhEcuodCQYueuUeQk0INDe2I8gE1IFPIh1/1ZoVnvkFYGK459FRy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAKFpoE+rRDoJ/2dsb2JhbABBA695gwGBB4IJAQEBBAEBAQ8BHT4LDAQCAQgOAwQBAQEKBhcBBgEgBh8JCAEBBBMIGoddAwoBC5o1lVgNiVOKB4NYgkdjBIgwNI4rii6DGoFpgwg X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="43048779" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 01 May 2012 23:00:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q41N0Oni006317; Tue, 1 May 2012 23:00:24 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 16:00:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 16:00:23 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A3734@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TRILL Multi-topology encoding draft Thread-Index: Ac0n09xKh0/pDtn5QuyKoYtTjrF8jQAGfEdA References: <344037D7CFEFE84E97E9CC1F56C5F4A5D10826@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" X-OriginalArrivalTime: 01 May 2012 23:00:24.0834 (UTC) FILETIME=[3169F620:01CD27EE] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org Subject: Re: [trill] [rbridge] TRILL Multi-topology encoding 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: Tue, 01 May 2012 23:01:05 -0000 Hi Donald In the ID we have specified a backward compatibility mode where one can = use NH-VLAN to encode the multi topology ID on pt-pt links. -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Tuesday, May 01, 2012 12:52 PM To: Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org Subject: Re: [rbridge] TRILL Multi-topology encoding draft While this certainly encodes topology into frames, it is not clear to me = that the technique using a new tag is generally supported by existing = TRILL 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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Mar 26, 2012 at 12:54 PM, Tissa Senevirathne (tsenevir) = wrote: > Dear All > > > We have posted draft-tissa-trill-mt-encode-00. This draft discuss=20 > methods that can be used to encode multi topology id without=20 > exhausting nickname space or adding additional control plane=20 > extensions to abbreviate absolute topology. Please let us know your = comments. > > > > Abstract: > > > > =A0=A0 Two alternative methods of encoding Multi Topology Identifier=20 > within > > =A0=A0 the TRILL data frames are presented. Methods proposed herein do = not > > =A0=A0 require overloading TRILL RBridge nickname to encode Multi = Topology > > =A0=A0 Identifier. > > > > Thanks > > Tissa > > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From internet-drafts@ietf.org Wed May 2 06:25:29 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 543E221F85C0; Wed, 2 May 2012 06:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtBxpgCTIlE7; Wed, 2 May 2012 06:25:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E582E21F8475; Wed, 2 May 2012 06:25:28 -0700 (PDT) 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.02 Message-ID: <20120502132528.28151.16955.idtracker@ietfa.amsl.com> Date: Wed, 02 May 2012 06:25:28 -0700 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-rbridge-extension-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: Wed, 02 May 2012 13:25:29 -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 o= f Links Working Group of the IETF. Title : TRILL: Header Extension Author(s) : Donald Eastlake Anoop Ghanwani Vishwas Manral Yizhou Li Caitlin Bestler Filename : draft-ietf-trill-rbridge-extension-04.txt Pages : 15 Date : 2012-05-02 The IETF TRILL (Transparent Interconnection of Lots of Links) base protocol specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies two of those bits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-04.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-extension/ From ghanwani@gmail.com Wed May 2 09:16: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 6499521F853D for ; Wed, 2 May 2012 09:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuqniiCVxTx4 for ; Wed, 2 May 2012 09:16:44 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BDC3C21F853B for ; Wed, 2 May 2012 09:16:44 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q42GFfGP015971 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 2 May 2012 09:15:50 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so1687764pbb.39 for ; Wed, 02 May 2012 09:15:41 -0700 (PDT) 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 :content-transfer-encoding; bh=hr0kXadheSWf2Dqom3PCngpZIkfOh5d9uJjrV/VKtDU=; b=mCyb/biVTr7w8vGmjo/mJTajJrOAUWKT3hTRKj+tynCEf6n3gFlhPHeJ7bD+Og4t18 a3gW1PTHgwErekQnkl7377PVsenVVLsPJ2QKKUfmaVPde8eqaQndK6o8rKMJSoZRwfGZ gnm/D17EQ+NVopITXSPBCLyPTsQ0xxhdzKsLvluY5cNia4jdMlbkGQDwURxgpVKPJAp8 OsRvK/5+myiR37u1l249tCh1NGl5w6U7TrmMjhq/znGHM3/LZKIIR71CYmywTnXZ1To2 w54tEjSL8u33iYb3GfVQy+GVOi36mWjgiPJJkmHNARSyK9A2KK97j/yYN+CXdAOuMEAU bm6g== MIME-Version: 1.0 Received: by 10.68.238.38 with SMTP id vh6mr727701pbc.50.1335975341241; Wed, 02 May 2012 09:15:41 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.142.153.18 with HTTP; Wed, 2 May 2012 09:15:41 -0700 (PDT) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5010A3734@xmb-sjc-214.amer.cisco.com> References: <344037D7CFEFE84E97E9CC1F56C5F4A5D10826@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A3734@xmb-sjc-214.amer.cisco.com> Date: Wed, 2 May 2012 09:15:41 -0700 X-Google-Sender-Auth: _L-mesHgCbugXl3_tCTV-Wgq7SI Message-ID: From: Anoop Ghanwani To: "Tissa Senevirathne (tsenevir)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ghanwani@gmail.com Cc: Donald Eastlake , rbridge@postel.org Subject: Re: [trill] [rbridge] TRILL Multi-topology encoding 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: Wed, 02 May 2012 16:16:45 -0000 When using the outer-VLAN, while the frame format itself would be backwards compatible, I don't believe existing silicon would actually be able to make use of it. So it depends on what we mean by "backwards compatibility"? Do we need the data plane to be backwards compatible? If so, neither encoding mechanism works. Or do we need just the frame format to be backwards compatible? Then using the outer VLAN works. Anoop On Tue, May 1, 2012 at 4:00 PM, Tissa Senevirathne (tsenevir) wrote: > Hi Donald > > In the ID we have specified a backward compatibility mode where one can u= se NH-VLAN to encode the multi topology ID on pt-pt links. > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, May 01, 2012 12:52 PM > To: Tissa Senevirathne (tsenevir) > Cc: rbridge@postel.org > Subject: Re: [rbridge] TRILL Multi-topology encoding draft > > While this certainly encodes topology into frames, it is not clear to me = that the technique using a new tag is generally supported by existing TRILL= 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 > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > > On Mon, Mar 26, 2012 at 12:54 PM, Tissa Senevirathne (tsenevir) wrote: >> Dear All >> >> >> We have posted draft-tissa-trill-mt-encode-00. This draft discuss >> methods that can be used to encode multi topology id without >> exhausting nickname space or adding additional control plane >> extensions to abbreviate absolute topology. Please let us know your comm= ents. >> >> >> >> Abstract: >> >> >> >> =A0=A0 Two alternative methods of encoding Multi Topology Identifier >> within >> >> =A0=A0 the TRILL data frames are presented. Methods proposed herein do n= ot >> >> =A0=A0 require overloading TRILL RBridge nickname to encode Multi Topolo= gy >> >> =A0=A0 Identifier. >> >> >> >> Thanks >> >> Tissa >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Wed May 2 09:19: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 328A621F85FB for ; Wed, 2 May 2012 09:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.727 X-Spam-Level: X-Spam-Status: No, score=-103.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqA-+IckhZna for ; Wed, 2 May 2012 09:19:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEE6621F85B9 for ; Wed, 2 May 2012 09:19:52 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1385359obb.31 for ; Wed, 02 May 2012 09:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=W3L+kCoJZKUBVKO7X8OweAgSlDgxUZxnmY7iSe1x3wY=; b=Emlk/rtgvzDRTaV1jXHn8TQFVRBO7qRfFbmL7S0cL1NNJsn6D9MCp9qZO0V3KUj2SM TQWbF+0PRyuHoH6QaaB2DxBllYmDlYRaYMeMgIFEVGkSxyvfPdYKLVUx/yLeREYhegEm 6wOGfu1KKpE94P7MCklZpgrwA4Nk5IoDA7Qb5losZonsSuBr6H0QcyEvvO2FemlPngyu 94UtMsz4DHL+Sa6AaXtR1VfMZcZ0HIAGea8e+iwAAABX7W9rcM1WlR/Jqb8OTUK9Mjjn 1RPcHKWMrfEMCHSQHKGQfhZ+QXGcfVDWxlyjHGgphtNbE88A9UIvX0yAeeRchV9Sx0cR RvYA== Received: by 10.182.154.73 with SMTP id vm9mr33044931obb.72.1335975592379; Wed, 02 May 2012 09:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.143.65 with HTTP; Wed, 2 May 2012 09:19:31 -0700 (PDT) From: Donald Eastlake Date: Wed, 2 May 2012 12:19:31 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [trill] draft-ietf-trill-clear-correct 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, 02 May 2012 16:19:53 -0000 HI, The plan is for Erik Nordmark to be document shepherd of this draft. In reviewing the email, Erik has concluded that Section 3.4 should state that it is essential that all RBridges in a campus do the calculation in the same way as it affects the RPFC check. Also, as an editorial change, it would be useful to add a list of the changes made to RFC 6325 by this draft. In addition, the last sentence of Section 4 is not complete. While it is not possible to send a specifically addressed unicast Channel message to an RBridge that does not have a nickname, such and RBridge can receive a unicast Channel message from a neighbor sent to the Any-RBridge nickname and can receive multi-destination Channel messages under some circumstances. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From nordmark@acm.org Wed May 2 10:11: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 DE6F411E8096 for ; Wed, 2 May 2012 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H7lJTDdOkN9 for ; Wed, 2 May 2012 10:11:32 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 482F211E8086 for ; Wed, 2 May 2012 10:11:32 -0700 (PDT) Received: from [171.70.217.4] (dhcp-171-70-217-4.cisco.com [171.70.217.4]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q42HBSS0032480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 10:11:28 -0700 Message-ID: <4FA16ABD.3030301@acm.org> Date: Wed, 02 May 2012 10:11:25 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 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] draft-ietf-trill-clear-correct 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, 02 May 2012 17:11:33 -0000 On 5/2/12 9:19 AM, Donald Eastlake wrote: > HI, > > The plan is for Erik Nordmark to be document shepherd of this draft. > > In reviewing the email, Erik has concluded that Section 3.4 should > state that it is essential that all RBridges in a campus do the > calculation in the same way as it affects the RPFC check. Also, as an > editorial change, it would be useful to add a list of the changes made > to RFC 6325 by this draft. To clarify and expand on this a but, there were some emails on the list saying that the changes in section 3.4 are good, but that all the RBridges have to use the same calculation or the RPF check will drop packets that shouldn't be dropped. Assuming that is correct, then it would make sense to specify in section 3.4 that this change causes an incompatibility with 6325 (and explain the issue a bit) but that it makes sense to fix this (there were reasons posted on the list). I think it would also be good to have an additional section titled "Incompatible changes" which just contains a sentence which refers to section 3.4. Erik > In addition, the last sentence of Section 4 is not complete. While it > is not possible to send a specifically addressed unicast Channel > message to an RBridge that does not have a nickname, such and RBridge > can receive a unicast Channel message from a neighbor sent to the > Any-RBridge nickname and can receive multi-destination Channel > messages under some circumstances. > > 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 tsenevir@cisco.com Fri May 4 15:38:31 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 948D321E8015 for ; Fri, 4 May 2012 15:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.878 X-Spam-Level: X-Spam-Status: No, score=-6.878 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uny8qjr-vF+a for ; Fri, 4 May 2012 15:38:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C64DF21F84F0 for ; Fri, 4 May 2012 15:38:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q44MbcW1023302 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 4 May 2012 15:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=3134; q=dns/txt; s=iport; t=1336171067; x=1337380667; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=uH9xT+1RPi2QHb8iL1GeSR7bKCz/CIXu6kLYPeBPNVw=; b=ZnWM9e2o7sHYgNkp1BzqstN6B6qzYb8vMYNM4TmXo9PO6mJrNXLI5TqB XML5e8fG3+fZkqgZBVAN5OsQhxL/a+ebZvlEJyHE56Co6jtI/P7A0KRUA S2lUzu1Xm8ExofBM2Tt9OPOOHjqEylgxhgKxWphCsd+0vI62D3iI3c3N2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAONZpE+rRDoJ/2dsb2JhbABCAw6yXYEHggkBAQEEAQEBDwEdPgsMBAIBCBEEAQEBCgYXAQYBIAYfCQgBAQQTCBqHXQMKAQubEJYpDYlTiguDWIJHYwSIMDSOK4ougxqBaYIvWQ X-IronPort-AV: E=Sophos;i="4.75,533,1330905600"; d="scan'208";a="43483905" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 04 May 2012 22:37:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q44Mbbbi000890; Fri, 4 May 2012 22:37:37 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 15:37:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 May 2012 15:37:35 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A501142B7C@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] [rbridge] TRILL Multi-topology encoding draft Thread-Index: Ac0oftk/FN9JXKGySSS8S6J/2c5f3ABxu02A References: <344037D7CFEFE84E97E9CC1F56C5F4A5D10826@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5010A3734@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Anoop Ghanwani" X-OriginalArrivalTime: 04 May 2012 22:37:37.0296 (UTC) FILETIME=[81897900:01CD2A46] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: Donald Eastlake , rbridge@postel.org Subject: Re: [trill] [rbridge] TRILL Multi-topology encoding 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: Fri, 04 May 2012 22:38:31 -0000 This encoding happens hop-by-hop. Which means when interfacing with = RBridges that are not capable of understanding the proposed encoding = methods, RBridges may not use the proposed encoding on those interfaces, = thus maintaining the backward compatibility. This is possible because = TRILL header remain unchanged and encoding happens as part of the outer = header.=20 -----Original Message----- From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop = Ghanwani Sent: Wednesday, May 02, 2012 9:16 AM To: Tissa Senevirathne (tsenevir) Cc: Donald Eastlake; rbridge@postel.org Subject: Re: [trill] [rbridge] TRILL Multi-topology encoding draft When using the outer-VLAN, while the frame format itself would be = backwards compatible, I don't believe existing silicon would actually be = able to make use of it. So it depends on what we mean by "backwards compatibility"? Do we need the data plane to be backwards compatible? If so, neither encoding mechanism works. Or do we need just the frame format to be backwards compatible? Then using the outer VLAN works. Anoop On Tue, May 1, 2012 at 4:00 PM, Tissa Senevirathne (tsenevir) = wrote: > Hi Donald > > In the ID we have specified a backward compatibility mode where one = can use NH-VLAN to encode the multi topology ID on pt-pt links. > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, May 01, 2012 12:52 PM > To: Tissa Senevirathne (tsenevir) > Cc: rbridge@postel.org > Subject: Re: [rbridge] TRILL Multi-topology encoding draft > > While this certainly encodes topology into frames, it is not clear to = me that the technique using a new tag is generally supported by existing = TRILL 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 > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > > On Mon, Mar 26, 2012 at 12:54 PM, Tissa Senevirathne (tsenevir) = wrote: >> Dear All >> >> >> We have posted draft-tissa-trill-mt-encode-00. This draft discuss=20 >> methods that can be used to encode multi topology id without=20 >> exhausting nickname space or adding additional control plane=20 >> extensions to abbreviate absolute topology. Please let us know your = comments. >> >> >> >> Abstract: >> >> >> >> =A0=A0 Two alternative methods of encoding Multi Topology Identifier=20 >> within >> >> =A0=A0 the TRILL data frames are presented. Methods proposed herein = do=20 >> not >> >> =A0=A0 require overloading TRILL RBridge nickname to encode Multi=20 >> Topology >> >> =A0=A0 Identifier. >> >> >> >> Thanks >> >> Tissa >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Fri May 4 17:38:56 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 E20E721F8473 for ; Fri, 4 May 2012 17:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.713 X-Spam-Level: X-Spam-Status: No, score=-103.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQk29H+T9k65 for ; Fri, 4 May 2012 17:38:56 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED52121F8471 for ; Fri, 4 May 2012 17:38:54 -0700 (PDT) Received: by yhq56 with SMTP id 56so3965849yhq.31 for ; Fri, 04 May 2012 17:38:54 -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:content-transfer-encoding; bh=YZfQuIU8d7u6al9N1pEbYk/K+h0cKvXUgkVFrCbJd1c=; b=ieoZIJMYuUcoBnP3n7hipvyzObF5boT/0SN74aDNfsklOaYclSnVUaM+yL4rK4kGXt DmUgVki70hwq7OCF00i7k0X6MctYzmZdmsTJFQbvXoVp97IW/B+Cw2HMnRpbqR5S+8ww WpLBQ5S/Nd0sHsxKNKj7Ppc5nC615DQG552rqmU2csx7yXda0QpsqNr2qtnWAJ9y4z42 3gjrFNTGqOIlB8z69SpZQO5BJZP01tRa5df3qTOQXIdl4wFfUjIuUfZZB2KmJf8rfYo6 LbMHeEJwkiuI7apzcB69bqD0c93x8qWon+vbiL+PcNiu55hmF3UrZRzp3pInf+iCYZjO LBiw== Received: by 10.50.159.164 with SMTP id xd4mr4231806igb.13.1336177903450; Fri, 04 May 2012 17:31:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Fri, 4 May 2012 17:31:23 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Fri, 4 May 2012 20:31:23 -0400 Message-ID: To: Muhammad Mohsin Sardar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trill@ietf.org Subject: Re: [trill] Tree calculation 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, 05 May 2012 00:38:57 -0000 Hi Muhammad, On Sun, Apr 22, 2012 at 2:49 PM, Muhammad Mohsin Sardar wrote: > Hi, > > It is given in section 4.5 of RFC 6325: > > "it is important for all RBridges to know: > > o how many trees to compute > > o which trees to compute > o what the tree number for each tree is > o which trees each ingress RBridge might choose (for building > Reverse Path Forwarding Check filters)" > > > Can anyone explain, how an RBridge calculate this information? The idea is that the rest of Section 4.5 of RFC 6325, including the sub-sections, explains how these things are calculated. Note that https://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/ changes tree construction a bit in its section 3.4. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Thank you! > > -- > Best Regards, > Muhammad Mohsin Sardar > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From internet-drafts@ietf.org Tue May 8 09:22: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 6A58821F85BE; Tue, 8 May 2012 09:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd8jFf+F1f-H; Tue, 8 May 2012 09:22:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38E921F84D3; Tue, 8 May 2012 09:22:31 -0700 (PDT) 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.02 Message-ID: <20120508162231.24236.18774.idtracker@ietfa.amsl.com> Date: Tue, 08 May 2012 09:22:31 -0700 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-clear-correct-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, 08 May 2012 16:22:32 -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 o= f Links Working Group of the IETF. Title : TRILL: Clarifications, Corrections, and Updates Author(s) : Donald Eastlake Mingui Zhang Anoop Ghanwani Ayan Banerjee Vishwas Manral Filename : draft-ietf-trill-clear-correct-03.txt Pages : 29 Date : 2012-05-08 The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327 and RFC 6439 provide clarifications and updates with respect to Adjacency and Appointed Forwarders. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/ From d3e3e3@gmail.com Tue May 8 09:33: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 6938E21F8499 for ; Tue, 8 May 2012 09:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.708 X-Spam-Level: X-Spam-Status: No, score=-103.708 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbTVkn5LcrV3 for ; Tue, 8 May 2012 09:33:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B481E21F847C for ; Tue, 8 May 2012 09:33:54 -0700 (PDT) Received: by yenq13 with SMTP id q13so2083671yen.31 for ; Tue, 08 May 2012 09:33:49 -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 :content-type:content-transfer-encoding; bh=9wcpgy2frmBgH1dHm93Oep/QYiBCYtmNg23PxnOm8No=; b=clsSgtrQJPb9nZv6HgmgcU4Yb2ZRQCShPEJt8CgLEMHDrAE0G/c9+uEO4pZaGKWzxp GkTJ01jjO3PB/X8xV4L2KIAfhj4qFnbvKTS1nssJLvVZBO1Zlq7b5WOUCR7ie4Qvncgw asIFxCLy1LQJkK58fM/+AZ8cRiv53QMeg2OOF/iII7to8PpZiE6If2gA7BkCgXeJP3OX JGii2y0HwFVJxKkpACCMMk3edDSYtyba2g3qr1+gatM9sctJJ8HZtXAabgq6uZ78aMLQ Hhr5mUKLICQ4iF3trEbNd6cRRcbO/7LNR1P6QNtQ4K+DSQxUpQF4XKOfGE5cCceWxggE 1atQ== Received: by 10.50.51.163 with SMTP id l3mr11008754igo.3.1336494829377; Tue, 08 May 2012 09:33:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Tue, 8 May 2012 09:33:29 -0700 (PDT) In-Reply-To: <20120508162231.24236.18774.idtracker@ietfa.amsl.com> References: <20120508162231.24236.18774.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 8 May 2012 12:33:29 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [trill] I-D Action: draft-ietf-trill-clear-correct-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, 08 May 2012 16:33:55 -0000 Hi, This version has the changes discussed here http://www.ietf.org/mail-archive/web/trill/current/msg05081.html 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, May 8, 2012 at 12:22 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Transparent Interconnection of Lots= of Links Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TRILL: Clarifications, Correct= ions, and Updates > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Donald Eastlake > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mingui Zhang > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anoop Ghanwani > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ayan Banerjee > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vishwas Manral > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-clear-correct-0= 3.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 29 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-08 > > =A0 The IETF TRILL (TRansparent Interconnection of Lots of Links) > =A0 protocol provides least cost pair-wise data forwarding without > =A0 configuration in multi-hop networks with arbitrary topology, safe > =A0 forwarding even during periods of temporary loops, and support for > =A0 multipathing of both unicast and multicast traffic. TRILL > =A0 accomplishes this by using IS-IS (Intermediate System to Intermediate > =A0 System) link state routing and by encapsulating traffic using a > =A0 header that includes a hop count. Since the TRILL base protocol was > =A0 approved in March 2010, active development of TRILL has revealed a > =A0 few errata in the original RFC 6325 and some cases that could use > =A0 clarifications or updates. > > =A0 RFC 6327 and RFC 6439 provide clarifications and updates with respect > =A0 to Adjacency and Appointed Forwarders. This document provide other > =A0 known clarifications, corrections, and updates to RFC 6325, RFC 6327, > =A0 and RFC 6439. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-03.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/ From mahesh.akula36@gmail.com Tue May 8 10:24: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 A0F6E21F8496 for ; Tue, 8 May 2012 10:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoUHw5c+fdwn for ; Tue, 8 May 2012 10:24:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F25B021F8495 for ; Tue, 8 May 2012 10:24:29 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q48HNWnt015303 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 May 2012 10:23:42 -0700 (PDT) Received: by lbbgh12 with SMTP id gh12so7433872lbb.39 for ; Tue, 08 May 2012 10:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4QTsV6dJnaH5D/H3Mw4WVU0scZQX6uSuxx1ejzuT9Js=; b=LINGeVvRqZMwXIunYc8M7JmY3ksp4lf4mR4ElYY9OuzN2HMaGELzcn+vHrKHTVZHL5 Vk7xhTtvm9Kt7xG1glMq4nDW/RO1fh3lZsK4rdxjZIDVHFRWMjO3CViEhRkuoG7eHdmi 1+VASSpStCB2XZ2H6taZ9oxDuQXaUHmgSpigBxCKNB77S5uOYkVeloafMYGAwqaN23IS 5lKXJHQHOq6XstHio/hizhKmDo7N1oDNbOfpk/arwHYYq6tAsqL8tVxmlPCi3lwZmXBq cUQYggl1fVESRuI3bPX2tKcbAoBhCgpFeChNrtfu9AKTrunzINwBW8RSLt5xHOoEboNt jnwQ== MIME-Version: 1.0 Received: by 10.112.26.197 with SMTP id n5mr7479199lbg.58.1336497811296; Tue, 08 May 2012 10:23:31 -0700 (PDT) Received: by 10.152.21.230 with HTTP; Tue, 8 May 2012 10:23:31 -0700 (PDT) Date: Tue, 8 May 2012 10:23:31 -0700 Message-ID: From: Mahesh Akula To: Donald Eastlake Content-Type: multipart/alternative; boundary=bcaec555571849107804bf89a58d X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mahesh.akula36@gmail.com Cc: rbridge@postel.org Subject: [trill] Nickname Selection 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, 08 May 2012 17:24:33 -0000 --bcaec555571849107804bf89a58d Content-Type: text/plain; charset=ISO-8859-1 Hi Donald, In RFC 6325 3.7.3, i'm troubling understanding below statement, can you please help clarify? First it says, node with higher IS-IS ID keeps the nickname, then it says, *if there is a tie in priority* then node with higher IS-IS system ID keeps the nickname. It gives meaning that IS-IS ID and nickname priority are same?? Each RBridge is responsible for ensuring that its nickname or each of its nicknames is unique. If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, *then the RBridge or pseudonode with the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if there is a tie in priority,* the RBridge with the numerically higher IS-IS System ID keeps the nickname, and the other RBridge MUST select a new nickname. This can require an RBridge with a configured nickname to select a replacement nickname. Regards, Mahesh --bcaec555571849107804bf89a58d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Donald,

In RFC 6325 3.7.3, i'm troubling understa= nding below statement, can you please help clarify?

First it says, node with higher IS-IS ID keeps the nickname, then it says= , if there is a tie in priority then node with higher IS-IS system I= D keeps the nickname. =A0It gives meaning that IS-IS ID and nickname priori= ty are same?? 

Each RBridge is responsible for ensuring that its =
nickname or each
      of its nicknames is unique.  If RB1 chooses nickname x, and RB1
      discovers, through receipt of an LSP for RB2 at any later time,
      that RB2 has also chosen x, then the RBridge or pseudonode with
      the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if
      there is a tie in priority, the RBridge with the numerically
      higher IS-IS System ID keeps the nickname, and the other RBridge
      MUST select a new nickname.  This can require an RBridge with a
      configured nickname to select a replacement nickname.

<=
/pre>
Regards,
Mahesh

--bcaec555571849107804bf89a58d-- From glen@amsl.com Tue May 8 17:43: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 5DC859E8013 for ; Tue, 8 May 2012 17:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdRq8mZznj-N for ; Tue, 8 May 2012 17:43:30 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 125739E8012 for ; Tue, 8 May 2012 17:43:27 -0700 (PDT) Received: by c8a.amsl.com (Postfix, from userid 1000) id 50D8712C87D; Tue, 8 May 2012 17:43:23 -0700 (PDT) Date: Tue, 8 May 2012 17:43:23 -0700 From: Glen To: trill@ietf.org Message-ID: <20120509004323.GA21934@amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [trill] Test, please ingore 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, 09 May 2012 00:43:30 -0000 Trill List - My apologies for this test. I'm debugging a bounce report sent in by Donald Eastlake. I should have this resolved momentarily. Thank you. Glen Glen Barney IT Director AMS (IETF Secretariat) From glen@amsl.com Tue May 8 17:56: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 256949E801A for ; Tue, 8 May 2012 17:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T6OKkAVnf73 for ; Tue, 8 May 2012 17:56:31 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 8D10E9E8019 for ; Tue, 8 May 2012 17:56:31 -0700 (PDT) Received: by c8a.amsl.com (Postfix, from userid 1000) id B99CC12C87D; Tue, 8 May 2012 17:56:32 -0700 (PDT) Date: Tue, 8 May 2012 17:56:32 -0700 From: Glen To: trill@ietf.org Message-ID: <20120509005632.GA23778@amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [trill] Trill List Outage 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, 09 May 2012 00:56:32 -0000 Dear Trill List - As some of you may already know, your list has been out of service for about the last six hours or so. Messages sent to the list would have resulted in a delivery failure message back to the sender. Donald Eastlake reported this to us several hours ago, and the problem is now fixed. It appears that, when we created a new mailing list earlier this morning, mailman failed to rebuild one of the mail database files (the "virtual table" file used by Postfix) necessary for proper list mail transport. It turns out that the server permissions on that file were wrong, although I do not know why that would have happened, and so mailman could not recreate the file. Of course, mailman did not give me an error message of any kind (I created the list myself) so I wasn't aware of that failure, but because of it, a pre-March version of the database was used instead, resulting in the breakage of your list, and several lists created for IETF 84. I've fixed the permissions, so this "should" not happen again, and I'm copying the entire AMS IETF Team on this email so that they are all aware of this. If there is some larger problem with mailman, however, we may have more work to do. We'll keep an eye on it over the next several list creates, to help ensure this does not happen again. I'm sorry for the inconvenience. Please feel free to contact us at ietf-action if any of you encounter any further problems. Glen Glen Barney IT Director AMS (IETF Secretariat) From glen@amsl.com Wed May 9 15:01: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 D1E6311E80CF for ; Wed, 9 May 2012 15:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqSbiX1j52GO for ; Wed, 9 May 2012 15:01:17 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 884F111E8086 for ; Wed, 9 May 2012 15:01:17 -0700 (PDT) Received: by c8a.amsl.com (Postfix, from userid 1000) id 3D42212C89B; Wed, 9 May 2012 15:01:16 -0700 (PDT) Date: Wed, 9 May 2012 15:01:16 -0700 From: Glen To: trill@ietf.org Message-ID: <20120509220116.GA26917@amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [trill] Test, please ignore 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, 09 May 2012 22:01:18 -0000 Sorry - Having just created another list for the IETF, I'm just making sure things didn't break. Please ignore this test. Glen Glen Barney IT Director AMS (IETF Secretariat) From nordmark@acm.org Fri May 11 09:14: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 9B1EB21F8688 for ; Fri, 11 May 2012 09:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqyIZJJXLs6w for ; Fri, 11 May 2012 09:14:02 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id A220A21F8513 for ; Fri, 11 May 2012 09:14:02 -0700 (PDT) Received: from [10.33.22.63] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q4BGDxQW020750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 09:13:59 -0700 Message-ID: <4FAD3AC7.4030500@acm.org> Date: Fri, 11 May 2012 09:13:59 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "trill@ietf.org" References: <4F9AB82A.5060901@acm.org> In-Reply-To: <4F9AB82A.5060901@acm.org> X-Forwarded-Message-Id: <4F9AB82A.5060901@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Fwd: Publication requested: draft-ietf-trill-rbridge-bfd-05.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, 11 May 2012 16:14:03 -0000 This should probably have gone to the list - I'll make sure subsequent ones do. Erik -------- Original Message -------- Subject: Publication requested: draft-ietf-trill-rbridge-bfd-05.txt Date: Fri, 27 Apr 2012 08:15:54 -0700 From: Erik Nordmark To: iesg-secretary@ietf.org, Ralph Droms CC: Trill Chairs TRILL: Bidirectional Forwarding Detection (BFD) Support (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard as indicated in the title page header. This document specifies the standard method of encapsulating the BFD protocol when used in conjunction with TRILL. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in RBridge campuses based on the RBridge Channel extension to the the TRILL protocol. BFD is a simple, widely deployed OAM mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. Working Group Summary There was a clear consensus in favor of the document with the consensus determination made in late February. There was then some delay due to fixing various editorial problems and nits, many of which were discussed on the mailing list during the WG Last Call, but these have now been fixed. Document Quality BFD and TRILL are both widely implemented although there have been no announced implementations of the BFD encapsulation for TRILL in this document. During the review period, the addition of some material to the Security Considerations section was suggested and adopted. See http://www.postel.org/pipermail/rbridge/2012-February/004768.html http://www.postel.org/pipermail/rbridge/2012-February/004819.html Personnel Who is the Document Shepherd? Erik Nordmark Who is the Responsible Area Director? Ralph Droms (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Careful review of the whole document, including looking at its dependencies on rbridge-channel and rbridge-extension. There are references to section 10 and section 4, which I think should both be references to section 7. I've told the authors that this nit can be deferred until the AD review has been done. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. See also item 5 below. (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? If so, describe the review that took place. Review related to the BFD aspects was identified. Notice of this document's working group last call was posted to the BFD WG mailing list and one of the co-authors of this draft is co-chair of the BFD WG and particularly knowledgeable in BFD. (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? None. (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. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures on this document. There is existing and disclosed IPR on the BFD base protocol. (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? The consensus is reasonably broad. (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 is an ID-NITS error flags for a Normative Reference to RFC20 (defining ASCII). ** Downref: Normative reference to an Unknown state RFC: RFC 20 That is the only RFC that defines ASCII. If desirable we can change it to a reference to: USA Standard Code for Information Interchange, USAS X3.4-1967, United States of America Standards Institute, July 7, 1967 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria apply. (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? If such normative references exist, what is the plan for their completion? There is a normative reference to RFC 20 whose status, as a legacy, RFC is unknown, as noted above. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. See item 14 above. (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. The IANA Considerations section correctly lists the two code points required to be allocated. These are in a sub-registry of the TRILL Parameters registry. That sub-registry is created by draft-ietf-trill-rbridge-channel, a draft being advanced at the same time as this document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries or sub-registries are created by this draft. (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. No part of this draft is in a formal language. --- From nordmark@acm.org Fri May 11 09:30: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 9226221F8638 for ; Fri, 11 May 2012 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFpln1GQ0DSi for ; Fri, 11 May 2012 09:30:04 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id AC82C21F8606 for ; Fri, 11 May 2012 09:30:04 -0700 (PDT) Received: from [10.33.22.63] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q4BGU2ae007295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 09:30:02 -0700 Message-ID: <4FAD3E8A.3010206@acm.org> Date: Fri, 11 May 2012 09:30:02 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "trill@ietf.org" References: <4F9A2DDA.1070009@acm.org> In-Reply-To: <4F9A2DDA.1070009@acm.org> X-Forwarded-Message-Id: <4F9A2DDA.1070009@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Fwd: Nits on draft-ietf-trill-rbridge-channel 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, 11 May 2012 16:30:05 -0000 FYI: I had sent these nits to the authors a while back. I think it makes sense to revise the draft to take care of the nits below, and then send it to the IESG. The "verbatim reproduction of the Inner Ethernet Header" should probably be left alone at this point in time. Regards, Erik -------- Original Message -------- Subject: Nits on draft-ietf-trill-rbridge-channel Date: Thu, 26 Apr 2012 22:25:46 -0700 From: Erik Nordmark To: draft-ietf-trill-rbridge-channel@tools.ietf.org Shouldn't this say something slightly different than MUST be zero? CHV: A 4-bit field that gives the RBridge Channel Header Version and MUST be zero. Something like "This document specifies version zero." The verbatim reproduction of the Inner Ethernet Header in section 2.1 means that this document would need to be revised as a result of things like fine grained labels. Wouldn't it make sense to instead do this by reference to RFC6325 instead of reproducing the exact header? That gives us the flexibility to have documents which update RFC6325 without touching this document. Section 2.2 tries to rename the Op-len field in the base protocol to be Ext-len. I think I commented on this being confusing and not worth-while for the extensions draft, thus I think the channel draft can use the same wording as the extensions draft (which does not attempt to rename the field.) Section 6.2 says The IEEE Registration Authority has been assigned the Ethertype for RBridge-Channel. "has been assigned" should probably be "has assigned". Do we already have an allocated number to replace the TBD? Typo: "particuclar" Erik From nordmark@acm.org Fri May 11 10:27: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 47B8E21F86C1 for ; Fri, 11 May 2012 10:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R53Spg+q-mnr for ; Fri, 11 May 2012 10:27:11 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8D721F86BD for ; Fri, 11 May 2012 10:27:11 -0700 (PDT) Received: from [10.33.22.63] (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 q4BHR8kt002947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 10:27:09 -0700 Message-ID: <4FAD4BEC.6080707@acm.org> Date: Fri, 11 May 2012 10:27:08 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "trill@ietf.org" References: <4FAD4BCC.4090709@acm.org> In-Reply-To: <4FAD4BCC.4090709@acm.org> X-Forwarded-Message-Id: <4FAD4BCC.4090709@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Fwd: Publication requested: draft-ietf-trill-rbridge-extension-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: Fri, 11 May 2012 17:27:12 -0000 -------- Original Message -------- Subject: Publication requested: draft-ietf-trill-rbridge-extension-04 Date: Fri, 11 May 2012 10:26:36 -0700 From: Erik Nordmark To: iesg-secretary@ietf.org, Ralph Droms CC: Trill Chairs TRILL: Header Extension draft-ietf-trill-rbridge-extension-04 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard as indicated in the title page header. This document specifies some additional flags for the extension part of the TRILL header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The IETF TRILL (Transparent Interconnection of Lots of Links) base protocol specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies two of those bits, plus the Critical Channel Alert Flag used by the channel draft. Working Group Summary There was rough consensus in the working group in favor of the document, with one relatively strong dissenter. The main point of the dissenter was that the material in this draft is not needed to provide an RBridge channel that can be used for BFD and error reporting, hence the extensions are speculative on future standardization that would make use of them. The WG neverless wants to proceed with this document. Document Quality The document has been carefully reviewed in the WG and by the document shepherd. There are no known implementations of the additional Critical Channel Alert Flag specified in this document. Personnel Who is the Document Shepherd? Erik Nordmark Who is the Responsible Area Director? Ralph Droms (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Careful review of the whole document, including looking at its dependencies to and from rbridge-channel and rbridge-bfd. (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? If so, describe the review that took place. No. (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? None. (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. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures on this document. (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? The consensus is reasonably broad. (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. No issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria apply. (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? If such normative references exist, what is the plan for their completion? No, (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (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. The IANA Considerations section refers to section 3 in the body of the document for the initial content of the new subregistry, and section 3 is consistent with the description in section 2. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. A new subregistry is created by this document called "TRILL Extended Header Flags", but allocations are subject to Standards Action and not Expert Review. Hence no experts are needed. (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. No part of this draft is in a formal language. From nordmark@acm.org Fri May 11 17:38:04 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 94AAF21F85E7 for ; Fri, 11 May 2012 17:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOtFKYVbF6uG for ; Fri, 11 May 2012 17:38:04 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1C42321F85E6 for ; Fri, 11 May 2012 17:38:04 -0700 (PDT) Received: from [10.21.118.163] (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 q4C0c0IO029443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 17:38:01 -0700 Message-ID: <4FADB0E8.1090000@acm.org> Date: Fri, 11 May 2012 17:38:00 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "trill@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 12 May 2012 00:38:04 -0000 The document is at https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ We've discussed this document in WG meetings and on the list in the past. Please send comments to the list. Erik From tsenevir@cisco.com Mon May 14 05:35:31 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 1FF8D21F860B for ; Mon, 14 May 2012 05:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.863 X-Spam-Level: X-Spam-Status: No, score=-8.863 tagged_above=-999 required=5 tests=[AWL=1.736, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIs-tvy7KTwR for ; Mon, 14 May 2012 05:35:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6C56521F859A for ; Mon, 14 May 2012 05:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=1020; q=dns/txt; s=iport; t=1336998930; x=1338208530; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=d9SOxmtHckMPcRw8l6rDJNNsWJj26NHTkyjfElUGfyY=; b=G8wra081mNFGyhVylq38AjQD39RegL65YqwGyaEyxIPjvfijZiOdoD/y TmFtIK9BR6jd5quKEDFSuES+6vaiOlpzWQkYJX0i71zw2ZcmXkQHfD2/q j2e2rqtoeHw7wvbPjZCwugXLAOxK+5E5uRsdJbmTurjcStGfyDCXMDySb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMz7sE+rRDoG/2dsb2JhbABEs3OBB4IVAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBMHh2sBC5pIn2cEixqFJWMEiGSbcIFpgwk X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="44611039" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 14 May 2012 12:35:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4ECZA9Q021594; Mon, 14 May 2012 12:35:10 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 05:35:10 -0700 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: Mon, 14 May 2012 05:34:52 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4FADB0E8.1090000@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0v14OF2W91gDgpTRy9oRvF6ilJagB9fm5w References: <4FADB0E8.1090000@acm.org> From: "Tissa Senevirathne (tsenevir)" To: "Erik Nordmark" , X-OriginalArrivalTime: 14 May 2012 12:35:10.0168 (UTC) FILETIME=[004CF580:01CD31CE] Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 12:35:31 -0000 I do not think we should rush this document to WG status. We should look in a bigger picture i.e. what sorts of TRILL interconnects are needed and then proceed accordingly. We do not want too many solutions that implement subsets. It is a pain for vendors and confusion for customers. What we need is a single comprehensive solution that covers the problem spaces. My vote is "NO" to move this document to WG status. -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Friday, May 11, 2012 5:38 PM To: trill@ietf.org Subject: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? The document is at https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ We've discussed this document in WG meetings and on the list in the past. Please send comments to the list. Erik _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From carlsonj@workingcode.com Mon May 14 05:56: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 A8A2521F8452 for ; Mon, 14 May 2012 05:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt1pWpfp+txy for ; Mon, 14 May 2012 05:56:20 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2621F845D for ; Mon, 14 May 2012 05:56:19 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id q4ECuCjY011619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 08:56:13 -0400 (EDT) Message-ID: <4FB100EC.9090203@workingcode.com> Date: Mon, 14 May 2012 08:56:12 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: "Tissa Senevirathne (tsenevir)" References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: carlson; whitelist Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 12:56:20 -0000 Tissa Senevirathne (tsenevir) wrote: > I do not think we should rush this document to WG status. We should look > in a bigger picture i.e. what sorts of TRILL interconnects are needed > and then proceed accordingly. > > We do not want too many solutions that implement subsets. It is a pain > for vendors and confusion for customers. What we need is a single > comprehensive solution that covers the problem spaces. > > My vote is "NO" to move this document to WG status. That sounds a bit backwards to me. The document is clearly in scope of the working group, and I believe the only other question regarding adoption is whether the wg wants (and the authors want) to steer the document by the working group consensus process. Determining whether it's needed or the right technical solution is further down the road. If the wg determines that it's not right and can't fix it, then it can terminate the work that it steers. Adoption doesn't mean "we're committed to publishing this." I think leaving work that is in the scope of the working group outside the wg merely because some higher-level planning is contemplated is not a good idea, and not keeping with IETF tradition. It invites exactly the sort of "too many solutions" problems that the poster refers to, as the rejected authors seek out other venues -- including individual submission -- to pursue the work. -- James Carlson 42.703N 71.076W From tsenevir@cisco.com Mon May 14 06:15:42 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 0FBC821F86BE for ; Mon, 14 May 2012 06:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.95 X-Spam-Level: X-Spam-Status: No, score=-8.95 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ylBU5DXZKex for ; Mon, 14 May 2012 06:15:41 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 62D1E21F86BA for ; Mon, 14 May 2012 06:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=2639; q=dns/txt; s=iport; t=1337001341; x=1338210941; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TL/L2+hmQa231FgbV57r0j5XiZz7FCS4TZXHMmehnjY=; b=NAD81RnVGgIxcnjtvNKSuDFmwg5qAd0tbgKo/pV35WkX5TB1JetW227b UyI1CkgXvEWlzlzQc7JKGTUPHCj2HZO6eShbk34J2fXqalj6JoSOTBJDl oXPk1duM0XjiAAJppcfHO3eoq5wcj8iWg/LoIrFYCMgz03gPiwgntIbKu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE4EsU+rRDoJ/2dsb2JhbABEs3OBB4IVAQEBAwESAR0KPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgTB4dnBAELmkqfaQSLGoUlYwSIZJtwgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208";a="41592896" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 14 May 2012 13:15:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4EDFe4b003196; Mon, 14 May 2012 13:15:40 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 06:15:40 -0700 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: Mon, 14 May 2012 06:15:37 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4FB100EC.9090203@workingcode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0x0PieleNiDd5ZStKKsS1u3Zj9UgAAC5LA References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> From: "Tissa Senevirathne (tsenevir)" To: "James Carlson" X-OriginalArrivalTime: 14 May 2012 13:15:40.0669 (UTC) FILETIME=[A8FDFAD0:01CD31D3] Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 13:15:42 -0000 Hi James=20 I am not clear with your point though, you indicated lead to "too many solutions", which is exactly the issue.=20 please see my comments in-line -----Original Message----- From: James Carlson [mailto:carlsonj@workingcode.com]=20 Sent: Monday, May 14, 2012 5:56 AM To: Tissa Senevirathne (tsenevir) Cc: Erik Nordmark; trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Tissa Senevirathne (tsenevir) wrote: > I do not think we should rush this document to WG status. We should=20 > look in a bigger picture i.e. what sorts of TRILL interconnects are=20 > needed and then proceed accordingly. >=20 > We do not want too many solutions that implement subsets. It is a pain > for vendors and confusion for customers. What we need is a single=20 > comprehensive solution that covers the problem spaces. >=20 > My vote is "NO" to move this document to WG status. That sounds a bit backwards to me. [Answer] Doing small piecemeal work, is not the right approach.=20 =20 The document is clearly in scope of the working group, and I believe the only other question regarding adoption is whether the wg wants (and the authors want) to steer the document by the working group consensus process. [Answer] Good point, I re-read the charter one more time and there is no where it says TRILL over IP or other encapsulation, so it seems the document is not in charter. Please could you point to the WG, which line item in charter that qualifies this work to be in scope ? https://datatracker.ietf.org/wg/trill/charter/ Determining whether it's needed or the right technical solution is further down the road. If the wg determines that it's not right and can't fix it, then it can terminate the work that it steers. Adoption doesn't mean "we're committed to publishing this." I think leaving work that is in the scope of the working group outside the wg merely because some higher-level planning is contemplated is not a good idea, and not keeping with IETF tradition. It invites exactly the sort of "too many solutions" problems that the poster refers to, as the rejected authors seek out other venues -- including individual submission -- to pursue the work. [Answer] IETF tradition has been to start with a problem space and create a common solution not making every draft that is in scope of charter a WG document. Your point on "too many solutions" exactly that is my point having subset of solutions finally leads to too many small pieces. --=20 James Carlson 42.703N 71.076W From carlsonj@workingcode.com Mon May 14 07:29:50 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 DA92821F876A for ; Mon, 14 May 2012 07:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-XQbTfLVSxb for ; Mon, 14 May 2012 07:29:50 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDDE21F850C for ; Mon, 14 May 2012 07:29:50 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id q4EETehM011944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 10:29:40 -0400 (EDT) Message-ID: <4FB116D4.8060008@workingcode.com> Date: Mon, 14 May 2012 10:29:40 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: "Tissa Senevirathne (tsenevir)" References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: carlson; whitelist Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 14:29:51 -0000 Tissa Senevirathne (tsenevir) wrote: > That sounds a bit backwards to me. > > [Answer] Doing small piecemeal work, is not the right approach. We might agree on that point, but it's not the question at hand. The question at hand is whether to adopt a draft. > The document is clearly in scope of the working group, and I believe the > only other question regarding adoption is whether the wg wants (and the > authors want) to steer the document by the working group consensus > process. > > [Answer] Good point, I re-read the charter one more time and there is no > where it says TRILL over IP or other encapsulation, so it seems the > document is not in charter. Please could you point to the WG, which line > item in charter that qualifies this work to be in scope ? > > https://datatracker.ietf.org/wg/trill/charter/ Sure: "This includes a MIB module and other pieces needed for operations, but also additional ways to extend and optimize TRILL for the properties of the networks on which it is deployed." This seems to me to be an additional way to extend TRILL for the property of a network -- specifically, an IP network. Granted, I'm not thrilled about the idea of adding a new means to reach mutual encapsulation. I assume the authors have a good reason to do this, and have interesting ideas on how and why it should be done. The important point is that I think this working group is the best possible forum to air those ideas. > [Answer] IETF tradition has been to start with a problem space and > create a common solution not making every draft that is in scope of > charter a WG document. Your point on "too many solutions" exactly that > is my point having subset of solutions finally leads to too many small > pieces. Some efforts do indeed follow that simple linear path -- idea, BOF, charter, WG, publication. But that's certainly not the only path, nor perhaps even the most common. Adoption by an existing WG of new in-scope documents is something that I view as crucially important to continued WG viability. Without it, protocols just grow like weeds as new extensions are otherwise developed, deployed, and documented without the help of WG consensus using the individual-submission RFC publication track. Failing to adopt does not foreclose publication of an RFC describing this extension, nor any other work by the authors. It simply disconnects the WG from the process. Sending TRILL over IP off to the individual-submission world without WG input would, I think, be a poor result of this exercise. I've been through that problem as PPPEXT chair, and it's no fun. -- James Carlson 42.703N 71.076W From tsenevir@cisco.com Mon May 14 08:04: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 525F021F8805 for ; Mon, 14 May 2012 08:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.028 X-Spam-Level: X-Spam-Status: No, score=-9.028 tagged_above=-999 required=5 tests=[AWL=1.571, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M35l6ScfSYps for ; Mon, 14 May 2012 08:04:50 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1139321F8550 for ; Mon, 14 May 2012 08:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=4008; q=dns/txt; s=iport; t=1337007888; x=1338217488; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gU+eibrCOEhnBXdp7H9GcOhJdvdu/v4pmTAh9d06AQQ=; b=aHGczHwTXPRS/WPjNfEzpMDzk2pBgJD4pqo1hTHLCbVqWZ1ehsEvj4U3 w4JQd9LZXfWu7T2Cy/P/P+O1vCizWVtYlsF3lik3JP7s97IGjDOdjg5RD 0JMJcMloQk1VgEaJ/b/pyZZKCS3npiNmqEafG5ysdUlWffsqlIxfvJY3u E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMUesU+rRDoH/2dsb2JhbAA6CrNzgQeCFQEBAQMBEgEdCjQLBQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQTCBMHh2cEAQuaTZ9uBIsaD4UWYwSIZJtwgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208";a="42143592" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 14 May 2012 15:04:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4EF4bSB022386; Mon, 14 May 2012 15:04:37 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 08:04:37 -0700 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: Mon, 14 May 2012 08:04:31 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4FB116D4.8060008@workingcode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0x3gfIc3E1K3n3SHOh3W9J+s23nQAApxyw References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> <4FB116D4.8060008@workingcode.com> From: "Tissa Senevirathne (tsenevir)" To: "James Carlson" X-OriginalArrivalTime: 14 May 2012 15:04:37.0154 (UTC) FILETIME=[E10A7020:01CD31E2] Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 15:04:51 -0000 Hi James I think we are agreeing on lots points except one important point i.e. SHOULD or SHOULD NOT make individual submissions WG docs without a strategy. My main objection of making individual submissions WG docs without well thought through strategy is it takes away the focus and confuse WG, customers and burden vendors. Additionally, TRILL WG should focus on the priority items that was agreed in Taipei. Adding additional WG docs is not helping anyways. I am in the opinion that WG should identify priority Work areas, then form strategy around it, bring together different ideas to form well thought through solutions.=20 Secondly, it seems you are in the opinion that to get WG input the draft need to be WG document. I disagree with that. A draft does not need to be in WG status to get WG feedback. Authors should solicit feedback through the mailing list. Making a WG status is not going to change that.=20 -----Original Message----- From: James Carlson [mailto:carlsonj@workingcode.com]=20 Sent: Monday, May 14, 2012 7:30 AM To: Tissa Senevirathne (tsenevir) Cc: Erik Nordmark; trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Tissa Senevirathne (tsenevir) wrote: > That sounds a bit backwards to me. >=20 > [Answer] Doing small piecemeal work, is not the right approach.=20 We might agree on that point, but it's not the question at hand. The question at hand is whether to adopt a draft. > The document is clearly in scope of the working group, and I believe=20 > the only other question regarding adoption is whether the wg wants=20 > (and the authors want) to steer the document by the working group=20 > consensus process. >=20 > [Answer] Good point, I re-read the charter one more time and there is=20 > no where it says TRILL over IP or other encapsulation, so it seems the > document is not in charter. Please could you point to the WG, which=20 > line item in charter that qualifies this work to be in scope ? >=20 > https://datatracker.ietf.org/wg/trill/charter/ Sure: "This includes a MIB module and other pieces needed for operations, but also additional ways to extend and optimize TRILL for the properties of the networks on which it is deployed." This seems to me to be an additional way to extend TRILL for the property of a network -- specifically, an IP network. Granted, I'm not thrilled about the idea of adding a new means to reach mutual encapsulation. I assume the authors have a good reason to do this, and have interesting ideas on how and why it should be done. The important point is that I think this working group is the best possible forum to air those ideas. > [Answer] IETF tradition has been to start with a problem space and=20 > create a common solution not making every draft that is in scope of=20 > charter a WG document. Your point on "too many solutions" exactly that > is my point having subset of solutions finally leads to too many small > pieces. Some efforts do indeed follow that simple linear path -- idea, BOF, charter, WG, publication. But that's certainly not the only path, nor perhaps even the most common. Adoption by an existing WG of new in-scope documents is something that I view as crucially important to continued WG viability. Without it, protocols just grow like weeds as new extensions are otherwise developed, deployed, and documented without the help of WG consensus using the individual-submission RFC publication track. Failing to adopt does not foreclose publication of an RFC describing this extension, nor any other work by the authors. It simply disconnects the WG from the process. Sending TRILL over IP off to the individual-submission world without WG input would, I think, be a poor result of this exercise. I've been through that problem as PPPEXT chair, and it's no fun. --=20 James Carlson 42.703N 71.076W From touch@isi.edu Mon May 14 08:11: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 C2C7E21F87D7 for ; Mon, 14 May 2012 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS5cIHLvRidz for ; Mon, 14 May 2012 08:11:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 202CD21F8723 for ; Mon, 14 May 2012 08:11:38 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q4EFB6W4016648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 May 2012 08:11:16 -0700 (PDT) Message-ID: <4FB1208B.8070103@isi.edu> Date: Mon, 14 May 2012 08:11:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Tissa Senevirathne (tsenevir)" References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> <4FB116D4.8060008@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 15:11:38 -0000 Regarding this approach, I'm also wondering why TRILL-over-IP? Since TRILL is over ethernet, and ethernet is over IP, why is a specific solution for TRILL over IP even needed? Seems like a lot of potential complexity to save 18 bytes. Joe On 5/14/2012 8:04 AM, Tissa Senevirathne (tsenevir) wrote: > Hi James > > I think we are agreeing on lots points except one important point i.e. > SHOULD or SHOULD NOT make individual submissions WG docs without a > strategy. > > My main objection of making individual submissions WG docs without well > thought through strategy is it takes away the focus and confuse WG, > customers and burden vendors. Additionally, TRILL WG should focus on the > priority items that was agreed in Taipei. Adding additional WG docs is > not helping anyways. I am in the opinion that WG should identify > priority Work areas, then form strategy around it, bring together > different ideas to form well thought through solutions. > > Secondly, it seems you are in the opinion that to get WG input the draft > need to be WG document. I disagree with that. A draft does not need to > be in WG status to get WG feedback. Authors should solicit feedback > through the mailing list. Making a WG status is not going to change > that. > > > > -----Original Message----- > From: James Carlson [mailto:carlsonj@workingcode.com] > Sent: Monday, May 14, 2012 7:30 AM > To: Tissa Senevirathne (tsenevir) > Cc: Erik Nordmark; trill@ietf.org > Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG > document? > > Tissa Senevirathne (tsenevir) wrote: >> That sounds a bit backwards to me. >> >> [Answer] Doing small piecemeal work, is not the right approach. > > We might agree on that point, but it's not the question at hand. The > question at hand is whether to adopt a draft. > >> The document is clearly in scope of the working group, and I believe >> the only other question regarding adoption is whether the wg wants >> (and the authors want) to steer the document by the working group >> consensus process. >> >> [Answer] Good point, I re-read the charter one more time and there is >> no where it says TRILL over IP or other encapsulation, so it seems the > >> document is not in charter. Please could you point to the WG, which >> line item in charter that qualifies this work to be in scope ? >> >> https://datatracker.ietf.org/wg/trill/charter/ > > Sure: > > "This includes a MIB module and > other pieces needed for operations, but also additional ways to extend > and optimize TRILL for the properties of the networks on which it is > deployed." > > This seems to me to be an additional way to extend TRILL for the > property of a network -- specifically, an IP network. > > Granted, I'm not thrilled about the idea of adding a new means to reach > mutual encapsulation. I assume the authors have a good reason to do > this, and have interesting ideas on how and why it should be done. The > important point is that I think this working group is the best possible > forum to air those ideas. > >> [Answer] IETF tradition has been to start with a problem space and >> create a common solution not making every draft that is in scope of >> charter a WG document. Your point on "too many solutions" exactly that > >> is my point having subset of solutions finally leads to too many small > >> pieces. > > Some efforts do indeed follow that simple linear path -- idea, BOF, > charter, WG, publication. But that's certainly not the only path, nor > perhaps even the most common. Adoption by an existing WG of new > in-scope documents is something that I view as crucially important to > continued WG viability. Without it, protocols just grow like weeds as > new extensions are otherwise developed, deployed, and documented without > the help of WG consensus using the individual-submission RFC publication > track. > > Failing to adopt does not foreclose publication of an RFC describing > this extension, nor any other work by the authors. It simply > disconnects the WG from the process. > > Sending TRILL over IP off to the individual-submission world without WG > input would, I think, be a poor result of this exercise. I've been > through that problem as PPPEXT chair, and it's no fun. > From carlsonj@workingcode.com Mon May 14 09:17: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 5D80521F8532 for ; Mon, 14 May 2012 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOa2HAxxmwIW for ; Mon, 14 May 2012 09:17:51 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id B918D21F8627 for ; Mon, 14 May 2012 09:17:51 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id q4EGHjx9012277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 12:17:45 -0400 (EDT) Message-ID: <4FB13028.8060903@workingcode.com> Date: Mon, 14 May 2012 12:17:44 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: "Tissa Senevirathne (tsenevir)" References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> <4FB116D4.8060008@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: carlson; whitelist Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 16:17:52 -0000 Tissa Senevirathne (tsenevir) wrote: > I think we are agreeing on lots points except one important point i.e. > SHOULD or SHOULD NOT make individual submissions WG docs without a > strategy. I understand what you're saying, but I think that steering work that's directly related to the WG's future success sounds to me like part of a good strategy. > My main objection of making individual submissions WG docs without well > thought through strategy is it takes away the focus and confuse WG, > customers and burden vendors. Additionally, TRILL WG should focus on the > priority items that was agreed in Taipei. Adding additional WG docs is > not helping anyways. I am in the opinion that WG should identify > priority Work areas, then form strategy around it, bring together > different ideas to form well thought through solutions. I don't quite follow. Publishing an RFC as an independent submission to the IESG has exactly those effects. That's the bad outcome that occurs when a WG doesn't steer work that's intimately related to its charter. I don't understand how a "burden" develops on vendors or customers as a result of the discussion of ideas in the WG -- that's all that drafts represent; ideas. A burden certainly can develop as a result of _decisions_ that are made by a WG, but mere discussion shouldn't have that effect. If it does, then those vendors and customers have just way too much time on their collective hands, or perhaps they're confused about the process. > Secondly, it seems you are in the opinion that to get WG input the draft > need to be WG document. I disagree with that. A draft does not need to > be in WG status to get WG feedback. Authors should solicit feedback > through the mailing list. Making a WG status is not going to change > that. Oh, well. I tried. Much luck. -- James Carlson 42.703N 71.076W From tsenevir@cisco.com Mon May 14 09:51: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 5480E11E8080 for ; Mon, 14 May 2012 09:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.1 X-Spam-Level: X-Spam-Status: No, score=-9.1 tagged_above=-999 required=5 tests=[AWL=1.499, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucHaSa+pB28D for ; Mon, 14 May 2012 09:51:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 129BD21F883A for ; Mon, 14 May 2012 09:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=2741; q=dns/txt; s=iport; t=1337014268; x=1338223868; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XYfNUdmTjcS8ZkXQdZt7WfaAibh6IdZ5FXiKc0J+RoI=; b=Tm0XfM7r3rFOmlsU42aeplL4qQZM1eAJUdXzOnUKa1DUq8ojNG15PFXr VBY1p6FPpcmH4XwiRFdznYjK3iUEd5o6RieYFbMRfmDftY9orrIMB5tIn DjQ9hZe8FGVvH7Gw0zvsRPfEU6NGdy8a27rM+mALNm3+kd5fhuj8Nf2de 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKU2sU+rRDoH/2dsb2JhbAA6CrNygQeCFQEBAQMBEgEdCjQLBQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQTCBMHh2cEmn6fdosaD4UWYwSIZJtwgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208";a="42158541" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 14 May 2012 16:51:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4EGp7Tl004781; Mon, 14 May 2012 16:51:07 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 09:51:07 -0700 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: Mon, 14 May 2012 09:51:02 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5011CB005@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4FB13028.8060903@workingcode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0x7R0dBrKlFtSrSBWQ01EfNZ6w2wAA41qQ References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> <4FB116D4.8060008@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> <4FB13028.8060903@workingcode.com> From: "Tissa Senevirathne (tsenevir)" To: "James Carlson" X-OriginalArrivalTime: 14 May 2012 16:51:07.0344 (UTC) FILETIME=[C1E40D00:01CD31F1] Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 16:51:18 -0000 Please comments in-line -----Original Message----- From: James Carlson [mailto:carlsonj@workingcode.com]=20 Sent: Monday, May 14, 2012 9:18 AM To: Tissa Senevirathne (tsenevir) Cc: Erik Nordmark; trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Tissa Senevirathne (tsenevir) wrote: > I think we are agreeing on lots points except one important point i.e. > SHOULD or SHOULD NOT make individual submissions WG docs without a=20 > strategy. I understand what you're saying, but I think that steering work that's directly related to the WG's future success sounds to me like part of a good strategy. > My main objection of making individual submissions WG docs without=20 > well thought through strategy is it takes away the focus and confuse=20 > WG, customers and burden vendors. Additionally, TRILL WG should focus=20 > on the priority items that was agreed in Taipei. Adding additional WG=20 > docs is not helping anyways. I am in the opinion that WG should=20 > identify priority Work areas, then form strategy around it, bring=20 > together different ideas to form well thought through solutions. I don't quite follow. Publishing an RFC as an independent submission to the IESG has exactly those effects. That's the bad outcome that occurs when a WG doesn't steer work that's intimately related to its charter. I don't understand how a "burden" develops on vendors or customers as a result of the discussion of ideas in the WG -- that's all that drafts represent; ideas. A burden certainly can develop as a result of _decisions_ that are made by a WG, but mere discussion shouldn't have that effect. If it does, then those vendors and customers have just way too much time on their collective hands, or perhaps they're confused about the process. [Answer] Each WG status document is intended to be considered to be a future RFC. They are not mere numbers or academic papers. That is the reason why WG, Vendors and customers read them. Yes having too many of them and some with duplication or implementing part solution takes away the time available in hand. Again, my point is we do not need to make a document a WG status document for simple discussion purpose (which seems the point you are arguing) > Secondly, it seems you are in the opinion that to get WG input the=20 > draft need to be WG document. I disagree with that. A draft does not=20 > need to be in WG status to get WG feedback. Authors should solicit=20 > feedback through the mailing list. Making a WG status is not going to=20 > change that. Oh, well. I tried. Much luck. --=20 James Carlson 42.703N 71.076W From carlsonj@workingcode.com Mon May 14 10:03: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 3784B21F8839 for ; Mon, 14 May 2012 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH05lpaEc07X for ; Mon, 14 May 2012 10:03:51 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 795DB21F8838 for ; Mon, 14 May 2012 10:03:51 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id q4EH3k9p012444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 13:03:46 -0400 (EDT) Message-ID: <4FB13AF1.8080300@workingcode.com> Date: Mon, 14 May 2012 13:03:45 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: "Tissa Senevirathne (tsenevir)" References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> <4FB116D4.8060008@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> <4FB13028.8060903@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB005@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5011CB005@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: carlson; whitelist Cc: Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 17:03:52 -0000 Tissa Senevirathne (tsenevir) wrote: > [Answer] Each WG status document is intended to be considered to be a > future RFC. They are not mere numbers or academic papers. That is the > reason why WG, Vendors and customers read them. Yes having too many of > them and some with duplication or implementing part solution takes away > the time available in hand. Again, my point is we do not need to make a > document a WG status document for simple discussion purpose (which seems > the point you are arguing) We clearly disagree in fundamental ways on how the process works. I had thought that BCP 25 made it clear that I-Ds have no standards status whatsoever, and that advancement of wg documents (if it happens, not when) requires both group consensus and IESG review. WG adoption does not in any way confer RFC status upon a draft. And, yes, I do think the bar for entry into discussion should be quite low. A draft discussing a new HTML status code probably doesn't belong here. But something discussing TRILL extensions clearly does, even if it's something that the group hadn't collectively "planned" on discussing. Given the nature of the disagreement, and the fact that I'm repeating myself, I don't think extended discussion will be fruitful. Perhaps it'd be good to hear other viewpoints. -- James Carlson 42.703N 71.076W From touch@isi.edu Mon May 14 10:12: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 20BAD21F88D4 for ; Mon, 14 May 2012 10:12:09 -0700 (PDT) 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.799, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPGW95STLGd0 for ; Mon, 14 May 2012 10:12:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id AAD6A21F88D0 for ; Mon, 14 May 2012 10:12:07 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q4EHBO0c008697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 May 2012 10:11:34 -0700 (PDT) Message-ID: <4FB13CBD.6000206@isi.edu> Date: Mon, 14 May 2012 10:11:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: James Carlson References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF43@xmb-sjc-214.amer.cisco.com> <4FB116D4.8060008@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF89@xmb-sjc-214.amer.cisco.com> <4FB13028.8060903@workingcode.com> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB005@xmb-sjc-214.amer.cisco.com> <4FB13AF1.8080300@workingcode.com> In-Reply-To: <4FB13AF1.8080300@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Tissa Senevirathne \(tsenevir\)" , Erik Nordmark , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 17:12:09 -0000 On 5/14/2012 10:03 AM, James Carlson wrote: > Tissa Senevirathne (tsenevir) wrote: >> [Answer] Each WG status document is intended to be considered to be a >> future RFC. They are not mere numbers or academic papers. ... > We clearly disagree in fundamental ways on how the process works. I had > thought that BCP 25 made it clear that I-Ds have no standards status > whatsoever, and that advancement of wg documents (if it happens, not > when) requires both group consensus and IESG review. WG adoption does > not in any way confer RFC status upon a draft. This is discussed in Sec 5.3 of the Tao of the IETF. > And, yes, I do think the bar for entry into discussion should be quite > low. A draft discussing a new HTML status code probably doesn't belong > here. But something discussing TRILL extensions clearly does, even if > it's something that the group hadn't collectively "planned" on discussing. WG status does not have any impact on whether the draft is discussed. I agree with Tissa - IMO, the WG should adopt drafts it reasonably agrees it wants to issue as WG RFCs. WG adoption doesn't confer particular status, but it is a suggestion to the WG as to where critical resources should be spent (e.g., resolving WG docs before considering independent ones, when resources are critical). Joe From radiaperlman@gmail.com Mon May 14 10:36: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 1735911E808A for ; Mon, 14 May 2012 10:36:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GYs96T9cDSZ for ; Mon, 14 May 2012 10:36:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5ED11E8087 for ; Mon, 14 May 2012 10:36:47 -0700 (PDT) Received: by eaaq13 with SMTP id q13so452085eaa.31 for ; Mon, 14 May 2012 10:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CVcuvDtszXYhQq42rRoqOC/lDjlt5V1IWJp8q38wyXA=; b=IRYyMKfcuEU4e8GN5gd4vKuq2EuB9YOtIAq3HVJWS1RluxXv+8/zHaA6XgWkGwfU39 U8XlA46ZfSSluZL7SFVPtKp9z9L4fu7CZHmI0F8f1963XLJWIVSVzWcoAcShU0zyP3Ug H9XhJvCQnBHxF3c58GSyUkhTzEMaznMcL9aVHP1AtjJ9qVhpoilyE19dvN7NnEbLGyQa 6LJoLrYsRTL4wS6GS6u52M+Xarm1Aeg/NqxHnqxqRciRD6LgUzkUOJwf5kgoic9qToA1 D4760vln9X/FUG+TS1Kr3NYMskxv20z7ot+46fc2kuvoNdt8L9GN2tRz+nZ13zllIX8D 57Mg== MIME-Version: 1.0 Received: by 10.14.99.79 with SMTP id w55mr1683733eef.59.1337017006276; Mon, 14 May 2012 10:36:46 -0700 (PDT) Received: by 10.213.34.78 with HTTP; Mon, 14 May 2012 10:36:46 -0700 (PDT) In-Reply-To: <4FADB0E8.1090000@acm.org> References: <4FADB0E8.1090000@acm.org> Date: Mon, 14 May 2012 10:36:46 -0700 Message-ID: From: Radia Perlman To: Erik Nordmark Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 17:36:48 -0000 I don't understand the controversy. TRILL over IP is useful in several cases which are actually clearly explained in this document. And in general, the document seems well thought out and well written. So, I think it should be a WG document. Radia On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark wrote: > > The document is at > https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ > > We've discussed this document in WG meetings and on the list in the past. > > Please send comments to the list. > > =A0 Erik > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From tsenevir@cisco.com Mon May 14 12:06: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 7860C21F8763 for ; Mon, 14 May 2012 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.165 X-Spam-Level: X-Spam-Status: No, score=-9.165 tagged_above=-999 required=5 tests=[AWL=1.434, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u06HNxEWsAGb for ; Mon, 14 May 2012 12:06:18 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1031A21F88BD for ; Mon, 14 May 2012 12:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=2044; q=dns/txt; s=iport; t=1337022377; x=1338231977; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=q5qV/n00qtgcEXNAR8GXPWbQxM0lJ/OSYcio57gpsSU=; b=BLI0TEBuLI4FHzpebracamqymxRmx3mh5hKmqEDxXLK6YzeOcPgPHnym lKJMgbU1NNsScOLB9YCf7+n9DNWPcnfn3/Anezq5MSAOjkq957aZbHSKv e4H5/QFe/IQ41RvhPb8BvFjOAOvnW9HNl2Uc7ZxdlQ4CQergsn17LUY6T I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHVWsU+rRDoJ/2dsb2JhbABEs3SBB4IVAQEBBAEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggTB4drDJpkn24EixqFHWMEiDA0m3CBaYMJ X-IronPort-AV: E=Sophos;i="4.75,588,1330905600"; d="scan'208";a="42181155" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 May 2012 19:06:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4EJ6FQN025237; Mon, 14 May 2012 19:06:15 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 12:06:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 12:06:09 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0x+CouBBXNAN0uR6i8ek02Z35wrwABzP2A References: <4FADB0E8.1090000@acm.org> From: "Tissa Senevirathne (tsenevir)" To: "Radia Perlman" , "Erik Nordmark" X-OriginalArrivalTime: 14 May 2012 19:06:15.0388 (UTC) FILETIME=[A2A961C0:01CD3204] Cc: trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 19:06:19 -0000 Hi Radia If we are discussing about TRILL over foo then this draft is not = generic.=20 If we are discussing about TRILL over IP then I begin to wonder why = cannot we use existing pseudo-wire techniques. If we can use existing VPLS or L2VPN techniques to achieve required = functionality, why do we need yet another solution to save 2 MAC address = and a VLAN on outer Ethernet header.=20 If we are discussing about TRILL over foo then WG need to have consensus = on overall strategy before moving individual solutions to WG status. = People may argue we should have a lower bar to enter documents to WG = status, but side effect of that is we are over crowding the document = set, hence taking focus away from agreed priority items. Additionally, = one may even argue TRILL over any other transport protocol should be = part of L2VPN. Lastly, what is the rush to move this document to WG status ? -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf = Of Radia Perlman Sent: Monday, May 14, 2012 10:37 AM To: Erik Nordmark Cc: trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG = document? I don't understand the controversy. TRILL over IP is useful in several = cases which are actually clearly explained in this document. And in general, the document seems well thought out and well written. So, I think it should be a WG document. Radia On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark wrote: > > The document is at > https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ > > We've discussed this document in WG meetings and on the list in the = past. > > Please send comments to the list. > > =A0 Erik > _______________________________________________ > 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 Mon May 14 12:26: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 6577B21F887D for ; Mon, 14 May 2012 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qM0AaONACsC for ; Mon, 14 May 2012 12:26:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E121F8870 for ; Mon, 14 May 2012 12:26:50 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6722533pbc.31 for ; Mon, 14 May 2012 12:26:50 -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 :content-type:content-transfer-encoding; bh=4rT+aOS+ogNpn6kjnp1bLAehf918rVrn3d+cWPY4f2M=; b=miAPgg3XzE+sHxkDbvD2YLuKSHRnhDEZI62Oj3kHnrKVd+80BkW9idUXHEI/MmQwMh S+tTeJUPXHJLAkozOAzCwpuXET2e7raeAk5U9qroUK1YJXvA2tqFrWvjkOGITBWv4WjA IL3uy8qPcxL/5Yz32aRU9wXx1JKHgafF/4ChNk14yVrhnnmqMGA74kjClQPDDh/kGvAY bSzo6P54Wz5LyIwWkp/Q7tJII5eAJ43XGmCwNgOgys1FtMAMILEe7rpkaj8yk0QOyB29 LD8/yr7xYO7MoHPAaOhqBk/PEJSUGklXsFa0TeLlK40Fz3rXaH78kKdGaQw5sEStJKed MzwA== Received: by 10.50.51.226 with SMTP id n2mr3989501igo.3.1337023610440; Mon, 14 May 2012 12:26:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Mon, 14 May 2012 12:26:30 -0700 (PDT) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> From: Donald Eastlake Date: Mon, 14 May 2012 15:26:30 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 19:26:51 -0000 None of these arguments matter as our Area Director says that we need to re-Charter to make TRILL over IP a WG draft. However, I will respond a bit below: On Mon, May 14, 2012 at 3:06 PM, Tissa Senevirathne (tsenevir) wrote: > Hi Radia > > If we are discussing about TRILL over foo then this draft is not generic. > > If we are discussing about TRILL over IP then I begin to wonder why canno= t we use existing pseudo-wire techniques. You can but the result is inferior, adding more layers of fuzz between TRILL and actual transport protocol. > If we can use existing VPLS or L2VPN techniques to achieve required funct= ionality, why do we need yet another solution to save 2 MAC address and a V= LAN on outer Ethernet header. Maybe on a point-to-point link the main advantage is the savings you mention. But on a multi-point technology like IP there are lots of other factors in addition to saving a non-trivial number of bytes, factors related to multi-destination traffic, security, etc. The current L2VPN WG draft, to the extent it talks about interconnecting TRILL islands, isn't TRILL over anything but, although it connects the TRILL data planes, runs some new different more loosely coupled control protocol between the islands. > If we are discussing about TRILL over foo then WG need to have consensus = on overall strategy before moving individual solutions to WG status. People= may argue we should have a lower bar to enter documents to WG status, but = side effect of that is we are over crowding the document set, hence taking = focus away from agreed priority items. =A0Additionally, one may even argue = TRILL over any other transport protocol should be part of L2VPN. > > Lastly, what is the rush to move this document to WG status ? That's no different than asking why the obstructionism about a draft that has been presented and discussed and in which previously raised objections have been, as far as I can tell, resolved. Sitting on your hands is not a way to get standards done. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of= Radia Perlman > Sent: Monday, May 14, 2012 10:37 AM > To: Erik Nordmark > Cc: trill@ietf.org > Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG docum= ent? > > I don't understand the controversy. =A0TRILL over IP is useful in several= cases which are actually clearly explained in this document. > And in general, the document seems well thought out and well written. > > So, I think it should be a WG document. > > Radia > > On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark wrote: >> >> The document is at >> https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ >> >> We've discussed this document in WG meetings and on the list in the past= . >> >> Please send comments to the list. >> >> =A0 Erik >> _______________________________________________ >> 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 aldrin.ietf@gmail.com Mon May 14 13:29: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 09B6421F88BF for ; Mon, 14 May 2012 13:29:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09Wk+K8gErDO for ; Mon, 14 May 2012 13:29:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6496221F88AC for ; Mon, 14 May 2012 13:29:31 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6791537pbc.31 for ; Mon, 14 May 2012 13:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=vnfu+XfoCHP30AWTav9cvjXH91U3Dfq7eKjjYqeN43c=; b=P24V8ZEnr/AIvQCwn4bFx4iAblKyMFiTPp0QpRFycnFjgZvENbHpLYO4T3yDKpcuVF zyGyZhTGcXj90ori6uBzQRpd/g23mAjuIByKy/mQyz3hdfTjenGTGPtu0khf2NaEVHQ5 hVVlrQFeFfZAHFsaTU36lSbrxzM2tiTjCrmyBJlLpygpbQ0HwHcYGFLDJCaL4YBaHcLd HBRQG67LVPV5LQqQYD0sFJXGPNrmxB+wfBpXHAd9evFfIEeygn7NXFi0xtkCa6aVLGaC 3694zXm81UDvMbuVigMP9LGwaYHm0PYhFDZsWszIBTrVu1DPmHtrf6W6e/HPy06zyglZ RaUQ== Received: by 10.68.232.129 with SMTP id to1mr3493306pbc.27.1337027371132; Mon, 14 May 2012 13:29:31 -0700 (PDT) Received: from [192.168.254.142] ([12.207.18.42]) by mx.google.com with ESMTPS id i1sm23203993pbv.49.2012.05.14.13.29.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 13:29:30 -0700 (PDT) References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <99450BAB-E40C-4F1F-A1E2-19D63CA9E3A1@gmail.com> X-Mailer: iPad Mail (9B206) From: Sam Aldrin Date: Mon, 14 May 2012 13:29:28 -0700 To: Donald Eastlake Cc: "trill@ietf.org" Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 20:29:32 -0000 Hi Donald, Few questions inline. Sam Sent from my iPad On May 14, 2012, at 12:26 PM, Donald Eastlake wrote: > None of these arguments matter as our Area Director says that we need > to re-Charter to make TRILL over IP a WG draft. However, I will > respond a bit below: %sam- does this mean, the poll being undertaken is a moot point? If so, why t= o ask the WG for adoption? >=20 > On Mon, May 14, 2012 at 3:06 PM, Tissa Senevirathne (tsenevir) > wrote: >> Hi Radia >>=20 >> If we are discussing about TRILL over foo then this draft is not generic.= >>=20 >> If we are discussing about TRILL over IP then I begin to wonder why canno= t we use existing pseudo-wire techniques. >=20 > You can but the result is inferior, adding more layers of fuzz between > TRILL and actual transport protocol. %sam - are you saying, because it uses ip, it is superior technology than L2= technologies like PW? Ip has to use L2 anyway, so, the logic you are using d= oesn't make sense to me. >=20 >> If we can use existing VPLS or L2VPN techniques to achieve required funct= ionality, why do we need yet another solution to save 2 MAC address and a VL= AN on outer Ethernet header. >=20 > Maybe on a point-to-point link the main advantage is the savings you > mention. But on a multi-point technology like IP there are lots of > other factors in addition to saving a non-trivial number of bytes, > factors related to multi-destination traffic, security, etc. That is not true. Vpls is a multi point technology and is widely used in man= y network types. Which aspects of the technology makes ip better here? >=20 > The current L2VPN WG draft, to the extent it talks about > interconnecting TRILL islands, isn't TRILL over anything but, although > it connects the TRILL data planes, runs some new different more > loosely coupled control protocol between the islands. It is not entirely correct. The existing draft does encap trill frames with l= abels to be transferred over pw's. Whether it connects islands or something e= lse is a matter of how you deploy the technology. Sam >=20 >> If we are discussing about TRILL over foo then WG need to have consensus o= n overall strategy before moving individual solutions to WG status. People m= ay argue we should have a lower bar to enter documents to WG status, but sid= e effect of that is we are over crowding the document set, hence taking focu= s away from agreed priority items. Additionally, one may even argue TRILL o= ver any other transport protocol should be part of L2VPN. >>=20 >> Lastly, what is the rush to move this document to WG status ? >=20 > That's no different than asking why the obstructionism about a draft > that has been presented and discussed and in which previously raised > objections have been, as far as I can tell, resolved. Sitting on your > hands is not a way to get standards done. >=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 >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of= Radia Perlman >> Sent: Monday, May 14, 2012 10:37 AM >> To: Erik Nordmark >> Cc: trill@ietf.org >> Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG docum= ent? >>=20 >> I don't understand the controversy. TRILL over IP is useful in several c= ases which are actually clearly explained in this document. >> And in general, the document seems well thought out and well written. >>=20 >> So, I think it should be a WG document. >>=20 >> Radia >>=20 >> On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark wrote: >>>=20 >>> The document is at >>> https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ >>>=20 >>> We've discussed this document in WG meetings and on the list in the past= . >>>=20 >>> Please send comments to the list. >>>=20 >>> Erik >>> _______________________________________________ >>> 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 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Mon May 14 14:19: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 9743E21F8910 for ; Mon, 14 May 2012 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.688 X-Spam-Level: X-Spam-Status: No, score=-103.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utx+F2CJwQtE for ; Mon, 14 May 2012 14:19:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 963B921F890C for ; Mon, 14 May 2012 14:19:09 -0700 (PDT) Received: by yenq13 with SMTP id q13so5681456yen.31 for ; Mon, 14 May 2012 14:19:09 -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 :content-type:content-transfer-encoding; bh=l/3Q7AZ4DBHrSbieemVUhoSkHIuSgGZsjSCTRaFcQA4=; b=Ojf1aoR3AtaXBdy/V1zSm3r/LFk6iAbfQ3hQJCUy2BNkkIwIgF0J9RstLi1DmUHwJh cIBRVFs48Am6d2W3s0RNCYtDxs2RvyNBbqPGKleixvM5HEMoDTo6I9myrWRL02D4UerE C9vFxFd5lvgfwY6W2yuwEq3yLBaKcXfLR2B3EL1VaqBZqW5m7JUZSrbuzlWwe+gNJsur rfDpZ+896M8olfKS6ABO+2A78y+LHWz57AS7F6gkb/XPNANPycTiXQfM8yFNqI6qVl4k DuWUSewWSrnV/YAmuXlWe9Gq4I4m70DTLlnISTUySI44bGHpw15YHnvmKAJJ0yltrb0k fBWQ== Received: by 10.50.41.165 with SMTP id g5mr451517igl.13.1337030348822; Mon, 14 May 2012 14:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Mon, 14 May 2012 14:18:48 -0700 (PDT) In-Reply-To: <99450BAB-E40C-4F1F-A1E2-19D63CA9E3A1@gmail.com> References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> <99450BAB-E40C-4F1F-A1E2-19D63CA9E3A1@gmail.com> From: Donald Eastlake Date: Mon, 14 May 2012 17:18:48 -0400 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 21:19:10 -0000 Hi Sam, On Mon, May 14, 2012 at 4:29 PM, Sam Aldrin wrote: > Hi Donald, > > Few questions inline. > > Sam > > Sent from my iPad > > On May 14, 2012, at 12:26 PM, Donald Eastlake wrote: > >> None of these arguments matter as our Area Director says that we need >> to re-Charter to make TRILL over IP a WG draft. However, I will >> respond a bit below: > %sam- does this mean, the poll being undertaken is a moot point? If so, w= hy to ask the WG for adoption? Yes, it is moot. When the question was asked, this was not realized. >> On Mon, May 14, 2012 at 3:06 PM, Tissa Senevirathne (tsenevir) >> wrote: >>> Hi Radia >>> >>> If we are discussing about TRILL over foo then this draft is not generi= c. >>> >>> If we are discussing about TRILL over IP then I begin to wonder why can= not we use existing pseudo-wire techniques. >> >> You can but the result is inferior, adding more layers of fuzz between >> TRILL and actual transport protocol. > %sam - are you saying, because it uses ip, it is superior technology than= L2 technologies like PW? Ip has to use L2 anyway, so, the logic you are us= ing doesn't make sense to me. Not at all. I'm saying that when you design a native way of doing X over Y, you typically get a better result that when you say "we will do X over Y by just using the Generic over Y existing protocol and doing X over Generic over Y". Let me give a specific example: GRE. Lots of things use GRE but if you look at the GRE RFC 2784, it says: "In attempting to be more general, many protocol specific nuances have been ignored [in GRE]. The result is that this proposal may be less suitable for a situation where a specific "X over Y" encapsulation has been described." Another specific example of something that can get fuzzed and produce inferior results due to generic middle levels of protocol is MTU handling. On the other hand, it takes more work to to specify specific native ways to do X over Y for lots of Ys. You don't always end up with the same answer. TRILL over PPP (RFC6361) uses a native format designed for TRILL. On the other hand, draft-yong-trill-trill-o-mpls for full point to point connection of RBridges specifies using already specified Ethernet or PPP MPLS pseudo-wires and recommends using the PPP types because it saves bytes and is already specified. >>> If we can use existing VPLS or L2VPN techniques to achieve required fun= ctionality, why do we need yet another solution to save 2 MAC address and a= VLAN on outer Ethernet header. >> >> Maybe on a point-to-point link the main advantage is the savings you >> mention. But on a multi-point technology like IP there are lots of >> other factors in addition to saving a non-trivial number of bytes, >> factors related to multi-destination traffic, security, etc. > That is not true. All I was trying to say was that multi-point (multi-access) link technologies are more complicated than point-to-point so there are more different factors in their performance. I continue to believe that. >Vpls is a multi point technology and is widely used in many network types.= Which aspects of the technology makes ip better here? Ubiquity? I'm really not interested in continuing to argue about technology t1 versus technology t2 since I'm pretty certain that you would eventually find out that t1 was better under some circumstances and t2 was better under other circumstances. This does not mean that you should standardize both t1 and t2 but if you believe the circumstances where tx was best were common enough, you would want to standardize tx. >> The current L2VPN WG draft, to the extent it talks about >> interconnecting TRILL islands, isn't TRILL over anything but, although >> it connects the TRILL data planes, runs some new different more >> loosely coupled control protocol between the islands. > It is not entirely correct. The existing draft does encap trill frames wi= th labels to be transferred over pw's. Whether it connects islands or somet= hing else is a matter of how you deploy the technology. Last time I looked, I believe it only did that for TRILL Data frames, not TRILL IS-IS frames. Donald > Sam >> >>> If we are discussing about TRILL over foo then WG need to have consensu= s on overall strategy before moving individual solutions to WG status. Peop= le may argue we should have a lower bar to enter documents to WG status, bu= t side effect of that is we are over crowding the document set, hence takin= g focus away from agreed priority items. =A0Additionally, one may even argu= e TRILL over any other transport protocol should be part of L2VPN. >>> >>> Lastly, what is the rush to move this document to WG status ? >> >> That's no different than asking why the obstructionism about a draft >> that has been presented and discussed and in which previously raised >> objections have been, as far as I can tell, resolved. Sitting on your >> hands is not a way to get standards done. >> >> 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 >> >>> -----Original Message----- >>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf = Of Radia Perlman >>> Sent: Monday, May 14, 2012 10:37 AM >>> To: Erik Nordmark >>> Cc: trill@ietf.org >>> Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG doc= ument? >>> >>> I don't understand the controversy. =A0TRILL over IP is useful in sever= al cases which are actually clearly explained in this document. >>> And in general, the document seems well thought out and well written. >>> >>> So, I think it should be a WG document. >>> >>> Radia >>> >>> On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark wrote= : >>>> >>>> The document is at >>>> https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ >>>> >>>> We've discussed this document in WG meetings and on the list in the pa= st. >>>> >>>> Please send comments to the list. >>>> >>>> =A0 Erik >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill From eric.gray@ericsson.com Mon May 14 14:47: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 78AB821F8767 for ; Mon, 14 May 2012 14:47:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSnoDd8I2wUL for ; Mon, 14 May 2012 14:47:25 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08D21F8748 for ; Mon, 14 May 2012 14:47:25 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4ELl8Jf032212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 May 2012 16:47:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 14 May 2012 17:47:17 -0400 From: Eric Gray To: Donald Eastlake Date: Mon, 14 May 2012 17:47:16 -0400 Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0yFzeKIl1CZyPNSEa90KYj1d8fogAAptbQ Message-ID: References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> <99450BAB-E40C-4F1F-A1E2-19D63CA9E3A1@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 14 May 2012 21:47:26 -0000 Donald, Possibly I am missing something here, but it looks like=20 you are not being terribly clear. Either that, or you it may be that you are being clear terribly. :-) In saying that the AD has said that the WG needs "to=20 re-charter to make TRILL over IP a WG draft [SIC]" it is not clear exactly what this means. Moreover, in responding to Sam's request for clarification, you have not made this any=20 clearer. Are you saying: 1) The AD says that this cannot be a WG draft unless the WG adds it to the Charter. ... Or ... 2) The AD has instructed us to add this work item to the WG Charter, so that work can progress on this draft. I suspect that what you mean is the former, but what you said can be interpretted either way, and either way would mean the question of adopting the draft as a WG draft is moot... -- Eric -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Monday, May 14, 2012 5:19 PM To: trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG documen= t? Hi Sam, On Mon, May 14, 2012 at 4:29 PM, Sam Aldrin wrote: > Hi Donald, > > Few questions inline. > > Sam > > Sent from my iPad > > On May 14, 2012, at 12:26 PM, Donald Eastlake wrote: > >> None of these arguments matter as our Area Director says that we need >> to re-Charter to make TRILL over IP a WG draft. However, I will >> respond a bit below: > %sam- does this mean, the poll being undertaken is a moot point? If so, w= hy to ask the WG for adoption? Yes, it is moot. When the question was asked, this was not realized. >> On Mon, May 14, 2012 at 3:06 PM, Tissa Senevirathne (tsenevir) >> wrote: >>> Hi Radia >>> >>> If we are discussing about TRILL over foo then this draft is not generi= c. >>> >>> If we are discussing about TRILL over IP then I begin to wonder why can= not we use existing pseudo-wire techniques. >> >> You can but the result is inferior, adding more layers of fuzz between >> TRILL and actual transport protocol. > %sam - are you saying, because it uses ip, it is superior technology than= L2 technologies like PW? Ip has to use L2 anyway, so, the logic you are us= ing doesn't make sense to me. Not at all. I'm saying that when you design a native way of doing X over Y, you typically get a better result that when you say "we will do X over Y by just using the Generic over Y existing protocol and doing X over Generic over Y". Let me give a specific example: GRE. Lots of things use GRE but if you look at the GRE RFC 2784, it says: "In attempting to be more general, many protocol specific nuances have been ignored [in GRE]. The result is that this proposal may be less suitable for a situation where a specific "X over Y" encapsulation has been described." Another specific example of something that can get fuzzed and produce inferior results due to generic middle levels of protocol is MTU handling. On the other hand, it takes more work to to specify specific native ways to do X over Y for lots of Ys. You don't always end up with the same answer. TRILL over PPP (RFC6361) uses a native format designed for TRILL. On the other hand, draft-yong-trill-trill-o-mpls for full point to point connection of RBridges specifies using already specified Ethernet or PPP MPLS pseudo-wires and recommends using the PPP types because it saves bytes and is already specified. >>> If we can use existing VPLS or L2VPN techniques to achieve required fun= ctionality, why do we need yet another solution to save 2 MAC address and a= VLAN on outer Ethernet header. >> >> Maybe on a point-to-point link the main advantage is the savings you >> mention. But on a multi-point technology like IP there are lots of >> other factors in addition to saving a non-trivial number of bytes, >> factors related to multi-destination traffic, security, etc. > That is not true. All I was trying to say was that multi-point (multi-access) link technologies are more complicated than point-to-point so there are more different factors in their performance. I continue to believe that. >Vpls is a multi point technology and is widely used in many network types.= Which aspects of the technology makes ip better here? Ubiquity? I'm really not interested in continuing to argue about technology t1 versus technology t2 since I'm pretty certain that you would eventually find out that t1 was better under some circumstances and t2 was better under other circumstances. This does not mean that you should standardize both t1 and t2 but if you believe the circumstances where tx was best were common enough, you would want to standardize tx. >> The current L2VPN WG draft, to the extent it talks about >> interconnecting TRILL islands, isn't TRILL over anything but, although >> it connects the TRILL data planes, runs some new different more >> loosely coupled control protocol between the islands. > It is not entirely correct. The existing draft does encap trill frames wi= th labels to be transferred over pw's. Whether it connects islands or somet= hing else is a matter of how you deploy the technology. Last time I looked, I believe it only did that for TRILL Data frames, not TRILL IS-IS frames. Donald > Sam >> >>> If we are discussing about TRILL over foo then WG need to have consensu= s on overall strategy before moving individual solutions to WG status. Peop= le may argue we should have a lower bar to enter documents to WG status, bu= t side effect of that is we are over crowding the document set, hence takin= g focus away from agreed priority items. =A0Additionally, one may even argu= e TRILL over any other transport protocol should be part of L2VPN. >>> >>> Lastly, what is the rush to move this document to WG status ? >> >> That's no different than asking why the obstructionism about a draft >> that has been presented and discussed and in which previously raised >> objections have been, as far as I can tell, resolved. Sitting on your >> hands is not a way to get standards done. >> >> 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 >> >>> -----Original Message----- >>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf = Of Radia Perlman >>> Sent: Monday, May 14, 2012 10:37 AM >>> To: Erik Nordmark >>> Cc: trill@ietf.org >>> Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG doc= ument? >>> >>> I don't understand the controversy. =A0TRILL over IP is useful in sever= al cases which are actually clearly explained in this document. >>> And in general, the document seems well thought out and well written. >>> >>> So, I think it should be a WG document. >>> >>> Radia >>> >>> On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark wrote= : >>>> >>>> The document is at >>>> https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ >>>> >>>> We've discussed this document in WG meetings and on the list in the pa= st. >>>> >>>> Please send comments to the list. >>>> >>>> =A0 Erik >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 Mon May 14 17:55:43 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 C469E21F88C0 for ; Mon, 14 May 2012 17:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr6tbkTq-bLm for ; Mon, 14 May 2012 17:55:43 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5B05B21F884C for ; Mon, 14 May 2012 17:55:43 -0700 (PDT) Received: from [10.0.0.100] (96-24-67-191.sfo.clearwire-wmx.net [96.24.67.191] (may be forged)) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q4F0tdno023445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 17:55:41 -0700 Message-ID: <4FB1A98A.8010803@acm.org> Date: Mon, 14 May 2012 17:55:38 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "trill@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] TRILL OAM Design Team 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, 15 May 2012 00:55:43 -0000 Hi, As discussed in Paris, an OAM Design Team has been set up to work on TRILL OAM drafts. As per IETF policy, the output of this design team has no special status or preference compared proposals by any other one or more participants in the TRILL WG. Sorry for the delay in formally announcing this. The members of the design team in alphabetic order are: Sam Aldrin David M. Bond Donald Eastlake Anoop Ghanwani Jon Hudson Tal Mizrahi Naveen Nimmu Thomas Narten Erik Nordmark Radia Perlman Tissa Senevirathne Shivakumar Sundaram Rohit Watve Li Yizhou Thanks, Erik and Donald From aldrin.ietf@gmail.com Mon May 14 18:37: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 7097F21F88FF for ; Mon, 14 May 2012 18:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmaDdFDYhrvN for ; Mon, 14 May 2012 18:37:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDF1C21F88F7 for ; Mon, 14 May 2012 18:37:00 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7037770pbc.31 for ; Mon, 14 May 2012 18:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=mMjluvjljMtIOsgweMVv0HObOrnxYJ6/HdXJQlZEx/Q=; b=kJGm0fmjn8XJFPP0hXYCvJUUzkv2zVRCdu4ljAOaZfTua7QWLXYvOJKZWD2trSZqBu U/U2amp0qO6nYl79VYEv90uA0OcjRo/PuBWOPNPu2MwmQEwoC69eEVDhecJbr+V9ITTt 3QhW24zJFya3t3UelAkNJZOPZcmauCz1KQqLm/sPP7Fu6IYMCox3RNBCgLzLhDo3wpKQ cOAxtYDZwUxX807u5ph8TSYrHYZ+enRxOMRY0xfLWRG7ZmEw3HbAp27O/6C5SLRJdOO6 aaBoCxZwANiLAJeMT4aSCrzmjfYFoBK92FNl/nmk8T4qj5mHuiIZh+eF3zbUfc6u75Ay /i6g== Received: by 10.68.217.38 with SMTP id ov6mr353262pbc.25.1337045820321; Mon, 14 May 2012 18:37:00 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id pu5sm125623pbc.28.2012.05.14.18.36.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 18:36:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E88A607-FF55-41F2-9BF1-C7D1B2766FEA" From: Sam Aldrin In-Reply-To: Date: Mon, 14 May 2012 18:36:56 -0700 Message-Id: <75F16D34-56E3-42D8-A6D3-EAE79A77CDE7@gmail.com> References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> <99450BAB-E40C-4F1F-A1E2-19D63CA9E3A1@gmail.com> To: Donald Eastlake X-Mailer: Apple Mail (2.1278) Cc: "trill@ietf.org" Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 01:37:09 -0000 --Apple-Mail=_2E88A607-FF55-41F2-9BF1-C7D1B2766FEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 [Removed content which is not relavent] >>=20 >>> None of these arguments matter as our Area Director says that we = need >>> to re-Charter to make TRILL over IP a WG draft. However, I will >>> respond a bit below: >> %sam- does this mean, the poll being undertaken is a moot point? If = so, why to ask the WG for adoption? >=20 > Yes, it is moot. When the question was asked, this was not realized. There are multiple drafts addressing TRILL interconnect, which means = TRILL over something. These drafts include TRILL over IP as well. What does this decision mean for those drafts, which includes TRILL over = IP as well? >=20 > Not at all. I'm saying that when you design a native way of doing X > over Y, you typically get a better result that when you say "we will > do X over Y by just using the Generic over Y existing protocol and > doing X over Generic over Y". Let me give a specific example: GRE. > Lots of things use GRE but if you look at the GRE RFC 2784, it says: > "In attempting to be more general, many protocol specific > nuances have been ignored [in GRE]. The result is that this proposal > may be less suitable for a situation where a specific "X over Y" > encapsulation has been described." If layering is the problem, then we would not be talking about NVGRE etc = technologies, which are built over it. My point is, just because there = is generic layer, does not discount X over generic over Y, because there = are other advantages which comes along with that. >=20 > Another specific example of something that can get fuzzed and produce > inferior results due to generic middle levels of protocol is MTU > handling. %SAM - It goes both ways. MTU issue and defragmentation, packet re-order = are some other issues which comes along with IP. >=20 >>=20 >>=20 >=20 > Last time I looked, I believe it only did that for TRILL Data frames, > not TRILL IS-IS frames. Correct. The current PBB-EVPN do not process IS-IS control frames. -sam >=20 > Donald >=20 >> Sam >>>=20 >>>> If we are discussing about TRILL over foo then WG need to have = consensus on overall strategy before moving individual solutions to WG = status. People may argue we should have a lower bar to enter documents = to WG status, but side effect of that is we are over crowding the = document set, hence taking focus away from agreed priority items. = Additionally, one may even argue TRILL over any other transport protocol = should be part of L2VPN. >>>>=20 >>>> Lastly, what is the rush to move this document to WG status ? >>>=20 >>> That's no different than asking why the obstructionism about a draft >>> that has been presented and discussed and in which previously raised >>> objections have been, as far as I can tell, resolved. Sitting on = your >>> hands is not a way to get standards done. >>>=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 >>>> -----Original Message----- >>>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On = Behalf Of Radia Perlman >>>> Sent: Monday, May 14, 2012 10:37 AM >>>> To: Erik Nordmark >>>> Cc: trill@ietf.org >>>> Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG = document? >>>>=20 >>>> I don't understand the controversy. TRILL over IP is useful in = several cases which are actually clearly explained in this document. >>>> And in general, the document seems well thought out and well = written. >>>>=20 >>>> So, I think it should be a WG document. >>>>=20 >>>> Radia >>>>=20 >>>> On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark = wrote: >>>>>=20 >>>>> The document is at >>>>> https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ >>>>>=20 >>>>> We've discussed this document in WG meetings and on the list in = the past. >>>>>=20 >>>>> Please send comments to the list. >>>>>=20 >>>>> Erik >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 --Apple-Mail=_2E88A607-FF55-41F2-9BF1-C7D1B2766FEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

None of these arguments matter = as our Area Director says that we = need
to re-Charter to make TRILL over IP a WG draft. However, I = will
respond a bit = below:
%sam- does = this mean, the poll being undertaken is a moot point? If so, why to ask = the WG for adoption?

Yes, it is moot. When the = question was asked, this was not realized.
There = are multiple drafts addressing TRILL interconnect, which means TRILL = over something. These drafts include TRILL over IP as = well.
What does this decision mean for those drafts, which = includes TRILL over IP as well?

Not at all. I'm saying that when you design a = native way of doing X
over Y, you typically get a better result that = when you say "we will
do X over Y by just using the Generic over Y = existing protocol and
doing X over Generic over Y". Let me give a = specific example: GRE.
Lots of things use GRE but if you look at the = GRE RFC 2784, it says:
  "In attempting to be more = general, many protocol specific
  nuances have been = ignored [in GRE]. The result is that this proposal
  may = be less suitable for a situation where a specific "X over Y"
=   encapsulation has been described."
If = layering is the problem, then we would not be talking about NVGRE etc = technologies, which are built over it. My point is, just because there = is generic layer, does not discount X over generic over Y, because there = are other advantages which comes along with that.

Another specific example of something that can = get fuzzed and produce
inferior results due to generic middle levels = of protocol is MTU
handling.
%SAM - It goes = both ways. MTU issue and defragmentation, packet re-order are some other = issues which comes along with IP.




Last time I looked, I = believe it only did that for TRILL Data frames,
not TRILL IS-IS = frames.
Correct. The current PBB-EVPN do not = process IS-IS control = frames.

-sam

Donald

Sam

If we = are discussing about TRILL over foo then WG need to have consensus on = overall strategy before moving individual solutions to WG status. People = may argue we should have a lower bar to enter documents to WG status, = but side effect of that is we are over crowding the document set, hence = taking focus away from agreed priority items.  Additionally, one = may even argue TRILL over any other transport protocol should be part of = L2VPN.

Lastly, = what is the rush to move this document to WG status = ?

That's no different than asking = why the obstructionism about a = draft
that has been presented and discussed and in which = previously raised
objections have been, as far as = I can tell, resolved. Sitting on = your
hands is not a way to get standards = done.

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

-----Original = Message-----
From: = trill-bounces@ietf.org = [mailto:trill-bounces@ietf.org] On Behalf Of Radia = Perlman
Sent: = Monday, May 14, 2012 10:37 = AM
To: = Erik Nordmark
Cc: trill@ietf.org
Subject: Re: [trill] Should we = make draft-mrw-trill-over-ip-01 a WG = document?

I = don't understand the controversy.  TRILL over IP is useful in = several cases which are actually clearly explained in this = document.
And in = general, the document seems well thought out and well = written.

So, I = think it should be a WG = document.

Radia

On = Fri, May 11, 2012 at 5:38 PM, Erik Nordmark <nordmark@acm.org> = wrote:

The document is = at
https:/= /datatracker.ietf.org/doc/draft-mrw-trill-over-ip/

We've discussed this document in = WG meetings and on the list in the = past.

Please send comments to the = list.

  = Erik
_______________________________________________
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
_______________________________________________
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

= --Apple-Mail=_2E88A607-FF55-41F2-9BF1-C7D1B2766FEA-- From aldrin.ietf@gmail.com Mon May 14 18:43:56 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 701BA21F8920 for ; Mon, 14 May 2012 18:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ynRWBERzK8h for ; Mon, 14 May 2012 18:43:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5221F890B for ; Mon, 14 May 2012 18:43:46 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7043790pbc.31 for ; Mon, 14 May 2012 18:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZQuYcB3zbUqhuGeTlOUGP7p1Lhy+4xlRpK/QAPBcmr4=; b=Ii+47r7GNsK6SB9dz305qY6GbSDwvlWXpGnn5x5tRk4Mr1z6T2XXDPldfUtjyhQfK+ zv7g7UcMct1M1GK47XUchlln96rwfYbAoIkp0xr8Z9KSSL7gAcOjY1AGZKRnodOfU10W 0HzMGiejWEoflYGhQGuXECkyEWLz2FBw0fVm2U3mz+hGhKM/euZp8Xd1DEqSKJip8M5c Do/GzeMKHgVckXPoMJ/dxX4SBqlLgW3akywm6TdIl/vCYerZJrAGarRLGPzCyu4XLLOz wy34pKGX6s0d2H/h+RilPubPRwIhz92oIo4gQLbo0wglX2XHV+oetMIo9oa5oC5rh48H jPog== Received: by 10.68.222.130 with SMTP id qm2mr381677pbc.28.1337046226670; Mon, 14 May 2012 18:43:46 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id tx9sm149185pbc.10.2012.05.14.18.43.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 18:43:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Sam Aldrin In-Reply-To: <4FADB0E8.1090000@acm.org> Date: Mon, 14 May 2012 18:43:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68C9A3E6-F592-49CC-B475-52E6F866605D@gmail.com> References: <4FADB0E8.1090000@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1278) Cc: "trill@ietf.org" Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 01:43:56 -0000 I do not support making this WG document as of now. Reasons are as follows - There is still lots to be done in the interconnect area before = picking individual solutions like TRILL over IP, TRILL over GRE, TRILL = over MPLS etc - There are other drafts which are also addressing interconnect and = TRILL over various WAN technologies and cover much broader scope and not = just IP. - We really haven't discussed much in the area of interconnect. Once = that discussion happens, WG could take the right course on how to move = forward. -sam On May 11, 2012, at 5:38 PM, Erik Nordmark wrote: >=20 > The document is at > https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ >=20 > We've discussed this document in WG meetings and on the list in the = past. >=20 > Please send comments to the list. >=20 > Erik > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From tsenevir@cisco.com Mon May 14 19:32:00 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 D25BC21F894A for ; Mon, 14 May 2012 19:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.225 X-Spam-Level: X-Spam-Status: No, score=-9.225 tagged_above=-999 required=5 tests=[AWL=1.374, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZahD7n928HY for ; Mon, 14 May 2012 19:32:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E1BBE21F8945 for ; Mon, 14 May 2012 19:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=5090; q=dns/txt; s=iport; t=1337049120; x=1338258720; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HIOFMfGjW6ymjVan7ZpEzridgewgm8P/dzLCzlWgqIk=; b=Gg79u/IOWGA9WAv579JqajRpIlG1QCxIo9EYGksFWCdX99tQmkGkTPRV bKipq/y/JYqHnmcRetJO+kblaUar4hxdPEfxVaCRsrUtzpBiCpqTznhOH u9qjIzNfXguLT4+MFuE2Ya2fcCTsiegA4GDxec1ZToO5O0d3kUL0q2sVi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIS/sU+rRDoH/2dsb2JhbABBA7N5gQeCFQEBAQMBAQEBDwEdPhAHBAIBCA4DBAEBAQoGFwEGASAGHwkIAQEEARIIEweHXgMGBAybB5Y1DYlPBIokboJVgkhjBIgwNJhWgxqBaYMJ X-IronPort-AV: E=Sophos;i="4.75,590,1330905600"; d="scan'208";a="42227754" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 15 May 2012 02:31:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4F2Vxa2014930; Tue, 15 May 2012 02:31:59 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 19:31:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 19:31:49 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5011CB255@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? Thread-Index: Ac0yB4cpiJxhIyq/QwaN/9zF7mQBowANle+w References: <4FADB0E8.1090000@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" , X-OriginalArrivalTime: 15 May 2012 02:31:59.0311 (UTC) FILETIME=[E7482DF0:01CD3242] Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 02:32:00 -0000 Hi Donald Please see some comments in-line -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf = Of Donald Eastlake Sent: Monday, May 14, 2012 12:27 PM To: trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG = document? None of these arguments matter as our Area Director says that we need to = re-Charter to make TRILL over IP a WG draft.=20 [Answer] That is very prudent and thanks. However, I will respond a bit below: On Mon, May 14, 2012 at 3:06 PM, Tissa Senevirathne (tsenevir) = wrote: > Hi Radia > > If we are discussing about TRILL over foo then this draft is not = generic. > > If we are discussing about TRILL over IP then I begin to wonder why = cannot we use existing pseudo-wire techniques. You can but the result is inferior, adding more layers of fuzz between = TRILL and actual transport protocol. [Answer] Which sense would the result be inferior ? Native form of TRILL = as defined in RFC 6325 is with a link-level header and removing that and = remapping to IP in my opinion is more fuzz than using native form over = L2VPN. > If we can use existing VPLS or L2VPN techniques to achieve required = functionality, why do we need yet another solution to save 2 MAC address = and a VLAN on outer Ethernet header. Maybe on a point-to-point link the main advantage is the savings you = mention. But on a multi-point technology like IP there are lots of other = factors in addition to saving a non-trivial number of bytes, factors = related to multi-destination traffic, security, etc. The current L2VPN WG draft, to the extent it talks about interconnecting = TRILL islands, isn't TRILL over anything but, although it connects the = TRILL data planes, runs some new different more loosely coupled control = protocol between the islands. [Answer] Sam has already answered this. > If we are discussing about TRILL over foo then WG need to have = consensus on overall strategy before moving individual solutions to WG = status. People may argue we should have a lower bar to enter documents = to WG status, but side effect of that is we are over crowding the = document set, hence taking focus away from agreed priority items. = =A0Additionally, one may even argue TRILL over any other transport = protocol should be part of L2VPN. > > Lastly, what is the rush to move this document to WG status ? That's no different than asking why the obstructionism about a draft = that has been presented and discussed and in which previously raised = objections have been, as far as I can tell, resolved. Sitting on your = hands is not a way to get standards done. [Answer] Few fronts here: 1. I Have raised the same objection in Taipei = and over the mailing list, i.e. why yet another solution, as far as I = can tell that has not been resolved. 2. We can fundamentally disagree, but my opinion on right way to get = standards done is to have a well thought through strategy rather than = advancing individual solutions. 3. On a different note, our WG should spent sometime deciding on what = work items to be done and strategy around them. According to published = goals, TRILL is up for re-charter or shutdown in July 2012. Having clear = strategy around work items to be done will help. (My two bits of = thoughts here)=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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf = > Of Radia Perlman > Sent: Monday, May 14, 2012 10:37 AM > To: Erik Nordmark > Cc: trill@ietf.org > Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG = document? > > I don't understand the controversy. =A0TRILL over IP is useful in = several cases which are actually clearly explained in this document. > And in general, the document seems well thought out and well written. > > So, I think it should be a WG document. > > Radia > > On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark = wrote: >> >> The document is at >> https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/ >> >> We've discussed this document in WG meetings and on the list in the = past. >> >> Please send comments to the list. >> >> =A0 Erik >> _______________________________________________ >> 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 _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Mon May 14 20:18: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 330139E800B for ; Mon, 14 May 2012 20:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.686 X-Spam-Level: X-Spam-Status: No, score=-103.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSFDFCYLQn3z for ; Mon, 14 May 2012 20:18:19 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98BFD9E8006 for ; Mon, 14 May 2012 20:18:19 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2306299ggn.31 for ; Mon, 14 May 2012 20:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=TZ0WlvYwp7Tw9ZdFLJe1sYAs5mCc2A51AUlKh8Gkkvc=; b=g6RgG3caYSH0bx2COU/Wi8zbEe27XPlbnEX1PYsKZFRxPn8s0T2eYeQu1cjTEgHWyW jzEkuJdpS/B1q2nkgwDQTazWZbPc+BE0lCzExO8yiNpzKwfpYQBKgiAsIw5iscS9FBcn 8rxuvSgqhDto2NGO44YDL83BAlyzY7xox/b6xm4bXpqEdl85KoapjW1chK8TKTolFm7l op6kZpUQxcAHJyZ1/ZE6AXDpob2XRW0Nrlsw4Yryo3DNxTvFKW4zlN1qcRusLEgTv83y y7Yt1+xXE/1wQ/D5XNvsM8VbgTBNsafk2eWNxe0JWpc0jYvST4tLQcyU0FYuQdTe8XnH muLw== Received: by 10.42.176.6 with SMTP id bc6mr4961157icb.49.1337051898968; Mon, 14 May 2012 20:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Mon, 14 May 2012 20:17:58 -0700 (PDT) In-Reply-To: <4FAD3E8A.3010206@acm.org> References: <4F9A2DDA.1070009@acm.org> <4FAD3E8A.3010206@acm.org> From: Donald Eastlake Date: Mon, 14 May 2012 23:17:58 -0400 Message-ID: To: Erik Nordmark Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "trill@ietf.org" Subject: Re: [trill] Fwd: Nits on draft-ietf-trill-rbridge-channel 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, 15 May 2012 03:18:20 -0000 Hi, On Fri, May 11, 2012 at 12:30 PM, Erik Nordmark wrote: > FYI: I had sent these nits to the authors a while back. > I think it makes sense to revise the draft to take care of the nits below= , > and then send it to the IESG. > > The "verbatim reproduction of the Inner Ethernet Header" should probably = be > left alone at this point in time. > > Regards, > =A0 Erik > > -------- Original Message -------- > Subject: Nits on draft-ietf-trill-rbridge-channel > Date: Thu, 26 Apr 2012 22:25:46 -0700 > From: Erik Nordmark > To: draft-ietf-trill-rbridge-channel@tools.ietf.org > > Shouldn't this say something slightly different than MUST be zero? > =A0 =A0 =A0CHV: A 4-bit field that gives the RBridge Channel Header Versi= on > =A0 =A0 =A0 =A0 =A0 =A0and MUST be zero. > Something like "This document specifies version zero." OK > The verbatim reproduction of the Inner Ethernet Header in section 2.1 > means that this document would need to be revised as a result of things > like fine grained labels. Wouldn't it make sense to instead do this by > reference to RFC6325 instead of reproducing the exact header? That gives > us the flexibility to have documents which update RFC6325 without > touching this document. As draft specifically discusses various fields in the Inner Ethernet header including the VLAN tag, and as per your note above, I don't think this should be changed. > Section 2.2 tries to rename the Op-len field in the base protocol to be > Ext-len. I think I commented on this being confusing and not worth-while > for the extensions draft, thus I think the channel draft can use the > same wording as the extensions draft (which does not attempt to rename > the field.) OK. > Section 6.2 says > =A0 The IEEE Registration Authority has been assigned the Ethertype > =A0 for RBridge-Channel. > > "has been assigned" should probably be "has assigned". > Do we already have an allocated number to replace the TBD? OK > Typo: "particuclar" OK. Also, Vishwas Manral's email address in the Author Info Section has a typo that should be fixed. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > =A0 Erik From narten@us.ibm.com Tue May 15 03:28: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 E4F6D21F862B for ; Tue, 15 May 2012 03:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJn2t0cafPcg for ; Tue, 15 May 2012 03:28:27 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3072D21F8629 for ; Tue, 15 May 2012 03:28:27 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 15 May 2012 04:28:26 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 15 May 2012 04:27:59 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 014DE19D8052 for ; Tue, 15 May 2012 04:27:47 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4FARujL100860 for ; Tue, 15 May 2012 04:27:57 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4FAScZH027903 for ; Tue, 15 May 2012 04:28:39 -0600 Received: from cichlid.raleigh.ibm.com ([9.65.197.255]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4FAScPG027872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 May 2012 04:28:38 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4FARs8U017402 for ; Tue, 15 May 2012 06:27:55 -0400 Message-Id: <201205151027.q4FARs8U017402@cichlid.raleigh.ibm.com> To: trill@ietf.org In-reply-to: <4FB100EC.9090203@workingcode.com> References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CAF33@xmb-sjc-214.amer.cisco.com> <4FB100EC.9090203@workingcode.com> Comments: In-reply-to James Carlson message dated "Mon, 14 May 2012 08:56:12 -0400." Date: Tue, 15 May 2012 06:27:54 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12051510-3270-0000-0000-000006591C4A Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 10:28:28 -0000 James Carlson writes: > The document is clearly in scope of the working group, and I believe the > only other question regarding adoption is whether the wg wants (and the > authors want) to steer the document by the working group consensus > process. IMO, this document is a straightforward TRILL encapsulation over Foo document. I would expect TRILL to produce a number of these, one per link technology. As long as such documents are scoped as how to run TRILL over a specific technology, IMO, such documents should be taken on by this WG. If we don't do it, who will? And we certainly want exactly one document per foo technology... > Determining whether it's needed or the right technical solution is > further down the road. If the wg determines that it's not right and > can't fix it, then it can terminate the work that it steers. Adoption > doesn't mean "we're committed to publishing this." That is the theory. Sadly, in practice, taking on a document as a WG item often does imply a committment to publish. I've seen plenty of WGs make the argument that taking a document on is not a committment to publish, and then later see a real reluctance to abandon a document that has limited if any real support. To be clear, I support taking on this particular document because I believe this is a good example of the kind of document that should be squarely within scope. However, I also agree with Tissa's general concern: "Tissa Senevirathne (tsenevir)" writes: > My main objection of making individual submissions WG docs without well > thought through strategy is it takes away the focus and confuse WG, > customers and burden vendors. Additionally, TRILL WG should focus on the > priority items that was agreed in Taipei. Adding additional WG docs is > not helping anyways. I am in the opinion that WG should identify > priority Work areas, then form strategy around it, bring together > different ideas to form well thought through solutions. This WG has too many documents to deal with and we are to some extent thrashing. Any WG has a finite amount of WG cycles. I continue to worry generally that our cycles are spread too thinly across too many documents. While I support taking on draft-mrw-trill-over-ip, it is far from clear to me that it needs to be a priority item for the WG. Thomas From narten@us.ibm.com Tue May 15 03:31:16 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 95E0121F8637 for ; Tue, 15 May 2012 03:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.451 X-Spam-Level: X-Spam-Status: No, score=-110.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijcwKUFC1pMN for ; Tue, 15 May 2012 03:31:16 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9821F8636 for ; Tue, 15 May 2012 03:31:15 -0700 (PDT) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 15 May 2012 04:31:14 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 15 May 2012 04:31:10 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 19FFBC9005C for ; Tue, 15 May 2012 06:31:04 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4FAV4Qb143560 for ; Tue, 15 May 2012 06:31:05 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4FAUx9M016899 for ; Tue, 15 May 2012 04:31:00 -0600 Received: from cichlid.raleigh.ibm.com ([9.65.197.255]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4FAUvPA016804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 04:30:58 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4FAUuJg017425; Tue, 15 May 2012 06:30:56 -0400 Message-Id: <201205151030.q4FAUuJg017425@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> Comments: In-reply-to Donald Eastlake message dated "Mon, 14 May 2012 15:26:30 -0400." Date: Tue, 15 May 2012 06:30:56 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12051510-7408-0000-0000-00000509EEE3 Cc: trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 10:31:16 -0000 Donald Eastlake writes: > None of these arguments matter as our Area Director says that we need > to re-Charter to make TRILL over IP a WG draft. However, I will > respond a bit below: Then let us please have that discussion and recharter. IMO, it is close to ludicrous for "TRILL over Foo" documents to be out-of-scope for this WG, if that is indeed what you are saying. One could argue that the WG needs to finish its core documents first. Or that it needs to get deploy experience first, etc., etc. Or that specific FOO is not needed. But having work on draft-mrw-trill-over-ip being done outside of the WG because its generally out-of-scope for TRILL would be broken, IMO. Thomas From rdroms@cisco.com Tue May 15 03:35: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 87AD621F8838 for ; Tue, 15 May 2012 03:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85aE5+3PdDQ2 for ; Tue, 15 May 2012 03:35:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DB6D521F870E for ; Tue, 15 May 2012 03:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1469; q=dns/txt; s=iport; t=1337078148; x=1338287748; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aAXRQqYCSlFsyxuU9xNfmrFTO9ITeq5SHfDc4Hjuzsc=; b=jAEztRu7GtXqkH/vOod6DiA37BPsZ+ew3MGD9wOmNpvq2fYHW2XnVXaR MJ/EtYvl8tIiIukUs6GWDfVwQwQvpAQPQJxDLQmJy9FkZpKGwKMrVGAVO yEJQYjWIja9aGYmE13OZjzXzc8+f//8tmva65fqU78Sg1QhFZ1bgamGrg U=; X-IronPort-AV: E=Sophos;i="4.75,593,1330905600"; d="scan'208";a="83318722" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 15 May 2012 10:35:47 +0000 Received: from rtp-rdroms-8912.cisco.com (rtp-rdroms-8912.cisco.com [10.116.164.51]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4FAZkKo014345; Tue, 15 May 2012 10:35:47 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201205151030.q4FAUuJg017425@cichlid.raleigh.ibm.com> Date: Tue, 15 May 2012 06:35:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2374D275-4D01-4031-99FA-85682AF19803@cisco.com> References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> <201205151030.q4FAUuJg017425@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1278) Cc: Donald Eastlake , trill@ietf.org, Ralph Droms Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 10:35:48 -0000 On May 15, 2012, at 6:30 AM 5/15/12, Thomas Narten wrote: > Donald Eastlake writes: >=20 >> None of these arguments matter as our Area Director says that we need >> to re-Charter to make TRILL over IP a WG draft. However, I will >> respond a bit below: >=20 > Then let us please have that discussion and recharter. IMO, it is > close to ludicrous for "TRILL over Foo" documents to be out-of-scope > for this WG, if that is indeed what you are saying. >=20 > One could argue that the WG needs to finish its core documents > first. Or that it needs to get deploy experience first, etc., etc. Or > that specific FOO is not needed. But having work on > draft-mrw-trill-over-ip being done outside of the WG because its > generally out-of-scope for TRILL would be broken, IMO. draft-mrw-trill-over-ip is not out of scope, it's just not on the = current list of deliverables for the working group. The core charter of = the working group is still OK but the list of deliverables is more than = a year old. Some have been completed, some have seen some progress but = are late, some have not been addressed at all. It's appropriate for the = WG to revisit the list of deliverables, decide what documents are core = and revise the charter appropriately. - Ralph >=20 > Thomas >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From mrw@lilacglade.org Tue May 15 03:54: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 8DBB021F872D for ; Tue, 15 May 2012 03:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm2SbmlHR9MH for ; Tue, 15 May 2012 03:54:27 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5921F8709 for ; Tue, 15 May 2012 03:54:26 -0700 (PDT) Received: from [10.36.0.36] (pool-108-49-158-143.bstnma.fios.verizon.net [108.49.158.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 250A420383; Tue, 15 May 2012 06:50:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-389-142294330 From: Margaret Wasserman In-Reply-To: Date: Tue, 15 May 2012 06:54:23 -0400 Message-Id: References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: Donald Eastlake , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 10:54:27 -0000 --Apple-Mail-389-142294330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ralph, Just FYI -- I am one of the authors of draft-mrw-trill-over-ip, so = obviously I have an interest in the outcome here. On May 14, 2012, at 3:26 PM, Donald Eastlake wrote: > None of these arguments matter as our Area Director says that we need > to re-Charter to make TRILL over IP a WG draft. However, I will > respond a bit below: Could you clarify what you mean by "we need to re-Charter to make TRILL = over IP a WG draft"? I can think of two things you might mean. (1) TRILL over Foo documents would fall into this part of the charter, "...but also additional ways to extend and optimize TRILL for the properties of the networks on which it is deployed." but we need to add a milestone for TRILL over IP which you and the = chairs can easily do if the WG agrees it wants to do this work. This = makes sense to me. OR (2) The above sentence would not cover TRILL over Foo documents, and we = would need to do a completely new charter to cover them. This doesn't = make sense to me for two reasons: (a) TRILL over Foo documents are = pretty clearly going to be needed, and need to be done in the TRILL WG, = and (b) I'm not sure what else would fall more firmly under the notion = of "extend ... TRILL for the properties ... of the networks on which = will be deployed". Whatever your intent, if we _did_ somehow manage to charter a WG where = the work needed to encapsulate the core protocol in IP _doesn't_ fall in = the WG charter, could we please fix that? I understand that we aren't done with the discussion of whether or not = the WG wants to adopt this particular draft for that purpose, but the = decisions about whether to encapsulate TRILL in IP, and if so, how do = it, clearly need to be made in the TRILL WG, not through the individual = or independent submission paths (which is what tends to happen when = existing, nearly complete documents are declared out-of-scope for any = IETF WG). Thanks, Margaret --Apple-Mail-389-142294330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
None of these = arguments matter as our Area Director says that we need
to re-Charter = to make TRILL over IP a WG draft. However, I will
respond a bit = below:

Could you clarify what you = mean by "we need to re-Charter to make TRILL over IP a WG draft"? =  I can think of two things you might = mean.

(1) TRILL over Foo documents would fall = into this part of the charter,

"...but also additional ways to
extend and optimize TRILL for = the properties of the networks on
which it is = deployed."

but we need to add a milestone for TRILL over IP which you and = the chairs can easily do if the WG agrees it wants to do this work. =  This makes sense to = me.

OR

(2) The above sentence would not cover TRILL over Foo documents, = and we would need to do a completely new charter to cover them. =  This doesn't make sense to me for two reasons:  (a) TRILL = over Foo documents are pretty clearly going to be needed, and need to = be done in the TRILL WG, and (b) I'm not sure what else would fall = more firmly under the notion of "extend ... TRILL for the properties ... = of the networks on which will be deployed".

Whatever your intent, if we _did_ somehow manage to charter a WG = where the work needed to encapsulate the core protocol in IP _doesn't_ = fall in the WG charter, could we please fix = that?

I understand that we aren't done with the discussion of whether or = not the WG wants to adopt this particular draft for that purpose, but = the decisions about whether to encapsulate TRILL in IP, and if so, how = do it, clearly need to be made in the TRILL WG, not through the = individual or independent submission paths (which is what tends to = happen when existing, nearly complete documents are declared = out-of-scope for any IETF WG).

Thanks,
Margaret







= --Apple-Mail-389-142294330-- From rdroms@cisco.com Tue May 15 04:33: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 3345E21F86F2 for ; Tue, 15 May 2012 04:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CFj0nnTdFE4 for ; Tue, 15 May 2012 04:33:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 70DE121F86CE for ; Tue, 15 May 2012 04:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=2744; q=dns/txt; s=iport; t=1337081634; x=1338291234; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=D9IesdKCJsU36NCfkrfvbfrmeONQC5CQP1YqOXXSxw8=; b=Ybon68iYsgK1BW0cqMsr7c0586heD7XdeKXl37hAY2HDo11NjjrC3CNN N/begbh0lQkreQKZS2+0LolXnjOXgaiQoAPzxPBE/3CkoI7Zda8layQ0Z UE/9JXwacs423v8ybBRa24qmLdq/b0kcNLn1Q6a8BbpvlMiUn2CO/iBL7 w=; X-IronPort-AV: E=Sophos;i="4.75,593,1330905600"; d="scan'208";a="83307657" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 15 May 2012 11:33:54 +0000 Received: from rtp-rdroms-8912.cisco.com (rtp-rdroms-8912.cisco.com [10.116.164.51]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4FBXri4015361; Tue, 15 May 2012 11:33:53 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Tue, 15 May 2012 07:33:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) Cc: Donald Eastlake , trill@ietf.org, Ralph Droms Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 11:33:55 -0000 On May 15, 2012, at 6:54 AM 5/15/12, Margaret Wasserman wrote: >=20 > Hi Ralph, >=20 > Just FYI -- I am one of the authors of draft-mrw-trill-over-ip, so = obviously I have an interest in the outcome here. >=20 > On May 14, 2012, at 3:26 PM, Donald Eastlake wrote: >> None of these arguments matter as our Area Director says that we need >> to re-Charter to make TRILL over IP a WG draft. However, I will >> respond a bit below: >=20 > Could you clarify what you mean by "we need to re-Charter to make = TRILL over IP a WG draft"? I can think of two things you might mean. I meant a third thing (quoting from previous e-mail): draft-mrw-trill-over-ip is not out of scope, it's just not on the = current list of deliverables for the working group. The core charter of = the working group is still OK but the list of deliverables is more than = a year old. Some have been completed, some have seen some progress but = are late, some have not been addressed at all. It's appropriate for the = WG to revisit the list of deliverables, decide what documents are core = and revise the charter appropriately. - Ralph >=20 > (1) TRILL over Foo documents would fall into this part of the charter, >=20 > "...but also additional ways to > extend and optimize TRILL for the properties of the networks on > which it is deployed." >=20 > but we need to add a milestone for TRILL over IP which you and the = chairs can easily do if the WG agrees it wants to do this work. This = makes sense to me. >=20 > OR >=20 > (2) The above sentence would not cover TRILL over Foo documents, and = we would need to do a completely new charter to cover them. This = doesn't make sense to me for two reasons: (a) TRILL over Foo documents = are pretty clearly going to be needed, and need to be done in the TRILL = WG, and (b) I'm not sure what else would fall more firmly under the = notion of "extend ... TRILL for the properties ... of the networks on = which will be deployed". >=20 > Whatever your intent, if we _did_ somehow manage to charter a WG where = the work needed to encapsulate the core protocol in IP _doesn't_ fall in = the WG charter, could we please fix that? >=20 > I understand that we aren't done with the discussion of whether or not = the WG wants to adopt this particular draft for that purpose, but the = decisions about whether to encapsulate TRILL in IP, and if so, how do = it, clearly need to be made in the TRILL WG, not through the individual = or independent submission paths (which is what tends to happen when = existing, nearly complete documents are declared out-of-scope for any = IETF WG). >=20 > Thanks, > Margaret >=20 >=20 >=20 >=20 >=20 >=20 >=20 From mrw@lilacglade.org Tue May 15 07:00: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 0540921F86C4 for ; Tue, 15 May 2012 07:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cpq7sG1b9UW for ; Tue, 15 May 2012 07:00:49 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2B921F86A4 for ; Tue, 15 May 2012 07:00:49 -0700 (PDT) Received: from [10.36.0.36] (pool-108-49-158-143.bstnma.fios.verizon.net [108.49.158.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 086E1203C0; Tue, 15 May 2012 09:56:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <2374D275-4D01-4031-99FA-85682AF19803@cisco.com> Date: Tue, 15 May 2012 10:00:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <963A148F-8D19-4F51-B14A-697A323096F5@lilacglade.org> References: <4FADB0E8.1090000@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5011CB0E0@xmb-sjc-214.amer.cisco.com> <201205151030.q4FAUuJg017425@cichlid.raleigh.ibm.com> <2374D275-4D01-4031-99FA-85682AF19803@cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , Donald Eastlake , trill@ietf.org Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 15 May 2012 14:00:51 -0000 On May 15, 2012, at 6:35 AM, Ralph Droms wrote: > draft-mrw-trill-over-ip is not out of scope, it's just not on the = current list of deliverables for the working group. The core charter of = the working group is still OK but the list of deliverables is more than = a year old. Some have been completed, some have seen some progress but = are late, some have not been addressed at all. It's appropriate for the = WG to revisit the list of deliverables, decide what documents are core = and revise the charter appropriately. I agree that the charter could use an update, and I support updating it! = :-) Personally, I would like to see the concept of a "TRILL over IP" = encapsulation added to the new charter, whether that eventually leads to = adopting my current draft, or deciding to go with another approach (like = TRILL over Ethernet over IP), as I think this is something that is = clearly needed for the deployment of TRILL in large campuses. I don't think we should allow ourselves to get stuck in situation where = we all agree that a problem is in-scope for the WG, but we can't adopt = or advance any drafts to address that problem, because we haven't = handled the bureaucratic end of things yet. So, let's get the charter = update done quickly. Is there anything I can do to help? Thanks! Margaret From internet-drafts@ietf.org Tue May 15 13:47:04 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 0FB5911E8083; Tue, 15 May 2012 13:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkoFr6smur6y; Tue, 15 May 2012 13:47:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B9621F87EA; Tue, 15 May 2012 13:47:03 -0700 (PDT) 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.02 Message-ID: <20120515204703.32237.2618.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 13:47:03 -0700 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-rbridge-channel-06.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, 15 May 2012 20:47:04 -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 o= f Links Working Group of the IETF. Title : TRILL: RBridge Channel Support Author(s) : Donald Eastlake Vishwas Manral Yizhou Li Sam Aldrin Dave Ward Filename : draft-ietf-trill-rbridge-channel-06.txt Pages : 27 Date : 2012-05-15 This document specifies a general channel mechanism for sending messages, such as BFD (Bidirectional Forwarding Detection) messages, between RBridges (Routing Bridges) and between RBridges and end stations in an RBridge campus through extensions to the TRILL (TRansparent Interconnection of Lots of Links) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-channel-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-channel-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-channel/ From d3e3e3@gmail.com Tue May 15 14:04: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 937AB21F85EE for ; Tue, 15 May 2012 14:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.685 X-Spam-Level: X-Spam-Status: No, score=-103.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pihhmJULgTG for ; Tue, 15 May 2012 14:04:18 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A594C21F85C0 for ; Tue, 15 May 2012 14:04:17 -0700 (PDT) Received: by qcsq13 with SMTP id q13so26214qcs.31 for ; Tue, 15 May 2012 14:04:17 -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 :content-type:content-transfer-encoding; bh=wnWmzCD5Gm/IGF3SdBKk5eOZvKg8qX8NxQG7Ee7imUo=; b=y0EIVomzBJhzE0xtOopVXZ50dgO2LEkcL4H4pvUQhKA1VMT8ggWODMwMzX1uHyQOMg uJoxkxPqVuxzrhmYwMRwI/P0As8e8ccPVd7RptfDSjoqVxn9w/4fsFdsz1ayyRHLG7dp J6SUIIhcrHQg3uUeBgN/iJLboNgTrdKa+seP0EAem8/4u3bIlgFjlNGU/duZJSnpbi1/ jqQQBYm644BPPF1FkTE+jfdTfLteCm8g+8cDPov5R7EP4YyyxO5KrddsjYHPBx+P5M7c XqQUd05bFOMy4o1sZ4bAUAefarsOs1xFEN7IrEWUeGB/HXzr/eUKmxE9zZ6TnQtW5gcQ y6dA== Received: by 10.50.41.165 with SMTP id g5mr346395igl.13.1337115856759; Tue, 15 May 2012 14:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Tue, 15 May 2012 14:03:56 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Tue, 15 May 2012 17:03:56 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [trill] Fwd: Nickname Selection 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, 15 May 2012 21:04:18 -0000 The following replies to Mahesh never made it to the TRILL WG list because they were sent during the few hours the list was down. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com ---------- Forwarded message ---------- From: Donald Eastlake Date: Tue, May 8, 2012 at 2:27 PM Subject: Re: [trill] Nickname Selection To: Radia Perlman Cc: Mahesh Akula , rbridge@postel.org Right, this is a typo. It is fixed in Section 4, Item 1, of the Clarifications and Corrections draft: http://www.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-03.txt 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, May 8, 2012 at 1:31 PM, Radia Perlman wrot= e: > That looks like a typo to me. =A0I would assume it should say: > >> Each RBridge is responsible for ensuring that its nickname or each >> =A0 =A0 =A0 of its nicknames is unique. =A0If RB1 chooses nickname x, an= d RB1 >> =A0 =A0 =A0 discovers, through receipt of an LSP for RB2 at any later ti= me, >> =A0 =A0 =A0 that RB2 has also chosen x, then the RBridge or pseudonode w= ith >> =A0 =A0 =A0 the numerically higher IS-IS ID (LAN ID) keeps the nickname,= or if > > > ********* > I think the above line should be > "the numerically higher priority keeps the nickname, or if" > > *********************** >> =A0 =A0 =A0 there is a tie in priority, the RBridge with the numerically >> =A0 =A0 =A0 higher IS-IS System ID keeps the nickname, and the other RBr= idge >> =A0 =A0 =A0 MUST select a new nickname. =A0This can require an RBridge w= ith a >> =A0 =A0 =A0 configured nickname to select a replacement nickname. >> > > On Tue, May 8, 2012 at 10:23 AM, Mahesh Akula = wrote: >> Hi Donald, >> >> In RFC 6325 3.7.3, i'm troubling understanding below statement, can you >> please help clarify? >>> Each RBridge is responsible for ensuring that its nickname or each >> =A0 =A0 =A0 of its nicknames is unique. =A0If RB1 chooses nickname x, an= d RB1 >> =A0 =A0 =A0 discovers, through receipt of an LSP for RB2 at any later ti= me, >> =A0 =A0 =A0 that RB2 has also chosen x, then the RBridge or pseudonode w= ith >> =A0 =A0 =A0 the numerically higher IS-IS ID (LAN ID) keeps the nickname,= or if >> =A0 =A0 =A0 there is a tie in priority, the RBridge with the numerically >> =A0 =A0 =A0 higher IS-IS System ID keeps the nickname, and the other RBr= idge >> =A0 =A0 =A0 MUST select a new nickname. =A0This can require an RBridge w= ith a >> =A0 =A0 =A0 configured nickname to select a replacement nickname. >> > >> First it says, node with higher IS-IS ID keeps the nickname, then it say= s, >> if there is a tie in priority then node with higher IS-IS system ID keep= s >> the nickname. =A0It gives meaning that IS-IS ID and nickname priority ar= e >> same?? >> >> >> Regards, >> >> Mahesh >> >> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> From nordmark@acm.org Wed May 16 08:23: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 3C34321F863B for ; Wed, 16 May 2012 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGcF+S6kIxfa for ; Wed, 16 May 2012 08:23:29 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 335D321F862B for ; Wed, 16 May 2012 08:23:29 -0700 (PDT) Received: from [10.0.0.143] (96-24-77-210.sfo.clearwire-wmx.net [96.24.77.210] (may be forged)) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q4GFNPQb011878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 May 2012 08:23:27 -0700 Message-ID: <4FB3C66B.7010005@acm.org> Date: Wed, 16 May 2012 08:23:23 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "trill@ietf.org" References: <4FB3C528.3000708@acm.org> In-Reply-To: <4FB3C528.3000708@acm.org> X-Forwarded-Message-Id: <4FB3C528.3000708@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Fwd: Publication requested: draft-ietf-trill-rbridge-channel-06 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, 16 May 2012 15:23:30 -0000 -------- Original Message -------- Subject: Publication requested: draft-ietf-trill-rbridge-channel-06 Date: Wed, 16 May 2012 08:18:00 -0700 From: Erik Nordmark To: iesg-secretary@ietf.org, "rdroms >> Ralph Droms" CC: Trill Chairs TRILL: RBridge Channel Support draft-ietf-trill-rbridge-channel-06 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard as indicated in the title page header. This document specifies how a channel (with associated code points) for carrying things like BFD and error reports for TRILL. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The TRILL base protocol standard [RFC6325] provides for TRILL Data messages and TRILL IS-IS messages. This document specifies a general channel mechanism for the transmission of other messages within an RBridge campus, such as BFD (Bidirectional Forwarding Detection, [RFC5880]) and error messages, between RBridges and end stations that are directly connected on the same link and between RBridges. This mechanism supports a requirement to be able to operate with minimal configuration. Working Group Summary There was consensus in the working group in favor of the document. Document Quality The document has been carefully reviewed in the WG and by the document shepherd. There are currently no known implementations of the channel mechanism, but BFD and error reporting will drive their implementation. Personnel Who is the Document Shepherd? Erik Nordmark Who is the Responsible Area Director? Ralph Droms (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Careful review of the whole document, including looking at dependencies to and from rbridge-bfd and rbridge-extension. (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? If so, describe the review that took place. No. (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? None. (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. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures on this document. (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? The consensus is reasonably broad. (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. No issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria apply. (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? If such normative references exist, what is the plan for their completion? There are normative references to draft-ietf-trill-rbridge-extension which is being advanced simultaneously and to draft-eastlake-isis-rfc6326bis whose move to an ISIS WG draft has been requested. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (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. The IANA considerations section lists the additional code points and multicast addresses, and also the three new sub-registries. The description of the sub-registries and their initial content is consistent with the rest of the docuument. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new subregistries do not require Expert Review. (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. No part of this draft is in a formal language. From russw@riw.us Wed May 16 11:48:49 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 B60DE21F85CF for ; Wed, 16 May 2012 11:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lgf3lqwq0Zc for ; Wed, 16 May 2012 11:48:49 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4E43F21F85C5 for ; Wed, 16 May 2012 11:48:49 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SUjHE-0002SF-NC for trill@ietf.org; Wed, 16 May 2012 11:48:48 -0700 Message-ID: <4FB3F68F.2030000@riw.us> Date: Wed, 16 May 2012 14:48:47 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: trill@ietf.org References: <4FADB0E8.1090000@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document? 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, 16 May 2012 18:48:49 -0000 > I don't understand the controversy. TRILL over IP is useful in > several cases which are actually clearly explained in this document. > And in general, the document seems well thought out and well written. > > So, I think it should be a WG document. Agreed --I support making this a working group doc. :-) Russ From nordmark@acm.org Wed May 16 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 2B74E11E8073 for ; Wed, 16 May 2012 17:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qntWhGdhdgqH for ; Wed, 16 May 2012 17:14:35 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4C72D11E8072 for ; Wed, 16 May 2012 17:14:35 -0700 (PDT) Received: from [10.21.67.101] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q4H0EW5B013900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 May 2012 17:14:33 -0700 Message-ID: <4FB442E8.5010300@acm.org> Date: Wed, 16 May 2012 17:14:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "trill@ietf.org" References: <4FB44210.6070306@acm.org> In-Reply-To: <4FB44210.6070306@acm.org> X-Forwarded-Message-Id: <4FB44210.6070306@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Fwd: Publication requested: draft-ietf-trill-clear-correct-03 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, 17 May 2012 00:14:36 -0000 -------- Original Message -------- Subject: Publication requested: draft-ietf-trill-clear-correct-03 Date: Wed, 16 May 2012 17:10:56 -0700 From: Erik Nordmark To: iesg-secretary@ietf.org, Ralph Droms CC: Trill Chairs TRILL: Clarifications, Corrections, and Updates draft-ietf-trill-clear-correct-03 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard as indicated in the title page header. That is needed since this document updates RFC 6325, RFC 6327, and RFC 6439 which are proposed standards. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327 and RFC 6439 provide clarifications and updates with respect to Adjacency and Appointed Forwarders. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. The clarifications, corrections, and updates cover many areas, but the most substantial ones are in the areas of: - Overloaded and/or Unreachable RBridges - Distribution Trees - Nickname selection - Maximum Transmission Unit Note that one change in this document (section 3.4) is not backward compatible with [RFC6325] but has nevertheless been adopted to reduce distribution tree changes resulting from topology changes. Working Group Summary There was consensus in the working group in favor of the document. Document Quality The document has been carefully reviewed in the WG and by the document shepherd. The document was forwarded to the IS-IS WG mailing list, which resulted in some additional improvements. Personnel Who is the Document Shepherd? Erik Nordmark Who is the Responsible Area Director? Ralph Droms (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Reviewed the document. (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? If so, describe the review that took place. The -00 version of the draft was forwarded to the IS-IS list which resulted in comments from Mike Shand which were incorporated in the draft. (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? None. (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. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures on this document. (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? The document has been discussed in the WG first as an individual draft and later as a WG draft with relatively broad participation. However, only a few commented on the actual WG last call. (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. While the abstract says "This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, RFC 6439." the id-nits tool generates comments to the effect that the "abstract doesn't seem to directly say this". I suspect that is because the above "updates" text doesn't follow some unstated formatting assumption in the id-nits tool. id-nits incorrectly generates a warning about a "non-RFC5735-compliant IPv4 addresses" for the text "... Section 4.6.2.1" (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria apply. (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? If such normative references exist, what is the plan for their completion? There is a normative reference to draft-eastlake-isis-rfc6326bis which is the formal definition of the IS-IS code points and formats. The plan is for that document to become an IS-IS WG draft and be reviewed in the IS-IS WG. That process has already been initiated. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (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. Verified that the three items in the IANA considerations section match the text in the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (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. No part of this draft is in a formal language. --- From d3e3e3@gmail.com Thu May 17 05:56: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 185C621F8629 for ; Thu, 17 May 2012 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.68 X-Spam-Level: X-Spam-Status: No, score=-103.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eapFTtUlDho0 for ; Thu, 17 May 2012 05:56:44 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABFD21F8627 for ; Thu, 17 May 2012 05:56:44 -0700 (PDT) Received: by yhq56 with SMTP id 56so2126942yhq.31 for ; Thu, 17 May 2012 05:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=GBT78b9pJZwnfM6DsRe/Y4i2VZHISZY+yHZEfEFgBt8=; b=kc3d2+lwvTP2e6MwSR9dhP3hJhxja9Y6D1bxsgh1tEyime0SrGdl3V6zsBP3b7KetK Vm7QD9THPQjzMRBX5rlgWWxDaRrDDAkWfe5BrMTmD/laWECJvL5Z0gkIqNyAGfzOvHZ7 W5lB3ES8nc7i5NaQBbz5Dm8dEqLHsr/qyrX39yiy+TaOafYa+OfoQB9TY42Ysi96Sbaa Bdu8kNOGxwFzWzTMAEgcIxGGAVIA5GK5kdQUToqxRhUEqe8wN2vsgPV8wX3RznNjOOEI PDLuuUdH4e6oqboqC7JOQBaixoT2xO8gR+b4cXTdwkCLzs5wvRhMI0KwnuVwEl0iT0h8 KfFA== Received: by 10.50.187.137 with SMTP id fs9mr13278084igc.50.1337259403640; Thu, 17 May 2012 05:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Thu, 17 May 2012 05:56:23 -0700 (PDT) From: Donald Eastlake Date: Thu, 17 May 2012 08:56:23 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [trill] will stop working June 8th 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, 17 May 2012 12:56:45 -0000 The TRILL WG mailing list has been for some time. The old WG name has been forwarding to so either one has actually worked. This has been causing some minor operational problems. This is a warning that on or about June 8th, will stop working and mail to that address will bounce. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From d3e3e3@gmail.com Sat May 19 13:55:56 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 11C7521F85AD for ; Sat, 19 May 2012 13:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.74 X-Spam-Level: X-Spam-Status: No, score=-101.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTo3HZSoXiJk for ; Sat, 19 May 2012 13:55:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1BB21F85AC for ; Sat, 19 May 2012 13:55:48 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so7133768obb.31 for ; Sat, 19 May 2012 13:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=k/H4yISDJCVDKHVW1PNuxEjnNKyOESzN7jW0myC5WiA=; b=Kt5PfbBRNSpX1V+dHCkOoW1M2W47KpNCLko1pCZCaYTj+5LBJQNdKvocIPL8dDtiq5 8sfFVTmM5Jy9gFc8SzVNlbzvouT6lXTcLcrcBeCX6hGw4/ucZPPpjjCy9z8yQ3qtad79 axzwrdu9nvCH58T2j3IJjXevxE8wpVoKDhPQ82aJfO3/IyXI8ZiykQhFpTf148pekY5c OF1XykpJFSR5UC5j9u6E400yEXMO8RaydwGNNfW9X/3Ur0x6jcX0Ieke6uQflfTqalE6 Rl12pQdW5Xyqx9l9Szy33N1HBNS7CinAWsM5VQPPCo611UsEEjRYZsRebteEnI65W2k8 xlAQ== Received: by 10.50.104.166 with SMTP id gf6mr3552824igb.35.1337460947770; Sat, 19 May 2012 13:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Sat, 19 May 2012 13:55:27 -0700 (PDT) From: Donald Eastlake Date: Sat, 19 May 2012 16:55:27 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [trill] Paris Minutes have been uploaded 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, 19 May 2012 20:55:56 -0000 Minutes from the Paris TRILL meeting have been uploaded. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From mgururam@gmail.com Tue May 22 03:11: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 105DA21F8552 for ; Tue, 22 May 2012 03:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+VvMG1a-0Qd for ; Tue, 22 May 2012 03:11:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 96BFE21F854D for ; Tue, 22 May 2012 03:11:02 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q4MAAWqI017055 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 22 May 2012 03:10:42 -0700 (PDT) Received: by wibhm6 with SMTP id hm6so3562737wib.3 for ; Tue, 22 May 2012 03:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WZK8SEhFLkXA2QSf2kNOV+JZgAtnMeAn07vlonKHPa0=; b=xCfjXTdGWlxge6DYOAdsa67r0u+7TGIPuWi832s4QprdFhUzd+WUh8k/4oH4VmW6om cxoTWikoMLmD6uIVqCpJ+nKsOMHjufGLVCPhpnwBHOEG+6CFOCNhOVOq4BOvy7DcxWXO cNQaDkTmPTGl66kuHR9t0P4A8dZ2LtG+9iWd7BArG4jLlPUtDkINjNWVzfwCgjhIQlyN 2nR81A0hAMk+t5+inMGodjNYs7DbPO/j1dfbPyDyHK8dMqn71UOVrV4L6nb4flQj/mA7 +U/DPOlGMtdb1Vk7ZWtv5lF+Bx8XV9qL56yjRTdHBSmEGSk7viORsnj9hgc7gFCtpRCn k9qg== MIME-Version: 1.0 Received: by 10.180.107.99 with SMTP id hb3mr33748036wib.0.1337681431883; Tue, 22 May 2012 03:10:31 -0700 (PDT) Received: by 10.223.7.24 with HTTP; Tue, 22 May 2012 03:10:31 -0700 (PDT) Date: Tue, 22 May 2012 15:40:31 +0530 Message-ID: From: gururam m To: rbridge@postel.org Content-Type: multipart/alternative; boundary=e89a8f23558191ede404c09d3acf X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mgururam@gmail.com Subject: [trill] RPF entries..RFC 6325 section 4.5.2 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, 22 May 2012 10:11:03 -0000 --e89a8f23558191ede404c09d3acf Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a query related to the RPF check from RFC 6325. Let us say a TRILL domain setup has about 6 RBridges each with a single nickname and 6 multicast trees are computed by each RBridge in the TRILL domain and the trill domain setup is as shown below. RB1-------RB2--------RB3 | | | | | | RB4------RB5----------RB6 As per my understanding each RB will have RPF entries that are equal to the ingress interfaces on that RB. For e.g RB1 has two interfaces hence it has two RPF entries and RB2,RB5 will have 3 RPF entries since it has 3 interfaces or to state the number of RPF entries on each RBridges depends on the number of ports that are part of the multicast trees on that particular RBridge. Please correct me if my understanding is not correct. Regards Ram --e89a8f23558191ede404c09d3acf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0=A0=A0=A0 I have a query related to the RPF check from RFC 632= 5.

Let us say a TRILL domain setup has about 6 RBridges each with a= single nickname and 6 multicast trees are computed by each RBridge in the = TRILL domain and the trill domain setup is as shown below.

RB1-------RB2--------RB3
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 |
=A0 | =A0 =A0 =A0=A0=A0=A0=A0=A0=A0 |=A0=A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0= RB4------RB5----------RB6

As per my understanding each RB will have= RPF entries that are equal to the ingress interfaces on that RB. For e.g R= B1 has two interfaces hence it has two RPF entries and RB2,RB5 will have 3 = RPF entries since it has 3 interfaces or to state the number of RPF entries= on each RBridges depends on the number of ports that are part of the multi= cast trees on that particular RBridge.

Please correct me if my understanding is not correct.

RegardsRam

--e89a8f23558191ede404c09d3acf-- From mgururam@gmail.com Tue May 22 03:14: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 322D821F85C6 for ; Tue, 22 May 2012 03:14:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BouWGXxie0o for ; Tue, 22 May 2012 03:14:32 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78A1F21F85A5 for ; Tue, 22 May 2012 03:14:32 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4061045wgb.13 for ; Tue, 22 May 2012 03:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3BAgNB5ovqavccndzSo9BV/BUDHRdLqoL+UMReyt4gM=; b=uwVV5vub6G/hWwwG81svuPVXMshotjDXZRltkSn0mt5DoEsRDLnH25f5s3LEbRr7Mc BvhZ1rsy6UPcyLrTFn1rRt2K+77WHwBO8UNqaFxPSuCAaYEJfkY6KRdWZy6rQq9no6A3 54cW9e1CbDcRLjNxEMY4IJb+Z5soshcWP9tRWXXjh13c/Yc1TbYxFlQ0vNGEHnIM/aDN 5XDVj8Y2ErtCLEGEevQZQ4BnMsQVvfSQrvNmWzmzwBvHTAAvyk153qUY6tZAaGRx5dis t4ETGqJZBeO1oGr530krWGFlJGhuT6WnHhHuxzmgLRIVqBgUCBtmd6z2YsjPVKf58gKY XOzA== MIME-Version: 1.0 Received: by 10.216.199.1 with SMTP id w1mr15002189wen.19.1337681671646; Tue, 22 May 2012 03:14:31 -0700 (PDT) Received: by 10.223.7.24 with HTTP; Tue, 22 May 2012 03:14:31 -0700 (PDT) Date: Tue, 22 May 2012 15:44:31 +0530 Message-ID: From: gururam m To: trill@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7e4e7dc6ccc04c09d48af Subject: [trill] RPF entries ..RFC 6325 section 4.5.2 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, 22 May 2012 10:14:33 -0000 --0016e6d7e4e7dc6ccc04c09d48af Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a query related to the RPF check from RFC 6325. Let us say a TRILL domain setup has about 6 RBridges each with a single nickname and 6 multicast trees are computed by each RBridge in the TRILL domain and the trill domain setup is as shown below. RB1-------RB2--------RB3 | | | | | | RB4------RB5----------RB6 As per my understanding each RB will have RPF entries that are equal to the ingress interfaces on that RB. For e.g RB1 has two interfaces hence it has two RPF entries and RB2,RB5 will have 3 RPF entries since it has 3 interfaces or to state the number of RPF entries on each RBridges depends on the number of ports that are part of the multicast trees on that particular RBridge. Please correct me if my understanding is not correct. Regards Ram --0016e6d7e4e7dc6ccc04c09d48af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0=A0=A0=A0 I have a query related to the RPF check from RFC 632= 5.

Let us say a TRILL domain setup has about 6 RBridges each with a single=20 nickname and 6 multicast trees are computed by each RBridge in the TRILL domain and the trill domain setup is as shown below.

RB1-------RB2--------RB3
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 |
=A0 | =A0 =A0 =A0=A0=A0=A0=A0=A0=A0 |=A0=A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0= RB4------RB5----------RB6

As per my understanding each RB will have RPF entries that are equal to=20 the ingress interfaces on that RB. For e.g RB1 has two interfaces hence=20 it has two RPF entries and RB2,RB5 will have 3 RPF entries since it has 3 interfaces or to state the number of RPF entries on each RBridges=20 depends on the number of ports that are part of the multicast trees on=20 that particular RBridge.

Please correct me if my understanding is not correct.

RegardsRam --0016e6d7e4e7dc6ccc04c09d48af-- From d3e3e3@gmail.com Tue May 22 06:23: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 EDC7721F8505 for ; Tue, 22 May 2012 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4RT5DfCHFnf for ; Tue, 22 May 2012 06:23:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3AE21F84E6 for ; Tue, 22 May 2012 06:23:01 -0700 (PDT) Received: by yhq56 with SMTP id 56so6424684yhq.31 for ; Tue, 22 May 2012 06:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jt3NBjG4/j1P3cT++4yBRDjP4X6ukU0miJu8f7pHQSo=; b=ckWd63Ph1bBa4ItoOthl56K5g7znP7OjNID5dVvRx6ES2M6Nwe9GnIc9bO6E65KgnZ tfDSRpVz7WzSKfDVmOiXwNSmuyA3BH5YsEuqnbwVBtrQgSLr0kdS1oP5SG+pieCwQO3i +CKvgiKwbQ0JsEXkxg8BNIIEC9kwYq5AhctQK3vKdTRLkXjP/T/W3fOghNQCVwbJh2mn sjkSycEEuw1uJfccjW80sfC7C7uTqJvXwoSmwDXIDFkHkI3zVTzdQpwThEoAQdUoo9bT vwmVh74G6M8dnGe5056w9W6gs2rP2QADSyggTJzsQQIVQO/QDy4CG9Pknv0tO3MWmZ/x abyQ== Received: by 10.50.140.3 with SMTP id rc3mr9367146igb.58.1337692980526; Tue, 22 May 2012 06:23:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Tue, 22 May 2012 06:22:40 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Tue, 22 May 2012 09:22:40 -0400 Message-ID: To: gururam m Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trill@ietf.org Subject: Re: [trill] RPF entries ..RFC 6325 section 4.5.2 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, 22 May 2012 13:23:02 -0000 Hi, On Tue, May 22, 2012 at 6:14 AM, gururam m wrote: > Hi, > I have a query related to the RPF check from RFC 6325. > > Let us say a TRILL domain setup has about 6 RBridges each with a single > nickname and 6 multicast trees are computed by each RBridge in the TRILL > domain and the trill domain setup is as shown below. > > RB1-------RB2--------RB3 > | | | > | | | > RB4-------RB5--------RB6 > > As per my understanding each RB will have RPF entries that are equal > to the ingress interfaces on that RB. I think you are talking about TRILL Data traffic so I would avoid using the word "ingress" here. In TRILL "ingress" normally refers to receiving native traffic, not TRILL Data frames. > For e.g RB1 has two interfaces hence it has two RPF entries and RB2, > RB5 will have 3 RPF entries since it has 3 interfaces or to state > the number of RPF entries on each RBridges depends on the number of > ports that are part of the multicast trees on that particular > RBridge. TRILL does not constrain how the RPF (Reverse Path Forwarding) Check entries are organized. If you think about it as a lookup under the triple { tree number; port; ingress RBridge nickname } that returns a boolean, then there are a lot more entries than you are talking about. In this case (number of ports)*(number of trees)*(number of possible ingress RBridges) or (number of ports)*30. If you think about it as a lookup under the double { tree number; ingress RBridge nicknme } that returns the expected receiving port that you then compare with the actul receiving port for the check, then there are 30 entries at each RBridge in your example. (This assumes that no RBridge is announcing the trees it is using as a subset of the computed trees. If one does, it reduces the RPF Check information.) Other methods are possible. 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=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Please correct me if my understanding is not correct. > > Regards > Ram From dai.xuehui@zte.com.cn Tue May 22 20:33: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 B921621F854B for ; Tue, 22 May 2012 20:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.959 X-Spam-Level: X-Spam-Status: No, score=-97.959 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad4dpuI4ErFo for ; Tue, 22 May 2012 20:33:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5005921F851C for ; Tue, 22 May 2012 20:33:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 28620316744263; Wed, 23 May 2012 10:47:59 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 33453.316744263; Wed, 23 May 2012 11:33:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q4N3X9rU009300 for ; Wed, 23 May 2012 11:33:09 +0800 (GMT-8) (envelope-from dai.xuehui@zte.com.cn) To: trill@ietf.org MIME-Version: 1.0 X-KeepSent: 89E79485:7ACDAFA9-48257A07:0012895E; 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, 23 May 2012 11:33:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-23 11:33:10, Serialize complete at 2012-05-23 11:33:10 Content-Type: multipart/related; boundary="=_related 0013837648257A07_=" X-MAIL: mse01.zte.com.cn q4N3X9rU009300 Subject: [trill] trill ecmp utilization 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, 23 May 2012 03:33:20 -0000 This is a multipart message in MIME format. --=_related 0013837648257A07_= Content-Type: multipart/alternative; boundary="=_alternative 0013837848257A07_=" --=_alternative 0013837848257A07_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBhIHByb2JsZW0gb24gdGhlIGRlZmluaXRpb24gb2YgRUNNUCAgdXRpbGl6 YXRpb24gaW4gVFJJTEwgT0FNIFJlcSANCmRyYWZ0LCB3aGljaCBzYWlkIHRoYXQ6ICAiT0FNIE1B WSBwcm92aWRlIGZ1bmN0aW9uYWxpdHkgdG8gbW9uaXRvciANCnV0aWxpemF0aW9uIG9mIEVDTVAg cGF0aHMgdG8gc3BlY2lmaWVkIGRlc3RpbmF0aW9uIFJCcmlkZ2VzLiBVdGlsaXphdGlvbiANCmlz IGRlZmluZWQgYXMgZGlzdHJpYnV0aW9uIG9mIHRyYWZmaWMgb3ZlciBkaWZmZXJlbnQgRUNNUCBt ZW1iZXJzLiINCg0KDQpHaXZlbiB0aGUgZmlndXJlIGJlbG93LCBSQjEgaXMgaW5ncmVzcyBSYnJp ZGdlIGFuZCBSQjkgaXMgZWdyZXNzIFJicmlkZ2UsIA0KUkIyIGhhcyB0aHJlZSBkb3duc3RyZWFt IFJCcyhSQjMsIFJCNCBhbmQgUkI1KSB0aGF0IGNhbiByZWFjaCBSQjksIGFuZCBSQjYgDQpoYXMg dHdvIGRvd25zdHJlYW0gUkJzo6hSQjcgYW5kIFJCOKOpdG8gUkI5LCBzbyB0aGVyZSBhcmUgYWxs IDYgRUNNUCBwYXRocyANCmZyb20gUkIxIHRvIFJCOS4NCg0KIFRoZW4sIG15IHF1ZXN0aW9uIGlz o7oNCkluIHRoZSBjdXJyZW50IHRleHQsIGRvZXMgIkVDTVAgbWVtYmVyIiBtZWFuIG9uZSBzcGVj aWZpYyBwYXRoIGZyb20gUkIxIHRvIA0KUkI5KHN1Y2ggYXMgUkIxLVJCMi1SQjMtUkI2LVJCNy1S QjkpPyBvciBvbmUgc3BlY2lmaWMgbm9kZShzdWNoIGFzIFJCMik/DQoNCg0KDQoNClBsZWFzZSBj b3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuDQoNCg0KQmVzdCBS ZWdhcmQsDQpYdWVodWkNCg0KDQoNCg0KDQoNCg0K --=_alternative 0013837848257A07_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZlIGEgcHJvYmxlbSBvbiB0aGUg ZGVmaW5pdGlvbiBvZg0KRUNNUCAmbmJzcDt1dGlsaXphdGlvbiBpbiBUUklMTCBPQU0gUmVxIGRy YWZ0LCB3aGljaCBzYWlkIHRoYXQ6IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPiZuYnNwOyZxdW90 O09BTQ0KTUFZIHByb3ZpZGUgZnVuY3Rpb25hbGl0eSB0byBtb25pdG9yIHV0aWxpemF0aW9uIG9m IEVDTVAgcGF0aHMgdG8gc3BlY2lmaWVkDQpkZXN0aW5hdGlvbiBSQnJpZGdlcy4gVXRpbGl6YXRp b24gaXMgZGVmaW5lZCBhcyBkaXN0cmlidXRpb24gb2YgdHJhZmZpYw0Kb3ZlciBkaWZmZXJlbnQg RUNNUCBtZW1iZXJzLiZxdW90OzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTM+R2l2ZW4gdGhlIGZpZ3VyZSBiZWxvdywgUkIxIGlzIGluZ3Jlc3MgUmJyaWRnZSBh bmQNClJCOSBpcyBlZ3Jlc3MgUmJyaWRnZSwgUkIyIGhhcyB0aHJlZSBkb3duc3RyZWFtIFJCcyhS QjMsIFJCNCBhbmQgUkI1KSB0aGF0DQpjYW4gcmVhY2ggUkI5LCBhbmQgUkI2IGhhcyB0d28gZG93 bnN0cmVhbSBSQnOjqFJCNyBhbmQgUkI4o6l0byBSQjksIHNvDQp0aGVyZSBhcmUgYWxsIDYgRUNN UCBwYXRocyBmcm9tIFJCMSB0byBSQjkuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mz4mbmJzcDtUaGVuLCBteSBxdWVzdGlvbiBpc6O6PC9mb250PjwvdHQ+DQo8YnI+PGZv bnQgc2l6ZT0zPkluIHRoZSBjdXJyZW50IHRleHQsIGRvZXMgJnF1b3Q7RUNNUCBtZW1iZXImcXVv dDsgbWVhbg0Kb25lIHNwZWNpZmljIHBhdGggZnJvbSBSQjEgdG8gUkI5KHN1Y2ggYXMgUkIxLVJC Mi1SQjMtUkI2LVJCNy1SQjkpPyBvcg0Kb25lIHNwZWNpZmljIG5vZGUoc3VjaCBhcyBSQjIpPzwv Zm9udD4NCjxicj4NCjxicj48aW1nIHNyYz1jaWQ6XzFfMDcwNDhENDAwNzA0OEFFQzAwMTM4Mzcx NDgyNTdBMDc+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlBsZWFzZSBjb3JyZWN0IG1l IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QuPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTM+QmVzdCBSZWdhcmQsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mz5YdWVodWk8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0013837848257A07_=-- --=_related 0013837648257A07_= Content-Type: image/gif Content-ID: <_1_07048D4007048AEC0013837148257A07> Content-Transfer-Encoding: base64 R0lGODlhVQLTAOcAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAVQLTAEAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkygFBkg5cCXLlzBjJgzgkmVN mThz6tzJU+NNlD97Ch1KkSbMoESTKl3KtCPSgytrupz6FKHRplixXmUYVaXXrw+rZh1LtizPrTLF qlRrtq1bgmzfyp1LV2FcsCnvctVb1y1aoH0DC/bLd3DEv4aXIraZuLHjvI+FLo6McbLZwpQzz7Ws mSznwZ874xVNWnLp0y21YkYNcXVJ15Xbwr4Yemjtj7M9H83N2ufu0Sd5vxQ+8bbp4ZqJSzTeO6Ty w3xpXpUuFXpUo9Sza98OQHr37eCxh//P7pD6d7TGx5P3rl79+fbcvTc0/x5ua/Hw4+PPf70/f/Pu zceefPKV91xzIgFYIHPTHSXbb2Uxx9GBSlFoIIJpQWjhfA8Ot2GCHy4UYk8jzlQihjNp6OBlEHp2 IlTJtYgiZB7OKNuLNuKEY1E7iiZhjkCmGCRTP2bV1YQ9klTkkEwWl+SMBUK52pKxVfRkk1julSVX Wx5m4ooiXtnlmDxKSeZIVNLWkphntumcWmla5FqcbrJY552ZDQhmQXTiieSefgba2G1TfXVka4Im quiiTfVZHKOQRiqpjIBNaumlmG7k6HKZdurpp0IyBmpaV7I56qelnhrTpl6q6qpJqb7/mlesstbq EauIromrrTmZymudYtF636/DIkfssUsK+yeyyh7b6a6oRZmotET56ixd0AJrI7WDWnttht9yWle2 jpEbLpre2sptcOn6aG2zWlGqGqDlyouqvZV2aa5h7SaI77MqctidocCJ2KHAR1YXVr/lNTzww9qF FaPDCSss4Kt6FVpoahc+LGqE/1YIb2KlMuxjwB/rVmOEI/MbMqYln2uVzDSCC+q+NGtqMp44g+jn zjln1LObQ9vGW9HOBb0t0H0xLfLFxi6sNM9jIt3cTYRCDBaDM099r9T/RTwgf0I7rarZXrO2mNUc C5w22wWnfS7cHtMt9914f4kwwRu7/53334CTSm/ghBfuc9SGJ6542WO/l995joO3+Jdh9xc52ZPL 2vLidKOd+WObK9755xgPnvnopJ9t+uSopz7qXRtrHDeMrq9FsdZt+107wHtr3TeX9J0Ou1d9F+b5 7tjOjqbehbeO/KJrrw7V8UE6//ydoYUe5tTWX6+vuCmXHW733lc/G/XQ8Wp3+UCuL9e6kLpPO/ul oe9ioPIXRT+/9geWv2L9093+5vWtAPrEgEIbIIn+R7RyIVBJCqyZ6PrHwLc80FkVvBnDMsi/dmmv Wi+r1gfHFUJLxcxjEhzLCe+HONCVcFInHOFxbGI/8pHshZKKofQqhMOzyHAzPYwfyv9SaKQg6sSG LluZ6lYGu60sqFUgMxBVgtLEyzRRKg2KzsQENEUUSs1VGZtOg7xol9+ZyD9i1KKd9oJGXVWRZVyM nH0klicpOm4t0bng++xIHtt98YdnMWKvAGnBHcJsiFnSI7supcg2+aqRryETB0FTvkcaEoRKVCEh /XJJE2qocpAbG+ZYJrb9PK5x3CFl2EK5SviBBpWtNOV4MAZLNMLncpKT2yQ9tcFMuTKCHROeJqEH yQIGbpdOAoks28PKyoWomG8LGjKdohwklgmYJPrVNNkFG2vSEZuNQtU2j5jHThoEmuwb5xqxBycZ ohOc3yHaOwPJp+ENLHbK41MZ4en/riH9EobXuR0+yRiqNfETQepU5jwtGKuFHlRObwzfchyKrU0+ NFr7LCL3LHrRq2EtdAllkjc7mkjrhVRfHCUpijp3UpW6dFzDUxjWvvnSmsIspTbN6fdaqNOeKgqn Pg2q+oRKVPyZs6hIbV8sbcnMfyb1qVCNqlQ1dVTAjXSqMMSqPrWqtqr+7apcZRRFhxrW0wB1o14t Kwl5+jmwqlUwZ1WaW9/atLTiba50TR5bhbnXvN6QjVPEYq5qVxsFOdGp+fSr/+yIx63Ck1BpdKxi oXQ73CVWV4S1Z8JyJ8DJJjFMtjSok8aqtriIcqaeXakNSUsavKa2UWOUqGStGtfX/w5ytsEJ5l1r a9tMzlG2Bruba3t7xOACt7MyGy5xSwjUlpbWrstdJE3zlcC58Ta6OntUX+VUwOtilzbdhC6HWAtb 8X6XquBdpntOe8vXkDcp/2mmM+tz3u3607lA3Al+kbrfQPY3XvB97/7+K0IBv4mF9QUvIwlsM8Ik eKIaZDCsXvlgLWnOwMj1n4R3h2EAYmjDxapvhzUp4BGLlrgg7kyKu5ajFXsNseODpokZq1YXezS/ 8tTqjPNEvR0f8KmHyqxiACpUG0vyf0a2TTyLy974NjliVlyvek/Zx/s5s5aPo8wsn7zlKfvYQ5Lj 8i3Ze1ncHGxWVjSvCgX5U0Tmdv+dQKmhd+HL5mm5ecJwli6CiTgoNf/szpHMM6zk7GcA07B0TJTk kRlZyV4Vms/uTbN9F+vbmwHan4v2pPcsOWlMHhqOnV7rp5f46TlDsNLl9c106xXqrCa6dxoz3pmD u1nLbg/UXMIdVQYbmYwRz4/pAyMdN2vGjMaUY8U2rsrGSzDOZnTPdqmbH9WoZYnFLnhQIzXwmg3j 2NKa21Bcdq5rbTxCw3prvHahQIEdRkTv7XftJmigozjqYbYax2gW9quPO2RUE8nUSvY370r9aOrG WdL8hmudBaXDe9Oz3kYC+Azzre2Dy/vU9Ka4uA3Oaohbet+QJtLCR26lLWr8dST/V1PVvpzhabFc xcme98b1bO+EU9rjX8M5x5uUZDOb8OXJiTnGZz5ohIeckgL3ZYuu7GVm3mg9TZdyeJ7u5KjPUsuG na+Yq/w6w+KSyu19MdDr562eS8bsPx97r3eGdh0lVe38Uw3crxnVuTP04jxkuN0Z3jwG790qfydm 3mSs0ILXM7WBf3i3qGn4Mpc18asiu/gcrmzsQh7Pvdkvcdr+VXV9GcaHp3zoKwyXy//4vkR3GOmZ 9/OVf9Hm81v9reNn+hOzfue3l33Lz8R5JQVrhLV/W/CXTPvpcdE/pU+38XVfmcv3vsHEB21jm53h 5z927kEeeNbuCW7VJ5/5B25fyq2cetrv6w/8kUbo8HHT0PULuX7dXZX7n5ee5s7/cLBHf/pnf/Rc J1fi+gdhuYd5IUYzyhWAb/IUP2R9MNV4CFhd5td/kCNcAPiAVvIuAyh8DmiBP9Y9DAg6FciBCoY4 H7h2YPd1Y1aCb4U69yeC0QRYeBRYq+aCNMh/ZYRFXTSDNbiD56RZ1Id3uMWDQmh7ZyRHwLZ7Q0iD B5iEzKeCTBhWS/iEq+eEUohVUViFD3aFWChiIbiFfqWFXmh5XRiGK6h1Vjd1ZHgSAQEAOw== --=_related 0013837648257A07_=-- From aldrin.ietf@gmail.com Tue May 22 22:32:56 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 7D3AF21F8597 for ; Tue, 22 May 2012 22:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwJaeBuL5Lkr for ; Tue, 22 May 2012 22:32:56 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0751A21F8587 for ; Tue, 22 May 2012 22:32:55 -0700 (PDT) Received: by dacx6 with SMTP id x6so9427589dac.31 for ; Tue, 22 May 2012 22:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=LaagFGfgWeaX/3CFs+gGBibxiS1WvwDPpqDp/j0PxuA=; b=JB8mNUgmo9VTnchJ44zKCMheEZuJMLZpjcUK2g6BmGppY48xH8LLOQaFgH4HDiEt1G 0t72Av85EahDJ1YWpY9plF+4zzv+mc3EDDDxxwMjsleNEOwfsEKzs2rQx8tSy5WxO4Qz Z2sgsB6qXRodZNlGwCsFlxcxwMQg1a0+j+CKmFTL0kjIValx6ox0/Glr31PZSj5noHQY idQ9PvM1x7crQ/kZ3R4agVPhy7Mzi8LXFjZasITMSD6nTLM5zLsREmUNf4gjp5N6osMX qxQAlwT+UWxvikXYVSIb+O73gu6kojSm23uQ9TDgxnnrP38XxKkx69ycu7dkuf11dLn0 4I0w== Received: by 10.68.191.106 with SMTP id gx10mr6179581pbc.161.1337751174694; Tue, 22 May 2012 22:32:54 -0700 (PDT) Received: from [10.90.165.181] (mobile-166-205-136-140.mycingular.net. [166.205.136.140]) by mx.google.com with ESMTPS id ru4sm632029pbc.66.2012.05.22.22.32.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 May 2012 22:32:53 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-26F0F191-8966-44C8-8E31-DF8724494DE6 Message-Id: <7CFD7C0D-15DA-4D35-A8C4-643996D9529B@gmail.com> X-Mailer: iPhone Mail (9B206) From: Sam Aldrin Date: Tue, 22 May 2012 22:32:44 -0700 To: "dai.xuehui@zte.com.cn" Cc: "trill@ietf.org" Subject: Re: [trill] trill ecmp utilization 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, 23 May 2012 05:32:56 -0000 --Apple-Mail-26F0F191-8966-44C8-8E31-DF8724494DE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is per path, not node. Sam Sent from my iPhone On May 22, 2012, at 8:33 PM, dai.xuehui@zte.com.cn wrote: >=20 > Hi,=20 >=20 > I have a problem on the definition of ECMP utilization in TRILL OAM Req d= raft, which said that: "OAM MAY provide functionality to monitor utilizatio= n of ECMP paths to specified destination RBridges. Utilization is defined as= distribution of traffic over different ECMP members."=20 >=20 >=20 > Given the figure below, RB1 is ingress Rbridge and RB9 is egress Rbridge, R= B2 has three downstream RBs(RB3, RB4 and RB5) that can reach RB9, and RB6 ha= s two downstream RBs=EF=BC=88RB7 and RB8=EF=BC=89to RB9, so there are all 6 E= CMP paths from RB1 to RB9.=20 >=20 > Then, my question is=EF=BC=9A=20 > In the current text, does "ECMP member" mean one specific path from RB1 to= RB9(such as RB1-RB2-RB3-RB6-RB7-RB9)? or one specific node(such as RB2)?=20= >=20 > =20 >=20 >=20 > Please correct me if my understanding is not correct.=20 >=20 >=20 > Best Regard,=20 > Xuehui=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill --Apple-Mail-26F0F191-8966-44C8-8E31-DF8724494DE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It is per path, not node.<= /div>

Sam

Sent from my iPhone

On May= 22, 2012, at 8:33 PM, dai.xuehui@z= te.com.cn wrote:

=
Hi,

I have a problem on the definition o= f ECMP  utilization in TRILL OAM Req draft, which said that: <= font size=3D"3"> "OAM MAY provide functionality to monitor utilization of ECMP paths to specified destination RBridges. Utilization is defined as distribution of traffic over different ECMP members."


Given the figure below, RB1 is ingress Rbridge and RB9 is egress Rbridge, RB2 has three downstream RBs(RB3, RB4 and RB5) that can reach RB9, and RB6 has two downstream RBs=EF=BC=88RB7 and RB8=EF=BC=89to= RB9, so there are all 6 ECMP paths from RB1 to RB9.

 Then, my question is=EF=BC=9A
In the current text, does "ECMP member" mean one specific path from RB1 to RB9(such as RB1-RB2-RB3-RB6-RB7-RB9)? or one specific node(such as RB2)?

<mime-attachment.gif>


Please correct me if my understanding is not correct.


Best Regard,
Xuehui






____________________= ___________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mai= lman/listinfo/trill
= --Apple-Mail-26F0F191-8966-44C8-8E31-DF8724494DE6-- From dai.xuehui@zte.com.cn Wed May 23 01:14:00 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 B3BD121F86A3; Wed, 23 May 2012 01:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.176 X-Spam-Level: X-Spam-Status: No, score=-95.176 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEGOSvxnwb4e; Wed, 23 May 2012 01:13:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A07F121F84CE; Wed, 23 May 2012 01:13:57 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 621291455586978; Wed, 23 May 2012 16:10:22 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 33453.2327679635; Wed, 23 May 2012 16:13:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q4N8DYeY093648; Wed, 23 May 2012 16:13:34 +0800 (GMT-8) (envelope-from dai.xuehui@zte.com.cn) In-Reply-To: <7CFD7C0D-15DA-4D35-A8C4-643996D9529B@gmail.com> To: Sam Aldrin MIME-Version: 1.0 X-KeepSent: 269CA915:1D600583-48257A07:002C8F2A; 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, 23 May 2012 16:13:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-23 16:13:36, Serialize complete at 2012-05-23 16:13:36 Content-Type: multipart/alternative; boundary="=_alternative 002D2F6448257A07_=" X-MAIL: mse01.zte.com.cn q4N8DYeY093648 Cc: trill-bounces@ietf.org, "trill@ietf.org" Subject: Re: [trill] trill ecmp utilization 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, 23 May 2012 08:14:00 -0000 This is a multipart message in MIME format. --=_alternative 002D2F6448257A07_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2Fto6wgDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4NCg0Kd2l0aCBlY21wIHV0aWxpemF0 aW9uIG9mIGFsbCBlY21wIHBhdGhzLCB5b3UgbWF5IGZpbmQgdGhhdCBhIGhhc2ggDQpwb2xhcml6 YXRpb24gaGFwcGVucywgdGhlbiB3aGF0IHdpbGwgeW91IGRvIGFib3V0IHRoaXM/DQoNCg0KQmVz dCByZWdhcmRzLA0KWHVlaHVpDQoNCg0KDQoNCg0KDQpTYW0gQWxkcmluIDxhbGRyaW4uaWV0ZkBn bWFpbC5jb20+IA0Kt6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0wNS0yMyAx MzozMg0KDQrK1bz+yMsNCiJkYWkueHVlaHVpQHp0ZS5jb20uY24iIDxkYWkueHVlaHVpQHp0ZS5j b20uY24+DQqzrcvNDQoidHJpbGxAaWV0Zi5vcmciIDx0cmlsbEBpZXRmLm9yZz4NCtb3zOINClJl OiBbdHJpbGxdIHRyaWxsIGVjbXAgdXRpbGl6YXRpb24NCg0KDQoNCg0KDQoNCkl0IGlzIHBlciBw YXRoLCBub3Qgbm9kZS4NCg0KU2FtDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gTWF5IDIy LCAyMDEyLCBhdCA4OjMzIFBNLCBkYWkueHVlaHVpQHp0ZS5jb20uY24gd3JvdGU6DQoNCg0KSGks IA0KDQpJIGhhdmUgYSBwcm9ibGVtIG9uIHRoZSBkZWZpbml0aW9uIG9mIEVDTVAgIHV0aWxpemF0 aW9uIGluIFRSSUxMIE9BTSBSZXEgDQpkcmFmdCwgd2hpY2ggc2FpZCB0aGF0OiAgIk9BTSBNQVkg cHJvdmlkZSBmdW5jdGlvbmFsaXR5IHRvIG1vbml0b3IgDQp1dGlsaXphdGlvbiBvZiBFQ01QIHBh dGhzIHRvIHNwZWNpZmllZCBkZXN0aW5hdGlvbiBSQnJpZGdlcy4gVXRpbGl6YXRpb24gDQppcyBk ZWZpbmVkIGFzIGRpc3RyaWJ1dGlvbiBvZiB0cmFmZmljIG92ZXIgZGlmZmVyZW50IEVDTVAgbWVt YmVycy4iIA0KDQoNCkdpdmVuIHRoZSBmaWd1cmUgYmVsb3csIFJCMSBpcyBpbmdyZXNzIFJicmlk Z2UgYW5kIFJCOSBpcyBlZ3Jlc3MgUmJyaWRnZSwgDQpSQjIgaGFzIHRocmVlIGRvd25zdHJlYW0g UkJzKFJCMywgUkI0IGFuZCBSQjUpIHRoYXQgY2FuIHJlYWNoIFJCOSwgYW5kIFJCNiANCmhhcyB0 d28gZG93bnN0cmVhbSBSQnOjqFJCNyBhbmQgUkI4o6l0byBSQjksIHNvIHRoZXJlIGFyZSBhbGwg NiBFQ01QIHBhdGhzIA0KZnJvbSBSQjEgdG8gUkI5LiANCg0KIFRoZW4sIG15IHF1ZXN0aW9uIGlz o7ogDQpJbiB0aGUgY3VycmVudCB0ZXh0LCBkb2VzICJFQ01QIG1lbWJlciIgbWVhbiBvbmUgc3Bl Y2lmaWMgcGF0aCBmcm9tIFJCMSB0byANClJCOShzdWNoIGFzIFJCMS1SQjItUkIzLVJCNi1SQjct UkI5KT8gb3Igb25lIHNwZWNpZmljIG5vZGUoc3VjaCBhcyBSQjIpPyANCg0KPG1pbWUtYXR0YWNo bWVudC5naWY+IA0KDQoNClBsZWFzZSBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMg bm90IGNvcnJlY3QuIA0KDQoNCkJlc3QgUmVnYXJkLCANClh1ZWh1aSANCg0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWls aW5nIGxpc3QNCnRyaWxsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyaWxsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KDQoNCg== --=_alternative 002D2F6448257A07_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNhbaOsIDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3VyIHJl cGx5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+d2l0 aCBlY21wIHV0aWxpemF0aW9uIG9mIGFsbCBlY21wIHBhdGhzLA0KeW91IG1heSBmaW5kIHRoYXQg YSBoYXNoIHBvbGFyaXphdGlvbiBoYXBwZW5zLCB0aGVuIHdoYXQgd2lsbCB5b3UgZG8gYWJvdXQN CnRoaXM/PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5CZXN0IHJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5YdWVodWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+U2FtIEFsZHJpbiAmbHQ7YWxkcmluLmlldGZAZ21h aWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+t6K8/sjLOiAmbmJzcDt0cmlsbC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDUtMjMgMTM6MzI8L2ZvbnQ+DQo8dGQgd2lk dGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7ZGFpLnh1ZWh1 aUB6dGUuY29tLmNuJnF1b3Q7ICZsdDtkYWkueHVlaHVpQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mcXVvdDt0cmlsbEBpZXRmLm9yZyZxdW90OyAmbHQ7dHJpbGxAaWV0Zi5vcmcm Z3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3RyaWxsXSB0cmlsbCBlY21wIHV0aWxpemF0aW9u PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkl0 IGlzIHBlciBwYXRoLCBub3Qgbm9kZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlNh bTxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z Pjxicj4NCk9uIE1heSAyMiwgMjAxMiwgYXQgODozMyBQTSwgPC9mb250PjxhIGhyZWY9bWFpbHRv OmRhaS54dWVodWlAenRlLmNvbS5jbj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5kYWkueHVl aHVpQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+DQp3cm90ZTo8YnI+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpLDwvZm9u dD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KSSBoYXZlIGEgcHJvYmxlbSBvbiB0aGUgZGVmaW5pdGlvbiBvZiBFQ01QICZuYnNw O3V0aWxpemF0aW9uIGluIFRSSUxMIE9BTQ0KUmVxIGRyYWZ0LCB3aGljaCBzYWlkIHRoYXQ6IDwv Zm9udD48dHQ+PGZvbnQgc2l6ZT0zPiZuYnNwOyZxdW90O09BTSBNQVkNCnByb3ZpZGUgZnVuY3Rp b25hbGl0eSB0byBtb25pdG9yIHV0aWxpemF0aW9uIG9mIEVDTVAgcGF0aHMgdG8gc3BlY2lmaWVk DQpkZXN0aW5hdGlvbiBSQnJpZGdlcy4gVXRpbGl6YXRpb24gaXMgZGVmaW5lZCBhcyBkaXN0cmli dXRpb24gb2YgdHJhZmZpYw0Kb3ZlciBkaWZmZXJlbnQgRUNNUCBtZW1iZXJzLiZxdW90OzwvZm9u dD48L3R0Pjxmb250IHNpemU9Mz4gPGJyPg0KPGJyPg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTM+ PGJyPg0KR2l2ZW4gdGhlIGZpZ3VyZSBiZWxvdywgUkIxIGlzIGluZ3Jlc3MgUmJyaWRnZSBhbmQg UkI5IGlzIGVncmVzcyBSYnJpZGdlLA0KUkIyIGhhcyB0aHJlZSBkb3duc3RyZWFtIFJCcyhSQjMs IFJCNCBhbmQgUkI1KSB0aGF0IGNhbiByZWFjaCBSQjksIGFuZA0KUkI2IGhhcyB0d28gZG93bnN0 cmVhbSBSQnOjqFJCNyBhbmQgUkI4o6l0byBSQjksIHNvIHRoZXJlIGFyZSBhbGwgNiBFQ01QDQpw YXRocyBmcm9tIFJCMSB0byBSQjkuPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2Zv bnQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQogVGhlbiwgbXkgcXVlc3Rpb24gaXOjujwvZm9udD48 L3R0Pjxmb250IHNpemU9Mz4gPGJyPg0KSW4gdGhlIGN1cnJlbnQgdGV4dCwgZG9lcyAmcXVvdDtF Q01QIG1lbWJlciZxdW90OyBtZWFuIG9uZSBzcGVjaWZpYyBwYXRoDQpmcm9tIFJCMSB0byBSQjko c3VjaCBhcyBSQjEtUkIyLVJCMy1SQjYtUkI3LVJCOSk/IG9yIG9uZSBzcGVjaWZpYyBub2RlKHN1 Y2gNCmFzIFJCMik/IDxicj4NCjxicj4NCiZsdDttaW1lLWF0dGFjaG1lbnQuZ2lmJmd0OyA8YnI+ DQo8YnI+DQo8YnI+DQpQbGVhc2UgY29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIG5v dCBjb3JyZWN0LiA8YnI+DQo8YnI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQpCZXN0 IFJlZ2FyZCw8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTM+IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0z Pjxicj4NClh1ZWh1aTwvZm9udD48L3R0Pjxmb250IHNpemU9Mz4gPGJyPg0KPGJyPg0KPGJyPg0K PC9mb250Pjx0dD48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+PGZvbnQgc2l6 ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0 bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT50cmlsbEBpZXRmLm9y ZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2Zv bnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJpbGw8L3U+PC9mb250PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0 PGJyPg0KdHJpbGxAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyaWxsPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 002D2F6448257A07_=-- From d3e3e3@gmail.com Wed May 23 07:39: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 5E14921F8749 for ; Wed, 23 May 2012 07:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.549 X-Spam-Level: X-Spam-Status: No, score=-100.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qydsTv9wlPVv for ; Wed, 23 May 2012 07:39:11 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 858EF21F8748 for ; Wed, 23 May 2012 07:39:11 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so5004111wgb.13 for ; Wed, 23 May 2012 07:39:10 -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:content-transfer-encoding; bh=uSUg0lZyMPeMukzxUAeHxgncHuHmeLez/fCroSVnlsY=; b=OUyCuLWNX/PVTYjbkvSSk6MvzEA/ZBwVnsYNPcH6tlo0mVwr0SgLYGfXdIrYuLMDbd VPNzC9U6/CTCOdOaW0giPymgdRMmx9L3IqGSoFRsvgRLE00BqTcrEJzV+mbDKUlK9bQK ri4mgBInsfooz1MlW9AYCbCmbtjuFEbzGQJJCSp5vsCt/4GCK+Hyae3wn7fKPq9jWXNR VL6aogZ+IsvAWkwxBnZNg4fmtaRstNxmQF9/XzmGHjmEDyeyzHZVSoeqN0ALEsnr4ufR TxpyI2G5EtXMsajeUgcilIGGP/xO+AGDB5Peg9lXuR5Ur33g/tPRBk6QTU62e9uYryFd rh6w== Received: by 10.50.104.166 with SMTP id gf6mr13199679igb.35.1337783950006; Wed, 23 May 2012 07:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Wed, 23 May 2012 07:38:49 -0700 (PDT) In-Reply-To: References: <7CFD7C0D-15DA-4D35-A8C4-643996D9529B@gmail.com> From: Donald Eastlake Date: Wed, 23 May 2012 10:38:49 -0400 Message-ID: To: dai.xuehui@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: Sam Aldrin , "trill@ietf.org" Subject: Re: [trill] trill ecmp utilization 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, 23 May 2012 14:39:12 -0000 Hi, On Wed, May 23, 2012 at 4:13 AM, wrote: > > Hi Sam=A3=AC > > Thanks for your reply. > > with ecmp utilization of all ecmp paths, you may find that a hash > polarization happens, then what will you do about this? Polarization is a very well known potential problem. I suppose if you find hash polarization is happening, you should tell the implementors of TRILL for your RBridges to fix their implementations. The ECMP hashing should include some quantity that is unique per RBridge in a campus, such as the IS-IS System ID or a nickname. Perhaps the base protocol specification should have said this, but it didn't, so perhaps it should be included in the Clarifications and Corrections 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 > Best regards, > Xuehui > > > > Sam Aldrin > =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org > > 2012-05-23 13:32 > > =CA=D5=BC=FE=C8=CB > "dai.xuehui@zte.com.cn" > =B3=AD=CB=CD > "trill@ietf.org" > =D6=F7=CC=E2 > Re: [trill] trill ecmp utilization > > > > It is per path, not node. > > Sam > > Sent from my iPhone > > On May 22, 2012, at 8:33 PM, dai.xuehui@zte.com.cn wrote: > > > Hi, > > I have a problem on the definition of ECMP utilization in TRILL OAM Req > draft, which said that: "OAM MAY provide functionality to monitor > utilization of ECMP paths to specified destination RBridges. Utilization = is > defined as distribution of traffic over different ECMP members." > > > Given the figure below, RB1 is ingress Rbridge and RB9 is egress Rbridge, > RB2 has three downstream RBs(RB3, RB4 and RB5) that can reach RB9, and RB= 6 > has two downstream RBs=A3=A8RB7 and RB8=A3=A9to RB9, so there are all 6 E= CMP paths > from RB1 to RB9. > > Then, my question is=A3=BA > In the current text, does "ECMP member" mean one specific path from RB1 t= o > RB9(such as RB1-RB2-RB3-RB6-RB7-RB9)? or one specific node(such as RB2)? > > > > > Please correct me if my understanding is not correct. > > > Best Regard, > Xuehui > > > > > > > _______________________________________________ > 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 iesg-secretary@ietf.org Wed May 23 14:15:49 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 5541B11E80A5; Wed, 23 May 2012 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ApZ1Ef2wpRm; Wed, 23 May 2012 14:15:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B893A11E8098; Wed, 23 May 2012 14:15:48 -0700 (PDT) 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.02 Message-ID: <20120523211548.28200.46941.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 14:15:48 -0700 Cc: trill@ietf.org Subject: [trill] Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) to Proposed Standard X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:15:49 -0000 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL: Bidirectional Forwarding Detection (BFD) Support' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed May 23 14:18:00 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 7343D11E80B7; Wed, 23 May 2012 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gojMyaQxukC7; Wed, 23 May 2012 14:18:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE07311E80A0; Wed, 23 May 2012 14:17:59 -0700 (PDT) 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.02 Message-ID: <20120523211759.29647.17070.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 14:17:59 -0700 Cc: trill@ietf.org Subject: [trill] Last Call: (TRILL: Header Extension) to Proposed Standard X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:18:00 -0000 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL: Header Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF TRILL (Transparent Interconnection of Lots of Links) base protocol specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies two of those bits. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-extension/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-extension/ballot/ No IPR declarations have been submitted directly on this I-D.