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 protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
