Re: [Roll] [6tisch] Support of flow label to carry the RPL information in data packets

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 13 May 2014 01:07 UTC

Return-Path: <brian.e.carpenter@gmail.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 4ECEB1A07DD; Mon, 12 May 2014 18:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 bhONV4s9iuz1; Mon, 12 May 2014 18:07:06 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 61D9C1A07DC; Mon, 12 May 2014 18:07:06 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id bj1so8194212pad.41 for <multiple recipients>; Mon, 12 May 2014 18:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lm6v0JVrboZEEq3ZrENlkaUMbOxng3Cd8e9YYYFrzJM=; b=mG2ed2t8t31e7YkPSnHFDmNC9v9yqxZsF0xhZ6kdUgnFpWk/W5ZD0eG0qB6SJtYPqY piAJDTrwMTgk3wRvicbz6CSBOR7StL79GNaNYscTkjS0R7aQjDQvf4u6sjs5HN0x9R/P t2TsRrqxu40bOi6UImtkgLmPqkqZt3uUqlEEMXrmUKDHodalPk0p+SIZYolj/UuVsgHQ ne6WIz2Yry5DONTtMR0sqkFCkt4ui6Tm78Lknbjy1JW5ODbL6HMdWg9ofig63uCb6Hwl cds1bdXlAOxBukS/d1mPw4oaWbrDa4CBcfsd9Oz0mTBoB7BsLQNcK3PYdm6AbaBw0ka5 QxiA==
X-Received: by 10.66.140.6 with SMTP id rc6mr59951845pab.87.1399943220292; Mon, 12 May 2014 18:07:00 -0700 (PDT)
Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id gz11sm25094941pbd.1.2014.05.12.18.06.56 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 18:06:59 -0700 (PDT)
Message-ID: <53717031.1010800@gmail.com>
Date: Tue, 13 May 2014 13:06:57 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <534D4F7A.3040605@cox.net> <CAH7SZV9WeQmuaHvUZ35_ySL4ak4+SDfbmpMbXgqQL+C833sTGw@mail.gmail.com> <1397607559.92815.YahooMailNeo@web120004.mail.ne1.yahoo.com> <CAP+sJUfx6=-22+A_=M_v3iSf6piGeyHkF2_BPm2ntbWnCEhTSw@mail.gmail.com> <CAMsDxWRgNoWdaRaZz=tOuWQ+ucCfFE7EnHxbbjBvBR64xoF_dQ@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD842605A64@xmb-rcd-x01.cisco.com> <5362DE09.9010405@gmail.com> <E045AECD98228444A58C61C200AE1BD84265698A@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD84265698A@xmb-rcd-x01.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/kkHhgLmdsVosaplz_w5H2hbc3l0
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, roll <roll@ietf.org>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>
Subject: Re: [Roll] [6tisch] Support of flow label to carry the RPL information in data packets
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: 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: Tue, 13 May 2014 01:07:09 -0000

On 13/05/2014 01:32, Pascal Thubert (pthubert) wrote:
> Hi Brian:
> 
> Thanks a bunch for your review and support:
> 
> To address your issues, what would you think about:

Yes, IMHO it's clear and allows for a clear decision.

Thanks
    Brian

