Hi Anoop, thank you for the consise text. I think I've got the idea. Would the minor tweak be acceptable?
In most cases, a single BFD session is sufficient for the given VTEP to monitor the reachability of a remote VTEP, regardless of the number of VNIs in common. When the single BFD session is used to monitor reachability of the remote VTEP, an implementation SHOULD use a VNI of 0. Regards, Greg On Fri, Nov 23, 2018 at 10:47 AM Anoop Ghanwani <[email protected]> wrote: > Hi Greg, > > I would recommend the following change. > > OLD > > 7. Use of reserved VNI > > BFD session MAY be established for the reserved VNI 0. One way to > aggregate BFD sessions between VTEP's is to establish a BFD session > with VNI 0. A VTEP MAY also use VNI 0 to establish a BFD session > with a service node. > > NEW > > 7. Use of reserved VNI > > In most cases, only a single BFD session is necessary for a given VTEP > to monitor the reachability to a remote VTEP, regardless of the number of > VNIs in common. When a single session is used to monitor reachability > remote VTEP, an implementation SHOULD use a VNI of 0. > > Thanks, > Anoop > > On Thu, Nov 22, 2018 at 12:28 PM Greg Mirsky <[email protected]> > wrote: > >> Hi Anoop, >> apologies if my explanation was not clear. Non-zero VNIs are recommended >> to be used by a VTEP that received BFD control packet with zero Your >> Discriminator value. BFD control packets with non-zero Your Discriminator >> value will be demultiplexed using only that value. As for the special role >> of VNI 0 the section 7 of the draft states the following: >> BFD session MAY be established for the reserved VNI 0. One way to >> aggregate BFD sessions between VTEP's is to establish a BFD session >> with VNI 0. A VTEP MAY also use VNI 0 to establish a BFD session >> with a service node. >> Would you suggest changing the normative language in this text? >> >> Regards, >> Greg >> >> PS. Happy Thanksgiving to All! >> >> On Wed, Nov 21, 2018 at 11:00 PM Anoop Ghanwani <[email protected]> >> wrote: >> >>> Hi Greg, >>> >>> See below prefixed with [ag4]. >>> >>> Thanks, >>> Anoop >>> >>> On Wed, Nov 21, 2018 at 4:36 PM Greg Mirsky <[email protected]> >>> wrote: >>> >>>> Hi Anoop, >>>> apologies for the miss. Is it the last outstanding? Let's bring it to >>>> the front then. >>>> >>>> - What is the benefit of running BFD per VNI between a pair of VTEPs? >>>>>>>> >>>>>>> GIM2>> An alternative would be to run CFM between VMs, if there's >>>>>>> the need to monitor liveliness of the particular VM. Again, this is >>>>>>> optional. >>>>>>> >>>>>> >>>>>> [ag2] I'm not sure how running per-VNI BFD between the VTEPs allows >>>>>> one to monitor the liveliness of VMs. >>>>>> >>>>> >>>> [ag3] I think you missed responding to this. I'm not sure of the value >>>> of running BFD per VNI between VTEPs. What am I getting that is not >>>> covered by running a single BFD session with VNI 0 between the VTEPs? >>>> >>>> GIM3>> I've misspoken. Non-zero VNI is recommended to be used to >>>> demultiplex BFD sessions between the same VTEPs. In section 6.1: >>>> The procedure for demultiplexing >>>> packets with Your Discriminator equal to 0 is different from >>>> [RFC5880]. For such packets, the BFD session MUST be identified >>>> using the inner headers, i.e., the source IP and the destination IP >>>> present in the IP header carried by the payload of the VXLAN >>>> encapsulated packet. The VNI of the packet SHOULD be used to derive >>>> interface-related information for demultiplexing the packet. >>>> >>>> Hope that clarifies the use of non-zero VNI in VXLAN encapsulation of a >>>> BFD control packet. >>>> >>> >>> [ag4] This tells me how the VNI is used for BFD packets being >>> sent/received. What is the use case/benefit of doing that? I am creating >>> a special interface with VNI 0 just for BFD. Why do I now need to run BFD >>> on any/all of the other VNIs? As a developer, if I read this spec, should >>> I be building this capability or not? Basically what I'm getting at is I >>> think the draft should recommend using VNI 0. If there is a convincing use >>> case for running BFD over other VNIs serviced by that VTEP, then that needs >>> to be explained. But as I mentioned before, this leads to scaling issues. >>> So given the scaling issues, it would be good if an implementation only >>> needed to worry about sending BFD messages on VNI 0. >>> >>> >>>> >>>> Regards, >>>> Greg >>>> >>>>>
