Ted, I don’t think anyone would dispute that supplementary information is necessary for various purposes. The question becomes – how much supplementary information – where that supplementary information is coming from – and how much correlation you need to do to get to meaningful information.
Each time you add a step in this process and force an additional piece of information into the chain to make something more useful, you increase complexity and you create a situation where debugging and tracing and other such things become more and more reliant on external software and routines. This in turn increases cost and decreases the ability of operators to handle this in the absence of complex tools. So sure, for the vendors, it may be in their advantage to introduce more and more complexity to force more and more software, but this is very much not in the interests of the operators. It's here where I think we often end up in a divergence between practical operation and fancy ideas – and between vendors and operators. From the operator perspective, that which is simpler and makes it easier to have their own engineers operate it, debug it and run it, without spending millions on tools, makes a lot of sense. The reverse in true in the vendor world – where complexity serves to increase revenues (though often ends up in operators having to choose between investment in network hardware vs investment in vendor tools to run said network) Now, is this an argument that is “technically relevant” in terms of an IETF standard – many would argue no – but there are very practical considerations here when considering how a standard will be used and deployed. The level of complexity and lack of debuggability and the obfuscation that I see in all of this, is the same concern that I am seeing echoed in every NOG meeting I am in – and while it may not be directly relevant to the text in a document, it does carry relevance to the end users of the protocol – the operators. There is in essence – a commercial conflict between these two things – which is outside of the realm of the IETF – but – unless we can find harmonization between the operators and the vendors on such things, we will end up in deeper and deeper stalemates that are not in anyones interests. Therefore, reducing the complexity involved in debugging and operating something, will decrease resistance during the standardization process. Furthermore, the more obfuscated things get, and the deeper the complexity, the more chance of pitfalls that are not seen until it is to late – and the growing risk of security problems that could not be foreseen until we have pushed something widely into the field. Andrew From: Ted Hardie <[email protected]> Sent: Monday, October 25, 2021 1:37 PM To: Andrew Alston <[email protected]> Cc: Eliot Lear <[email protected]>; Nick Hilliard <[email protected]>; SPRING WG List <[email protected]>; 6man WG <[email protected]> Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) On Mon, Oct 25, 2021 at 9:47 AM Andrew Alston <[email protected]<mailto:[email protected]>> wrote: > Of course there is. You cannot distinguish routing from host without looking > at external control channels, such as a routing or configuration protocol; > and you certainly cannot determine the subnet mask of a network without that > external information, since it's not in the ?> packet. And it's not even in > the control plane if the route has been aggregated. Does that make the > information "ambiguous"? The point is that the subnet mask of a network is > part of a context that you discussed, and you might not have it. This analogy doesn't really work for me. In the case of an SRH - the router acts on the packet based on local configuration - how it gets that config doesn't really matter. The SID size in use by each router may or may not be exposed by an IGP for reading - and could differ at each node. I think Eliot's main point is that there are aspects of a flow's routing through a network which are observable in a packet and there are aspects which are not. Think about a network which implements a flow-based equal-cost multipath; the determination of which flows take which path uses information in the packet but the algorithm that hashes it together and chooses a next hop is not. The practices about what to choose can vary significantly and to debug (or plan), you have to know a lot more about the network than what's in the packet itself. regards, Ted Hardie In the case of standard forwarding you have a FIB entry - inserted from the RIB - that goes a certain place. In the case of this - a router could be using either 16bit SID or 32bit SID - entirely configured locally - and dependent on the configuration - will determine if the node in question shifts the information by 16 or 32 bits - before the FIB lookup. Therefore - in a standard scenario - you know that packet X is going to be forwarded using a FIB entry lookup of Y - in the case of this - you have no idea what the router is actually going to be looking up - because you don't know if its going to be doing a 16 or 32 bit sid without knowing the specific local configuration on the router. That’s a very different level of complexity in terms of operations and debugging on a large network Andrew -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6> --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
