[trill] Comments on draft-ietf-trill-directory-framework-01
Erik Nordmark <nordmark@acm.org> Thu, 15 November 2012 00:03 UTC
Return-Path: <nordmark@acm.org>
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 D480021F854E for <trill@ietfa.amsl.com>; Wed, 14 Nov 2012 16:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 lbq3ruhmDM7j for <trill@ietfa.amsl.com>; Wed, 14 Nov 2012 16:03:18 -0800 (PST)
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC5321F853F for <trill@ietf.org>; Wed, 14 Nov 2012 16:03:18 -0800 (PST)
Received: from [10.154.212.171] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id qAF03FLb001668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 16:03:15 -0800
Message-ID: <50A43143.6000209@acm.org>
Date: Wed, 14 Nov 2012 16:03:15 -0800
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "trill@ietf.org" <trill@ietf.org>
References: <50A42C5A.9060004@acm.org>
In-Reply-To: <50A42C5A.9060004@acm.org>
X-Forwarded-Message-Id: <50A42C5A.9060004@acm.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [trill] Comments on draft-ietf-trill-directory-framework-01
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: Thu, 15 Nov 2012 00:03:18 -0000
[Resent with a better subject to make it easier to correlated emails to internet-drafts. Please respond to this email.] Some questions and comments on the draft from the perspective of one WG participant (i.e., without my chair hat). Also, I hope this will stimulate some WG discussion and getting more folks to read and comment on the draft. In the abstract (and repeated in the introduction) we have: Edge RBridges currently learn the mapping between MAC addresses and their egress RBridges by observing the data packets traversed through. When an ingress RBridge receives a data frame with its destination address (MAC&VLAN) unknown, the data frame is flooded within the VLAN across the TRILL campus. The above text doesn't take into account the existence of ESADI. It makes sense to reword it to state that data-plane learning is mandatory and ESADI is optional, and that flooding occurs when ESADI is not used. The following sentence (also in the abstract *and* intro) seems unrelated to the topic of the draft, since the draft doesn't talk about changing AF (and I don't see how a directory can change how AF works): When there are more than one RBridge ports connected to one bridged LAN, only one of them can be designated as the Appointed Forwarder port for forwarding/receiving native traffic to/from each VLAN, the other RBridge ports on that LAN have to be disabled for native traffic in that VLAN. In section 5 you list the benefits, but the list doesn't include any benefits related to getting the ARP/ND information from the directory. Shouldn't that be added? [But also see the last comment below] In section 5 you have: [IP, MAC, attached RBridge nickname, {list of interested RBridges}] I suspect VLAN (or FGL) should be added to the above list. I think ESADI allows a <MAC,VLAN> or <IP,VLAN> be attached to more than one RBridge, which would imply that a table with the above structure would have multiple attached RBrudge nicknames. Also, a host can definitely have multiple IPv4 and IPv6 addresses on the same network interface, resulting in multiple rows in the above table that only differs in the IP address. It isn't clear to me if the "list of interested RBridges" is needed. It assumes that it is cost-effective to track everybody that might have cached the information and do selective update of those RBridges, as opposed to sending updates to any RBridge interested in that VLAN. In any case, the list of interested only applies to a pull model. In Table 1 there are no IP addresses; I would assume that they would be pushed as well. In section 5.3 there is a description of how RBridges cache the information from the directory, but there is no discussion of how that cached information would be updated should the destination (IP, MAC, VLAN) change. There should at least be a sentence saying that there needs to be a mechanism for the directory to invalidate or update cached information when that information is stale due to a change in the directory content. Finally I was under the impression that the draft would reduce ARP/ND traffic by leveraging getting IP->MAC address bindings from the directory. But I don't see any text about this for push nor pull. As currently specified the document doesn't reduce any ARP/ND traffic - it merely optionally uses ARP/ND packets to trigger directory lookups. Hence I'm a bit confused about the scope of the draft. I was assuming that the draft would specify that an ingress rbridge would intercept ARP requests (and Neighbor Solicitations) and use the information from the directory (whether push or pull) to unicast the ARP/NS to the egress rbridge, thereby avoid flooding the ARP/ND to all the rbridges in the VLAN. Erik
- [trill] directory cmt Erik Nordmark
- [trill] Comments on draft-ietf-trill-directory-fr… Erik Nordmark
- Re: [trill] directory cmt Linda Dunbar