Ok, so couple of things. I really think we need to clearly and totally divorce the comments on this list from those around SRH – since – there seems to be this kind of bizarre conflating of two issues, and while it’s a nice piece of obfuscation – let’s be clear on a number of things.
1. Almost every objection on this list that I have seen has related directly to the NP and uSID drafts – not towards the SRH draft which does not sit within this working group. The primary problem I see with the SRH draft is around overhead – and well – if people wish to live with that level of overhead – so be it – but, that does not relate to the complexity, the violations of RFC8200 and the wholesale re-definition of the address semantics as defined by RFC4291 that have been objected to here – those issues are directly related to the NP and uSID drafts. Let’s be clear on that. 2. The constant citing of a marketing document – where almost everything in there is related to the use of SRv6 in the context of the SRH – again – not in this working group – with little evidence or citation of use of the NP draft or the uSID drafts which are what we sound be discussing here – is, in my view, really stretching for support – through an obfuscation of items that while related are not the same thing Now, there is also an argument I have seen that you should not have two things that solve the same problem. So, lets talk about the CRH for a second. CRH does not address the same issues that the NP draft does – it addresses an insane and inescapable overhead issue. In the process of doing that, it provides, in my view, a cleaner version of the functionality of that contained in the network programming draft and the uSID draft, without header insertion and without the burning of absolutely insane amounts of address space. So again – let’s not conflate issues here. Now – I would ask this, and I have asked the questions before and not seen them addressed – if they have been – I would be more than happy to be corrected and be pointed to the emails that address these things 1. Can someone explain how with the use of NP proper aggregation is going to work 2. Can someone please – as per the request made by the chairs in Montreal – supply an indication of the address space burn that is required – both in terms of the uSID draft and the NP draft 3. Can the authors please explain how either of these drafts is proposed to work in either an inter-asn or inter-igp area scenario – or – is this explicitly and unequivocally designed to work only within a single domain – and if that is the case – I’d be happy to explain how this would work with CRH – and why there is an additional requirement for CRH beyond the removal of the overhead 4. In the case of uSID – can we get an explanation of how it is compatible with the network programming draft outside of end point programming – since the way I see it – if you’re shifting bits to effectively perform “routing by NAT” – you’re throwing away the locator bits as defined in the network programming draft. If the answer to this is to retain the entire SID list – then the overhead reduction disappears – and at which point, please can someone explain to me why you would run uSID at all if you are doing this. 5. Since we have had constant references to multiple platforms supporting this – can we get a list of actual vendors and hardware that support the NP and uSID drafts in production today – not SRH – NP and uSID – and inter-op tests between these platforms. Let’s separate the issues here. I will also say – I do NOT oppose work continuing on SRH and SRv6 – never have – never will. I also do not oppose work continuing on either the NP or uSID drafts – provided the issues that have been raised – time and again on this list are addressed. However, I will also state that I do not believe that CRH performs the same function as the NP draft, what it does is include the functionality involved in the NP draft, while solving an overhead issue – and on that basis alone, outside of many other reasons, I believe that work on it should continue. Over the last few days reading emails on this list – I fear a situation where both sides (and I include myself on this), are feeling the need to attack each other – and block the work on “opposing” drafts. Now, I can easily see how this could arise – but – I’ll also say that I don’t think its in the interests of the industry, or the operators, or well, anyone. I would far rather see a situation where we work towards a productive solution – let work continue on all of this, and then let the industry decide which they want to use, and indeed, work towards a productive solution where we have some interoperability. And yes, as was alluded to, I did raise the possibility of an inter-op draft to facilitate forward movement here, and I had only one vendor out of all the vendors I approached actually indicate opposition to this, so I would ask now directly on list, can we work towards a situation where instead of all blocking each other – work continues and we find a way to play nice, and indeed, inter-operate? I really fear that the alternative is that this fight drags on forever, and in the mean time, vendors and operators alike continue to develop and deploy outside of the standardization – and every day that continues – we move further away from being able to find a sane way to inter-operate. There is a phrase that I have heard – and perhaps it applies here – perhaps we need to put our guns down – and find a way to in which we can move forward that while it probably will not satisfy everyone, will be in the interests of the market in general by avoiding a total standoff. Just my thoughts Andrew From: Zafar Ali (zali) <z...@cisco.com> Sent: Wednesday, 11 September 2019 07:27 To: Aijun Wang <wangai...@tsinghua.org.cn>; 'Robert Raszuk' <rob...@raszuk.net>; 'Sander Steffann' <san...@steffann.nl> Cc: 'Ron Bonica' <rbonica=40juniper....@dmarc.ietf.org>; 'SPRING WG List' <spring@ietf.org>; Andrew Alston <andrew.als...@liquidtelecom.com>; 'James Guichard' <james.n.guich...@futurewei.com>; 'Shraddha Hegde' <shrad...@juniper.net>; 'Rob Shakir' <ro...@google.com>; 'Voyer, Daniel' <daniel.vo...@bell.ca>; Zafar Ali (zali) <z...@cisco.com> Subject: Re: 答复: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.) <snip> Hi, Robert: But the concept of SRv6+ is more clear than the SRv6(topology/service instruction separation; different instruction carried in different IPv6 EH). Hi Aijun, Can you please various thread to gauge the complexity, incompleteness and why CRH (aka SRv6+) makes no sense, e.g.,: * Countless responses from Robert, includinghttps://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE<https://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE> * Many responses like https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4<https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4> * Many responses from Dirk, including https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM<https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM> * Excellent points from Dan https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4<https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4>. * Many reasons like https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ<https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ> Hope it helps, Thanks Regards … Zafar <snip>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
