Virtual Private Wire Service Support in Ethernet VPN
draft-ietf-bess-evpn-vpws-14

[ For -11 / -12 ] 
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.

[ For -13 ]
The draft was revised to address Alia's DISCUSS, and also Spencer's "traditional way" and "both B and P flags MUST NOT be both set" comment, but still does not expand EVPN; I also agree with Spencer that it would be helpful to expand P2P on first use.  I reread the document and have some additional comments - note that these are are only comments, but I think that they would make the document more readable...

1: Introduction:
"that in EVPN terminology would mean a single pair of Ethernet Segments ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing failure and 'Ethernet Segments (ES)' was intended? If not, 

You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick with one.

1.1: Terminology:
"EVI: EVPN Instance." --  Ok, but EVPN is still not defined / referenced.

3.1  EVPN Layer 2 attributes extended community
" A PE that receives an update with both B and P flags set MUST treat the
 route as a withdrawal. If the PE receives a route with both B and P
 clear, it MUST treat the route as a withdrawal from the sender PE."
Do the above 2 sentences say the same thing? It sure sounds like repetition, if not, please explain the difference. If not, removing one would make this less confusing.

Figure 3: EVPN-VPWS Deployment Model
You use the terms / labels "PSN1", "PSN2" - what are these? "Provider <something> Network"?

From https://www.rfc-editor.org/materials/abbrev.expansion.txt:
> It is common in technical writing to abbreviate complex technical terms
> by combining the first letters.  The resulting abbreviations are often
> called acronyms.  Editorial guidelines for the RFC series generally
> require expansion of these abbreviations on first occurrence in a
> title, in an abstract, or in the body of the document.

These guidelines go on to point out which acronyms are common enough not to require expansion on first use. The following acronyms are not considered common, and require expansion on first use *and* in the title (I'm being very careful to cite only those which are *not* expanded on first use, so each of these should be actionable):

- VPWS 
- EVPN
- P2P
- MAC (which is, itself, ambiguous without an expansion on first use)
- PE
- CE
- L2
- DF
- iBGP
- eBGP

I don't think "encap" is a word.

I have not made a complete effort to understand the technical aspects of this document as its acronym use is literally too thick for me to read and comprehend its contents. I presume it is readable to its community of interest (as three implementations already exist); but finding ways to write in prose instead of acronyms where possible would be highly welcome.

I agree with people that the document is rather heavy on acronyms.

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'm interested to see the response to Mirja's comment #4.  

Glad to see #1 is okay.

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 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.