[bess] Spencer Dawkins' No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-bess-evpn-vpws-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.