Zafar, While I am not going to answer all the points in your email – I am going to raise one issue. You talk about NOT debating a solution. I point out that it was also stated in Montreal that we needed an analysis of the IPv6 address space required by the network programming and usid drafts. Can I ask when we will get an indication of this? Since unless we are reading this wrong – it is a *vast* amount of space – and until such time as we know that – it is not possible to put the policy change proposals before the RIR’s without any more than an estimate based on our interpretations. While I’m quite happy to go ahead with others to propose policies in the RIR space to get the space allocation proposals changed to meet the requirements of this document – I would rather do this being able to state clearly in the policy where the numbers come from.
As of right now – you are sitting there pointing at problems – that’s ok – others have shown problems in what you have put forward. We will however respond to each of your issues – and that is more than I can say is happening right now from the SRv6 NP fraternity. I have asked multiple times regarding the change in address semantics as defined in RFC4291 – I have zero reply on this. I have raised the issue of inflation of IGP – the only answer I have had is to renumbering my network (which in my book equates to interference of already existent deployments – please see the spring charter on this). I have also stated quite categorically – that I do not wish to see the work on SRv6 stopped – on the contrary – I believe that two alternatives make sense – I believe in operator choice – and indeed – I point to the fact that I explicitly proposed that we work together on an inter-op draft and was explicitly told that there was no interest in this from the authors of these drafts. The chairs also explicitly asked why anything we necessary beyond SRH – and when you turn and attack based on lack of justification – I have yet to see a single justification for similar in the uSID draft – so – lets be a little consistent here. I also point out – that I and others HAVE stated why we need something more – the overhead of SRv6 for my network – and many others – is simply untenable. uSID does not solve that problem without introducing a whole RANGE of other issues. So – lets now put this simply a.) CRH/SRv6+ does not redefine the IPv6 address semantics – SRv6 NP does – uSID does again (in a way that is incompatible with SRv6 NP I might add) b.) CRH/SRv6+ does not require the (massive) overhead that SRv6 imposes c.) CRH/SRv6+ does not do header insertion or header removal in violation of a standard that already has consensus from the community – SRv6 NP does d.) ISIS extensions for CRH do not propose to cater for header insertions or header removals – the SRv6 draft-ietf-lsr-isis-srv6-extensions explicitly does e.) CRH/SRv6+ does not collapse the network routing function, the programming function and the addressing function all into the same thing – SRv6 does – creating in my view significant complexity and operational headaches f.) When asked about binding SID’s – we stated we could support each and if given the use case we would – though we do point out that because of the overhead savings on traditional SRv6 we believe we can demonstrate that this may not be necessary – we are prepared to do it. On the contrary – I am still yet to understand how inter-domain operation of SRv6 will actually function With regards to your points about its all already developed – are you really telling me that because the authors chose to go and spend ages developing something while taking zero cognizance of the consensus in the community on both the semantics of addresses and issues like header insertion and removal – just because you ignored them and wrote the code we are now meant to rubber stamp it? While at the same time – instead of working on resolving the issues that have been raised here time and again – you continue to fight to squash something that multiple people have said should go ahead? Andrew From: spring <spring-boun...@ietf.org> on behalf of "Zafar Ali (zali)" <z...@cisco.com> Date: Saturday, 7 September 2019 at 19:17 To: Ron Bonica <rbon...@juniper.net>, Shraddha Hegde <shrad...@juniper.net>, Rob Shakir <ro...@google.com>, SPRING WG List <spring@ietf.org> Cc: "Zafar Ali (zali)" <z...@cisco.com> Subject: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.) Ron, > There hasn't been a single mail denying the above advantages of SRv6+ Among many comments from many operators and vendors, please see, https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4 We must remind you that the original questions from the Spring chair were NOT on debating the solution. Furthermore, during Spring WG meeting, Bob (6man chair), said: [Bob Hinden] As 6man co-chair, would like to understand whether SPRING is interested in this (CRH) work. A clear message would be useful to ensure that 6man spends time usefully [https://etherpad.ietf.org/p/notes-ietf-105-spring]. • You ignored the chair’s direction. • You added 6man WG for some unknown reasons. Since you added 6man to this Spring discussion on the “requirements”, among many other things, the two WGs witnessed: • Spring chairs and AD were repeatedly flamed. They had to defend [https://mailarchive.ietf.org/arch/msg/spring/ZFm_bQP1-C2f9xJuXtvEd9mLoxU] • 6man AD/ chairs had to defend, e.g., https://mailarchive.ietf.org/arch/msg/spring/zfr-dCuSHSJRjE2NkJbfjuWoCi4. • An atmosphere that the Spring and 6man are disconnected was created. • Heated discussions (that are not on the table). • Etc. Not to mention, many lost their sleep, long weekend, hair, deadlines; gained blood pressure/ weight, etc. ;-) Unfortunately, there is a trend. The same has been tried against SRv6, again and again. • Without success. • Huawei has deployed. • Cisco has deployed. • Several operators have reported significant commercial traffic at linerate forwarding. • Linux and FD.IO open-source stacks are available and have been used in deployments. • Several interoperability tests have been reported. • Numerous SP’s are clearly asking SRv6 in RFP, and the deployment prospect in 2020 and 2021 is significant. In summary, Can you please follow the directions set by the chairs and stop creating email threads? This is not how we are supposed to promote technologies at IETF. Thanks Regards ... Zafar From: Ron Bonica <rbon...@juniper.net> Date: Friday, September 6, 2019 at 1:34 AM To: "Zafar Ali (zali)" <z...@cisco.com>, Shraddha Hegde <shrad...@juniper.net>, Rob Shakir <ro...@google.com>, SPRING WG List <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org> Subject: RE: [spring] Beyond SRv6. Zafar, Your memory is selective. In the SPRING session, many people argued that “SRv6 was nearly complete and we didn’t need another solution”. But I don’t remember anybody arguing against the technical merits of SRv6+. If you can make a technical argument against SRv6+, I encourage you to do so. I look forward to a gentlemanly exchange. Ron Juniper Business Use Only From: Zafar Ali (zali) <z...@cisco.com> Sent: Friday, September 6, 2019 12:53 AM To: Shraddha Hegde <shrad...@juniper.net>; Ron Bonica <rbon...@juniper.net>; Rob Shakir <ro...@google.com>; SPRING WG List <spring@ietf.org>; 6...@ietf.org Cc: Zafar Ali (zali) <z...@cisco.com> Subject: Re: [spring] Beyond SRv6. <snip> >SRv6+ is definitely a better proposal in terms > 1.Adherence to IPv6 Architecture > 2.Efficient encoding > 3.Operational simplicity > > There hasn't been a single mail denying the above advantages of SRv6+ This is absolutely false! Have you forgotten the very strong arguments against it at the Spring session in Montreal and the various emails on the list that echoed them 😉 Not to mention comments from Robert R (https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo). Yes, indeed Ron presented the proposal to every workgroup possible in Montreal, only to find no interest from anyone. I would advise you to read that silence differently. 😉 <snip> _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
