Subject: [nemo] Charter update, continued

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 19 Sep 2006 19:18:10 -0700

Hi folks, I'm back..

Here is the current version of the charter. I am still making  
changes, and need to modify the milestones section. But wanted to  
share what's there now and see if there are any comments.

Please send comments directly to me, for the moment, and when I have  
the next version we can discuss it on the list.

http://www.mobilenetworks.org/nemo/charter2_3.txt

TJ

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Sep 2006 11:02:09 +0200

> http://www.mobilenetworks.org/nemo/charter2_3.txt

TJ, thanks for posting the new Charter proposal.  There is one specific
item I would like to ask in this message:

"- Work with the Mobile IPv4 working group to hand over work on
    IPv4-only NEMO solutions."

Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call
through this WG, supposedly ending September 30th.  How do you (and WG
members) see transition to the MIP4 WG?

I see it as being finalised here and submitted to IESG, and only then
eventually taken on by the MIP4 WG.

Thanks,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Sep 2006 11:34:43 +0200

> http://www.mobilenetworks.org/nemo/charter2_3.txt

Another remark on the Charter2_3.  It has an item:
"??? 2006		Submit -00 draft on Route Optimization for
			geographically distributed HAs"

However, this is not currently a WG item (so can't be considered as
"finishing ongoing WG documents") and has no other textual description
in charter2_3.  What is it about?  Is it
draft-wakikawa-mip6-nemo-haha-01.txt or
draft-wakikawa-mip6-nemo-haha-spec-00?

We've had a long discussion previously about the need and feasibility of
  HAHA protocols.  There may have been many conclusions, I don't remember
all.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 22 Sep 2006 12:41:34 +0200

Hi Alex,

Thanks for the comment.

I don't know what was TJ's intention in this sentence, but I propose to
remove it from the charter. 

It was agreed at last july that the MIPv4 work should be done in the
MIP4 WG, and that the NEMO WG is just going to complete it's work on the
NEMOv4 Informational draft which is - as explained by Alex - going to be
sent to the IESG. Since it's an informational draft, we don't expect any
more CPU time from the NEMO WG so mentioning it in the new charter is
pointless IMHO.

Thierry.

On Fri, 22 Sep 2006 11:02:09 +0200

-- 
Thierry ERNST, PhD
http://www.nautilus6.org/~thierry
IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair
--
INRIA Rocquencourt Project-Team IMARA, France.
+33 1 39 63 59 30 (office)

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 22 Sep 2006 06:01:05 -0700

If this work is taken over by MIPv4 shouldn't MIPv4 decide whether to
make this Informational or standards track? 

Since MIPv4 WG is more interested in this work we might be able to go
through peer review of this work more properly there.

George

> -----Original Message-----
> From: Thierry Ernst [mailto:[email-masked]]
> Sent: Friday, September 22, 2006 6:42 AM
> To: Alexandru Petrescu
> Cc: [email-masked]; [email-masked]
> Subject: Re: v4 (was: [nemo] Charter update, continued)
> 
> 
> Hi Alex,
> 
> Thanks for the comment.
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Sep 2006 07:07:51 -0700

> members) see transition to the MIP4 WG?

at the last IETF, the MIP4 WG expressed willingness
to take on this document and even standardize it as
a proposed standard.

process wise, it is simple. the authors just need
to submit the draft to the MIP4 WG. the NEMO WG
chairs just need to remove this draft from the NEMO
charter.

> eventually taken on by the MIP4 WG.

there is no need to do this.

I would favor doing this in the MIP4 WG and let the
MIP4 WG decided whether it will be Informational or
Standards track.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Sep 2006 16:32:48 +0200

Sounds feasible, thanks for all the suggestions, I would even prefer it
if it were not for the following:

I would rather prefer it sent to IESG from here than from MIP4.  IESG is
used with network mobility documents coming from here.  I would not
prefer delays coming from misunderstanding by IESG answering
questions: where was it developped?  where was it LC'ed?  who sends it?
  The double answer to this makes it - probably - difficult to understand.

It may also be that it can go to IESG from MIP4 relatively smoothly - I
do not know.

I think we need advice from AD about how to proceed with the least
bottlenecks.

Thanks,

Alex

Vijay Devarapalli wrote:
>> TJ, thanks for posting the new Charter proposal.  There is one
>> specific item I would like to ask in this message:
>> 
>> through this WG, supposedly ending September 30th.  How do you (and
>> WG members) see transition to the MIP4 WG?
> 
> at the last IETF, the MIP4 WG expressed willingness to take on this
> document and even standardize it as a proposed standard.
> 
> process wise, it is simple. the authors just need to submit the draft
> to the MIP4 WG. the NEMO WG chairs just need to remove this draft
> from the NEMO charter.
> 
>> I see it as being finalised here and submitted to IESG, and only
>> then eventually taken on by the MIP4 WG.
> 
> I would favor doing this in the MIP4 WG and let the MIP4 WG decided
> whether it will be Informational or Standards track.
> 
> Vijay
>

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 22 Sep 2006 16:38:23 +0200

