Hi Michaeil, On 20/10/2016 04:59, Michael Richardson wrote: > > 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.
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. > > 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.) > > 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? 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. > > > 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. 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 > 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 <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
