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

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 23 Aug 2005 13:20:46 -0400

> > 2) Remove the ambiguity surrounding HI/HAck, and either 
 > clearly define 
 > > why, when and how it is used, or drop it.
 > 
 > Can we rephrase this "clarify the role of HI/HAck in address 
 > duplication
 > handling"?

=> I don't want to limit the scope of the work before we start.
So I prefer James' statement because it allows for a wide range of
actions, whereas your statement limits it to clarification. This assumes
that we agree they're useful.

 > 
 > As an implementor pointed out, at least some folks may want to have 
 > them. And, they are not required to be used even in the current spec.

=> Yes but "Must support" is still too strong. MUSTs are reserved
for functions that break the protocol if not supported. 

Hesham

 > 
 > Thanks,
 > 
 > -Rajeev
 > 
 > 
 > > 
 > > I think it will require some discussion and maybe some 
 > implementation 
 > > experiments before we can come to a conclusion about how 
 > to resolve 
 > > these issues.
 > > 
 > >            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 4:27 PM
 > > Subject: Re: [Mipshop] FNA in the current spec
 > > 
 > > 
 > >>
 > >> So, the position taken in RFC 4068 is MUST be supported and
 > >> SHOULD be used. Any reason to change that? Provide your
 > >> reasoning.
 > >>
 > >> Also, I might turn this into text for the issue tracker,
 > >> unless you provide some explicit text.
 > >>
 > >> -Rajeev
 > >>
 > >>
 > >> 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: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Aug 2005 10:26:13 -0700

> that we agree they're useful.

Sorry, but I don't understand what "Remove the ambuguity ..." means.

> for functions that break the protocol if not supported. 

Okay. Another issue: What normative clause to use regarding the usage
of HI/HAck.

-Rajeev