Subject: [mobile-ip] Re: [mipcharter] Proposed Charter for IPv6 Mobility

From: Rajeev Koodli <[email-masked]>
Date: Tue, 04 Mar 2003 17:10:41 -0800

> > d) L2 event notification: I am not sure what you mean
>
> Basically, which message sequences are optional depending on L2 support. There
> is no need for some of the messages (like FBU) if L2 support is available to
> make them unnecessary.
>

We went through a set of issues prior to Yokohama IETF I believe. The result of
that is that folks want packet forwarding on the tunnel only after FBU is processed

even if the tunnel was set up by other means. Please have a look at that
discussion.
We seem to be repeating many things.. Anyway, if there is no authorization from
the MN, I don't see why this is relevant for Mobile IP.

> > For what it is worth, an appendix is a good place for such an exercise.
> > Folks should have multiple choices in "combining" different protocols.
> > I don't think we ought to show how different protocols _need_ to be
> > combined in _a_ particular way. We should leave that choice to developers,
> market.
> >
>
> Disagree. It should be in a separate draft. If I have to take this thing to the
> Japanese regulatory authorities, I don't what to explain why text involving
> handover is in a draft that I'm claiming is useful for location privacy.
>

Ok. We may be slightly out of sync here. I agree with you that the two
should be separate IDs. I meant if one wanted to see a broader picture,
an appendix could help (with no normative depenedency). I am all for
allowing parties to use the hooks (protocols) their own way for serving
their purposes.

>
> > I actually recall it slightly differently. The messages in question here have
> > been part of FMIPv6 since late 2000/early 2001. Folks more thorough with
> > the history can correct me, but I think there was no CARD then. Even when
> > the above discussion took place, I don't believe it was ever in the context of
> > FMIPv6.
> >
>
> I was in the room when this was discussed and I remember it quite well, I don't
> believe you were there. This was at the IETF immediately prior to the CRAPS BOF,
>

You mean OBAST BOF. That was at San Diego.

> I think that was Pittsburgh in 2000. There was explicit discussion about access
> router reachability using handover and how to get that information to the
> mobile. FMIPv6 wasn't even discussed then, the work had just started, and CARD
> wasn't identified as such. There were others also there I can remember, but I
> will refrain from any further comment on who.
>

Ok. I guess we have differenr reference points here..

>
> >
> > >
> > > The technical issue isn't whether FMIP can handle it, it is whether the
> > > resulting combination of protocols is properly designed to avoid duplication
> and
> > > gaps. The information being propagated by FMIP is exactly the same as the
> base
> > > information propagated by CARD. The basic design issue is propagating
> wireless
> > >
> >
> > So, CARD should have taken that account given that FMIPv6 had it in the
> > first place, right ?
> >
>
> Um, no. We are not keeping score on who has occupied this particular bit of turf
> first. :-) The intent it to get a well designed set of protocols with orthogonal
> functionality, at least, that is my intent.
>

I am not trying to keep one either :-) Sigh..

>
> The current CARD design requires two cases: one where FMIP is supported and one
> not. There should be just one case: a protocol to get information about an AR to
> the MN. There is no reason why their needs to be duplicate sets of functionality
> here.
>

I thought the messages were defined as options. If CARD is useful without
FMIP, folks will implement it without FMIP. If folks feel they are better used
together, the options would be part of the FMIP messages. Since FMIP can work
without needing CARD, I don't see the reason to require FMIP to use CARD.

>
> >
> > Combining protocols without proper justification is also questionable.
> > In fact, I see there is gretaer likelihood of delay and lost productivity in
> trying
> > to
> > impose a particular way of combining protocols
> >
>
> The "proper justification" is that they have overlapping functionality. Please
> read RFC 1958, Architectural Principle 3.2:
>
>    3.2 If there are several ways of doing the same thing, choose one.
>    If a previous design, in the Internet context or elsewhere, has
>    successfully solved the same problem, choose the same solution unless
>    there is a good technical reason not to.  Duplication of the same
>    protocol functionality should be avoided as far as possible, without
>    of course using this argument to reject improvements.
>

This sounds like a suggestion for CARD to re-use FMIP :-), which BTW
they are doing. So, what is the issue ?

>             jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 04 Mar 2003 17:31:37 -0800

James Kempf wrote:

> > b) no resource management concern since messages in a) are stateless
>
> So has preconfiguration been completely removed from the draft (sorry, I have
> not had time to read)?
>

Ah, it depends on what you exactly mean by pre-configuration.
Anyway, PrRtSol/PrRtAdv messages do not invoke HI/HAck
sequence, which takes place upon processing FBU. Until FBAck
is received, the new CoA is not confirmed. So, sending FNA
upon connecting to new link is used both for this purpose and
for announcing the MN's presence on the new link.
That's FMIPv6 in a nut shell. Let's find a way to secure FBU
and we are done! :-) Really.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 11:17:31 -0800

Rajeev,

I believe there was some comment on the mailing last week requesting that
secured L2 support be utilizable without any L3 signaling, perhaps in an
appendix.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, March 04, 2003 5:10 PM
Subject: Re: [mipcharter] Proposed Charter for IPv6 Mobility