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
