Hi, What is the marginal utility of either 2 or 3?
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: nvo3 <nvo3-boun...@ietf.org> On Behalf Of Joel M. Halpern > Sent: Tuesday, October 22, 2019 3:07 PM > To: Greg Mirsky <gregimir...@gmail.com>; Anoop Ghanwani > <an...@alumni.duke.edu> > Cc: Dinesh Dutt <did...@gmail.com>; draft-ietf-bfd-vx...@ietf.org; NVO3 > <n...@ietf.org>; Santosh P K <santosh.pallaga...@gmail.com>; Jeffrey Haas > <jh...@pfrc.org>; rtg-bfd WG <rtg-bfd@ietf.org>; T. Sridhar > <tsrid...@vmware.com>; xiao.m...@zte.com.cn > Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP > > I do not understand the value of option 2. > Which is why I asked in my initial review to move to option 1. > > And option 2 requires stealing MAC addresses from the users, which seems to > me to be a very bad thing that option 1 avoids. > > Yours, > Joel > > On 10/22/2019 2:17 PM, Greg Mirsky wrote: > > Hi Anoop, et al., > > I agree with your understanding of what is being defined in the > > current version of the BFD over VxLAN specification. But, as I > > understand, the WG is discussing the scope before the WGLC is closed. > > I believe there are three options: > > > > 1. single BFD session between two VTEPs 2. single BFD session per > > VNI between two VTEPs 3. multiple BFD sessions per VNI between two > > VTEPs > > > > The current text reflects #2. Is WG accepts this scope? If not, which > > option WG would accept? > > > > Regards, > > Greg > > > > On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani <an...@alumni.duke.edu > > <mailto:an...@alumni.duke.edu>> wrote: > > > > I concur with Joel's assessment with the following clarifications. > > > > The current document is already capable of monitoring multiple VNIs > > between VTEPs. > > > > The issue under discussion was how do we use BFD to monitor multiple > > VAPs that use the same VNI between a pair of VTEPs. The use case > > for this is not clear to me, as from my understanding, we cannot > > have a situation with multiple VAPs using the same VNI--there is 1:1 > > mapping between VAP and VNI. > > > > Anoop > > > > On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern <j...@joelhalpern.com > > <mailto:j...@joelhalpern.com>> wrote: > > > > From what I can tell, there are two separate problems. > > The document we have is a VTEP-VTEP monitoring document. There > > is no > > need for that document to handle the multiple VNI case. > > If folks want a protocol for doing BFD monitoring of things > > behind the > > VTEPs (multiple VNIs), then do that as a separate document. The > > encoding will be a tenant encoding, and thus sesparate from what is > > defined in this document. > > > > Yours, > > Joel > > > > On 10/21/2019 5:07 PM, Jeffrey Haas wrote: > > > Santosh and others, > > > > > > On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote: > > >> Thanks for your explanation. This helps a lot. I would > > wait for more > > >> comments from others to see if this what we need in this > > draft to be > > >> supported based on that we can provide appropriate sections > > in the draft. > > > > > > The threads on the list have spidered to the point where it > > is challenging > > > to follow what the current status of the draft is, or should > > be. :-) > > > > > > However, if I've followed things properly, the question below > > is really the > > > hinge point on what our encapsulation for BFD over vxlan > > should look like. > > > Correct? > > > > > > Essentially, do we or do we not require the ability to permit > > multiple BFD > > > sessions between distinct VAPs? > > > > > > If this is so, do we have a sense as to how we should proceed? > > > > > > -- Jeff > > > > > > [context preserved below...] > > > > > >> Santosh P K > > >> > > >> On Wed, Sep 25, 2019 at 8:10 AM <xiao.m...@zte.com.cn > > <mailto:xiao.m...@zte.com.cn>> wrote: > > >> > > >>> Hi Santosh, > > >>> > > >>> > > >>> With regard to the question whether we should allow > > multiple BFD sessions > > >>> for the same VNI or not, IMHO we should allow it, more > > explanation as > > >>> follows. > > >>> > > >>> Below is a figure derived from figure 2 of RFC8014 (An > > Architecture for > > >>> Data-Center Network Virtualization over Layer 3 (NVO3)). > > >>> > > >>> | Data Center Network (IP) > > | > > >>> | > > | > > >>> > > +-----------------------------------------+ > > >>> | | > > >>> | Tunnel Overlay | > > >>> +------------+---------+ > > +---------+------------+ > > >>> | +----------+-------+ | | > > +-------+----------+ | > > >>> | | Overlay Module | | | | Overlay > > Module | | > > >>> | +---------+--------+ | | > > +---------+--------+ | > > >>> | | | | | > > | > > >>> NVE1 | | | | | > > | NVE2 > > >>> | +--------+-------+ | | > > +--------+-------+ | > > >>> | |VNI1 VNI2 VNI1 | | | | VNI1 VNI2 > > VNI1 | | > > >>> | +-+-----+----+---+ | | > > +-+-----+-----+--+ | > > >>> |VAP1| VAP2| | VAP3 | |VAP1| VAP2| > > | VAP3| > > >>> +----+-----+----+------+ > > +----+-----+-----+-----+ > > >>> | | | | | | > > >>> | | | | | | > > >>> | | | | | | > > >>> > > -------+-----+----+-------------------+-----+-----+------- > > >>> | | | Tenant | | | > > >>> TSI1 | TSI2| | TSI3 TSI1| TSI2| > > |TSI3 > > >>> +---+ +---+ +---+ +---+ +---+ > > +---+ > > >>> |TS1| |TS2| |TS3| |TS4| |TS5| > > |TS6| > > >>> +---+ +---+ +---+ +---+ +---+ > > +---+ > > >>> > > >>> To my understanding, the BFD sessions between NVE1 and NVE2 > > are actually > > >>> initiated and terminated at VAP of NVE. > > >>> > > >>> If the network operator want to set up one BFD session > > between VAP1 of > > >>> NVE1 and VAP1of NVE2, at the same time another BFD session > > between VAP3 of > > >>> NVE1 and VAP3 of NVE2, although the two BFD sessions are > > for the same > > >>> VNI1, I believe it's reasonable, so that's why I think we > > should allow it > > > > _______________________________________________ > > nvo3 mailing list > > n...@ietf.org <mailto:n...@ietf.org> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/nvo3 > > __;!8WoA6RjC81c!TqBnCBob- > mGlRIth01cY0gBaFxq5GzSZjQh6CW4FENMMATOR6aryer > > Pnf__xrJY$ > > > > _______________________________________________ > nvo3 mailing list > n...@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/nvo3__;!8 > WoA6RjC81c!TqBnCBob- > mGlRIth01cY0gBaFxq5GzSZjQh6CW4FENMMATOR6aryerPnf__xrJY$