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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 04 August 2014 15:42 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 028711B2B85; Mon, 4 Aug 2014 08:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 i2uzP1eyA2Ne; Mon, 4 Aug 2014 08:42:04 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9471B2B87; Mon, 4 Aug 2014 08:42:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2791; q=dns/txt; s=iport; t=1407166925; x=1408376525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xw3B3o2JPOVlwtt1J2/28xsD7wSNskWemkGFgIbJPoA=; b=Q+xk0i1hPwJMQZzZMdTIebNY51L7W4uI19HfoNNFmwhc+L67v3yCzcui xjCV3bvnHxbl/C37RXIBqQKDwii+vcfMpynp/Sm470vWity1aM/pr11i9 ReoandSFkk5X7Fx76XJwDgYXSSfZxtS2zLLGD82qO4S60q5DFaI/hoWIR M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj4FAJup31OtJV2a/2dsb2JhbABagw2BKQTTewGBEBZ3hAMBAQEEeQwEAgEIEQQBAQEKHQchERQJCAIEAQ0FCIgmAxG+Jw2HABeNH4F8MQcGgymBHAWKVY8qkD6GKINNbAGBRQ
X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="344977142"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 04 Aug 2014 15:41:57 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s74FfuAB031725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 15:41:56 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 10:41:56 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Ole Troan <otroan@employees.org>
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrcL83Dn9icet106HlaTIaH7gh5vAi3mAgABJ2ID//8HXoA==
Date: Mon, 04 Aug 2014 15:41:55 +0000
Deferred-Delivery: Mon, 4 Aug 2014 15:41:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D17F25@xmb-rcd-x01.cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.com> <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.org> <26363.1407161715@sandelman.ca>
In-Reply-To: <26363.1407161715@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.74.174]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/FMHYkuruIeMYGmvVfnmY57ym9OM
Cc: roll <roll@ietf.org>, 6man WG <ipv6@ietf.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: Mon, 04 Aug 2014 15:42:06 -0000

Exactly;

It can be argued that the LLN is a single something that is a more complex form of the classical host-router link from the L3 perspective.
RFC6437 understands that the host can leave the flow label to all zeroes and allows the first router to set it in a recommended fashion. 
The draft pushes that role to the RPL root that is effectively the gateway from the LLN onto the Internet.
Upon the WLLC discussion I have added " Updates: 6437 (if approved) " and posted an update with no other change in the text.

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: lundi 4 août 2014 16:15
> To: Ole Troan
> Cc: roll; 6man WG
> Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> 
> On 01 Aug 2014, at 21:58 , Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote:
>     >> It is true that the RFC also says
>     >>
>     >> A forwarding node MUST either leave a non-zero flow label value
>     >> unchanged or change it only for compelling operational security
>     >> reasons...
>     >>
>     >> There is a case for arguing that flow-label-for-rpl should carry the
>     >> legend "Updates: 6437 (if approved)" because it adds another
> exception
>     >> to this sentence. There is also a case for arguing that
>     >> flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6437
>     >> according to Section 4 of that RFC.
>     >>
>     >> Either way, I don't see a problem.
> 
> Ole Troan <otroan@employees.org> wrote:
>     > I see the principles in these two documents as mutually exclusive:
>     > RFC6437: middleboxes can mess with the flow label -flow-label-for-rpl:
>     > networks uses flow label field as an immutable protocol field
> 
>     > you can't both use the flow label as an immutable protocol field and
>     > have middleboxes rewriting it.
> 
> This is my take.
> Case 1:  packet is within the LLN.  No issue; the sender sets the flow label,
>      and we know (by design) that there aren't any (non-RPL) middle boxes
>      that need to rewrite it.
> 
> Case 2: the packet has to leave the LLN, travel across the Internet, and
>      enter another LLN.
>      Here the arguments about the LLN being a kind of virtual host from
>      the document are relevant.  The flow label, when it crosses the
>      Internet, would be immutable.  Prior to this document, the flow label
>      would have been compressed out, been zero, and the DODAG root ought
> to
>      have set it in some consistent fashion anyway.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>