Subject: RE: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

From: Ron Bonica <[email-masked]>
Date: Thu, 27 Feb 2020 18:38:06 +0000

Pablo,

The question at hand is whether PSP is so crucial to SRv6 that it is worth stretching the limits of RFC 8200 compliance. The emails that you site below say that it is for the following reasons:

  1.  Because PSP is already deployed
  2.  Because PSP unburdens the ultimate segment router from the task of processing and removing the SRH
  3.  Because PSP enables incremental deployment

The first argument can be dismissed out of hand. Just because something has been deployed doesn't mean that it adds value or even that it causes no harm.

The second argument is dubious. Given that the ultimate segment endpoint has to remove the outer IPv6 header and forward the packet, the additional cost of checking the Segments Left field and removing the SRH is minimal.

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/ and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:

  *   Can process a SID, received as an IPv6 DA, on the fast path
  *   Cannot process an SRH, even if Segments Left equal 0, on the fast path.

In this scenario, PSP keeps packets off of that device's slow path.

While I have sympathy for Dan's dilemma, I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.

Maybe a compromise is possible? Would it be possible to move discussion of the PSP out of the Network programming draft and into a separate draft that a) describes the use-case in which it is required and b) discourages its use in all other cases.

                                                                                                                         Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Tuesday, February 25, 2020 10:17 AM
To: Gyan Mishra <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Gyan,

As I (and other WG members) have explained in the past, PSP is not trying to provide any feature parity with MPLS.

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].
There is substantial benefit. Four operators have deployed PSP, which proves the benefit.
And additionally 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

I don't see the point of starting a new thread from zero that discusses the same thing.

Cheers,
Pablo.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 25 February 2020 at 00:35
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

PSP has historical context from PHP ( Penultimate Hop POP) in the MPLS world.

20+ years ago when MPLS we originally developed the concept of PHP implicit null reserved label value 0 was done to offload the burden of the egress PE FEC destination to pop the entire label stack before forwarding the native IP packet to the CE.

Hardware these days for the last 15 years or so are so advanced that the idea that you are saving processing on the egress PE has not existed for a long time.

Even  back then in both SP and enterprise space there were issues that arise related to PHB QOS egress queuing,  that occurs on the PHP node that had the MPLS shim popped, it cannot schedule on the topmost label via exp provider markings done on the ingress PE upon label imposition.

A workaround to this issue was to set explicit null label value 0 and use pipe or uniform mode to tunnel the customer payload to the egress PE FEC destination called UHP ultimate hop node with topmost label intact.

The concept of implicit null PHP concept did not bode well in the MPLS world so I don't see why that feature parity would be added to a next gen protocol that would be the future MPLS replacement.

I agree with taking some of the good features and knobs from MPLS, but why take the ones like implicit null with is really an archaic feature.

My 2 cents

Gyan

On Mon, Feb 24, 2020 at 5:38 PM Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:[email-masked]>> wrote:
Ron,

This is the 5th time that we have this discussion in the past five months.

I consider those three questions as closed based on the previous discussion.
https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYs9oOW3B$>

Cheers,
Pablo.

From: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>
Date: Monday, 24 February 2020 at 16:27
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>, Mark Smith <[email-masked]<mailto:[email-masked]>>, Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>, "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Folks,

We may need to ask the following questions:

1)      Does PSP violate letter of RFC 8200?

2)      Does PSP violate the spirit of RFC 8200?

3)      Is PSP a good idea?

The 6man WG, and not SPRING, should answer the first two questions. So I will avoid them an explore the third.

At first glance, PSP adds no value. Once Segments Left has been decremented to 0, the Routing header becomes a NOOP. So why bother to remove it? I see the following arguments:

1)      To save bandwidth between the penultimate and ultimate segment endpoints.

2)      To unburden the ultimate segment endpoint from the task of processing the SRH

3)      To unburden the ultimate segment endpoint from the task of removing the SRH

The first argument is weak. Routing headers should not be so large that the bandwidth they consume is an issue.

The second argument is also weak. Once the ultimate segment endpoint has examined the Segments Left field, it can ignore the SRH. The ultimate segment endpoint must be SRv6-aware, because it must process the SID in the IPv6 destination address field. Given that the ultimate segment endpoint is SRv6 aware, it should be able to process the SRH on the fast path.

