Robert, my problem here is – I believe that there could have been common ground found between various proposals except – what the current drafts do – is fundamentally rewrite the ipv6 protocol – the changes in the address semantics (twice over in incompatible ways between the programming draft and the uSID draft) – the violations of rfc8200 – etc – mean that – it becomes very hard to find a solution when there is a massive philosophical difference – where the philosophical difference is routed in – a v6 address is a 128bit identifier as defined by rfc4291 – vs – an address is well – insert a long list of other things on top of that.
We spent the better part of 25 years getting IPv6 to what it is – and now – fundamentally – there is an attempt to rewrite the very thing that IPv6 is – and therein lies one of my major problems – and no matter how many times I have raised the semantic issues – it seems to be an issue that is being blindly ignored. Tell me – how do you do aggregation of addresses in the network programming draft – aggregate – lose the function bits How do you do uSID in the network programming draft – shift – lose the function bits – or – retain the entire stack – and lose the entire point of uSID in the first place – to solve the overhead By rewriting the IPv6 specification in the way this does – it introduces draft after draft to cater for what is essentially no longer IPv6 – vs – finding a way to work within the IPv6 specification to produce the same functionality as is required in a compatible manner that is more efficient. Therein I believe lies half the root of this – on one side – you have an attempt to redefine an entire protocol that was 25 years in the making in the image of what one group of people believe it should be – on the other side – you have an acknowledgement of required functionality – and an attempt to provide it while not rewriting the entire protocol in the process. Andrew From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Robert Raszuk Sent: Friday, 6 September 2019 11:18 To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> Cc: Fernando Gont <fg...@si6networks.com>; spring@ietf.org; 6...@ietf.org Subject: Re: [spring] Question about SRv6 Insert function Ron, > They remind us that draft-ietf-spring-network-programming are far from > maturity. To me it actually highlights something quite contrary. It is that some folks are pretty far from appreciating or even grasping the value of the proposal. In your other note you have extensively elaborated well on how to effectively kill innovation in IETF. If we would be following your advice there would be almost non documents which build on former work and update former work. But most importantly documenting something does not force anyone to actually use it if they choose so. This entire smoke about header insertion from what I have been told has some technical concerns about real source awareness about say MTU issues. Well for one if I am doing insertion in my network I better make sure I do not drop the packet based on the MTU. It is so basic ... of course I must clean up when I fwd the packet to other domain but this is basic network hygiene. In the same time folks are happy to encap + add EHs, DOs etc ... on the grounds that src of the encap will be in the packet. Is this sufficient .. even if ICMP is sent to such src (domian ingress) I bet such domain ingress will not notify the original packet src anyway. And with encap the packet gets much bigger anyway. But I was not part of v6 creators and I think I will keep it that way based on that little thread we had here :) Best, R.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
