[spring] Is srv6 PSP a good idea

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 11 December 2019 02:54 UTC

Return-Path: <jmh@joelhalpern.com>
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 4245B1200F5 for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 18:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 nENjTpIU9LxY for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 18:54:41 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 E988212006B for <spring@ietf.org>; Tue, 10 Dec 2019 18:54:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47XhNd66hYz6GChr for <spring@ietf.org>; Tue, 10 Dec 2019 18:54:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1576032881; bh=35uznBzqV6aCgZFQ2VCzD17j+6+Lh/eDei7eK672CZw=; h=To:From:Subject:Date:From; b=WACkjdwJUzIl21S/98Jxyi8RQvKb46aFtYmy3T+5LftUchUsG11hh2ghoKFvdLv6T 2OUjM9zumo8icGY42S3tQDaSuFAhtBer0fIJxOLh4ZqN6Tb/2i6Kms4BDhr4qrTU+J B6brjoDYnO7qWoTLaIC3NI7vDGSfcImYzDetmais=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47XhNd0ksHz6GChp for <spring@ietf.org>; Tue, 10 Dec 2019 18:54:40 -0800 (PST)
To: "spring@ietf.org" <spring@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <5c2a4b36-0c59-709e-23eb-00f4aa1ce52f@joelhalpern.com>
Date: Tue, 10 Dec 2019 21:54:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/rCqj2Fqufadl7zoLWoI7n6ObUkk>
Subject: [spring] Is srv6 PSP a good idea
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, 11 Dec 2019 02:54:43 -0000

For purposes of this thread, even if you think PSP violates RFC 8200, 
let us assume that it is legal.

As I understand it, the PSP situation is:
o the packet arrives at the place (let's not argue about whether SIDs 
are locators) identified by the SID in the destination address field
o that SID is the next to last SID in the SID list
o that sid is marked as / known to be PSP
o at the intended place in the processing pseudocode, the last (first) 
entry in the SRH is copied into the destination IPv6 address field of 
the packet
-> The SRH being used is then removed from the packet.

In order to evaluate whether this is a good idea, we have to have some 
idea of the benefit.  It may be that I am missing some of the benefit, 
and I would appreciate clarification.
As far as I can tell, the benefit of this removal is that in exchange 
for this node doing the work of removing the SRH, the final node in the 
SRH does not have to process the SRH at all, as it has been removed.

I have trouble seeing how that work tradeoff can be beneficial. 
Removing bytes from the middle of a packet is a complex operation. 
Doing so in Silicon (we expect this to be done in the fast path of 
significant forwarders as I understand it) requires very special 
provision.  Even in software, removing bytes from the middle of a packet 
requires somewhere between some and a lot of extra work.  It is 
distinctly NOT free.

In contrast, we have assumed that the work of processing SRH itself is 
tractable, since otherwise all of SRv6 would be problematic.  So why is 
this necessary.

Yours,
Joel

PS: Note that both the MPLS case and the encapsulation case are very 
different in that the material being removed is at the front of the IP 
packet.  Pop or prepend are MUCH easier than middle-removal (or 
middle-insertion).