I think what said Vijay is the right thing to do. Just submit the draft
in MIP4 and let the group decide what to do. Alternatively, keeps it as
informational in the NEMO WG and sends it to the IESG as is after the LC
is over. I prefer the former. 

Thierry

On Fri, 22 Sep 2006 16:32:48 +0200

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 22 Sep 2006 16:57:48 +0200

Below:

> MIP4 WG decided whether it will be Informational or

Yes, that would make the most sense to me.

	Henrik

---

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Sep 2006 09:54:05 -0700

Yes, I agree. If the NEMO WG wants to move this to MIPv4, then it is up to 
the MIPv4 WG to decide the document publication status.

            jak

----- Original Message ----- 
From: "Tsirtsis, George" <[email-masked]>
To: "Thierry Ernst" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>; "Pete McCann" <[email-masked]>; <[email-masked]>; 
"Henrik Levkowetz" <[email-masked]>
Sent: Friday, September 22, 2006 6:01 AM
Subject: RE: v4 (was: [nemo] Charter update, continued)

George

> > TJ, thanks for posting the new Charter proposal.  There is one
specific
> > through this WG, supposedly ending September 30th.  How do you (and
WG
> > I see it as being finalised here and submitted to IESG, and only
then

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 22 Sep 2006 11:57:47 -0700

The only problem is that MIP4 WG needs another re-chartering to make
NEMOv4 work its own. It would be nice if this is done promptly so that
the NEMOv4 base draft does not find itself in limbo.

George 

> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, September 22, 2006 12:54 PM
> To: Tsirtsis, George; Thierry Ernst; Alexandru Petrescu
> Cc: [email-masked]; Pete McCann; [email-masked]; Henrik Levkowetz
> > NEMOv4 Informational draft which is - as explained by Alex - going
to
> be

---

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Sep 2006 14:09:32 -0700

If that is the only item that needs to get into their charter, it shouldn't 
require a lot of discussion. Or is there some amount of controversy in the 
MIPv4 WG about whether or not it should be taken up?

            jak

----- Original Message ----- 
From: "Tsirtsis, George" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Thierry Ernst" 
<[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>; "Pete McCann" <[email-masked]>; <[email-masked]>; 
"Henrik Levkowetz" <[email-masked]>
Sent: Friday, September 22, 2006 11:57 AM
Subject: RE: v4 (was: [nemo] Charter update, continued)

George

to

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 22 Sep 2006 23:23:39 +0200

Hi James,

> MIPv4 WG about whether or not it should be taken up?

Nope.  This was discussed in the MIP4 meeting in Montreal, and there was clear
consensus on taking this on, and there has been no contrary comments on the
mailing list later.

The MIP4 minutes from Montreal reflects this consensus clearly, as well as the
expressed intention of putting this into a revised charter:

  http://tools.ietf.org/wg/mip4/minutes?item=minutes66.html

Regards,

	Henrik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 25 Sep 2006 10:15:36 +0200

My understanding of the comments in the last meeting was that we were 
going _first_ to identify what are the relevant scenarios for which we 
need to design RO solutions and their requirements and only _after_ 
that we are going to work in actual solutions.

I mean, my recollection of Thierry's suggestion was to have a first 
rechartering where we include items about identifying relevant 
scenarios and requirements for RO and when this is done a new 
recharter, to include the design of solutions for the identified 
scenarios

As i previously mentioned here, i think it is very hard to evaluate how 
approapriate a solution is if we don't have explicitly fleshed out what 
the problem and requiremnets are

So i would suggest to remove the item

Submit -00 draft on Route Optimization for geographically distributed 
HAs

And to include an item about providing a new ID -00 about identifying 
scenarios and requirements for RO

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 25 Sep 2006 15:17:36 +0200

Dear all,

I have been involved in some groups working on communication between
vehicles and the roadside and vehicle-vehicle communications through
the Internet. For their scenarios, 2 RO needs emerge:

1. The MR in the vehicle should be able to communicate with a CN on the
roadside without going through the MR-HA tunnel. 

2. A MR in a vehicle should be able to communicate with another MR in
another vehicle via the Internet infrastructure but packets flowing via
the HAs of both MRs should be avoided.

May be we could have these listed in the new charter more explicitly.

Thierry.

On Tue, 19 Sep 2006 19:18:10 -0700

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 25 Sep 2006 15:33:50 +0200

Hi Thierry,

I thought that the new charter would only be tasked to identify the use 
cases and requirements and that future rechartering was needed to 
actually enter in the solution space.

At least that was what i understood from your answer in the last 
meeting when you said:

"  Thierry:
      For the new charter, I would have a doc on use-case, and that's 
it."

(from the montreal meeting in the RO discussion)

I don't have a problem with dealing with the requirements that you 
comment, which i guess are valid problems, but my understanding is that 
we were going to describe these in a docuement that was to be produced 
and disucssed in the wg, rather than in the charter...

My point is, i would include a charter item that is to produce an ID 
with the use cases (e.g. car industry) and their requirements (e.g. 
those you mention below) rather than including these requirements in 
the charter itself.

Bottom line is that i guess that the discussion of the requirements 
should not be part of the charter discusion but part of the 
requirements/use case ID discussion.

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 25 Sep 2006 15:55:45 +0200

Hi Marcelo,

True, that was my intention at first but it was also pointed out that
TJ's draft charter was a good start and that we should detail it further
and be more explicit.

The RO problem is already discussed in the 2 drafts, so I think it is
well understood enough.

Regarding the use cases, these would surely help, but it appears that
what is needed by the aviation industry is pretty far from NEMO Basic
Support (i.e. not a mere optimization) and the car industry is still in
the process of trying to understand what the IETF is (a bit like 3GPP a
while ago if you see what I mean) so I wouldn't expect them to come up
with a clear description of the use cases in the next 2 years (though
they [=some organizations like ISO] DO work on an architecture based on
NEMO and IPv6 but are still far from understanding the IETF folks could
help and save them some mistakes in their architecture).

So, with respect to what you concluded below, the new charter could list
as deliverable a use case documents (but it is most likely to be
produced by us targetted the organizations such as ISO than the other
way round) and some solutions for the RO problem in which we have
identified needs (the 2 I listed), which are reasonably easy to solve,
and for which we possibly have candidate solutions.

Thierry

On Mon, 25 Sep 2006 15:33:50 +0200

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 25 Sep 2006 18:03:50 +0200

> True, that was my intention at first but it was also pointed out that

it is unfortunate that you have changed your mind... i thought there 
was concesous in the meeting about following this approach (at least 
the 3 people that commented seemed to agree with this approach, Jari, 
Hesham (ccopied) and myself)

> The RO problem is already discussed in the 2 drafts, so I think it is

i agree that the problems resulting from not having RO are well 
understood and also i think it is understood that there are many 
solutions that provide different sets of features and deal with 
differents parts of the problems resulting from not having RO

it is also clear imho that no one size fit all solution to deal with 
all the issues

i guess that we also agree that we are not going to standarize alll the 
existent proposals (i guess there are over 20 nemo RO proposals)

so, how do we choose which solutions to standarize?

a reasonable approach was to identify relevant use cases and provide 
solutions for these. that is to define requirements for those use cases 
that have potential users and then use these requirements as a 
selection criteria to define which solutions to standarize

but if we don't produce these requirements then we don't know which 
solution we need

so how do we proceed in this case?

I guess that all the people that has proposed a solution has a 
different idea of what is important and they have produced a solution 
folloing these things they consider that are relevant. So each solution 
will be superior to the others if the particular features provided are 
considered relevant

> Support (i.e. not a mere optimization)

i dont see why this is a problem

i mean, aviation seems to be one of the most relevant cases for 
deploying moving networks and if they need a solution i would say that 
the problem is relevant (especially considering what they do if we 
don't provide an alternative solution, injecting BGP routes and 
introducing bgp instability is not the best for the health of the 
network i guess)

so, i would take Terry's draft and try to figure out how can we provide 
what they need using nemo and possible extensions. We can come to the 
conclusion that nemo is not a good starting point and we need a 
completelly different strategy (and then we need a different bof or 
whatever) but i defnietely think we should try to figure out if it is 
possible to fulfill their requirements making some nemo extensions.

That's is why the idea of producing only requirements draft at this 
rechartering stage was good. we can produce the requirements draft and 
evaluate if we can provide what they need with nemo extensions. If we 
can we recharter to do so, if not we should go for a bof

>  and the car industry is still in

that is unfortunate also...

but i thought some people from the car industry were trying to submit a 
draft for the last ietf...

> and for which we possibly have candidate solutions.

how do we decide that we will focus in these particular needs and not 
in other needs?
i mean what we would be doing would be to determine that some of the 
requirements are the ones that we will try to satisfy, but what are the 
grounds to select these two requirements and not others?

having a user requirements has the benefit that we the requirements 
have been set up by a potential user that seems to have a real need...

Regards, marcelo

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Sep 2006 07:46:06 -0700

marcelo bagnulo braun wrote:
> Submit -00 draft on Route Optimization for geographically distributed HAs

disagree. the "geographically distributed HAs" was a
much more specific problem. it is not intended to be
a general purpose route optimization solution. even
when you have a route optimization solution, you
would still need something to address distributed HAs.

I actually dont mind removing the word "Route
Optimization" from the above sentence. the fact is it
does some sort of route optimization as a side effect.
and it doesn't involve the mobile routers in route
optimization. thats a good feature. :)

Vijay

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 26 Sep 2006 11:18:35 +0900

Dear Thierry,

> the HAs of both MRs should be avoided.

In both case RFC3963 allows the MR to use RO with a CN or another MR for 
its own local traffic. To avoid some confusion, I think it would be 
better to describe the requirements from the MNN point of view.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 26 Sep 2006 10:19:55 +0800

Hello Vijay,

> optimization. thats a good feature. :)

