Hi Anoop, thank you for your thorough review and the comments. I'm traveling over the weekend and will respond in details later next week.
Regards, Greg On Thu, Nov 8, 2018 at 4:58 PM Anoop Ghanwani <[email protected]> wrote: > > 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 > >
