Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Alexander Vainshtein <[e-mail]>]

Joel, Andy and all,
FWIW I concur with your positions regarding comparison between PHP in MPLS and PSP in SRv6.

I would also like to stress that, to the best of my understanding,  in MPLS PHP is a local behavior between the penultimate and ultimate nodes with the ultimate node explicitly requesting it and the penultimate one giving the option to agree (i.e.to pop the top label when forwarding the packet) or disagree (and to swap the top label to Explicit NULL). The head-end node (and the rest of the nodes on the path) remain completely ignorant of this behavior. I.e., PHP has been introduced - and remains - truly optional.

I have not seen any specifications that would allow the tail-end node of an SRv6 path that wants to benefit from PSP to explicitly request this behavior from the penultimate one, nor do I see would the penultimate node that cannot support PSP do if requested to perform it.  The suggestions I have seen that it would be up to the head-end node (that inserts the SRH) to indicate that PSP is requested - on behalf of the tail-end node? -  look problematic to me as well.

My 2c,
Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

-----Original Message-----
From: spring <[e-mail]> On Behalf Of Joel M. Halpern
Sent: Wednesday, March 4, 2020 9:09 AM
To: Andrew G. Malis <[e-mail]>
Cc: [e-mail]; Martin Vigoureux <[e-mail]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

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 <[e-mail] 
> <mailto:[e-mail]>> 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=[e-mail]
>     <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     
> https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2
> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> 

_______________________________________________
spring mailing list
[e-mail]
https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________