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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 19 August 2014 20:31 UTC

Return-Path: <brian.e.carpenter@gmail.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 575781A6EF6; Tue, 19 Aug 2014 13:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 cuMhiHYjI6Mp; Tue, 19 Aug 2014 13:31:47 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06D11A016B; Tue, 19 Aug 2014 13:31:47 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id et14so10516385pad.35 for <multiple recipients>; Tue, 19 Aug 2014 13:31:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4OnGCL2FsypqTrAu4nkvHDbi9nh/tbN/FXoUM5RvEDA=; b=W8sWL5ZyXuTGMvY9Z4ezTNJUhJqiN9Q90jiaD7RxlPuaMAEOxJqoxQq2NUeMCGdoNR kj+PA9Gt11/m0xX5AswYOZ9dVUko4640WlutgHWjp4UkRi58b9DE/WYyxt+B/YxtvpuX TAhG2UOdKX0H1MgYbrq1mkS1Ye51EJHuQoERGExshycY1/gbDML/9YNNRsPVUzFKjWtj 9IQGEyzCX/ul4S6dMvlg8Qo0ZIWguwhXTqcUbSybKseTBFA94TFokDhUhLUgMACKo99O nJH2mAeuv6iFYuLBJFXOuGooQWr6RjVkim1aDPBp6LrZbiWttR6mCRUN+4Y4JThFd+Ed 8vWA==
X-Received: by 10.66.222.132 with SMTP id qm4mr23358367pac.140.1408480305184; Tue, 19 Aug 2014 13:31:45 -0700 (PDT)
Received: from [192.168.178.23] (182.199.69.111.dynamic.snap.net.nz. [111.69.199.182]) by mx.google.com with ESMTPSA id ob14sm30763457pdb.40.2014.08.19.13.31.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 13:31:44 -0700 (PDT)
Message-ID: <53F3B431.7060703@gmail.com>
Date: Wed, 20 Aug 2014 08:31:45 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
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> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>, <53ED1992.1010708@gmail.com> <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> <53EEB016.4030105@gmail.com> <E045AECD98228444A58C61C200AE1BD842D4671C@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D4671C@xmb-rcd-x01.cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/QOgJYyyIuXyGRjhIO_eKc4Z5jcc
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "6lo@ietf.org WG" <6lo@ietf.org>
Subject: Re: [Roll] [6lo] 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: Tue, 19 Aug 2014 20:31:50 -0000

Hi Pascal,

If we're really going to discuss this, we need the IAB to establish
liaison and get the right to let us all see the specification. I'm not
going to spend my time speculating about a secret document. However,
the bit you quote: "FlowLabel: The lower order 16 bits of the FlowLabel
shall be set to ContractID. The higher order 4 bits shall be all zeros."
certainly seems to violate RFC 6437. Whether it violated the somewhat
confused situation left by RFC 2460 and RFC 3697 is less clear. I have
no recollection of anybody from ISA or IEC talking to the IETF about
this issue.

Regards
   Brian

