Re: [Roll] using the flow label instead of hop by hop

Philip Levis <pal@cs.stanford.edu> Fri, 19 October 2012 20:08 UTC

Return-Path: <pal@cs.stanford.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF6521F87FE for <roll@ietfa.amsl.com>; Fri, 19 Oct 2012 13:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlWm8s4TbcKA for <roll@ietfa.amsl.com>; Fri, 19 Oct 2012 13:08:19 -0700 (PDT)
Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id F11E721F8200 for <roll@ietf.org>; Fri, 19 Oct 2012 13:08:18 -0700 (PDT)
Received: from dn0a21026c.sunet ([10.33.2.108]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <pal@cs.stanford.edu>) id 1TPIrd-0006hK-Fg; Fri, 19 Oct 2012 13:08:16 -0700
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <5081A327.9010505@exegin.com>
Date: Fri, 19 Oct 2012 12:46:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B2EA2C51-CC54-4B08-949C-5CF09EBFC3E0@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD8221CB0DA@xmb-rcd-x01.cisco.com> <5081A327.9010505@exegin.com>
To: Owen Kirby <osk@exegin.com>
X-Mailer: Apple Mail (2.1278)
X-Scan-Signature: 8ab272620d4bdfee2f14268d9892c5ce
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] using the flow label instead of hop by hop
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 Oct 2012 20:08:20 -0000

I realize there's a lot of pressure for this in terms of header sizes, but this seems like exactly the kind of engineering hack/optimization that has painful long-term implications. Such as the Internet of Things prevents the flow label from ever being used effectively.

Phil

On Oct 19, 2012, at 11:59 AM, Owen Kirby wrote:

> Pascal,
> 
> I'm not entirely convinced that using the flow label like this is a good idea. Using the flow labels to carry the RPL HbH information works on the premise that packets being routed through the RPL domain wouldn't otherwise use the flow label. This assumption might be correct in a network of homogenous nodes with no external prefixes (eg: appendix A.5), but there may still be cases where packets being routed through the RPL domain might want to set the flow label. If this draft were to go forward, I would have some questions:
> 
> When a  forwarding node receives a packet with the flow label set, how does it determine whether the flow label contains an identifier of the 5-tuple, or it contains the RPL HbH information? To get it wrong would interfere with the forwarding behavior and lead to interoperability issues.
> 
> When packets are received from an external prefix, how does the ingress router handle the flow label? Would it destroy the original label, leave the original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the label (ie: the inner header contains the original flow label, and the outer header contains the HbH information)?
> 
> How would the DODAG root rebuild the flow label from the 5-tuple if it encounters packets that have been fragmented at the IPv6 layer? The primary use of the flow label is so that routers don't have to reassemble IPv6 fragments when forwarding to determine the 5-tuple (which is a challenging thing for a router to do).
> 
> Cheers,
> Owen
> 
> On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote:
>> Hi
>>  
>> When I started this draft, we had a series of chats with Brian Carpenter and apparently reached a gentleman agreement that it was doable within the RPL domain to use the flow label and avoid the Hop by Hop option.
>>  
>> I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on that discussion but did not get news from the group since then.
>>  
>> This technique has a number of advantages, in particular
>> -it saves extra bytes for the RPL option and the HbH header.
>> -it also avoids the prescribed tunneling within the RPL domain for packets from the outside.
>> - it has an optimized compression with 6LoWPAN.
>>  
>> Is there interest in the group to continue? If so I’d be glad to have some discussion time at the next meeting.
>>  
>> Cheers,
>>  
>>  
>> 
>> Pascal Thubert
>> IPv6 Engineering
>> 
>> pthubert@cisco.com
>> Phone :+33 497 23 26 34
>> Mobile :+33 619 98 29 85
>> 
>> 
>> Cisco Systems
>> Village d'Entreprises Green Side bat. T3 
>> 400, Avenue Roumanille
>> 06410 Biot - Sophia Antipolis  
>> France
>> 
>> Cisco.com
>> 
>> <Mail Attachment.jpeg>
>> 
>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.
>>  
>>  
>> 
>> 
>> _______________________________________________
>> 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