Subject: [spring] SRv6 PSP use case

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Mar 2020 15:41:44 -0500

I think I have now inferred what the intended use case is for PSP.  I 
really wish folks had stated it in full and explicitly, rather than 
implicitly a piece at a time, on the list.

As noted below after the explanation, I think that supporting this use 
case does require some explanations somewhere.  And given that the 
support is in terms of PSP, I guess the NP draft is the place to put the 
caveats.

As far as I can tell, the use case is as follows.
The operator has devices, that they reasonably wish to continue to use.
These devices can support encapsulation and decapsulation with 
sufficiently arbitrary content.
These devices comply with the RFC 8200 requirement for ignoring routing 
headers by punting those to the slow path.  With significant performance 
penalty.
   --  Presumably, these devices have some form of protection to prevent 
this slow-pathing from becoming a DoS on the other necessary control 
functions.  I don't think that protection is an SRv6 or NP problem.  But 
it is necessary.

Thus, the SRv6 designers want to be able to use these devices as part of 
the SRv6 domain, strictly at entry and exit.  They use PSP as a way to 
avoid hitting the slow path on decapsulate.  (Presumably because the 
check that punts the packet to the slow path is before the check that 
says "decapsulate".  And it probably should be in that order.)

In order to support this, the authors have also pretended that maximum 
SID depth is meaningful for a thing that is not a stack, and that 0 
means "no SRH permitted".  While an interesting stretch on the routing 
protocol semantics, it is not SPRING's problem.

The fact that these nodes can not be SRv6 end nodes other than as 
terminal nodes with a prior node that advertised PSP SID(s) and where 
those PSP SIDs are used on any path that terminates at these end nodes 
is important.  It probably should be called out.  It would have helped a 
number of the examples that were discussed on the list.

There is another implication that needs to be stated explicitly.  And I 
do not know how the necessary property can be indicated.  These nodes 
MUST NOT be transit nodes in an SRv6 path.

Having parsed the use case, I would note that the topological 
constraints are pretty severe.  the operator must ensure that there are 
PSP processing nodes sufficiently close to these edge nodes that they do 
not destroy the traffic engineering properties in order to achieve the 
ingress / egress utilization.

If all of this had been stated explicitly, I think we could have had a 
clear discussion of teh costs and benefits.

Yours,
Joel

---

From: Andrew Alston <[email-masked]>
Date: Wed, 4 Mar 2020 20:53:12 +0000

Thanks Joel for the inference.

Would love to have some comment from the authors on this.  In the mean time in the next 2 or 3 days I’ll write some code and see if I can verify this theory across a range of vendor devices that I have, will advise on the results I get.

Thanks

Andrew

From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
Date: Wednesday, 4 March 2020 at 23:42
To: "[email-masked]" <[email-masked]>
Subject: [spring] SRv6 PSP use case

Yours,
Joel

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 4 Mar 2020 22:01:05 +0000

Hi Joel, what you describe was also described by Dan Voyer and Jingrong previously.  You’ve added some signalling color but otherwise the same.
If you’ve read https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-00#section-2.4
you can see how SRv6 is used for an L3VPN without an SRH present.

Combine that with the TE description with PSP here https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-00#section-2.8.1

Now you should be able to see how to put this together.

The WG decided illustrations such as this belong in the illustration draft.
I believe the WG requested that be split from draft-filsfils-spring-srv6-network-programming draft before adoption.
That was over a year ago.

Darren

On Mar 4, 2020, at 3:41 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

I think I have now inferred what the intended use case is for PSP.  I really wish folks had stated it in full and explicitly, rather than implicitly a piece at a time, on the list.

As noted below after the explanation, I think that supporting this use case does require some explanations somewhere.  And given that the support is in terms of PSP, I guess the NP draft is the place to put the caveats.

As far as I can tell, the use case is as follows.
The operator has devices, that they reasonably wish to continue to use.
These devices can support encapsulation and decapsulation with sufficiently arbitrary content.
These devices comply with the RFC 8200 requirement for ignoring routing headers by punting those to the slow path.  With significant performance penalty.
 --  Presumably, these devices have some form of protection to prevent this slow-pathing from becoming a DoS on the other necessary control functions.  I don't think that protection is an SRv6 or NP problem.  But it is necessary.

