Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover capability extension

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 13 Nov 2002 15:26:58 +0000

Hi James:

Please see below as [HMC]:

>From: "James Kempf" <[email-masked]>
>To: "Eunsoo Shim" <[email-masked]>, "Pete McCann" <[email-masked]>,  
>  "Rajeev Koodli" <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>
>Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover 
>capability extension
>Date: Tue, 12 Nov 2002 23:24:41 -0800
>
>
> > We don't know how CARD will evolve and thus I am afraid to put 
>constraints
> > on CARD by relying on FMIP for the information distribution part.
> > I guess that is (almost?) the same reason some people do not like to 
>have
> > FMIP rely on CARD.
>
>This is precisely the reason why it is a good idea to start simple. The 
>current
>DT document is much too complicated. We don't need "preferences" and
>"requirements" being sent by the MN to the AR.

[HMC] On the contrary, I think that the current document is very clearly 
written. It also severs to bring up the issues that were "glossed over" in 
issues and requirements draft. It was OK that time, but for designing a 
protocol, we need black and white reasoning and WG consensus on them.

[HMC] For now, there are no details available about what capabilities are 
important. So if there are ten capabilities that are deemed important, I 
would rather keep "preferences". In other words, MN would be interested in 
only one of those 10, and hence has to ask specifically for it. Thus, IMO, 
it is premature to say that preferences is premature optimization.

[HMC] Also, TAR selection on current AR has never been ruled out, I mean by 
WG consensus. At least, meeting minutes from Pittsburgh do not say that, and 
I guess we did not meet in Yokohama.

We know two uses now, fast
>handover and intertechnology handover. We should define CARD so that it 
>works
>for these cases, but is extensible for later cases.

[HMC] Those are important ones, but not only ones. There is no comprehensive 
understading at this point about in what scenarios CARD will be useful. 
Hence, a good strategy would be to design a extensible protocol and IMHO 
current DT document does a good job at it. Further, there is a clear section 
on how FMIPv6 overlap would be leveraged for efficient optimization. So, I 
see CARD and FMIPv6 coexist in an efficient manner rather than confilct each 
other.

>
> > A question arising to me is whether revising FMIP would be justified 
>later
> > for distribution of more information than what FMIP needs between AR and 
>MN
> > even though the revision is not really for fast handoff. The possible 
>change
> > may be not only the content of the information from AR to MN but also 
>the
> > way MN requests information to AR.
>
>If we use FMIP, any additional capabilities can later be added as ICMP 
>options.
>This is a simple and easy way of extending the protocol without having to 
>redo
>it.
>
> > Currently what FMIP needs from the information distribution is a subset 
>of
> > what CARD is trying to cover. If we consider merging the overlapping 
>parts,
> > wouldn't it be reasonable to take a more general one? Then there would 
>be no
> > problem to support not only what FMIP needs but also whatever 
>information
> > distribution other/future work needs. Again I think SeaMoby WG should do
> > more work on CARD to find a good resolution of this overlapping.
>
>
>The DT document calls for an unspecified ICMP extension for distributing 
>the
>capabilities. Why not make that extension the same as PrxyRtAdv? Similarly, 
>why
>not make SolPrxyRtAdv the same as the extension for soliciting it? Why have 
>two
>ICMP extensions that are similar in 80% of what they do? The IETF needs to
>maintain some architectural consistency. Just because these protocols are 
>being
>done in two working groups is no reason to get into turf battles about 
>whose
>protocol depends on whose.
>
> > As a last comment, I don't know who is going to disclose their product
> > development plans on the mailing list. Since CARD work started not so 
>long
> > ago, probably we can ask whether people are interested in any feature 
>rather
> > than people have any product plan using the feature at this moment.
>
>If nobody is going to stand up and say they want to use CARD in products, 
>then
>we ought to stop the work and let people publish it as research papers. 
>IETF is
>not in the business of doing research, it does engineering of standards for
>products.
>
>             jak
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Nov 2002 12:20:26 -0800

> protocol, we need black and white reasoning and WG consensus on them.

The requirements document went through last call, and so it is presumed to have
WG consensus. These issues were not "glossed over", they were deemed by the WG
to be irrelevent to the design of the CAR protocol. Otherwise, they would be in
the requirements document.

If you think that this is not so and want to reopen the requirements discussion,
Pat and I can send email the Allison and the IESG saying that, sorry, the
requirements aren't done yet, and we can spend another year arguing about them
like with CT.

> it is premature to say that preferences is premature optimization.

Is Nokia planning on implementing this in their products?

> I guess we did not meet in Yokohama.

We had a discussion last last spring about this. If you want, we can recall the
requirements document from the IESG and reopen the discussion.

But be warned: the IESG will not be pleased about this.

> understading at this point about in what scenarios CARD will be useful.

Right, and that is exactly why the design should be conservative and simple,
only do what people want in their products now, but provide for extensibility
should some new uses arise. Otherwise, we may end up designing something that
nobody implements.

> see CARD and FMIPv6 coexist in an efficient manner rather than confilct each

I disagree. They conflict in 80% of what they do. CARD is trying to do more, but
it is more that is currently not on people's product roadmap, as far as I can
see.

            jak