Re: WGLC comments on draft-ietf-bfd-vxlan

[Greg Mirsky <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <[e-mail]>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> See below prefixed with [ag4].
>>>
>>> Thanks,
>>> Anoop
>>>
>>> On Wed, Nov 21, 2018 at 4:36 PM Greg Mirsky <[e-mail]>
>>> 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
>>>>
>>>>>