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. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
