Subject: [nemo] On NEMO Re-Chartering w.r.t. RO -- summary so far

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 12 Oct 2006 19:07:20 +0800

Hello all,

Seems like all discussions on RO-related re-chartering of NEMO WG has
subsided, so perhaps it is time for a test of consensus?

Based on my understanding of the posts within the ML, the consensus
seems to be:

   - A work item needs to be added to the charter to document 
     industry requirements and use cases

A somewhat "rougher" consensus seems to be:

   - A work item explicitly identifying the Global HA HA protocol
     should not be in the charter

   - Instead, route optimization solutions should be added.

Now, what kind of route optimization solutions should be added does not
seems to be too clear based on my reading of the ML.  TJ's draft charter
already contains 2 items:

    - Communication between nodes located in separate mobile networks,

    - and communication between a mobile network node and a visited
      network node / service should be addressed.

And Thierry, Watari independently suggested that:

    - MR to MR communication not going through a MR-HA tunnel 

I myself have proposed to look at, instead of Global-HAHA, 

   - An infrastructure-based RO solution

There have also been call for adding route optimization solutions based
on the requirements from the requirements draft, but to avoid a
rechartering in Mar2007 again, this should be explicitly placed in the
WG charter.  So far, I don't see any objections to this.  The only
contention point is what type of route optimizations.

That's pretty much what I can summarize from I can read in recent ML
activities.

On a related note, I would also like to point the WG to some discussions
on the same ML 1 year ago, in which I suggested possible next steps to
route optimizations (I'd even prepared some slides for that in 64th
IETF, but was dropped due to time constraint).  See attached post below.

/rgds
/cwng

-------- Forwarded Message --------
From: Chan-Wah NG <[email-masked]>
To: T.J. Kniveton <[email-masked]>
Cc: ml-nemo WG <[email-masked]>
Subject: Re: [nemo] Next steps in RO
Date: Thu, 03 Nov 2005 14:36:43 +0800

Hello all,

My personal views are that the following 3 main pieces are needed:

(1) A mechanism for MNNs to send packet from where the NEMO is attached.

This mechanism would allow MNNs, however deeply they are nested, to
appear to a node outside the NEMO as if they are a simple mobile node.
attached to the point of attachment of the root-MR.  This mechanism
would allow a solution to the nested mobile HA problem, and the security
policy prohibiting visitor traffic problem.  Not only that, it also
allows VMN to operate MIPv6 RO without being subjected to NEMO-BS
tunnel.

(2) A mechanism for MRs to offer route optimization to LFNs.

This is less important, but it's a mean to complete the entire RO
process.  The mechanism above in (1) will allowed modified nodes (i.e. VMN) to
achieve RO in a way compatible to the more "legacy" MIPv6 RO.  This
mechanism, OTOH, will allow RO to be achieved for unmodified LFNs.

(3) A correspondent router solution.

The deployment of such an entity would allow two benefits: (1) perform
RO for non-modified CNs, and (2) the discovery of MR by other mobile
nodes, if this MR is treated as a CR.

Some of the above may require future research, and may encompass a lot
of smaller but significant issues to be solved.  One can in fact have
the NEMO WG re-chartered to work on only 1 or 2 of the above, and have
the rest moved to IRTF for further research.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Oct 2006 15:49:06 +0200

Hi Chan-Wah,

>    - An infrastructure-based RO solution

A couple of comments:

first, i guess that it is obvious, but i guess we don't need different 
solutions for each case, and that if we find a single solution that 
supports more than one of these cases, it would be a plus, right?

Second, i found it a bit strange the set of solutions that you have 
selected... i mean, the first two suggested by TJ seem to describe 
situations where RO is desirable.

However, the second one seems somehow related to the the first one 
proposed by TJ, i mean what is the difference between RO between MNN 
located in different nemos and RO between two MRs?

The third one seem to be addressing the general problem of RO between a 
MNN and any other CN located in the internet. However, instead of 
stating that a general solution for RO between a MNN and any other CN 
is to be designed, you already impose a condition on the solution, that 
is, that it must be based on the infrastrucutre. I don't wee why this 
should be the case... I mean, i see several benefits of using an 
infrastrucutre approach, but other solutions not based on the 
infrastrucutre may also provide other tradeoffs and other benefits. On 
other words, why do you rule out solutions not based on infrastrucutre 
from the list?

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 13 Oct 2006 00:28:35 +0200

