Subject: Re: [Roll] Review and concerns

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2009 18:32:06 +0100

Philip Levis a écrit :
> 
> On Dec 15, 2008, at 3:23 AM, Emmanuel Baccelli wrote:
> 
>> 
>> 
>> On Thu, Dec 11, 2008 at 9:52 PM, David E. Culler 
>> <[email-masked]> wrote: Emmanuel, We discussed the list 
>> of rows in each of the IETF meetings and associated discussions 
>> leading up to those.   It sounds like you agree that if you have 
>> some criteria for limiting the search space the discussion will 
>> never complete.   That is necessary, according to the charter, to 
>> consider the space of solutions that might actually solve the 
>> problem.  To do any analysis there has to be something specific to 
>> analyze.  You mention two addition WGs that have done relevant 
>> work. Indeed, from the very beginning it was stated that Roll 
>> should work in conjunction with those groups.  It is key another 
>> thing to say "this specific protocol as described by this RFC or 
>> I-D ought to be analyzed in draft-ietf-roll-protocols-survey-03".
>> 
>> Here's the NEMO list.  Which are you arguing should be included and
>>  why?
>> 
>> 
>> Sorry to be blunt, but your charter says that DTN and NEMO are to 
>> be reviewed as well as the rest. There is not a word about either 
>> of these "fields" in the draft, why? You need to answer this 
>> question. Not me.
> 
> I thought the draft is very explicit:
> 
> This document considers "existing routing protocols" to be protocols
>  that are specified in RFCs or, in the cases of DYMO 
> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very 
> mature draft which will most likely become an RFC.  This document 
> does not seek to answer the question of whether there is any protocol
>  anywhere which could meet LLN application requirements.  Rather, it
>  seeks to answer whether protocols, as specified in current IETF 
> standards documents, can meet such requirements.
> 
> In the case of DTN, it's IRTF.
> 
> In the case of NEMO, it is not a routing protocol.

Sorry, late, browsing the ROLL discussions.

NEMO not a routing protocol?  What's a routing protocol anyways.  NEMOv6
  extension to Mobile IPv6 may affect the routing tables, or affects the
binding cache with prefixes, which is a routing-related data structure.

Home Agent 'forwards' packets according to rules in its binding cache...

A question that may be raised is whether a NEMO-like structure (a set
of nodes moving together, 'represented' by its mobile router moving with
them) may get formed in the LLN deployments and at the same time that
LLN must be connected to the Internet.  If both conditions are met then
NEMO concepts and NEMOv6 protocol may be needed for LLN.

Alex

> 
> When the charter was written, the initial thought was that reviewing 
> those protocols seemed like a good idea. We did. But after further 
> examination and discussion, both on the mailing list at at IETF 
> meetings, the WG reached consensus that the current methodology for 
> the *routing protocol survey* is the right one. Because neither is a 
> standards-track routing protocol, their mechanisms do not help answer
> the question of whether ROLL needs to recharter for protocol design.
> Rather, they might be part of the next step, which is to examine
> existing mechanisms and protocols to see how protocol design should
> go forward.
> 
> Phil _______________________________________________ Roll mailing 
> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
> 

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2009 18:35:50 +0100

David E. Culler a écrit :

>  Here's the NEMO list.  Which are you arguing should be included and why?

RFC3963 NEMOv6 base spec should be included because:

-it and not RFC5177 NEMOv4 because ROLL does IPv6 only
-if there is a chance that a LLN network may contain groups of entities
  moving together (a moving network) and at the same time LLN is
  connected to the Internet then Mobile IPv6 with its NEMOv6 extensions
  may look attractive.
-if the latter condition is not satisfied it still makes sense to talk
  about moving network concepts, in the sense that one entity may be in
  charge of all entities in the moving network, without necessarily using
  Mobile IPv6 protocol nor NEMOv6.

Alex

