Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
Linda Dunbar <linda.dunbar@huawei.com> Tue, 27 November 2012 16:11 UTC
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1338D21F8559 for <trill@ietfa.amsl.com>; Tue, 27 Nov 2012 08:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CNRGbiy2iqB for <trill@ietfa.amsl.com>; Tue, 27 Nov 2012 08:11:22 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E823B21F8557 for <trill@ietf.org>; Tue, 27 Nov 2012 08:11:20 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALY63579; Tue, 27 Nov 2012 16:11:19 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 16:11:09 +0000
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 16:11:16 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Tue, 27 Nov 2012 08:11:12 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Black, David" <david.black@emc.com>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
Thread-Index: AQHNyoJb9IC4oPdPSEevrN5yYyHkN5f92axA
Date: Tue, 27 Nov 2012 16:11:11 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450B6042@dfweml505-mbx>
References: <CAF4+nEH9_MkMTDDG7jn_xipXV-feu4Xy0GyH9NyNO_5EaNw3nQ@mail.gmail.com> <50A4095E.80009@acm.org> <8D3D17ACE214DC429325B2B98F3AE71284D3FF0C@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284D3FF0C@MX15A.corp.emc.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.136.166]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2012 16:11:23 -0000
David, Thank you very much for the detailed comments. I will incorporate them in the next revision. Some answers to your comments are inserted below: > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Saturday, November 24, 2012 2:29 PM > To: trill@ietf.org; Linda Dunbar > Subject: RE: [trill] WG Last Call: draft-ietf-trill-directory- > framework-01.txt > > Hi Linda, > > Here are some (somewhat tardy) comments on this WG Last Call. > > (1) As noted by some of the others who commented, more functionality > details would be good to add, especially on mixing of the push and > pull models in Section 5. Cache consistency needs to be covered, > at least its invalidation portion, as relying solely on aging out > entries can black-hole traffic that uses a stale entry that hasn't > aged out yet. > [Linda] This framework is mainly to cover the benefits of directory service. I will add some high level description, however I will try not to repeat the description in the mechanism draft which covers the details of caching and policy of pull/push. > (2) I also agree with Erik's earlier comment about not understanding > why Appointed Forwarders are in this draft. If use of a directory > can relax Appointed Forwarder restrictions without causing problems > (e.g., loops), that needs to be explained somewhere, probably in > Section 4. Otherwise, Appointed Forwarders should not be discussed. [Linda] Agree. Will change accordingly. > > (3) On the comment about capitalizing MUST, SHOULD and MAY, the > applicable RFC is RFC 2119, but those terms are not ordinarily used > in requirements documents. An explanation that these keywords > express requirements on protocol development should be provided in > order to use the upper case versions of these keywords. > [Linda] Will change per you comments. Thanks. > Here are some more detailed comments: > > Abstract: > Edge RBridges currently learn the mapping between MAC addresses and > their egress RBridges by observing the data packets traversed > through. > > Change to: ... by observing traffic that traverses the RBridge. > > Section 1, 1st paragraph: > > (This ''blocked'' state > has no effect of TRILL Data or IS-IS frames, which can still be sent > and received. It only affects native frames.) > > "of TRILL data" -> "on TRILL Data" in second line above. > > In item 2 in the list, I'd change "usually" to "often": > 2. Topology is usually based on racks and rows. > > In item 3 in the list, explain that server reload can change the MAC > address and why that change may be needed or desirable, because > Section 4 appears to assert that the MAC address can change. If > that wasn't intended, this text in Section 4 needs attention for > physical servers (it's ok for VMs): > > When a VM is moved to a new > location or a server is loaded with a new application with different > IP/MAC addresses, it is more likely that the DA of data packets sent > out from those VMs are unknown to their attached edge RBridges. > > Item 4 should follow up on the mention of subnets in item 3 and > observe that multiple subnets on the same port at the same time is > common for server virtualization and the change rate is higher than > for physical servers. > > In the definition of "Bridge", change "draft" to "document". > > Section 3, p.6, first bullet - change both instances of "RB1" to > "an RBridge" as there's no RB1 in figure 1. > > The last bullet in Section 3.1 is a bit sloppy about its use of the > word "entries". It needs to explain exactly what is in an "entry" - > it might be possible to do this in an introduction by stating that > the presence of an entry (and list what it contains) avoids flooding > of inbound frames that match the entry. > > Section 3.2, Scenario #1 - The use of the word "uplink" is confusing, > overly constraining and not necessary. The important concept is how > many ToR switches are in each rack. It's quite feasible for a server > or switch in a rack to have multiple uplinks to the same ToR (e.g., > when the links are 1 Gigabit Ethernet). > > Section 4, first sentence: > OLD > In data center environment, applications placement to servers, > racks, and rows is orchestrated by Server (or VM) Management > System(s). > NEW > In a data center environment, the assignment of applications > to servers, including rack and row selection, is orchestrated > by Server (or VM) Management System(s). > END > > I'd suggest deleting Section 6 (Conclusion and Recommendations), > as it's important for considering what the WG will do, but may not > have much value in a published RFC. > > > Thanks, > --David > > > -----Original Message----- > > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On > Behalf Of Erik > > Nordmark > > Sent: Wednesday, November 14, 2012 4:13 PM > > To: trill@ietf.org > > Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory- > framework-01.txt > > > > > > We would really like to she some more explicit indications from WG > > participants that they have read this document and agree with it. > > > > Please include any substantial as well as editorial improvements that > > result from reviewing the document. > > > > Erik > > > > On 10/25/12 3:55 PM, Donald Eastlake wrote: > > > This message begins a TRILL WG two week Last Call on the > > > draft-ietf-trill-directory-framework draft. > > > > > > Thanks, > > > Donald > > > ============================= > > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > > 155 Beaver Street, Milford, MA 01757 USA > > > d3e3e3@gmail.com > > > _______________________________________________ > > > trill mailing list > > > trill@ietf.org > > > https://www.ietf.org/mailman/listinfo/trill > > > > > > > _______________________________________________ > > trill mailing list > > trill@ietf.org > > https://www.ietf.org/mailman/listinfo/trill
- [trill] WG Last Call: draft-ietf-trill-directory-… Donald Eastlake
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Erik Nordmark
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Radia Perlman
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Erik Nordmark
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Sam Aldrin
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Thomas Narten
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Yizhou Li
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Black, David
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Linda Dunbar
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Donald Eastlake
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Black, David
- Re: [trill] WG Last Call: draft-ietf-trill-direct… Donald Eastlake