Donald: Hi!
Thanks for your answers! I'll clear the DISCUSS once the document is updated. Thanks! Alvaro. On 7/29/16, 7:19 PM, "Donald Eastlake" <[email protected]> wrote: >Hi Alvaro, > >On Wed, Jul 6, 2016 at 11:13 PM, Alvaro Retana <[email protected]> >wrote: >> Alvaro Retana has entered the following ballot position for >> draft-ietf-trill-arp-optimization-06: Discuss >> >> ... >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I know this is an optional optimization, as described by the ³MAY² >> in the Introduction. However, some of the other normative language >> is not as strong as it should be to clearly specify the required >> behavior (if the mechanisms are being used), cause confusion, or is >> simply out of place. >> >> 1. In 3.1 (Get Sender's IP/MAC Mapping Information for Non-zero IP) >> the text says that the ³RBridge MAY use different strategies to do >> so². That ³MAY² contradicts the ³SHOULD² used before it, which >> directs the RBridge to verify a duplicate address. s/MAY/may > >OK. > >> 2. Still in 3.1: ³Šthe RBridge SHOULD verify if a duplicate IP >> address has already been in useŠ² What are the reasons where the >> RBridge would not verify this situation? IOW, why is this ³SHOULD² >> not a ³MUST²? > >If the network manager's philosophy is have the network behave as if >the relevant set of end stations were on a single link and just >believe an ARP it received, it might not do anything to try to verify >conflicting prior attachment information. > >> 3. I¹m confused as to whether the APPsub-TLV is required or not. >> The source of my confusion comes from Section 3.3 (Determine How to >> Handle the ARP/ND Response) which says that ³R2 SHOULD initiate a >> link state update to inform all the other RBridges of the target's >> locationŠThe update message can be carried by an IA APPsub-TLV >> [IA-draft]Š² This text seems to say that the APPsub-TLV SHOULD be >> used to carry the information ‹ but text in Section 2 (IP/MAC >> Address Mappings) sounds to me as if the use of the APPsub-TLV is >> optional: ³If the RBridge has extracted the sender's IP/MAC address >> pair from the received data packet (either ARP or ND), it MAY save >> the information and use the IA APPsub-TLVŠ² Also, 3.1 and 3.2 both >> say that an ³RBridge MAY use the IA APPsub-TLV². And finally the >> Security Considerations section seems to recommend using itŠ Maybe >> it¹s just me, but please clarify. [BTW, if it is required, then I >> think that both the IA-draft and DirMech references should be >> Normative.] > >I agree that the wording should be clarified. > >RBridges are interested in the nickname of the RBridge to which some >destination address is attached, since RBridges route on nickname. This >information can be communicated for IP addresses with IP reachability >link state TLVs and for MAC addresses with MAC reachability link state >TLVs (each genrally within the scope of a VLAN (or FGL)). However, for >ARP/RARP/ND optimization, you generally want to know the MAC<->IP >mapping which is absent with separate MAC and IP reachability. > >The IA APPsub-TLV is, as far as I know, the only link state data >format that can be used to bind together the MAC and IP address(es) >for an interface (port), as well as providing the nickname of the >RBridge to which that interface is attached and possibly other >information. Thus, if you are to communicate information useful to, >for example, provide a locally created response to an ARP, you need to >use IA APPsub-TLV. > >> 4. In Section 2 (IP/MAC Address Mappings) the ³MAY² in the following >> sentence is out of place since that is already the function of the >> confidence (as described in draft-ietf-trill-ia-appsubtlv and >> RFC6325): ³A different confidence level MAY also be used to indicate >> the reliability of the mapping information.² > >That should be a lower case "may" (or perhaps "can" or something else). > >> 5. In Section 3.2 (Determine How to Reply to ARP/ND), both options >> (?) a and b say that the ³RBridge MAY take oneŠ². If the RBridge >> selected that option, then I think the action is no longer optional. >> s/MAY/MUST > >OK. > >Thanks, >Donald >=============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
