Subject: Re: [nemo] Usage Requirement - Personal Mobile Router

From: Thomas Narten <[email-masked]>
Date: Sun, 03 Dec 2006 08:43:16 -0500

> there is a market for personal mobile routers. there
> are IPv4 products already available. problem is about
> route optimization for these PMRs.

The above does not a problem statement make.

Is there a draft describing (in a few pages) what exactly the problem
is? With enough specificity that one can imagine what a solution might
look like, so one can decide whether a formal WG is needed, what kind
of engineering work needs to be done, and indeed, whether a solution
would actually be deployable in practice, have support of key
stakeholders, etc.?

I don't see the need for this topic to be added to the charter at this
time. That does not mean the problem area isn't interesting or that no
work is needed. It simply needs that (IMO) more ground work needs to
be done first to make it clear what the actual work would be. At that
point we can figure out how best to do the work (e.g., formally
chartering it somewhere).

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Sun, 03 Dec 2006 07:55:24 -0800

I think the personal mobile router is a great idea
and I hope that we will see products and work
around that.

However, I also have doubts about adding more
work items to the charter. This is not to say that
we can never do this, but my original idea about
the rechartering was that we move from what
could theoretically be done in RO space to a
very constrained set of goals, driven by
specific business needs. Also, I do not think this
working group has the bandwidth to handle
too many topics at the same time. We can
talk about what those topics should be, but
I am very concerned about trying to do too
many things, or adding open-ended work
items.

In any case, I have a few practical observations.
First, I have been ready to take the NEMO charter
to the IESG already for some weeks, but we need
to resolve this issue first. Lets not waste too
much time on this.

Second, it may be that there is commonality
between solutions needed in the automobile
and PMR spaces.

Third, there is a lot of value in doing some
things sequentially. Once we have shown
that we can complete work for one topic
in a timely manner it is much easier to take
on additional topics. Or, as the new charter
indicates, if there is not sufficient energy
to create the working group documents
before a given deadline, the topic in question
is dropped and could be replaced by another
one.

So here's a strawman suggestion on how
to proceed: (1) Charter the working group with
the original two topics now. (2) In parallel
with the WG efforts, Vijay and others who have
an interest in the PMR space work further
with their ideas and requirements, possibly
also gather input from people who are
implementing the PMR without RO. (3)
In April-May 2007, one of several things
has happened. Perhaps we see at that
point that the automotive industry needs
actually point to solutions that satisfy
also the PMR needs. Perhaps we see
that one of the topics has not gotten
enough attention, and so we terminate
that work and recharter to include PMR
in its place. Perhaps both topics have
progressed far enough that there is
evidence that the WG can complete the
requirements phase, at which time we
could recharter to add a third topic.

Thoughts?

--Jari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 04 Dec 2006 09:55:46 +0100

Hi Jari,

	Your proposed approach makes sense to me.

	Regards,

	Carlos J.

-- 
¡ASÓCIATE! Gratis para estudiantes  http://www.telematica.ws
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 5 Dec 2006 00:38:54 +0900

Hi

PMR is interesting usage, but the problems are also not clear to me.
I think your approach is fair enough.

ryuji

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 12 Dec 2006 18:12:15 -0800

> could recharter to add a third topic.
Is there anyone who is *not* in agreement with Jari's suggestion on how 
to move forward with the charter?

TJ

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 12 Dec 2006 19:18:47 -0800

I paid attention to this thread a bit too late, nevertheless, here are
some thoughts. 

The one thing that is not yet totally clear to me is whether we will end
up needing different RO solutions for each specific set of requirements
we collect. That actually seems quite undesirable to me from an end user
perspective. Of course, if the critical requirements in each category
are so vastly different and we have a situation where we simply don't
have a subset of agreeable requirements, it may just be that we need
different solutions. But, until we are done with the requirements phase,
it is not feasible to answer that question. 

In terms of the charter, I would much prefer to see requirements
collected from all use cases of industry interest as of now and
determine the solution direction as the next step. I think that PMR is
an important use case for the industry - on RO for PMR, I'm not so sure
- which is why it'd be worthwhile to go through the step of collecting
requirements. 

As of now, the charter pre-supposes that we will have separate solution
drafts for the aviation and automotive industries. I suggest that we
hold off on that and instead have this charter revision only collect and
consolidate requirements and try to identify if there is an acceptable
subset that can lead to a unified solution. A subsequent charter
revision can add the relevant solution milestones that will be more
accurate based on the requirements. 

My 2 cents,
Vidya   

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]] 
> Sent: Tuesday, December 12, 2006 6:12 PM
> To: Jari Arkko
> Cc: 'ml-nemo WG'
> Subject: Re: [nemo] Usage Requirement - Personal Mobile Router
> 
> Jari Arkko wrote:
> > So here's a strawman suggestion on how to proceed: (1) Charter the 
> > working group with the original two topics now. (2) In 
> parallel with 
> > the WG efforts, Vijay and others who have an interest in 
> the PMR space 
> > work further with their ideas and requirements, possibly 
> also gather 
> > input from people who are implementing the PMR without RO. (3) In 
> > April-May 2007, one of several things has happened. Perhaps 
> we see at 
> > that point that the automotive industry needs actually point to 
> > solutions that satisfy also the PMR needs. Perhaps we see 
> that one of 
> > the topics has not gotten enough attention, and so we 
> terminate that 
> > work and recharter to include PMR in its place. Perhaps both topics 
> > have progressed far enough that there is evidence that the WG can 
> > complete the requirements phase, at which time we could 
> recharter to 
> > add a third topic.
> Is there anyone who is *not* in agreement with Jari's 
> suggestion on how to move forward with the charter?
> 
> TJ
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Dec 2006 12:32:42 +0200

