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

Reply via email to