Andy,
AFAIKS, the only use case PSP is to accommodate SRv6 egress nodes that:
* Can process an SRv6 SID that appears in the IPv6 Destination Address
* Can process the SRH with Segments Left equal to 0
* But cannot process the SRH with Segments Left equal to 0 at high speed
I am not aware that any such device exists. Does anybody know of one?
Ron
From: Andrew G. Malis <agma...@gmail.com>
Sent: Tuesday, March 3, 2020 6:28 PM
To: Robert Raszuk <rob...@raszuk.net>
Cc: Ron Bonica <rbon...@juniper.net>; bruno.decra...@orange.com;
spring@ietf.org; Joel M. Halpern <j...@joelhalpern.com>; Martin Vigoureux
<martin.vigour...@nokia.com>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
MPLS PHP was invented to solve a particular issue with some forwarding engines
at the time - they couldn't do a final pop followed by an IP lookup and forward
operation in a single forwarding cycle (it would impact forwarding speed by 50%
best case). 20 years later, is this still an issue at the hardware/firmware
level? If so, affected implementers should speak up, otherwise there's really
no need for PSP.
Cheers,
Andy (who was there at the time)
On Tue, Mar 3, 2020 at 3:11 PM Robert Raszuk
<rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote:
Hi Ron,
> MPLS PHP is a clear case of de-encapsulation.
Purely looking at technical aspect that is not true at all.
MPLS PHP does not remove label stack. MPLS PHP is just used to pop last label.
After MPLS PHP packets continue with remaining label stack to the egress LSR
(example L3VPN PE).
> I don't think that you can compare MPLS PHP with SRv6 PSP
But I agree with that. Both operations have very little in common from packet's
standpoint or forwarding apect. Well maybe except "penultimate" word :)
Kind regards,
R.
On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>
wrote:
Folks,
I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP is a clear
case of de-encapsulation. We do that all the time. In SRv6 PSP, we are removing
something from the middle of a packet. That is quite a different story.
Ron
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$>
Juniper Business Use Only
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
