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? 2. I do not think that the term “legacy” is appropriate for IPv4 and IPv4 based services. 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. 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. 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. 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. 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. 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. 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. Thanks, Ketan From: BESS <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; 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 https://www.ietf.org/mailman/listinfo/bess