Summary: Has a DISCUSS. Needs 2 more YES or NO OBJECTION positions to pass.
First, thank you for a clearly written document that contained enough context to trigger my hazy memory of some of the technical details. My concern is around this paragraph in the Introduction: "The MPLS label value in the Ethernet A-D route can be set to the VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may have a global scope or local scope per PE and may also be equal to the VPWS service instance identifier set in the Ethernet A-D route. " First, I recognize that folks have implemented and deployed EVPN with VXLAN. That's fine. There is an ISE RFC 7348 that describes VXLAN. Depending on what you (authors, shepherd, AD, WG) decide to do about the rest of my concern, it is likely that this should be normative references - which would be a downref. Second, the paragraph here isn't really adequate to describe how to implement the functionality. I don't see how: a) The ingress PE decides which VNIs it can send based upon the VNI=MPLS_label from the egress. Is there an assumption that VXLAN allows sending all VNIs across the particular VPWS, whether port-based, VLAN-based, etc? b) Is there an assumption that the egress PE-advertised MPLS label also indicates the VNI to be used? That seems like another mode, like the VLAN-based service, except it is perhaps VNI + VLAN-based service? Please don't take this Discuss as a reason to remove the paragraph and the implied functionality. If it's implemented and deployed (and I think it is) - then what I really want is to just have it adequately written down so that others can interoperably implement. The downref to VXLAN should just be a matter of process nuisance (i.e. another IETF Last Call and handling any concerns).
1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or "This specification" or... 2) Sec 3.1: " C If set to 1, a Control word [RFC4448] MUST be present when sending EVPN packets to this PE." Given discussions with IEEE about real MACs starting with 4 and 6 in top nibble, adding a statement about it being BCP to include the control word (unless using Entropy Label) would be a good idea.
From Roni's Gen-ART review: Nits/editorial comments: In section 1 second paragraph "[RFC7432] provides the ability " looks like the reference is not a link to RFC7432.
I did have some non-Discuss questions that you might wish to think about before the document is approved ... In the Abstract This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. everything is exceptionally clear, except that I don't know what the "traditional way" of signaling means. The same phrase appears in Section 1 Introduction This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P services. These benefits include single-active redundancy as well as all-active redundancy with flow-based load-balancing. Furthermore, the use of EVPN for VPWS eliminates the need for traditional way of PW signaling for P2P Ethernet services, as described in section 4. with the addition of "as described in section 4", but I didn't see an explicit statement in Section 4 that explained what was replacing the "traditional way". Even a clear reference to an RFC where the "traditional way" was defined would be helpful. It would probably be helpful to expand acronums like "P2P" on first use. I immediately thought "peer to peer?" but I bet you didn't mean that. Yes, there's a terminology section, but it's three and a half pages into the document. In this text, For EVPL service, the Ethernet frames transported over an MPLS/IP network SHOULD remain ^^^^^^ tagged with the originating VLAN-ID (VID) and any VID translation MUST be performed at the disposition PE. why is this a SHOULD? I guess my first question should be "does this still work if you don't?" In this text, In multihoming scenarios, both B and P flags MUST NOT be both set. the double both(s) made this difficult to parse. Is it saying In multihoming scenarios, the B and P flags MUST be cleared. or something else? But I'm guessing, and the rest of that paragraph made me doubt my guesses.
This document is very heavy on the acronyms, and could do with some expanding of these -- for example, the document starts out with "This document describes how EVPN can be used...". I'm no MPLS VPN person, so much time was spent searching to try figure out what everything meant. I also agree with Spencer's "In multihoming scenarios, both B and P flags MUST NOT be both set. " being hard to parse, and disagree with Acee that is it clear.
The shepherd write-up says: "Two IPR discussions from Juniper & Cisco respectively: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws Haven't seen WG discussion on that." Can we confirm that the wg is aware of the IPRs before publication? Other minor comments: 1) Agree with Warren that all the acronyms make it hard to read. Please check that you've spelled out all acronyms at the first occurrence in the intro accordingly, including EVPN. 2) section 3.1: Is the B flag even needed? Doesn't P=0 indicate that this is the Backup PE? 3) I would maybe move section 5 right after the intro because it provides some background on the benefits of this extension. 4) Are you sure there are no additional security consideration based on the information provided in this extension? E.g. an attacker indicates being the primary PE and thereby causes a conflict, or problems based on the indication of a small MTU by an attacker? Not sure if there is any risk or if that is covered somewhere else...?
I agree with people that the document is rather heavy on acronyms.
I'm interested to see the response to Mirja's comment #4. Glad to see #1 is okay.