Last Call Review of draft-ietf-bfd-vxlan-07

Request Review of draft-ietf-bfd-vxlan
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-05-31
Requested 2019-05-17
Authors Juniper Networks, Sudarsan Paragiri, Vengada Govindan, Mallik Mudigonda, Gregory Mirsky
Draft last updated 2019-05-27
Completed reviews Rtgdir Last Call review of -07 by Joel Halpern (diff)
Opsdir Last Call review of -07 by Jürgen Schönwälder (diff)
Genart Last Call review of -07 by Erik Kline (diff)
Tsvart Last Call review of -07 by Olivier Bonaventure (diff)
Secdir Last Call review of -07 by Shawn Emery (diff)
Assignment Reviewer Erik Kline
State Completed
Review review-ietf-bfd-vxlan-07-genart-lc-kline-2019-05-27
Posted at
Reviewed rev. 07 (document currently at 08)
Review result On the Right Track
Review completed: 2019-05-27


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-bfd-vxlan-07
Reviewer: Erik Kline
Review Date: 2019-05-27
IETF LC End Date: 2019-05-31
IESG Telechat date: Not scheduled for a telechat


If my understanding is correct (which it may well not be), this document
places restrictions on the inner Ethernet and IP layer deployment that
previously may not have been present.

My reading if this document is that the outer IP header and the inner IP
header have the same VTEP src and dst IPs.  The outer and inner Ethernet
headers have the same source MAC and may have the same dst MAC. Is this

If so, this would mean that the VTEP's MAC address (or the special dest MAC)
cannot be used within the VXLAN network (or at least not on the same host.
Similarly, it appears that the VTEP's IP addresses are no longer free to
be used within the encapsulated VXLAN VNI. Do I understand this correctly?
Was this always the case?

If there is a document defining restrictions that VTEPs place on the
inner VXLAN segment, that might be good to reference.

Failing that, I think I would like to see some discussion of alternatives
that were rejected with reasons behind their rejection.

One possible solution might be to use "impossible" Ethernet addresses and
"impossible" IP addresses in the inner packet.  For example, a source
IP address of all ones or all zeros would be very unlikely to ever be a
valid IP packet.  I'm not 100% sure, but I suspect that a source MAC of
all ones would also never really be treated as valid.  Clever use of
multicast IP and Ethernet addresses in the source fields might also be
sufficient to render the inner packet "invalid" in the sense that it would
never collide with legitimate traffic.

If I have misread this document, or VTEPs are already placing constraints
on the inner VXLAN environment similar to those above, then this review
should instead be treated as "Ready with Nits".

Major issues:

Only my concern/misunderstanding described above.

Minor issues:


Nits/editorial comments:

* The document generally does a really good job of Expanding Acronyms
  At First Use (EAAFU) -- very much appreciated. In section 1 though,
  NVE is used without accompanying expansion, I think.

* There is no 4.2 so maybe sections 4 and 4.1 could just be section 4.