Hi Jurgen,
thank you for your review, detailed and precise questions. Please find my answers in-line and tagged GIM>>.
Regards,
Greg
On Tue, May 21, 2019 at 12:28 AM Jürgen Schönwälder via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Jürgen Schönwälder
Review result: Has Issues
I only have a very limited understanding of VXLAN ands BFD technology.
Hence, some of my question may look odd to the insiders.
- RFC 7348 defining VXLAN is informational, why would BFD for VXLAN be
standards track?
GIM>> That has been somewhat of the way to bring the de-facto standard into the IETF standardization process.
- Section 2.1 "Terminology" expands acronyms but it does say where
these "terms" are actually defined. Some pointers to the relevant
RFCs may be useful.
GIM>> That might be useful, thank you. But, AFAIK, at IETF that is not the traditional format (though I know that other SDOs refer to the source of the definition used in the document.)
- Section 3 starts talking about VNI numbers but acronym VNI has not
been introduced before. I assume VNI = VXLAN Network Identifier.
GIM>> Thank you. Adding to the Terminology "VXLAN Network Identifier (or VXLAN Segment ID)" and will expand on the first use..
- I am not familiar with VXLAN but I wonder how the endpoints
addresses are obtained in practice. This BFD document says for
example "The details of how the MAC address of the destination VTEP
is obtained are outside the scope of this document." Well, OK, but
how does this work? Is there a document where this is explained?
Well, I am actually less concerned about how the inner address is
obtained, I think I am more urgently missing how the VTEP determines
the remote tunnel endpoint address.
GIM>> One of the ways could be through exchange of the BFD packets when the DA MAC is the dedicated MAC. More on that below.
- Why do you need a special MAC address? The text says I can use this
address or the address of the destination VTEP but there is no
reasoning when to use what or why a dedicated address is needed.
GIM> Would the following text added at the end of Section 4.1 address your question:
NEW TEXT:
The use of the dedicated MAC allows starting BFD session before
learning the MAC address of the remote VTEP. As a result, after the
BFD session has reached the Up state the operational state of the
VXLAN tunnel to may be set to Up.
- What is a 'reasonable upper bound' on the number of BFD sessions
that can be created between the same pair of VTEPs? 1? 2? 8? 64?
256? 4096? How does the choice of this upper bound impact security?
GIM>> I agree, that is too vague. Would changing the text to recommend that the control mechanism be provided if multiple BFD sessions between the same piar of VTEP allowed:
OLD TEXT:
The implementation SHOULD have a reasonable upper bound on the number
of BFD sessions that can be created between the same pair of VTEPs.
of BFD sessions that can be created between the same pair of VTEPs.
NEW TEXT:
If the implementation supports establishing multiple BFD sessions
between the same pair of VTEPs, there SHOULD be a mechanism to control
the maximum number of such session that can be active at the same
time.
between the same pair of VTEPs, there SHOULD be a mechanism to control
the maximum number of such session that can be active at the same
time.
- Which BFD mode is assumed to be used, asynchronous or demand? Or
does this not matter for this usage of BFD, i.e., both work just
fine and will be interoperable?
GIM>> For p2p VXLAN tunnel, the Asynchronous mode of BFD is recommended:
The asynchronous mode of BFD, as defined in [RFC5880], can be used to monitor a p2p VXLAN tunnel.
The Demand mode is used in RFC 8293 that is recommended if the Multicast Service Node resides behind the NVE:
In the case where a Multicast Service Node (MSN) (as described in
Section 3.3 of [RFC8293]) resides behind an NVE, the mechanisms
described in this document apply and can, therefore, be used to test
the connectivity from the source NVE to the MSN.
Section 3.3 of [RFC8293]) resides behind an NVE, the mechanisms
described in this document apply and can, therefore, be used to test
the connectivity from the source NVE to the MSN.
- Why is echo BFD outside the scope of this document? Can I just turn
on echo mode or will extra specifications be needed?
GIM>> The BFD Echo mode is underspecified in RFC 5880. To achieve interoperability we need to standardize it first.
