Re: Opsdir last call review of draft-ietf-bfd-vxlan-07

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> 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.