Resend with Martin's correct email > -----Original Message----- > From: iesg [mailto:[email protected]] On Behalf Of Adrian Farrel > Sent: 17 October 2014 12:05 > To: [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: GenART review of draft-ietf-l2vpn-evpn-10 > > 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
