Re: WG Review: Mobility for IPv6 (mip6)

[Vijay Devarapalli <vijayd@iprg.nokia.com>]

hi Thomas,

Thomas Narten wrote:

> > > 2) Features such as renumbering of the home link, home agent discovery,
> > >      Route Optimization, which are currently a part of the base
> > >      specification can be specified more explicitly as separate
> > >      specifications. This will also enable modularizing the Mobile
> > >      IPv6 specification further into the minimal subset and add-on
> > >      features. Some of these specifications will be identified as
> > >      base mechanisims of Mobile IPv6.
>
>
> > I dont see how the above paragraph has anything to do with the
> > primary goal of the WG.
>
>
> I (and others) will argue that one of the reasons it took so long to
> get the current spec finished is that it got too large, and that it
> had too many unrelated things crammed in it.  

the main reason was that Mobile IP WG was asked to solve a very hard
problem of trying to establish a trust between two nodes in the
internet, without using an infrastructure like PKI or AAA. the WG first
assumed that this is not a MIPv6 problem. if you go by that, the spec
was done in Dec of 2000. not much thought was given to this problem
before that. it took more than 2 years to come up with a solution to do
this. I attended a MIPv6 interop event in Sep 2000 where we had all the
features in the base spec working.

> Large documents are hard
> to get through the process because there is so much more that everyone
> has to agree to.

true.

> The exact same thing will happen with any revised document. The
> problem will quite possibly be even worse, because there will be stuff
> that everyone agrees needs to get fixed, but there will be
> controversial (and unrelated) stuff that folks can't agree on, 

why? we are not planning to include any new features in the MIPv6 spec.
you mean the stuff we have currently in the spec (for which we have
concensus) will become controversial again? infact we might be dropping
features from the spec if there is no interest (by those who are
deploying).

> and as
> a result the document won't actually get revised in a timely
> fashion. And then, as time goes on, getting more changes gets even
> harder because more and more implementations have learned how to deal
> with the existing (possibly broken) spec and don't want to change
> their implementations and don't want a revised spec to make their
> implementations valid, and so forth.

nothing broken in the current spec.

> So, I think it is actually quite important that the base spec be split
> apart, and that this is an important step in getting revised documents
> out in a reasonable time period.


I feel having this as one of the primary goals of the WG will only take
up time which could be better spent on working on some deployment
issues. the rest of the charter looks great.

> Even the current history of the spec shows the problems of bundling
> too much stuff into it. The basics for MIPv6 were understood and
> "done" a long time ago. But RO proved to be a big problem.
> Unfortunately, RO was part of the base spec and it was not possible to
> publish just the base MIPv6 two years ago (and I'll note that MIPv4
> doesn't have RO, and is being deployed, so publishing that would have
> been useful). 

its true that smaller specs go through quickly. I am not disputing that.
but, MIPv6 without RO is not very useful. it wouldnt be very different
from MIPv4. just like we want IPv6 to be something more than just larger
address space, we wanted MIPv6 to offer something substanstially more
than what is in MIPv4. Route Optimization in MIPv4 was abandoned, once
the base spec was done. we didnt want the same thing to happen again.

we also have to remember that too many small documents might create a 
situation similar to IKEv1.

Vijay