> what the current drafts do – is fundamentally rewrite the ipv6 protocol
I think you are giving small team of focused engineers way too much credit here :) What they tried to do is to merely make sure that if someone decides to use IPv6 they have a chance to not only have functional parity with other transports, but also could go a bit forward and turn v6 transport into more innovation. In that respect objectives of both SRv6 and SRv6+ are identical. Now having seen stones being smashed at those who try to actually improve IPv6 I am personally even more discouraged. It is now becoming even more obvious why adoption of IPv6 in enterprise networks, enterprise compute clusters or end users is so marginal after 25+ years .... Cheers, R. On Fri, Sep 6, 2019 at 10:27 AM Andrew Alston < andrew.als...@liquidtelecom.com> wrote: > 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
