Subject: [spring] Is srv6 PSP a good idea

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Dec 2019 21:54:37 -0500

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).

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 11 Dec 2019 04:13:21 +0000

I think it's a good idea.
Nothing new, but benefits that people have already said seems notable to me.

(1) reduce the load of final destination. This benefit can be notable for the following sub reasons.
(1.1) final destination tends to have heavy load. It need to handle all the EHs and do the delivery/demultiplex the packet to the right overlay service.
(1.2) example 1, the final destination may need to handle the DOH after the RH.
(1.3) example 2, the final destination may need to do the assembly of fragmented packets.
(1.4) example 3, the final destination may need to do AH/ESP after the Fragmentation Header.
(1.5) example 4, the final destination may need to deliver the packet to the right overlay service.

(2) support the incremental deployment when final destination(s) do not process/recognize SRH. This benefit can be notable for the following sub reasons.
(2.1) A core router may (fan-out) connected with a big number of low-end routers that do not support SRH but support tunnel-end/service-demultiplex function of SRv6.

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, December 11, 2019 10:55 AM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Dec 2019 09:15:37 -0500

Thank you Jingrong for providing some of the other motivations.  Two 
furhter comments.

As far as I know, the only savings on the end box is the processing for 
noticing the SRH, noticing that SL is 0 and there are no relevant TLVs, 
and then moving on.

If the actual end device is not part of the SR domain, I assume that 
encapsulation would have been used, so I think it is reasoanble to 
assume that in the PSP case the end device is SR capable.

Do you have any comments on what appears to be the significant increase 
in complexity on the device performing PSP?  The question I am trying to 
get at is about the tradeoff, which needs one to evaluate both sides.

Yours,
Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:11:33 +0000

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 <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
Date: Wednesday, 11 December 2019 at 03:55
To: "[email-masked]" <[email-masked]>
Subject: [spring] Is srv6 PSP a good idea

    

    
    Yours,
    Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:11:58 +0000

Jingrong,
 
> Nothing new, but benefits that people have already said seems notable to me.

Agreed.

Cheers,
Pablo.

-----Original Message-----
From: spring <[email-masked]> on behalf of "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wednesday, 11 December 2019 at 05:15
To: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

    
    
    Thanks
    Jingrong
    
    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Wednesday, December 11, 2019 10:55 AM
    To: [email-masked]
    Subject: [spring] Is srv6 PSP a good idea

    

    
    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Dec 2019 00:48:07 -0500

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

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Dec 2019 20:50:23 +0000

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.

                                                    Ron

Juniper Business Use Only

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Wednesday, December 11, 2019 3:12 PM
To: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Is srv6 PSP a good idea

Joel,

Thanks,
Pablo.

-----Original Message-----
From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
Date: Wednesday, 11 December 2019 at 03:55
To: "[email-masked]" <[email-masked]>
Subject: [spring] Is srv6 PSP a good idea

    

    
    Yours,
    Joel

    _______________________________________________
    spring mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$ 

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$

---

From: David Allan I <[email-masked]>
Date: Thu, 12 Dec 2019 21:40:08 +0000

Hi Pablo

Looking over the benefits list, Irrespective of any other merits, I'd actually suspect that 1.3/example 2 is kind of a specious benefit. 

My reasoning is if fragmentation has occurred, and the NSH has been replicated in all fragments and needs to be removed from each fragment by the penultimate SR. This offers minimal benefit to the reassembly function at the ultimate Segment Router.

IMO SRH removal at an intermediate device is a more complex operation.  In a simplistic description of operation it adds at a minimum, parsing and a memcpy of the payload. In effect it replaces Start_of_payload_ptr += length (SRH) at the ultimate SR with memcpy (start_of_SRH_ptr, start_of_SRH_ptr+length(SRH), length(SRH)) at the penultimate SR.

So skipping over the exhausted SRH would appear to be trivial compared to the work at the penultimate segment router to remove it entirely. IMO it does not offer benefits equivalent to PHP in MPLS

The same argument could be considered without fragmentation, but fragmentation becomes a particularly ugly example.

Hope this helps
Dave

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Wednesday, December 11, 2019 12:12 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Is srv6 PSP a good idea

Jingrong,

Agreed.

Cheers,
Pablo.

-----Original Message-----
From: spring <[email-masked]> on behalf of "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wednesday, 11 December 2019 at 05:15
To: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

    
    
    Thanks
    Jingrong
    
    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Wednesday, December 11, 2019 10:55 AM
    To: [email-masked]
    Subject: [spring] Is srv6 PSP a good idea

    

    
    Yours,
    Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Sat, 14 Dec 2019 09:42:21 +0000

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" <[email-masked]>
Date: Thursday, 12 December 2019 at 06:48
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

    
    Yours,
    Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Sat, 14 Dec 2019 09:49:59 +0000

