[trill] 答复: draft-yizhou-trill-arp-optimization-01

[Liyizhou <[e-mail]>]

Gayle, thanks for your review. Will update all the editorial changes.

Yizhou

-----邮件原件-----
发件人: trill [mailto:[e-mail]] 代表 gayle noble
发送时间: 2015年2月24日 11:21
收件人: [e-mail]
主题: Re: [trill] draft-yizhou-trill-arp-optimization-01

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: [e-mail]
Email: [e-mail]
EMail: [e-mail]
Email: [e-mail]
EMail: [e-mail]


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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/trill