Thus, the SRv6 designers want to be able to use these devices as part of the SRv6 domain, strictly at entry and exit.  They use PSP as a way to avoid hitting the slow path on decapsulate.  (Presumably because the check that punts the packet to the slow path is before the check that says "decapsulate".  And it probably should be in that order.)

In order to support this, the authors have also pretended that maximum SID depth is meaningful for a thing that is not a stack, and that 0 means "no SRH permitted".  While an interesting stretch on the routing protocol semantics, it is not SPRING's problem.

The fact that these nodes can not be SRv6 end nodes other than as terminal nodes with a prior node that advertised PSP SID(s) and where those PSP SIDs are used on any path that terminates at these end nodes is important.  It probably should be called out.  It would have helped a number of the examples that were discussed on the list.

There is another implication that needs to be stated explicitly.  And I do not know how the necessary property can be indicated.  These nodes MUST NOT be transit nodes in an SRv6 path.

Having parsed the use case, I would note that the topological constraints are pretty severe.  the operator must ensure that there are PSP processing nodes sufficiently close to these edge nodes that they do not destroy the traffic engineering properties in order to achieve the ingress / egress utilization.

If all of this had been stated explicitly, I think we could have had a clear discussion of teh costs and benefits.

Yours,
Joel

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

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 4 Mar 2020 17:34:51 -0500

A case with no SRH is clearly not a case for PSP.
With regard to the case for PSP, as I said in my note I am concerned 
that if we want to support this specific case, then there are 
restrictions on deployment and operation that need to be called out.

For example, a path compute engine for example needs to know that it not 
only can not use such nodes as .END without prior PSP, but that it can 
not include them in transit paths.

Yours,
Joel

On 3/4/2020 5:01 PM, Darren Dukes (ddukes) wrote:
> Hi Joel, what you describe was also described by Dan Voyer and Jingrong 
> previously.  You’ve added some signalling color but otherwise the same.
> If you’ve read 
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-00#section-2.4 
> 
> Combine that with the TE description with PSP here 
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-00#section-2.8.1
> 
> I believe the WG requested that be split from 
> draft-filsfils-spring-srv6-network-programming draft before adoption.
>> support is in terms of PSP, I guess the NP draft is the place to put 
>> the caveats.
>>
>> These devices comply with the RFC 8200 requirement for ignoring 
>> routing headers by punting those to the slow path.  With significant 
>> performance penalty.
>> functions.  I don't think that protection is an SRv6 or NP problem. 
>>  But it is necessary.
>>
>> Thus, the SRv6 designers want to be able to use these devices as part 
>> of the SRv6 domain, strictly at entry and exit.  They use PSP as a way 
>> to avoid hitting the slow path on decapsulate.  (Presumably because 
>> the check that punts the packet to the slow path is before the check 
>> that says "decapsulate".  And it probably should be in that order.)
>>
>> is important.  It probably should be called out.  It would have helped 
>> a number of the examples that were discussed on the list.
>>
>> There is another implication that needs to be stated explicitly.  And 
>> I do not know how the necessary property can be indicated.  These 
>> nodes MUST NOT be transit nodes in an SRv6 path.
>>
>> constraints are pretty severe.  the operator must ensure that there 
>> are PSP processing nodes sufficiently close to these edge nodes that 
>> they do not destroy the traffic engineering properties in order to 
>> achieve the ingress / egress utilization.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Thu, 5 Mar 2020 12:16:08 +1100

Hi Joel,

> The operator has devices, that they reasonably wish to continue to use.

My understanding is that the operator wants to extend their SRv6 control
plane domain onto PEs, past the edge of their current SRv6 forwarding plane
domain, because they don't currently have budget available to upgrade the
forwarding plane in those PEs.

This situation would be temporary until there is budget to upgrade the PEs'
forwarding planes. I'd think this situation is likely to last no more than
2 to 3 years in a big operator. The more successful SR is, the quicker the
upgrades are likely to be.

So this is effectively a permanent IETF technical workaround for a
temporary financial problem.

