[nvo3] Genart early review of draft-ietf-nvo3-vxlan-gpe-13

[Gyan Mishra via Datatracker <[e-mail]>]

Reviewer: Gyan Mishra
Review result: Ready with Issues

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

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

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.