Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments

From: George Tsirtsis <[email-masked]>
Date: Tue, 3 Jul 2001 13:51:45 -0400

James,

You may be doing this already but anyway...

In the draft about L2 triggers and in addition to the triggers of the FMIP
docs could you please add the very obvious and very useful messages for the
MN's API:
- Link Down (L2 ID of link)
- Link UP (L2 ID of link)
The first is obvious and actually not that useful but the second is also
obvious but very important....and with the L2ID, indicates the much
neglected (in RFC2002bis and the like) movement detection...I bet this is
going to be the most useful of all :-)

I will say more when you get the draft done...but do let me know if you want
input earlier...

Regards
George
-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 5:35 AM
To: [email-masked]; [email-masked]'
Subject: Re: [mobile-ip] Ext. for FMIPv6 - comments

Hi George,

At 07:25 AM 7/3/01 -0400, George Tsirtsis wrote:
>Hi Kempf et. al.
>
>First of all I want to say that this is good work and introduces a mode of
>operation (using oCOA at nAR + no L3 messages over the air) that in the
>FMIPv6 draft is only covered partially as an error case...I guess Gopal
>might have already told you that we discussed this before and we did want
to
>support it in FMIPv6 but run out of time and... steam :(...so your
extension
>draft is very welcome indeed!
>
>I do have some disagreements/comments regarding the comparison section 2
but
>I am not going to get into nit picking mode..there isn't much point ;-)
>since I agree with the essence of the proposal.

OK. Ultimately, I think it would be beneficial to have both drafts merged
into
a single fast handoff protocol. Actually, I even think it would be
worthwhile
to have the IPv6 fast handoff work merged into the MIPv6 draft itself, but
that is probably impractical at the moment because the base MIPv6 draft
is much further along. Perhaps an item for moving to Draft Standard. At
that point, the comparison material can be dropped. It is only there as
motivation for why we feel the alternative is necessary.

>Instead I have one observation to make and more may follow after further
>digestion of the new draft...
>
>I think the time has come to create a mobility aware "L2 API" for IP...and
>yes, I know the IETF does not usually do APIs but I know enough people in
>this and other WGs that KNOW this is needed and are willing to make it
>happen. I actually wonder if there is anything done in this direction
>already and I am not aware of it...I do not have much time to follow IETF
>gossip these days due to an increasingly demanding day job...
>
>I think the draft already describes a number of triggers but we should work
>on their meaning so they are abstract enough to be applicable in different
>technologies and maybe add more as needed (hopefully not too many)...BTW, I
>am not suggesting you should do anything different in this draft...just
that
>we discuss this issue independently of this draft as well.

In fact, I am preparing just such a draft as we speak. The intent is to take
the material from the BETH draft and from the FMIPv4 draft and perhaps
add something on the link with Seamoby context transfer.

                 jak

---

From: James Kempf <[email-masked]>
Date: Tue, 03 Jul 2001 22:59:07 -0700

OK, I will add those.

                 jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 08 Jul 2001 17:59:51 -0400

Hello George,
  Here is an excerpt from
draft-manyfolks-ipv6-cellular-host-00.txt:
Within the current 3GPP architecture, a cellular host will always
   keep the connection to the same GGSN (default router) for a context.
   Movement between default routers is not permitted. The only scenario
   where a MN would change default routers is in the case of a handover
   between two different access technologies. In this case the MN will
   be simultaneously connected to both routers which would eliminate
   the need for anticipation through the current router. Hence the Fast
   Handoffs draft will not be required within the current 3GPP
   architecture.

What do you think?

--
Behcet