Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Tom Herbert <tom@herbertland.com> Sat, 20 February 2021 15:32 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA543A14E9 for <tsv-art@ietfa.amsl.com>; Sat, 20 Feb 2021 07:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 W6w9Dw_PphZm for <tsv-art@ietfa.amsl.com>; Sat, 20 Feb 2021 07:32:41 -0800 (PST)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 D5EC83A14E8 for <tsv-art@ietf.org>; Sat, 20 Feb 2021 07:32:40 -0800 (PST)
Received: by mail-ej1-x62b.google.com with SMTP id w1so21353143ejf.11 for <tsv-art@ietf.org>; Sat, 20 Feb 2021 07:32:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BccZQrZ9Xk9bczPEVA36PM0NgOh8D3x3T5Ikf2zIAWk=; b=wV9QT8vsWzvDnhSxTXtgL6wXAS2obmPIPGPBdH+Qef5rjTqjeWKLR/+01fk9eGB+bD w2i1fwJqijF1oB5SIOMTj+v32T+bwE4T2w9bWuM19YWOLX4UeglMwfjPTSIudQvbLQEh pP2lYvW1PcMnlUEjpSfCQMsG3DioD+KwjTxZ+k/v9b/PVA3FL7NCLg2makexNd29Ffno SojPI7GOMW3oFLmCffQxt55xuvQpbXIMeUG/n9hbJhkUuO1TjqjeMBCqvPeqR30rKuhf ya7B0wQuhbPB7aKVg0Oe+Dj9J/NBiLvmFI2UyPdQgJ7eRYxtU81ovQwVuGSWfnWDZro8 4c6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BccZQrZ9Xk9bczPEVA36PM0NgOh8D3x3T5Ikf2zIAWk=; b=Fq+qKtbUoBRwcDtFweSNSfrsaZo7wso1QIvTAW3KNuGf/afQL2Vp1JknHQqhYb2Azc wtsMTG3tp5AqCFcGuqWQJH4Tmuiq19ncvLEqjNknaQBrMBkZVu8d2vFDq9fbqgElSwJc FWuG1t2I8Y4nqBWa3Xd1neRCH2LGQGjNv8kHd3CkNe5eQS0/1occt2O730nCiIbHpTCZ bdWnpOumyX7HKCF31kdVpu6KsLGKUmfw8xs0S4RlEa/O5tu2EjrXkFeTF6XGEZ5nFo+6 WN2eo74WKA5tTQSDc0nOlImO06tkeTjDI51UEWrY3UikZi9i7l7A+0zP0fX6n1tLFz4g HwQw==
X-Gm-Message-State: AOAM532jd3yZ9LgQxL0B2tP0svJKq5ElQP5wX3Yjra66ypLPqjPl8M8f OrgHr8fFFgn+G+0excQtoagw4Vrra/M1ph5LYfl8Xg==
X-Google-Smtp-Source: ABdhPJwy6xcuDQvWHN/l+UOwxtxdZ9KEurPC1q0aKHN5p8n+BiY48heoXvkXIguSAksyw3oZG8QbYeuh0ZfKV+VTwIA=
X-Received: by 2002:a17:906:4442:: with SMTP id i2mr13769184ejp.41.1613835159104; Sat, 20 Feb 2021 07:32:39 -0800 (PST)
MIME-Version: 1.0
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com> <0e377231-c319-2157-30a0-759e2f96a692@gmail.com> <5f464f17-85ed-f105-35f9-02f35d04aed2@si6networks.com> <CALx6S364zGbq_HZNNVEaJHnHccuk4Zau2DXhmaVYbwnYQc-5bw@mail.gmail.com> <1847e8e3-543f-5deb-dd14-f7c7fa3677db@si6networks.com>
In-Reply-To: <1847e8e3-543f-5deb-dd14-f7c7fa3677db@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 20 Feb 2021 08:32:28 -0700
Message-ID: <CALx6S34TPppMRJrOvyJ05LLeRvv+S51pQHJnzZDKk-qOdsF0AA@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsv-art@ietf.org, last-call@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/m4SrGnSsWf36lhRYjlcwkURgmOA>
Subject: Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Feb 2021 15:32:43 -0000

On Fri, Feb 19, 2021 at 10:09 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> Hi, Tom,
>
> On 19/2/21 18:13, Tom Herbert wrote:
> [....]>> xor add this:
> >>
> >>     [RFC7098] discusses how the IPv6 FLow Label can used to enhance layer
> >>      3/4 (L3/4) load distribution and balancing for large server farms.
> >>
> >> right after:
> >>      Thus, ECMP and Hash-based Load-
> >>      Sharing should be possible without the need to process the entire
> >>      IPv6 header chain to obtain upper-layer information to identify
> >>      flows.
> >>
> > I don't why this is only a "should".
>
> This is not a requirement. We're mostly indicating possibility.
>
>
> > Hashing of three tuple for load
> > balancing works as described as evident by the fact it is in wide
> > deployment (consider it's been in Linux stack for it's internal load
> > balancing for several years and there's now over a billion devices in
> > the world that do this).
>
> LB based on the FL relies on:
> * Appropriate implementation of the FL
> * Use of the FL in load balancers
>
> There has been (and still is) an interesting mix of cases where one or
> both of this simply do not happen.

Fernando,

On the other hand, there are use cases where it does work and is in
deployment; in fact, there are use cases where it's the *only* way to
do in flow classification on packets. The implicit requirement of this
draft here is that packets have port numbers in plain text, however
that is not possible in no-first fragments, tunnel mode IPsec,
tunnling protocols the routers don't understand, etc.

With regards to extension headers, the presumed problem isn't that the
port numbers are present, it's that some, not all, routers have
limited capabilities to parse over EHs to find the transport headers.
This is reflected in the statement: "If an IPv6 header chain is
sufficiently long that it exceeds the packet look-up capacity of the
router, the router might be unable to determine how the packet should
be handled, and thus could resort to dropping the packet." It's not to
me clear what "sufficiently long" means; in particular, such a
statement isn't helpful to the host stack developer trying to figure
out if the packets they're creating will be properly forwarded.  For
the purpose of providing use guidance to the host stack developers,
can you please clarify exactly what "sufficiently long" is?  For
instance, is it reasonable to expect that modern routers should be
able forward packets that contain sixty-four bytes of Destination
Options, or Routing Header, or HBH Options? Note that RFC8504 and
RFC8883 do discuss processing limits being exceeded in terms of the
protocol considerations (in fact, RFC8504 recommends a specific
default limits on the maximum number of HBH and DestOpt options a host
will process in order to mitigate the "DoS due to processing
requirements" issue raised in 7.4 of this draft).

Tom

>
> See e.g.: https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/
>
> We're just the messenger here....
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>