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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 May 2016 11:46:01 +1200

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.

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.

Comments?

   Brian

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Fri, 27 May 2016 01:01:16 +0000

Hi Brian.
Comments below.
Best.
Jéferson

>  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...

> 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.

> Comments?
>
>    Brian
>
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 May 2016 13:29:45 +1200

> 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].

> 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