Re: [trill] draft-yizhou-trill-arp-optimization-01
gayle noble <windy_1@skyhighway.com> Tue, 24 February 2015 03:21 UTC
Return-Path: <windy_1@skyhighway.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FDB1A00ED for <trill@ietfa.amsl.com>; Mon, 23 Feb 2015 19:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QJMm36qkHNS for <trill@ietfa.amsl.com>; Mon, 23 Feb 2015 19:21:26 -0800 (PST)
Received: from skyhighway.com (skyhighway.com [63.249.82.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9981A00BD for <trill@ietf.org>; Mon, 23 Feb 2015 19:21:26 -0800 (PST)
Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id t1O3LGNn073865 for <trill@ietf.org>; Mon, 23 Feb 2015 19:21:16 -0800 (PST)
Message-Id: <201502240321.t1O3LGNn073865@skyhighway.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 23 Feb 2015 19:21:15 -0800
To: "trill@ietf.org" <trill@ietf.org>
From: gayle noble <windy_1@skyhighway.com>
In-Reply-To: <CAF4+nEEbJQQ3e_LDR_BhRMWrXf-tZzB8OFS7UDy3EEFJJL=sWA@mail.g mail.com>
References: <20150214192017.15181.75809.idtracker@ietfa.amsl.com> <CAF4+nEEbJQQ3e_LDR_BhRMWrXf-tZzB8OFS7UDy3EEFJJL=sWA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/A6Hy68M_ILuigs4HAyLDOk8LoFE>
Subject: Re: [trill] draft-yizhou-trill-arp-optimization-01
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2015 03:21:27 -0000
I read this draft and have the following thoughts/comments about the ability of the written words to communicate the technology >*grin*< 1) Page 3 Terminology (I'd remove the word "is") The acronyms and terminology in [RFC6325] /is/ are used herein. Some of these are listed below for convenience with the following along with some additions: 2) page 3 At first I thought the acronym was repeated in the definition of the acronym instead of referring to a reference document. So, for clarity to other California Air Heads, I would replace the "[IA]" with [IA-draft] (so) IA - Interface Addresses, a TRILL APPsub-TLV[IA] (would be) IA - Interface Addresses, a TRILL APPsub-TLV [IA-draft] 3) page 3 IP/MAC Address Mappings (remove second "and" ) Traditionally an RBridge learns the MAC and /and/ Data Label (VLAN or FGL) to nickname correspondence of a remote host, as per [RFC6325] and [RFC7172], from TRILL data frames received. 4) page 4 - first paragraph (I'd replace the IA with IA-draft) (so) Addresses (IA) APPsub-TLV [IA] enhances the TRILL base protocol by allowing IP and MAC address mappings to be distributed in the control plane by any RBridge. (would become) Addresses (IA) APPsub-TLV [IA-draft] enhances the TRILL base protocol by allowing IP and MAC address mappings to be distributed in the control plane by any RBridge. 5) page 4 (reword) The information may be possibly from different sources. (to) The information may possibly be from different sources. 6) page 4 (as written) RBridges can then use the Flags Field in IA APPsub-TLV to identify if the source is a directory server or local observation by the sender. Different confidence level may also be used to indicate the reliability of the mapping information. (I'd re-word it to) RBridges can then use the Flags Field in IA APPsub-TLV to identify if the source is a directory server or a local observation by the sender. A different confidence level may also be used to indicate the reliability of the mapping information. 7) page 5 (I'd replace [IA] with [IA-Draft]) (so) The ingress RBridge may use the IA APPsub-TLV [IA] with the Local flag set in ESADI [RFC7357] to distribute any new or updated IP/MAC information obtained in this step. (becomes) The ingress RBridge may use the IA APPsub-TLV [IA-draft] with the Local flag set in ESADI [RFC7357] to distribute any new or updated IP/MAC information obtained in this step. 8) page 6 (I'd replace [IA] with [IA-draft]) (so) The RBridge may use an IA APPsub-TLV[IA]with the Local flag set to distribute the sender's MAC and IP mapping information. (becomes) The RBridge may use an IA APPsub-TLV[IA-draft]with the Local flag set to distribute the sender's MAC and IP mapping information. 9) last sentence page 6 top of page 7 ("initiate" should be "initiates" as R2 is the noun of the sentence at that point) If the ingress RBridge R1 decides to unicast the ARP/ND request to the target's egress RBridge R2 as discussed in subsection 3.2 item a) or to flood the request as per [RFC6325], then R2 decapsulates the query, and initiate [initiates] an ARP/ND query on the target's link. 10) Page 7 (I'd replace [IA] with [IA-draft]) (so) The update message can be carried by an IA APPsub-TLV [IA] with the Local flag set in ESADI [RFC7357] or as per [DirMech] if push directory server is in use. (becomes) The update message can be carried by an IA APPsub-TLV [IA-draft] with the Local flag set in ESADI [RFC7357] or as per [DirMech] if push directory server is in use. 11) page 7 (I think RARP is repeated twice) (as written) Handling RARP (Reverse Address Resolution Protocol) Messages RARP[RFC903] uses the same packet format as ARP but a different Ethertype (0x8035) and opcode values. (I think it should be) Handling RARP (Reverse Address Resolution Protocol) Messages[RFC903] uses the same packet format as ARP but a different Ethertype (0x8035) and opcode values. 12) page 7 just before IANA considerations (the word "to" was left out) The ingress RBridge should also rate limit the ARP/ND queries for the same target to be injected to the TRILL campus [to] prevent the possible attack. 13) page 9 (the word "Email" is not formatted the same for all emails. I think one format should be chosen and used in all documents. I prefer "Email" to EMail" but either is fine as long as they all are the same. ) EMail: liyizhou@huawei.com Email: d3e3e3@gmail.com EMail: ldunbar@huawei.com Email: Radia@alum.mit.edu EMail: igor@yahoo-inc.com 14) just a note Acronyms used might be nice to list them all in the document APPsub-TLV Application sub-Type-Length-Values ARP Address Resolution Protocol DAD Duplicate Address Detection DirMech Edge Directory Assist Mechanisms ESADI End Station Address Distribution Information FGL Fine-Grained Label IA Interface Addresses IP Internet Protocol MAC media access control address ND Neighbor Discovery RARP Reverse Address Resolution Protocol RBridge Routing Bridge SEND secure neighbor discovery TLV Type Length Value TRILL Transparent Interconnection of Lots of Links TRILL Tunneled Routing in the Link Layer TRILL switch an RBridge
- [trill] I-D Action: draft-ietf-trill-cmt-05.txt internet-drafts
- Re: [trill] I-D Action: draft-ietf-trill-cmt-05.t… Donald Eastlake
- Re: [trill] draft-yizhou-trill-arp-optimization-01 gayle noble
- Re: [trill] draft-ietf-trill-rfc7180bis-01 gayle noble
- [trill] 答复: draft-yizhou-trill-arp-optimization-01 Liyizhou
- Re: [trill] draft-yizhou-trill-arp-optimization-01 gayle noble
- Re: [trill] draft-ietf-trill-rfc7180bis-01 Donald Eastlake