Hi Martin, I firmly believe that all reviews are good reviews, and thank you for the time you have put into this.
You'll understand, of course, the squawking noise made by the authors who received your review the day after the IESG discussed your document on the telechat. In fact, the last Discus cleared a short while ago, and I was just about to click the friendly red button marked "Approved". Including the standard GenArt boilerplate about "last call comments" might be a tiny but ironic :-) But let's cut to the chase... > I found the overview in Section 4 to be very...wooly. Hmmm. I re-read and found it relatively to the point. Sentences are quite short, and are all definitive. > It launches > straight into alphabet soup, True there are a lot of abbreviations. But the terms are either well-known or described in Section 3. For example, if a reader is unfamiliar with CE, PE, MPLS, IP, GRE, then I'm afraid they will get nothing out of the document. Expanding the terms will not help. > but didn't manage to identify what it was > that the document was trying to achieve, vs. what already exists. Do you feel that Section 1 does not make it clear what the document is trying to achieve? Yes, it is true that there is no list of "new protocol elements defined in this document to supplement existing mechanisms and thereby enable EVPN". I would argue that that list is provided by Sections 5, 6, and 7, while sections 5 through 18 describe the new protocol procedures. So, since the whole document after the section you are discussing is about the new stuff, I think that making a list is unnecessary. > It > certainly raises questions: is this document going to address the > issue of how MAC learning is populated on devices in networks attached > to CE? I think you mean a device further into the customer network (i.e., not a PE). Why do you think that this would be changed in an EVPN? The behavior of the nodes in customer sites are not impacted by the way the PEs are sharing information. That could be said to be the whole point of the work. > Is it going to deal with (MAC) learning on the PE and CE > equipment? The question for PEs is answered in the third paragraph of Section 4. The question for CEs is answered in the fifth paragraph of Section 4. > What information does the CE really need at the MAC layer > to do its job? I'm sorry, but I don't understand this question. Is the behavior of a CE in an EVPN assumed to be different from that of a CE in any other Ethernet emulation environment? I don't think so. > The information provided is definitely not enough to > make sense of the remainder of the document. OK. But I don't see what information is missing given that your questions (above) are basically already addressed in the text. Maybe some time with 7209 would help set the scene. The text certainly points at 7209 right from the start. > Maybe that's just a shortcoming in my own education; this subject is > well outside of my field. OK. That's fine. And thanks for reviewing anyway. > I also found the sudden introduction of a bag of protocol elements > without context very difficult to process. So an ESI identifies an > EVPN? What do I do with one? Well, the term is introduced in the terminology section and also section 5 as identifying an Ethernet segment, and section 5 describes what an Ethernet segment is from the perspective of the CE. There then follows text indicating how ESIs are allocated and the rules for uniqueness. What you are missing, I think, is the forward pointers to indicate what use is made of the ESI (i.e., why does an Ethernet segment need an identifier). The need comes from 7209, but the usage is later in this document. I dare say that the text (probably in Section 5) could start with "As indicated in [RFC7290], each PE-CE Ethernet segment needs a unique identifier in an EVPN. This section defines how such identifiers are assigned and how they are encoded for use in EVPN signaling. Later sections of the document describe the protocol mechanisms that utilize the identifiers." Would that have helped? > In section 5, why is there not some sort of registry for the ESI Types > that are defined here? Good question. It's a question I asked when I did my AD review back in July. The reply was: "We don't anticipate any other ESI type besides the ones mentioned here." While I am not 100% convinced there will never be a new type, if a new type does show up it will be a rare occurrence and can be handled by a new I-D in the BESS working group without contention. A registry could be added later if really necessary. > Section 6: > > An Ethernet Tag ID is a 32-bit field containing either a 12-bit or a > 24-bit identifier that identifies a particular broadcast domain > (e.g., a VLAN) in an EVPN Instance. > > How do I distinguish one from t'other? It depends on the EVPN BGP route in use for the different service interfaces. Like the text says... The following subsections discuss the relationship between broadcast domains (e.g., VLANs), Ethernet Tag IDs (e.g., VIDs), and MAC-VRFs as well as the setting of the Ethernet Tag ID, in the various EVPN BGP routes (defined in section 8), for the different types of service interfaces described in [RFC7209]. > Nits: > Please check for expansion on first use for acronyms. Maybe it's OK > to not expand LSP or MPLS, but I think that there are others that need > work. We did already do a scrub on this. At this point I think we will leave it to the RFC editor to catch any strays. > Please provide references on first use of a new concept. I have no > idea what a BGP NLRI is, and finding out is made more difficult by > this: > > This document defines a new BGP NLRI, called the EVPN NLRI. NLRI is already expanded on first use. It's a bit fundamental! You shouldn't be let loose on anything that touches BGP if you don't know what an NLRI is. The reference would be RFC 4271 which is the BGP spec. Thanks for your input. Adrian _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
