Subject: [Anima] GRASP open issues confirmation

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 23 Nov 2015 08:59:34 +0000

Hi Dear all,

In Yokohama, we had very constructive discussion of the GRASP open issues. Thanks for all your valuable comments.

As I perceived, there were some issues that seemed consensus during the discussion, let me list them as below. If you have any different opinions, please feel free to comment.
(We also had some issued not reached consensus or clear solution yet, let me discuss them separately by different threads later.)

- Discovery issues:
d1) Handling of multiple valid discovery responses
Consensus: multiple responses should be valid use case. However, how to chose the most proper response, should NOT within GRASP scope.
d2) Do we need "fast withdrawal" of discovery responses?
Consensus: GRASP doesn't decide withdrawal of the discovery results; but it should be able to do the withdrawal indicated by ASAs.
d3) Clarify if/when discovery needs to be repeated
Consensus: GRASP should NOT decide the repeat time period. It is a use case specific, should be decided by the ASA.
d4) Do we need random delay in discovery response?
Consensus: No. But we might need to limit the response rate from the same responder, to prevent DOS attack.

- Security issues:
s1) Mandatory/Optional to run GRASP in ACP?
Consensus: GRASP runs in ACP by default. Data-plane GRASP is allowed as a separate instance. TLS/DTLS needs to be used to protect the data-plane GRASP.
s2) State that role-based authorization of ASAs is out of scope for GRASP
Consensus: Agreed.

- Other issues:
o1) We have specified repeats for failed discovery etc. Is that sufficient to deal with sleeping nodes?
Consensus: It should NOT be GRASP's job to deal with sleeping nodes. (ASA's job)
o2) Private Enterprise Number(PEN) is used to distinguish vendor options. Would a domain name be better?
Consensus: PEN might not make sense for autonomic nodes; domain name might be better.
o3) Is Session ID sufficient to identify relayed responses?
Consensus: Not sufficient, originator's address should be needed.
o4) Clarify that a node will contain one GRASP instance supporting multiple ASAs
Consensus: Agreed.

Best regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Nov 2015 08:13:54 +1300

Hi,

> Consensus: multiple responses should be valid use case. However, how to chose the most proper response, should NOT within GRASP scope.

Agreed. It should be left to the ASA. However, I would expect the GRASP engine
to have a default choice in case the ASA doesn't care. For the moment I think
that can be left as an implementation choice.

> Consensus: GRASP doesn't decide withdrawal of the discovery results; but it should be able to do the withdrawal indicated by ASAs.

In practice I think an explicit withdrawal isn't needed: what is needed is that
an ASA can deregister an objective, so that future requests for that objective
will fail. The same thing should happen automatically when an ASA exits.

A related issue is whether discovery reponses need an individual TTL
(like DNS). At the moment we specify indefinite caching. This also
affects the next issue...

> Consensus: GRASP should NOT decide the repeat time period. It is a use case specific, should be decided by the ASA.

...which suggests that we do need a TTL.

> Consensus: No. But we might need to limit the response rate from the same responder, to prevent DOS attack.

I think the draft already suggests this when relaying responses.

> Consensus: GRASP runs in ACP by default. Data-plane GRASP is allowed as a separate instance. TLS/DTLS needs to be used to protect the data-plane GRASP.

That is more or less what the draft says now. The IESG has just had an interesting
discussion of a similar point for HNCP. We need to be clear about the difference
between "mandatory to implement" and "mandatory to use".

> Consensus: It should NOT be GRASP's job to deal with sleeping nodes. (ASA's job)

Generally agreed, but we surely need to think about what happens if the GRASP engine
itself sleeps.

> Consensus: PEN might not make sense for autonomic nodes; domain name might be better.

I will send a separate message about this.

> Consensus: Not sufficient, originator's address should be needed.

Probably correct, although the collision probability is extremely
low.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Nov 2015 08:34:48 +1300

>> Consensus: PEN might not make sense for autonomic nodes; domain name might be better.

The point here is that some GRASP objectives will be standardised and their
names will be in an IANA registry; they don't need either a PEN or a domain name.

Other objectives will be non-standardised; we call them "vendor" options but of
course they could be private in any way, open-source, or whatever. However, to
make them unique, they need some tag that is guaranteed to be unique, which means
we need to pick something that is registered somewhere. The two obvious choices
are PEN numbers or domain names.

PEN numbers (draft-liang-iana-pen) are fixed length (32 bit) integers introduced
for SNMP (but with no dependency on SNMP), allocated FCFS at no cost. This morning,
there are 46768 of them allocated.

Domain names are variable length strings. They cost money to obtain and maintain.
They can vanish or be re-assigned.

>From a GRASP efficiency point of view, I think that 32 bit integers are marginally
better.

Regards
   Brian