On 21/10/2016 01:56, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> wrote:
> >> What I was saying was, *IF* I know how to find a machine with an open
> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that
> >> I should receive my answer on that connection.
>
> > A says discover("B") to C, but C doesn't know where B is. So there will
> > be no answer, unless C does extra stuff.
>
> So, C would forward the discover("B"), and then when it gets to B,
> it would connect directly to A, and introduce itself? This is obvious now
> that you give this example, but not from the document. I might also think
> that B would connect to C, and then C would tell A.
But it couldn't do that unless it had already discovered C previously, in which
case it could simply reply to A with its cached locator for C.
>
> This clearly fails if A has a LL address only.
Yes, but that's why we have discovery relaying.
>
> >> In the 6tisch case doing multicast is either expensive or unsupported.
> >> On the other hand, we can quite easily declare that the 6LBR /
> >> DODAG-root (the router at the top of the tree) will have
> >> GRASP_LISTEN_PORT open.
>
> > Yes, you have topology knowledge in that case.
>
> Do you agree that a discovery("C") sent to C over TCP should be answered
> over that TCP connection?
Oh yes, and that is what should happen under the covers in any case, if
discovery
is running over the ACP.
However, I'm not convinced that we should document this (unicast discovery).
At least not yet.
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima