WGLC comments on draft-ietf-bfd-vxlan

[Anoop Ghanwani <[e-mail]>]

Here are my comments.

Thanks,
Anoop

==

Philosophical

Since VXLAN is not an IETF standard, should we be defining a standard for
running BFD on it?  Should we define BFD over Geneve instead which is the
official WG selection?  Is that going to be a separate document?

Technical

Section 1:

This part needs to be rewritten:
>>>
The individual racks may be part of a different Layer 3 network, or they
could be in a single Layer 2 network. The VXLAN segments/overlays are
overlaid on top of Layer 3 network. A VM can communicate with another VM
only if they are on the same VXLAN segment.
>>>
It's hard to parse and, given IRB, the last sentence above is wrong.

Section 3:
>>>
 Most deployments will have VMs with only L2 capabilities that
may not support L3.
>>>
Are you suggesting most deployments have VMs with no IP
addresses/configuration?

>>>
Having a hierarchical OAM model helps localize faults though it requires
additional consideration.
>>>
What are the additional considerations?

Would be useful to add a reference to RFC 8293 in case the reader would
like to know more about service nodes.

Section 4
>>>
Separate BFD sessions can be established between the VTEPs (IP1 and IP2)
for monitoring each of the VXLAN tunnels (VNI 100 and 200).
>>>
IMO, the document should mention that this could lead to scaling issues
given that VTEPs can support well in excess of 4K VNIs.  Additionally, we
should mention that with IRB, a given VNI may not even exist on the
destination VTEP.  Finally, what is the benefit of doing this?  There may
be certain corner cases where it's useful (vs a single BFD session between
the VTEPs for all VNIs) but it would be good to explain what those are.

Sections 5.1 and 6.1

In 5.1 we have
>>>
The inner MAC frame carrying the BFD payload has the
following format:
... Source IP: IP address of the originating VTEP. Destination IP: IP
address of the terminating VTEP.
>>>

In 6.1 we have
>>>

Since multiple BFD sessions may be running between two
VTEPs, there needs to be a mechanism for demultiplexing received BF

packets to the proper session.  The procedure for demultiplexing
packets with Your Discriminator equal to 0 is different from[RFC5880
<https://tools.ietf.org/html/rfc5880>].

*For such packets, the BFD session MUST be identified*

*using the inner headers, i.e., the source IP and the destination IP
present in the IP header carried by the payload of the VXLAN*

*encapsulated packet.*


>>>
How does this work if the source IP and dest IP are the same as specified
in 5.1?

Editorial

- Terminology section should be renamed to acronyms.
- Document would benefit from a thorough editorial scrub, but maybe that
will happen once it gets to the RFC editor.

Section 1
>>>
"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348
<https://tools.ietf.org/html/rfc7348>]. provides an encapsulation scheme
that allows virtual machines (VMs) to communicate in a data center network.
>>>
This is not accurate.  VXLAN allows you to implement an overlay to decouple
the address space of the attached hosts from that of the network.

Section 7

VTEP's -> VTEPs