Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 09 May 2012 08:32 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A1521F85B4 for <roll@ietfa.amsl.com>; Wed, 9 May 2012 01:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.218
X-Spam-Level:
X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxxkMxotO32Z for <roll@ietfa.amsl.com>; Wed, 9 May 2012 01:32:05 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 131E221F846E for <roll@ietf.org>; Wed, 9 May 2012 01:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=12858; q=dns/txt; s=iport; t=1336552324; x=1337761924; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7o9ig+YUP2MkRjfMRUROCJrG45fbNCOpcVHU0Rw8ms8=; b=G/m+HuiHARedVrbUDxyiRfreGUdUw5bk1opP/tc0e/q0fwgCHYTgXHcB BqjoTU7cruH4/ikF+AEj1AQvB5HLtFvGv4qytlM+c+JPDTpcY6EKcJ49l dB7RW7F+RE46skG0/HVYt2vEntS0Bz80in4V3Fp6j11UM4wT88MqVyAH/ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAN8qqk+Q/khN/2dsb2JhbABEhXWsPoESgQeCDAEBAQMBEgEQDQQ3DgwEAgEIEQQBAQECAgYGFwECAgIBAR8lCQgBAQQTCBEJh14DBgWbDY0WiTQNiVOBL4hyawUXhF41YwShO4MagWmCaw
X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="72757501"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 09 May 2012 08:32:02 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q498W2uA027047; Wed, 9 May 2012 08:32:02 GMT
Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 10:32:02 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Wed, 9 May 2012 10:31:35 +0200
Message-ID: <BDF2740C082F6942820D95BAEB9E1A8401A393C4@XMB-AMS-108.cisco.com>
In-Reply-To: <4FA9230F.5090100@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D Action: draft-thubert-roll-flow-label-00.txt
Thread-Index: Ac0tIJ/V+K5iLLSPQgecC3rzVf34+AAnNszg
References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> <4FA3C476.5000903@gmail.com> <BDF2740C082F6942820D95BAEB9E1A840196201E@XMB-AMS-108.cisco.com> <4FA8ECF0.7070200@gmail.com> <BDF2740C082F6942820D95BAEB9E1A840196237C@XMB-AMS-108.cisco.com> <4FA9230F.5090100@gmail.com>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 09 May 2012 08:32:02.0172 (UTC) FILETIME=[351CABC0:01CD2DBE]
Cc: roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 09 May 2012 08:32:06 -0000

Hi Brian:
 
>>> If we are talking about the encapsulating packet, sure. Is there any reason that the label in the raw packet would be changed?
>> But that's the core problem we'll have to solve. This draft aims specifically at removing the extra encapsulation that consumes octets and thereby battery.
>OK, somehow this was still not very clear to me. I think maybe some diagrams for the non-RPL-expert are needed.
 >I try to avoid being doctrinaire; all I can tell you is the models we proposed in 6man which involved rewriting the flow label at domain boundaries were very unpopular.

[Pascal] This is MUCH appreciated, Brian. 

>You should probably look at draft-carpenter-6man-flow-update-03[]  (and only the -03 version). I think that would have allowed what you want to do, but it was firmly rejected by 6man.

>Thus what I am about to say is heresy: as long as the flow labels emerging from the RPL domain *look* as if the source computer set a flow label per flow conformant with RFC 6437, it should be OK.

>Except for this complication: in the world of server load balancing, there is some interest in using the same flow label for multiple transport sessions from the same client, even if the client's IP address changes due to mobility. This is still pretty speculative, but it really does require the source node to have control over the final value of the flow label.

[Pascal] I added text and published 01 per our discussions. The text indicates that the RPL option is still an option. This is true in particular when the flow label as another usage or if the part of the Rank that is meaningful to establish the path consistency cannot be compressed in one octet.

Thanks a bunch for all;


