Hi Paul, Thank you for your review and comments.
Please see zzh> below. -----Original Message----- From: Paul Kyzivat <[email protected]> Sent: Saturday, September 4, 2021 12:49 PM To: [email protected] Cc: General Area Review Team <[email protected]> Subject: Gen-ART Last Call review of draft-ietf-bess-evpn-bum-procedure-updates-09 [External Email. Be cautious of content] I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!NEt6yMaO-gk!W0Qg_GJNKPW9qxyacZa9GrMR4O0HrEFl8S5yRxLO1hOD_VPsIHq7quz78j2zMaGr$ >. Document: draft-ietf-bess-evpn-bum-procedure-updates-09 Reviewer: Paul Kyzivat Review Date: 2021-09-04 IETF LC End Date: 2021-09-07 IESG Telechat date: ? Summary: This draft has serious issues, described in the review, and needs to be rethought. General: My review of this document is limited because I have no knowledge of the subject domain. Nevertheless I think I was able to grasp the gist of what this document intends to achieve and identify a concern. However it is possible that I have misunderstood and so my comments may be off base. While I have no reason to doubt the mechanisms specified, I think the manner in which they are specified is likely to lead to confusion and misunderstanding by developers. IIUC, RFC7117 improved the handling of BUM traffic for VPLS, but did not address BUM traffic for EVPN. Then RFC7432 specified how to handle BUM traffic for EVPN while referencing RFC7117 for some of its procedures, even though RFC7117 had no provision for support of EVPN. It appears to me that someone who had an implementation of RFC7117 for VPLS might have had to modify it to support RFC7432, yet RFC7432 did not indicate that it updated RFC7117. The developer would have had to infer what changes were required. But at least the changes seem to be small and unlikely to be misunderstood. Zzh> RFC7432's reference to RFC7117 is informational (so that people familiar with 7117 can easily relate to the similar procedures), and it (RFC7432) covers "inclusive P2MP tunnel" only (when it comes to BUM support), i.e., all BUM traffic (from a PE) goes into a single P2MP tunnel that reaches all other PEs, whether a PE needs to receive traffic or not. That inclusive tunnel is also un-segmented. Zzh> RFC7117 itself does also cover selective and segmented tunnel (for VPLS), and this document, covers selective and/or segmented tunnel for EVPN. The current document specifies in its heading and abstract that it updates RFC7432, while not mentioning RFC7117. Yet section 2 says: ... For brevity, only changes/additions to relevant [RFC7117] and [RFC7524] procedures are specified, instead of repeating the entire procedures. From these it is ambiguous whether RFC7117 is or is not being updated. zzh> This document does indeed not update RFC7117/7524, which is for VPLS/MVPN not for EVPN. Zzh> However, since most of the selective/segmented tunnel procedures for EVPN are very similar to those in RFC7117/7524, we decided not to repeat them in this document, but to refer to 7117/7524 with modifications pointed out. It then goes on to state: Note that these are to be applied to EVPN only, and not updates to [RFC7117] or [RFC7524]. This further clouds things. How could it be known how future updates to those documents might interact with the changes in this document? Zzh> As explained above, the intention is to refer to existing procedures in RFC7117/7524 with modifications pointed out for EVPN selective/segmented tunnels. Those modifications are for EVPN only not for VPLS/MVPN. In the remainder of the document I find no explicit text that appears to normatively updates RFC7432. I find this mystifying. Zzh> All procedures in this document (including those referring to 7117/7524) are additional optional procedures that 7432 does not cover. However there are numerous places that normatively change RFC7117. Several of these are of the form: The following bullet in Section N.N.N.N of [RFC7117]: ... is changed to the following when applied to EVPN: ... even though RFC7117 didn't contemplate supporting EVPN at all. This seems to assume that an entirely different implementation of RFC7117 will be made for EVPN and these modifications made to that, while not impacting implementations of RFC7117 being used for other types of VPNs. Is this a reasonable assumption? Zzh> Yes. Zzh> RFC7117 is for VPLS, which predates EVPN. EVPN comes later and is specified in 7432, though 7432 has informational reference to 7117 when it comes to "inclusive non-segmented P2MP" tunnel, and this document refers to 7117's selective/segmented tunnel procedures with modifications pointed out. Overall it seems that it will be very difficult for a developer to read this document and determine exactly what must be implemented, or after the fact to determine whether an implementation conforms to this document. IMO a different style of specification is called for. Probably an RFC7117bis and perhaps a RFC7432bis. Zzh> Hope my explanation above is making things a little bit clearer now. You can see that it is definitely not a RFC7117bis; it is not a RFC7432bis either (rather it is an extension to RFC7432). Zzh> I can put in some text to explain the above in the document, and any suggestions are appreciated (quite often I take things for granted and not realizing where/what can add clarity). Zzh> Thanks! Zzh> Jeffrey Juniper Business Use Only _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
