Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents
Note: This ballot was opened for revision 05 and is now closed.
Alvaro Retana No Objection
It would be very nice to have references to (PBB-)EVPN and (PBB-)VPLS in the introduction. I think that all of these references should be Normative because they are "documents that must be read to understand or implement the technology". It looks like the references are made later in the text...but a couple are listed as only Informative. I don't think that the use of rfc2119 language in §2 (Requirements) is appropriate because (1) there isn't any Normative action from the requirements, and (2) these are resolved later in this document. I agree with others (Genart, Opsdir) in that this document reads more like a BCP or even an Informational document. [nit] s/(PBB-VPLS) solutions (PBB-)VPLS./(PBB-VPLS) solutions.
Warren Kumari No Objection
I'm staying out of the "what track should it be" discussion... Thanks to Linda Dunbar for the OpsDir review.
(Deborah Brungard; former steering group member) Yes
I agree with the current status as PS. While it does not define new codepoints or protocol extensions, it defines new mechanisms which need to be supported by all (PBB-)EVPN nodes. The mechanisms are not supported by operational configuration, they are new mechanisms which need to be supported by the node itself. A BCP/Informational status would be appropriate if this document was only defining the procedures related to the VPLS or PBB-VPLS PEs. For those nodes, there is no change, as all the new mechanisms supporting seamless integration need to be supported on the EVPN nodes.
(Martin Vigoureux; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) (was Discuss) No Objection
Thank you for addressing my DISCUSS.
(Ben Campbell; former steering group member) No Objection
Thanks for the work on this. I support Alissa's discuss. §2: - The 2119/8174 keywords in this section are not used according to the RFC 2119/RFC 8174 definitions. The RFCs talk about requirements on implementations to achieve interoperability. This speaks of requirements for the standards process. If the working group prefers to keep the use of keywords in this section, please add some additional text to the 2119/8174 boilerplate to explain the usage. (My other comments on the section assume that the normative keywords will remain.) - Req 2: "The solution MUST require no changes..." I suggest "MUST NOT require changes" - Req 5: This doesn't seem to state a solution requirement; rather, it describes an action that VPN instances may take. Is the solution requirement to allow this behavior?
(Benjamin Kaduk; former steering group member) No Objection
Please be consistent about (non-)hyphenation of "VPLS A-D". Is "MP2P" really an intended acronym (vs., e.g., P2MP)? It does not appear in https://www.rfc-editor.org/materials/abbrev.expansion.txt and is not defined, even though P2MP is, and MP2P is used some 8 times in the document. We probably need a definition and/or reference for "split-horizon". Section 2 6. The support of All-Active redundancy mode across both (PBB-)EVPN PEs and (PBB-)VPLS PEs is outside the scope of this document. The claim (not quoted) of "seamless" integration seems to only hold if All-Active redundancy mode is not in common use. Is it? Section 3.1 In this case, when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the basis that it belongs to an unknown SAFI. [...] Is this "MUST" a new requirement imposed by this document, or a restatement of an existing requirement from elsewhere? Section 3.2 Please expand FEC on first usage (or define it in the terminology section). When we talk about "learned" C-MAC addresses from traffic on VPLS PWs and injecting those MAC addresses into bridge tables, RIB/FIB tables, and MAC-VRFs, are these learned C-MAC addresses coming from provider-owned equipment or customer equipment? Giving the customer the ability to inject MAC addresses without verification would probably merit a closer look (though I do note that the penultimate paragraph discusses the non-propagation of the learned addresses over the control plane). Section 3.4.2, 4.4.2 My understanding was that P2MP (PBB-)EVPN tunnels are a well-understood thing, in which case I would expect to see something more like "this document does not modify the operation of multicast P2MP EVPN tunnels" than "outside the scope of this document". Section 5 Does the extra state that (PBB-)EVPN PEs need to maintain (i.e., both the normal EVPN state and PWs to the VPLS PEs) pose any risk of DoS due to resource exhaustion?
(Ignas Bagdonas; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
To me this documents reads more like an informational doc, providing guidance for operations but not specifying any new protocol or protocol extensions or requirements that are mandatory to implement for interoperability.
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
* Section 3.3 MAC Mobility The handling of MAC mobility between the EVPN and VPLS PEs seems a bit, for a lack of a better term, "not seamless" to me. While only using EVPN a MAC that has moved will get propagated out without *initiating* any sort of BUM traffic itself as described Section 15 of RFC7432. If I understand this document correctly, if a MAC moves onto a segment with a VPLS PE, traffic towards it will be blackholed until it initiates BUM traffic which is not the case when the MAC moves between EVPN PEs. Did I get this right? If so, I think this limitation needs to be highlighted a bit more prominently.