[bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT)

[Alia Atlas <[e-mail]>]

Alia Atlas has entered the following ballot position for
draft-ietf-bess-evpn-vpws-11: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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


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

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.