IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 04 August 2014 14:15 UTC

Return-Path: <mcr@sandelman.ca>
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 5EA6D1B2B16; Mon, 4 Aug 2014 07:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 EHmOtWcFVU5V; Mon, 4 Aug 2014 07:15:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA5D1B2B11; Mon, 4 Aug 2014 07:15:17 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6309620029; Mon, 4 Aug 2014 10:17:38 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id E5E0F63AC9; Mon, 4 Aug 2014 10:15:15 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D3FF6638D6; Mon, 4 Aug 2014 10:15:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ole Troan <otroan@employees.org>
In-Reply-To: <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.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> <53DBF16F.2090202@gmail.com> <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 04 Aug 2014 10:15:15 -0400
Message-ID: <26363.1407161715@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/tjXlOevvMxrnikPDqPf7JJLyc28
Cc: roll <roll@ietf.org>, 6man WG <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
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: Mon, 04 Aug 2014 14:15:20 -0000

On 01 Aug 2014, at 21:58 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >> It is true that the RFC also says
    >>
    >> A forwarding node MUST either leave a non-zero flow label value
    >> unchanged or change it only for compelling operational security
    >> reasons...
    >>
    >> There is a case for arguing that flow-label-for-rpl should carry the
    >> legend "Updates: 6437 (if approved)" because it adds another exception
    >> to this sentence. There is also a case for arguing that
    >> flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6437
    >> according to Section 4 of that RFC.
    >>
    >> Either way, I don't see a problem.

Ole Troan <otroan@employees.org> wrote:
    > I see the principles in these two documents as mutually exclusive:
    > RFC6437: middleboxes can mess with the flow label -flow-label-for-rpl:
    > networks uses flow label field as an immutable protocol field

    > you can't both use the flow label as an immutable protocol field and
    > have middleboxes rewriting it.

This is my take.
Case 1:  packet is within the LLN.  No issue; the sender sets the flow label,
     and we know (by design) that there aren't any (non-RPL) middle boxes
     that need to rewrite it.

Case 2: the packet has to leave the LLN, travel across the Internet, and
     enter another LLN.
     Here the arguments about the LLN being a kind of virtual host from
     the document are relevant.  The flow label, when it crosses the
     Internet, would be immutable.  Prior to this document, the flow label
     would have been compressed out, been zero, and the DODAG root ought to
     have set it in some consistent fashion anyway.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.27.8 | Report a Bug | By Email | System Status