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

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Jun 2019 13:40:13 -0700

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 <
[email-masked]> 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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Jun 2019 11:40:33 +0200

> the IETF standardization process.

I leave this to the IESG.
 
> the definition used in the document.)

Perhaps conventions different between different parts of the IETF, as
a review, I find it helpful to know where things are actually defined
(and I assume the same is true for implementors).

>  VXLAN tunnel to may be set to Up.

Not sure I managed to parse the second sentence. So is the idea that
the dedicated MAC address is only do be used until the MAC address has
been discovered? But yes, any text that helps readers to understand
this is appreciated.

>    the maximum number of such session that can be active at the same

Works for me. I read this as "the maximum number of such session
should be configurable", which is great advice for implementors.

>    the connectivity from the source NVE to the MSN.

Perhaps say more explicitely that in the Multicast Service Node case,
demand mode of BFD is used?
 
> interoperability we need to standardize it first.

OK

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>