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