I have no objection Brian. I can understand the reason for keeping the flow label
"clean".
I was just wondering if there were any plans to use the flow label for ND traffic too, or
we should consider that there are no real flows there.
Regards,
Tassos
Brian E Carpenter wrote on 15/10/2011 02:43:
Also remember that 3697 is obsoleted by draft-ietf-6man-flow-3697bis,
which is fully approved and very close to becoming an RFC.
Regards
Brian
On 2011-10-15 12:30, Tassos Chatzithomaoglou wrote:
Hemant Singh (shemant) wrote on 15/10/2011 01:41:
Tassos,
From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr]
Sent: Friday, October 14, 2011 6:29 PM
To: Hemant Singh (shemant)
Cc: IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for
draft-hsingh-6man-enhanced-dad-01.txt
I was wondering...wouldn't the flow label be a "better" field for
storing this random number?
If i remember correctly, early drafts of RPL were using it for loop
detection (ok, in a very different way), although in the later ones a
new option was chosen.
Sure, RFC 3697 is very strict on its specification, sure SEND already
uses the Nonce option, but since we are talking about ND only
(=before any real src/dst flow) i would like to know the>rationale
behind of this decision; choosing an extra option instead of a
mandatory -useless until recently- field. Maybe then, all ND messages
could be supported (less impact on memory?).
I may have missed some talks about this in the past (or maybe i'm
talking nonsense :-[ ), so please forgive me if this is the case.
No forgiveness needed ☺. You have been a great reviewer for lot of
documents! The flow label was the first field I and another colleague
of mine at Cisco thought of. However yet another colleague of mine
shot down the use of Flow Label with the following comments in double
quotes.
“Using the flow label for this is likely to be highly controversial.
I can already hear people claiming it's not a "flow", etc.”
The flow label has another nuance. It's a 20-bit field and thus a
nonce generated with such number of bits has one in a million chance
of a duplicate. The community may prefer at least a 32-bit nonce or
higher. That is why I decided to just use the Nonce Option from SEND
in RFC 3971.
Thus can we move away from the Flow Label and use the Nonce Option
from SEND?
Thanks,
Hemant
That is ok with me. Just wanted to know the background story.;-)
btw, draft-asati-v6ops-dad-loopback seems to be dealing with the same
problem too (but from a different perspective). Section 3.2 of it is
quite similar though.
Are there any plans to merge these two docs? If not, will there be any
references of each other?
PS: previous email came from my old address, so i messed things a little
bit.
Regards,
Tassos
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