Hi,

> supports more than one of these cases, it would be a plus, right?

It could be a plus if this is feasible; if it's not, independent
solutions could be devised when the need is strong and as long as the
different solutions, each addressing a different part of the problem,
are interoperable.

But, instead of speaking about different solutions, from a charter point
of view we should speak about the different scenarios where a solution
is urgently expected.

> MNN and any other CN located in the internet. 

No, this is not correct. When I proposed this I really meant a CN clause
to the AR visited by the MR.

> However, instead of 

What do you mean by solutions not based on the infrastructure ?

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Oct 2006 14:13:12 +0200

> different solutions, each addressing a different part of the problem,

fully agree

> of view we should speak about the different scenarios where a solution

fully agree also

> to the AR visited by the MR.

my mistake, i meant the one about infrastrucutre based RO , sorry for 
hte confusion...

> What do you mean by solutions not based on the infrastructure ?

all the other solutions that are not in the category of "an 
infrastrucutre based RO"

for example, end to end RO for instance.... e.g. based on mip RO

in any case, i agree with you that we should include in the charter the 
scenarios where RO is needed rather than how the solutions should be 
designed, infrastrucutre, end to end and so. I would leave this out of 
the charter

Regards, marcelo

---

From: "Ivancic, William D. \(GRC-RCN0\)" <[email-masked]>
Date: Fri, 13 Oct 2006 12:13:25 -0500

I would really like to see Global HAHA worked as I think it provides a
solution for the aeronautics community.  However, I am most certainly
open to other solutions.  I believe, however, that Global HAHA is well
bounded and therefore has a chance to be accomplish in a reasonable
amount of time.

Whatever solutions are proposed, we need to ensure deployment is
realizable in many environments and scenarios and that it can be
secured in a practical manner.

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

> -----Original Message-----
> From: Chan-Wah Ng [mailto:[email-masked]] 
> Sent: Thursday, October 12, 2006 7:07 AM
> To: IETF NEMO WG
> Subject: [nemo] On NEMO Re-Chartering w.r.t. RO -- summary so far
> 
> Hello all,
> 
> Seems like all discussions on RO-related re-chartering of 
> NEMO WG has subsided, so perhaps it is time for a test of consensus?
> 
> Based on my understanding of the posts within the ML, the 
> consensus seems to be:
>

---

From: Chan-Wah NG <[email-masked]>
Date: Mon, 16 Oct 2006 10:46:53 +0800

Hello Thierry, Marcelo,

While I agree that we should get requirements, then see where solutions
is needed (urgently), I maintain that the charter should include a
solution clause, something like "based on the requriements and scenarios
where RO is needed, the WG would produce appropriate RO solution(s).".

The reasons being:

(1) the basic objective behind doing requirements/scenarios is to have
RO.

(2) I don't see that work needing to take too long, and we don't want a
re-chartering again in March.

/rgds
/cwng

-- 
Chan-Wah NG <[email-masked]>
Panasonic Singapore Labs

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 16 Oct 2006 16:07:19 +0200

Well, written this way this makes sense to me.
Thierry

On Mon, 16 Oct 2006 10:46:53 +0800

> > >>> IETF, but was dropped due to time constraint).  See attached post

\

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Oct 2006 22:42:33 +0200

I am perfectly ok with this too

Thanks, marcelo

El 16/10/2006, a las 16:07, Thierry Ernst escribió:

>>>>> The third one seem to be addressing the general problem of RO 
>>>>> between
>>>>> a
>>>>>> on the same ML 1 year ago, in which I suggested possible next 
>>>>>> steps
>>>>>> to

---

From: Masafumi Watari <[email-masked]>
Date: Wed, 25 Oct 2006 13:39:59 +0900

Hi,

Is it possible to have the another revised draft charter before the
meeting or are we going to discuss this at San Diego?

I did send some comments to T.J. on the charter as well and I'm just 
curious to know what the plans are.

thanks,
watari

On Mon, 16 Oct 2006 16:07:19 +0200
Thierry Ernst <[email-masked]> wrote:

> > > El 13/10/2006, a las 0:28, Thierry Ernst escribi
> > > 
> > > >
> > > > Hi,
> > > >
> > > >> A couple of comments:
> > > >>

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 27 Oct 2006 19:21:04 -0700

Hi,

Yes, I plan to have one more revision of the charter proposal before the 
meeting in San Diego.

TJ