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

Robert Cragie <robert.cragie@gridmerge.com> Wed, 20 August 2014 14:48 UTC

Return-Path: <robert.cragie@gridmerge.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 6DACD1A0435; Wed, 20 Aug 2014 07:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ozeKkKyF_pmm; Wed, 20 Aug 2014 07:48:37 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.21]) (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 680DA1A0436; Wed, 20 Aug 2014 07:48:33 -0700 (PDT)
Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1XK7Bg-0004Ed-AB; Wed, 20 Aug 2014 15:48:32 +0100
Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1XK7Bd-00034e-PV; Wed, 20 Aug 2014 15:48:32 +0100
Received: from host86-171-66-149.range86-171.btcentralplus.com ([86.171.66.149] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XK7Bc-0000VM-5b; Wed, 20 Aug 2014 15:48:28 +0100
Message-ID: <53F4B536.3060101@gridmerge.com>
Date: Wed, 20 Aug 2014 15:48:22 +0100
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: roll@ietf.org, "6lo@ietf.org" <6lo@ietf.org>
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> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net> <53F10959.2000102@gmail.com> <53F2375E.6000501@globis.net> <7414.1408396816@sandelman.ca>
In-Reply-To: <7414.1408396816@sandelman.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080103090101000104060601"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/H3MxdKSGQDl3MfoFuTpzfDY4348
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: robert.cragie@gridmerge.com, 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: Wed, 20 Aug 2014 14:48:44 -0000

I have been following this discussion with interest and here is my quick 
take on it:

* Flow label seems a fairly abstract concept and it doesn't seem 
unreasonable to use the space it occupies within a specific domain like 
RPL. What is proposed in draft-thubert-6man-flow-label-for-rpl-03 
doesn't seem consistent with the principle of what a "flow" is though as 
it changes hop-by-hop, which is clearly not the intended purpose for a 
flow label field. However, as others have pointed out, it is still a 
mutable field as far as AH is concerned and therefore that does not 
preclude the use as specified in 
draft-thubert-6man-flow-label-for-rpl-03. It is also clear that the flow 
label has to be reset at the edge of the domain anyway.
* Route-over in a mesh network changes everything. The use of the RPL 
option in RFC6553 does indeed seem reasonable but the IP-in-IP 
construction then complicates matters considerably.
* What Carsten proposes in draft-bormann-6lo-rpl-mesh-01 makes the most 
sense to me as putting it at "layer 2.5" is the logical place to put 
this sort of information due to it being hop-by-hop

So in summary, I have no real objection to what is proposed in 
draft-thubert-6man-flow-label-for-rpl-03 but I think Carsten's approach 
is better.

Robert

On 18/08/2014 10:20 PM, Michael Richardson wrote:
> I just want to point out that the RPL Instance ID isn't used for routing
> like the MPLS label. RPL nodes still do longest prefix match routing
> on IPv6 destination address.
>
> If you had to make an analogy to other technology, it's more like a VLAN
> tag being used to pick a virtual router/routing table.
>
>> I would prefer to avoid making the trade off if we don't have to. Who knows
>> what future application will use the flow label?
> Yes, my response is: "hi, we are the future. Do you mind if we use that
>       thing you reserved for us?"
>
>> I'm no RPL expert, but
>> http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more elegant
>> and avoids all of this discussion.
> 6lo-rpl-mesh is certainly merits discussion.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll