Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 12 Jul 2002 14:26:39 -0500

Hello Vijay,
Thanks for your email. BTW, can you please 
explain how can we implement fast handoff without
any link layer support? I also do not understand
why standardization of FMIPv6 will get delayed
because of L2 triggers. Is it not enough to 
document various L2 triggers and the actions to be taken 
based upon the L2 triggers? Do we need anything more than this?  
regards,
ajoy

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:08 PM
To: Singh Ajoy-ASINGH1
Cc: 'James Kempf'; Rajeev Koodli; [email-masked]
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions

Ajoy,

you got me wrong. I am not against using L2 triggers. I know you
need them to get the most optimized handovers. but we also need
a generic FMIPv6 solution (I dont know how manys times I have
said this now) that does not depend on L2 triggers. we need an
RFC soon (dont you?).

Vijay

Singh Ajoy-ASINGH1 wrote:
> 
> Hello Vijay,
> We have implemented FMIPv4 in our prototype 3G Cellular testbed.
> We have implemented both source as well as target triggers required
> to support Post-Reg (FMIPv4 version of BETH). So, I do not understand
> why are you complaining about L2 triggers? BTW, can you explain how
> can you implement FMIPv6 without using Link layer triggers?
> regards,
> ajoy
> 
> 
> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, July 12, 2002 12:26 PM
> To: Vijay Devarapalli
> Cc: Rajeev Koodli; [email-masked]
> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions
> 
> > > In particular, Section 3.3 and 3.4 were dropped from the draft. These
> are critical
> > > for describing how Postregv6 (aka BETH)
> > > can be implemented. If there is some problem with too much reference
to
> L2
> >
> > Section 3.3 and 3.4 also critically depend on L2 triggers to work.
> > BTW, I still havent figured out how to implement L2 triggers on our
> > testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers
> > draft becomes a standard. right?? and the L2 triggers document does
> > not even have a permanent home (WG).
> >
> 
> If you want to know how to implement L2 triggers, either I or Jon Wood can
> help you. I implemented them on the Solaris
> emulator and Jon on our Linux/BSD emulator. Jon is also in the process of
> implementing L2 triggered 802.11 handover, in a
> manner that is consistent with the 802.11 spec and doesn't depend on
> proprietary extensions.
> 
>         jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 12 Jul 2002 14:04:33 -0700

hi Ajoy ,

I think Raj's email answers your question.

I am afraid Section 3.2.1 of draft 4 will hold back the draft
from advancing unless there is a standard way of doing L2-ST,
L2-TT, L2-LD, L2-LU. even if there is a standard way of doing
the triggers, there has to be some kind of reference that FMIPv6
can quote. I am afraid that is not there (or wont there when
we need to advance FMIPv6)

take a look at the following mail from Jack McCann, I just saw
in the IPv6 WG. I hope I am not doing anything wrong by cutting 
and pasting this mail

> The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt)
> contains normative references to the Scoped Addressing Architecture
> (draft-ietf-ipngwg-scoping-arch-04.txt).  In particular, it relies 
> on the definition of zone indices, and on the scoped address text 
> format defined in that document.  This was flagged as an issue 
> during IESG review.  
> 
> To allow 2553bis to move forward and be published as an RFC without
> having to wait on the scoping-arch document, we've proposed to move 
> those portions of the Basic API that rely on scoping-arch into a 
> separate document that can advance alongside the scoping-arch document.
> 
> There are 4 items that will move from 2553bis to the new "scoping api"
> document:
> 
> 1. References to the terms "link index" and "site index" in
>    the definition of the sin6_scope_id field.  Note that the
>    sin6_scope_id field will remain in 2553bis.
> 
> 2. Use of the scoped address text format with getaddrinfo().
> 
> 3. Use of the scoped address text format with getnameinfo().
> 
> 4. The NI_NUMERICSCOPE flag.
> 

draft-ietf-ipngwg-scoping-arch-04.txt is infact a WG document in the
IPv6 WG, but not an RFC yet. because of this, it cannot be referenced 
in the API draft. 

L2 triggers draft has not been adopted by any WG.

do you see the danger?? please dont conclude I am spreading FUD. this
is a real concern.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Sat, 13 Jul 2002 05:37:40 -0700

Vijay,

> we need to advance FMIPv6)

Would your opinion change if these triggers were described in the abstract within the document? Similar to what Charlie and I
discussed the other day? Thus, there would be no normative references outside the document.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jul 2002 10:24:03 -0700

> discussed the other day? Thus, there would be no normative references outside the document.

yes, ofcourse! in any way that doesnt tie FMIPv6 draft to L2 triggers
draft.

Vijay