Hi Donald, Your proposed changes look good to me. I will clear once the new version gets posted with the changes,
Thanks Suresh On 07/07/2016 10:04 AM, Donald Eastlake wrote: > 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
