Anoop Ghanwani
2018-11-08 09:58:12 UTC
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
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