Ron,

What is the "price paid by the penultimate segment"? All the current implementations do this at linerate with no performance degradation as I have explained in my email before.

There is substantial benefit. Four operators have deployed PSP, which proves the benefit. 
It enables new use-cases that have been provided by other members in the list. [1], [2] and [5].
From operational perspective it is not complex as explained in [3].
Operators have expressed their value in [4] and [5].

[1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI

Cheers,
Pablo.

-----Original Message-----
From: Ron Bonica <[email-masked]>
Date: Thursday, 12 December 2019 at 21:50
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Is srv6 PSP a good idea

    Pablo,

    
    
                                                        Ron

    
    
    -----Original Message-----
    From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
    Sent: Wednesday, December 11, 2019 3:12 PM
    To: Joel M. Halpern <[email-masked]>; [email-masked]
    Subject: Re: [spring] Is srv6 PSP a good idea
    
    Joel,

    

    
    
    Thanks,
    Pablo.
    
    -----Original Message-----
    From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
    Date: Wednesday, 11 December 2019 at 03:55
    To: "[email-masked]" <[email-masked]>
    Subject: [spring] Is srv6 PSP a good idea

        

        
        Yours,
        Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Sat, 14 Dec 2019 09:57:08 +0000

Hi Dave,

Thank you for participating in the discussion.

I fail to see how it "fragmentation becomes particularly ugly". What is the negative impact to the final destination? I believe there is none.
Intuitively I tend to agree with Jingrong that PSP is beneficial since the egress PE will have easier access to the fragmentation header.

Regardless of whether it has any benefit: note that the source is the one choosing which segments that go into the SRH. As such, it can encode into the packet a penultimate segment with no PSP support. PSP is optional and it is advertised in the control plane so that the source can decide whether to use it.

Thank you,
Pablo.

-----Original Message-----
From: David Allan I <[email-masked]>
Date: Thursday, 12 December 2019 at 22:40
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Xiejingrong (Jingrong)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Is srv6 PSP a good idea

    Hi Pablo

    

    
    Hope this helps
    Dave

    -----Original Message-----
    From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
    Sent: Wednesday, December 11, 2019 12:12 PM
    To: Xiejingrong (Jingrong) <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
    Subject: Re: [spring] Is srv6 PSP a good idea
    
    Jingrong,

    Agreed.
    
    Cheers,
    Pablo.
    
    -----Original Message-----
    From: spring <[email-masked]> on behalf of "Xiejingrong (Jingrong)" <[email-masked]>
    Date: Wednesday, 11 December 2019 at 05:15
    To: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: [spring] Is srv6 PSP a good idea

        
        
        Thanks
        Jingrong
        
        -----Original Message-----
        From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
        Sent: Wednesday, December 11, 2019 10:55 AM
        To: [email-masked]
        Subject: [spring] Is srv6 PSP a good idea

        

        
        Yours,
        Joel

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 14 Dec 2019 16:07:18 +0000

Hi Joel,

Regrading this question:
Do you have any comments on what appears to be the significant increase
in complexity on the device performing PSP? 

I think the removal of some bytes from an packet header is a common case without any significant increasing complexity for a long time.
For example, a Layer-2 switch receives an ethernet frame from a port with a vlan tag, and forwards/switches it to another port without a vlan tag, then it strips the 2 bytes of vlan tag value and 2 bytes of 0x8100. The 4 bytes are in the middle of the ethernet header and the ip header, which otherwise would not need to be stripped if it's the case from a tag port to another tag port.

I found this in my book, "Network system design using network processors" by Douglas E. Comer 2004.
On page 38 "4.12 Operation and Data Chaining", introduced modern NICs use a technique known as “operation chaining or command chaining” instead of operating on a single large buffer.
Which makes me believe that, the removal of some bytes from some packet header (L2 or L3 header), would not cause the 1500 bytes of packet be moved, but instead a very basic function that various packet processors have solved very long ago as a basic function of "header/packet modification".

Hope the above understanding is right.

Thanks
Jingrong

________________________________________
From: spring [[email-masked]] on behalf of Joel M. Halpern [[email-masked]]
Sent: Wednesday, December 11, 2019 22:15
To: [email-masked]
Subject: Re: [spring] Is srv6 PSP a good idea

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Sun, 15 Dec 2019 10:03:22 +1100

On Sun, 15 Dec 2019, 03:07 Xiejingrong (Jingrong), <[email-masked]>
wrote:

> I think the removal of some bytes from an packet header is a common case
> without any significant increasing complexity for a long time.
> For example, a Layer-2 switch receives an ethernet frame from a port with
> a vlan tag, and forwards/switches it to another port without a vlan tag,
> then it strips the 2 bytes of vlan tag value and 2 bytes of 0x8100. The 4
> bytes are in the middle of the ethernet header and the ip header, which
> otherwise would not need to be stripped if it's the case from a tag port to
> another tag port.
>

According to Radia Perlman, in her book, "Interconnections", 2nd edition,
this was a work around to some NICs at the time not supporting sending and
receiving frames large enough to do full Ethernet-in-Ethernet tunnelling to
add VLAN information.

Cisco had implemented a pre-standard version of VLAN tagging - Inter-Switch
Link (ISL), which is what had inspired the IEEE to standardise VLAN
tagging. This used E-in-E tunnelling. This was possible because Cisco knew
what its hardware was capable of.

https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html

The checksum (FCS) of a frame is calculated at the sender (identified by
SA), so that the intended receiver (identified by the DA) can determine if
the frame was corrupted in flight.

VLAN tag insertion violates this end-to-end function of the checksum,
because the checksum is recalculated when VLAN tags are added.

When the frame arrives at the DA, the checksum isn't validating the frame
that was sent by the SA, it is only validating the frame that was sent by
the last device to remove the VLAN tag that then recalculated and updated
the checksum.

Those who designed IEEE tagging didn't do insertion because they wanted to
or thought it was a good idea. They didn't have a choice if they wanted to
be available with existing Ethernet chipsets.

> On page 38 "4.12 Operation and Data Chaining", introduced modern NICs use
> a technique known as “operation chaining or command chaining” instead of
> operating on a single large buffer.
> Which makes me believe that, the removal of some bytes from some packet
> header (L2 or L3 header), would not cause the 1500 bytes of packet be
> moved, but instead a very basic function that various packet processors
> have solved very long ago as a basic function of "header/packet
> modification".
>
> > (1.1) final destination tends to have heavy load. It need to handle all
> the EHs and do the delivery/demultiplex the packet to the right overlay
> service.
> > (2) support the incremental deployment when final destination(s) do not
> process/recognize SRH. This benefit can be notable for the following sub
> reasons.
> > (2.1) A core router may (fan-out) connected with a big number of low-end
> routers that do not support SRH but support tunnel-end/service-demultiplex
> function of SRv6.
> >
> > Thanks
> > Jingrong
> >
> 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
> idea of the benefit.  It may be that I am missing some of the benefit, and
> I would appreciate clarification.
> 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.
> >
> requires somewhere between some and a lot of extra work.  It is distinctly
> NOT free.
> >

---

From: Mark Smith <[email-masked]>
Date: Sun, 15 Dec 2019 14:08:32 +1100

On Fri, 13 Dec 2019, 07:50 Ron Bonica, <rbonica=[email-masked]>
wrote:

> Pablo,
>
> I am not convinced the benefit derived by the ultimate segment justifies
> the price paid by the penultimate segment. Specifically,
>
> - 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.

> 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.
>
> 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.
>
> In summary, it can be implemented without any burden in hardware and
> deployment experience prove this is beneficial to operators.
>
> Thanks,
> Pablo.
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 15 Dec 2019 01:35:52 -0500

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 <[email-masked]> wrote:

>
>
> On Fri, 13 Dec 2019, 07:50 Ron Bonica, <rbonica=
> [email-masked]> wrote:
>
>> Pablo,
>>
>> 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.
>>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

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

---

From: David Allan I <[email-masked]>
Date: Mon, 16 Dec 2019 16:49:18 +0000

HI Pablo:

Replies in-line prefaced with DA>

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Saturday, December 14, 2019 1:57 AM
To: Xiejingrong (Jingrong) <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Is srv6 PSP a good idea

Hi Dave,

I fail to see how it "fragmentation becomes particularly ugly". What is the negative impact to the final destination? I believe there is none.
DA> The work that needs to be performed doing PSP is substantially more than the final destination to handle the SRH.  That fragmentation multiplies this was my point.

Intuitively I tend to agree with Jingrong that PSP is beneficial since the egress PE will have easier access to the fragmentation header.
DA> I've seen the point raised that implementations can do this today. I would still be concerned about the additional load we are imposing as the next generation of interfaces comes along. 

Regardless of whether it has any benefit: note that the source is the one choosing which segments that go into the SRH. As such, it can encode into the packet a penultimate segment with no PSP support. PSP is optional and it is advertised in the control plane so that the source can decide whether to use it.
DA> I have to admit I find that to be a strange statement, effectively the source can choose whether or not to do something that is of questionable benefit?

Rgds
Dave

-----Original Message-----
From: David Allan I <[email-masked]>
Date: Thursday, 12 December 2019 at 22:40
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Xiejingrong (Jingrong)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Is srv6 PSP a good idea

    Hi Pablo

    

    
    Hope this helps
    Dave

    -----Original Message-----
    From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
    Sent: Wednesday, December 11, 2019 12:12 PM
    To: Xiejingrong (Jingrong) <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
    Subject: Re: [spring] Is srv6 PSP a good idea
    
    Jingrong,

    Agreed.
    
    Cheers,
    Pablo.
    
    -----Original Message-----
    From: spring <[email-masked]> on behalf of "Xiejingrong (Jingrong)" <[email-masked]>
    Date: Wednesday, 11 December 2019 at 05:15
    To: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: [spring] Is srv6 PSP a good idea

        
        
        Thanks
        Jingrong
        
        -----Original Message-----
        From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
        Sent: Wednesday, December 11, 2019 10:55 AM
        To: [email-masked]
        Subject: [spring] Is srv6 PSP a good idea

        

        
        Yours,
        Joel

---

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Dec 2019 15:04:52 +0000

Pablo,

In your message below, are you arguing that it is easier for the penultimate node to remove the SRH than it is for the ultimate node to ignore it? I think that would be a stretch.

                                                                              Ron

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Saturday, December 14, 2019 4:50 AM
To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Is srv6 PSP a good idea

Ron,

[1].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$ 
[2].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$ 
[3].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$ 
[4].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$ 
[5].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$ 

Cheers,
Pablo.

-----Original Message-----
From: Ron Bonica <[email-masked]>
Date: Thursday, 12 December 2019 at 21:50
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Is srv6 PSP a good idea

    Pablo,

    
    
                                                        Ron

    
    
    -----Original Message-----
    From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
    Sent: Wednesday, December 11, 2019 3:12 PM
    To: Joel M. Halpern <[email-masked]>; [email-masked]
    Subject: Re: [spring] Is srv6 PSP a good idea
    
    Joel,

    

    
    
    Thanks,
    Pablo.
    
    -----Original Message-----
    From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
    Date: Wednesday, 11 December 2019 at 03:55
    To: "[email-masked]" <[email-masked]>
    Subject: [spring] Is srv6 PSP a good idea

        

        
        Yours,
        Joel

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Dec 2019 18:08:01 -0500

On Tue, Dec 17, 2019 at 10:05 AM Ron Bonica <rbonica=
[email-masked]> wrote:

> Pablo,
>
> In your message below, are you arguing that it is easier for the
> penultimate node to remove the SRH than it is for the ultimate node to
> ignore it? I think that would be a stretch.
>
>
>     Ron
>
>
>
> What is the "price paid by the penultimate segment"? All the current
> implementations do this at linerate with no performance degradation as I
> have explained in my email before.
>
> [1].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$
> [2].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$
> [3].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$
> [4].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$
> [5].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$
>
> Cheers,
> Pablo.
>
> To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <
> [email-masked]>, "[email-masked]" <[email-masked]>
>     I am not convinced the benefit derived by the ultimate segment
> justifies the price paid by the penultimate segment. Specifically,
>
>     1.- The use-case for PSP has already been provided at the mailer.
> There are scenarios where it provides benefits to operators.
>
>     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).
>

