Subject: RE: [Mip6] FW: MIP6 agenda (Final)

From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
Date: Mon, 29 Nov 2004 19:30:37 +0100

Hi James,
I agree with your statement below. It looks like some mobility protocols have been brought to completion within the IETF more with the only desire to satisty the will to produce those protocols than with the will to ear the market needs. This is what bring so many protocols to the state of unuseness.  
Eric Njedjou

-----Message d'origine-----
De : James Kempf [mailto:[email-masked]] 
Envoyé : lundi 29 novembre 2004 19:20
À : NJEDJOU Eric RD-RESA-REN; Thierry Ernst; [email-masked]
Objet : Re: [Mip6] FW: MIP6 agenda (Final)

Eric,

I can't find anything specific to object to in your analysis, but I was making a broader point. My point was, that researchers often tend to oversell the interest in implementing and deploying their work, particularly in the IETF. This then leads WGs to get chartered that develop protocols which don't get deployed. Given the enormous amount of time and effort involved in doing IETF work (particularly for the WG chairs and draft editors), I believe it is important to weed out those tendencies early, prior to chartering, and re-direct such research work to the IRTF, where it properly belongs.

            jak

----- Original Message -----
From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Thierry Ernst"
<[email-masked]>; <[email-masked]>
Sent: Sunday, November 28, 2004 7:12 AM
Subject: RE: [Mip6] FW: MIP6 agenda (Final)

Hi James,

The Problem i guess Operators have with the Seamoby Protocols is more
complex.
First, the Seamoby protocols were meant to be operations to be performed
prior/post to running the Fats Handoffs protocols. And Fast Handoffs
protocols themselves are not deployed because operators are still only
assessing the real need to have IP mobility services for their customers as
provided by Mobile IP. Another issue is that the Fast Handoffs protocols
were designed with the 802.11 AP/AR to 802.11 AP/AR handover scenario in
mind. And We can effectively see that people have only be able to implement
the Fast Handoffs protocols for 802.11 handover.  Fast Handoffs do not apply
to GPRS <-> 802.11 handover scnearios. This is because the handover
signalling is something to be exchanged at the very edge of the network
(access routers) and exchanging FMIP signalling between an AR in the 802.11
network and the GGSN in the GPRS core network require the flows to pass via
too many hops, rendering the handover process not reactive as is the will of
having a fast handoff scheme.
Therefore for the GPRS <-> 802.11, the only possible fallback is to use
simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not require
Operators to modify their edge to include SEAMOBY/MIPSHOP operations. When
the need for MIpv4/MIPv6 will really be ascertained, then those protocols
will be considered, but again not for the inter-technology handovers.
Another reason why SEAMOBY/MIPSHOP protocols would not likely be deployed on
a large scale is that even that 802.11 AP to AP handover scenario ( those
protocols fit for) does not require a subnet change in most of the cases.
The whole thing can therefore be handled within L2 as Task Group R of IEEE
802.11 is doing.

Eric Njedjou
France Telecom

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de
James Kempf
Envoyé : lundi 22 novembre 2004 18:43
À : Thierry Ernst; [email-masked]
Objet : Re: [Mip6] FW: MIP6 agenda (Final)

Hi Thierry,

Please don't feel offended, but I tend to discount attestations from
researchers that there is product and deployment interest. For 4 years, we
had researchers saying that there was product and deployment interest in
Seamoby, yet prior to switching the drafts to experimental, we had not a
single vendor or operator willing to say that they were interested in
developing and deploying the protocols. That's why they were switched to
experimental. If there are not vendors and operators willing to come on the
list and participate in the process so their customers can enjoy the
benefits of interoperability, then I don't think this is an appropriate
topic for the mip6 WG, since mip6 isn't chartered to do experimental work.

Regarding ISO, if there's another standardization body that needs the work,
then a liason letter to the IETF via the IAB requesting an Internet standard
might be in order.

