Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-bess-pbb-evpn-isid-cmacflush Reviewer: Russ White Review Date: 22 October 2021 Intended Status: Standards Track == Summary: This document is basically ready for publication but has nits that should be considered prior to publication. Overall, the document is readable--the labeling and layout of the diagrams can be confusing, however (see notes below on figure 1). The flow of the document is fine, and the solution description seems to be sufficient for a reader with knowledge of PBB and eVPN to understand what is being done to resolve the problem. Major Issues: None. Minor Issues: Based on the description given for figure 1, it seems that ISID1 is a single device connected once to CE1, once to CE2, and once to CE3. In turn, CE3 apparently has two connections into the PBB-eVPN network. If this is all correct, then I find the diagram confusing. ISID1 appears to be a _label_ for the three CE devices, rather than connected to them ... or are the three CE's actually the same device as ISID1? Or is ISID1 a different device, connected (according to the labels) to an MPLS Ag network and a G.8032 access ring? This configuration seems a little odd to me. The connectivity shown between PE3, PE4, and CE3 is not clear. Are there two links from PE3 and CE3, or one? If there is one, why are there two different sets of lines, one of which is labeled "vES null," and the other labeled with the state of the connection (act or stb)? What is the significance of this particular connection layout? The terms "act" and "stb" are not used anywhere in the text; in theory, somewhere above when the word "standby" is used, it would have a note saying "denoted as stb in the diagram below," or something similar. Otherwise, the reader is left trying to understand what the labels "act" and "stb" mean. What is the significance of the "MPLS Ag Network" in the lower right corner of the diagram? If this is supposed to label the part of the network which is not PBB-eVPN, then shouldn't it be below the diagram, similar to how the label for the PBB-eVPN network is above the network? Is there any reason that it matters for this use case that the vES null attached PEs or devices are part of some other MPLS network? Could they just be part of a plain IP network? It seems to me, reading the text, that the impact would be the same even if these devices were part of a plain IP network? I see, on the right side, the label "MPLS Ag," and (possibly) a corresponding label on the left side saying "G.8032 Access Ring." It seems a bit odd that the label for the PBB-eVPN network is above the diagram, but these two labels, which appear to refer to other parts of the network appear to be incorprated into the diagram itself (?). Why this difference? If these are denoting different parts of the network, it would help the reader understand the diagram better if they were all in the same location in the diagram (?). Are the kinds of network outside the PBB-eVPN network important? Does it matter if one of the two connections from ISID1 (I'm assuming there's a single device here) is through an MPLS network of some other type, and its other connections is through an access ring? Would it make any difference if the entire diagram were simplified to show a single device connected via plain Ethernet in three different places, one of which has redudant links into the PBB-eVPN network? I understand there is underlying resilience in these different technologies, but I'm not certain how that impacts the operation of the mechanism described in the draft. Nits: 4b is missing a "T." == :-) /r -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