> draft-ietf-nemo-basic-support 
> <http://tools.ietf.org/wg/nemo/draft-ietf-nemo-basic-support/> 	-03 
> <http://tools.ietf.org/html/draft-ietf-nemo-basic-support> 	
> 	2004-06-07   	RFC 3963 <http://tools.ietf.org/html/rfc3963> 	
> draft-ietf-nemo-home-network-models 
> <http://tools.ietf.org/wg/nemo/draft-ietf-nemo-home-network-models/> 
> -06 <http://tools.ietf.org/html/draft-ietf-nemo-home-network-models> 	
> 	2006-02-21   	RFC 4887 <http://tools.ietf.org/html/rfc4887> 	
> draft-ietf-nemo-multihoming-issues 
> <http://tools.ietf.org/wg/nemo/draft-ietf-nemo-multihoming-issues/> 	-07 
> <http://tools.ietf.org/html/draft-ietf-nemo-multihoming-issues> 	
> 	2007-02-07   	RFC 4980 <http://tools.ietf.org/html/rfc4980> 	
> draft-ietf-nemo-requirements 
> <http://tools.ietf.org/wg/nemo/draft-ietf-nemo-requirements/> 	-06 
> <http://tools.ietf.org/html/draft-ietf-nemo-requirements> 	
> 	2006-11-09   	RFC 4886 <http://tools.ietf.org/html/rfc4886> 	
> draft-ietf-nemo-ro-problem-statement 
> <http://tools.ietf.org/wg/nemo/draft-ietf-nemo-ro-problem-statement/> 
> -03 <http://tools.ietf.org/html/draft-ietf-nemo-ro-problem-statement> 	
> 	2006-09-18   	RFC 4888 <http://tools.ietf.org/html/rfc4888> 	
> draft-ietf-nemo-ro-space-analysis 
> <http://tools.ietf.org/wg/nemo/draft-ietf-nemo-ro-space-analysis/> 	-03 
> <http://tools.ietf.org/html/draft-ietf-nemo-ro-space-analysis> 	
> 	2006-09-18   	RFC 4889 <http://tools.ietf.org/html/rfc4889> 	
> draft-ietf-nemo-terminology 
> <http://tools.ietf.org/wg/nemo/draft-ietf-nemo-terminology/> 	-06 
> <http://tools.ietf.org/html/draft-ietf-nemo-terminology> 	
> 	2006-11-09   	RFC 4885 <http://tools.ietf.org/html/rfc4885> 	
> 
> 
> There are many topics that as a working group we'd like to move on to 
> once this process completes.  Much important work has been done outside 
> IETF WGs.  Some of it in the IRTF.  Others in other places.  All the 
> more reason to complete this well formed, bounded effort.   Again, I do 
> not hear any suggestion that any protocol within the domain of analysis 
> meets the criteria.  I do hear that there are protocols or modifications 
> to protocols that do or could.  We need to complete the process on this 
> draft so that we can move on to consider such enhancements, candidates, 
> or new designs. 
> 
> 
> On Thu, Dec 11, 2008 at 4:09 PM, Emmanuel Baccelli <emmanuel.baccelli at 
> gmail.com <mailto:emmanuel.baccelli%20at%20gmail.com>> wrote:
> 
> 
> 
>     On Tue, Dec 9, 2008 at 11:28 PM, David E. Culler <culler at
>     eecs.berkeley.edu <mailto:culler%20at%20eecs.berkeley.edu>> wrote:
> 
> 
>         Some concerns recognize that there are protocols outside the
>         defined universe that should be considered and that appear to be
>         far better suited to meeting the criteria than the set of IETF
>         protocols that were considered - since those protocols were
>         developed without these criteria.  Again, that suggests that the
>         criteria are a reasonable guide, that they do not appear to be
>         unobtainable, and that the analysis has provided a suitable guide.
> 
>         None of the comments seem to be claiming that there is a
>         solution within the universe that we were chartered to consider
>         that meets the criteria.
> 
> 
>  
> Even admitting that the universe you defined is wide enough (a point 
> which is actually agued since months), we could conclude to this only if 
> this universe (defined in the charter) is covered entirely. Again, it is 
> not the case: I have seen nothing said about NEMO or DTN, so reports of 
> investigations in these fields need to be included in the draft anyways.
> 
> Second, if we are not going into a long research phase, I am still 
> wondering what existing protocols/algorithms, IP compatible or not, are 
> being "hinted at" here, which could meet the "dream" criterii that are 
> evoked in the draft. Chris Dearlove and other people have asked this 
> question many times, and it is yet to be answered.
> 
> Emmanuel
> 
> 
> ------------------------------------------------------------------------
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 16 Jan 2009 10:01:03 -0800

> Mobile IPv6 protocol nor NEMOv6.

The question is not whether NEMO or some variant thereof might be  
relevant in an LLN. The question, with respect to this draft, is  
whether ROLL could adopt NEMO unchanged as the routing protocol for  
LLNs. "If there is a chance" and "may look attractive" mean that NEMO  
might be relevant to the next step of discussion, but are not relevant  
now. Do you agree? Please read the full document.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2009 19:21:42 +0100

