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

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

I thing the multihoming problem could potentially have future markets interests and could be worthwile looking at though. As an example access service providers would be selling ubiquitous wireless services. These may require that the multihoming problem be well understood  
Eric 

-----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: "James Kempf" <[email-masked]>
Date: Mon, 29 Nov 2004 14:17:03 -0800

Eric,

This is exactly the kind of speculative grounds that I am trying to warn
against. If the problem is not well understood, then IRTF is the right place
for it. If it is well understood and people are ready to design a protocol
to solve it, then IETF is the right place for it.

Having a good problem statement is a start, and I believe there has been
some discussion about that on the list. The process of developing the
problem statement, and the problem statement itself, should reveal a good
deal about how well understood the problem is.

            jak

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

I thing the multihoming problem could potentially have future markets
interests and could be worthwile looking at though. As an example access
service providers would be selling ubiquitous wireless services. These may
require that the multihoming problem be well understood
Eric

-----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"

Hi James,

Eric Njedjou
France Telecom

-----Message d'origine-----

Hi Thierry,

            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)

say,
802.11
deployed
is
brought
between
BOF
a
our
(by
and
?
a
what
crystalized,
model
to
MobOpts
within a

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 30 Nov 2004 11:03:32 +0900

Hi James,

> to solve it, then IETF is the right place for it.

The problem is sufficiently well understood, but no sufficiently well
stated. We are working on the a problem statement, which I agree must be
improved. We just haven't invested so much time on it because we wanted
to sense the need for such a document before. But now, I clearly see the
need to make this statement clearer.

Besides this, tens of solutions have been proposed. The only problem is
that each solution brings an answer to an individual issue. So, the
purpose of the problem statement is not to get a better understanding of
the problem, but to write it black on white to that we can work together
on a comprehensive solution, hopefully giving an answer to more than one
issue.

I don't see a need to shift such work to the IRTF as this is clearly not
academic, but highly technical. Bringing features allowing the use of
multiple interfaces in MIPv6 (well, both to MIP6 and NEMO, indeed) is
something very concrete. If the intend is to consider the host
multihoming issues with no specific protocol in mind, then, yes, I would
agree that this belongs to the IRTF.

If the purpose of the IETF is to produce protocols that have a better
chance to be deployed, the support of multiple interfaces in MIP6 is
surely one means that will help a wider deployment of the (so long ...)
work produced by this WG.

If I was to follow your position on IRTF vs IETF, I think most of the
work conducted at the IETF could have been shifted there, and WGs like
IPNG, Multi6, Mobile IP wouldn't have ever existed.

> deal about how well understood the problem is.

BTW, I don't buy your (could be offending ;-) statement about
"researchers".

Thierry.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 30 Nov 2004 08:29:29 -0800

Thierry,

jak>> This expresses a common misconception about IRTF. IRTF is not meant to
be academic, it is meant to be a place where ideas are refined before they
are well enough understood for concensus to be achieved on the basic
architecture and design of the protocol, when the problem is not well
understood. It is not meant to be a place to do research without any
connection to IETF standardization work.

jak>> Regarding this particular problem, I can think of a few cases where
there might be some specific enhancements to mip6 that might not require
IRTF work (for example, allowing the registration of multiple home
addresses) because they are well enough understood but what I am concerned
about is that the people will immediately push for more. An example here is
nemo. While the initial problem of using Mobile IP for mobile networks was
well understood, people were pushing from the very beginning to do route
optimization, which has even proved a hard problem for individual hosts.
IMHO, the route optimization work for networks should have been moved to
IRTF immediately when the WG was chartered, and the WG should have
concentrated on solving the near term problem. Unfortuantely, at that time,
there was no mobopts RG, which would have been the right place for the work,
so it was put into the charter for later. That had the effect of essentially
delaying any work to understand the problem better, whereas, if it had been
put into the IRTF, the issues (particularly regarding security) could have
been studied in parallel with the standardization of Mobile IP for mobile
networks.

jak>> So, in the end, it actually helps get the whole problem solved if the
easy, well-understood parts are done in IETF and the harder ones are done in
IRTF.

jak>> The purpose of IETF is to produce protocols that *get deployed*, IMHO.
Work should be chartered only if the preconditions for that are available.

jak>> Point noted. It was not meant to be offensive, just a summary of my
experience with Seamoby. After all, I do a certain amount of research
myself.

                         jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 30 Nov 2004 17:12:24 -0800

> agree that this belongs to the IRTF.

As I mentioned in a previous e-mail, IRTF MobOpts is not working
on things academic, although I would not discorage academic work.
Instead, our intention is to work on focussed topics of relevance to
IETF and bring them back to IETF. In other words, all the fun
discussion surrounding multiple proposals could take place in MobOpts.
Specific to host multi-homing using MIP:  One approach could be
to write a single problem statement for both MIP6 & MobOpts, produce a document
in
MobOpts and bring it back to MIP6 for standardization. That way,
the solution would already be well-understood for standardization.

-Rajeev