Re: [Roll] call for consensus for the RPL RPI / RH3 compression

Robert Cragie <robert.cragie@gridmerge.com> Fri, 19 December 2014 15:54 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173571A89C4; Fri, 19 Dec 2014 07:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey3c4F-Q2v5m; Fri, 19 Dec 2014 07:54:41 -0800 (PST)
Received: from mailscan1.extendcp.co.uk (mailscan34.extendcp.co.uk [79.170.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2C21A89B9; Fri, 19 Dec 2014 07:54:40 -0800 (PST)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1Y1zt0-0005m8-1G; Fri, 19 Dec 2014 15:54:38 +0000
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1Y1zsy-0001qU-Jl; Fri, 19 Dec 2014 15:54:37 +0000
Received: from [12.234.128.141] (helo=[100.68.5.120]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Y1zst-0002rc-UH; Fri, 19 Dec 2014 15:54:32 +0000
Message-ID: <54944A36.4000101@gridmerge.com>
Date: Fri, 19 Dec 2014 15:54:30 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com> <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <E045AECD98228444A58C61C200AE1BD848AC7D04@xmb-rcd-x01.cisco.com> <54942758.6090705@innovationslab.net> <E045AECD98228444A58C61C200AE1BD848AC86C5@xmb-rcd-x01.cisco.com> <549440F0.8040407@innovationslab.net>
In-Reply-To: <549440F0.8040407@innovationslab.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010703010502080204070200"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DN_9_dv7rHhjvDeagloftCB2AYM
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>
Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Dec 2014 15:54:45 -0000

+1.

It sounds like an interop would be the ideal place to test out the 
various hypotheses on the respective proposals.

Robert

On 19/12/2014 15:14, Brian Haberman wrote:
>
> On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:
>> That's interesting, Brian.
>>
>> We decided that for completeness of its expression of the RPL
>> operation, the draft should provide a pointer on the way the RPL info
>> is carried. We need a minimum set of common stuff to interop and the
>> way to express the RPL information is one. We can live with any
>> default as long as everyone implements it. Now if optionally people
>> support additional ways to make comparisons with that reference, that
>> would certainly be good, if the question is still open at that time.
>> All in all, if you agree, we can progress the draft in IESG review
>> leaving that particular reference open to be changed till later in
>> the process?
> Why would you expect that to be acceptable?  If a piece of the spec is
> needed for interoperability, it needs to be there during the review.
> Why send it to the IESG if there are still questions on how that piece
> will be done?  If it is left out, how will anyone know if there is
> consensus on the spec as a whole?
>
> It seems to me that:
>
> 1. There have been several proposals put forth
>
> 2. Issues have been raised on each one
>
> So, it seems prudent (to me) to look at each of the alternatives and
> determine which warts everyone concerned is willing to live with.
> Running code is a good way to do that.
>
> Making that determination needs to be done before the spec is sent to
> the IESG.
>
> Regards,
> Brian
>
>> Pascal
>>
>>
>>> -----Original Message----- From: Brian Haberman
>>> [mailto:brian@innovationslab.net] Sent: vendredi 19 décembre 2014
>>> 14:26 To: Pascal Thubert (pthubert); Routing Over Low power and
>>> Lossy networks Cc: 6man-chairs@tools.ietf.org;
>>> int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo-
>>> chairs@tools.ietf.org Subject: Re: [Roll] call for consensus for
>>> the RPL RPI / RH3 compression
>>>
>>> Pascal,
>>>
>>> On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote:
>>>> The rush Carsten,
>>>>
>>>> is that the document that will be the base for the 6TiSCH interop
>>>> test in Prague is now in last call, and that document refers to
>>>> the NHC draft. The question is what should it refer to, and
>>>> whatever it refers to should be stable and implementable by now.
>>> So, do you view the code for the interop being "set in stone"?  As
>>> Adrian pointed out, the interop could be a way to work out the
>>> tradeoffs of these multiple approaches.  That is, running code
>>> leads to an IETF specification rather than the other way around.
>>>
>>> Regards, Brian
>>>
>>>> Just the first (per your words) is just fine with me.
>>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>>> -----Original Message----- From: Roll
>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Carsten Bormann
>>>>> Sent: vendredi 19 décembre 2014 09:17 To: Routing Over Low
>>>>> power and Lossy networks Cc: 6man-chairs@tools.ietf.org;
>>>>> int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo-
>>>>> chairs@tools.ietf.org Subject: Re: [Roll] call for consensus
>>>>> for the RPL RPI / RH3 compression
>>>>>
>>>>> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert)
>>>>> <pthubert@cisco.com> wrote:
>>>>>> Decision in Hawaii was that the NHC draft could not be
>>>>>> accepted as is, since we should compress also the RH3, and
>>>>>> without a clear view of how that would happen, the details of
>>>>>> the NHC compression could not be determined. So the NHC
>>>>>> approach was abandoned
>>>>> That is not at all what I recollect from Hawaii.
>>>>>
>>>>> The current smorgasbord is:
>>>>>
>>>>> — various ways to hijack the flow label (dead) — the 6553-NHC
>>>>> proposal — ideas for a new mesh header
>>>>>
>>>>> I’m not going to beat the dead horse of the flow label hijack.
>>>>>
>>>>> The 6553-NHC proposal mainly needs a decision between the
>>>>> three variants (flip a coin, if need be). If time is of the
>>>>> essence, 6553-NHC is the natural thing to do. We can always do
>>>>> an RFC 6554 NHC compression separately.
>>>>>
>>>>> The MH proposal is forward-looking and probably the right thing
>>>>> for the evolution of 6lo, but probably also not compatible with
>>>>> a tight time schedule.
>>>>>
>>>>> Now, what is the rush? RFC 6553/6554 do exist.
>>>>>
>>>>> So we get to choose between rushing 6553-NHC to completion or
>>>>> using 6553/6554 for now and doing the MH work right (or. more
>>>>> likely than just the first, both). I don’t have an opinion on
>>>>> wether we need to rush 6553-NHC, but if we need to rush
>>>>> anything, this one it is.
>>>>>
>>>>> Grüße, Carsten
>>>>>
>>>>> _______________________________________________ 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