Keyur, Thanks very much for your review. Please refer to the comment resolutions below and let us know if there are any further comments.
From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of Keyur Patel <ke...@arrcus.com<mailto:ke...@arrcus.com>> Date: Monday, September 5, 2016 at 3:34 PM To: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Subject: [bess] RTG Dir QA review: draft-ietf-bess-evpn-overlay-04.txt Hello, I have been selected as the Routing Directorate QA reviewer for draft-ietf-bess-evpn-overlay-04.txt. The Routing Directorate QA reviews are intended to be a support to improve the quality of RTG Area documents as they pass through the IETF process. This is the QA review at the time of the WG document adoption poll. Summary: This document describes how Ethernet VPN (EVPN) [RFC7432] can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures. In particular, the following encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. The document is well written, easy to read and follow. Some minor comments are listed below: Comments: 1) Introduction section suggests xmpp based approach as an alternative to the BGP as a control plane. It is unclear how the draft sections 8-10 and the security section 12 relate to the alternative solution. My suggestion would be to remove the reference if possible considering the draft is specific to BGP as a control plane. Agreed. I will remove it. 2) Section 5.1.2.1 defines Autoderivation RT which suggests the use of 2 byte AS number. Do we need to consider 4 byte AS number as well? [??] No, Auto-derivation of RT will not be supported for 4-byte AS. 3) Section 6: Minor Nit. Consider replacing "statically" with "locally". Done. 4) Section 7.1: Talks about using RD value of 0. RD as a type:value field. Type 0 RD requires the usage of 2 byte AS number (private values are strongly discouraged) which needs to be 0 for RD value to be 0. AS 0 according to IANA is reserved. Seems to be like usage of AS 0 is prohibited. Would a reserve RD value be more appropriate? Since the recommendation is to use a unique RD value per RFC7432, the text corresponding to RD value of 0 is removed. 5) section 8.3.1 describes the draft constrain wrt mpls over gre versus vxlan/nvgre. Perhaps it would be great to highlight the constrain upfront in the introduction section? OK. We highlighted this constrain upfront in section 8. 6) Do you need to add text to describe ARP/ND suppression in presence of default route? That is covered in more depth in some other draft. Regards, Ali Best Regards, Keyur
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
