Brian E Carpenter <[email protected]> wrote:
    > 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.

Still, I'm more confused now.

When A has a LL only, we would have to have, not only discovery relaying, but
also response forwarding.   So does B reply to C (to be relayed to A), or is
it a fail as B tries to connect to A's LL address, and does not connect?


    >> >> 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.

When?  I feel that this is important behaviour that needs to be defined for
the GRASP core system.


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



Attachment: signature.asc
Description: PGP signature

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

Reply via email to