Re: [Anima-signaling] GRASP and renumbering: suggestions

[Brian E Carpenter <[e-mail]>]

On 27/05/2016 13:01, Jéferson Campos Nobre wrote:
> Hi Brian.
> Comments below.
> Best.
> Jéferson
> 
> Em qui, 26 de mai de 2016 às 20:46, Brian E Carpenter <
> [e-mail]> escreveu:
> 
>> Hi design team. I expect you saw the recent messages about renumbering,
>> and you may have seen the big discussion in 6man about stable addresses.
>>
>> I have two suggestions for GRASP.
>>
>> 1) In the description of discovery, we say this:
>>
>>  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.
>>
> 
> I'm not an english native speaker, but I would expect MUSTs instead of
> SHOULDs. Or maybe this is related to the "some environments" restriction...

Well, yes, it is, but also I think cache staleness is quite a subtle
issue and there might be implementation questions that we haven't thought
of, so leaving a little flexibility seems reasonable to me. An IETF 'SHOULD'
has a very precise meaning: "there may exist valid reasons in particular
circumstances to ignore a particular item, but the full implications must
be understood" [RFC2119].

>> 2) And in the API, I suggest that the 'discover' function
>> needs an optional 'flush' parameter, to specify that previously
>> discovered locators must be flushed first.
>>
>> I am reluctant to add a TTL to discovery responses. It's a complication,
>> and experience with DNS is that resolvers often ignore the TTL.
>>
> 
> I believe most discovery protocols work use TTL, thus I would favor using
> also. However, I'm not sure how this would impact the signaling protocol
> and, consequently, the current implementations.

It would just be one more field in a discovery response, so I don't think
the impact on the protocol is very big. I don't think it would be horrible
to implement - just set the expiry time in the cache after receiving a
discovery response, and flush out expired entries each time an ASA wants
that locator.

Thanks, any other opinions?

    Brian