Reviewer: Gyan Mishra Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-nvo3-vxlan-gpe Reviewer: Gyan Mishra Review Date: 2023-11-26 IETF LC End Date: 2023-11-xx IESG Telechat date: Not scheduled for a telechat Summary: This document describes extending Virtual eXtensible Local Area Network (VXLAN), via changes to the VXLAN header, with four new capabilities: support for multi-protocol encapsulation, support for operations, administration and maintenance (OAM) signaling, support for ingress-replicated BUM Traffic (i.e. Broadcast, Unknown unicast, or Multicast), and explicit versioning. New protocol capabilities can be introduced via shim headers. This document is almost ready for publication as a proposed standard. I have some critical minor issues that need to be reviewed and resolved by the authors before publication. Major issues: None Minor issues: The draft should go into some more detail in backwards compatibility section stating that the forward looking objective is that VXLAN RFC 7348 would eventually become obsolete and all vendor implementations and operator deployments would now support VXLAN-GPE. Would any flag day be necessary to change over from VXLAN to VXLAN-GPE. Regarding OAM support VXLAN does not support in-situ OAM as does VXLAN-GPE however VXLAN implementations do have OAM support capabilities with separate OAM packets from data packets. This should be mentioned. As far as encapsulation VXLAN supports Ethernet as all Data Centers are Ethernet based. So there has not been any need for multi protocol support to support IPv4 or IPv6 directly as the payload next header instead of Ethernet header only. What would be the advantage of supporting IPv4 or IPv6 protocol encapsulation over Ethernet encapsulation for the payload. The savings would be in not requiring the Ethernet header and CRC so some overhead bytes savings. NVO VXLAN does not support NSH today for service plane and relies today on complex PBR for service chaining SFFs in the forwarding chain. So now with VXLAN-GPE with P bit would facilitate the support of SFC NSH service plane eliminating the complexity of VXLAN service chaining. This should be mentioned in the draft. Are there any vendor implementations of VXLAN-GPE and any issues encountered during interoperability testing between VXLAN and VXLAN-GPE? It should be noted somewhere in the specification that VXLAN-GPE is identical to “VXLAN EVPN” as there is an RFC for VXLAN RFC 7348 flood and learn where control plane and data plane are together mac learning via data plane, however there is not any RFC for “VXLAN EVPN” where now the control plane has its own separate EVPN control plane procedures defined in BGO MPLS EVPN RFC 7432 and NVO encapsulation overlays procedures defined in RFC 8365. Stating somewhere in the draft that the separation of control plane via BGP EVPN mac learning using EVPN Route types RT-2, RT-5 etc all exists identically for VXLAN-GPE and all EVPN procedures RFC 7432 are followed identically as is done today with “VXLAN EVPN”. I believe GENEVE RFC 8926 should be mentioned as informative and maybe normative as out of all the NVO encapsulation types that GENEVE is the chosen NVO encapsulation moving forward. How does that play into advancing “VXLAN EVPN” to “VXLAN-GPE EVPN” given that the industry has decided on a different foreword looking encapsulation with GENEVE. Nits: I think RFC 7432 BGP MPLS EVPN and RFC 8365 NVO should be added as informational references indicating that no changes to VXLAN EVPN control plane.