Re: [Roll] [roll] Discussion on draft

Hi Phil:

MANEMO was an effort that lead to a number of preBOF that were quite
successful. MANEMO and ROLL had very similar objectives but MANEMO
started in the wrong area (Internet) and with a scope that was not
specific enough (more generic L3 mesh for sensors, cities and disaster
recovery). Most of all, a draft like yours was missing to convince the
A-Ds that there was actual work to do apart from pointing at the usual
suspects from the MANET WG.

Seems to me that ROLL is doing the right thing for all of these matters;
and if you add to the picture the strong requirement drafts that we
already have, I'm very impressed with the WG and its leadership. 

In any case there is no RFC'ed solution for MANEMO that you can refer in
your draft. There were solution drafts that were advanced enough though:

http://tools.ietf.org/html/draft-thubert-tree-discovery-06 . TD is a
simple distance-vecteur to locate a sink and establish a graph to/from
that sink

http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header-07
enables source route along the TD graph till routing states are
established. This enables fast movements and cases when no routing at
all is desired above TD.

http://tools.ietf.org/html/draft-thubert-nina-02 . NINA (AKA bubbles)
sets routing states along the tree; this is all optimized for mesh to
sink. An additional component could be added to improve inner mesh
routing as Kris discusses on this thread. For instance, 802.11s is using
AODV for that purpose.

I hope this helps,

Pascal

>-----Original Message-----
>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Teco Boot
>Sent: vendredi 28 mars 2008 17:01
>To: 'Philip Levis'
>Cc: roll@ietf.org
>Subject: Re: [Roll] [roll] Discussion on draft
>
>Phil,
>
>I swapped subject from manet to roll, for fitting my (and others) mail
>rules.
>On (fixed)ANET, my experience is that obstacles may move. For MESH and
MANET
>protocols, the trigger for recomputing paths is not that important.
>On existing protocols, discussed in IETF, we had MANEMO (MANET for
NEMO). I
>have published NEMO for MANET, which is tailored for Autoconf as it
builds a
>path between MANET Router and Border Router (sink) using NEMO. Before
>Dublin, I will split the proposal and refine the related parts for
Autoconf.
>These drafts do not describe routing anymore. I plan to work on the
MESH
>routing part starting second half this year, depending on the outcome
in
>Autoconf WG.
>
>Maybe add a section on MESH, describing that currently IETF is not
working
>on this? And that a couple of personal drafts are published.
>
>I still wonder why IETF is ignoring MESH, as I think it makes sense to
solve
>the problem at L3. Heterogeneous media are difficult to manage at L2.
>
>Regards, Teco
>
>
>> -----Oorspronkelijk bericht-----
>> Van: Philip Levis [mailto:pal@cs.stanford.edu]
>> Verzonden: vrijdag 28 maart 2008 16:27
>> Aan: Teco Boot
>> CC: roll@ietf.org
>> Onderwerp: Re: [manet] Discussion on draft
>>
>> On Mar 28, 2008, at 12:52 AM, Teco Boot wrote:
>>
>> > Hi Phil,
>> > Maybe this raised before, but I miss a category of "xxx" protocols,
>> > sometimes referred as "mesh" protocols.
>> > "Mesh" is not pure MANET, as MANET routing protocols typically
>> > provide paths
>> > within the MANET. "Mesh" protocols provide paths between nodes and
a
>> > backbone network.
>> > MANET protocols can provide paths to the backbone also. The other
>> > way is not
>> > always true, "mesh" protocols do typically not provide paths
between
>> > nodes
>> > or at least this is the second priority.
>> > Maybe the draft only discuss existing IETF protocols (e.g. RFC
>> > exists or WG
>> > is chartered), but I think the "mesh" type of protocols is worth
>> > mentioning.
>> > Regards, Teco
>>
>> Teco,
>>
>> You're right; currently, the document only addresses existing IETF
>> protocols. Basically, if there isn't a suitable solution already
>> within the IETF corpus, then ROLL may need to add one (to the
corpus).
>> If that's the case, the follow-up question whether such a protocol
>> would be an RFC-based specification of an existing, open protocol.
>> Coming from the academic side, for example, there are plenty of
>> protocols, but few meet the requirements (in terms of functionality,
>> interoperability, etc.) of something that could be presented as an
RFC.
>>
>> I'm not sure I'd agree with your definition of the distinction of
>> "mesh" protocols (I generally consider them to be ANET protocols,
that
>> is, ad-hoc but not necessarily mobile), but I understand the
>> distinction you're making, and
>> that's more important than debating terminology.
>>
>> Which protocols are you thinking of?
>>
>> Phil
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll