Re: [spring] Is srv6 PSP a good idea

Sander Steffann <> Wed, 26 February 2020 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 248653A1345; Wed, 26 Feb 2020 12:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kyy262fuSUby; Wed, 26 Feb 2020 12:07:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A978C3A1347; Wed, 26 Feb 2020 12:07:53 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0F064C; Wed, 26 Feb 2020 21:07:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1582747669; bh=bV3K4wK2n5OHxDbvCE7 9+nbwaZf0BlfsY9KiNhw1cEE=; b=TG2c6tIBlwxvbwag8Or7oTmc/hNHW/dFXuw /KFDwmwU4dh/CGsPArDP8SW4FXaUJhealhO/Ut5obo2+MiANf2s9JsKXbD9/AGju dtrLdsyett9sCO928QtqE9EWHr/bkwLbTdB1W1s8XK1JIGa32I4sTxTMdzTk9/PT 8FwBHKdE=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id LK0z4EMoYzJn; Wed, 26 Feb 2020 21:07:49 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:ce80:e1db:2079:7e02:1779] (unknown [IPv6:2a02:a213:a300:ce80:e1db:2079:7e02:1779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 471EF3C; Wed, 26 Feb 2020 21:07:49 +0100 (CET)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_9C3D0564-3375-42F0-AE0C-8AEF7914963B"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Subject: Re: [spring] Is srv6 PSP a good idea
Date: Wed, 26 Feb 2020 21:07:44 +0100
In-Reply-To: <>
Cc: Sander Steffann <>, "" <>, 6man WG <>
To: Robert Raszuk <>
References: <> <> <>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2020 20:07:59 -0000

Hi Robert,

> No worries ... three IPv6 musketeers have already presented themselves well to this discussion. This was just one more demo of it. No need to apologize - at least me :)
> And while you can call someone's opinion the way you like - the fact that SRv6 builds on top of IPv6 does not make it automatically IPv6 extension.

Yes it does. It uses the IPv6 header with IPv6 extension headers with IPv6 addresses. SRv6 packets are IPv6 packets, and therefore have to follow IPv6 semantics. If you want to create an exception to that, then RFC8200 is the place to be.

> My perhaps subtle point was that while politically it has been sold like minor IPv6 extension from technical point it does not need to be positioned like one. The sole fact that it reuses the same ethertype does not make it an extension.

Oh yes, it also uses the IPv6 ethertype. I almost forgot that one. SRv6 is still based on an IPv6 *Extension* Header.

> Now as I have already been through my round of circular explanations in the previous months - now I just sit and watch how it goes round and round again.

Happy to hear you're giving up on pushing a draft that violates RFC8200 by claiming that SRv6 doesn't have to follow the RFC that it is based on because SRv6/NP is special, SRv6/NP is not really IPv6, IPv6 addresses as used by SRv6/NP aren't really IPv6 addresses etc.

Instead of trying to squeeze your way through with all these excuses, why not simply acknowledge the comments that PSP violates RFC8200, and either work on updating RFC8200 or removing PSP (whose benefits have been questioned on their own)? Work with this community and the operators to gain actual consensus, not some parody of consensus by trying to bend the rules when you don't like them.

You could easily get my consent by removing PSP from the draft. It violates RFC8200 and for what? What makes PSP so important that the draft would be unworkable without it? Why do you rather play these games than adjust the draft based on honest feedback? What hidden agendas are there? Because based on everything I have seen PSP is a minor feature that is implemented in a very controversial way. Why is it worth all this nonsense? (and I mean nonsense in the literal way: it really doesn't make sense to me)