Re: [spring] SRv6 PSP use case

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