Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

Ole Troan <otroan@employees.org> Thu, 06 December 2018 18:27 UTC

Return-Path: <otroan@employees.org>
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 43E86130F0D; Thu, 6 Dec 2018 10:27:59 -0800 (PST)
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 5y7H_JKR44Ar; Thu, 6 Dec 2018 10:27:57 -0800 (PST)
Received: from bugle.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 38E4B130EEE; Thu, 6 Dec 2018 10:27:57 -0800 (PST)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 5BD4AFECC074; Thu, 6 Dec 2018 18:27:56 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id ACA89ABBA60; Thu, 6 Dec 2018 19:27:52 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <a8d4f432-babc-cd48-217b-8a2540b7ce86@foobar.org>
Date: Thu, 06 Dec 2018 19:27:52 +0100
Cc: "Smith, Donald" <Donald.Smith@CenturyLink.com>, tsv-art <tsv-art@ietf.org>, OPSEC <opsec@ietf.org>, ietf <ietf@ietf.org>, "draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org" <draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3284645-1924-41B8-BD82-8B36ED44BEFE@employees.org>
References: <C4886ABA-3BBE-46AE-B2D9-9A6836D7A8BB@strayalpha.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <d6deb7af-99dd-9013-2722-8ebbe00c0b37@si6networks.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <68EFACB32CF4464298EA2779B058889D53E5B552@PDDCWMBXEX503.ctl.intranet> <a8d4f432-babc-cd48-217b-8a2540b7ce86@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/SoO2I31TwGBPZLGaTKTApNB_wWU>
Subject: Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06
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: Thu, 06 Dec 2018 18:27:59 -0000

>> This is the only study I know that did something like that. It was
>> limited to a single router and is 2 years or so old.
> this isn't a relevant study because the device in question was a software-forwarded device (i.e. no separation between control plane and forwarding plane).  The devices we're talking about in this discussion are systems which have separate management planes which can be overloaded by excess traffic from the forwarding planes, unless specific mitigating configuration is used.
> 
> Not sure why the authors of that report used a C1841 - that device dates from 2004.

The VPP project maintains lots of performance measurements for modern Intel CPUs.
https://docs.fd.io/csit/rls1810/report/vpp_performance_tests/packet_throughput_graphs/index.html

We haven’t measured extension header cost as far as I know.

Ole