Subject: Re: [nemo] Re: RO for geographically dist'd HAs

From: Masafumi Watari <[email-masked]>
Date: Mon, 02 Oct 2006 18:39:30 +0900

Hi Marcelo,

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

> > 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).
> >
> 
> 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?

I would agree if RO is provided between MR and a CR of the CN, and not
MR and CN - unless CN is a MIP6 CN.  Global HAHA might be a candidate
solution for this I guess.

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

I see what you are trying to say and I think we documented such
tradeoffs in the RO analysis draft while going through the various
proposals.  My point was that one policy we could follow is to leave
those MNNs unmodified and work on those first.  I also believe that such
requirement is quite reasonable after seeing a few NEMO like services.
A side note, that was one reason why Netlmm was chartered too, right?

As I mentioned above, providing RO for fixed nodes is still possible by
deploying CRs over the Internet.

watari

> > 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.
> >
> 
> 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
> 
> 
> > Having said that, I tend to agree with Vijay.
> >
> >>> 2. route optimization
> >>> for traffic between the two MNNs in the same mobile network.
> >>> (global HAHA is separate).
> >>
> >> this otoh, seems to me a more defined problem and maybe it is easier 
> >> to
> >> 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
> >
> >>>
> >>> 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.
> >>
> >> what if they don't?
> >>
> >>>  hopefully the
> >>> requirements gathering phase does not become a rat-hole.
> >>>
> >>
> >> yes i am afraid of that too
> >>
> >> regards, marcelo
> >>
> >>
> >>> Vijay
> >>>
> >>
> >
> >
> >
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 2 Oct 2006 15:23:14 +0200

El 02/10/2006, a las 11:39, Masafumi Watari escribió:
> proposals.

yes, the question is which tradeoffs are the ones we choose

>  My point was that one policy we could follow is to leave
> those MNNs unmodified and work on those first.

yes, this is one possible approach, but why should we choose this  
approach and not another one?

My point is that when deciding this we are making some assumption about  
the use cases. I would like to make this decision explicitly.

>   I also believe that such

could you provide some examples?
I mean, imho use cases (i.e. nemo like services used or to be used)  
should be the main driver of which solutions we should standarize,

> deploying CRs over the Internet.

i guess it is possible in several ways, but the first thing we need to  
decide si what do we want to do this for...

In other words, i am not worried about which approach we decide to  
adopt but rather the criteria that we used for selecting it among the  
multiple proposed solutions

Regards, marcelo

---

From: Masafumi Watari <[email-masked]>
Date: Tue, 03 Oct 2006 11:11:32 +0900

On Mon, 2 Oct 2006 15:23:14 +0200
marcelo bagnulo braun <[email-masked]> wrote:

> 
> El 02/10/2006, a las 11:39, Masafumi Watari escribi

As I said, by considering the solution as an enhancement to NEMO BS. 
BTW, I'm not saying that we should work only on this and not others.

> should be the main driver of which solutions we should standarize,

Well, Connexion by Boeing for example.  There is also a commercial
service that already provide Internet connectivity to passengers inside
trains running in Japan - the only thing they request is a laptop with a
WIFI device.  Others, some ITS organizations have expressed that the
nodes inside vehicles be kept untouched - in other words, we should not
expect them to be mobility aware.  This is again, why NEMO BS had such
requirement.

> multiple proposed solutions

But selecting an approach/scenario does limit the solutions.  Having a
full set of criteria/requirements beforehand is what the WG has been
trying to gather, but seems hard afterwards.

watari