Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

Tom Herbert <tom@herbertland.com> Mon, 14 March 2016 03:10 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8312D813 for <v6ops@ietfa.amsl.com>; Sun, 13 Mar 2016 20:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 EDULrKA_nD1J for <v6ops@ietfa.amsl.com>; Sun, 13 Mar 2016 20:10:58 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC6212D820 for <v6ops@ietf.org>; Sun, 13 Mar 2016 20:10:57 -0700 (PDT)
Received: by mail-ig0-x22e.google.com with SMTP id nk17so29538738igb.1 for <v6ops@ietf.org>; Sun, 13 Mar 2016 20:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RhrR9GXt2aJqDIQ+POQfI116d+MvI4zJNed0ln/Z2N0=; b=fO7aNUyIyHXSzXi+GTMxMyPg1LhxoRjRjTTuWt2SHOIA0iFqfEAnOEg1agcuxZjC3D AF5+/ynmJ+k/qlA90DS7XYFGZeVUW/CiuJk0FH7TamsX5CTANf+Cm1Sfh0Uxw4nVGGlT IeSS3sSrUr/Ae3jbl/PrnfQ7SKJpzvGFKWmaEKZxnJWKO1t/kuewct5rOgSmglBDm9ph 5JziPREb+Visk41U6VKU195/a7sk8bF8M47vGkdZRLgAWWrWHZ0IzL0obgbDtJ1gClNn ESPhGQc/fXSWWVy9fkWCpMMLgYVNBbjt3VPnM47o0FREhnfJ86E0kyaVqKKEJY4sz0pv gI/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RhrR9GXt2aJqDIQ+POQfI116d+MvI4zJNed0ln/Z2N0=; b=PXXlvHlAOV9x0mFDWKqntH6d2GYwo+/MikulRP4clRVDnIKBiSlBGnR6v/X54AymHt luLsrJ7LHZD/5Sii4aySsebKH6FxzvxADzeOTQe6iAMsj+ggCbVApocTT+vNZNsBn6oK 9IIA4WnpeO4lWbB3x4OWYs+NCQE3yQi4d5e8TydmOZs5RGurrsuXXDLaS9aOWNwVly/x csUAV3F9/f+XPSKdYniEFFIKHkLkS0SIsZ9mCdUc+Gl+swkHGwIcFOaDxQWxXY/OYhJV f29W49Ww5tBzoySNk/pDpQZlfK8rTiBt0TgapjnJozVb2SSXc7pJ31zIjx5v2EUcvCsB Y15g==
X-Gm-Message-State: AD7BkJLP2nhBkZ0w2HpT7h2CFzBxGIzSmWhDOrac1Lx8vmxg/hRsNMXxJ9IWyZI05SaiuCZv55kitgL2Pnb4Cg==
MIME-Version: 1.0
X-Received: by 10.50.23.43 with SMTP id j11mr1420450igf.94.1457925057032; Sun, 13 Mar 2016 20:10:57 -0700 (PDT)
Received: by 10.107.160.203 with HTTP; Sun, 13 Mar 2016 20:10:56 -0700 (PDT)
In-Reply-To: <CAHw9_iKqXBzFfGVA_KXWO8gt681EB9JECLjC3N8K=94pb7ShjA@mail.gmail.com>
References: <A277BE71-BD70-4AFE-97DA-F224D7DBBCB8@cisco.com> <BDA56C2D-788D-421C-B44A-1A29578F0F78@employees.org> <56E318C7.5020200@gmail.com> <F57DFD38-FC99-45AE-B41D-51B0565148B1@employees.org> <CALx6S37vNXk-g=W4n_Qvd2J=7xkgydvGEUwrhu8pRQig0hoqLg@mail.gmail.com> <1BB37194-0F5B-45C1-9DFA-87B1C28264D2@employees.org> <CALx6S37vfDcchTa5Tch+BS8rQAGgPP_EeYbVz19WBchSHTqExg@mail.gmail.com> <56E60B0D.6070600@gmail.com> <CALx6S36_Vi4XZfPvCNY42zpbXy9dXeXzwE8KedxYDhne371HHA@mail.gmail.com> <CAHw9_iKqXBzFfGVA_KXWO8gt681EB9JECLjC3N8K=94pb7ShjA@mail.gmail.com>
Date: Sun, 13 Mar 2016 20:10:56 -0700
Message-ID: <CALx6S36prYpXRExwJVLEG+sCdW9xL0V+BqRoUdwXHNZQDTnXSA@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: Warren Kumari <warren@kumari.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/DUcuJp93UtKi_eicHD2vSYcjArk>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2016 03:11:00 -0000

On Sun, Mar 13, 2016 at 8:01 PM, Warren Kumari <warren@kumari.net> wrote:
>
>
> On Mon, Mar 14, 2016 at 9:54 AM Tom Herbert <tom@herbertland.com> wrote:
>>
>> On Sun, Mar 13, 2016 at 5:51 PM, Brian E Carpenter
>> <brian.e.carpenter@gmail.com> wrote:
>> > On 14/03/2016 09:59, Tom Herbert wrote:
>> > ...
>> >> the point of using flow label is
>> >> that it eliminates the need to parse extension headers in the first
>> >> place for the ECMP use case. It would be nice if this benefit was and
>> >> the need for flow label support were better enunciated in the draft.
>> >
>> > I'll be the least likely person on the planet to disagree with that,
>> > but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd
>> > paragraphs of the Introduction) and has been in the IPv6 Node
>> > Requirements
>> > since 2011 (RFC434).
>> >
>> Brian,
>>
>> These are good descriptions flow label usage, but I don't see that
>> they set requirements as to 1) whether end host must/should/may send
>> non-zero flow labels with flow entropy 2) whether ECMP devices
>> must/should/may use non-zero flow labels as input to their hash, or 3)
>> if hosts use the flow label for EMCP must/should/may they parse any
>> deeper to extract additional L4 entropy. RFC6438 comes close and
>> answering #1, but that RFC is only applicable to tunnels.
>>
>> Pertaining to this draft, there is an observation that flow labels
>> would obviate the need for middle boxes to parse the header chain,
>
>
> I think I must have missed something somewhere / lost the plot -- which
> draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drops?
> I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at all
> -- if the *only* thing that the middlebox is doing is load-balancing / ECMP,
> then this may be true, but in many cases "middleboxes" (a term which seems
> about as vague as "thingies") are doing many other things, including
> filtering, encapsulation, translation, monitoring / measurement,
> "optimization", prioritization, etc.
>
Section 4.1.2 of draft-gont-v6ops-ipv6-ehs-packet-drops-03 discusses
ECMP. ECMP is a fundamental feature in switches, we currently rely it
on to get good load balancing across network fabrics.

> But, as I said, I suspect I've lost the plot somewhere along the line...
> W
>
>>
>> however the draft also states historically neither end nodes nor
>> routers support. It seem like there should at least be a
>> recommendation in "Future work"  section on how to attain widespread
>> support flow label.
>>
>> Thanks,
>> Tom
>>
>> >     Brian
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops