Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Sander Steffann <sander@steffann.nl> Wed, 04 March 2020 22:36 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63D93A0B2A for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 14:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=steffann.nl
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 HBHz4bplQ8Sn for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 14:36:14 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217993A0B08 for <spring@ietf.org>; Wed, 4 Mar 2020 14:36:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id D73164C; Wed, 4 Mar 2020 23:36:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:date:date:message-id:subject:subject:mime-version:from :from:content-transfer-encoding:content-type:content-type :received:received; s=mail; t=1583361370; bh=5OS+aF1Ix0cE1H9Hj/i +b4omAm2DSsuCzW/CWka8cHw=; b=IFV67tx64AMdvusLMNiKuHtOWYM33dSz/dg U92tWKbVkPrbcE5Lqkrw6/1KPI5GY+zaY2uTScET4HZX1xkYPV9xq0s2Ah8geHdC hbn+k74dY1E4EaR9e+bbGNTE5cKVn/97nL/BzwvSEiYU38tQIXnVQsABmYZDqKMi FyMwIJlw=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jeRKTOMv8Scn; Wed, 4 Mar 2020 23:36:10 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:ce80:15f6:a164:943c:a5c8] (unknown [IPv6:2a02:a213:a300:ce80:15f6:a164:943c:a5c8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id A1AAC3C; Wed, 4 Mar 2020 23:36:10 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Mime-Version: 1.0 (1.0)
Message-Id: <785D1954-9D35-4044-B601-A48CD3AA8E28@steffann.nl>
Date: Wed, 4 Mar 2020 23:36:09 +0100
Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
X-Mailer: iPhone Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/S4-rv9FJKWRwOA3vKu9c4D_sgOQ>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 22:36:19 -0000

Hi,

> I guarantee you there is case the performance penalty is more than 90%, only if the box send the IPv6 packet with RH or EH to the slow path (just to be compatible with RFC8200)!
> And I think that's common even for not very old box.

So you are saying that we're going through all these discussions about PSP, just for boxes where the vendor can implement the SR control plane, line rate decapsulation, but not to skip over RH in the case when remaining segments is 0 except by punting it to the control plane?

That sounds like some really backwards hardware or lack of implementation effort...

I understand that fully handling RH might be tricky for some platforms, but this discussion is only applicable to the special case where remaining==0.

I get the feeling that we're adding a protocol feature just to save a few bytes of code in the fast path. That sounds like a very bad tradeoff/engineering decision to me...

Cheers,
Sander