The third argument is even weaker. The ultimate segment endpoint:

-          Has to remove the IPv6 tunnel header, anyway

-          Being closer to the edge, may be less heavily loaded than the penultimate segment endpoint.

Can anyone articulate a better justification for PSP? If not, why test the limits of RFC 8200 over it?

                                                                                                           Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Andrew Alston
Sent: Monday, February 24, 2020 5:06 AM
To: Mark Smith <[email-masked]<mailto:[email-masked]>>; Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

I agree with the sentiments expressed below

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: Monday, 24 February 2020 00:50
To: Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:pcamaril=[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

On Mon, 24 Feb 2020, 07:47 Sander Steffann, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

> We have published a new update to draft-ietf-spring-srv6-network-programming. This revision simplifies the counters as per [1], clarifies the upper layer header processing as per [2] and removes the reference to the OAM draft [3].

I still oppose the segment popping flavours in section 4.16 without updating RFC8200.

I would expect that defying Internet Standard 86/RFC8200 means this ID needs to have Experimental rather than Standards Track status.

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Tfl9m_at6pZSp38lOtxE5WZLnsW_ojrgXUvQ_Rx-tN4MY7qa-MtwIQWgGCTduGJT$>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYkKy0jPv$>
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 20:11:03 +0100

Ron,

How about we go the other way and really admit that some hardware just can
not PSP at line rate ?

But for that there is very simple solution - you advertise PSP depth of
zero in IGP extensions and you are done.

Both ISIS and OSPFv3 extensions support this already today.

And as it has been said and illustrated it does not stretch RFC8200 at all.
PSP is performed by node listed in DA of the arriving packet. Such node can
do whatever it want with the outer header of the packet. Some folks try to
punch holes in 8200 to cover their issues - is that in good spirit of IETF
?

Your idea of taking piece of the consistent spec away is very broken as it
now makes other documents inconsistent and blocks hardware where such
function is supported today at line rate.

Let the operator choose if he wants PSP or not and move on ...

Best,
R.

On Thu, Feb 27, 2020 at 7:39 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Pablo,
>
>
>
> The question at hand is whether PSP is so crucial to SRv6 that it is worth
> stretching the limits of RFC 8200 compliance. The emails that you site
> below say that it is for the following reasons:
>
>
>
> The first argument can be dismissed out of hand. Just because something
> has been deployed doesn’t mean that it adds value or even that it causes no
> harm.
>
>
>
> The second argument is dubious. Given that the ultimate segment endpoint
> has to remove the outer IPv6 header and forward the packet, the additional
> cost of checking the Segments Left field and removing the SRH is minimal.
>
>
>
> The third argument was best articulated Dan Voyer in
> https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/
> and deserves some consideration. In his deployment scenario, the ultimate
> segment endpoint:
>
>
>
>    - Can process a SID, received as an IPv6 DA, on the fast path
>    - Cannot process an SRH, even if Segments Left equal 0, on the fast
>    path.
>
>
>
> In this scenario, PSP keeps packets off of that device’s slow path.
>
>
>
> While I have sympathy for Dan’s dilemma, I wonder whether it is a good
> idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.
>
>
>
> Maybe a compromise is possible? Would it be possible to move discussion of
> the PSP out of the Network programming draft and into a separate draft that
> a) describes the use-case in which it is required and b) discourages its
> use in all other cases.
>
>
>
>
>               Ron
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Pablo Camarillo
> (pcamaril)
> *Sent:* Tuesday, February 25, 2020 10:17 AM
> *To:* Gyan Mishra <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> Gyan,
>
>
>
> [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
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Tuesday, 25 February 2020 at 00:35
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>
> *Cc: *Ron Bonica <[email-masked]>, SPRING WG <[email-masked]>
> *Subject: *Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
>
>
> 20+ years ago when MPLS we originally developed the concept of PHP
> implicit null reserved label value 0 was done to offload the burden of the
> egress PE FEC destination to pop the entire label stack before forwarding
> the native IP packet to the CE.
>
>
>
> Hardware these days for the last 15 years or so are so advanced that the
> idea that you are saving processing on the egress PE has not existed for a
> long time.
>
>
>
> Even  back then in both SP and enterprise space there were issues that
> arise related to PHB QOS egress queuing,  that occurs on the PHP node that
> had the MPLS shim popped, it cannot schedule on the topmost label via exp
> provider markings done on the ingress PE upon label imposition.
>
>
>
> A workaround to this issue was to set explicit null label value 0 and use
> pipe or uniform mode to tunnel the customer payload to the egress PE FEC
> destination called UHP ultimate hop node with topmost label intact.
>
>
>
> The concept of implicit null PHP concept did not bode well in the MPLS
> world so I don’t see why that feature parity would be added to a next gen
> protocol that would be the future MPLS replacement.
>
>
>
> I agree with taking some of the good features and knobs from MPLS, but why
> take the ones like implicit null with is really an archaic feature.
>
>
>
> My 2 cents
>
>
>
> Gyan
>
>
>
> On Mon, Feb 24, 2020 at 5:38 PM Pablo Camarillo (pcamaril) <pcamaril=
> [email-masked]> wrote:
>
> Ron,
>
>
>
> https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYs9oOW3B$>
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> *From: *Ron Bonica <rbonica=[email-masked]>
> *Date: *Monday, 24 February 2020 at 16:27
> *To: *Andrew Alston <[email-masked]>, Mark Smith <
> [email-masked]>, Sander Steffann <[email-masked]>
> *Cc: *SPRING WG <[email-masked]>, "Pablo Camarillo (pcamaril)" <
> [email-masked]>
> *Subject: *RE: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> Folks,
>
>
>
> At first glance, PSP adds no value. Once Segments Left has been
> decremented to 0, the Routing header becomes a NOOP. So why bother to
> remove it? I see the following arguments:
>
>
>
> The second argument is also weak. Once the ultimate segment endpoint has
> examined the Segments Left field, it can ignore the SRH. The ultimate
> segment endpoint must be SRv6-aware, because it must process the SID in the
> IPv6 destination address field. Given that the ultimate segment endpoint is
> SRv6 aware, it should be able to process the SRH on the fast path.
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Andrew Alston
> *Sent:* Monday, February 24, 2020 5:06 AM
> *To:* Mark Smith <[email-masked]>; Sander Steffann <
> [email-masked]>
> *Cc:* SPRING WG <[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=
> [email-masked]>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Mark Smith
> *Sent:* Monday, 24 February 2020 00:50
> *To:* Sander Steffann <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; Pablo Camarillo (pcamaril) <
> pcamaril=[email-masked]>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
>
>
> On Mon, 24 Feb 2020, 07:47 Sander Steffann, <[email-masked]> wrote:
>
> Hi,
>
> > We have published a new update to
> draft-ietf-spring-srv6-network-programming. This revision simplifies the
> counters as per [1], clarifies the upper layer header processing as per [2]
> and removes the reference to the OAM draft [3].
>
> I would expect that defying Internet Standard 86/RFC8200 means this ID
> needs to have Experimental rather than Standards Track status.
>
>
>
>
>
>
>
>
> Cheers,
> Sander
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Tfl9m_at6pZSp38lOtxE5WZLnsW_ojrgXUvQ_Rx-tN4MY7qa-MtwIQWgGCTduGJT$>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYkKy0jPv$>
>
> --
>
> Gyan  Mishra
>
> Email: [email-masked]
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Andrew Alston <[email-masked]>
Date: Thu, 27 Feb 2020 20:02:51 +0000

Robert –

Do you know or can you please name any hardware that cannot do line rate PSP?  I could understand not being able to do USP at line rate – which may in certain implementations cause re-circulation (maybe THAT’S the unstated dirty secret that are keeping people pushing this without stating a use case?) – but PSP?

Andrew

From: ipv6 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, 27 February 2020 at 22:11
To: Ron Bonica <rbonica=[email-masked]>
Cc: SPRING WG <[email-masked]>, 6man WG <[email-masked]>, "Pablo Camarillo (pcamaril)" <pcamaril=[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Ron,

How about we go the other way and really admit that some hardware just can not PSP at line rate ?

But for that there is very simple solution - you advertise PSP depth of zero in IGP extensions and you are done.

And as it has been said and illustrated it does not stretch RFC8200 at all. PSP is performed by node listed in DA of the arriving packet. Such node can do whatever it want with the outer header of the packet. Some folks try to punch holes in 8200 to cover their issues - is that in good spirit of IETF ?

Your idea of taking piece of the consistent spec away is very broken as it now makes other documents inconsistent and blocks hardware where such function is supported today at line rate.

Best,
R.

On Thu, Feb 27, 2020 at 7:39 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Pablo,

The first argument can be dismissed out of hand. Just because something has been deployed doesn’t mean that it adds value or even that it causes no harm.

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/<https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/> and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:

While I have sympathy for Dan’s dilemma, I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.

                                                                                                                         Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Tuesday, February 25, 2020 10:17 AM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Gyan,

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

Cheers,
Pablo.

The concept of implicit null PHP concept did not bode well in the MPLS world so I don’t see why that feature parity would be added to a next gen protocol that would be the future MPLS replacement.

My 2 cents

Gyan

On Mon, Feb 24, 2020 at 5:38 PM Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:[email-masked]>> wrote:
Ron,

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 28 Feb 2020 05:05:28 +0000

Hi John,

Please check inline below.

From: spring <[email-masked]> On Behalf Of John Scudder
Sent: 28 February 2020 02:41
To: SPRING WG <[email-masked]>; 6man WG <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

I have an additional observation, or question, about Dan’s scenario. Almost all communication is bidirectional.
[KT] Sure and perhaps you can actually look at Dan’s scenario at https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/ … and (while I don’t claim this to be Dan’s application) then consider it’s about delivering content to a user/customer from a DC.

Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other. Doesn’t a head end need to add an SRH?
[KT] No. Since content delivery (say OTT video) is heavy in one direction and that is where we can agree that an operator would wish to do TE. The other way is not required. You see that this is work to address real-life scenarios and practical deployments – that is what is driving the implementation and deployment efforts. It is not about a “religious” thing – it’s fact based and real.

If I’ve gotten that right, then we can extend Ron’s list with one more item. That is, apparently the ultimate segment endpoint:
[KT] I hope you see what you perhaps missed 😊 … rest of your (and Ron and other’s similar) points below are now moot.

I hope I’ve been able to make you see the benefits of just one of the use-cases … assuming that you are not wearing the glasses of “PSP violates/stretches RFC8200” 😉

Thanks,
Ketan

• Can process a SID, received as an IPv6 DA, on the fast path
• Cannot process an SRH on receipt, even if Segments Left equal 0, on the fast path.
• Can add an SRH on transmission, on the fast path

Even though strictly speaking the second and third bullet points aren’t mutually exclusive, it’s a little difficult to imagine a real router that would have both these properties simultaneously. Perhaps I’m not being creative enough in imagining deployment scenarios? Since this scenario is claimed as an important reason this problematic feature is needed, it would be great if someone who understands it would elucidate, thanks.

One further point, Ron says “I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.” I also wonder this, especially because these devices will have a relatively limited lifetime in the network.[*] I don’t find the cost/benefit attractive of making a permanent detrimental change to the IPv6 architecture to accommodate a temporary deployment issue.

Regards,

—John

[*] Yes, I know “limited lifetime” can mean a surprising number of years, but in any event not as long as the expected lifetime as IPv6 itself. Furthermore, old devices tend to change roles so I think “limited lifetime” *in this role* isn’t too much of a stretch.

On Feb 27, 2020, at 1:38 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Pablo,

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_QTmM755Q$> and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:

                                                                                                                         Ron

Gyan,

[1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_QAAm0nSw$>
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_R7CfuQuA$>
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_RGqFWLfw$>
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_RhwnT1cw$>
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_Se7ocRiA$>

Cheers,
Pablo.

My 2 cents

Gyan

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 11:55:08 +0100

Hi John,

> I have an additional observation, or question, about Dan’s scenario.
Almost all communication is bidirectional.
> Presumably this means a router that’s the tail end of an SRv6 path in one
direction is the head end in the other.

While your observation is correct that most TCP connections are bidir SR in
a lot of cases can operate only in one direction. Needless to say it can
also be used with UDP streaming.

To extend Ketan's OTT video example let me observe that in a lot of
transactions queries from clients are tiny and do not TE capabilities while
responses are huge and bursty and may indeed benefit from special handling.

Sure if you think of applications like VPNs than you are right ..
regardless of the size of the packets proper tagging must occur in either
direction - but this is just one use of SRv6 perhaps not even the major
one.

- - -

Now as one friend just asked me offline - putting all IPv6 dogmas aside -
what is the technical issue with removing previously applied extension
header from the packet within a given operator's network ? What breaks when
you do that ?

Thx,
R.

On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs=
[email-masked]> wrote:

> I have an additional observation, or question, about Dan’s scenario.
> Almost all communication is bidirectional. Presumably this means a router
> that’s the tail end of an SRv6 path in one direction is the head end in the
> other. Doesn’t a head end need to add an SRH? If I’ve gotten that right,
> then we can extend Ron’s list with one more item. That is, apparently the
> ultimate segment endpoint:
>
> Even though strictly speaking the second and third bullet points aren’t
> mutually exclusive, it’s a little difficult to imagine a real router that
> would have both these properties simultaneously. Perhaps I’m not being
> creative enough in imagining deployment scenarios? Since this scenario is
> claimed as an important reason this problematic feature is needed, it would
> be great if someone who understands it would elucidate, thanks.
>
> One further point, Ron says “I wonder whether it is a good idea to stretch
> the IPv6 standard to accommodate IPv6-challenged devices.” I also wonder
> this, especially because these devices will have a relatively limited
> lifetime in the network.[*] I don’t find the cost/benefit attractive of
> making a permanent detrimental change to the IPv6 architecture to
> accommodate a temporary deployment issue.
>
> Regards,
>
> —John
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Feb 2020 11:03:26 -0500

While it is true that some traffic only needs steering in one direction, 
I have real trouble figuring out how an operator would dare deploy an SR 
edge device that could not steer incoming traffic.  Either they do not 
need SR, or they can expect that some traffic will need it in both 
directions.  So I am left supporting John's contention that there seems 
to be a gap in how one would used the hypothesized device that needs 
another device performing PSP.

also, and edge device that requires PSP would place constraints on the 
SRv6 traffic paths that could be used be used to it.  One would have to 
ensure that all SRv6 traffic ending there had a penultimate explicit hop 
to a device that could perform PSP.  Yes, this can be done.  It does 
seem to complicate life.  Thus, yet another way that PSP adds complications.

Yours,
Joel

On 2/28/2020 5:55 AM, Robert Raszuk wrote:
>  > Presumably this means a router that’s the tail end of an SRv6 path in 
> one direction is the head end in the other.
> 
> While your observation is correct that most TCP connections are bidir SR 
> in a lot of cases can operate only in one direction. Needless to say it 
> can also be used with UDP streaming.
> 
> transactions queries from clients are tiny and do not TE 
> capabilities while responses are huge and bursty and may indeed benefit 
> from special handling.
> 
> regardless of the size of the packets proper tagging must occur in 
> either direction - but this is just one use of SRv6 perhaps not even the 
> major one.
> 
> - - -
> 
> Now as one friend just asked me offline - putting all IPv6 dogmas aside 
> - what is the technical issue with removing previously applied extension 
> header from the packet within a given operator's network ? What breaks 
> when you do that ?
> 
> Thx,
> R.
> 
> 
> On Thu, Feb 27, 2020 at 10:11 PM John Scudder 
> <jgs=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     I have an additional observation, or question, about Dan’s
>     scenario.. Almost all communication is bidirectional. Presumably
>     this means a router that’s the tail end of an SRv6 path in one
>     direction is the head end in the other. Doesn’t a head end need to
>     add an SRH? If I’ve gotten that right, then we can extend Ron’s list
>     with one more item. That is, apparently the ultimate segment endpoint:
> 
>     Even though strictly speaking the second and third bullet points
>     aren’t mutually exclusive, it’s a little difficult to imagine a real
>     router that would have both these properties simultaneously. Perhaps
>     I’m not being creative enough in imagining deployment scenarios?
>     Since this scenario is claimed as an important reason this
>     problematic feature is needed, it would be great if someone who
>     understands it would elucidate, thanks.
> 
>     One further point, Ron says “I wonder whether it is a good idea to
>     stretch the IPv6 standard to accommodate IPv6-challenged devices.” I
>     also wonder this, especially because these devices will have a
>     relatively limited lifetime in the network.[*] I don’t find the
>     cost/benefit attractive of making a permanent detrimental change to
>     the IPv6 architecture to accommodate a temporary deployment issue.
> 
>     Regards,
> 
>     —John
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 17:12:35 +0100

Joel,

Let me observe that as it has been said already such end device may support
SR but SRH above say N SIDs is handled only in slow path.

In the same time let me observe that while slow path may be just fine for a
lot of time such device also is to receive 5 well engineered high
bandwidth streams. So only for those 5 streams it is required to do PSP.

IMO this is good enough reason to support it.

Thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 28 Feb 2020 08:22:25 -0800

Hi Robert,
you've asked about a possible operational drawback of PSP. I think that for
OAM PSP has decremental effect on the usefulness of performance
measurements as there's no obvious information to identify the path a
packet traversed.

Regards,
Greg

On Fri, Feb 28, 2020 at 2:55 AM Robert Raszuk <[email-masked]> wrote:

> in a lot of cases can operate only in one direction. Needless to say it can
>> I have an additional observation, or question, about Dan’s scenario..
>> stretch the IPv6 standard to accommodate IPv6-challenged devices.” I also
>> wonder this, especially because these devices will have a relatively
>> limited lifetime in the network.[*] I don’t find the cost/benefit
>> attractive of making a permanent detrimental change to the IPv6
>> architecture to accommodate a temporary deployment issue.
>>
>> Regards,
>>
>> —John
>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 17:37:01 +0100

Greg,

I agree. Moreover I would suggest to add such text that PSP endpoint
behaviours should or must not be set for any OEM packets. Would that help ?

Thx,
R.

On Fri, Feb 28, 2020 at 5:22 PM Greg Mirsky <[email-masked]> wrote:

> Hi Robert,
> you've asked about a possible operational drawback of PSP. I think that
> for OAM PSP has decremental effect on the usefulness of performance

---

From: Ron Bonica <[email-masked]>
Date: Fri, 28 Feb 2020 16:37:32 +0000

Beyond that, SRv6 nodes examine the O-flag, even when Segments Left is equal to 0. So, when the SRH is removed, O-flag functionality isn't available at the ultimate segment endpoint.

                                                          Ron

From: spring <[email-masked]> On Behalf Of Greg Mirsky
Sent: Friday, February 28, 2020 11:22 AM
To: Robert Raszuk <[email-masked]>
Cc: John Scudder <jgs=[email-masked]>; SPRING WG <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Hi Robert,
you've asked about a possible operational drawback of PSP. I think that for OAM PSP has decremental effect on the usefulness of performance measurements as there's no obvious information to identify the path a packet traversed.

Regards,
Greg

On Fri, Feb 28, 2020 at 2:55 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi John,

> I have an additional observation, or question, about Dan's scenario. Almost all communication is bidirectional.
> Presumably this means a router that's the tail end of an SRv6 path in one direction is the head end in the other.

While your observation is correct that most TCP connections are bidir SR in a lot of cases can operate only in one direction. Needless to say it can also be used with UDP streaming.

To extend Ketan's OTT video example let me observe that in a lot of transactions queries from clients are tiny and do not TE capabilities while responses are huge and bursty and may indeed benefit from special handling.

Sure if you think of applications like VPNs than you are right ... regardless of the size of the packets proper tagging must occur in either direction - but this is just one use of SRv6 perhaps not even the major one.

- - -

Now as one friend just asked me offline - putting all IPv6 dogmas aside - what is the technical issue with removing previously applied extension header from the packet within a given operator's network ? What breaks when you do that ?

Thx,
R.

On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs=[email-masked]<mailto:[email-masked]>> wrote:
I have an additional observation, or question, about Dan's scenario... Almost all communication is bidirectional. Presumably this means a router that's the tail end of an SRv6 path in one direction is the head end in the other. Doesn't a head end need to add an SRH? If I've gotten that right, then we can extend Ron's list with one more item. That is, apparently the ultimate segment endpoint:

* Can process a SID, received as an IPv6 DA, on the fast path
* Cannot process an SRH on receipt, even if Segments Left equal 0, on the fast path.
* Can add an SRH on transmission, on the fast path

Even though strictly speaking the second and third bullet points aren't mutually exclusive, it's a little difficult to imagine a real router that would have both these properties simultaneously. Perhaps I'm not being creative enough in imagining deployment scenarios? Since this scenario is claimed as an important reason this problematic feature is needed, it would be great if someone who understands it would elucidate, thanks.

One further point, Ron says "I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices." I also wonder this, especially because these devices will have a relatively limited lifetime in the network.[*] I don't find the cost/benefit attractive of making a permanent detrimental change to the IPv6 architecture to accommodate a temporary deployment issue.

Regards,

-John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WHQ0NUhAjwHVsM4IaKk9Y18cX6e8a4CIRz74xNQrYqdWDNahVJLVKyhuirvllWKo$>
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 28 Feb 2020 08:44:34 -0800

Hi Robert,
thank you for you consideration. Pablo and I had discussed references to
OAM in the SRv6 network programming draft. Pablo and authors kindly agreed
to remove all references to OAM and draft-ietf-6man-spring-srv6-oam. As we
are discussing the network programming
draft, draft-ietf-6man-spring-srv6-oam is in WGLC at 6man. My intention was
to work with the authors of SRv6 OAM draft on documenting its relationship
with PSP. Would that make sense?

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 17:45:56 +0100

Even better !

Thank you,
R.

On Fri, Feb 28, 2020 at 5:44 PM Greg Mirsky <[email-masked]> wrote:

>>>> While your observation is correct that most TCP connections are bidir
>>>> SR in a lot of cases can operate only in one direction. Needless to say it
>>>>> aren’t mutually exclusive, it’s a little difficult to imagine a real router
>>>>> that would have both these properties simultaneously. Perhaps I’m not being

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 28 Feb 2020 08:47:17 -0800

Hi Ron,
absolutely agree. And that is, in my opinion, question the authors of
draft-ietf-6man-spring-srv6-oam must clarify in the document. AFAIK, Zafar
and authors are working on the update to address WGLC comments. I'm looking
forward to discuss the changes.

Regards,
Greg

On Fri, Feb 28, 2020 at 8:37 AM Ron Bonica <[email-masked]> wrote:

>
>
> Beyond that, SRv6 nodes examine the O-flag, even when Segments Left is
> equal to 0. So, when the SRH is removed, O-flag functionality isn’t
> available at the ultimate segment endpoint.
>
>
>
>                                                           Ron
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* Friday, February 28, 2020 11:22 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* John Scudder <jgs=[email-masked]>; SPRING WG <
> [email-masked]>; 6man WG <[email-masked]>
> Sure if you think of applications like VPNs than you are right ...
> I have an additional observation, or question, about Dan’s scenario...
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WHQ0NUhAjwHVsM4IaKk9Y18cX6e8a4CIRz74xNQrYqdWDNahVJLVKyhuirvllWKo$>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2020 18:05:55 +0000

Hi Greg,

Please see [ZA] in-line.

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Friday, February 28, 2020 at 11:45 AM
To: Robert Raszuk <[email-masked]>
Cc: John Scudder <jgs=[email-masked]>, SPRING WG <[email-masked]>, 6man WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Hi Robert,
thank you for you consideration. Pablo and I had discussed references to OAM in the SRv6 network programming draft. Pablo and authors kindly agreed to remove all references to OAM and draft-ietf-6man-spring-srv6-oam. As we are discussing the network programming draft, draft-ietf-6man-spring-srv6-oam is in WGLC at 6man. My intention was to work with the authors of SRv6 OAM draft on documenting its relationship with PSP. Would that make sense?

[ZA] Agreed!

Regards,
Greg

On Fri, Feb 28, 2020 at 8:37 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

I agree. Moreover I would suggest to add such text that PSP endpoint behaviours should or must not be set for any OEM packets. Would that help ?

Thx,
R.

On Fri, Feb 28, 2020 at 5:22 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,
you've asked about a possible operational drawback of PSP. I think that for OAM PSP has decremental effect on the usefulness of performance measurements as there's no obvious information to identify the path a packet traversed.

Regards,
Greg

> Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other.

Sure if you think of applications like VPNs than you are right .. regardless of the size of the packets proper tagging must occur in either direction - but this is just one use of SRv6 perhaps not even the major one.

- - -

Thx,
R.

On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs=[email-masked]<mailto:[email-masked]>> wrote:
I have an additional observation, or question, about Dan’s scenario... Almost all communication is bidirectional. Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other. Doesn’t a head end need to add an SRH? If I’ve gotten that right, then we can extend Ron’s list with one more item. That is, apparently the ultimate segment endpoint:

Regards,

—John