Perhaps Geographically Distributed HA has aspects which is not related
to RO, but it has nothing specific to NEMO.  MIP6 WG is already starting
to look at HA reliability etc.  If the item is not presented as an RO
approach to the RO problem (which arguably would benefit NEMO more since
it scales better with NEMO than with mobile hosts), I see no reason why
NEMO WG should work on it.

/rgds
/cwng

---

From: Andy Huang <[email-masked]>
Date: Tue, 26 Sep 2006 11:10:52 +0800

I agree with you on the point that it will be better to replace MR with MNN 
in the requirements.
But is there anything related to RO in RFC3963? I don't see anything about 
it.

----- Original Message ----- 
From: "Romain KUNTZ" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 26, 2006 10:18 AM
Subject: Re: [nemo] Charter update: RO between MR and foreign access network

>> roadside without going through the MR-HA tunnel. 2. A MR in a vehicle 
>> should be able to communicate with another MR in
> its own local traffic. To avoid some confusion, I think it would be better 
> to describe the requirements from the MNN point of view.
>
> Regards,
>
> -- 
> Romain KUNTZ
> [email-masked]
>
>

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 26 Sep 2006 12:21:01 +0900

Hello,

In section 1:
    All traffic between the nodes in the Mobile Network and Correspondent
    Nodes passes through the Home Agent.  This document does not describe
    route optimization of this traffic.

