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

Donald Eastlake <> Mon, 25 February 2013 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC0D221F9593 for <>; Mon, 25 Feb 2013 09:01:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.289
X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OP76HxR5GLjI for <>; Mon, 25 Feb 2013 09:01:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2DD6521F9563 for <>; Mon, 25 Feb 2013 09:01:08 -0800 (PST)
Received: by with SMTP id 16so3094733obc.5 for <>; Mon, 25 Feb 2013 09:01:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1LldWr8Mmo8rbZeF3U126Yh4sdR5TQza/A9S4To+UgM=; b=BfoKR5NarB9x2yGFZXz1chtUvsbgFb1QNSb2iTqsc8J2brW8foy3gG6Bq16kx3MmL7 LWDP+qmUSoYzP0Y6eb2jBN6jfAJRMjP70wawtdvLr0wQs/pIAO53WVy6Z6WjQwzdoJnN /lViRKwkU0GAEcGHDXn9CYuOdxyWz0AQx2/IHDC4u2vQo2AuHZfUboRxiSOOE5lG1y0J dRDtgfO2VF/Xa+Cb62o/UuW0rdW09uVVz74uWrgbdPc9bdqPXNyS4MrMa3o7WaLK0SEP sNFqjRJ2tMK9eUgkVFgrdAX3Tk4j8cvYWcrnmvWJMrdW+hYPwMVmqdDlGxUQQCtTFTz+ pVCQ==
X-Received: by with SMTP id n1mr4755143oee.39.1361811667598; Mon, 25 Feb 2013 09:01:07 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 25 Feb 2013 09:00:47 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Donald Eastlake <>
Date: Mon, 25 Feb 2013 12:00:47 -0500
Message-ID: <>
To: "Black, David" <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Feb 2013 17:01:24 -0000

Hi David,

Thanks for pointing out your earlier review and comments which were
partially responded to at the time.

I understand that you comments were on the -02 version. When I say
below something was done, I'm referring to the -03 version and when I
just say OK or indicate something will be done, I am referring to the
to be posted -04 version.

On Sat, Nov 24, 2012 at 3:28 PM, Black, David <>
> 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.

Functional detail is to be covered in
draft-dunbar-trill-scheme-for-directory-assist a new version of which
is about to be posted. The framework document is very high level and
it's primary purpose was to provide a means for the WG to indicate its
approval of pursuing this direction. However, we will put in a bit
more concerning cache consistency.

> (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.

References to Appointed Forwarders will be removed.

> (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.

Reference to RFC 2119 and capitalized implementation requirement words
were eliminated.

> 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.

Actually, I don't particularly like "traverses". It sound like
learning from transit frames, which TRILL switches do not do, although
the fact that it mentiones "Edge RBridges" helps. I think "
observing traffic they ingress or egress..." would be better.

> 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.

That wording has been removed.

> 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".

There are a number of occurrences of "draft" which should probably be
changed because it will not be a draft when it is published as an RFC.

> 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.

The wording will be improved.

> 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:
>    In data center environment, applications placement to servers,
>    racks, and rows is orchestrated by Server (or VM) Management
>    System(s).
>    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).

That seems like an improvement in wording.

> 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.

Since the point of the adoption of this document was the the TRILL WG
wishes to pursue directory assistence, I think that the recommendation
part should stay.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> Thanks,
> --David
>> -----Original Message-----
>> From: [] On Behalf Of Erik
>> Nordmark
>> Sent: Wednesday, November 14, 2012 4:13 PM
>> To:
>> 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
>> >