Hi Stefano, Stefano Salsano wrote on 23/10/2021 01:29:
if an operator wants to combine CSIDs of different length, building the debug tools becomes more complex, but this actually depends on the specific choices and configurations
Exactly. For example, problems will occur when the operator changes SID length inside their domain, or attempts to interoperate with other SRH domains (either within the same or with different administrative domains), or merges with another network which uses with a different SID length.
From the point of view of operations and management of production networks, if a protocol allows for a variable length parameter, but doesn't explicitly encode the length of the parameter, then this introduces protocol ambiguity. Protocol ambiguity is toxic on production networks because it causes breakage which is difficult to diagnose and may be impossible to fix.
If the SRH compression draft proposed to encode the compressed SID length for each instance of a C-SID in the header, then this problem goes away.
On this basis, I'm objecting to the adoption of draft-filsfilscheng-spring-srv6-srh-compression as a WG draft, and respectfully suggest that the spring wg does not adopt any draft in future which allows for different C-SID lengths but doesn't encode C-SIDs as {length,value} tuples.
Nick _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
