Hi Gyan, Thanks for your quick and detailed response. Please check inline below.
From: Gyan Mishra <hayabusa...@gmail.com> Sent: 17 April 2021 12:10 To: Ketan Talaulikar (ketant) <ket...@cisco.com> Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; bess@ietf.org; draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 Hi Ketan Thanks you for your feedback on the draft. Most of your comments have been mentioned on the ML are being addressed in the next draft update. Responses in-line Many Thanks!! Gyan On Sat, Apr 17, 2021 at 12:21 AM Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: Hello Authors, A few comments/observations on this draft: 1. The BCP categorization does not seem right for this document and perhaps informational is better. Is this really something that has already seen widespread deployment such that the IETF community can say that it is the best “current” practice? Gyan> This draft addresses a real issue that has been discussed at NANOG and other operator groups around the world related to IXP major peering points where 1000s have IPv4 & IPv6 dual stacked peering exist and IPv4 address depletion have been a major issue issue for many years now. Operators around the world are clamoring for a solution that can help with worldwide address IPv4 depletion issues at the IXP peering points. With this solution IXPs as well as all infrastructure Core, DC PE-CE public or private can now utilize this solution and reap the benefits immediately on address space saving. This can be used for IPv4 core or IPv6 core and I will clarify in the draft. All infrastructure peering with this draft along with RFC 5565 now becomes officially IPv6-Only. [KT] I am not questioning the need for a design to address this problem space. It is real and relevant – something that the WG should take up. So thanks to the authors for bringing this up. Just emphasising it, in case anyone got a different impression from my initial response. With this draft as it stands today as a BCP, the POC QA testing from the 5 major vendors that make up almost 90%+ of the router and switch market share Cisco, Juniper, Arista, Nokia, Huawei, the idea is that all other vendors will follow suit and adopt this BCP and implement and support this solution to help with IPv4 address depletion issues faced by their customers. We not trying to be not inclusive of all vendors, as it’s impossible to test every vendor. With this draft being a BCP, as strategy, we would now once this draft is published as a best practice be able create an industry shift momentum that now all operators all around the world including Verizon as well as other tier 1 carriers as well as Tier 2 and 3 and all ISPs can use this solution immediately and start deployment once this draft becomes an RFC. This will also help with the underlying goal of worldwide IPv6 proliferation. [KT] This is my concern exactly and I think we perhaps differ on the definition of BCP. As also, differ on the use of IETF stream RFC as the means for publication of interop test results. I will suggest to the authors as well as the WG to consider using such a document for capturing the design as informational. More specifically, I will recommend somewhat on similar lines as RFC7938 or even draft-ietf-mpls-seamless-mpls (even though the later didn’t get to RFC). That, IMHO, would be valuable for everyone in the community (including vendors and operators). 2. do not think that the term “legacy” is appropriate for IPv4 and IPv4 based services. Gyan> Understood. I can remove the word legacy 3. RFC5565 specifies the dual-stack PEs and IPv6-only P routers for delivering IPv4-based BGP services between the PEs via various mechanisms. This proposal brings that notion to the PE-CE link. The CE is dual-stack and the PE is IPv6-only. However, it is not describing how the forwarding plane works between PE and CE – an explanation or reference is required and without that clarity I am unable to understand how to actually deploy this. Gyan> The next update will have a section that talks about IPv4 forwarding plane processing without an IPv4 address. Both the PE and CE will not have an IPv4 address, but will be able to process and forward IPv4 packets. The concept is very similar to the cisco “IPv6 enable” command where you don’t need an IPv6 address configured on the interface for IPv6 processing and forwarding. Juniper and Nokia have tested and confirmed they have a CLI command for IPv4 forwarding without an IPv6 address. We are investigating a similar IPv4 forwarding option with the other vendors including Cisco. This is part of implementation space and each vendor will have their own existing knob if one exist or create a new knob for IPv4 forwarding without an IPv4 address. The PE-CE IPv4 forwarding without an IPv4 address configured with all the functionality and line rate processing capabilities will all be major part of the QA interoperability POC and test results. [KT] This is the heart of the matter and the most critical part for the design that we are talking about here. I am afraid some of these mechanisms are not standardized. Even on this adoption call, I thought I saw some assumptions (maybe I read that wrong?) being made about the use of MPLS as the data-plane. The draft in the current state is missing this most important part. 4. The document touches on IXP deployments, but again does not actually cover how the forwarding works nor provides references for how this proposal works for that deployment. Gyan> Answered above 5. Is section 4 really required? Wouldn’t a simple reference to RFC8950 suffice? The BGP signalling part for IPv4 over a single IPv6 peering and over IPv6 NH is already specified and covered in various Standards Track document (esp RFC8950) – so using their references rather than repeating them would be better. Gyan> As the draft pertains to PE-CE edge IPv6 only peering the use cases involved end to end forwarding over all permutations of DC or Core scenarios including both IPv4-Only and IPv6-Only core so I will be adding a section that talks specifically about the PE-CE IPv6 only peering in relation to RFC 5565 v4 edge over a v6 core and v6 edge over a v4 core. So as the core peering is all in scope as part of the interoperability testing we will keep the RFC 8950 section in the draft as it would be relevant in the POC. I will update that section as to how the RFC 8950 update to RFC 5549 is now relevant to the interoperability testing. [KT] That was really an editorial comment. Will look forward to those details that you mention for both PE-CE and IXP designs. 6. If/when this gets published as an RFC, is the goal of this document to describe interop test results between specific vendors, OR is it do document the design, its operational considerations, and how it can be realized? E.g. RFC7938 – does something of that sorts. I do not think that IETF RFCs are good for documenting interop and it is better done via other “live” documents since these aspects change over course of time. It might even give an exclusionary impression for vendors not included in this document or those who might add this capability down the line. I’ve generally seen implementation status sections being taken out of Standards Track documents before publishing as RFC. Gyan> Answered in #1. This draft document the design solution to a problem and as a BCP will allow operators to have the comfort level to start deployments immediately once published. The test results currently in the Appendix will all be moved to Section 3. [KT] So you are proposing to publish interop testing reports in an RFC that is going to be a BCP? Again, I don’t believe this is the right approach and will let the chairs and others in the WG advise. 7. I would request the authors to explicitly clarify the Objective/Purpose of this draft in more precise and crisp manner in a section of its own so the WG knows what it is taking up. It might also help repeating the same throughout the document. Gyan> Understood. I will clarify in the next update. 8. Finally, there is some language as follows in Sec 3 which perhaps needs to be revisiting? The test results published from this document provide concrete evidence that this is now the Best Practice for Edge peering. The document will be the de-facto standard for operators to now use a single PE-CE Edge IPv6 peer to carry both IPv4 and IPv6 NLRI. Gyan> I will clean up the language. Would also request the WG and chairs to share their views on some of the above points – (1), (2), (6) and (7). Clarity on these points is, IMHO, important and necessary before the WG considers adoption of this document. Gyan> I have complied all the feedback from the adoption call thus far including your comments, and will be submitting the updated draft this weekend. [KT] Will look forward to that update since I am hoping that it will clarify the goal/purpose of the document better (at least for me). We agree on the need to address the problem statement – my concerns are on how to go about it and if this document (in the current/updated form) provides the right platform for it. Thanks Ketan Thanks, Ketan From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of Bocci, Matthew (Nokia - GB) Sent: 13 April 2021 15:07 To: draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org<mailto:draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 Hello, This email begins a two-weeks WG adoption poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1]. Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document will not progress without answers from all of the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on April 27th 2021. Regards, Matthew and Stephane [1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/ _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
