Re: [spring] Is srv6 PSP a good idea

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Joel,

Regarding PSP as an optional behaviour in a standard:
From an implementation perspective I don’t see a big cost.
From a deployment perspective PSP is enabling new use-cases. Hence benefits.
From an operational perspective, 4 of the existing deployments have chosen to use PSP.

Regarding ASICs complexity:
It's a bold statement to say "non trivial undertaking" when several vendors support PSP at linerate in a broad set of different chipset families. 
Deep termination or chopping was complex several years ago. This is no longer an issue. As pointed out in my previous email, this has been deployed using ASICs that started shipping 3 years ago (and were designed much earlier).
To go even further: I have not worked with any ASIC currently available on the market that supports SRH processing and cannot do PSP at linerate. Please bring one to the table if you know one. 

By the way: you brought up this same topic two months ago at the mailer. At that time we got to the same conclusion: it is not complex.
https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0

Thanks,
Pablo.

-----Original Message-----
From: "Joel M. Halpern" <[e-mail]>
Date: Thursday, 12 December 2019 at 06:48
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [spring] Is srv6 PSP a good idea

    There are several aspects of your reply that leave me wondering.
    
    First, optional behaviors in a protocol spec have signficiant cost.  So 
    if they are nbot needed, we generally prefer not to have options.

    Second, I am confused by your comments about complexity.  From my 
    conversations with multiple ASIC folks at different companies, middle 
    removal is generally not a trivial undertaking.  My congratulations to 
    the Broadcom folks for achieving it.
    Even if it is relatively simple, it is pretty clear that middle removal 
    of an SRH is significantly more effort than skipping an exhausted SRH. 
    particularly when such skipping is in a device inside the SRH domain. 
    (Since it is outside the domain, one would have encapsulated, and 
    removed the entire encapsulating header, which is indeed simpler.)
    
    Yours,
    Joel
    
    On 12/11/2019 3:11 PM, Pablo Camarillo (pcamaril) wrote:
    > Joel,
    > 
    > 1.- The use-case for PSP has already been provided at the mailer. There are scenarios where it provides benefits to operators.
    > 
    > 2.- The PSP behavior is optional. It is up to the operator in his deployment to decide whether to enable it or not at one particular router.
    > Similarly, a vendor may decide not to implement it. The PSP behavior has been implemented by several vendors and deployed (see the srv6 deployment draft).
    > 
    > 3.- A network may have PSP enabled at some nodes and not at others.  Everything is still interoperable and works fine.
    > 
    > 4.- PSP is not a complex operation in hardware (doable at linerate on existing merchant silicon).
    > Example: It has been implemented and deployed on Broadcom J/J+. If I recall correctly Broadcom Jericho+ started shipping in March 2016! PSP is supported on this platform at linerate with no performance degradation (neither PPPS nor BW).
    > Given that this is doable in a platform from more than 3 years ago, I fail to see how you need "very special provision" to do this.
    > 
    > Is it really something that horrible to provide freedom of choice to the operators deploying?
    > 
    > In summary, it can be implemented without any burden in hardware and deployment experience prove this is beneficial to operators.
    > 
    > Thanks,
    > Pablo.
    > 
    > -----Original Message-----
    > From: spring <[e-mail]> on behalf of "Joel M. Halpern" <[e-mail]>
    > Date: Wednesday, 11 December 2019 at 03:55
    > To: "[e-mail]" <[e-mail]>
    > 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.
    >      
    >      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).
    >      
    >      _______________________________________________
    >      spring mailing list
    >      [e-mail]
    >      https://www.ietf.org/mailman/listinfo/spring
    >      
    >