Adrian Farrel has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated Discuss after Telechat conversation with Brian. I have moved my first point into a Comment and added some clarification. --- Shouldn't you describe some manageability considerations? What events should be logged? What access to the stored informaiton should be provided? (For example, should the operator be able to read the Binding Table?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In my Discuss I originally wrote: > I don't see any discussion of the size of the Binding Table. In > fact, it seems to be assumed to be "large enough". History shows > that we are not good at guessing the value of "large enough" and > certainly the application of this mechanism to VPNs makes this a > little worrying. That probably means that the document needs to > describe what happens when the Binding Table is full. Might be as > simple as handling the failure case in 4.2.1. First, don't be distracted by the VPN thing. I am just asking about what happens when a BNG receives a Neighbor Solicitation message and is unable to store the tentative address as mandated in Section 4.2.1. Brian says that the protocol is unreliable, so it is as simple as making a local decision to drop the message or flush an entry from the cache. That sounds fine to me, and I started to look for text in the I-D that describes "lost message", "cache full", "cache cycling", and "cache timeout". I am not convinced that this is an issue. But I am slightly worried about the impact of a node that has been happily alive and running suddenly being dropped from the cache and "replaced" by another node with the same address. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
