Andrew, Please see inline the answers with PC2.
Also, I guess that by mistake, your inline emails remove this text from your original email and my reply to it. Let me copy paste it in here to make sure it is not lost. From Andrew on March 2nd: The promises to deliver an assessment of IP Space burn as per what is on video from the montreal meeting – was not delivered on or addressed Pablo on March 4th: PC1: Authors do not recall such a promise. Can you please point me at either a) an email URL; b) SPRING WG meeting minutes; c) SPRING WG meeting recording (with precise minute and seconds) where such promise happened? Technical points inline below. Regards, Pablo. From: Andrew Alston <andrew.als...@liquidtelecom.com> Date: Friday, 6 March 2020 at 06:36 To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, Martin Vigoureux <martin.vigour...@nokia.com>, "spring@ietf.org" <spring@ietf.org> Cc: "6...@ietf.org" <6...@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programm...@ietf.org> Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming From: Pablo Camarillo (pcamaril) <pcama...@cisco.com> Sent: Wednesday, 4 March 2020 15:17 To: Andrew Alston <andrew.als...@liquidtelecom.com>; Martin Vigoureux <martin.vigour...@nokia.com>; spring@ietf.org Cc: 6...@ietf.org; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programm...@ietf.org> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming Andrew, Inline. PC1. Regards, Pablo. From: Andrew Alston <andrew.als...@liquidtelecom.com<mailto:andrew.als...@liquidtelecom.com>> Date: Monday, 2 March 2020 at 20:56 To: Martin Vigoureux <martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> Cc: "6...@ietf.org<mailto:6...@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>> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming Resent from: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent to: <c...@cisco.com<mailto:c...@cisco.com>>, <pcama...@cisco.com<mailto:pcama...@cisco.com>>, <j...@leddy.net<mailto:j...@leddy.net>>, <daniel.vo...@bell.ca<mailto:daniel.vo...@bell.ca>>, <satoru.matsush...@g.softbank.co.jp<mailto:satoru.matsush...@g.softbank.co.jp>>, <lizhen...@huawei.com<mailto:lizhen...@huawei.com>> Resent date: Monday, 2 March 2020 at 20:56 I am completely stunned by this. The question regarding RFC8200 is still unaddressed. PC1: PSP complies with RFC8200. https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk/<https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk> https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/<https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk> https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/<https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw> https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/<https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM> https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/<https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0> https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/<https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso> https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek/<https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek> https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58/<https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58> This is highly – highly disputed still – by multiple parties – and repeatedly claiming something that is wrong does not make it somehow right. In fact to claim that it doesn’t flies in the face of the last call write up which says that this needs to be adjudicated by the IESG. PC2: Text in RFC8200 is crystal clear. PC1: Also, I do not understand the issue or what “IP Space burn” you talk about. Please see this: https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0/<https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0> Was this your question? Please see around minute 22 for the next couple of minutes in https://www.youtube.com/watch?v=WuoJWecyATQ which specifically calls for a credible discussion around IP space usage and agreement to have such a credible discussion, which has not occurred. PC2: The comment started because in the draft we had an example that was assigning A:1::/32 as loopback interface for a router. This is wrong (prefix length, documentation prefix,). This was fixed in revision 2 of the WG draft, published in September 19th 2019. The closure of this comment was presented by me personally in IETF Singapore. Please refer to the slides. In Singapore you were present (signed blue sheet) and did not had any comment about such closure. PC2: Still, if you want to discuss technically: please let me know what is unanswered after reading this email https://mailarchive.ietf.org/arch/msg/spring/34s0MNMsXe7lTYJr1jw-xBpoRp0/ The issues around the potentially problems in relation to rfc7112 – have never been addressed or commented on. PC1: RFC7112 considerations apply to all extension headers including SRH. I do not understand the relevance of it with Network Programming draft. The concern here is around the SID size and deep SID stacks in the face of 128bit SID’s. PC2: Neither this document, nor this working group, is defining the Segment Routing Header. That was done at 6man. If you think there are considerations from RFC7112 that should apply particularly for the SRH, please raise it there. That said personally I don’t believe that there’s any consideration from RFC7112 that should apply particularly to the SRH. Andrew
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
