Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

"Black, David" <david.black@emc.com> Sat, 24 November 2012 20:28 UTC

Return-Path: <david.black@emc.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 D9CB521F84F9 for <trill@ietfa.amsl.com>; Sat, 24 Nov 2012 12:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.412
X-Spam-Level:
X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOH-UuMz4UF5 for <trill@ietfa.amsl.com>; Sat, 24 Nov 2012 12:28:58 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 100E321F84F5 for <trill@ietf.org>; Sat, 24 Nov 2012 12:28:57 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAOKSsYH006711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2012 15:28:54 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 24 Nov 2012 15:28:45 -0500
Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAOKSiQ1025357; Sat, 24 Nov 2012 15:28:44 -0500
Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Sat, 24 Nov 2012 15:28:43 -0500
From: "Black, David" <david.black@emc.com>
To: "trill@ietf.org" <trill@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
Date: Sat, 24 Nov 2012 15:28:42 -0500
Thread-Topic: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
Thread-Index: Ac3CrWgm/VxKoubUThyzi08klgddGwHzWwYg
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284D3FF0C@MX15A.corp.emc.com>
References: <CAF4+nEH9_MkMTDDG7jn_xipXV-feu4Xy0GyH9NyNO_5EaNw3nQ@mail.gmail.com> <50A4095E.80009@acm.org>
In-Reply-To: <50A4095E.80009@acm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <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: Sat, 24 Nov 2012 20:28:59 -0000

Hi Linda,

Here are some (somewhat tardy) comments on this WG Last Call.

(1) As noted by some of the others who commented, more functionality
details would be good to add, especially on mixing of the push and
pull models in Section 5.  Cache consistency needs to be covered,
at least its invalidation portion, as relying solely on aging out
entries can black-hole traffic that uses a stale entry that hasn't
aged out yet.

(2) I also agree with Erik's earlier comment about not understanding
why Appointed Forwarders are in this draft.  If use of a directory
can relax Appointed Forwarder restrictions without causing problems
(e.g., loops), that needs to be explained somewhere, probably in
Section 4.  Otherwise, Appointed Forwarders should not be discussed.

(3) On the comment about capitalizing MUST, SHOULD and MAY, the 
applicable RFC is RFC 2119, but those terms are not ordinarily used
in requirements documents.  An explanation that these keywords
express requirements on protocol development should be provided in
order to use the upper case versions of these keywords.

Here are some more detailed comments:

Abstract:
   Edge RBridges currently learn the mapping between MAC addresses and
   their egress RBridges by observing the data packets traversed
   through.

Change to: ... by observing traffic that traverses the RBridge.

Section 1, 1st paragraph:

                (This ''blocked'' state
   has no effect of TRILL Data or IS-IS frames, which can still be sent
   and received. It only affects native frames.)

"of TRILL data" -> "on TRILL Data" in second line above.

In item 2 in the list, I'd change "usually" to "often":
   2. Topology is usually based on racks and rows.

In item 3 in the list, explain that server reload can change the MAC
address and why that change may be needed or desirable, because
Section 4 appears to assert that the MAC address can change.  If
that wasn't intended, this text in Section 4 needs attention for
physical servers (it's ok for VMs):

   When a VM is moved to a new
   location or a server is loaded with a new application with different
   IP/MAC addresses, it is more likely that the DA of data packets sent
   out from those VMs are unknown to their attached edge RBridges.  

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