Re: BOF report: NSIIM

["James Kempf" <kempf@docomolabs-usa.com>]

Warning: I'm heavily implicated in anything involving MIP so read these comments
with that in mind.

> They have lists of issues that they think are base spec issues for
> each proposed WG.  I find myself strongly disagreeing with Jim Kempf,
> who is also here: I'm not convinced that splitting into v4 specific
> and v6 specific groups is a good idea given our current believes about
> it being one dual-stack internet.  I assume that Jim will present his
> own view.  To be fair, Jim did also later bring up MIPv4-MIPv6
> interaction issues, so it's possible that I just haven't spent enough
> time in MIP-hell to understand why this proposed split is the right
> thing.
>
> Apparently part of the problem here is that discussion of the base
> MIPv6 spec has pretty much tied up the current WG for the last several
> years.  Sense of the room seemed to be that this is a real problem,
> question is how to deal with it.
>
> Given how much of this is about dealing with a problem in an existing
> WG that I don't follow, I'm not sure how much I can really add about
> the advisability of what they're proposing here.
>

The basic split between MIPv4 and MIPv6 has pretty strong concensus in the MIP
community. The primary problem is that the constituencies for the two are quite
different. MIPv4 is primarily of interest to 3GPP2, some small vendors, and
Nextel. Their interest is in dealing with deployment-related problems that are
coming up. They are not interested in extending the feature set. The MIPv6
constituency is academics, industrial researchers, 3GPP, and 3GPP2. Their
interest is in cleaning up the base spec, perhaps splitting the base spec into
three or four pieces to make it more modular, and a collection of extensions for
performance optimization and security that are somewhat future-oriented. Given
that widespread deployment is conditioned on widespread deployment of IPv6, the
MIPv6 constituency is not too concerned with deployment issues at this time.

Having all this stuff on one mailing list and in one working group has meant
that some things just do not get discussed because the WG has trouble focussing
on more than one thing at a time. Thus, the last two years have been spent
primarily focussing on completing the MIPv6 spec and any other discussion has
been just pushing into a head wind.

Given those practical considerations, there are some architectural
considerations for splitting the two WGs. Pekka Nikkander and I did a draft,
which was somewhat controversial, in which we talked about the different design
choices in MIPv4 and MIPv6. Some parts of the two protocols are quite similar,
others are very different. The parts where they are different are places where
MIPv6 is doing some performance optimization.

So, given the primarily practical considerations, I think it makes sense to
split the two.

> There was some confusion caused by a poorly worded statement that the
> IRTF should not get into research on seriously different mobility
> mechanisms; that was clarified to mean "this set of IETF WGs could use
> some shorter term help from the IRTF", not an attempt to tell the IRTF
> that it's not allowed to do its own thing.
>
> Some question about other forms of mobility (eg, HIP, which is
> currently sort of trying to position itself as a possible mobility
> solution), should these WGs think about that stuff too?  Probably not,
> but it'd be nice to stop saying that MIP is the only form of mobility,
> even if it's mostly just an accidental side effect of a WG name that
> was chosen a decade ago.
>
> Some discussion of where the right boundary between, eg, this work's
> problem space ends and AAA's begins.  Unsurprisingly, the INT ADs
> appear to be on top of this problem, although some of the usual
> suspects will probably try to stray off the reservation.
>

I think the INT ADs have a pretty good handle on the situation. Like I said
above, the split is primarily of practical concern and I think it will probably
make their management task easier. Careful attention will need to be paid to the
IPv4/IPv6 transition and to AAA for MIPv6, which are topics some in the MIP
community would like to ignore. Also, I've advocated a further MIPv6 split
between topics specific to cleaning up the base draft and advanced topics like
performance optimization. This kind of split has worked well in Transport for
SIP, and I think MIP could benefit from it too.

            jak