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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 02 May 2014 16:54 UTC

Return-Path: <pthubert@cisco.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 305751A6FC1; Fri, 2 May 2014 09:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level:
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 sRpOq4ozpFJp; Fri, 2 May 2014 09:54:27 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4F1A6F88; Fri, 2 May 2014 09:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9878; q=dns/txt; s=iport; t=1399049665; x=1400259265; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ekj1PpmxKhO2uYMjXFRs+nM3bzGN490KARETA+/vEv4=; b=MT15gGce8RyDgBHWFA3Cz2eGPC1dx0/+Bg6ngz0I4Jp6VP9819UVhUbB vHU9pFNgn0ATQ4UNRu+fLv0ploqgQfb3KlM8z8azS1PQeUKAGQciJxmVE XaEHbXDYCWpXawIKq+860WYcsq3wY53A+YTHAMf4z4zRjb3jhpcWoQ61L 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAMDMY1OtJV2c/2dsb2JhbABagwZPWIJnqhCQG4ZoURl4FnSCJQEBAQMBAQEBIBEVJQQHBQ0BCBEEAQEBAgIGHQMCBB8GCxMBAQgJAQQBDQUIiCUDCQgNpgedVw2GRBeBKosRgS8XAQEBHRYbgnY1gRUEhFkDkmIGgyiJToIKhVuBdYE/gXY5
X-IronPort-AV: E=Sophos;i="4.97,973,1389744000"; d="scan'208";a="40582311"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 02 May 2014 16:54:21 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s42GsLCR004875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 May 2014 16:54:21 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 2 May 2014 11:54:21 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>
Thread-Topic: [6tisch] [Roll] Support of flow label to carry the RPL information in data packets
Thread-Index: Ac9mJv51tx5eNW6ATb660Q0CI/KJdg==
Date: Fri, 2 May 2014 16:54:20 +0000
Deferred-Delivery: Fri, 2 May 2014 16:54:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842632160@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.22.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/pHdRPsuoncSS2R3yFaTfxEfzocw
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
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: Fri, 02 May 2014 16:54:30 -0000

Thanks a bunch for this Brian;

I'll submit a revision addressing your points. Please see inline:

> > 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.
> 
[PT] This assumption is there today, since RPL expects to build stub networks with a default route towards the root. I agree it makes sense to provisionally add words to indicate a treatment for packets leaving the RPL domain regardless of the exit point in case a weird deployment would inject traffic into the internet from a leaf. 
>
> 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.
> 
[PT] yes

> 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.
 
[PT] Roll and 6TiSCH are copied; the draft has circulated as a ROLL draft for quite a while without an objection on that matter.
We are not deprecating the other method, but we are proposing an alternate method. I results that we'll have to decide how an implementation knows which method to use.




> 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.

[PT] Can I change that text to describe the behavior proposed by the draft inside the RPL domain as the way the rules in 6437 are interpreted?


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
> >