Thanks, Diego!
I think, if SeqNum=0 has the special meaning, 6P would need to pass a received
SeqNum to a corresponding SF... But, my understandings is that, SeqNum is
maintained only by 6P and not revealed to SFs... An alternative way to tell
a power-cycle event to the peer would have been
Yacht,
Let me chime in a little bit. Responses below.
Regards,
Diego
El mié., 24 de abr. de 2019 06:24, Yasuyuki Tanaka
escribió:
> Hi Xavi,
>
> > What is the issue you see with this?
>
> At least, there is an inconsistency in RFC8480. Here is another example:
>
>
Hi Xavi,
> What is the issue you see with this?
At least, there is an inconsistency in RFC8480. Here is another example:
https://tools.ietf.org/html/rfc8480#section-3.2.2
rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a given
rfc8480> transaction MUST share the same
Hi Yatch,
thanks for your response. see inline my comments.
Missatge de Yasuyuki Tanaka del dia dt., 23
d’abr. 2019 a les 10:49:
> Hi Xavi,
>
> Thank you for your reply.
>
> On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:
> > When node B power cycles loses the last seen seqNum. Its stored
Hi Xavi,
Thank you for your reply.
On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:
When node B power cycles loses the last seen seqNum. Its stored value is then 0
and hence when it receives the request responds with the error and with the
stored last seen seqnum (0).
does it make
Hi Yatch,
thanks for your observation. I think that the behaviour is correct as
described in the text. When node B power cycles loses the last seen seqNum.
Its stored value is then 0 and hence when it receives the request responds
with the error and with the stored last seen seqnum (0).
does it
Hi,
I came across a question in RFC8480 (6P), which looks like an error to
me... Can anybody help? This is about the SeqNum field of the 6P header.
Section 3.2.2 defines SeqNum like this:
[https://tools.ietf.org/html/rfc8480#section-3.2.2]
> SeqNum: The sequence number associated with the 6P