In 5 to 10 years time it is unlikely anybody would have a need or want PSP
in this scenario, because all SRv6 control and SRv6 forwarding planes in
all SR enabled networks would be congruent.

Regards,
Mark.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 5 Mar 2020 04:40:37 +0000

Hi Joel,

Thanks for your attempt at summarizing one of the use-cases of PSP which has been actively discussed/debated on the list. I see that you are suggesting to do something like a use-case review for it. It might be a useful discussion for the WG, but I am sure you are not suggesting any association with the progression of the net-pgm draft. Do clarify since that document is a standards track and does not discuss or cover use-cases. It only covers the standardization of the various SID behaviors as explained in its introduction.

Since we are talking use-cases, I think it is important again to remind what Bruno said here : https://mailarchive.ietf.org/arch/msg/spring/MkMkmNtEgnOYb5v_T-1HLLV6AB8/

"A negative claim is a colloquialism for an affirmative claim that asserts the non-existence or exclusion of something.[10] The difference with a positive claim is that it takes only a single example to demonstrate such a positive assertion ("there is a chair in this room," requires pointing to a single chair), while the inability to give examples demonstrates that the speaker has not yet found or noticed examples rather than demonstrates that no examples exist (the negative claim that a species is extinct may be disproved by a single surviving example or proven with omniscience)."

I would also like to add that it is perfectly likely that an operator has more use-case(s) for the building block of PSP in their network that they do not want to disclose. It may be their differentiator or innovation which they do not have to share with the IETF. There will also likely be other use-cases in the future that are built on top of the building blocks that we are standardizing. I don’t believe you are suggesting that we regulate use-cases at the IETF?

And then, I will again come back to the key point which we’ve debated before : why not have PSP?

Mark,

Perhaps you are rehashing the point that you raised and was answered here : https://mailarchive.ietf.org/arch/msg/spring/nOWf9iys3en1NN6IVbWodzaw7_M/

Also, it seems unfruitful to perform estimations of network operators upgrade/refresh plans or to analyse their financial conditions in this context. It seems more appropriate to support standardization work that enables rollout of innovation that is also attempting to be relevant for what is real and out there today.

Thanks,
Ketan

From: spring <[email-masked]> On Behalf Of Mark Smith
Sent: 05 March 2020 06:46
To: Joel M. Halpern <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] SRv6 PSP use case

Hi Joel,

On Thu, 5 Mar 2020, 07:42 Joel M. Halpern, <[email-masked]<mailto:[email-masked]>> wrote:
I think I have now inferred what the intended use case is for PSP.  I
really wish folks had stated it in full and explicitly, rather than
implicitly a piece at a time, on the list.

My understanding is that the operator wants to extend their SRv6 control plane domain onto PEs, past the edge of their current SRv6 forwarding plane domain, because they don't currently have budget available to upgrade the forwarding plane in those PEs.

This situation would be temporary until there is budget to upgrade the PEs' forwarding planes. I'd think this situation is likely to last no more than 2 to 3 years in a big operator. The more successful SR is, the quicker the upgrades are likely to be.

So this is effectively a permanent IETF technical workaround for a temporary financial problem.

In 5 to 10 years time it is unlikely anybody would have a need or want PSP in this scenario, because all SRv6 control and SRv6 forwarding planes in all SR enabled networks would be congruent.

Regards,
Mark.

functions.  I don't think that protection is an SRv6 or NP problem..  But
it is necessary.

says "decapsulate".  And it probably should be in that order..)

Yours,
Joel

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 5 Mar 2020 16:07:30 +0000

Hi all,

We just updated our draft on the SRv6 Deployment Consideration. One of the new updates in the draft is to add some of the PSP use cases, which is inspired by the discussions over the mailing list. Your comments on the draft are very welcomed as well as more PSP use cases. Thank you!

The posted draft can be found here,
https://tools.ietf.org/html/draft-tian-spring-srv6-deployment-consideration-01.

Best regards,
Shuping

From: spring [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, March 5, 2020 12:41 PM
To: Mark Smith <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] SRv6 PSP use case

Hi Joel,

Mark,

Thanks,
Ketan

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: 05 March 2020 06:46
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] SRv6 PSP use case

Hi Joel,

Regards,
Mark.

Yours,
Joel