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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 01 August 2014 12:56 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 D19921A854B; Fri, 1 Aug 2014 05:56:47 -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 qVTfW_Gq8kUU; Fri, 1 Aug 2014 05:56:42 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEB81A0B14; Fri, 1 Aug 2014 05:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3352; q=dns/txt; s=iport; t=1406897802; x=1408107402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tVR2wH25GCFpDfqHL4WDRHLF1o52CijN/QbyRyKzFY0=; b=RzeHxqv549lxjCMRTokONjKPSTKl0WPxOAWC01AVTQ7ItpecEaSnC3Wt x5pToU1Jnth+sYJUOcGh70rz5NX0VTnONQb5tl9gi1OTDRKH5M4Vx90Q4 cvzkd2nZtJy/BQSrw54Qk6nmoHcxbIAG5sf2tiCef6OMHA3WCGfHfQWK/ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAHyN21OtJA2D/2dsb2JhbABbDoJ/UlcEy38Kh0wBgQgWd4QDAQEBAwEBAQFrCwwEAgEIDgMBAwEBAQodBycLFAMGCAIEAQ0FCIgyCA3JeBMEjn4dMQcGgymBHAWGBoRIpgaDB0JsgUU
X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="344416242"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2014 12:56:41 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s71CufmE019179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 12:56:41 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 07:55:51 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrXsN1MAnFsPEm0SwuR6qTQA6spu7svGw
Date: Fri, 1 Aug 2014 12:56:40 +0000
Deferred-Delivery: Fri, 1 Aug 2014 12:56:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D049E9@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>
In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.197.62]
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/6K7SWiHy905t-l8DpjM2osw_8Fw
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <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: Fri, 01 Aug 2014 12:56:48 -0000

> > Let's look at what IPHC does at the LBR when a flow label is elided and has
> to be inflated to be forwarded to the IPv6 network, this standardized
> behaviour is somehow interfering the end to end notion of the flow label as
> the content is being populated at the border of the LLN.
> 
> No.  With IPHC, the flow label has always been there, it just was transmitted
> in a very compressed form.

My take is that you are both providing angles on a same thing. It does not make sense for a LLN node to waste compute power and bandwidth to get a random through that is of use only in the core of the internet, should the packet ever get there. So the flow label is effectively zero - or something locally significant in specific standards, which is not design to serve the purpose of load balancing in the core. So in either case, we need the root to 'inflate' the zero flow label, or replace it by something that fits the core of the Internet. That behavior was not specified so far and it should be. This document is covering this particular gap.

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: vendredi 1 août 2014 13:24
> To: Xavier Vilajosana
> Cc: roll; ipv6@ietf.org
> Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> On 01 Aug 2014, at 10:50, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
> wrote:
> 
> >
> > Let's look at what IPHC does at the LBR when a flow label is elided and has
> to be inflated to be forwarded to the IPv6 network, this standardized
> behaviour is somehow interfering the end to end notion of the flow label as
> the content is being populated at the border of the LLN.
> 
> No.  With IPHC, the flow label has always been there, it just was transmitted
> in a very compressed form.
> 
> I think the visceral reaction that most of us have in using the flow label as a
> mesh routing header is that this blurs the layer boundaries.  So much for O,
> R, F, and rank.  Putting the VLAN ("instance ID") into the packet is a
> significantly larger change, because it essentially extends the IP service
> interface by a VLAN ID.  We normally try to hide IDs of this kind below IP.
> 
> Now, I'm not saying any of this new architecture is wrong.  I just think what
> we need to do is discuss this as the architectural change that it is, not as a
> simple optimization.  (The need for some kind of optimization of IP-in-IP
> mesh routing for small-packet IoT applications is pretty obvious to me.)
> 
> The other story is that we are retracting RFC 6437 and turning the flow label
> into the "field you may trample on in your lower layers if you have a good
> reason".  Cynically, one could say this is proper payback for designing this
> field without a compelling purpose and no protocol evolution story attached
> to it.  So the evolution just eats it.  Teachable moment.
> 
> Grüße, Carsten
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------