In section 3:
    For traffic originated by itself, the Mobile Router can use
    either reverse tunneling or route optimization, as specified in
    [RFC3775].

romain

Andy Huang wrote:
> I agree with you on the point that it will be better to replace MR with 
> MNN in the requirements.
> But is there anything related to RO in RFC3963? I don't see anything 
> about it.
> 
> ----- Original Message ----- From: "Romain KUNTZ" <[email-masked]>
> To: <[email-masked]>
>> In both case RFC3963 allows the MR to use RO with a CN or another MR 
>> for its own local traffic. To avoid some confusion, I think it would 
>> be better to describe the requirements from the MNN point of view.
>>
>> Regards,
>>
>> -- 
>> Romain KUNTZ
>> [email-masked]
>>
>>
> 
> 
> 

-- 
Romain KUNTZ
[email-masked]

---

From: Andy Huang <[email-masked]>
Date: Tue, 26 Sep 2006 11:21:46 +0800

----- Original Message ----- 
From: "Chan-Wah Ng" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; "ml-nemo WG" 
<[email-masked]>; "T.J. Kniveton" <[email-masked]>
Sent: Tuesday, September 26, 2006 10:19 AM
Subject: Re: [nemo] Re: RO for geographically dist'd HAs

> NEMO WG should work on it.

In fact, a WG draft has been designed by DT in MIP6 WG.
https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt

Do you think we need a especial HA reliability protocol for NEMO?

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Sep 2006 20:32:10 -0700

This looks like a good start for a more specific set of requirements for RO. 
I don't think these requirements necessarily need to be in the charter, but 
I think the charter could be made more specific with respect to what 
particular cases will be used, for example this one.

            jak

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 26 Sep 2006 12:10:43 +0800

Hello Andy

> Do you think we need a especial HA reliability protocol for NEMO? 

At a first glance, I don't see why NEMO need something different.
Unless someone is deploying a home agent inside a mobile network, as
illustrated in the nemo-use-case and nemo-ro-ps drafts.

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Sep 2006 22:59:41 -0700

sigh... this is the third or the fourth time I
am sending the following to the NEMO mailing
list. people should really look up the archives
before sending mails.

there was one spec to start with. it was called
the HAHA protocol. then it was split into three.
one was base HAHA which defined messages that
are exchanged between two home agents for
binding cache sync, hello messages, etc. the
second was local HAHA for HA reliability. third
was global HAHA for geographically distributed
HAs. note that all of them contribute to how the
MIP6/NEMO home network is configured and
operates.

the base HAHA and the local HAHA contributed
towards the HA reliability protocol that is
being standardized in the MIP6 WG. the spec in
the MIP6 WG assumes the HAs are still on the
same home link. geographically distributed HAs
are not addressed in that spec.