> [Gyan].  Good point Joel.  So I think providing parity between SR-MPLS and
SRv6 being two completely different specifications like apple versus
orange.  SR-MPLS reuses the MPLS ldp data plane so PHP and UHP is popping
the traditional MPLS 4 byte shim.  So with SR-MPLS since you are reusing
the ldp data plane with new SRGB range 16000-23999 you are still doing
label swapping and not label stacking. Only when doing SR-TE are you
stacking the transport labels additional transport label per hop for the
traceroute.

My point is that SRV6 being a completely different animal from SR-MPLS we
don’t have to and should not carry over feature parity for the sake of
doing so if it’s unnecessary.  The main point here is PSP and USP are not
popping a transport header or topmost label as with SR-MPLS.  So with PSP
and USP the pseudocode is identical and repetitive with SL==0, pop SRH.
>From an SRV6 technical standpoint at the egress P PSP node or egress PE USP
node you would always only have a single SRH present

The only process that adds the additional SRH is TI-LFA and I believe we
decided that SRH would be part of a new 6in6 encapsulation done st the PLR
node.

If I am wrong, please correct me.

The only other scenario which I believe was brought up is if the SRH was so
large that it was fragmented and so have a fragmentation eh present as well
and then in that case instead of popping both SRHs now present on the USP
egress PE node which would be more processing you would pop the 1st EH on
the PSP node and the last EH fragment on the USP egress PE node.