> 
> " 
> 
> 1.1.  Applicability
> 
>    This specification applies to a RPL [RFC6282] domain that forms a
>    stub LLN and is connected to the Internet by and only by its RPL
>    root(s), which act(s) as Border Router(s) for the LLN. With RPL, a
>    root is the bottleneck for all the traffic between the Internet and
>    the Destination-Oriented Directed Acyclic Graph (DODAG) that it
>    serves.
> 
>    In that context, the specification entitles a RPL root to rewrite the
>    IPv6  [RFC2460] Flow Label of all packets entering or leaving the RPL
>    domain in both directions, from and towards the Internet, regardless
>    of the original setting.  This may seem contradictory with the IPv6
>    Flow Label Specification  [RFC6437] which stipulates that once it is
>    set, the Flow Label is left unchanged; but the RFC also indicates a
>    violation to the rule can be accepted for compelling reasons, and
>    that security is a case justifying such a violation.
> 
>    This specification suggests that energy-saving, which is the crux of
>    most LLN applications, is another compelling reason for a violation
>    to the aforementioned rule, and that the violation is acceptable as
>    long as 1) it is contained within the RPL domain and 2) the IPv6 Flow
>    Label is rewritten in a manner that conforms the prescriptions of
>    [RFC6437].
> 
> "
> 
> I'm adding some more text to address your points 2 and 3, but it seems to me that the above is what addresses the core of your suggestion.
> Does that seem OK?
> 
> Cheers,
> 
> Pascal
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: vendredi 2 mai 2014 01:52
>> To: Pascal Thubert (pthubert)
>> Cc: 6man@ietf.org; 6tisch@ietf.org; roll; Xavier Vilajosana; Ines Robles
>> Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL information
>> in data packets
>>
>> On 18/04/2014 02:27, Pascal Thubert (pthubert) wrote:
>>> Dear all;
>>>
>>> Considering the support we have at 6TiSCH and ROLL for the work, I
>> published draft-thubert-6man-flow-label-for-rpl-00.txt to the 6MAN WG.
>>> The main discussion is probably to confirm whether our proposed use of
>> the flow label inside the RPL domain is compatible with the goals that are
>> achieved by RFC6437. Let us continue the discussion there from now on.
>>
>> The proposal really does three things:
>>
>> 1. Asserts (implicitly) that a ROLL domain is really, truly, absolutely separated
>> from the Internet at layer 3 except for traffic through its root node (acting as
>> a border router).
>>
>> I think that needs to be stated very explicitly as a fundamental requirement
>> for this spec to be acceptable.
>>
>> 2. It recommends that the root rewrites the flow label on outbound packets
>> according to the provisions in RFC 6437.
>> The slight deviation from RFC 6437 purism there is that it treats the existing
>> flow label on the packets as if it was zero.
>>
>> 3. It requires that the root rewrites the flow label on inbound packets even if
>> they are already set to non-zero.
>> That is indeed a violation of RFC 6437. But it is a violation we have already
>> accepted in another case: "for compelling operational security reasons".
>> What's lost? The ability for nodes inside the ROLL domain to perform flow-
>> label based load balancing for such inbound packets. I think it's for ROLL and
>> 6TISCH to say whether that loss matters.
>>
>> In my opinion, we shouldn't be religious about this as long as point 1 is
>> guaranteed. I don't see any risks to the generic use of the flow label.
>>
>> I think the language around the relationship with RFC 6437 is a bit defensive
>> at the moment and could probably be a bit simpler and clearer. ("The
>> following exceptions to the rules in [RFC6437] are made:..."). I'd have a
>> preference for doing that without a formal update to 6437, because it's only
>> RPL implementors who need to change anything.
>>
>>     Brian
>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>> From: xvilajosana@gmail.com [mailto:xvilajosana@gmail.com] On Behalf
>>> Of Xavier Vilajosana
>>> Sent: jeudi 17 avril 2014 10:00
>>> To: Ines Robles
>>> Cc: Pascal Thubert (pthubert); 6tisch@ietf.org; roll
>>> Subject: Re: [6tisch] [Roll] Support of flow label to carry the RPL
>>> information in data packets
>>>
>>> +1 I think this is more than needed. In addition RFC 6282 defines how
>> header compression needs to be handled together with extension headers. I
>> think this is not clear and leads to confusions (afecting already some
>> wireshark dissectors). The use of flow label will solve several problems at
>> once.
>>> X.
>>>
>>>
>>>
>>> 2014-04-16 22:44 GMT+02:00 Ines Robles
>> <mariainesrobles@googlemail.com<mailto:mariainesrobles@googlemail.com
>>>> :
>>> +1
>>>
>>> Ines
>>>
>>> 2014-04-15 21:19 GMT-03:00 Qin Wang
>> <qinwang6top@yahoo.com<mailto:qinwang6top@yahoo.com>>:
>>> +1
>>>
>>> Qin
>>> On Wednesday, April 16, 2014 1:47 AM, Prof. Diego Dujovne
>> <diego.dujovne@mail.udp.cl<mailto:diego.dujovne@mail.udp.cl>> wrote:
>>> +1 !
>>>
>>> 2014-04-15 12:25 GMT-03:00 Tom Phinney
>> <tom.phinney@cox.net<mailto:tom.phinney@cox.net>>:
>>> +1 for sure. The flow label has always been the preferable method for me,
>> and I suspect for others with knowledge of how it is used in ISA100.11a.
>>> ===
>>>
>>> On 2014.04.15 07<tel:2014.04.15%2007>:25, Pascal Thubert (pthubert)
>> wrote:
>>> Dear all:
>>>
>>> As some of you remember, the RPL specification has changed over time
>> WRT to the location of the information that RPL places in the data packets.
>> We started with the flow label but these were the days when what became
>> RFC 6437 was being defined at 6MAN, so we shied away and defined the
>> HbH technique that is now specified as RFC 6553.
>>> We’ll note that the RPL option defined in RFC 6553 takes 6 octets, and with
>> the HbH hdr we end up with 8 extra octets. An extra IP-in-IP encapsulation is
>> required on top of that unless both endpoints are in the same RPL domain.
>> All this overhead may be acceptable when power is available and the PHY
>> allows for larger frames, but in traditional battery-operated 15.4 with ~ 80
>> bytes usable per frame, my experience from integrating 6LoWPAN HC with
>> ISA100.11a says that all these extra bytes will be on the way of the 6TiSCH
>> adoption.
>>> Still, both RFC 6550 and RFC 6552 are designed to allow for an alternate
>> technique and in particular for the use of the flow label, as is elaborated in
>> http://tools.ietf.org/html/draft-thubert-roll-flow-label-02 . Using the flow
>> label reduces the cost of the RPL information dramatically, down to a level
>> that is probably acceptable for the target SDOs.
>>> So my plan for now is to move the flow label draft to 6MAN and prepare
>> for a hot season, and I’m looking for support from both 6TiSCH and ROLL to
>> back me up from the start.  Yes, you can help!
>>> Please +1 if you agree we need this work to happen, and/or provide any
>> suggestion.
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>> _______________________________________________
>>>
>>> 6tisch mailing list
>>>
>>> 6tisch@ietf.org<mailto:6tisch@ietf.org>
>>>
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> 6tisch@ietf.org<mailto:6tisch@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>>
>>> --
>>> DIEGO DUJOVNE
>>> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
>>> Facultad de Ingeniería UDP
>>> www.ingenieria.udp.cl<http://www.ingenieria.udp.cl/>
>>> (56 2) 676 8125<tel:%2856%202%29%20676%208125>
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> 6tisch@ietf.org<mailto:6tisch@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org<mailto:Roll@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> 6tisch@ietf.org<mailto:6tisch@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>