Martin, thanks for your comments and Adrian, thanks for your input & suggestions.
Adrian, I will go ahead and add the paragraph that you suggested to the beginning of section 5. Also, several comments revolve around the motivation of this draft and what it tries to solve, etc. Although this is described in Introduction section (sec. 1), I thought it might be helpful to beef it up. So, I am adding the following paragraph to the beginning of section 1. "Virtual Private LAN Service (VPLS), as defined in [RFC4664], [RFC4761], and [RFC4762], is a proven and widely deployed technology. However, the existing solution has a number of limitations when it comes to multi-homing and redundancy, multicast optimization, provisioning simplicity, flow-based load balancing and multi-pathing that are of important considerations for data center deployments. [7209] describes the motivation for a new solution to address these limitations. It also outlines a set of requirements that the new solution must address.² Then the second paragraph follows it: "This document describes procedures for a BGP MPLS based solution called Ethernet VPN (EVPN) to address the requirements specified in [RFC7209]. Please refer to [RFC7209] for the detailed requirements and motivation. EVPN requires extensions to existing IP/MPLS protocols as described in this document. In addition to these extensions EVPN uses several building blocks from existing MPLS technologies." BTW, since these are just editorial changes, I will just give them to the RFC editor, unless you want me to check the new rev in. Cheers, Ali On 10/17/14, 4:14 AM, "Adrian Farrel" <[email protected]> wrote: >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
