[spring] Further thoughts on g-srv6/csid

[Andrew Alston <[e-mail]>]

Hi All,

So - to understand the claims of compatibility between the behaviors within the same domain - I decided the best way to test this was to write some actual code to simulate it.  I'm hoping to get the full simulation code out in the next 24 hours - but in the mean time I figured I'd add some thoughts here on the list so that any assumptions and readings I have of the documents that are incorrect can be corrected so I can adjust my code for these things to make it more accurate.

However - so far, I observe the following.

Firstly - on an ingress node that must encapsulate with a stack of srh headers - there is an assumption that the encapsulation is always going to be correct as regards the various node sid sizes and behaviors.  For example - if you were to create something using purely next behavior - and in the network you were running a combination of 16bit and 32bit - the assumption is that the node receiving the packet is configured for that size - and the shift it does on the address matches that size.  However, if the encapsulation is wrong - you could end up shifting 32bit when you meant to shift 16bit or vice versa - and ending up with some entirely undefined behavior - since the packet itself contains no information that lets the node determine the sid size its meant to shift by - it ASSUMES the encapsulating node got it right.  That seems very fragile to me.

This gets even worse in a mixed replace/next scenario.  Again - because the node receiving the encapsulated packet has no way to determine from what I can see, what is in that routing header, you can end up with a situation where a node applies replace behavior to what is meant to be next behavior or vice versa - and again - undefined behavior.  That's the very definition of fragile, since it assumes that either the controller always got it right, or in the case of something being statically configured for pathing, that the human who configured the path got the flavors right in their path definition - because there ain't no room for error there.

Then - we get to the issue of the encapsulation itself.  In the event that this is all controller driven - and the controller is constructing that SRH and the router is basically storing the SRH and just applying it - that's not gonna hurt.  However, if the router itself has to do a mixed construction - that - is a pretty performance heavy operation by anyone's standards.  Yes, the transit node can handle the behaviors at line rate - but the header construction at the ingress node makes me wonder about potential performance hits.  (there are ways to mitigate this - which are going to be implementation dependent, but it would be worth making some suggestions on this in the document)

Basically - what we've now got is a situation where - it can be argued these things can work together in the same domain - but the potential for breakage and undefined behavior is off the charts.  Without some way embedded in the packet to verify what behavior and sid size is in that routing header - I can see not only mistakes happening - but potential exploitable issues here - because of the potential for defined behavior against wrong data which will produce undefined results.

This is over and above the cases that Greg mentioned in his email - and in the simulation code - those things will be able to be simulated and it will become pretty clear as to the results.  But - as I said - if anyone sees any problems with my assumptions here - please - let me know and I can adjust the simulation code before release.

Thanks

Andrew