Greg, I think the draft is fine as is.
I discussion with Xiao Min was about #3 and I see that as unnecessary until we have a draft that explains why that is needed in the context of the NVO3 architecture. Anoop On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky <gregimir...@gmail.com> 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> > 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> >> 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> 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 >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>
