From Adrian.Farrel@huawei.com Wed Feb 3 09:33:06 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954A528C1A2 for ; Wed, 3 Feb 2010 09:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV7ruTLnO5ZV for ; Wed, 3 Feb 2010 09:33:05 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 5FBAD28C1A0 for ; Wed, 3 Feb 2010 09:32:59 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXA003SO0S6VZ@usaga03-in.huawei.com> for rtg-dir@ietf.org; Wed, 03 Feb 2010 11:33:42 -0600 (CST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXA004SD0S4VH@usaga03-in.huawei.com> for rtg-dir@ietf.org; Wed, 03 Feb 2010 11:33:42 -0600 (CST) Date: Wed, 03 Feb 2010 17:33:26 +0000 From: Adrian Farrel To: Routing Area Directorate Message-id: <3C6B277128BA453C97FF320BCBCAFE83@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [RTG-DIR] Routing Directorate Test Message X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 17:33:06 -0000 Hi, This is a test message to verify your subscription to the Routing Directorate mailing list. If you do not receive this message, please let Ross know. I will be updating the charter page soon to show your names. That update will also show how long your term is (recall, one third of you get to be considered for reselection every year). The choice of 1, 2, or 3 years was random. Cheers, Adrian From Adrian.Farrel@huawei.com Thu Feb 4 07:19:10 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B7728C0F5 for ; Thu, 4 Feb 2010 07:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zElTGxkDHXUU for ; Thu, 4 Feb 2010 07:19:09 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 754F23A6C4E for ; Thu, 4 Feb 2010 07:19:09 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXB0078AP97PL@usaga01-in.huawei.com> for rtg-dir@ietf.org; Thu, 04 Feb 2010 07:19:56 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXB00M0RP96F6@usaga01-in.huawei.com> for rtg-dir@ietf.org; Thu, 04 Feb 2010 07:19:55 -0800 (PST) Date: Thu, 04 Feb 2010 15:19:48 +0000 From: Adrian Farrel To: Routing Area Directorate Message-id: <6A9761895FF84E5F837947559B7FDD6D@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [RTG-DIR] Charter page updated X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 15:19:10 -0000 http://www.ietf.org/iesg/directorate/routing.html Charter is unchanged. You are all listed. We have added boilerplate and an example of what review output might look like. Thoughts welcome. Review requests will probably start to cut in soon. Thanks, Adrian From acee.lindem@ericsson.com Tue Feb 16 16:49:32 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9733A7E29 for ; Tue, 16 Feb 2010 16:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5-YuWj9VqKo for ; Tue, 16 Feb 2010 16:49:31 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 3682D28C0E0 for ; Tue, 16 Feb 2010 16:49:31 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1H0qpcH026034; Tue, 16 Feb 2010 18:52:52 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.77]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 16 Feb 2010 19:51:06 -0500 From: Acee Lindem To: "rtg-ads@tools.ietf.org" Date: Tue, 16 Feb 2010 19:50:59 -0500 Thread-Topic: draft-ietf-trill-rbridge-protocol-15.txt Thread-Index: Acqva0lCRPBZb6QrRyORhesb1jQM0Q== Message-ID: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "dratf-ietf-trill-rbridge-protocol@tools.ietf.org" , "trill-chairs@tools.ietf.org" Subject: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 00:49:32 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://www.ietf.org/iesg/directorate/= routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-trill-rbridge-protocol-15.txt Reviewer: Acee Lindem Review Date: 2010-02-16 IETF LC End Date: TBD Intended Status: Proposed Standard Summary: Given the complexity of the protocol, I believe interoperable implementatio= ns are the imperative. Also, there are some areas which I believe should b= e addressed in the document. Major Issues: I think this is a very complex protocol when you consider all the pieces and the interaction with IEEE 802.1 bridging. Hence, I think interoperable implementations are necessary for document advancement. Without them, I would think the intended status should be Experimental. There is a lengthy discussion on determining the inter-RBridge MTU for the purposes of TRILL control packets. However, what happens an end-stat= ion sends a max-MTU packet and the the 40 bytes of ethernet outer header and TRILL header cause the packet to be too large to be transported betw= een RBridges? In a TRILL domain with multiple distribution trees, how does an ingress RBridge determine which distribution tree to use? I read section 4.5 several times and it is not clear to me how the ingress RBridge selects a distribution tree (other than everyone using the highest priority). Also, nickname terminology is confusing. Is the nickname1 tree the distribution tree rooted at RBridge 1 or is the nickname space for the distribution trees separate? The document should explain the philosophy and usage of confidence level with respect to the {port, VLAN, MAC address} tuples. This discussion should also tie in the confidence configuration in section 5.1. Minor Issues: The RBridge configuration in section 5 should include the default values and ranges of values. The use of ESADI is inconsistent. In some cases, it is used as one would expect in that it refers to a piece of End Station Address Distribution Information. However, in other cases it is used to refer to the protocol exchange of ESADI (e.g., see the second paragraph of page 14). This is very confusing. Also inconsistent is the usage of "RBridge" and "Rbridge". Given the former is the title of the protocol, I'm assuming all instances should be "RBridge". Nits: Page 18, Section 2.5.1, 1st paragraph, replace "In that case," with "In this case,". Page 23, Section 3.4, replace "a known unicast TRILL data frame" with "a known unicast MAC address". Page 26, Section 3.7.3, 1st bullent, shouldn't this contain a reference to "[layer2]"? Page 28, Section 3.7.3, second bullet, restructure the sentence beginning "Because of the ... " for readability. Page 44, Section 4.2.6, first full paragraph, replace "RBridges ," with "RBridges," and "next hop" with "next hop". Page 46, Section 4.4.1, third paragraph, replace "completely independent= ly" with "completely independent". Page 48, Section 4.4.2, first full paragraph, capitalize or somehow deno= te the "Appointed-Forwarders TLV" and possibly reference "[layer]". Page 52, Section 4.4.5, first paragraph, replace "permitted to a" with "permitted on a". Page 59, Section 4.5.5, first bullet, replace "nickanme1" with "nickname= 1". Page 67, Section 4.8, first sentence, can this be restructured to not be one continuous stream of consciousness? Page 70, Section 4.8.3, first bullet, replace "who's" with "whose" consi= stent with this usage. Page 72, Section 4.9.1, first full paragraph, replace "to the left in the this list" with "to the left of the other bit in thi= s list". Page 75. Section 4.9.3.2, second paragraph, replace "in the first set" w= ith "in the lower priority set". Page 77, Section 5.1, replace "number of distribution tree" with "number= of distribution trees". Page 78, Section 5.2, fifth bullet, replace "it disable learning" with "= it disables learning". Thanks, Acee From d3e3e3@gmail.com Wed Feb 17 21:05:58 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A260028C0EE for ; Wed, 17 Feb 2010 21:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dODSqakPo5T9 for ; Wed, 17 Feb 2010 21:05:57 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 939B628C0E0 for ; Wed, 17 Feb 2010 21:05:56 -0800 (PST) Received: by ewy8 with SMTP id 8so9073122ewy.29 for ; Wed, 17 Feb 2010 21:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vMZS664EzBJgZW/URo4Axf5PmRTBggV92UghbMMTYqo=; b=vrff7x/KDfOcO+xlak/VBlle9MwsamhAYpzQaYgjbgrUviXO7AwaUnCzFWkADGY7M0 g/Jba56SeVEBvkd2Lfg0gZS9u9PFolZSolYeh5NwPJws4+fQfgI7cDZ/jHq0Fr2YQQiX L8cN71prQNqQ0D+gvxF0ctUgn/HjxckWLFmX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MCSzEOPNWeCmmZupqMIZC7m4Ru1xtrlbTX51wMm7kW3R/S4/B22KDTZbqqHOvIYLE9 S2hrh37Emcws2o2JthGy5rhmxw5razYUI0gKa8pSSy56d66ttXecLUmyFRjBG9rfPj/t buWdh/F7Z8yK7rhyw7C2+yEVHfZNvOe6qPM6M= MIME-Version: 1.0 Received: by 10.216.88.205 with SMTP id a55mr1866550wef.122.1266469654534; Wed, 17 Feb 2010 21:07:34 -0800 (PST) In-Reply-To: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> Date: Thu, 18 Feb 2010 00:07:34 -0500 Message-ID: <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> From: Donald Eastlake To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 17 Feb 2010 21:22:21 -0800 Cc: "rtg-dir@ietf.org" , "dratf-ietf-trill-rbridge-protocol@tools.ietf.org" , Ralph Droms , "trill-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 05:05:58 -0000 Hi Acee, Thanks for your detailed comments. On Tue, Feb 16, 2010 at 7:50 PM, Acee Lindem wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, > please see http://www.ietf.org/iesg/directorate/routing.html > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > Document: draft-ietf-trill-rbridge-protocol-15.txt > Reviewer: Acee Lindem > Review Date: 2010-02-16 > IETF LC End Date: TBD > Intended Status: Proposed Standard The IETF Last Call End Date was January 11th, 2010. > Summary: > Given the complexity of the protocol, I believe interoperable > implementations are the imperative. Also, there are some areas > which I believe should be addressed in the document. See responses below. > Major Issues: > I think this is a very complex protocol when you consider all the > pieces and the interaction with IEEE 802.1 bridging. Hence, I think > interoperable implementations are necessary for document advancement. > Without them, I would think the intended status should be > Experimental. I see no justification for this. As far as I am aware, there is no four step standardization system (Experimental -> Proposed -> Draft -> Full) in the IETF for "complex" protocols, as opposed to a three step standardization system for "simple" protocols. I am not claiming the specification is perfect. But I believe it clearly fits the criterion for Proposed Standard from RFC 2026: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. It is also true that RFC 2026 contains the following: The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. Based on the above paragraph, there was a policy requiring "One or more implementations" of their major features for core Internet routing protocols prior to Proposed Standard [RFC1264]. However, (1) that policy is no longer generally in effect [RFC4794] and (2) TRILL is not a core Internet routing protocol. It is a Local Area Networking protocol based on a well understood and deployed routing protocol, level 1 IS-IS. > There is a lengthy discussion on determining the inter-RBridge MTU > for the purposes of TRILL control packets. However, what happens > if an end-station sends a max-MTU packet and the 40 bytes of > ethernet outer header and TRILL header cause the packet to be too > large to be transported between RBridges? Obviously, when a frame exceeds MTU on an Ethernet link, it is generally discarded. (There did not appear to be any interest in the TRILL WG in adding a link fragmentation protocol for such cases.) The consensus of the TRILL WG is that this is not a problem as modern switches have adequate headroom for headers and encapsulation and the like. However, to assure safe operation of the TRILL Protocol in case of limited MTU and to be able to take advantage of a high campus wide inter-Rbridge link MTU, the TRILL MTU feature was added. I thought the draft was clear on the applicability of this feature. It is careful, both in the Section heading and in the text, to say that the TRILL MTU feature is for "Inter-RBridge Links". It also includes the following paragraph (where "Sz" has already been defined as the campus wide minimum inter-Rbridge link MTU): Sz has no direct effect on end-stations and is not directly related to any end-station to end-station "path MTU". Methods of using Sz or any link MTU information gathered by TRILL IS-IS in the traffic engineering of routes or the determination of any path MTU is beyond the scope of this document. A sentence could be add to the above paragraph such as "Native frames that, after TRILL encapsulation, exceed the MTU of a link on which they would be sent will generally be discarded." By the way, I'm not sure where you get "40 bytes" for TRILL encapsulation. It adds either 20 bytes or 24 bytes, depending on whether an outer VLAN tag is sent on the wire (unless there are options included in the TRILL Header): 12 for the outer destination and source MAC addresses, possibly 4 for the outer VLAN tag, and 8 for the TRILL header. In a fully RBridged point-to-point network there would be no reason to include such an outer VLAN tag on TRILL data or control frames sent between RBridges, so only 20 bytes would normally be added. > In a TRILL domain with multiple distribution trees, how does an > ingress RBridge determine which distribution tree to use? I read > section 4.5 several times and it is not clear to me how the > ingress RBridge selects a distribution tree (other than everyone > using the highest priority). Also, nickname terminology is > confusing. Is the nickname1 tree the distribution tree rooted at > RBridge 1 or is the nickname space for the distribution trees > separate? On tree selection: Other than the TRILL requirement that the ingress RBridge announce the set of distribution trees that it might use, what does it matter? The RBridge campus will operate "correctly" regardless of what tree(s) are used by the ingress as long as it puts all the frames that are part of the same order-dependent flow on the same tree. In the absence of other considerations, it is probably best to use the tree whose root RBridge is least cost from the ingress RBridge. But, other than that, such questions as which sub-set of distribution trees to use if you are multipathing multi-destination frames seems like an excellent area for implementer creativity and beyond the scope of this document. On nickname terminology: In early drafts, there was only one nickname per RBridge, so distribution trees could equally well be considered to be named by a nickname or uniquely determined by their root RBridge. More recently the option of multiple nicknames per RBridge was added and now distribution trees are uniquely labeled only by their nickname. Nicknames are also permitted for pseudo-nodes. There is only one nickname allocation space. Every nickname in use in a campus designates either an RBridge or a pseudo-node and one or more nicknames also each designate a distribution tree. With this explanation, do you think that the draft text still needs clarification and if so do you have any suggestions? > The document should explain the philosophy and usage of confidence > level with respect to the {port, VLAN, MAC address} tuples. This > discussion should also tie in the confidence configuration in > section 5.1. Well, how about something like the following new text: The confidence level mechanism allows an RBridge campus manager to cause certain address learning sources to prevail over others. In a default configuration, without the optional ESADI protocol, addresses are only learned from observing local native frames and the decapsulation of received TRILL data frames. Both of these sources default to confidence level 0x20 so, since learning at an equal or high confidence overrides previous learning, the learning in such a default case mimics default 802.1 bridge learning. While RBridge campus management policies are beyond the scope of this document, here are some example types of policies that can be implemented with the confidence mechanism and the rational for each: o Locally received native frames might be considered more reliable than decapsulated frames received from remote parts of the campus. To stop MAC addresses learned from such local frames from being usurped by remotely received forged frames, the confidence in locally learned addresses could be increased or that in addresses learned from remotely sourced decapsulated frames decreased. o MAC address information learned through a cryptographically authenticated Layer 2 registration protocol, such as 802.1X with a cryptographically based EAP method, might be considered more reliable than information learned through the mere observation of data frames. When such authenticated learned address information is transmitted via the ESADI protocol, the use of authentication in the TRILL EASDI LSP frames could make tampering with it in transit very difficult. As a result, it might be reasonable to announce such authenticated information via the ESADI protocol with a high confidence, so it would override any alternative learning from data observation. Manually configured address information is generally considered static and so defaults to a confidence of 0xFF while no other source of such information can be configured to a confidence any higher than 0xFE. However, for other cases, such as where the manual configuration is just a starting point which the Rbridge campus manager wishes to be dynamically overrideable, the confidence of such manually configured information may be configured to a lower value. > Minor Issues: > The RBridge configuration in section 5 should include the default > values and ranges of values. That can be done for the configuration items added by TRILL. But where whole blocks of parameters are incorporated by reference (such as all 802.1Q-2005 port VLAN and priority parameters), I don't see a need to list in the TRILL specification all the default values and ranges copied from the referenced document. > The use of ESADI is inconsistent. In some cases, it is used as one > would expect in that it refers to a piece of End Station Address > Distribution Information. However, in other cases it is used to > refer to the protocol exchange of ESADI (e.g., see the second > paragraph of page 14). This is very confusing. Is this all that unusual? "LSP" is sometimes used to mean a protocol message and sometimes to mean the data in an LSP. But it would be reasonable to do a review and replace "ESDAI" with "ESADI data" or "ESADI protocol" or the like, where appropriate for clarity. > Also inconsistent is the usage of "RBridge" and "Rbridge". Given > the former is the title of the protocol, I'm assuming all > instances should be "RBridge". Well, the draft states the following in Section 1.3: "The second letter in Rbridge is case insensitive. Both Rbridge and RBridge are correct." :-) Interestingly enough, I don't recall any comment like yours being posted to the TRILL WG mailing list. Nor was this mentioned by any of the previous Independent Expert, Directorate, or other reviews, including not being mentioned in the GenART review. Nor has it been mentioned by any AD. Under the circumstances I'd be inclined to leave it as is. > Nits: Thanks for all the corrections and suggestions for improvement below. I'd be happy to make changes based on them. > Page 18, Section 2.5.1, 1st paragraph, replace "In that case," > with "In this case,". I actually think "that" reads better than "this". But how about replacing "In that case" with "For such configurations". > Page 23, Section 3.4, replace "a known unicast TRILL data frame" > with "a known unicast MAC address". OK. > Page 26, Section 3.7.3, 1st bullet, shouldn't this contain a > reference to "[layer2]"? OK. > Page 28, Section 3.7.3, second bullet, restructure the sentence > beginning "Because of the ... " for readability. OK. Can split into two sentences. > Page 44, Section 4.2.6, first full paragraph, replace "RBridges ," > with "RBridges," and "next hop" with "next hop". OK. > Page 46, Section 4.4.1, third paragraph, replace "completely independently" > with "completely independent". I think it would be better to replaced "completely independently of whether they are padded or not" with "even though they are not padded". > Page 48, Section 4.4.2, first full paragraph, capitalize or > somehow denote the "Appointed-Forwarders TLV" and possibly > reference "[layer2]". OK to both changes. > Page 52, Section 4.4.5, first paragraph, replace "permitted to a" > with "permitted on a". OK. > Page 59, Section 4.5.5, first bullet, replace "nickanme1" with > "nickname1". OK. > Page 67, Section 4.8, first sentence, can this be restructured to > not be one continuous stream of consciousness? Sure. How about changing it to start as follows: RBridges have to learn the MAC addresses and VLANs of their locally attached end stations for link/VLAN pairs for which they are the appointed forwarders. Learning this enables them to do the following: And then convert the two main bullet points into separate sentences. > Page 70, Section 4.8.3, first bullet, replace "who's" with "whose" > consistent with this usage. OK. > Page 72, Section 4.9.1, first full paragraph, replace "to the left > in the this list" with "to the left of the other bit in this > list". OK. > Page 75. Section 4.9.3.2, second paragraph, replace "in the first > set" with "in the lower priority set". OK, that change does make it clearer. > Page 77, Section 5.1, replace "number of distribution tree" with > "number of distribution trees". OK. > Page 78, Section 5.2, fifth bullet, replace "it disable learning" > with "it disables learning". OK. > Thanks, > Acee Thanks, Donald [document Editor] ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com From Adrian.Farrel@huawei.com Fri Feb 19 14:46:26 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0336828C100 for ; Fri, 19 Feb 2010 14:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ChWvpVXQgOA for ; Fri, 19 Feb 2010 14:46:25 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 5798228C0F9 for ; Fri, 19 Feb 2010 14:46:25 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY400EI020D2A@usaga01-in.huawei.com> for rtg-dir@ietf.org; Fri, 19 Feb 2010 14:48:13 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY4006C420B3K@usaga01-in.huawei.com> for rtg-dir@ietf.org; Fri, 19 Feb 2010 14:48:13 -0800 (PST) Date: Fri, 19 Feb 2010 22:47:53 +0000 From: Adrian Farrel To: Routing Area Directorate Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [RTG-DIR] Meet the ADs X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 22:46:26 -0000 Hi, The ADs (all three), Would like to meet the Routing Directorate, remind ourselves who you are, and possibly buy you a lemonade to share between you. The agenda looks horribly stretched already, so we want to put our claim on a slot now. Monday 8pm. More details to be announced later. Cheers, Adrian per pro Russ'n'Stewart PS Sorry if some of you can't make that slot, but don't let it worry you. From acee.lindem@ericsson.com Wed Feb 24 11:50:13 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118E528C1DF for ; Wed, 24 Feb 2010 11:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.303 X-Spam-Level: X-Spam-Status: No, score=-6.303 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va8SrVWTh8ff for ; Wed, 24 Feb 2010 11:50:11 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id F0BB128C1D0 for ; Wed, 24 Feb 2010 11:50:10 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1OJsMCe017475; Wed, 24 Feb 2010 13:54:22 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 24 Feb 2010 14:52:15 -0500 From: Acee Lindem To: Donald Eastlake Date: Wed, 24 Feb 2010 14:52:10 -0500 Thread-Topic: draft-ietf-trill-rbridge-protocol-15.txt Thread-Index: Acq1itz0/U1woyNARiuGk5T/gT89bQ== Message-ID: <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> In-Reply-To: <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "dratf-ietf-trill-rbridge-protocol@tools.ietf.org" , Ralph Droms , "trill-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 19:50:13 -0000 Hi Donald, See inline. On Feb 18, 2010, at 12:07 AM, Donald Eastlake wrote: > Hi Acee, > > Thanks for your detailed comments. > > On Tue, Feb 16, 2010 at 7:50 PM, Acee Lindem w= rote: >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this >> draft. The Routing Directorate seeks to review all routing or >> routing-related drafts as they pass through IETF last call and IESG >> review. The purpose of the review is to provide assistance to the >> Routing ADs. For more information about the Routing Directorate, >> please see http://www.ietf.org/iesg/directorate/routing.html > >> Although these comments are primarily for the use of the Routing >> ADs, it would be helpful if you could consider them along with any >> other IETF Last Call comments that you receive, and strive to >> resolve them through discussion or by updating the draft. > >> Document: draft-ietf-trill-rbridge-protocol-15.txt >> Reviewer: Acee Lindem >> Review Date: 2010-02-16 >> IETF LC End Date: TBD >> Intended Status: Proposed Standard > > The IETF Last Call End Date was January 11th, 2010. > >> Summary: > >> Given the complexity of the protocol, I believe interoperable >> implementations are the imperative. Also, there are some areas >> which I believe should be addressed in the document. > > See responses below. > >> Major Issues: > >> I think this is a very complex protocol when you consider all the >> pieces and the interaction with IEEE 802.1 bridging. Hence, I think >> interoperable implementations are necessary for document advancement. >> Without them, I would think the intended status should be >> Experimental. > > I see no justification for this. As far as I am aware, there is no > four step standardization system (Experimental -> Proposed -> Draft -> > Full) in the IETF for "complex" protocols, as opposed to a three step > standardization system for "simple" protocols. > > I am not claiming the specification is perfect. But I believe it > clearly fits the criterion for Proposed Standard from RFC 2026: > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > It is also true that RFC 2026 contains the following: > > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. > > Based on the above paragraph, there was a policy requiring "One or > more implementations" of their major features for core Internet > routing protocols prior to Proposed Standard [RFC1264]. However, (1) > that policy is no longer generally in effect [RFC4794] and (2) TRILL > is not a core Internet routing protocol. The ADs informed me that there is no requirement in the INT area for intero= perable implementations or protocol experience. Hence, I guess it is a judg= ement call. If not two implementations, is there one righteous implementat= ion that interoperates with itself? > It is a Local Area Networking > protocol based on a well understood and deployed routing protocol, > level 1 IS-IS. Well, not exactly. It is ISIS but the hello protocol is modified, it is bei= ng used for multicast distribution tree with new rules for tie breaking, an= d the application supported by the L2 topology information is brand new. > >> There is a lengthy discussion on determining the inter-RBridge MTU >> for the purposes of TRILL control packets. However, what happens >> if an end-station sends a max-MTU packet and the 40 bytes of >> ethernet outer header and TRILL header cause the packet to be too >> large to be transported between RBridges? > > Obviously, when a frame exceeds MTU on an Ethernet link, it is > generally discarded. (There did not appear to be any interest in the > TRILL WG in adding a link fragmentation protocol for such cases.) > > The consensus of the TRILL WG is that this is not a problem as modern > switches have adequate headroom for headers and encapsulation and the > like. However, to assure safe operation of the TRILL Protocol in case > of limited MTU and to be able to take advantage of a high campus wide > inter-Rbridge link MTU, the TRILL MTU feature was added. > > I thought the draft was clear on the applicability of this feature. It > is careful, both in the Section heading and in the text, to say that > the TRILL MTU feature is for "Inter-RBridge Links". It also includes > the following paragraph (where "Sz" has already been defined as the > campus wide minimum inter-Rbridge link MTU): > > Sz has no direct effect on end-stations and is not directly related > to any end-station to end-station "path MTU". Methods of using Sz or > any link MTU information gathered by TRILL IS-IS in the traffic > engineering of routes or the determination of any path MTU is beyond > the scope of this document. > > A sentence could be add to the above paragraph such as "Native frames > that, after TRILL encapsulation, exceed the MTU of a link on which > they would be sent will generally be discarded." Maybe this should be stated explicitly. It seems to me that any draft that = adds an additional level of encapsulation (outer ethernet + TRILL header) s= hould have some discussion. > > By the way, I'm not sure where you get "40 bytes" for TRILL > encapsulation. It adds either 20 bytes or 24 bytes, depending on > whether an outer VLAN tag is sent on the wire (unless there are > options included in the TRILL Header): 12 for the outer destination > and source MAC addresses, possibly 4 for the outer VLAN tag, and 8 for > the TRILL header. In a fully RBridged point-to-point network there > would be no reason to include such an outer VLAN tag on TRILL data or > control frames sent between RBridges, so only 20 bytes would normally > be added. > >> In a TRILL domain with multiple distribution trees, how does an >> ingress RBridge determine which distribution tree to use? I read >> section 4.5 several times and it is not clear to me how the >> ingress RBridge selects a distribution tree (other than everyone >> using the highest priority). Also, nickname terminology is >> confusing. Is the nickname1 tree the distribution tree rooted at >> RBridge 1 or is the nickname space for the distribution trees >> separate? > > On tree selection: Other than the TRILL requirement that the ingress > RBridge announce the set of distribution trees that it might use, what > does it matter? The RBridge campus will operate "correctly" regardless > of what tree(s) are used by the ingress as long as it puts all the > frames that are part of the same order-dependent flow on the same > tree. In the absence of other considerations, it is probably best to > use the tree whose root RBridge is least cost from the ingress > RBridge. But, other than that, such questions as which sub-set of > distribution trees to use if you are multipathing multi-destination > frames seems like an excellent area for implementer creativity and > beyond the scope of this document. I may have missed exactly how it works. So, at the ingress, the frame is un= icast to the root of the distribution tree selected by the ingress. The roo= t of the distribution tree will then re-encapsulate it and send it on the = distribution tree as a multicast. Correct? If so, then I agree with your st= atement. > > On nickname terminology: In early drafts, there was only one nickname > per RBridge, so distribution trees could equally well be considered to > be named by a nickname or uniquely determined by their root > RBridge. More recently the option of multiple nicknames per RBridge > was added and now distribution trees are uniquely labeled only by > their nickname. Nicknames are also permitted for pseudo-nodes. There > is only one nickname allocation space. Every nickname in use in a > campus designates either an RBridge or a pseudo-node and one or more > nicknames also each designate a distribution tree. > > With this explanation, do you think that the draft text still needs > clarification and if so do you have any suggestions? Maybe section 3.7 could explicitly state that the distribution tree nicknam= es and the RBridge nicknames are independent of one another. Or if they are= not, precisely explain the correlation. > >> The document should explain the philosophy and usage of confidence >> level with respect to the {port, VLAN, MAC address} tuples. This >> discussion should also tie in the confidence configuration in >> section 5.1. > > Well, how about something like the following new text: > > The confidence level mechanism allows an RBridge campus manager to > cause certain address learning sources to prevail over others. In a > default configuration, without the optional ESADI protocol, > addresses are only learned from observing local native frames and > the decapsulation of received TRILL data frames. Both of these > sources default to confidence level 0x20 so, since learning at an > equal or high confidence overrides previous learning, the learning > in such a default case mimics default 802.1 bridge learning. > > While RBridge campus management policies are beyond the scope of > this document, here are some example types of policies that can be > implemented with the confidence mechanism and the rational for > each: > > o Locally received native frames might be considered more reliable > than decapsulated frames received from remote parts of the > campus. To stop MAC addresses learned from such local frames > from being usurped by remotely received forged frames, the > confidence in locally learned addresses could be increased or > that in addresses learned from remotely sourced decapsulated > frames decreased. > > o MAC address information learned through a cryptographically > authenticated Layer 2 registration protocol, such as 802.1X with > a cryptographically based EAP method, might be considered more > reliable than information learned through the mere observation > of data frames. When such authenticated learned address > information is transmitted via the ESADI protocol, the use of > authentication in the TRILL EASDI LSP frames could make > tampering with it in transit very difficult. As a result, it > might be reasonable to announce such authenticated information > via the ESADI protocol with a high confidence, so it would > override any alternative learning from data observation. > > Manually configured address information is generally considered > static and so defaults to a confidence of 0xFF while no other > source of such information can be configured to a confidence any > higher than 0xFE. However, for other cases, such as where the > manual configuration is just a starting point which the Rbridge > campus manager wishes to be dynamically overrideable, the > confidence of such manually configured information may be > configured to a lower value. This would be good. In the last sentence, do you mean the MAC addresses are= dynamically learned or changing the configuration of the confidence level?= I suspect the former. > > >> Minor Issues: > >> The RBridge configuration in section 5 should include the default >> values and ranges of values. > > That can be done for the configuration items added by TRILL. But where > whole blocks of parameters are incorporated by reference (such as all > 802.1Q-2005 port VLAN and priority parameters), I don't see a need to > list in the TRILL specification all the default values and ranges > copied from the referenced document. I agree (these reference documents could simply be cited, if they are not a= lready). > >> The use of ESADI is inconsistent. In some cases, it is used as one >> would expect in that it refers to a piece of End Station Address >> Distribution Information. However, in other cases it is used to >> refer to the protocol exchange of ESADI (e.g., see the second >> paragraph of page 14). This is very confusing. > > Is this all that unusual? "LSP" is sometimes used to mean a protocol > message and sometimes to mean the data in an LSP. But it would be > reasonable to do a review and replace "ESDAI" with "ESADI data" or > "ESADI protocol" or the like, where appropriate for clarity. I support this change. > >> Also inconsistent is the usage of "RBridge" and "Rbridge". Given >> the former is the title of the protocol, I'm assuming all >> instances should be "RBridge". > > Well, the draft states the following in Section 1.3: "The second > letter in Rbridge is case insensitive. Both Rbridge and RBridge are > correct." :-) > > Interestingly enough, I don't recall any comment like yours being > posted to the TRILL WG mailing list. Nor was this mentioned by any of > the previous Independent Expert, Directorate, or other reviews, > including not being mentioned in the GenART review. Nor has it been > mentioned by any AD. Under the circumstances I'd be inclined to leave > it as is. As a point of reference, I believe IPsec standard started out allowing mult= iple permutations of uppercase and lowercase. However, in RFC 4301, they se= ttled on "IPsec". Here is an excerpt: The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of the sequence of letters "IPsec" should be understood to refer to the IPsec protocols. Thanks, Acee > >> Nits: > > Thanks for all the corrections and suggestions for improvement > below. I'd be happy to make changes based on them. > >> Page 18, Section 2.5.1, 1st paragraph, replace "In that case," >> with "In this case,". > > I actually think "that" reads better than "this". But how about > replacing "In that case" with "For such configurations". > >> Page 23, Section 3.4, replace "a known unicast TRILL data frame" >> with "a known unicast MAC address". > > OK. > >> Page 26, Section 3.7.3, 1st bullet, shouldn't this contain a >> reference to "[layer2]"? > > OK. > >> Page 28, Section 3.7.3, second bullet, restructure the sentence >> beginning "Because of the ... " for readability. > > OK. Can split into two sentences. > >> Page 44, Section 4.2.6, first full paragraph, replace "RBridges ," >> with "RBridges," and "next hop" with "next hop". > > OK. > >> Page 46, Section 4.4.1, third paragraph, replace "completely independen= tly" >> with "completely independent". > > I think it would be better to replaced "completely independently of > whether they are padded or not" with "even though they are not > padded". > >> Page 48, Section 4.4.2, first full paragraph, capitalize or >> somehow denote the "Appointed-Forwarders TLV" and possibly >> reference "[layer2]". > > OK to both changes. > >> Page 52, Section 4.4.5, first paragraph, replace "permitted to a" >> with "permitted on a". > > OK. > >> Page 59, Section 4.5.5, first bullet, replace "nickanme1" with >> "nickname1". > > OK. > >> Page 67, Section 4.8, first sentence, can this be restructured to >> not be one continuous stream of consciousness? > > Sure. How about changing it to start as follows: > > RBridges have to learn the MAC addresses and VLANs of their locally > attached end stations for link/VLAN pairs for which they are the > appointed forwarders. Learning this enables them to do the > following: > > And then convert the two main bullet points into separate sentences. > >> Page 70, Section 4.8.3, first bullet, replace "who's" with "whose" >> consistent with this usage. > > OK. > >> Page 72, Section 4.9.1, first full paragraph, replace "to the left >> in the this list" with "to the left of the other bit in this >> list". > > OK. > >> Page 75. Section 4.9.3.2, second paragraph, replace "in the first >> set" with "in the lower priority set". > > OK, that change does make it clearer. > >> Page 77, Section 5.1, replace "number of distribution tree" with >> "number of distribution trees". > > OK. > >> Page 78, Section 5.2, fifth bullet, replace "it disable learning" >> with "it disables learning". > > OK. > >> Thanks, >> Acee > > Thanks, > Donald [document Editor] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com From d3e3e3@gmail.com Thu Feb 25 22:11:34 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4278928C173 for ; Thu, 25 Feb 2010 22:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtOt+TtAdPCX for ; Thu, 25 Feb 2010 22:11:28 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CD0833A873D for ; Thu, 25 Feb 2010 22:11:27 -0800 (PST) Received: by wwb31 with SMTP id 31so2474746wwb.31 for ; Thu, 25 Feb 2010 22:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=s8q/d16pgkArkbouRehsFgSLvHketiYHyU6iA8rB5z4=; b=RyPlDD2PQp7vnLEhRQebDJpbWPWaOwf2kCzLjJzkqEOZGNkCxV8+egmbi8Z6rrPKjF ggY+MVBvd5lOtbVb6kKRShnrtTSuQAFF+wFrHzkJ8b+syfSiI0yrT2N3K4fPXbmffe1E rFFGfPg+/kSAbChIcj3DjThdnPcDxl0mX1AIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qk1hrZJEN/OzwPR58XH8zlgcjkmPKoKqdSyNpAACS3zLOYskGkAYnuwslXdKSEBRr3 KNo35TdqPP2fibIdwlT0G9xmV5CqgEoMMfp0qhcKCwT5MOuAHiwgf1sUnoveAtiQj+9S qH1GbT4gVkWKlx0DA2hqGhRh9rMrXEAArShsQ= MIME-Version: 1.0 Received: by 10.216.88.148 with SMTP id a20mr861272wef.124.1267164817124; Thu, 25 Feb 2010 22:13:37 -0800 (PST) In-Reply-To: <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> Date: Fri, 26 Feb 2010 01:13:37 -0500 Message-ID: <1028365c1002252213sda034c6wb21a1dd3a1bfa5b5@mail.gmail.com> From: Donald Eastlake To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 25 Feb 2010 23:55:55 -0800 Cc: "rtg-dir@ietf.org" , "dratf-ietf-trill-rbridge-protocol@tools.ietf.org" , Ralph Droms , "trill-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 06:11:34 -0000 Hi Acee, On Wed, Feb 24, 2010 at 2:52 PM, Acee Lindem wrote: > Hi Donald, > See inline. > > On Feb 18, 2010, at 12:07 AM, Donald Eastlake wrote: > >> Hi Acee, >> >> Thanks for your detailed comments. >> >> On Tue, Feb 16, 2010 at 7:50 PM, Acee Lindem wrote: >>> ... >> >>> I think this is a very complex protocol when you consider all the >>> pieces and the interaction with IEEE 802.1 bridging. Hence, I think >>> interoperable implementations are necessary for document advancement. >>> Without them, I would think the intended status should be >>> Experimental. >> >> ... >> >> I am not claiming the specification is perfect. But I believe it >> clearly fits the criterion for Proposed Standard from RFC 2026: >> >> A Proposed Standard specification is generally stable, has resolved >> known design choices, is believed to be well-understood, has received >> significant community review, and appears to enjoy enough community >> interest to be considered valuable. However, further experience >> might result in a change or even retraction of the specification >> before it advances. >> >> ... > The ADs informed me that there is no requirement in the INT area for > interoperable implementations or protocol experience. Hence, I guess > it is a judgement call. If not two implementations, is there one > righteous implementation that interoperates with itself? There is an open source implementation for Solaris. (By the way, according to UNH IOL, there are nine companies talking with them about interoperability testing. And, although there are no hardware TRILL products publicly announced, I was at NANOG 48 earlier this week and am at the Ethernet Summit right now. At both there are switch company booth personnel who seem quite happy to boast verbally about how strongly their companies support TRILL and how they are working on implementations.) >> It is a Local Area Networking protocol based on a well understood >> and deployed routing protocol, level 1 IS-IS. > Well, not exactly. It is ISIS but the hello protocol is modified, it > is being used for multicast distribution tree with new rules for tie > breaking, and the application supported by the L2 topology > information is brand new. It is my impression that the IESG came to a general conclusion that the application of any extra implementation/interoperability requirement to the TRILL base protocol specification for Proposed Standard would be at the discretion of the Internet Area Directors for two reasons: Such additional requirements are best applied to protocols or protocol changes that would be expected to have pervasive effects on the Internet, such as changes to TCP or BGP, not a local area networking protocol. (I'm also adding an explict statement that it is not a goal of TRILL to scale beyond the size of exisitng bridged LANs.) There was no hint that such a requirement would be imposed in the TRILL Charter or history so this would be an unexpected last-minute requirement. >>> There is a lengthy discussion on determining the inter-RBridge MTU >>> for the purposes of TRILL control packets. However, what happens >>> if an end-station sends a max-MTU packet and the 40 bytes of >>> ethernet outer header and TRILL header cause the packet to be too >>> large to be transported between RBridges? >> >> Obviously, when a frame exceeds MTU on an Ethernet link, it is >> generally discarded. (There did not appear to be any interest in the >> TRILL WG in adding a link fragmentation protocol for such cases.) >> >> The consensus of the TRILL WG is that this is not a problem as modern >> switches have adequate headroom for headers and encapsulation and the >> like. However, to assure safe operation of the TRILL Protocol in case >> of limited MTU and to be able to take advantage of a high campus wide >> inter-Rbridge link MTU, the TRILL MTU feature was added. >> >> ... [The draft] >> is careful, both in the Section heading and in the text, to say that >> the TRILL MTU feature is for "Inter-RBridge Links". It also includes >> the following paragraph (where "Sz" has already been defined as the >> campus wide minimum inter-Rbridge link MTU): >> >> Sz has no direct effect on end-stations and is not directly related >> to any end-station to end-station "path MTU". Methods of using Sz or >> any link MTU information gathered by TRILL IS-IS in the traffic >> engineering of routes or the determination of any path MTU is beyond >> the scope of this document. >> >> A sentence could be add to the above paragraph such as "Native frames >> that, after TRILL encapsulation, exceed the MTU of a link on which >> they would be sent will generally be discarded." > Maybe this should be stated explicitly. It seems to me that any > draft that adds an additional level of encapsulation (outer ethernet > + TRILL header) should have some discussion. I will add the above sentence in draft version -16 to make this explicit. >> By the way, I'm not sure where you get "40 bytes" for TRILL >> encapsulation. It adds either 20 bytes or 24 bytes, depending on >> whether an outer VLAN tag is sent on the wire (unless there are >> options included in the TRILL Header): 12 for the outer destination >> and source MAC addresses, possibly 4 for the outer VLAN tag, and 8 for >> the TRILL header. In a fully RBridged point-to-point network there >> would be no reason to include such an outer VLAN tag on TRILL data or >> control frames sent between RBridges, so only 20 bytes would normally >> be added. >> >>> In a TRILL domain with multiple distribution trees, how does an >>> ingress RBridge determine which distribution tree to use? I read >>> section 4.5 several times and it is not clear to me how the >>> ingress RBridge selects a distribution tree (other than everyone >>> using the highest priority). Also, nickname terminology is >>> confusing. Is the nickname1 tree the distribution tree rooted at >>> RBridge 1 or is the nickname space for the distribution trees >>> separate? >> >> On tree selection: Other than the TRILL requirement that the ingress >> RBridge announce the set of distribution trees that it might use, what >> does it matter? The RBridge campus will operate "correctly" regardless >> of what tree(s) are used by the ingress as long as it puts all the >> frames that are part of the same order-dependent flow on the same >> tree. In the absence of other considerations, it is probably best to >> use the tree whose root RBridge is least cost from the ingress >> RBridge. But, other than that, such questions as which sub-set of >> distribution trees to use if you are multipathing multi-destination >> frames seems like an excellent area for implementer creativity and >> beyond the scope of this document. > I may have missed exactly how it works. So, at the ingress, the > frame is unicast to the root of the distribution tree selected by > the ingress. The root of the distribution tree will then > re-encapsulate it and send it on the distribution tree as a > multicast. Correct? If so, then I agree with your statement. No. That's not how it works. With a bidirectional tree, an encapsulated packet can be injected anywhere, and travels from that point. So the ingress encapsulates it, and it just travels from there. The packet is not first unicast to the root and then re-encapsulated. The reasons it is good to use a tree whose root is least cost from the ingress RBridge are discussed in the first paragraph of Section 4.5. By the way, it turns out that in Section 4.6.1.2 of the current -15 draft it does explicitly state that, by default, an RBridge using one distribution tree chooses the one whose root is least cost from that RBridge. (While not pseudo code, section 4.6 is the most detailed and painstaking description in the draft of how to handle every type of frame it is possible for an RBridge to receive.) I will also add this to Section 4.5 where you were, quite reasonably, looking for it. >> On nickname terminology: In early drafts, there was only one nickname >> per RBridge, so distribution trees could equally well be considered to >> be named by a nickname or uniquely determined by their root >> RBridge. More recently the option of multiple nicknames per RBridge >> was added and now distribution trees are uniquely labeled only by >> their nickname. Nicknames are also permitted for pseudo-nodes. There >> is only one nickname allocation space. Every nickname in use in a >> campus designates either an RBridge or a pseudo-node and one or more >> nicknames also each designate a distribution tree. >> >> With this explanation, do you think that the draft text still needs >> clarification and if so do you have any suggestions? > Maybe section 3.7 could explicitly state that the distribution tree > nicknames and the RBridge nicknames are independent of one > another. Or if they are not, precisely explain the correlation. OK, how about adding the following at the end of 3.7.3: Every nickname in use in a campus identifies an RBridge (or pseudonode) and every nickname designates a distribution tree rooted at the RBridge (or pseudonode) it identifies. However, only a limited number of these potential distribution trees are actually computed by all the RBridge in a campus and they all compute the same set of distribution trees, as discussed in Section 4.5. >>> The document should explain the philosophy and usage of confidence >>> level with respect to the {port, VLAN, MAC address} tuples. This >>> discussion should also tie in the confidence configuration in >>> section 5.1. >> >> Well, how about something like the following new text: >> >> The confidence level mechanism allows an RBridge campus manager to >> cause certain address learning sources to prevail over others. In a >> default configuration, without the optional ESADI protocol, >> addresses are only learned from observing local native frames and >> the decapsulation of received TRILL data frames. Both of these >> sources default to confidence level 0x20 so, since learning at an >> equal or high confidence overrides previous learning, the learning >> in such a default case mimics default 802.1 bridge learning. >> >> While RBridge campus management policies are beyond the scope of >> this document, here are some example types of policies that can be >> implemented with the confidence mechanism and the rational for >> each: >> >> o Locally received native frames might be considered more reliable >> than decapsulated frames received from remote parts of the >> campus. To stop MAC addresses learned from such local frames >> from being usurped by remotely received forged frames, the >> confidence in locally learned addresses could be increased or >> that in addresses learned from remotely sourced decapsulated >> frames decreased. >> >> o MAC address information learned through a cryptographically >> authenticated Layer 2 registration protocol, such as 802.1X with >> a cryptographically based EAP method, might be considered more >> reliable than information learned through the mere observation >> of data frames. When such authenticated learned address >> information is transmitted via the ESADI protocol, the use of >> authentication in the TRILL EASDI LSP frames could make >> tampering with it in transit very difficult. As a result, it >> might be reasonable to announce such authenticated information >> via the ESADI protocol with a high confidence, so it would >> override any alternative learning from data observation. >> >> Manually configured address information is generally considered >> static and so defaults to a confidence of 0xFF while no other >> source of such information can be configured to a confidence any >> higher than 0xFE. However, for other cases, such as where the >> manual configuration is just a starting point which the Rbridge >> campus manager wishes to be dynamically overrideable, the >> confidence of such manually configured information may be >> configured to a lower value. > This would be good. In the last sentence, do you mean the MAC > addresses are dynamically learned or changing the configuration of > the confidence level? I suspect the former. Yes. I will replace "the manual configuration is" with "the manually configred MAC addresses are". Thanks, Donald >>>... > Thanks, > Acee > >... >> >> Thanks, >> Donald [document Editor] >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3@gmail.com From stbryant@cisco.com Fri Feb 26 02:13:56 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCDE3A8659 for ; Fri, 26 Feb 2010 02:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[AWL=-2.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijWcNMv4nKxk for ; Fri, 26 Feb 2010 02:13:55 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id CDB8A3A82B0 for ; Fri, 26 Feb 2010 02:13:54 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,545,1262563200"; d="scan'208";a="3807871" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 Feb 2010 09:43:51 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1QAG7vt023355; Fri, 26 Feb 2010 10:16:07 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o1QAG6X08797; Fri, 26 Feb 2010 10:16:06 GMT Message-ID: <4B879F65.5020604@cisco.com> Date: Fri, 26 Feb 2010 10:16:05 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Donald Eastlake References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> <1028365c1002252213sda034c6wb21a1dd3a1bfa5b5@mail.gmail.com> In-Reply-To: <1028365c1002252213sda034c6wb21a1dd3a1bfa5b5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , Acee Lindem , Ralph Droms , "trill-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:13:56 -0000 Donald > (I'm also adding an explict statement that it is > not a goal of TRILL to scale beyond the size of exisitng bridged LANs.) > When you say add a statement, are you thinking about a few words buried deep in the fine print, or a headline statement in capitals at the front of the form "THIS VERSION OF THE TRILL SPECIFICATION IS NOT CERTIFIED FOR DEPLOYMENT IN LARGE SCALE WIDE AREA NETWORKS!" The concern is that operators may use Trill for hollow core, in which case a protocol bug could bring down an ISP in a way that requires rebooting of their entire net. The intent of the warning is to make sure operators do adequate whitebox testing before they attempt any such deployment, and as such it needs to be suitably visible. - Stewart From db3546@att.com Fri Feb 26 12:53:33 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDCCB28C342 for ; Fri, 26 Feb 2010 12:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPGwQRiNPLVb for ; Fri, 26 Feb 2010 12:53:32 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id C477228C340 for ; Fri, 26 Feb 2010 12:53:32 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-9.tower-161.messagelabs.com!1267217747!21037329!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 19767 invoked from network); 26 Feb 2010 20:55:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Feb 2010 20:55:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1QKtc0i025171 for ; Fri, 26 Feb 2010 15:55:38 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1QKtXIW025080 for ; Fri, 26 Feb 2010 15:55:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {C6FCF98A-9E39-45EA-9468-EDF93EC32DAE} x-cr-hashedpuzzle: AL6N A5ZP A9zU CLji CPFP C8Ao FJdF FahI GISL GI3T HHp0 H0nA H00Q H5nb ISaT InHX; 1; cgB0AGcALQBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {C6FCF98A-9E39-45EA-9468-EDF93EC32DAE}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Fri, 26 Feb 2010 20:55:38 GMT; UgBvAHUAdABpAG4AZwAgAEEAcgBlAGEAIABEAGkAcgBlAGMAdABvAHIAYQB0AGUAIABSAGUAdgBpAGUAdwAgAFIAZQBxAHUAZQBzAHQAcwA= Content-class: urn:content-classes:message Date: Fri, 26 Feb 2010 15:55:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing Area Directorate Review Requests Thread-Index: Acq3Jgzt5enc/3xCSUaEMxdwm8FWQQ== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: Subject: [RTG-DIR] Routing Area Directorate Review Requests X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 20:53:33 -0000 Routing Area Directorate Members, As you may have noted, we have started the reviewing. Acee was the first (he gets an extra one of Adrian's lemonades) and you should all have his email with his review response. You will receive a request as the one below when you are assigned. As noted on our web page, please ACK to me within 24 hours (M-F) if you can do it (and per 5a, no reply is also presumed to be an ACK). If you are not available for reviewing, please let me know so I don't assign you.=20 Your Coordinator (currently under several feet of snow but still with electric) -----------------------------------------------------example------------ ------- >=20 > -----Original Message----- > From: Rtg Area Wiki [mailto:trac@tools.ietf.org]=20 > Sent: Saturday, February 06, 2010 2:40 PM > To: acee.lindem@ericsson.com; BRUNGARD, DEBORAH A (ATTLABS) > Cc: adrian.farrel@huawei.com; rcallon@juniper.net > Subject: Re: [Rtg Area Wiki] #2: Review of draft-ietf-trill-rbridge-protocol-15.txt >=20 > #2: Review of draft-ietf-trill-rbridge-protocol-15.txt > -------------------------------------------------------+---------------- ---- > Reporter: dbrungard@... | Owner: acee.lindem@... =20 > Type: review | Status: waiting =20 > Priority: major | Version: > Keywords: Trill RBridges Base Protocol Specification | Draft: draft-ietf-trill-rbridge-protocol-15.txt > -------------------------------------------------------+---------------- ---- > Changes (by dbrungard@...): >=20 > * status: open =3D> waiting >=20 >=20 > --=20 > Ticket URL: > Rtg Area Wiki >=20