Hi Suresh, Thanks for your insightful comments. See below.
On Wed, Jul 6, 2016 at 12:36 AM, Suresh Krishnan <[email protected]> wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-trill-arp-optimization-06: Discuss > > ... > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > * After the ingress RBridge learns the mapping between an IPv6 address > and a MAC address how is the liveness being tested/maintained? i.e. If a > "learnt" target IP goes off link and the Rbridge keeps responding to NS > messages wouldn't it make troubleshooting a nightmare? There needs to be appropriate liveness determination. There are a lot of ways this could be done but rather than going into this here, I think that a section should be added to the document on this topic. (Exactly what would happen if and IPv6 end station crashed or got disconnected would depend on many factors. In some cases the edge RBridge would know right away if it was a point-to-point link that went down. But optimized ARP/NS responses should stop not long after the end station becomes non-responsive to ARP/NS messages it receives directly.) > * Section 3.2 case a): There is no guidance as to why or when an Rbridge > would pick cases a1..a5. e.g. When a SEND NS is received only option a2 > can work and all others will fail. Yes, the restrictions on SEND should be noted. Otherwise, the choice is a matter of local policy. > * Section 3.2 case a.1): What should be the source IPv6 address of the NA > generated by the ingress RBridge? Will this be an address of the target > of the NS or one of the ingress Rbridge that responds? There is no requirement in the TRILL protocol that an RBridge have either an IPv4 or IPv6 address (although as a practical matter, they probably almost always do). So the source IPv6 address should be that of the target. > * Section 3.2: How is an ND message where the target IP is not known > handled? This case seems to be left out. If the target IP is "unknown", then generally you would flood based on the destination MAC within the VLAN/Label of the traffic but if you were in an environment with complete directory information and you know that IP did not exist, I think you could just discard the message. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * The draft contains no discussion of SEND (RFC3971) in the Security > considerations section when talking about forged ND messages. Yes, I think that should be mentioned. 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
