Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Philip Levis <pal@cs.stanford.edu> Sat, 16 August 2014 00:41 UTC

Return-Path: <pal@cs.stanford.edu>
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 65FAE1A0911; Fri, 15 Aug 2014 17:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level:
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 5hYcEJA9C8vM; Fri, 15 Aug 2014 17:41:41 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (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 35B6B1A0910; Fri, 15 Aug 2014 17:41:41 -0700 (PDT)
Received: from [76.14.66.110] (port=61066 helo=[192.168.0.106]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XIS3w-0003uj-1t; Fri, 15 Aug 2014 17:41:40 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <53E926EB.9000505@gmail.com>
Date: Fri, 15 Aug 2014 17:41:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: b64bce576883819501cf77c9371f4538
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/77LKcHLhqFNggHKQpLAaq0-bZog
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ole Troan <otroan@employees.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
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: Sat, 16 Aug 2014 00:41:42 -0000

On Aug 11, 2014, at 1:26 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Therefore, treating RPL as a special case is the remaining option.
> But does the ROLL community actually have consensus that they want
> this special case?

I'd argue that if you look at the 15+ so years of work into mesh routing on low power and lossy networks, data path validation is a common technique to almost every approach. That is, there is absolutely consensus in the people engineering these protocols that data packets need to carry information about the route so the network can quickly discover and adapt to changes in the topology. The reason is that the topology can change very quickly, on the order of a few tens to hundreds of packets. 

It turns out that this is very difficult to do efficiently in the IP architecture if you have small packets. HbH headers aren't tiny, and IP-in-IP encapsulation is significant.

In the broader scope of running IP over LLNs, I think that the ability to encode data path information into IPv6 headers without introducing significant overhead is critical. I therefore think this special case is worth it and important enough. But I also think it's important to very explicitly state that it is an additional special case, e.g., through an Updates:.

Phil