Vidya,
> perspective. ...
I think there is some likelihood that the needs are
indeed different enough that we cannot have just
one solution. Also, I do worry about attempting to
design a generic solution for a problem that is very,
very hard in the general case.

But your point is still taken. There needs to be
a step between the requirements and the
individual solutions. We should have an opportunity
to discuss if the different needs can be covered
by one mechanism. Perhaps some words could
be added to the charter to this effect.

--Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 09:35:18 -0800

Hi Jari, 

> >   
> I think there is some likelihood that the needs are indeed 
> different enough that we cannot have just one solution. Also, 
> I do worry about attempting to design a generic solution for 
> a problem that is very, very hard in the general case.
> 

I do agree with your point. But, if we have all the requirements in
front of us, we can see if two solutions, if not one, satisfy the
identified sets of requirements. I just think that assuming a 1:1
relationship between number of categories and number of solutions would
be undesirable. 

> But your point is still taken. There needs to be a step 
> between the requirements and the individual solutions. We 
> should have an opportunity to discuss if the different needs 
> can be covered by one mechanism. Perhaps some words could be 
> added to the charter to this effect.
> 

To this effect, are we adding the PMR needs as a category to collect
requirements from? 

Vidya

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Dec 2006 19:54:18 +0200

Vidya,
> To this effect, are we adding the PMR needs as a category to collect
I would rather start from a small set of
areas to collect requirements from, and
then add more later as we have progressed
with the first ones. I know this isn't optimized
from the point of view of getting one solution
that covers many needs. However, I think we
need focus on concrete cases with tangible
benefits to deployment more than we need
a universal solution in this case.

--Jari

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 13 Dec 2006 22:42:38 +0100

Hi,

But then, I would start with the PMR use case, not the automotive use
case. People from the automotive industry are not yet involved within
the IETF, hopefully they would soon (I got good signs and feedback from
related industries), but they don't have the IETF insight. For the PMR
use case, many people on the list used to IETF process have said they
are willing to collect the requirements. I'm sure they will in a very
efficient way. In addition, (some people from) the automotive industry
(e.g. ISO TC204 WG 16's CALM protocol architecture, or the Car-to-Car
Communication Consortium) right now is more trying to figure out where
exactly IPv6 would fit in (not as opposed with IPv4: there is a clear
indication from them that IPv4 is no-go). Their list of requirements
would rather embrace the entire set of IPv6 protocols instead of being
NEMO-specific. There would obviously be some MANET and NEMO there
(MANEMO), but not only. 

The aviation industry case is another story. We already have commitment
from NASA and Boeing, but I don't see in the short term this use case
involving more people that we presently have. And this would take years
to be deployed, whereas the PMR use case could be quite quickly.

So, leaving PMR out is like cutting our own feets. If this is a strategy
to make sure the work as specified in the charter is not done,
dismissing PMR is surely the right thing to do.

Thierry.

On Wed, 13 Dec 2006 19:54:18 +0200

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 13 Dec 2006 18:47:27 -0800

I agree with Thierry here.  

> From: Thierry Ernst [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 1:43 PM
> To: [email-masked]
> But then, I would start with the PMR use case, not the 
> automotive use case. People from the automotive industry are 
> not yet involved within the IETF, hopefully they would soon 
> (I got good signs and feedback from related industries), but 
> they don't have the IETF insight. For the PMR use case, many 
> people on the list used to IETF process have said they are 
> willing to collect the requirements. I'm sure they will in a 
> very efficient way. In addition, (some people from) the 
> automotive industry (e.g. ISO TC204 WG 16's CALM protocol 
> architecture, or the Car-to-Car Communication Consortium) 
> right now is more trying to figure out where exactly IPv6 
> would fit in (not as opposed with IPv4: there is a clear 
> indication from them that IPv4 is no-go). Their list of 
> requirements would rather embrace the entire set of IPv6 
> protocols instead of being NEMO-specific. There would 
> obviously be some MANET and NEMO there (MANEMO), but not only. 
> 
> The aviation industry case is another story. We already have 
> commitment from NASA and Boeing, but I don't see in the short 
> term this use case involving more people that we presently 
> have. And this would take years to be deployed, whereas the 
> PMR use case could be quite quickly.
> 
> So, leaving PMR out is like cutting our own feets. If this is 
> a strategy to make sure the work as specified in the charter 
> is not done, dismissing PMR is surely the right thing to do.
> 
> Thierry.
> 
> 
> 
> 
> >I would rather start from a small set of areas to collect 
> requirements 
> >from, and then add more later as we have progressed with the first 
> >ones. I know this isn't optimized from the point of view of 
> getting one 
> >solution that covers many needs. However, I think we need focus on 
> >concrete cases with tangible benefits to deployment more 
> than we need a 
> >universal solution in this case.
> >
> >--Jari
> >
> >
> 
>

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 13 Dec 2006 23:01:49 -0800

Well LCD should always be factored. But the deployment of these  
solutions is quite different. Routing issues and spheres of  
capability are quite different as well.

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 13 Dec 2006 23:05:14 -0800

On Dec 13, 2006, at 9:35 AM, Narayanan, Vidya wrote:

> identified sets of requirements.

Let's make an analogy.

An ISP with a /16 IPv4 prefix and my home DSL router with a /28  
prefix both have address blocks that need to be managed. I want to  
set up routing for my 8 IP addresses, delegate reverse DNS entries,  
and control routing and NAT (gasp). But my solution might be  
different from the ISP advertising their address space.

Same goes for an airplane flying around with a large prefix, an auto  
with a couple servers onboard, or my cell phone sitting in my back  
pocket and communicating with a few MNNs. Same paradigm, different  
deployment problems.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 13 Dec 2006 23:05:14 -0800

Let's make an analogy.