Please excuse time-warp mail: trying to hit zero inbox... [so you'd better not reply! :-)]
I think that my point below is not contradicted by any text, I just wanted to
close the loop on this thread. At least close it in my mind.
Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>> 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?
> 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.)
I share your view: ASAs need to be the apps of autonomic networking.
Quite literally that is a good model to take, and I hope someone takes this
view. The whole android model: Java/Dalvik/ART, IDE, very low latency IPC,
and isolation between ASA by default. Router Control plane CPUs are probably
still underpowered compared to today's smartphones, but are still in the
same category.
My recent understanding is that the M_RESPONSE is just about where the ASA
is. That the thing asking would still need to initiate a TCP GRASP
connection to the ASA to do the M_SYN_NEG process. What I was thinking was
that if the M_RESPONSE was sent by the responding ASA, then it could continue
to use the TCP connection that was already up.
It isn't a TCP connection setup that I'm trying to avoid, (that's a really
minor saving) but rather it permits load balancing of the ASA function at
discovery time, rather than a TCP SYN time. And if the ASA is located in
the NOC, it permits the NOC to do outgoing TCP connections, rather than
accept incoming ones.
In my thinking, the core/kernel GRASP daemon then functions much like inetd
did in Unix systems of yore (systemd has tried to replace this).
> 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.
I clearly did not explain this well enough, because you concluded the
opposite of what I was thinking. It would be used in the opposite situation
where GRASP spawned the ASA, passed it the M_DISCOVERY message to reply to.
When I say "spawned", it could be a process, or a complete container,
maybe a full VM.
It might even have a different IP address, although at that point I consider
that really, the GRASP daemon has just relayed the M_DISCOVERY to a very
limited GRASP instance running inside the ASA. This might be the best way to
think of the architecture that I'm thinking of anyway. That's why I wrote,
above, it doesn't really affect the protocol.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
