Subject: [Anima] concerns about selection of session-id in GRASP messages

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Oct 2016 11:59:19 -0400

As I understand it, once an ASA has discovered a counterpart ASA in another
node, they will open a TCP connection.  Some questions occured to me this
morning while cycling home from a working breakfast. Some clarification
questions are in order first, as it may be that my concern is moot.

while "3.3.6.1.  Flooding" talks about preventing loops by caching
session-id+originator, I think that the problem extends to all parts of
GRASP.

1) do DISCOVERY messages have to be multicast?  My understanding is that they
   do not have to be.  I think that they could be sent over TCP on links
   where multicast means nothing (PPP, GRE), or where multicast is not known
   to be available (MESH networks).

   Given an ACP made up of a bunch of point to point GRE tunnels, is there
   any reason there is no discovery really to do, is there any reason why the
   two GRASP daemons don't just establish a TCP connection between them, and
   leave it up?  They could use this connection for flooding messages and the
   like.

   The responding GRASP daemon could realize that the link can be used in
   both directions if the originating port is also the GRASP_LISTEN_PORT.

2) the response from a multicast DISCOVERY is a unicast TCP connection.
   (We've discussed this before, and I'm okay with it, but I still wonder if
   it will be well received.)

   Is there any reason why the TCP connection for the reply has to be from
   the GRASP "kernel"/"core" daemon?  Could the GRASP daemon pass the enquiry
   to the ASA itself, and the ASA could connect to the thing that is asking,
   and reply with the M_RESPONSE itself?

3) part two of above, if the M_RESPONSE indicates a locator (address and port)
   which is identical to that connection on which the M_RESPONSE is.  Or
   maybe we need a locator which just says, "HERE".
   Is this acceptable?

If the answer to (1) and (3) is yes, and the TCP connection can support
bi-directional flows of GRASP messages, then I think that we have a problem
if the session-id happens to be poorly chosen, and both sides initiate a
query that involved multiple M_NEGOTIATE cycles.  The two ends may get
confused.

(Again, I haven't caught up with the emails about -08 yet)

If we are expanding the session-id from 24 to 32-bits, then may I suggest
simply that we actually stop at 31 bits, and make the top bit to essentially
follow the ACK bit on the TCP. I.e. the side that responded to the TCP
connection always sets bit-31 on it's session-id.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Oct 2016 11:06:11 +1300

Hi Michaeil,
>    both directions if the originating port is also the GRASP_LISTEN_PORT.

In a context where there is an ACP, yes, but where there is no ACP, it
has to be LL multicast. Logically, it's always multicast. What I want is for
the ACP to do that for me. So either the ACP actually emulates a multicast
socket or it gives me a specific API that does the same thing as multicast
sendto() and recvfrom(). I don't think it's GRASP's job to do this.

>    and reply with the M_RESPONSE itself?

In my opinion, no. ASAs are the apps of an autonomic network and won't be written
by protocol geeks. The actual ASA should simply register itself with GRASP and indicate
that it's available for discovery; it will be some daemon inside GRASP that handles
discovery. I think any other implementation model is unreasonable: we're hoping there
will be 100s or 1000s of ASAs. (However, some of GRASP will be a user space
library, as Toerless pointed out ages ago and as the API draft indicates.)

>    maybe we need a locator which just says, "HERE".

It would be a protocol change, since there's no way to signal that at the
moment. Is it really useful? (It would probably be a new locator option,
like locator-option /= [O_SAME_LOCATOR]). But it would only work in compressed
implementation where the ASA and GRASP are tightly integrated.

> query that involved multiple M_NEGOTIATE cycles.  The two ends may get

Why? The M_REQ_NEG would use a new session_id. And session_ids are uniquised
by also matching the source address when relevant. I don't understand
the problem.

> (Again, I haven't caught up with the emails about -08 yet)

And neither has the WG since it's only a candidate draft so far...
(No secrets of course, it's at https://github.com/becarpenter/animaproto)

   Brian

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