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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 07 May 2012 13:00 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 C3CEE21F85C5 for <roll@ietfa.amsl.com>; Mon, 7 May 2012 06:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.196
X-Spam-Level:
X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 AOY0KiOQe0KA for <roll@ietfa.amsl.com>; Mon, 7 May 2012 06:00:40 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3F42821F85C4 for <roll@ietf.org>; Mon, 7 May 2012 06:00:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8100; q=dns/txt; s=iport; t=1336395640; x=1337605240; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GLIk1WqRUNszXxXk0dNwAixNqzkJYyVI74uuFCmGOM0=; b=kFcWSIHL7EzRU4/WOQF91WJaVT2V5+gH5EQ1LwWc5EWQkTjU4gXp7/Vd hOPaZCQHSM+mVd1uaedfzsF99Efr1hU46OhAMzP2zpoHFGhEA5boo3aME mmTgzmqXAudiwk+85pq+1kuMucBm/N+EvcAygt5OVAlgWsvPowwhVYazR U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAK3Gp0+Q/khR/2dsb2JhbABEhXKsE4ETgQeCDAEBAQMBEgEQDQRKCwIBCBoCBgYYAgICAQFVAQEEARoRCYdnBZsYjRaSK4EviVUXhGw1YwSkV4Fpgms
X-IronPort-AV: E=Sophos;i="4.75,543,1330905600"; d="scan'208";a="137223819"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 07 May 2012 13:00:39 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q47D0dMV006660; Mon, 7 May 2012 13:00:39 GMT
Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 15:00:38 +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: Mon, 7 May 2012 14:59:08 +0200
Message-ID: <BDF2740C082F6942820D95BAEB9E1A840196201E@XMB-AMS-108.cisco.com>
In-Reply-To: <4FA3C476.5000903@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D Action: draft-thubert-roll-flow-label-00.txt
Thread-Index: Ac0p7UzGKVwBLef2ShmrzvRtHI8k9gCXt24w
References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> <4FA3C476.5000903@gmail.com>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Brian E Carpenter" <brian.e.carpenter@gmail.com>, <roll@ietf.org>
X-OriginalArrivalTime: 07 May 2012 13:00:38.0868 (UTC) FILETIME=[6695D140:01CD2C51]
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: Mon, 07 May 2012 13:00:41 -0000

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.

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."

>    ...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.
 
>    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"?

> 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.

>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. 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?

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