In this case, it is even less relevant. The PSP for SRv6 does not
remove the double-processing. It merely removes the need to ignore the
SRH at the ultimate node.
Yours,
Joel
On 3/3/2020 6:27 PM, Andrew G. Malis wrote:
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