there has always been a lot of interest in global
HAHA in the NEMO WG whenever it has been presented.
that is why it still appears in the NEMO WG.

> Do you think we need a especial HA reliability protocol for NEMO?

if you take a look at the drafts, the messages
used by global HA would be the same as the ones
defined in draft-ietf-mip6-hareliability. the
current DT draft does not address geographically
distributed HAs.

Vijay

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 26 Sep 2006 14:39:55 +0800

Hello Vijay,

Thanks for clarifying ... and for sending the same mail 3 or 4 times :)
However, it changes nothing.  Global HAHA has nothing NEMO specific in
terms of reliability (except when a HA is in a mobile network).  In
fact, since the base messages and the local scope version of the spec
are being developed in MIP6, I seriously don't see any reason why the
global version should be done in NEMO and not MIP6.

Note that the above comment is in response to the treatment of Global
HAHA as a HA reliability mechanism.  If instead we are looking at route
optimization problem, I would agree to looking into something I called
"Infrastructure-based RO" where Global HAHA is clearly a candidate, but
it shouldn't be identified as a charter item.

/rgds
/cwng

---

From: Andy Huang <[email-masked]>
Date: Tue, 26 Sep 2006 14:45:45 +0800

Hi, Vijay:

I did remember you had explained the history of HAHA protocol when people 
discussed the proposed charter and global HAHA protocol in April. You 
emphasized that global HAHA is not a general RO solution for NEMO and RO is 
a side effect last time. It seems to me that there has been a kind of 
consensus about it at that time. Maybe I made a mistake.

Regarding the proposed charter: 'Submit -00 draft on Route Optimization for 
geographically distributed HAs'
Why do we discuss the same question once again?

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Andy Huang" <[email-masked]>
Cc: "Chan-Wah Ng" <[email-masked]>; "ml-nemo WG" 
<[email-masked]>
Sent: Tuesday, September 26, 2006 1:59 PM
Subject: Re: [nemo] Re: RO for geographically dist'd HAs

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Sep 2006 09:16:50 +0200

El 26/09/2006, a las 5:32, James Kempf escribió:

> This looks like a good start for a more specific set of requirements 
> for RO. I don't think these requirements necessarily need to be in the 
> charter, but I think the charter could be made more specific with 
> respect to what particular cases will be used,

actually, in the last meeting in montreal, the consesous was that the 
only item added to the charter was to identify RO use cases (like 
aviation, or car industry) and define the specific requirements for the 
identified use cases.

After we have done that, we could recharter again the wg to produce the 
actual RO solutions. At this point we would be in a very good shape to 
select among the over a dozens RO proposals, since we would have the 
requirements docuemtns as a selection criteria.

This would allow us to:
- produce solutions that have potential users and suit their 
requirements
- have an easy procedure to select among the existent proposals.

I think this approach is much better than having the discussion on the 
requirements now and include them in the charter, since i think that 
the definition of requirements needs the review of a RFC rather than 
the time required by a charter discussion

Regards, marcelo

>  for example this one.
>
>            jak
>
> ----- Original Message ----- From: "Thierry Ernst" 
> <[email-masked]>
> To: <[email-masked]>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Sep 2006 09:20:54 +0200

Hi Vijay,

> are not addressed in that spec.

so if the goal of global haha is neither RO and nor HA reliability,  
what is the goal of global haha?

I mean, my understanding is that the goal of global haha is reliabilty  
when you have has distributed geographycally, but this is still HA  
reliability, right?

so, probably it makes sense to do all the work on reliability in the  
same wg...

regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 26 Sep 2006 11:26:28 +0200

> better to describe the requirements from the MNN point of view.

Hi Romain,

Your are right, I was implicitly refering to the traffic originated from
the MNN which has to be sent over the bidirectional tunnel.

On the other hand, if we do consider the case where the MR is
originating the traffic, yes, the MR could use the CoA as the source
address. In this case, these packets are not sent over the bidirectional
tunnel.  But this raises an interesting issue. What if the MR move again
and want to maintain the connection originated from the previous CoA ?
It needs to register with a HA in the previous visted network.

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Sep 2006 12:24:42 +0200

Thierry Ernst wrote:
>>> I have been involved in some groups working on communication 
>>> between vehicles and the roadside and vehicle-vehicle 
>>> communications through the Internet. For their scenarios, 2 RO 
>>> needs emerge:
>>> 
>>> 1. The MR in the vehicle should be able to communicate with a CN
>>>  on the roadside without going through the MR-HA tunnel.

A netlmm solution could work for this?

>>> 2. A MR in a vehicle should be able to communicate with another 
>>> MR in another vehicle via the Internet infrastructure but packets
>>>  flowing via the HAs of both MRs should be avoided.