Philip Levis a écrit :
>> -it and not RFC5177 NEMOv4 because ROLL does IPv6 only -if there is
>> a chance that a LLN network may contain groups of entities moving
>> together (a moving network) and at the same time LLN is connected
>> to the Internet then Mobile IPv6 with its NEMOv6 extensions may
>> look attractive. -if the latter condition is not satisfied it still
>> makes sense to talk about moving network concepts, in the sense
>> that one entity may be in charge of all entities in the moving
>> network, without necessarily using Mobile IPv6 protocol nor NEMOv6.
>> 
> 
> LLNs.

Why there's no NEMOv6 protocol in the '(in)famous' table?

> "If there is a chance" and "may look attractive" mean that NEMO might
> be relevant to the next step of discussion, but are not relevant now.
> Do you agree? Please read the full document.

I'm looking at it... thanks for the comments.

My comments are for the archives.

I understand there's a hard deadline happening as we speak: no 
opposition from my side.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 17 Jan 2009 03:46:33 +0100

On Jan 16, 2009, at 18:32 PM, Alexandru Petrescu wrote:

>>> problem.  To do any analysis there has to be something specific  
>>> to analyze.  You mention two addition WGs that have done relevant  
>>  that are specified in RFCs or, in the cases of DYMO [I-D.ietf- 
>> manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very mature  
>> draft which will most likely become an RFC.  This document does  
>> not seek to answer the question of whether there is any protocol
> NEMO not a routing protocol?  What's a routing protocol anyways.

Alex, you ask a good question. You could also ask "what is a router  
anyways". As I see it, you'll get at least three different answers  
depending on whom you'll ask, for example for a router, you could get:

	o	something running the router portion of NDP
	o	something forwarding traffic not destined to itself
	o	something running a routing protocol

(I think that a major source of confusion in also the "MANEMO"  
discussions are found in different people picking different of the  
above as the "right" definition of a "router" and making assumptions  
based on this)

However, while it's interesting to try to understand what different  
communities intend, I'm not sure that this is conductive to the work  
of this wg.

> NEMOv6

A common "academic" position would be something akin to "routing  
protocol is a path finding algorithm, plus the information exchange  
necessary for that algorithm to operate". An equally valid position  
could be "something which affects routing tables". I'm sure that one  
can come up with others....

But, while the discussion is interesting, I'm not sure that ROLL is  
chartered to enumerate and document these positions?

Thomas

>> When the charter was written, the initial thought was that  
>> reviewing those protocols seemed like a good idea. We did. But  
>> after further examination and discussion, both on the mailing list  
>> at at IETF meetings, the WG reached consensus that the current  
>> methodology for the *routing protocol survey* is the right one.  
>> Because neither is a standards-track routing protocol, their  
>> mechanisms do not help answer

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 17 Jan 2009 06:40:20 +0100

On Jan 16, 2009, at 19:01 PM, Philip Levis wrote:

> LLNs. "If there is a chance" and "may look attractive" mean that  
> NEMO might be relevant to the next step of discussion, but are not  
> relevant now. Do you agree? Please read the full document.

Phil,

(side-note, I've read the updated I-D and will send detailed comments  
later, hopefully this weekend. On the whole, I think this last edit  
is a good improvement, so kudos).

I'm torn as to if I agree with you or Alex here, as you both have a  
point. In this kind of I-Ds, what we don't write is often more  
dangerous than what we do write. *IF* the WG feels that a variation  
of NEMO might make a candidate for solution-space work, *THEN* I fear  
that disregarding it in this I-D may guide subsequent work away from  
NEMO.

The "offending" paragrap would, I suspect, be thisone:

    We do not examine the Network Mobility Basic Support Protocol (NEMO
    RFC 3963 [RFC3963]) because it is not a routing protocol.  We do not
    examine hierarchical NEMO [I-D.thubert-tree-discovery] as a  
candidate
    because it only maintains a default route and so is insufficient for
    general routing.  Although NEMO itself is not a suitable routing
    solution to LLNs, some of its mechanisms, such as loop-free tree
    formation, might be useful in an LLN routing protocol.

If the WG considers investigating NEMO, then a softening of this  
paragraph may be in order?

Note: I do not have a personal opinion on the applicability of NEMO  
in this matter, I'm just observing that the above paragraph seems to  
exclude NEMO-variations for future work (despite the last sentence).

Cheers,

Thomas