Answering my own question, below, since nobody else has: On 31/05/2016 14:16, Brian E Carpenter wrote: > Hi WG, > > I expect you saw the recent messages about renumbering, and you may > have seen the big discussion in 6man about stable addresses. > > I think we are clear that address stability for the autonomic > infrastructure is very desirable, but the fact remains that in IPv6 > addresses can always change, so GRASP needs to tolerate that. > > After a little discussion on the design team list, I have two suggestions > for GRASP, and a question for the WG: > > 1) In the description of discovery, we need to say more about > the discovery cache timeout > > After a GRASP device successfully discovers a Discovery > Responder supporting a specific objective, it MUST cache this > information. This cache record MAY be used for future > negotiation or synchronization, and SHOULD be passed on when > appropriate as a Divert option to another Discovery Initiator. > The cache lifetime is an implementation choice that MAY be > modified by network Intent. > > I suggest adding something more here: > > In some environments, unexpected address renumbering might occur. > In such cases, the cache lifetime SHOULD be short compared to > the expected address lifetime and a mechanism to flush the > discovery cache SHOULD be implemented. > > 2) We should also add something to the API, to allow an ASA > to optionally flush previously discovered locators. > > Now the question. Should we add a TTL to discovery responses? > It isn't very hard to do. > > Pro: > - This would allow discovery cache timeouts to be tailored > per ASA instance instead of per network. > > Con: > - It slightly expands the Discovery Response message. > - It adds minor complexity to the discovery cache handling. > > Comments? Opinions?
I don't think that adding a timeout to the Discovery Response is useful. There is nothing "personal" to the ASA or the objective about discovery timeouts. It's simply a guess at how long a given node's address will remain valid. That is linked to unpredictable external events, not to the ASA. As a reminder, if an ASA goes away, any attempt to start a GRASP session with it before the discovery caches times out will fail anyway, so no harm will be done. ASAs already need to be robust in such cases. So I believe that a default timeout, that could in principle be modified network-wide, is just fine. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
