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

Mark Smith <markzzzsmith@gmail.com> Mon, 14 March 2016 01:21 UTC

Return-Path: <markzzzsmith@gmail.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 09C8C12D8F7 for <v6ops@ietfa.amsl.com>; Sun, 13 Mar 2016 18:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WuPF_nkW-keV for <v6ops@ietfa.amsl.com>; Sun, 13 Mar 2016 18:21:13 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 5913512D8D5 for <v6ops@ietf.org>; Sun, 13 Mar 2016 18:21:13 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id e185so191620490vkb.1 for <v6ops@ietf.org>; Sun, 13 Mar 2016 18:21:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NI6heZ8riARMzpDSEQCo+BvF1l/nzb86B8k0GB4oS90=; b=L6bvh/RBNClLywXSFynPp6QrDMqnIRBrQd1FKhJG4w/QQIFCcjo1RXs7+wdjwCotOI 3eZf9HaBN/rLOaip7HRqRRT715RkE9JuyQS3vZDyAjkBZdSnIfKH7SKQbhxwpF62deFW a7b8GmTB2XvhIYxlWy/U0iNtJBGiNjx8phS2MqYQ/AOdWCREg4kbfYNsH0PIG7+Q7sRT PewMROF3DY/iFRrRL2p/zxsyGGgQZwJ1gmdYjakrkR4wAugvCo1M/sJvnYPlI+N3xvEE UgMSZW6ch3i8kIEFkfOSpHx/TG0GXUrPzUDansIi6rGlYagRJR+JU0JW19f8EtFGBIVs qn7Q==
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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NI6heZ8riARMzpDSEQCo+BvF1l/nzb86B8k0GB4oS90=; b=Jccwhkt65SGKsm2jzez4aHgvpm1ssTufSHbChFUEzlkLqlOU0ATf/Qy/y4Eh5z4M9S PvCdrXk1ztqT3Qg/rj6tlH7FP6EqwOTn1z2nsNWEB/+naqXx3bEBjXRnRdJMKvkeYMq+ pKEpaqfreP5QeUaCkKIwtsqKFGT6zS0ZvPs49kDR3piSKkDc7bYZv9LfxUdonI061/o5 MYR8l4d13eg0TKcTtaB9c3jtCQrKTJ9D4vYx/q1sUJ0X735PsQKkZgNn0W1nkhozYvcR 2M6SlWnh4DyAE+ZfEJ1YIwQykGl11BEIQ1y661PFgjGCLnjOSo9DrRr+e1VQdo8KiTKs Z/Ug==
X-Gm-Message-State: AD7BkJIicTvPydq3Cr1Q9F2cqh+RWpsR2KBn9KE18W8ThETJB3sDWnl1iRwwrj7h1Fx0qkRuuZEt1f+Ft0lxEA==
X-Received: by 10.31.128.82 with SMTP id b79mr22441958vkd.47.1457918472444; Sun, 13 Mar 2016 18:21:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.5.68 with HTTP; Sun, 13 Mar 2016 18:20:42 -0700 (PDT)
In-Reply-To: <8EE27F32-CE30-459B-ACED-4ACA8AA6E79B@foobar.org>
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> <56E5D38F.7080507@foobar.org> <CAO42Z2wF-UxxMMc5-2rrCSbGqQPUCEF64wRK9-=S84EbD0khjQ@mail.gmail.com> <8EE27F32-CE30-459B-ACED-4ACA8AA6E79B@foobar.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 14 Mar 2016 12:20:42 +1100
Message-ID: <CAO42Z2wXC9pdV9MzPvJFVKt2O8ooBaSkaYi4=egQAC-Zk095Cg@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ABlG7Q1BnUwAbPR4m2mfmilfiw4>
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 01:21:15 -0000

On 14 March 2016 at 10:30, Nick Hilliard <nick@foobar.org> wrote:
> On 13 Mar 2016, at 23:05, Mark Smith <markzzzsmith@gmail.com> wrote:
>> So in the medium term, the specific use of LAG and/or ECMP to bundle
>> links, and their desire to look at transport layer headers, might
>> disappear. I came across work on "Flex Ethernet" the other day, and
>> one thing it seems to be looking to do is to solve the problem of link
>> bundling without the dependencies on layer 2/3/4 field values.
>
> flexethernet will solve a different set of problems to what we're talking about here.

So it might be worth enumerating all of them, as bullet #2 sounds like
the problem people are commonly solving with LAG and ECMP, and one
that has been mentioned in this discussion. From the Flex Ethernet
Implemention Agreement:

"5.3
Sample Applications
FlexE can support a variety of applications. A non-exhaustive list includes:
* Router to Transport Connection (more examples below).
* Intra-Data Center “Fat Pipe” application: bonded PHYs for flows exceeding the
PHY rate, or carrying traffic that doesn’t distribute efficiently with LAG.
* Generalized MLG applications, e.g., an n × 100G PHY as an umbilicus to a
satellite shelf of lower rate ports."


> I don't see any point in the foreseeable future where lags and ecmp will stop being relevant.
>

If there is a solution that costs the same or less than them, and
doesn't depend on the presence and/or distribution of layer 2/3/4
field values, I think they will stop or become far less relevant.

Those networks that rely on LAG or ECMP aren't general purpose any
more, as they've been optimised for certain link and upper layer
traffic profiles.

If you're originating the traffic, you're in control of the traffic
profile, so you can ensure the optimisation continues to work. If
you're not originating the traffic, there is always a risk the
optimisation will fail and there is nothing you can do to prevent it -
your customer probably believes they're getting X M/Gbps of any type
of traffic, rather than X M/Gbps of type Y traffic that you've
optimised for, and they'll probably be angry if you try to raise their
price to cover you increase bandwidth costs to deal with their
non-optimal traffic.

Getting the IETF to prohibit the non-optimal traffic avoids the
possibility of dealing with angry customers or increased network
costs. I don't think it is intentional, however I think that is what
is in effect happening here.

The optimisation is understandable, and is caused by the costs imposed
by Ethernet's 10x increments. FlexE seems to be specifically
addressing that problem, by supporting bundling and therefore smaller
link increments, without making assumptions about upper layer header
presence, location and field value distribution.

Regards,
Mark.





> Nick
>
>> "What is FlexEthernet?"
>> http://www.ethernetsummit.com/English/Collaterals/Proceedings/2015/20150415_1C_Gustlin.pdf
>>
>> "Flex Ethernet Implementation Agreement"
>> http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf
>>
>> Regards,
>> Mark.