On 20/10/2016 15:01, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>     > As I said, I don't really see the issue there. According to
>     > https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.6 the
>     > negotiation (or synchronization) session has its own session-id,
>     > distinct from the one used for discovery, even if they did re-use the
>     > same TCP session. Messages for the two transactions (discovery and
>     > negotiation) could be demultiplexed using the session-id, even if they
>     > overlapped in time for some reason. The ids will never clash, because
>     > the same party initiates discovery and negotiation.
> 
> But, can't there be multiple back and forths of M_NEGOTIATE?
> As such the same session-id would be sent in an M_NEGOTIATE in both
> directions.

Exactly. Like my example that I sent. Manually prettified, it reads:

A to B: [M_REQ_NEG, 8280376, ['EX3', 1, 6, ['NZD', 156]]]
B to A: [M_NEGOTIATE, 8280376, ['EX3', 1, 6, ['NZD', 155.5]]]
A to B: [M_END, 8280376, [O_ACCEPT]]

What's the problem? 8280376 is unique in A, and {8280376, A's address}
is unique in B. They can't get confused, even if there are numerous
negotiation steps.

OK, so now I'll make one with multiple steps [pause while I run my
example generator and prettify the results]

A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]]
B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]]
A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, 294.75]]
B to A: [M_WAIT, 11146801, 20899]
B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]]
A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, 235.8]]
B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']]

I use random numbers to generate the test cases. That was a nice one, it
shows B telling A to wait and it shows a failed negotiation. But since
A and B both know who they are, the fact that the session-id is identical
isn't a problem.

   Brian

> If not, then I don't understand negotiation at all.
> 
> 
> --
> 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

Reply via email to