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 < nore...@ietf.org> 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. 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. > > - 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. > > - 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.
