Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

Robert Raszuk <robert@raszuk.net> Wed, 15 July 2020 13:40 UTC

Return-Path: <robert@raszuk.net>
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 414023A08B0 for <ipv6@ietfa.amsl.com>; Wed, 15 Jul 2020 06:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 XyWrGAzFm4hx for <ipv6@ietfa.amsl.com>; Wed, 15 Jul 2020 06:40:51 -0700 (PDT)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 8FFB43A0C37 for <ipv6@ietf.org>; Wed, 15 Jul 2020 06:40:37 -0700 (PDT)
Received: by mail-ej1-x62d.google.com with SMTP id a1so2178724ejg.12 for <ipv6@ietf.org>; Wed, 15 Jul 2020 06:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ccNFKa0UPue53fj/0oTdYQavwGpNwFOSVTsx9pdJh/w=; b=MZxUaYlo1EY8g3leGi+sGIhi3mKCQ6EzrbQtgwlZgSNhxl0/FarLklympQEarwSOai oHCP9xF/ybnfVN2XbfSoOZ5XAB7M9dkvv19lNn9Ukscq4Il/CcuGzN9Te0/dQisXD33i b6tumXbhSXa0ZyHV24B2b0HAlgq1Y836xuLG/VMSVUv3x7G0YbVVPFci3vnTiZTD4MP7 CHm8idppROPdwVKrPUXByfutu36Tr7HxOZHFJ2t2ZsQ++DkuVQb/GjgZCleUEHipi5m+ 68fCxWsvO0LUPSR0jv3nxvGPPOHwlw+/J6RqcrBD6PMaEzfmosijGiEPAX9yAnt5P6n9 2Qxw==
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=ccNFKa0UPue53fj/0oTdYQavwGpNwFOSVTsx9pdJh/w=; b=RXPpws0V0kSbqFcU78bO0uVI4IDZk3TzAIehQr97UTnoJ/tf4TNV4VjZl1OOF/a2Zw x5JHBxWJVCePUXNjVG8jiN8ENFJF5NlQL4Ml47X5ejO56CsPG5wxKq2xc0U0v8y/12W/ sAbUS7aDpKJo7/MM7yaxu4SyO/F4nTQH2ZKPY3GWZUjF+BloU0S2dNQ39OJa4nRpSORk Wku4bjr5ILlqaSAAoiD8GXORHdbhQCH5QvDX3BlT0NTXnOrRcGuzf3n3MuTbvcl9urYy aM+pA82dUdfdS1sIVXtoAcpV++LM7drkBVSOlJGDx1x7Dp8JPqTEDnU3Y5LTqEDS+N9z OSrg==
X-Gm-Message-State: AOAM532Sp8yGBq/NmiUhAANje83K3xHOhVDFjkTEMPNG+T3vQoOuV4SD StNsLynGMaBzSFAzD2tUXf+wy/Rxgcu6QwYvcdzKjv50NK4=
X-Google-Smtp-Source: ABdhPJxpLtuds/BvnEAiYtJxpDvGPY6gKMbbZcj1CuVdrrwvjJURQFTmy0Kv3i133dH+42a1dtbouSnHB2QoGYuSZEQ=
X-Received: by 2002:a17:906:3a04:: with SMTP id z4mr9030194eje.441.1594820435956; Wed, 15 Jul 2020 06:40:35 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR05MB6348708352E1EE4421A61D63AE650@DM6PR05MB6348.namprd05.prod.outlook.com> <CALx6S34e21BLHRfx+p7agrzzDsx-M-XxB6cZQnWc-d0wqSesRQ@mail.gmail.com> <DM6PR05MB6348BCE5DDB6A8AF52D04FFAAE650@DM6PR05MB6348.namprd05.prod.outlook.com> <20200713191832.GC38490@faui48f.informatik.uni-erlangen.de> <CALx6S34TzXzHY1SK7te6-bcxO8V=kE1+o1AjL2S2oAPVTNbTBg@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE19160AFC@DGGEML532-MBX.china.huawei.com> <CABNhwV1w0JS0Rz-8KWUGAZ8o577=ciWgVXn9SLxS-sA5mjsRHA@mail.gmail.com> <20200714073612.GM38490@faui48f.informatik.uni-erlangen.de> <BYAPR11MB3207F6893A9A66F23B6564E0C0610@BYAPR11MB3207.namprd11.prod.outlook.com> <CALx6S37JxsYHJGcB0iq_96OJHqsyYR=zbBpcmnAG5+zDBVc5XA@mail.gmail.com> <CAOj+MMFZXAQJ8kUQxvbU8fWhsq5OL1AGpFeoEuq8xf+1Fr3Wuw@mail.gmail.com> <m1jvdmn-0000IzC@stereo.hq.phicoh.net>
In-Reply-To: <m1jvdmn-0000IzC@stereo.hq.phicoh.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 15 Jul 2020 15:40:27 +0200
Message-ID: <CAOj+MMFbEvPLnOAeD4Ay5fErhDjCO_8PFeX2wKQUM5dV4K19Ug@mail.gmail.com>
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000090f4d205aa7b1153"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7pC0IcFdimUzUdud2O_bnnSrMH8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 15 Jul 2020 13:40:53 -0000

> externally observable effects

But the point is that those effects will differ vendor to vendor ...
implementation by implementation ... product line by product line all for
the very same packet on the wire (or in the fiber).

One box for the very same extension header processing can be lightning fast
and the other terribly slow as some vendor can not handle it in their data
plane or perhaps just does not want to.

So what do you do ? Do you want to state that given extension must be
supported in fast path by all vendors before it is published as an RFC ?

Thx,
R.


On Wed, Jul 15, 2020 at 11:33 AM Philip Homburg <
pch-ipv6-ietf-6@u-1.phicoh.com> wrote:

> >I am watching this thread and have one question ... how any draft can
> >mandate to any implementation how it should process a packet ?
> >
> >One implementation can use 100% programmable hardware, the other can not.
> >Some process all packets in CPUs. Some may offload some processing to on
> >line card CPU vs punting it to RE/RP.
> >
> >Some may punt only first packet and then install forwarding state in the
> >dataplane so any subsequent packets are fully hardware switched.
> >
> >I am really not sure what is the value of this thread ....
>
> Maybe it is not so much about implementation details but about
> externally observable effects.
>
> If adding a particular type of extension header makes throughput go down by
> 90% then starting to use that extension header on a large scale may become
> a problem.
>
> If the first packet with a particular destination is slow then using lots
> of
> IPv6 addresses (for example one per process on a host) may overload a
> router,
> etc.
>
> So 'fast path' could be specified as within x% of the throughput/delay of a
> packet without the extension header.
>