[rbridge] Fwd: Review of draft-ietf-trill-rbridge-protocol-13.txt
Donald Eastlake <d3e3e3@gmail.com> Fri, 04 September 2009 04:40 UTC
Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F023A682C for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Thu, 3 Sep 2009 21:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Level:
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, GB_I_LETTER=-2]
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 IC-zdNccZD1f for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Thu, 3 Sep 2009 21:40:22 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 575033A659B for <trill-archive-Osh9cae4@lists.ietf.org>; Thu, 3 Sep 2009 21:40:22 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n841j6N8005661; Thu, 3 Sep 2009 18:45:08 -0700 (PDT)
Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n841iVjk005552 for <rbridge@postel.org>; Thu, 3 Sep 2009 18:44:32 -0700 (PDT)
Received: by ewy10 with SMTP id 10so515422ewy.13 for <rbridge@postel.org>; Thu, 03 Sep 2009 18:44:27 -0700 (PDT)
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 :content-transfer-encoding; bh=oWuE9RIuozF5mt0jgdKHQtZ+pQWtjjGkDv4p4n0K+Ew=; b=tMUP0rNG3FkRWH9UmyJJquDhQ86uktUorwxc1dxa8wPGycpGbs0t+gTsi0Js4S/tqG +DLzHRtEtjgfbL0sO3vg+E3tUjIeMASnAl44VoDeHyQijpkKwFiF5f6Op4v5TfJSJ85L WVvCuJy8sjJhQh6Jy+EFcZBhasHOcZH95MztY=
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:content-transfer-encoding; b=FsXy1YUo8QoU+fd+c6I3d+iWeCO7aOv6lUih/X1kwDtlM0iuZVW7BLFtXFI7ChFkJN AZLsa5hUprBmXsc/a2EjYoIYPaw9tdqk+HXaB1AqBPImpD0U37KiTVgRZxwxenINXVUO Kh9mVvfdJup7s+pVb2BBY+8oOjlTJM+kjBv94=
MIME-Version: 1.0
Received: by 10.216.88.65 with SMTP id z43mr657551wee.5.1252028667350; Thu, 03 Sep 2009 18:44:27 -0700 (PDT)
In-Reply-To: <1028365c0909031208m46af5055n5376f67fc1ea6f49@mail.gmail.com>
References: <EDC652A26FB23C4EB6384A4584434A0401984C29@307622ANEX5.global.avaya.com> <1028365c0909031208m46af5055n5376f67fc1ea6f49@mail.gmail.com>
Date: Thu, 03 Sep 2009 21:44:27 -0400
Message-ID: <1028365c0909031844v433114d0r1129b8f70b081312@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
To: Dan Romascanu <dromasca@avaya.com>, rbridge@postel.org
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id n841iVjk005552
Cc: Bernard Aboba <Bernard_Aboba@hotmail.com>, Ralph Droms <rdroms@cisco.com>
Subject: [rbridge] Fwd: Review of draft-ietf-trill-rbridge-protocol-13.txt
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
My apologies. Somehow my previous try at posting this got truncated, Below should be the full response. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com ---------- Forwarded message ---------- From: Donald Eastlake <d3e3e3@gmail.com> Date: Thu, Sep 3, 2009 at 3:08 PM Subject: Re: Review of draft-ietf-trill-rbridge-protocol-13.txt To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, rbridge@postel.org Cc: Erik Nordmark <erik.nordmark@sun.com>, Ralph Droms <rdroms@cisco.com>, ext Bernard Aboba <bernard_aboba@hotmail.com> Hi Dan, Thanks for your efforts in providing these detailed comments. On Sun, Aug 30, 2009 at 8:41 AM, Romascanu, Dan (Dan)<dromasca@avaya.com> wrote: > I was asked by the TRILL WG chairs to perform a review of > draft-ietf-trill-rbridge-protocol-13.txt. Below please find my findings. > > I appreciate the work put by the editors and WG in designing this > solution and writing the document. The editors are to be saluted for > writing an I-D which is in most parts clear and well organized. > > I do believe that this work and the document as it stands still have a > number of problems that need to be solved. > > 1. I have serious reservations that this document can directly go to > Proposed Standard. For reasons detailed below there is a lot of > incertitude in what concerns the interoperability or coexistence with > the layer 2 protocols designed in the IEEE. Many of these are still work > in progress. For this good reason in many places the document is forced > to make assumptions and cannot make but statements like 'Rbridges are > generally compatible with IEEE ...' (section 2.4.2). Has the WG > discussed the option of issuing the first version of this document as > Experimental? It is true that many IEEE 802.1 standards efforts are "work in progress". But with the ever multiplying number of efforts in 802.1, this situation seems permanent. To wait for 802.1 standards efforts to end would be to wait forever. There is no actual question concerning the interoperability of TRILL with current 802.1 protocols. Section 2 of the draft is a broad overview. That is the reason it says "... RBridges are generally compatible with IEEE [802.1Q-2005] customer bridges ..." in Section 2.4.2. If all the details were given in Section 2, it wouldn't be a broad introductory overview. To avoid misleading readers, that phrase should probably be changed to "... RBridges are compatible with IEEE [802.1Q-2005] customer bridges except as discussed in this document ...". I cannot recall any status other than Proposed Standard ever being suggested in the TRILL working group for this document. The TRILL protocol has had more review by routing and bridging network experts than most IETF protocols at the Proposed Standard level. TRILL has been implemented in software, tested, and the results of that testing included back in the protocol design. Multiple vendors are very interested in TRILL and I predict that RBridge products will ship in 2010. > 2. It looks to me like the motivation of the standard is frozen in time > into a period of evolution of the IEEE 802.1 technology trying to solve > some problems that were in part dealt with by the IEEE in the meantime. > Out of the four spanning tree bullets listed in the introduction as > problems that TRILL solves the second and the fourth seem to have been > dealt with by the IEEE 802.1aq and the IEEE 802.1ak respectively. It appears to me that this comment does not suggest any changes in the draft. But, as a response, the TRILL WG was created by the IETF to produce a standard subsequent to substantial discussion of the fact that, after it rejected TRILL technology, IEEE 802.1 then started an effort with similar goals. (And after the IEEE 802 Executive Committee stated that it had no objection to the IETF pursuing development of a TRILL standard.) > 3. All the VLAN discussions in the specification mention only the > C-VLANs. What about provider bridges? Can these be migrated to Rbridges? > The explanation in Appendix E is not sufficient, the compatibility with > provider bridges needs to be dealt in the core part of the I-D. The TRILL protocol specified in this draft is, as stated in the draft, a customer bridge standard. The draft is careful to refer to 802.1Q-2005 all over the place. An IEEE 802.1Q-2005 bridge is a purely customer bridge. This TRILL protocol specification does not try to solve the provider bridge problem. (I believe it would be relatively easy to extend TRILL to do that but it should be done in a separate document.) Provider bridges (and provider backbone bridges) cannot be replace by customer bridges, whether those customer bridges are 802.1 customer bridges or RBridges based on this spec. On the other hand, as stated in Appendix E, provider bridges (and/or provider backbone bridges) can be used to transparently interconnect parts of an RBridge campus. Since RBridges are compatible with provider bridges and provider backbone bridges, as I understand the word compatible, I don't understand what there is to "deal" with. However, an appropriately reworded version of the paragraph just above this paragraph can certainly be added to the main body of the draft. > 4. There needs to be more discussion about the IEEE protocols that do > not define forwarding or tagging. If TRILL makes a claim that the best > migration policy is to replace IEEE bridges by Rbridges it needs to > define behavior relative to protocols like IEEE 802.1AE Media Access > Control (MAC) Security, IEEE 802.1AB Station and Media Access Control > Connectivity Discovery, and IEEE 802.1aj Two Port Media Relay, as > bridges and end stations that are being replaced may support any or a > combination of these. This document does not claim that the best migration policy is incremental replacement, just that a network of 802.1Q-2005 customer bridges will, with the differences described in the document, operate correctly if some or all are replaced by RBridges. 802.1 protocols such as 802.1AE, 802.1AB, and 802.1X and 802.3 protocols such as Link Aggregation are logically implemented within ports. It makes no difference whether those ports are ports on 802.1D or 802.1Q or RBridge or IP router devices. (And, assuming they continue to develop in the direction it appears they are going, this will also be true of 802.1Qaz and 802.1Qbb.) This layering is covered in overview Section 2.4.1 and in more detail in Section 4.9.2 of the draft. As far as I can see, the draft makes RBridge "behavior relative to" this type of protocol, which is that they are orthogonal, clear. It would be true that if someone is incrementally replacing 802.1Q-2005 bridges that are using one or more of these, for want of a better term, "port level" protocols, such as 802.1AE, with RBridges, then obviously they need to use RBridges that also have the same port level protocols configured the same way. A statement to that effect could be added to the draft. 802.1aj is a work in progress. Although referred to as a "type of bridge", as currently specified 802.1aj devices are, as far as I can tell, a fancy type of repeater. For example, to quote from 802.1aj Draft D4.0, "A MAC Relay is transparent to all frame-based media independent protocols except those explicitly addressed to this device." (Of course, 802.1aj repeaters have a management interface and any node, whether a bridge or end station, could have independent functionality added to it to interact with that management interface, but I don't think of that as a change in the bridge or end station functionality.) A statement could be added to the draft saying "RBridges are compatible with IEEE 802.1aj devices as currently specified, in the same sense that IEEE 802.1Q-2005 bridges are compatible with such devices." or the like. > 5. For all the reasons above I think it is required that this document > is also reviewed in detail by IEEE 802.1. I suggest that a formal review > be required via a liaison letter before or during IETF Last Call. A review by IEEE 802.1 has been done. The TRILL draft has been modified based on that review (see item 2 of "Changes from -12 to -13" in Appendix Z). > 6. It would be good to add a section that provides some estimates about > the operational impact of the deployment of TRILL. For example a claim > is made that TRILL will allow internal forwarding tables to be > substantially smaller than in conventional bridges (Abstract). How much > smaller? Is there an estimation of the level of extra traffic created by > TRILL? Any recommendations on tuning to make it more efficient? The reason that forwarding tables are expected to be smaller is explained in the draft. From the explanation given, it seems fairly clear that the amount smaller primarily depends on the ratio between the number of RBridges and the number of end stations. What "extra" traffic do you refer to? The normal IS-IS control traffic? If so, no, the working group has not produced an estimate of how much IS-IS control traffic would be added. Nor has it produced an estimate of how much the automatic use of shortest paths would decrease traffic on the average link. There has been no work yet (although, of course, this could be added to a future Charter revision) on tuning of parameters. My opinion is that it is premature to do so before TRILL is actually deployed in a variety of environments. > 7. The claim made in the introduction section about TRILL avoiding the > problem of the 'significant configuration' required by the IP routers is > not substantiated but what follows. My reading of section 4.8.1 is that > although management configuration of ports and VLAN parameters is not > mandatory, it is highly recommended, and in its absence the protocol > cannot be expected to perform efficiently. Routers require subnet address configuration. Bridges, including RBridges, do not require any similar address configuration. This is what is being referred to and this can be clarified in the draft. Need for VLAN configuration depends on application. I do not see how it makes sense to make the blanket claim that "management configuration of ports and VLAN parameters" is "highly recommended". It is needed for some applications and totally unnecessary for others. > 8. Speaking about configuration parameters I could not locate the place > where the default interval between TRILL hello messages is defined and > how it can be changed. Maybe I missed it, if not please add this. This is deferred to the IS-IS standard and/or IETF ISIS WG. The Holding Time for a port is an IS-IS configuration parameter. The number of Hellos per Holding Time, facilities for adding timing jitter to avoid self-synchronization, etc., are all specified in IS-IS. It would be reasonable to add a statement such as "TRILL Hellos should be sent with the same timing as IS-IS LAN Hellos." or the like. > 9. In section 2, page 13, there is a recommendation to support SNMPv3 > over IP. I think this actually should be mapping of SNMPv3 over UDP over > IPv4 (RFC 3417) and mapping of SNMP over UDP over IPv6 (RFC 3419) OK, that recommendation can be made more precise and explicit as suggested. > 10. I find confusing the claim in section 2.4.2 > 'If the bridges replaced by > RBridges were zero configuration bridges, then their RBridge > replacements will not require configuration." > > I do not know what 'zero configuration' bridges are. I do not see an > Rbridge behaving better than a IEEE 802 bridge without configuration. > See also my comment #7. "Zero configuration" means no configuration has been done, i.e., it is run as out of the box with default settings, as in the former IETF ZEROCONF working group. That phrase can be replaced with something clearer. Is there any particular wording you would suggest? By definition "unmanaged bridges", a well known product category, are zero configuration because there is no way to configure them. A "managed bridge" would be zero configuration if its configuration features were not used. All the quoted text is saying is that default configuration 802.1Q-2005 bridges can be incrementally replaced by default configuration RBridges. As I say, this can be clarified. > 11. In section 4.1.1 > > " As specified in [802.1Q-2005], the priority field contains an > unsigned value from 0 through 7 where 1 indicates the lowest > priority, 7 the highest priority, and the default priority zero is > considered to be higher than priority 1 but lower than priority 2." > > This does not seem accurate, see Annex G in IEEE 802.1D-2005 Indeed, the draft does not reflect the 802.1D-2004 standard, which specifies priority 2 as "spare". However, the draft's target is 802.1Q-2005 bridges. 802.1Q-2005 is specifically cited in the quoted text above. In Appendix G of 802.1Q-2005 (page 282), priorities are specified as described in this draft. In particular, in 802.1Q-2005, priority 2 is specified as "Excellent Effort" and is the priority between 0 and 3. > 12. Section 4.3.1 - it would be good to justify where the figure 1470 > comes from. Also note that an end-station would not support such an MTU > unless it supports IEEE 802.3as, so it would be good to explain how > problems are avoided when an Rbridge replaces an IEEE 802.1 bridge that > connects to end-stations. The problem was TRILL IS-IS frames too long to go through classic 1512 byte limit (called "basic frame" in 802.3as-2006) or possibly 1516 byte (called "Q-tagged frame" in 802.3as-2006) limit devices between RBridges. I believe what 802.3as-2006 adds to previous 802.3 standards is an "envelope frame" with a limit of 1996 bytes, which doesn't seem relevant as it is much larger than 1470. (I'm including the source and destination MAC addresses in these lengths. The lengths given in 802.3as-2006 are 12 bytes smaller but do not include those addresses.) The problem is in being sure that IS-IS control messages (except, of course, MTU size test messages that exceed the MTU) can get through inter-RBridge links and the draft can be clarified to say so. End stations are not relevant to the problem although, I would think, they would mostly support the classic "basic frame" size or larger and thus be able to handle 1470. 1470 was an engineering compromise between TRILL WG members as a value which, with reasonable additional headers/tags/encapsulation/..., would be extremely unlikely to run into MTU problems in real world use of TRILL on IEEE 802.3 links. Some thought this default should be a little lower or higher. In any case, this parameter can be configured and the lowest configured value for an RBridge in the campus controls. > 13. I am confused about the need for section 5. The first part that > talks about assignment of multicast addresses seems redundant with > content in the IANA/IEEE considerations section. The second part tries > to list parameters that are configurable per Rbridge and per port? Than > many of the parameters listed in 4.8 and 4.9 are missing. I guess Section 5 is an artifact of the way the document evolved. It would indeed be an improvement to remove the first part and either remove the second part and the whole section or make the second part complete. > 14. Section 7.1 - I do not think that there is a need for registries of > the version numbers or Header reserved bits - these would be defined in > later versions of the protocol. For the TRILL Nicknames registry, the > appropriate RFC 5226 policy term is 'RFC Required' rather than 'RFC > Publication'. OK, that section can be modified as suggested. Thanks for the correction re RFC 5226 policy terms. > 15. Normative References - [802.3] has a 2008 edition Thanks for pointing out the update. > 16. Annex E will certainly evolve in time until publication, as the IEEE > 802.1 documents are also in evolution. At this point in time I would > suggest to add IEEE 802.1AB, IEEE 802.1AE and IEEE 802.1aj. Also IEEE > 802.1aq, IEEE 802.1Qaw and IEEE 802.1Qay have been approved in the > meantime. Well, if something like Appendix E is included in a draft, it will always just be a snapshot. To avoid continuing change later in the process, perhaps it should be frozen as of a specific date and that date cited in the Appendix. Perhaps the date the draft is forwarded to the TRILL WG Area Director. Appendix E is currently limited to completed and in process amendments to IEEE 802.1Q-2005. As such it should include 802.1aj. It could be expanded to include other relevant 802.1 standards and 802.1 standards efforts. Indeed, 802.1Qaw was approved on 25 July 2009 and 802.1Qay was approved on 5 August 2009, both after the date of this draft, and their status should be updated. However, it looks to me like 802.1aq is still a work in progress. > I hope this helps. > > Regards, > Dan Note: In a number of cases above it says something "could" be changed or added in the draft. That word is used because some discussion may be required in the working group as to what is best. Thanks, Donald (responding as the document editor) _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge
- [rbridge] Review of draft-ietf-trill-rbridge-prot… Romascanu, Dan (Dan)
- Re: [rbridge] Review of draft-ietf-trill-rbridge-… Donald Eastlake
- [rbridge] Fwd: Review of draft-ietf-trill-rbridge… Donald Eastlake
- Re: [rbridge] Review of draft-ietf-trill-rbridge-… Caitlin Bestler
- Re: [rbridge] Review of draft-ietf-trill-rbridge-… FEDYK Don
- [rbridge] Comments on draft-ietf-trill-rbridge-pr… Bernard Aboba
- [rbridge] Review of draft-ietf-trill-rbridge-prot… Roger Lapuh
- Re: [rbridge] Review of draft-ietf-trill-rbridge-… Caitlin Bestler
- Re: [rbridge] Review of draft-ietf-trill-rbridge-… Radia Perlman
- Re: [rbridge] Review of draft-ietf-trill-rbridge-… Donald Eastlake
- Re: [rbridge] Comments on draft-ietf-trill-rbridg… Donald Eastlake
- Re: [rbridge] Comments on draft-ietf-trill-rbridg… Donald Eastlake
- [rbridge] Fwd: Comments on draft-ietf-trill-rbrid… Donald Eastlake
- Re: [rbridge] Comments on draft-ietf-trill-rbridg… Donald Eastlake