Subject: RE: [Mipshop] FNA in the current spec

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 22 Aug 2005 22:18:33 -0400

> So if we agree that these (HI/HAck) are nice to have then 
 > why not using 
 > them for possible duplicate detection too. 

=> The problem is (I think) that people think it's an either
or situation. However, HI/Hack are not there to replace
DAD. The text in 4068 that talks about how the NAR can verify
the NCoA is very vague. How does the NAR do that? 

If we take a step back and understand that 99.999999% of the time
there is no collision, we would all see how silly it is to design
another mechanism (HI/HACK) to handle this. 

Anyway, I personally won't use them and as long as the spec
does not mandate their use I'm fine. I prefer to remove
them altogether though. If for nothing else, we'll avoid confusing
implementers. 

Hesham

   Making that the only and 
 > mandatory way of DADding however would add lots of complexity, to AR 
 > implementations since (if it is to be reliable)  they'd have 
 > to keep a 
 > pool of used addresses that would need to be authentic at 
 > all times, and 
 > one could see many issues here: nodes that left without ARs 
 > knowledge, 
 > and wanting to come back. Nodes that do have a duplicate 
 > address but the 
 > NAR is for some reason (no fmip (or other ext) support or 
 > being inactive 
 > for a long time) unaware of them.
 > 
 > Mandating oDAD on the other hand would add complexity for MN impls.
 > 
 > Isn't there any third option?
 > 
 > Emil
 > 
 > James Kempf wrote:
 > > I think the issue is whether or not the transport is 
 > required (i.e. MUST) 
 > > signal duplicates or not. I think it would simplify the 
 > protocol if the spec 
 > > were to take a position on this one way or the other:
 > > 
 > > - No duplicate signaling, HI/HAck not needed, reduces 
 > message complexity but 
 > > node MUST do DAD (even oDAD) on new link possibly delaying 
 > packets, small 
 > > but nonzero probability of address clash if the node sends 
 > unsolicted NA on 
 > > the new link w.o. completing oDAD,
 > > 
 > > - Duplicate signaling, HI/HAck needed, more message 
 > complexity, lessens 
 > > probability of address clash, unsolicted NA needed only to 
 > start packet 
 > > flow, no DAD needed on new link.
 > > 
 > > Either way, I think predictive information is needed to 
 > make it work. If 
 > > there's no predictive information, then DNA RS/RA is the 
 > most efficient.
 > > 
 > > I don't think there is really an issue about whether a 
 > link layer supports 
 > > something or not, I think this is just an IP level issue 
 > about what 
 > > modifications FMIP requires in the AR.
 > > 
 > >             jak
 > > 
 > > ----- Original Message ----- 
 > > From: "Rajeev Koodli" <[email-masked]>
 > > To: "James Kempf" <[email-masked]>
 > > Cc: <[email-masked]>; "Soliman, Hesham" 
 > > <[email-masked]>; <[email-masked]>
 > > Sent: Monday, August 22, 2005 3:50 PM
 > > Subject: Re: [Mipshop] FNA in the current spec
 > > 
 > > 
 > > 
 > >>The approach has been not to specify a particular duplicate
 > >>handling mechanism, but to allow hooks. For instance, there
 > >>was a proposal to keep a pool of duplicate-free addresses (aDAD
 > >>I think) at an AR. The protocol itself does not bind to any
 > >>one mechanism, but allows transport to signal duplicates or
 > >>no-duplicates.
 > >>
 > >>-Rajeev
 > >>
 > >>
 > >>James Kempf wrote:
 > >>
 > >>
 > >>>>In the mean time any propositions as to how _exactly_ 
 > this is to be done 
 > >>>>would be most welcome since we haven't really considered 
 > how to reliably 
 > >>>>do that.
 > >>>>
 > >>>
 > >>>The spec has a paragraph on it. I quoted it in another email.
 > >>>
 > >>>           jak
 > >>>
 > >>
 > >>
 > > 
 > > 
 > > 
 > > _______________________________________________
 > > Mipshop mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/mipshop
 > > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 09:06:46 -0700

Hesham,

> them altogether though. If for nothing else, we'll avoid confusing

I agree that the current spec is ambiguous. I think this needs to be cleaned 
up.

While I do agree that the probability of duplicates is very low, there are 
two issues:

1) It's not zero.
2) As a practical matter, I think the IESG will insist that FMIP have a 
clean story with regard to duplicates, no matter how unlikely, before they 
approve it for proposed standard.

I'd certainly like to get the protocol simplified as much as possible, so, 
from that standpoint, I'd like to get rid of HI/HAck and FNA. But only if we 
can figure out some nicer way to deal with the problems they were designed 
to address.

        jak