Subject: Adrian Farrel's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS and COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Oct 2012 09:29:36 -0700

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.