Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Tue, 5 Nov 2002 21:30:18 +0100

Hi Pete

 > My personal recommendation is that we split the FMIP work into two
 > pieces: (1) The specification of F-BU, F-BACK, and related security
 > considerations, and (2) the specification of mechanisms like
 > PrRtAdv/Sol, which seem less useful in the short term and which might
 > anyway be integrated with CAR or link layer signaling eventually.

The FMIPv6 spec without PrRtSol/Adv would be incomplete. It is similar to
saying that we take RAs out of the base MIPv6 spec. Anyone reading it
would have to ask what IP message makes the MN decide to send the F-BU.
I think the FMIPv6 spec should give the complete mechanism including
changes to movement detection (PrRtAdv/Sol) and security.

Rgds
/Karim

---

From: Pete McCann <[email-masked]>
Date: Tue, 5 Nov 2002 16:54:18 -0600

Hi, Karim,

 > changes to movement detection (PrRtAdv/Sol) and security.

I could also ask how the old AR gets the mapping table information.
Without a standardized mechanism, we won't have interoperability.
That coupled with the fact that anticipated handover seems impossible
without a fairly exotic device driver implementation leads me to
believe that we should defer this sort of signaling until we
understand the issues better, and have talked things through with
people who participate in the IEEE.

On the other hand, the F-BU is just previous FA notification which has
been around for a long time.  I expect there will be a lot of
discussion about how to develop a security association with an access
router, similar to the discussion that gave rise to return routability
in MIPv6, and we should probably have a (small) set of preferred
techniques for doing that.  I think the F-BU/BACK messages and the
related security considerations are more than enough to occupy the WG
(and to fill out a good sized internet draft) at this point in time.

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Tue, 5 Nov 2002 15:33:46 -0800

> changes to movement detection (PrRtAdv/Sol) and security.

As a practical matter, current firmware prevents using anticipated handover on
802.11. The IEEE may choose to change this,, but I doubt current card
manufacturers will want to change and so they are likely to fight it. So if we
are concerned about standardizing something that will work with exisiting link
layers, then separating the two makes a certain amount of sense. It will give
people something that they can implement.

On the other hand, the anticpated handover may be useful for future link
designs. Perhaps it could be made experimental, as was done with the FMIPv4
work.

            jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 07 Nov 2002 09:52:27 +1100

Hi Pete,

[ a whole lot of email snipped]
 >
 > Yes, and there could be many mechanisms to accomplish the mapping -
 > you might not even need a mapping server in oAR, perhaps you could
 > embed the info in system overhead, or quickly switch over to the new
 > link and do a solicitation, then switch back.
 >

It seems people are asking similar questions in
seamoby (regarding CARD) about how to get the L3
information.

There does seem to be some mechanisms which
get around the mapping scenario entirely on 802.11.
Fikouras et al's embedding of router address in
SSID is a possible way forward which doesn't even need
explicit L3 message exchange.

[greg's original message snipped]
 >
 > It seems strange that we would invent a short-term solution for a
 > problem that doesn't seem well motivated, and for which a long-term
 > solution is in the works.  This is just begging for problems down the
 > road.
 >

With regard to fast handovers, there's not really a
significant problem for AR's to also provide support
for PrRtrSol and PrRtrAdv, even if CARD becomes the
main state transfer mechanism.  It's just important
that the MN knows that the network supports CARD (maybe
through router advertisement options?), if the MN
supports it, and wants to use it instead of PrRtrSol/Adv.

[greg's email snipped]
 > I'm also unclear about what is the right relationship
 > between CARD and PrRtSol/Adv.
 >
 > -Pete
 >

Unless the seamoby team says:
'We love your (mobile-ip's) PrRtrSol/Adv messages,
can we use them for CARD?'

I don't see why anticipated handovers can't use these
messages to provide a basis for getting the protocol
out there as a proposed standard.

If seamoby is faster to get to standardization, and
gives all that FMIPv6 requires, I'll be the first to
put my hand up to get rid of PrRtrSol/Adv.

Greg

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 27 Nov 2002 11:36:22 -0800

Hello Pete,

Hello Pete,

While on another chase through old e-mail, I found this.
I hope it's not too late to respond.

>> The FMIPv6 spec without PrRtSol/Adv would be incomplete.

I agree with Karim.

> I could also ask how the old AR gets the mapping table information.

It could use many ways.  For many installations, even static
configuration could be useful.

> Without a standardized mechanism, we won't have interoperability.

This is not true, from the standpoint of the mobile node.
All the mobile node needs to do is to get the PrRtSol with
the information it needs.

> people who participate in the IEEE.

I agree that a sophisticated design may be needed, but I don't
agree that it needs to depend on something done within the IEEE.
Was your comment specifically about language in the 80211fh draft?

Regards,
Charlie P.