Must the two talking vehicles be within the wifi range?  (cca 50m).  If
yes, it may be that the requirement does not involve supporting IP
mobility: if the two vehicles move further from each other they probably
don't need to talk to each other.

What does the application look like in these requirements?  Video
stream?  Bumper radar approaching?  Road side emergency call?  These are
three very different types of applications with respect to networking
behaviour.  Video stream between two cars is continuous packet flow,
unidirectional.  Bumper radar approaching is messages sent periodically.
   Emergency call is voip duplex continuous exchanges.  For some IP
mobility is needed, for others not (bumper approaching is one example).

>> In both case RFC3963 allows the MR to use RO with a CN or another 
>> MR for its own local traffic. To avoid some confusion, I think it 
>> would be better to describe the requirements from the MNN point of
>>  view.
> 
> Hi Romain,
> 
> Your are right, I was implicitly refering to the traffic originated 
> from the MNN which has to be sent over the bidirectional tunnel.
> 
> address. In this case, these packets are not sent over the 
> bidirectional tunnel.  But this raises an interesting issue. What if
>  the MR move again and want to maintain the connection originated
> from the previous CoA ? It needs to register with a HA in the
> previous visted network.

The apps run on MR can do 3775 RO, using MR's Home Address and RR tests.

Using a CoA as src address of app packets on MR is not a solution that
supports mobility, as you say.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Sep 2006 08:24:50 -0700

hi Marcelo,

> aviation, or car industry) and define the specific requirements for the 

I saw hardly a couple of folks go to the mike.
and since when did whatever was decided at a
meeting override whats been discussed on the
mailing list so far. infact Pascal wasn't at
the meeting. you would have heard a few things
from him. :) I didnt bother going to the mike.

RO has been discussed for a long time on the
mailing list. its got more history than what was
just discussed at the last meeting.

Vijay

> - produce solutions that have potential users and suit their requirements
> requirements now and include them in the charter, since i think that the 
> definition of requirements needs the review of a RFC rather than the 
> time required by a charter discussion
> 
> Regards, marcelo
> 
>>  for example this one.
>>
>>            jak
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Sep 2006 10:22:13 -0700

marcelo bagnulo braun wrote:

> so if the goal of global haha is neither RO and nor HA reliability, what 
> is the goal of global haha?
> 

no. it is more about getting the geographically
distributed HAs to provide mobility for the same
set of MNs/MRs.

here is a realistic scenario. an operator in the
US can have multiple home agents distributed
geographically. they won't be all in the same
room. you can allocate the home agents dynamically
based on the MN/MR location. you can also
dynamically switch HAs with global HAHA.

> so, probably it makes sense to do all the work on reliability in the 

I guess you haven't gone through the draft.

Vijay

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 27 Sep 2006 11:59:08 +0800

Hello all,

> I guess you haven't gone through the draft.

As a co-author, perhaps you want to point out where in the draft covers
NEMO-specific content? You use the term MN/MR, suggesting that it is
catered for mobile node (host+router) in general.

> just discussed at the last meeting.

Vijay brought out a good point, people have been talking about RO since
even before the WG was formed.  So, interest in standardizing it is
definitely there.

However, pulling the discussion back on topic, I still see nothing
NEMO-specific in terms of global HAHA as a HA reliability protocol.  If
the WG decides that it wants to go straight into standardizing RO
solutions, I am fine with it.  But then, global HAHA should not be
singled out.  It is merely a candidate solution for a particular class
of RO solution.

In summary, IMHO:

(1) global HAHA for HA reliability in general should not be included as
a NEMO WG charter item (as there is nothing NEMO-specific);

(2) NEMO-specific HA reliability (eg. HA in NEMO) may be considered as a
NEMO WG charter item (problem statement first);

(3) If WG decides to add RO solutions into WG charter, no RO solution
proposal should be singled out as a WG charter item at this stage.
Instead, a few classes of RO solution should be included, such as:
  (a) Nested Tunnel Optimization
  (b) Infrastructure-based Optimization
  (c) MR providing RO for legacy (MIP6 included) MNNs

(4) If WG decides it's still too early (after all, we have been talking
about RO for close to 5 years now) to add RO solutions into WG charter,
a WG charter item should be added to document RO requirements from
various industries.

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Sep 2006 18:51:28 -0700

> catered for mobile node (host+router) in general.

I am not so particular where its done in this case.
so is "why not in MIP6 WG" your main reason for
objecting to this work?

Vijay

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 28 Sep 2006 10:40:33 +0800

> so is "why not in MIP6 WG" your main reason for

I think NEMO WG is formed to work on items specific to Mobile Networks
or Mobile Routers, and something that is general to mobile nodes should
be done in MIP6, MIPSHOP, or MOBOPS.

