Subject: RE: [Mipshop] Re: Stateful configuration and FMIPv6

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Tue, 23 Aug 2005 15:07:35 -0500

This text looks good to me. 

Vidya

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]] 
> Sent: Tuesday, August 23, 2005 1:25 PM
> To: James Kempf
> Cc: Narayanan Vidya-CVN065; [email-masked]; 
> Soliman, Hesham; [email-masked]
> Subject: Re: [Mipshop] Re: Stateful configuration and FMIPv6
> 
> 
> 
> Text for the issue tracker :-)
> 
> Should the FMIP specification define _how_ the NAR is able to 
> provide NCoA for a MN to use? Or, merely define transport 
> messages which can carry the NCoA, but does not specify the 
> mechanism used by NAR to obtain a (duplicate-free) NCoA.
> 
> -Rajeev
> 
> ps: discussion is good, but if you would like to see 
> something revised, you have to propose the issue and your 
> suggested text, which if backed up with an implementation 
> experience will greatly expedite the resolution of the issue.
> 
> 
> James Kempf wrote:
> 
> > I think the spec must provide a credible story about how it can be 
> > done,
> > or point to another spec that provides such a credible 
> story, in order 
> > to have FMIP in shape for proposed standard. Or drop trying 
> to support 
> > stateful configuration with predictive handover. In the current 
> > situation, I can't see how stateful configuration could be 
> done with 
> > predictive handover, except by postulating a mechanism on 
> the NAR that 
> > is not defined within this spec or another.
> > 
> > It's exactly the same problem as with preauthentication for 802.11. 
> > The
> > terminal needs to set up some state on the new link before 
> it gets there.
> > 
> >            jak
> > 
> > 
> > ----- Original Message ----- From: "Narayanan Vidya-CVN065"
> > <[email-masked]>
> > To: "'James Kempf'" <[email-masked]>; 
> > <[email-masked]>
> > Cc: "Soliman, Hesham" <[email-masked]>; <[email-masked]>; 
> > "Rajeev Koodli" <[email-masked]>; 
> <[email-masked]>
> > Sent: Tuesday, August 23, 2005 9:09 AM
> > Subject: Stateful configuration and FMIPv6
> > 
> > 
> >> James, all,
> >> Sorry for branching off another thread here, but I had an 
> orthogonal
> >> comment on this specific topic and didn't want it to 
> muddle the other 
> >> discussion.
> >>
> >> Why is it necessary for the spec to describe the details on how the
> >> NAR obtains the IP address in the stateful configuration 
> case? This is 
> >> not really part of the FMIPv6 protocol in my mind. FMIPv6 
> must provide 
> >> the means of transporting an IP address from the NAR to 
> the MN (which 
> >> it already does). But, the specific mechanism by which the 
> NAR obtains 
> >> this IP address should perhaps be outside the scope of the 
> spec. If 
> >> there is a need for standardizing a mechanism for that 
> (I'm not sure 
> >> if there is), perhaps there should be a separate short 
> document that 
> >> does that (stateful IP address configuration for FMIPv6).
> >>
> >> Thoughts?
> >>
> >> Vidya
> >>
> >>>
> >>> Stateful configuration is the more complex issue, as you have 
> >>> mentioned. I can think of a bunch of ways it could be approached:
> >>>
> >>> 1) Have the NAR maintain a pool of addresses, as you 
> mention. When 
> >>> the HI comes in, it picks one out, then sends it back in the HAck.
> >>> 2) Have the NAR perform proxy DHCP on behalf of the MN when
> >>> the HI arrives, send the HAck back with the address.
> >>> 3) Have the MN tunnel DHCP requests to the new link. The MN
> >>> could do this proactively every time it discovered a new NAR,
> >>> kind of like preauthentication in 802.11r. From an
> >>> architctural standpoint, this would probably be the preferred
> >>> approach. Or the PAR and NAR could act as a DHCP relay.
> >>> 4) Run the DHCP request through a tunnel over HI/HAck.
> >>> 5)  Forget about address preconfiguration with stateful. When
> >>> the MN moves to the new link, it must perform DHCP. So, in
> >>> the stateful case, handovers become reactive.
> >>>
> >>> None of these is particularly appealing, but I don't 
> think the spec 
> >>> deals with stateful configuration very well (if at
> >>> all) currently.
> >>>
> >>
> > 
> > 
> > 
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 16:31:33 -0700

Yes, I agree. This looks like a good definition of the issue.

        jak

----- Original Message ----- 
From: "Narayanan Vidya-CVN065" <[email-masked]>
To: "'Rajeev Koodli'" <[email-masked]>; "James Kempf" 
<[email-masked]>
Cc: <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, August 23, 2005 1:07 PM
Subject: RE: [Mipshop] Re: Stateful configuration and FMIPv6