Re: [spring] Is srv6 PSP a good idea

[Gyan Mishra <[e-mail]>]

All

The concept of PHP “Penultimate Hop POP” and UHP “Ultimate Hop POP” have
historical meaning as well as real consequences as far as a packet walk
through an mpls network.

>From a historical perspective which is really the correct way to look at
PHP in the MPLS world was designed by the developers of MPLS 25+ years ago
for the following reason.  Back then,  asic chipsets used by the MPLS
forwarding plane did not have the horsepower to pop the topmost ldp label
along with all services bottom of stack labels.

For that reason alone the MPLS developers back then came up with the PHP
concept.

In essence what that did was allow the ldp topmost label to be popped one
hop prior to the egress LSR PE node on the egress P node.

What that did was offload the entire burden of popping the entire label
stack done on the PE ultimate hop router to now be offset by one less label
to pop.  Back then that was a big deal and important for processing label
switched packets at high rates.

PSP became the default standard across all vendors and platforms “implicit
null label reserved value 3”

There was a double edged sword that came about from the PSP process.

As mpls became mainstream so did customer SLA and so end to end QOS became
the forefront importance to all service providers.

The major problem in the MPLS world that came about with PSP is that when
you pop that label at the egress PE 1 hop before the ultimate hop.  What
that did is the PE-P link the packet is forwarded without the ldp topmost
label intact preserved which contained the EXP bits for end to end QOS
scheduling.

A workaround fix to this issue was to institute a new feature called
“explicit null reserved label value 0”.  This was implemented using a QOS
policy called “pipe mode” that allowed the topmost label to now be
preserved and “ultimate” hopped which we today call UHP “Ultimate Hop POP”.

Another industry development that came about to get around the complexity
of pipe mode QOS policy to UHP was a enlightening concept but unfortunately
did not work for all use cases.

So the new feature that came about was the ability to schedule outbound on
each node in the operator MPLS core on both  on the topmost label EXP bits
of the topmost was present as well as on the preserved  inner header dscp
this dual PHB scheduling capability based on which outer header existed or
didn’t exist.   This worked for enterprises where you have trust
relationship with your customer or are a customer of yourself.

In the service provide area UHP ultimate hopping to preserve the ldp
topmost label became the general rule of thumb golden standard to meet
customer SLAs of end to end QOS.

Coming back full circle to SRV6.

The concept of PSP was added to SRv6 I believe to provide parity for
operators learning curve as well as similarities as SRV6 would be the
replacement to mpls.

Based on what I have stated above providing history of PHP and how it came
about ; and now adding this truly legacy function to a NG protocol such as
SRv6 to me does not make sense.

I don’t see the necessity to add just for the sake of adding or providing
parity to a soon to be legacy protocol.

I would like to see some technical justification as to why PSP is necessary
with our modern day routers to this in the PR spec.

Gyan





On Sat, Dec 14, 2019 at 10:08 PM Mark Smith <[e-mail]> wrote:

>
>
> On Fri, 13 Dec 2019, 07:50 Ron Bonica, <rbonica=
> [e-mail]> wrote:
>
>> Pablo,
>>
>> I am not convinced the benefit derived by the ultimate segment justifies
>> the price paid by the penultimate segment. Specifically,
>>
>> - the ultimate segment benefits because it doesn't have to skip over the
>> SRH with SL == 0
>> - in order for the ultimate segment to derive this benefit, the
>> penultimate segment needs to remove bytes from the middle of the packet and
>> update two fields in the IPv6 header
>>
>> As Joel said, we typically don't add options (i.e., complexity) to a
>> specification unless there is substantial benefit.
>>
>
>
> It's also contrary to the SPRING charter:
>
> "SPRING WG should avoid modification to existing data planes that would
> make them incompatible with existing deployments. Where possible,
> existing control and management plane protocols must be used within
> existing architectures to implement the SPRING function."
>
> The only time significant changes to IPv6 operation should be proposed are
> if what is being tried to be done is impossible using existing mechanisms,
> or there is a very significant benefit that far outweighs the cost and
> consequences of changing a protocol that is decades old and already has
> millions of deployments.
>
> When significant changes to a protocol are needed or would provide
> significant advantages, that's a sign that either (a) it's the wrong
> protocol to try to use or (b) it's time for a new version of the protocol.
>
> The 'man' in 6man stands for 'maintenance'. IPv6 is way past the
> development stage (that was 1995 and earlier).
>
> It seems SPRING is commonly taking a "new protocol development" approach
> regarding IPv6, rather than "use an existing protocol" approach. This "new
> protocol development" approach is costing a lot of time and effort due to
> long debates that really shouldn't be needed if the SPRING charter was
> being followed, and IPv6 was just being used rather than attempted to be
> being redeveloped.
>
> Regards,
> Mark.
>
>
>
>>                                                     Ron
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> From: spring <[e-mail]> On Behalf Of Pablo Camarillo
>> (pcamaril)
>> Sent: Wednesday, December 11, 2019 3:12 PM
>> To: Joel M. Halpern <[e-mail]>; [e-mail]
>> Subject: Re: [spring] Is srv6 PSP a good idea
>>
>> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
>>
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant