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

Reply via email to