See, I disagree with this Elliot, What you have is several operators who are clearly stating – there are issues with this. And tool evolution is exactly what I am referring to – the tools may exist – but what will they cost? For myself, I’m in the lucky position that I have a team that can go out and write tooling if we need it – that will scrape configs for SID lists – that will integrate with our IGP – will take feeds from BMP – whatever – we do that all the time on internal tooling. The question here is – what impact will this have on the smaller guys who cannot afford to either build or buy such tooling.
This has a knock on effect – the smaller operators are restricted in what they can deploy – the inter-op starts getting restricted – the potential breakage due to available skills in the networks increases – the potential for leakage of who knows what also goes up – and we end up with something that runs contrary to the IETF statement – that is “To make the internet work better”. Adding complexity where it can be avoided using TLV’s – which are supported in the SRH – does not assist anyone. Modifying a spec by minor degrees such that the lives of the spec’s consumers are made easier, increases likelihood of adoption and decreases resistance – to me that just makes perfect sense. Andrew From: Eliot Lear <[email protected]> Sent: Monday, October 25, 2021 3:35 PM To: Andrew Alston <[email protected]>; Ted Hardie <[email protected]> Cc: 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) Hi Andrew, I don't disagree with your point that operational complexity hinders adoption. However... On 25.10.21 14:14, Andrew Alston wrote: It's here where I think we often end up in a divergence between practical operation and fancy ideas The problem is that one often can't tell the difference between the two without the benefit of hindsight, and perhaps several revs of the spec. IPv6 itself is a perfect example of that truth (cf, MIPv6, site-local, IPsec requirements, and geographic routing). But I write that with the benefit of hindsight in which we did find use for other v6 features, like flow labels. Right now we have a lot of speculation about how tools won't evolve to assist operators, and I'm sympathetic to that to a point: tools develop best out of operational experience. Eliot
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