On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:
> Hello Brian:
> 
> I do not think that you can freely download the specification. You probably need membership first. The links exist from the Wikipedia page but they are broken. Same goes for the IEC version which is IEC 62734, but if you have access to the IEC then the current work is here http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir=65C&format=pdf&type=_CDV&file=735ea.pdf
> 
> Quotes: 
> 
> "The ContractID is associated with a particular D-route. This may be used when a particular graph or source D-route is intended to provide a defined level of service"
> 
> "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to ContractID. The higher order 4 bits shall be all zeros. This field shall only be present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC encoding."
> 
> Note that the 6TiSCH architecture echoes this design, and a d-route is very similar to a 6TiSCH track.
> 
> For the sake of history and to my best knowledge, ISA100.11a was the first industrial standard to adopt IPv6 for process control applications (control loops and monitoring). 
> It is effectively enabling IP in the control network, which is an historical step toward the IT/OT convergence, that is the Industrial equivalent of voice and video convergence over IP.
> 
> And also to my best knowledge and conforming RFC 3697, ISA100.11a does not mute the Flow Label inside the network, as Michael points out. Only when the additional backbone Router functionality is defined does the problem of rewriting come into play at the Backbone Router (same position as RPL root). For all I know this work is taking place at the Wireless Compliance Institute, WCI, but I do not have the latest.
> 
> Cheers,
> 
> Pascal
> 
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: samedi 16 août 2014 03:13
>> To: Pascal Thubert (pthubert)
>> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines Robles;
>> 6man WG; 6lo@ietf.org WG
>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>>
>> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:
>>> Hello Brian
>>>
>>> I do not think that ISA10011.a violates RFC 3697. What exactly made you
>> believe so?
>>
>> I was over-interpreting what you wrote, I guess. It's true that 3697 was rather
>> vague about what it called "flow state establishment methods" and
>> permitted both sequential and pseudo-random flow label values. Is the
>> ISA10011.a on line somewhere?
>>
>>> For all I know ISA100 does everything by the book. Note that ISA100 does
>> not update a non zero FL on the fly since it is not set by a source outside the
>> LLN if that is your concern.
>>> OTOH It may violate RFC 6437 in that the flow is not a random but a value
>> attributed by a PCE called system manager (along rules in section 4). As
>> things stand, we'd certainly want the backbone router at LLN egress to
>> rewrite the FL in packets towards the Internet with a randomized per flow
>> value.
>>> It will violate RFC 6437 because if the flow label is set by a router in the
>> Internet - or an updated source that complies to 6437-, the backbone router
>> at LLN Ingress will rewrite it.
>>> Both issues are addressed in my draft for a RPL domain. An RFC will also
>> hint a revision of the backbone router that it should rewrite the FL on
>> outgoing packets.
>>> What do you think?
>> I think that Phil's last message frames the question to 6man correctly, so I
>> will respond to him...
>>
>> Regards
>>     Brian
>>> Pascal
>>>
>>>> Le 14 août 2014 à 22:18, "Brian E Carpenter"
>> <brian.e.carpenter@gmail.com> a écrit :
>>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
>>>>> We can live with this Brian,
>>>>>
>>>>> but then I can we add at least an ISA100.11a network? ISA100.11a was
>> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label
>> to indicate which flow a packet belongs to.
>>>> I have no idea what ISA100.11a is or which organisation developed it,
>>>> but it sounds like a violation of the flow label standard at that
>>>> time (RFC 3697). If I'd known about it, we would probably have
>>>> included it in the menagerie of RFC 6294.
>>>>
>>>> There's not much the IETF can do about other organisations that
>>>> misuse our standards, although indeed we sometimes need to document
>>>> such cases.
>>>>
>>>>   Brian
>>>>
>>>>
>>>> In more details, devices are provisioned with per-flow behavior (including
>> routing) and settings in what is called a contract.
>>>> The contractID is carried in the IPv6 flow label.
>>>>> If so should we name ISA100 specifically or use a more vague description
>> like a "RPL or similar LLN domain"
>>>>> We'll note that resetting an flow label that comes from the Internet
>>>>> is a generic need is that flow label was set according to 6437,
>>>>> cannot be trusted to be untempered with,
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E
>>>>>> Carpenter
>>>>>> Sent: mercredi 13 août 2014 22:53
>>>>>> To: Philip Levis
>>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man
>>>>>> WG; 6lo@ietf.org WG
>>>>>> Subject: Re: [Roll] [6lo] WGLC for
>>>>>> draft-thubert-6man-flow-label-for-rpl-03
>>>>>>
>>>>>>> On 14/08/2014 07:07, Philip Levis wrote:
>>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
>>>>>> <pthubert@cisco.com> wrote:
>>>>>>>> If this draft is not adopted, the flow label from LLN will
>>>>>>>> probably stay all
>>>>>> zeroes as it is today and the goal of 6437 will not be achieved.
>>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437
>>>>>>> is to allow enclosed networks to use the flow label with Brian's
>>>>>>> statement
>>>>>>>
>>>>>>>> Actually that's why I don't want to see a formal update to 6437,
>>>>>>>> because the only rational update would be to allow any closed
>>>>>>>> domain to invent its own usage. We had that argument at length
>>>>>>>> during the development of 6437, and decided against it.
>>>>>>> Phil
>>>>>> Right. I'm drawing a very subtle line between (a) stating an
>>>>>> exception to 6437 for this particular usage and (b) opening the
>>>>>> door to other usages. Since 6man clearly didn't want (b) during the
>>>>>> development of
>>>>>> 6437 I think we do need to limit ourselves to (a).
>>>>>>
>>>>>>    Brian
>>>>>>
>>>>>> -------------------------------------------------------------------
>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> -------------------------------------------------------------------
>>>>>> -
>