I want to make sure I am not off on my thinking on USP and PSP as far as
when each happens.  So both USP and   PSP are the 1st two SIDs in the list
USP then PSP and the SL is processed in reverse order.  So am I wrong in my
thinking that in processing the SL as PSSI occurs at each hop along the
source routed path that when SL==0 you would process the 2nd to last
special  PSP SID and that would be the 2nd to last node in the SRv6 domain
which would in fact be the Penultimate hop node and you pop the SRH. Then
when SL==0 you you process the last special USP SID and that would be the
last node in the SRv6 domain which would be in fact the Ultimate hop PE
node and then you would pop the final SRH of present.

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 20 Dec 2019 17:36:01 +0000

Hi Ron,

I guess we are making some progress here but going in some circles. So far we have moved from “this violates RFC8200” to “there are no use-cases or benefits” to “this is complex for an ASIC” to “what is the benefit again” and now back to “this is complex for an ASIC”.

As for how easy or not something is, the PSP behavior has been implemented and deployed (running code). The use-cases have been described and positively reinforced by operators. I don't think there is any further explanation to provide.

Happy Holidays,
Pablo.

-----Original Message-----
From: Ron Bonica <[email-masked]>
Date: Tuesday, 17 December 2019 at 16:06
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Is srv6 PSP a good idea

    Pablo,

                                                                                  Ron

    
    -----Original Message-----
    From: Pablo Camarillo (pcamaril) <[email-masked]> 
    Sent: Saturday, December 14, 2019 4:50 AM
    To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
    Subject: Re: [spring] Is srv6 PSP a good idea
    
    Ron,

    
    
    Cheers,
    Pablo.
    
    -----Original Message-----
    From: Ron Bonica <[email-masked]>
    Date: Thursday, 12 December 2019 at 21:50
    To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: RE: [spring] Is srv6 PSP a good idea
    
        Pablo,

        
        
                                                            Ron

        
        
        -----Original Message-----
        From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
        Sent: Wednesday, December 11, 2019 3:12 PM
        To: Joel M. Halpern <[email-masked]>; [email-masked]
        Subject: Re: [spring] Is srv6 PSP a good idea
        
        Joel,

        

        
        
        Thanks,
        Pablo.
        
        -----Original Message-----
        From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
        Date: Wednesday, 11 December 2019 at 03:55
        To: "[email-masked]" <[email-masked]>
        Subject: [spring] Is srv6 PSP a good idea

            

            
            Yours,
            Joel