However, I believe a more productive track would be to take the work to
Mobopts as Raj and Rajeev have requested, possibly in conjunction with
examining the multihoming work that v6ops is doing for mobility implications
. Rajeev and Bill are working hard to make Mobopts a venue for maturing good
ideas, and I think that this work may now be showing results, since we now
have two drafts there that they are interested in making research group
drafts, for eventual re-introduction into IETF.

            jak

----- Original Message -----
From: "Thierry Ernst" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, November 21, 2004 8:07 PM
Subject: Re: [Mip6] FW: MIP6 agenda (Final)

>
> Hi James,
>
> > Are there any vendors interested in implementing this solution and/or
> > network operators interested in deploying it (note: I'm not asking for
> > detailed product plans, just the kind of committment that was given in,
say,
> > the chartering discussion of the Mobike WG several IETFs ago)? Or other
> > standardization bodies (such as our good friends at 3GPP2) who are
> > interested in incorporating it into their standards?
>
> Peole from various companies have told me so and I would rather let them
> express their opinions directly to demonstrate their true interest. But
> many of them may not be on the list.
>
> Also, there are proprietary solutions and these manufacturers may not be
> eager to standardize their solutions (unless some raise the topic at the
> IETF, in which case they would have to).
>
> For instance, mobile phone company A may want terminals allowing their
> users to switch between 3G/GPRS and 802.11. In their scenario, both
> access networks would belong to the same operator, so a proprietary
> solution is fine.
>
> But from a user perspective, I and other people think standardization is
> important, and there is an important need.
>
> There are for instance the car manufacturers or those making products
> for them (unfortunately, they don't speak up at the IETF because it's
> not in their culture) who need to manage multiple interfaces on their
> MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such
> feature is needed (in their CALM architecture).
>
> About implementation, there is an effort ongoing in a branch of the KAME
> ipv6 stack (don't look for it on the KAME page, you won't find it now)
> and people willing to do the same in USAGI. I don't want to speak up for
> USAGI and KAME people, but as far as reference implementations are
> concerned, we better implement standards rather than proprietary
> solutions, I think you would agree on this.
>
> Thierry.
>
>
>
> >         jak
> >
> > PS: BTW, if you haven't seen it, you should check out the literature on
> > Boeing's Connexion system. It uses BGP to manage routes to a mobile
802.11
> > network in an airplane on a transcontinental flight. Lufthasa has
deployed
> > it on their new A333-600's.
> >
> >
> > ----- Original Message ----- 
> > From: "Thierry Ernst" <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Thursday, November 18, 2004 6:55 PM
> > Subject: Re: [Mip6] FW: MIP6 agenda (Final)
> >
> >
> > >
> > > Dear Rajeev,
> > >
> > > Mobopts is a reseach group (IRTF), the problem that we want to solve
is
> > > much more clarified clarified than that, and solutions could be
brought
> > > in a timely manner if we restrict ourselves to part of the exisiting
> > > problems and extensions to MIP6 and NEMO.
> > >
> > > Of course, taking a look at the whole picture would require much more
> > > consideration, and for the whole picture Mobopts could be the right
> > > place. But, my intention, right now, is not to open the pendora box;
> > > it's rather about bringing a solution to an immediate concern, in a
> > > timely manner: how can I make use of my MIP6/NEMO function when I have
> > > multiple interfaces on my MH/MR ? I can't do it right now, and not
> > > because it's np complex, but because there is no agreed solution
between
> > > the parties involved.
> > >
> > > Regarding what has been said at the MIP6 meeting, taking into account
> > > the feedback from Erik, Thomas, and all the other, I would go for a
BOF
> > > at next IETF, but not with the objective to set up a new WG, but just
a
> > > one-time BOF to discuss the problem thoroughly.
> > >
> > > But, prior to doing that, the other people involved with me on the
> > > problem statement drafts, we should improve/clarify/extend our drafts.
> > > The target would be end of this year; based on new drafts we would
> > > consider setting up a BOF or not. (OK, guys, now we have pressure on
our
> > > shoulders ;-)
> > >
> > > Thierry
> > >
> > >
> > >
> > > On Thu, 18 Nov 2004 10:40:15 -0800
> > > Rajeev Koodli <[email-masked]> wrote:
> > >
> > > > Thierry Ernst wrote:
> > > >
> > > > > > Thus embarking on QoS sensitive, mobility specific multihoming
> > support
> > > > > > is both too open ended (on the QoS side) and too constraining
(by
> > only
> > > > > > looking at cases when MIP/Nemo is used).
> > > > > >
> > > > > > So I think it would be useful for folks to try to think about
and
> > > > > > discuss the bigger picture.
> > > > >
> > > > > Agree. But then, where should this discussion take place ? MIP6 WG
?
> > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ?
> > > > >
> > > >
> > > > I would add to Erik's observation that we need to be able to assess
a
> > topic to
> > > > see
> > > > the maturity of the problem and the state of solutions, as well as
what
> > could
> > > > be standardized in IETF. The IETF should work on well-defined _and_
> > > > well-agreed problems for which protocol specification could be
> > accomplished
> > > > in a timely manner. Topics where the problem needs to be
crystalized,
> > and
> > > > solution
> > > > space needs "thinking" require a forum for discussion. And, MobOpts
> > could
> > > > be such a place.
> > > >
> > > > We (mip*, MobOpts co-chairs) are in the process of working out a
model
> > to
> > > > facilitate closer co-operation between mip* groups and MobOpts. The
> > outcome
> > > > should be focussed discussion on topics of mutual interest that lead
to
> > > > documents
> > > > which can be a) taken up in mip* groups for standardization, b)
MobOpts
> > RG
> > > > RFCs. MobOpts would run milestones and try to produce documents
within a
> > > > timeframe of interest to mip* groups.
> > >
> > >
> > >
>
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Charles E.Perkins" <[email-masked]>
Date: Mon, 29 Nov 2004 12:36:16 -0800

Hello Eric,

It's hard to work towards a solution of the problem
you raise, without knowing which protocols you mean.
Presumably you at least include the [seamoby] protocols
and maybe Mobile IPv6.

In the case of Mobile IPv6, the protocol work was done
according to original requirements for IPv6.  I don't
see exactly which market interaction would satisfy
your apparent request in this case.

Fast Handover was developed to work with Mobile IPv6,
and so the same comments would apply.  The same point
could be applied to [seamoby], roughly speaking, but
the results were adapted for IPv4, and anyway were
strongly influenced by a weird amount of politicking,
problem statement haggling, requirements documentation,
and generalized abstraction detraction.

If, instead, you meant to discuss Mobile IP for
IPv4, then I think the barriers for more widespread
deployment have much more to do with (current)
operator business models than with protocol design.
Even so, We are seeing continued good growth in
deployment, and are poised for much more growth
in the future.

If you didn't mean any of these, then I guess
I missed your message and so please forgive my
irrelevant reply.

Lastly, I have several comments your point:
>          .....
> brought to completion within the IETF more with the
> only desire to satisty the will to produce those
> protocols than with the will to ear the market needs.

- First, I believe you always want to have people
  working on protocols who believe in them, and
  yet are open minded about community involvement

- Second, I really think most IETF engineers are
  in fact responsive to their perception of
  market needs.  As an example, the work on Fast
  Handovers was motivated quite strongly by the
  perceived need to enable Mobile IP to work
  with VoIP.

- Third, the market does not want protocols.
  The market wants systems.  IETF should not, in
  my opinion, get into the business of designing
  market-ready systems.  Instead, I think we should
  make protocol components that can readily be
  built into many systems of various kinds.

There is a lot of room for expertise at various levels.
Protocol engineering is one area of expertise, and
system integration is another, for instance.  Both
work better with good understanding of other areas
of expertise, e.g. security, and systems programming.
Maybe what we are getting now in the IETF isn't
such a bad mix of the various areas of expertise.
We can ask for some of the participants to be
economists or policy experts, but it might be
asking too much to require in every case.

Regards,
Charlie P.