IETF Logo Mail Archive

Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

Ole Troan <otroan@employees.org> Fri, 20 October 2017 14:58 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A0113421F for <ipv6@ietfa.amsl.com>; Fri, 20 Oct 2017 07:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 d165_ssrZQNG for <ipv6@ietfa.amsl.com>; Fri, 20 Oct 2017 07:58:23 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1327D13420F for <ipv6@ietf.org>; Fri, 20 Oct 2017 07:58:23 -0700 (PDT)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D1B1A2D5065; Fri, 20 Oct 2017 14:58:21 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D7EA32006ECE7C; Fri, 20 Oct 2017 16:58:16 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_40ED0137-0798-46C3-8797-29937C593A68"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]
Date: Fri, 20 Oct 2017 16:58:16 +0200
In-Reply-To: <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man WG <ipv6@ietf.org>
To: Toerless Eckert <tte@cs.fau.de>
References: <CALx6S341v1zd2Q9bts8-zrKxU59kieJTJJ=nHQ5w4oQZg=t_cA@mail.gmail.com> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <CALx6S37wLvuJ9tUGjYmzm63eq_bxq0jXSEgfCtH_2i74SvrbLA@mail.gmail.com> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <CALx6S34VRS4GumsFSqN8uDkv4TOLC8q+rOvyN=evUk83KPeHHg@mail.gmail.com> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <CALx6S36s_SoTqpPo=jXmrFC+pgUkEmF8UB_sx_0zGcK-G8JeTQ@mail.gmail.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jTeCNAU9hajMpzCzYSyRKhDMwl8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Oct 2017 14:58:24 -0000

Toerless,

>>> Problem with flow label is same as with hop-by-hop option: burned because
>>> nobody should dare use it for something useful with all the inconsistent
>>> code out in the field.  Nothing against redefining it (with new encoding)
>                                                          ^^^^^^^^^^^^^^^^^^^
>> There is no encoding. It's 20 opaque bits (and always has been). Please
>> read https://tools.ietf.org/html/rfc6437.
> 
> Sorry, lame use of words. Meant to say "stronger definition of DO and DONTs
> which may include new semantics". I never tried to analyze the state of
> affairs on flow label as i did for router alert. Just taking it from what
> i heard, last from Joel at the pechakucha.

Right. If we take Joel's findings, then it appears the conclusion is that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too high probability for failure. It would be very nice to have that fixed. Until then, we're forcing routers to parse transport headers.

Best regards,
Ole

v2.23.0 | Report a Bug | By Email