Re: [spring] Is srv6 PSP a good idea

"Voyer, Daniel" <> Fri, 13 December 2019 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65DDA1200E6 for <>; Fri, 13 Dec 2019 14:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hcLtBOPaSiuF for <>; Fri, 13 Dec 2019 14:14:11 -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 14B231200D6 for <>; Fri, 13 Dec 2019 14:14:10 -0800 (PST)
Received: from (HELO ([]) by with ESMTP; 13 Dec 2019 17:14:09 -0500
Received: from (2002:8eb6:120e::8eb6:120e) by (2002:8eb6:120e::8eb6:120e) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Dec 2019 17:14:09 -0500
Received: from ([fe80::615a:b316:d0f6:8b6c]) by ([fe80::615a:b316:d0f6:8b6c%22]) with mapi id 15.00.1473.003; Fri, 13 Dec 2019 17:14:09 -0500
From: "Voyer, Daniel" <>
To: "Xiejingrong (Jingrong)" <>, "" <>
Thread-Topic: [EXT]Re: [spring] Is srv6 PSP a good idea
Thread-Index: AQHVsgKjYcjkTdPeG0y33ySTkvbV/Q==
Date: Fri, 13 Dec 2019 22:14:08 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [spring] Is srv6 PSP a good idea
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Dec 2019 22:14:13 -0000

I agree 100% with Jingrong,

PSP allows us to bring SRv6 to legacy PE devices that are not capable of processing the SRH in the dataplane, but are capable of supporting SRv6 in the control plane.
See this example:
I am streaming traffic from a server to a customer;
The ingress PE (near the server) encapsulates the packet and adds an SRH with a low-latency list of segments;
The penultimate node in the SRH executes PSP;
The egress PE (near the customer) decapsulates the IPv6 header and forwards the inner packet to the customer.
We can include SLA unidirectionally from the server to the customer even though that the egress PE has a legacy ASIC. Legacy equipment are a reality and are not easy to replace, hence interoperability with brownfield is key for any innovative approach.


On 2019-12-10, 11:15 PM, "spring on behalf of Xiejingrong (Jingrong)" < on behalf of> wrote:

    I think it's a good idea.
    Nothing new, but benefits that people have already said seems notable to me.
    (1) reduce the load of final destination. This benefit can be notable for the following sub reasons.
    (1.1) final destination tends to have heavy load. It need to handle all the EHs and do the delivery/demultiplex the packet to the right overlay service.
    (1.2) example 1, the final destination may need to handle the DOH after the RH.
    (1.3) example 2, the final destination may need to do the assembly of fragmented packets.
    (1.4) example 3, the final destination may need to do AH/ESP after the Fragmentation Header.
    (1.5) example 4, the final destination may need to deliver the packet to the right overlay service.
    (2) support the incremental deployment when final destination(s) do not process/recognize SRH. This benefit can be notable for the following sub reasons.
    (2.1) A core router may (fan-out) connected with a big number of low-end routers that do not support SRH but support tunnel-end/service-demultiplex function of SRv6.
    -----Original Message-----
    From: spring [] On Behalf Of Joel M. Halpern
    Sent: Wednesday, December 11, 2019 10:55 AM
    Subject: [spring] Is srv6 PSP a good idea
    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.
    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).
    spring mailing list
    spring mailing list
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints