Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 **

This sounds good to me.Emmanuel

On Sat, Dec 20, 2008 at 1:50 AM, Stephen Dawson-Haggerty <
stevedh@eecs.berkeley.edu> wrote:

> Hi All,
> We are making good progress at integrating all this discussion into the
> next revision; however, there has been a lot of traffic and I want to make
> sure we hit on everyone's comments.  I've put below a preliminary changelog
> for the document.  These are only the major changes so far; there are others
> which are more typographical and thus not listed.  If you feel that I am
> missing something which we discussed, please let me know either personally
> or to the list.
>
> Thanks,
> Steve
>
>   - OSPF changed to OSPF/IS-IS, explain the distinctions and why the
> analysis is the same
>   - Notes justifying why we don't look at NEMO/DTN (verbatim from JP, Phil)
> since they're in the charter.
>   - Update the "control cost" metric: note that this metric is "necessary
> but not sufficient"
>   - Be a more explicit about reqs and limitations in the intro.
>   - Update DYMO to talk about distance, not hopcount
>   - T. Clausen's long email (most should have been considered & addressed)
>   - OLSRv2 changed to ? in the control cost metric, because it might be
> possible to pass with the right sort of aging of updates. ("Fisheye State
> Routing in Mobile Ad Hoc Networks").  It would almost certainly require a
> new specification to say how to do this in a correct and inoperable way, but
> might not violate the specification.  manet-fsr-00 seems like it has not
> been updated in quite a while.  FSR does not alter the "table scalability ";
> it's not claimed in the paper.
>
> On Fri, Dec 19, 2008 at 12:58 AM, Emmanuel Baccelli <
> Emmanuel.Baccelli@inria.fr> wrote:
>
>>
>>
>> On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis <pal@cs.stanford.edu>wrote:
>>
>>> Comment inline.
>>>
>>> On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote:
>>>
>>>
>>>>
>>>> On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis <pal@cs.stanford.edu>
>>>> wrote:
>>>>
>>>> On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote:
>>>>
>>>>
>>>> Now, let's try to be constructive and address your concerns.
>>>>
>>>> 1) Lack of background, context, ... in the document. Emmanuel is quite
>>>> right that background is missing in the document as well as a clear
>>>> conclusion: "how have we chosen the protocols in the survey, why protocols
>>>> X, Y, Z, ... have not been included in the survey, ...". I saw that Phil
>>>> agreed to add some text to address this issue.
>>>> Emmanuel, does that address your concern (to be confirmed once you see
>>>> the text) ?
>>>> Phil, could you please propose some text ?
>>>>
>>>> The OSPF section will be renamed OSPF/IS-IS and I will add supporting
>>>> text that notes the distinctions between the two and why their analysis is
>>>> the same.
>>>>
>>>> I guess that's not all, right? I suppose there will be additional text
>>>> justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be
>>>> evaluated is indeed a good sample of what is done in the IETF. Somewhere in
>>>> this additional text, we also need some justification why DTN protocols are
>>>> ignored and why there is not a word about NEMO-RO. I would rather recommend
>>>> that one or two protocols such as PRoPHET (DTN protocol put forward by
>>>> Stephen Farrell) be evaluated too, but if there is justification in the
>>>> draft why not to do it, it would be OK I guess (at least with me). In any
>>>> case, the goal of these additions would be to make the document both more
>>>> self-contained and self-explanatory, while easier to relate with the content
>>>> of the current charter.
>>>>
>>>>
>>>
>>> Emmanuel, did you read the rest of my message? I address NEMO/DTN on
>>> point 2. Please acknowledge.
>>>
>>
>>
>> Here are some relevant pointers (non-exhaustive list):
>>
>> http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01
>> http://tools.ietf.org/html/draft-thubert-tree-discovery-06
>>
>> They are in scope (NEMO space and DTN space) and they are describing
>> routing protocols that may be of interest for ROLL.
>>
>> If we just add the line you proposed, there will be no justification why
>> they are not evaluated. Do you agree?
>>
>> So we have a choice to make: either
>> (i) justify why such routing approaches are not in scope, or
>> (ii) evaluate a couple of such protocols in the draft, so as to partially
>> cover DTN and NEMO spaces, as the charter indicates.
>>
>> I suppose the latter wouldn't take so long? It's just a couple of
>> additional paragraphs and a couple of additional lines in the pass/fail
>> table, like for the protocols already evaluated in the draft... Do you
>> agree?
>>
>> Emmanuel
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>> 2) Missing protocols: we had to draw the line somewhere. *LOTS* of
>>>> protocols have been proposed over the last decade. We had many suggestions
>>>> to also look at protocol X, Y and Z. The decision was (according to our
>>>> charter) to limit our survey to existing IETF protocols (RFC or very mature
>>>> ID):  OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly
>>>> long. The charter mentions DTN. The WG decided not to include DTN and this
>>>> needs to be documented.
>>>> Phil, could you please add some text ? Note that this does not mean that
>>>> we may not borrow mechanism(s) from existing protocols by the way if we get
>>>> re-chartered.
>>>>
>>>> The current text reads:
>>>>
>>>> "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."
>>>>
>>>> I propose
>>>>
>>>> "This document considers "existing routing protocols" to be routing
>>>> 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. It does not
>>>> examine the Network Mobility Basic Support Protocol (NEMO)[cite],
>>>> DTN bundles[cite], or the DTN Licklider protocol[cite] because they
>>>> are not routing protocols."
>>>>
>>>>
>>> Phil
>>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>