---

From: Ron Bonica <[email-masked]>
Date: Sat, 21 Dec 2019 20:55:45 +0000

Chairs,

Please continue to track this as an open issue.

                                               Ron

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Friday, December 20, 2019 12:36 PM
To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [spring] Is srv6 PSP a good idea

 Hi Ron,

Happy Holidays,
Pablo.

-----Original Message-----
From: Ron Bonica <[email-masked]>
Date: Tuesday, 17 December 2019 at 16:06
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Is srv6 PSP a good idea

    Pablo,

                                                                                  Ron

    
    -----Original Message-----
    From: Pablo Camarillo (pcamaril) <[email-masked]> 
    Sent: Saturday, December 14, 2019 4:50 AM
    To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
    Subject: Re: [spring] Is srv6 PSP a good idea
    
    Ron,

    
    
    Cheers,
    Pablo.
    
    -----Original Message-----
    From: Ron Bonica <[email-masked]>
    Date: Thursday, 12 December 2019 at 21:50
    To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: RE: [spring] Is srv6 PSP a good idea
    
        Pablo,

        
        
                                                            Ron

        
        
        -----Original Message-----
        From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
        Sent: Wednesday, December 11, 2019 3:12 PM
        To: Joel M. Halpern <[email-masked]>; [email-masked]
        Subject: Re: [spring] Is srv6 PSP a good idea
        
        Joel,

        

        
        
        Thanks,
        Pablo.
        
        -----Original Message-----
        From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
        Date: Wednesday, 11 December 2019 at 03:55
        To: "[email-masked]" <[email-masked]>
        Subject: [spring] Is srv6 PSP a good idea

            

            
            Yours,
            Joel