Re: [spring] SRv6 PSP use case

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 <spring-bounces@ietf.org> on behalf of "Joel M. Halpern" <jmh@joelhalpern.com>
Date: Wednesday, 4 March 2020 at 23:42
To: "spring@ietf.org" <spring@ietf.org>
Subject: [spring] SRv6 PSP use case

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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>