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 >>> >>>>
