The problem is – I’m not convinced we have reached such an agreement – far from it.
My view on this is that – and I have stated this many times – I have no problem with the standard moving forward – providing that it does not violate other well defined standards (rfc8200 etc) I also as I have stated multiple times – and which have never been addressed have concerns about 1. The burn of address space required to adequately deploy some of this (something that there was agreement on in Montreal that there would be analysis on – which was never done) 2. The potential problems we could run into as regards RFC7112 in deep SID stack environments 3. The inflation of the IGP created by the fact that you now need to run both your normal loopbacks and your SID’s Points (a) through (c) though – are all things that I can kinda live with going into the standard – why – because I view this standard as overly complex, an operational nightmare, and nothing I will ever run on my network – but I accept that others may wish to use this and deal with those issues as they come up and each network should make its own decisions. What I cannot however live with – is the violation of rfc8200 which could cause unintended side effects. And so – while I do not stand opposed to this moving forward if the violations of other RFC’s are resolved – in no way shape or form can it be said that myself, and several others, believe that this brings advantages to our environments – indeed – I would argue it would bring an absolute nightmare and as such – I can say categorically that even if it proceeds – it won’t be deployed on my network. (Please refer to https://mailarchive.ietf.org/arch/msg/ipv6/AaK6S2IOjWGQWbOT3bvv53U7EMc/ for more of my thoughts on this issue) Andrew From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Maojianwei (Mao) Sent: Thursday, 27 February 2020 12:30 To: Lizhenbin <lizhen...@huawei.com>; bruno.decra...@orange.com; 'SPRING WG List' <spring@ietf.org> Cc: 6...@ietf.org; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programm...@ietf.org> Subject: RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming Hi friends, Internet standard is aimed to promote deployment and innovation, but not to be a barrier. While this WG LC has been extended again and again, if we have reached an agreement that SRv6 can bring many advantages for our network in future, we should shelve the dispute and promote industry. Meanwhile, we can have a discussion in the future about how to resolve the problem, bis 8200 or what else. So, I agree we close the WG LC now, and go ahead. Cheers~ Mao 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Lizhenbin 发送时间: 2020年2月26日 19:55 收件人: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 'SPRING WG List' <spring@ietf.org<mailto:spring@ietf.org>> 抄送: 6...@ietf.org<mailto:6...@ietf.org>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programm...@ietf.org<mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>> 主题: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming Hi Bruno and WG, The LC has lasted for almost 3 months which greatly exceeds the expected 2 week. In the process all the comments have been resolved while some issues is raised again and again with little value. On the other hand, there have been multiple commercial implementation and inter-op test and almost 20 deployments for SRv6 which justify the solution proposed by the draft in practice. We sincerely request to close the LC of the draft and move forward. Best Regards, Zhenbin (Robin) From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> [mailto:bruno.decra...@orange.com] Sent: Friday, December 06, 2019 1:15 AM To: 'SPRING WG List' <spring@ietf.org<mailto:spring@ietf.org>> Cc: 6...@ietf.org<mailto:6...@ietf.org>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programm...@ietf.org<mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>> Subject: WGLC - draft-ietf-spring-srv6-network-programming Hello SPRING, This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1]. Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20. You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics. If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point. This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions) Thank you, Bruno [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
