On Tue, Jun 04, 2019 at 01:40:13PM -0700, Greg Mirsky wrote:
> 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.
I leave this to the IESG.
> - 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.)
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).
> > - 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.
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.
> > - 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.
Works for me. I read this as "the maximum number of such session
should be configurable", which is great advice for implementors.
> > - 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.
Perhaps say more explicitely that in the Multicast Service Node case,
demand mode of BFD is used?
> >
> > - 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.
OK
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49