True, its doesn't matter to people like you and me where the work is
done.  But in terms of getting public review, where the work is done is
important.

Take the multihoming work I have been doing for instance.  The WG has
been stressing that only issues that are specific to NEMO should be
considered in NEMO WG, this is one of factor leading to the formation of
Monami6.  HA reliability is no different.

But I am curious as to why global HA reliability was not worked on by
the MIP6 WG?

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Sep 2006 21:47:46 -0700

> But I am curious as to why global HA reliability was not worked on by

because global HAHA is not about HA reliability. It
was really done to remove the dependency on link
local mechanisms like ICMPv6 options for building
the home agent list. These mechanisms don't work if
the HAs are distributed geographically.

frankly global HAHA has not been proposed in the
MIP6 WG. only HA reliability work has been proposed
there. even that was first presented in NEMO WG
since it was felt NEMO needs HA reliability
mechanisms more than MIP6.

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 28 Sep 2006 12:19:59 +0200

El 26/09/2006, a las 17:24, Vijay Devarapalli escribió:

>> aviation, or car industry) and define the specific requirements for 
>> the identified use cases.
>

agree

still it is a bit strange that in the meeting the wg chairs propose an 
approach to continue with the wg work, all the people that go to the 
mike agree (there were few of them, i agree, but one of them was the AD 
in charge) (this means that none oppose to the wg chair proposal), and 
next the wg chair continue in a different direction (without any 
(public) request from anyone in the wg ml)... do you agree that this is 
somehow surprising

regards, marcelo

> Vijay
>
>> After we have done that, we could recharter again the wg to produce 
>> the actual RO solutions. At this point we would be in a very good 
>> shape to select among the over a dozens RO proposals, since we would 
>> have the requirements docuemtns as a selection criteria.
>> This would allow us to:
>> I think this approach is much better than having the discussion on 
>> the requirements now and include them in the charter, since i think 
>> that the definition of requirements needs the review of a RFC rather 
>> than the time required by a charter discussion
>> Regards, marcelo
>>>  for example this one.
>>>
>>>            jak
>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 28 Sep 2006 12:31:57 +0200

> a WG charter item should be added to document RO requirements from

i agree with Chan-Wah in all the above points

i would prefer 4 rather than 3, but...

regards, marcelo

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 28 Sep 2006 05:31:52 -0700

> > (2) NEMO-specific HA reliability (eg. HA in NEMO) may be 
 > considered as 
 > > a

=> Me too. 

Hesham

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 28 Sep 2006 15:43:25 +0200

El 26/09/2006, a las 19:22, Vijay Devarapalli escribió:

>> I mean, my understanding is that the goal of global haha is  
>> reliabilty when you have has distributed geographycally, but this is  
>> still HA reliability, right?
>

but why do you want to do this?

the motivations that i can see for doing this is to achieve RO or HA  
reliability, what else can be the motivations for this?

> dynamically switch HAs with global HAHA.

yes, this seems indeed a reasonable scenario, but what is the ISP after  
in this setup? again, RO and HA reliability come to my mind...  
something else that i am missing?

Regards, marcelo

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 28 Sep 2006 10:37:00 -0700

marcelo bagnulo braun wrote:

> in this setup? again, RO and HA reliability come to my mind... something 
> else that i am missing?

not have all home agents in one room, but still provide
the same set of services from the same packet data
network. current MIPv6/NEMO specs restrict the HAs to
the same home link. can't be distributed geographically.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 28 Sep 2006 10:46:23 -0700

> i would prefer 4 rather than 3, but...

requirements are useful, yes. however, the problem is well
known. there are two main scenarios 1. route optimization
for the nodes in the mobile network 2. route optimization
for traffic between the two MNNs in the same mobile network.
(global HAHA is separate).

we document the problem and figured out what scenarios need
solutions.
http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt
there is also a document that does an excellent analysis
of the solution space.
http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-03.txt

personally I believe it is time to standardize solutions
that at least address the two main scenarios identified
above. at the same time, yes lets collect the requirements
from the industry and see if the solution we are
standardizing does meet those requirements. hopefully the
requirements gathering phase does not become a rat-hole.

Vijay

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 29 Sep 2006 10:46:54 +0800

> (global HAHA is separate).

I sort of agree with Vijay here, clearly the gathering of requirements
is a step towards standardizing a solution.  I would prefer 3 instead of
4, which is why I ordered them that way ;)

> requirements gathering phase does not become a rat-hole.

If indeed the various recent promises of drafts from different
industries are true, then it may not be a rat-hole.  

If we are going to have requirements in the charter, I would further
suggest that we have a strict deadline for this work item to complete
(and this time, adhere to it for a change).  I don't see why this
couldn't be finished before Mar 2007, if the WG and the chairs put in
adequate effort.  

