Subject: [Anima] Last minute glitch in draft-ietf-anima-grasp

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 May 2017 10:51:47 +1200

Hi,

This is embarrassing since the GRASP draft is already with the IESG,
but better now than later.

Bill Atwood has been testing the GRASP prototype on a larger setup
than previously, and this has just thrown up an issue in discovery
relaying. (We tried to do this test at the IETF98 hackathon, but
failed for practical reasons.)

The issue is minor in terms of words but really needs to be fixed.
Consider the following two extracts:

> 3.5.4.4.  Discovery Relaying
...
> Since the relay device is unaware of the timeout set by the original
> initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT
> milliseconds.

> 3.8.5.  Discovery Response Message
...
> It MUST contain a time-to-live (ttl) for the validity of the
> response, given as a positive integer value in milliseconds.  Zero
> is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6).

This is exactly the wrong way round. The TTL for a discovery response
needs to be *longer* than the timeout for a (relayed) discovery. If not,
the TTL will expire before the relayed discovery completes. This is
really an implementation issue but the above text almost guarantees
failure.

Proposed new text, which intentionally leaves the details for the
implementer:

> Since the relay device is unaware of the timeout set by the original
> initiator it SHOULD set a timeout significantly less than GRASP_DEF_TIMEOUT
> milliseconds.
...
> It MUST contain a time-to-live (ttl) for the validity of the
> response, given as a positive integer value in milliseconds.  Zero
> implies a value significantly greater than GRASP_DEF_TIMEOUT
> milliseconds (Section 3.6).

WG Chairs and AD: I will be on personal travel between now and the
IESG call on Thursday, so it isn't really possible to post a new
draft in time.

Regards
    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 23 May 2017 09:53:23 +0000

Hi all,

When I discuss ACP with some product people, they are always curious about why we choose RPL for routing.
I understand the benefits of RPL in ACP, it is lightweight and much more scalable in a single routing area, but most of the non-IoT network devices seem like lack the support of RPL. 

So, please pardon my iteration on this problem, can we possibly make another more traditional IGP literally legal in the ACP document? (e.g. ISIS-autoconf or OSPFv3-autoconf)
I know supporting multiple protocols would potentially cause interoperation issue. But in some closed solutions, multi-vendor interoperation is not the No.1 consideration for customers. If ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more widely adopted in non-IoT network devices.

Any comments? Or eggs :)

B.R.
Bing