Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 9 Aug 2005 11:55:31 -0400

No it's not. I still don't know why we kept it in the 
first place.

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On
 > Behalf Of James Kempf
 > Sent: Tuesday, August 09, 2005 11:51 AM
 > To: Subba Reddy; Junghoon Jee; 'Koshiro MITSUYA'; 'Alexandru 
 > Petrescu'
 > Cc: [email-masked]
 > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
 > Mobility Header
 > (FNA)
 > 
 > 
 > If oDAD is used, is FNA really needed?
 > 
 >             jak
 > 
 > ----- Original Message -----
 > From: "Subba Reddy" <[email-masked]>
 > To: "Junghoon Jee" <[email-masked]>; "'Koshiro MITSUYA'"
 > <[email-masked]>; "'Alexandru Petrescu'"
 > <[email-masked]>
 > Cc: <[email-masked]>
 > Sent: Tuesday, August 09, 2005 6:36 AM
 > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
 > Mobility Header (FNA)
 > 
 > 
 > > Hi Junghoon,
 > >
 > >
 > > > What about using FBU solely without FNA ?
 > >
 > > If MN has sent FBU in PAR's link, and if it has not received FBack,
 > > there can be two possibilities
 > >
 > > 1. Tunnel is not established between PCoA and NCoA, 
 > because FBU itself
 > might
 > > be lost.
 > > 2. All the message exchange happened successfully 
 > (FBU,HI,HAck), but by
 > the
 > > time PAR sends
 > > FBack MN might have moved to NAR.
 > >
 > > In the second case, if MN sends FNA, MN can receive the packets
 > immediately.
 > > Since MN don't
 > > know whether message processing is successful or not, it will send
 > FNA[FBU].
 > > So this will cover
 > > both the cases.
 > >
 > > If we send only FBU, NAR don't know, when to forward the packets.
 > >
 > > Thanks & Regards,
 > > Subba Reddy
 > >
 > > > Some implication from the FMIPv4 draft, "Adapting Mobile 
 > IPv6 Fast
 > > Handovers
 > > > for IPv4".
 > > >
 > > > Regards,
 > > > Junghoon
 > > >
 > > > > -----Original Message-----
 > > > > From: [email-masked]
 > > > > [mailto:[email-masked]] On Behalf Of Koshiro MITSUYA
 > > > > Sent: Tuesday, August 09, 2005 10:02 PM
 > > > > To: Alexandru Petrescu
 > > > > Cc: [email-masked]; Koshiro MITSUYA
 > > > > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into
 > > > > Mobility Header (FNA)
 > > > >
 > > > >
 > > > > Hello,
 > > > >
 > > > > I came up against the same situation during 
 > implementing FMIPv6.
 > > > > All current MIPv6 implementations don't accept the 
 > encapsulated FBU.
 > > > >
 > > > > Changing 3775 may work because the last header is still MH.
 > > > > And sending FBU and FNA separately works fine on my 
 > implementation.
 > > > >
 > > > > I personally prefer to send it separately, because it's more
 > > > > easy to implement, we don't need to modify 3775.
 > > > >
 > > > > regards,
 > > > > Koshiro
 > > > >
 > > > >
 > > > >
 > > > > On 2005/08/09, at 21:22, Alexandru Petrescu wrote:
 > > > >
 > > > > > Hello,
 > > > > >
 > > > > > I am not sure whether this issue has been already raised,
 > > > > sorry if so.
 > > > > >
 > > > > > Encapsulating FBU into an FNA may not be a very good idea.
 > > > > FNA is an
 > > > > > option in the Mobility Header, whose 3775-specified Payload
 > > > > Proto is
 > > > > > IPPROTO_NONE.  That means it can't encapsulate anything.
 > > > > >
 > > > > > It is true that 3775 says "Payload Proto [...] intended to
 > > > > be used by
 > > > > > a future extension" but only to further refer to a 
 > non-existent
 > > > > > Appendix B.1.
 > > > > >
 > > > > > Any thoughts?
 > > > > >
 > > > > > Alex
 > > > > >
 > > > > >
 > > > > > _______________________________________________
 > > > > > Mipshop mailing list
 > > > > > [email-masked]
 > > > > > https://www1.ietf.org/mailman/listinfo/mipshop
 > > > > >
 > > > >
 > > > >
 > > > > _______________________________________________
 > > > > Mipshop mailing list
 > > > > [email-masked]
 > > > > https://www1.ietf.org/mailman/listinfo/mipshop
 > > >
 > > >
 > > > _______________________________________________
 > > > Mipshop mailing list
 > > > [email-masked]
 > > > https://www1.ietf.org/mailman/listinfo/mipshop
 > > >
 > > >
 > >
 > >
 > > _______________________________________________
 > > Mipshop mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/mipshop
 > 
 > 
 > 
 > _______________________________________________
 > 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: "Soliman, Hesham" <[email-masked]>
Date: Tue, 9 Aug 2005 23:58:57 -0400

> So I think that the focus should probably be on valid NCEs,
 > with some mention of how to create one in a way compatible with
 > FMIPv6 (with ODAD, NA is fine), rather than on which packets
 > should be sent (and no mention of the NCE).

=> Agreed! 

Hesham

 > Greg

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 10 Aug 2005 13:47:46 -0400

Actually, I didn't say that the HI/Hack exchange is 
dependent on buffering Vs bicasting. I was saying that
there is already enough "caching" in ND implementations
to handle the buffering in the NAR, and it can be extended. 
So whether you use HI/Hack or not is almost orthogonal. 

Hesham

 > From: Subba Reddy [mailto:[email-masked]]
 > Sent: Wednesday, August 10, 2005 11:31 AM
 > To: James Kempf; Soliman, Hesham; Junghoon Jee; Koshiro MITSUYA;
 > Alexandru Petrescu
 > Cc: [email-masked]
 > Hi Jak,
 > > => I don't think so. The MN can form its CoA before it move
 > > (predictive) or after (reactive). In either case the CoA
 > > would be defended with oDAD. I don't see where the difference
 > > is.
 > >
 > > jak>> Yes, I think you are right. The PAR starts 
 > forwarding to the nCoA
 > via
 > > the NAR when it gets the FBU while the MN is on the 
 > previous router, the
 > NAR
 > > buffers until the MN arrives.
 > 
 > If NAR needs to do buffering, then HI, HAck exchange may be required.
 > As Hesham mentioned, if bicasting is used, then message 
 > exchange may not be
 > requied.
 > 
 > Thanks & Regards,
 > Subba Reddy
 > 
 >