Pascal
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: mardi 8 mai 2012 11:53
> To: Pascal Thubert (pthubert)
> Cc: roll@ietf.org
> Subject: Re: I-D Action: draft-thubert-roll-flow-label-00.txt
> 
> On 2012-05-07 13:59, Pascal Thubert (pthubert) wrote:
>> Hi Brian:
>>
>>> IMHO there are problems with this proposal. One is that it doesn't, 
>>> as far as I can see, demonstrate that the overhead of rewriting the 
>>> flow label on exit from an RPL domain is significantly less than the 
>>> overhead of dealing with the RPL hop-by-hop option at the edge of 
>>> the domain.
>> [Pascal] The overhead is mainly for packets coming from the outside 
>> into the RPL domain. Such packets need extra encapsulation that's 
>> detrimental for batteries and may cause a small packet to grow above 
>> the MAC Max Frame, leading to L2 or 6LoWPAN fragmentation.
> 
> If you can explain this in a few words in the text, it will be fine.
> 
>> Then, this phrase:
>>
>>> Sadly, the Option must be placed in a Hop-by-Hop option that must be 
>>> inserted or removed as the packet crosses the border of the RPL 
>>> domain.
>> bothers me, because (and I have looked recently) there is nothing in 
>> the IPv6 specs that allows for an extension header being inserted (or
>> removed) en route. The text continues
>>
>> [Pascal] I'll reword to indicate that the operation of inserting / 
>> removing the HbH header comes with 6in6. RFC 6553 says: " When the 
>> router is the source of the original packet and the destination is 
>> known to be within the same RPL Instance, the router SHOULD include 
>> the RPL Option directly within the original packet. Otherwise, 
>> routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the RPL 
>> Option in the tunnel header.  Using IPv6-in-IPv6 tunneling ensures 
>> that the delivered datagram remains unmodified and that ICMPv6 errors 
>> generated by a RPL Option are sent back to the router that generated 
>> the RPL Option."
> 
> Yes, I had to read quite deeply into 6553 to understand this. I think your draft will be read by people without detailed knowledge of RPL so it needs to be explained.
> 
>>> ...This operation may involve an extra encapsulation that is 
>>> detrimental to the network operation, in particular with regards to 
>>> bandwidth and battery constraints.
>> Why "may"? If the packet is inbound to RPL, RFC 6553 makes it clear 
>> that it must be encapsulated; if the packet is outbound, why would it 
>> be encapsulated at all? This case is covered in the RFC too:
>>
>> [Pascal] I wrote "may" from the fact that the packet may be issued 
>> and consumed within the RPL domain in which case the option is 
>> conserved all the way and there is no 6in6 encapsulation. But I agree 
>> the operation above does come with 6in6.
> 
> OK
> 
>>> 3.  Datagrams destined to nodes outside the RPL Instance are dropped 
>>> if the outermost IPv6 header contains a RPL Option not generated by 
>>> the RPL router forwarding the datagram.
>> Then, the draft says:
>>
>>> This document specifies how the Flow Label can be reused within the 
>>> RPL domain as a replacement to the RPL option.  The use of the Flow 
>>> Label within a RPL domain is an instance of the stateful scenarios 
>>> decribed in [RFC6437]...
>> In fact RFC 6437 carefully says very little about stateful scenarios; 
>> it does not describe them, but it does constrain them. Here is the 
>> entire section on this topic:
>>
>> [Pascal] what about the word "introduced", or "discussed"?
> 
> OK
> 
>>> 4.  Flow State Establishment Requirements
>>>
>>> A node that sets the flow label MAY also take part in a flow state 
>>> establishment method that results in assigning specific treatments 
>>> to specific flows, possibly including signaling.  Any such method 
>>> MUST NOT disturb nodes taking part in the stateless scenario just 
>>> described.  Thus, any node that sets flow label values according to 
>>> a stateful scheme MUST choose labels that conform to Section 3 of 
>>> this specification.  Further details are not discussed in this document.
>>> The problem is that section 3 intentionally does not consider flow 
>>> label values in which any of the bits have semantic significance, 
>>> and this was the consensus in the 6MAN WG after a great deal of 
>>> discussion. However, the  present proposal assigns semantics to 
>>> various bits in the flow label, destroying its desired property of 
>>> belonging to a statistically uniform distribution.
>> [Pascal] That is true within the edge network that is the RPL domain.
>> But outside the RPL domain the desired properties are conserved. The 
>> rationale for the statistically uniform distribution does not 
>> necessarily bring a lot of value within the LLN. On the other hand, 
>> the 6in6 encaps and HbH header are hugely detrimental to the 
>> operations and will result is shorter battery life and reduced 
>> applicability. I participated as a coeditor to the ISA100.11a 
>> standard that actually uses IPv6 in the 6LoWPAN HC form. I've seen 
>> how the adoption of IPv6 was at stake for a single additional octet 
>> in a header, and this actually led to changes at the IETF and the new 
>> 6LoWPAN HC. Indeed, unless you have a power source, every octet that 
>> you have to place it in every frame or packet in the LLN counts 
>> dearly.
> 
> I understand that, but there was a strong feeling in 6MAN that the flow label should be an end-to-end field (even though that is unenforceable).
> If you can make it clear that the flow label in your model refers only to the label of the encapsulating packet, and that any flow label set by the source host in the inner packet is not changed, it will be fine.
> That's the same model as RFC 6438 (flow labels for ECMP/LAG tunnels).
> 
>>> The issue is clearly stated in RFC 6437:
>>> Once set to a non-zero value, the Flow Label is expected to be 
>>> delivered unchanged to the destination node(s).  A forwarding node 
>>> MUST either leave a non-zero flow label value unchanged or change it 
>>> only for compelling operational security reasons as described in 
>>> Section 6.1.
>> [Pascal]  We have a compelling operational reason for sure, because 
>> the power consumption is the number one critical constraint that 
>> drives most of the physical design choices in a LLN where a battery 
>> life must often expressed in years.  I'm unclear, though, why RFC
>> 6437 went as far as indicating that the compelling reason should be 
>> qualified as security.
> 
> Because the firewall people had already made it very clear that whatever we wrote in an RFC, firewalls in sensitive applications would treat the flow label as a covert channel risk. Apart from that, as noted above, the WG wanted to insist on the end to end property of the label.
> 
>> I take that as an indication of criticality as opposed to a tentative 
>> to predict future needs. It makes sense to me to add in the draft 
>> that "the source in the LLN SHOULD set the Flow label to zero and 
>> MUST NOT expect that the flow label will be conserved end to end if 
>> it knows by policy that the LLN will use this draft". Would that be 
>> sufficient to alleviate this concern?
> 
> If we are talking about the encapsulating packet, sure. Is there any reason that the label in the raw packet would be changed?
> 
>    Brian
> 
>> And yes, I will certainly keep you CCed, and CC you if other threads 
>> pop up on the subject in ROLL, if you do not mind;
>>
>> Pascal