If one think along this line, then what Vijay suggest on adding both
requirements and RO solutions to the charter now make sense.  Are we
going to go through this rechartering business again in Mar 2007?  Might
as well add RO solutions to the charter right now.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 29 Sep 2006 10:23:35 +0200

El 28/09/2006, a las 19:37, Vijay Devarapalli escribió:

>> yes, this seems indeed a reasonable scenario, but what is the ISP  
>> after in this setup? again, RO and HA reliability come to my mind...  
> not have all home agents in one room,

exactly, and why do you want that for? usually, people ask for this in  
order to achieve reliability or RO and other benefit you would obtain  
from this setup?

Regards, marcelo

>  but still provide
>>>> so, probably it makes sense to do all the work on reliability in  
>>>> the same wg...
>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 29 Sep 2006 10:32:53 +0200

El 28/09/2006, a las 19:46, Vijay Devarapalli escribió:

> for the nodes in the mobile network

you mean RO between a MNN and an external node?

I agree this is a problem and it is well defined.
The problem that i find here, if we don't provide additional  
requirements, it will be extremely hard to select among the over a  
dozen proposed solutions for this. that is why i think that defining  
the use cases before is needed. Use cases impose requirmeents that  
allow us to select among the different solution with a somehow  
objective criteria
how do you choose between a solution that makes RO based in the  
infrastructure and an end to end RO solution? does the MR needs to do  
alll the work or is it ok to allow the MNN to be involved? Each of  
these different approaches provide benefits and drawbacks, and these  
are more or less critical depending in the application scenario that  
you have in mind. My concern is that if we just state in the cahrter  
that we will standarize a solution to provide RO between the MNN and  
the nodes on the internet, we won't have reasonable objective criteria  
to select one of the dozens proposed approaches ( and i guess we don't  
want to stadnarize them all)

Does any agree that this may be a problem or do you have any mechanisms  
to select among the proposed cirteria other than cherry picking?

> 2. route optimization

this otoh, seems to me a more defined problem and maybe it is easier to  
tackle, so we could go directly to it...

> standardizing does meet those requirements.

what if they don't?

>  hopefully the

yes i am afraid of that too

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 29 Sep 2006 10:40:00 +0200

> as well add RO solutions to the charter right now.

again agree with Chan-Wah here.

i don't have a problem with including both the use cases/requirements 
definitions and the solutions in the charter

regards, marcelo

---

From: Masafumi Watari <[email-masked]>
Date: Fri, 29 Sep 2006 20:16:13 +0900

On Fri, 29 Sep 2006 10:32:53 +0200
marcelo bagnulo braun <[email-masked]> wrote:

> 
> El 28/09/2006, a las 19:46, Vijay Devarapalli escribi〓
> 

If we consider the solution as more like an enhancement to NEMO BS, then
we would probably want to leave those MNNs untouched - RO would be to
bypass those HAs and make it MR to MR (Vehicle to vehicle, plane to
plane).

Now, if we start thinking about nesting of mobility protocols, obviously
there would be a lot more thinking to do.  My personal opinion however
is that we should work on the nested case after we understand its needs.

Having said that, I tend to agree with Vijay.

> tackle, so we could go directly to it...

I'm not sure about that -  to me this involves a lot more complexity.
But I do agree that these two are the cases we should look into.

watari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 29 Sep 2006 15:31:16 +0200

> bypass those HAs and make it MR to MR (Vehicle to vehicle, plane to

two comments:
- first, i agree that MR to MR (or MNN and MNN of different nemos) RO 
makes sense, but don't you think that RO between MNN and a fixed node 
in the internet is also required? and what about MNN and a mobile Node 
RO, does is this required?
-second, of course not having to modify the MNN is useful, specially in 
terms of deployment. But these type of solutions have their own 
drawbacks also (no solution has all the pros, i guess) so deciding that 
we will keep the MNN unmodified fits some unstated requirements and 
probably fits some unstated requirements. Again, this may be exactly 
what we are looking for, but it is extremely hard imho to be able to 
evaluate the different solutions and the different tradeoffs until the 
exact requirements for the use case that we have in mind have been 
written down. For instance, a solution that does requires modification 
to the MNN but provides RO between the MNN and the fixed nodes of the 
internet, without requiring modifications to the fixed nodes (which are 
of course much more than the MNN) is better or worse than the a 
solution that does not requires modification of the MNN but does not 
provides RO with the fixed nodes? again it depends on the use cases 
that you have in mind and the requirements of these use cases, i 
guess... or do you have any other criteria to select among different 
approaches?

> is that we should work on the nested case after we understand its 

i am fine with this too
i have thought less in this case than in the previous one, so i am 
probably underestiamting its difficulty. I am perfectly okey to work in 
requirements and use cases or whatever it takes to understand this case 
in more depth and include this work in the charter

Regards, marcelo