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

Greg Mirsky <gregimirsky@gmail.com> Sat, 24 November 2018 00:31 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA4128C65; Fri, 23 Nov 2018 16:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JObL26DiFtbq; Fri, 23 Nov 2018 16:31:08 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB821271FF; Fri, 23 Nov 2018 16:31:07 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id i26so9732647lfc.0; Fri, 23 Nov 2018 16:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jVaUcDIBcAqk4LqsBLdjSm5CaQiiu9zeDrwoVcUfaho=; b=GW++3v/4mCurhxIW6NdM24U4eN3DDq8Pl0ZbJIxfTy3aQFlxBq0jU+IYVokEkYW0DD 5aGWrrmY3zHsblFE3MRoXisySOVuh3T98lmUZ1y+Wb0D4XFopATiJOH1OIlWI2ntRmMM skEwfAouDJ/B7ZEFtYqCFTPpoAhLkOCFYJGVeZRxUz4V/KnhTWqT3own5SPKfHSkSrwI bhmJa5EAdHrPivjPTR+T8fYrhTpcalZvSSXWM5plQ9QVHUCU9ReAOU6Uk6U6SGw0dWl2 DCkUtIZ4gHhZ3NHJtmzIiA3IP0QGuBhANRD/6JW6+8JdTuI0F2cTIVmyuuaxaQ+9u1Rf NZ+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jVaUcDIBcAqk4LqsBLdjSm5CaQiiu9zeDrwoVcUfaho=; b=axLoyaik78cqdU7F88NvuZIwMKgHXtkn8C5KJLsMKhdwd0YEGFp/tvGA1eg2eWcM9K mzLuKorZfAyUHJnYpliz1mNwhrCvhv3wfwPmBRevRkzLmIr5LjQxMhaZJN1iZjUUCwfQ Hh07wg7C10+OlyTPQ8wkytR4LUKI2OnuC0CWg+SaALPaNgFgV+hQzKbFfDbbLxY8fvF7 Q31k1Qdn0FaEKOH6+mEY9E49/77Uy5dbKzWhxp1jXz4IWyIRvVqdCK+VI1F3/ekjKl8V 6uOuOiZF6vNbshIQs2x4vt7KYuhMN8SblTvCEBz7DAXrRyzErZ8v7xS3CUQYMWC9aAtI fiQA==
X-Gm-Message-State: AGRZ1gKdG+pDOUCct7JEiS+88Gyz7Zw/tLNm47E/CwGUf2m6jwDUkhaz miWbzuyFDE90lPPlsks9ib+woj7nmVLX704iRtw=
X-Google-Smtp-Source: AJdET5d7xGDpsk2Ma2e8StMqpukWM3RfXzHWVs3fERGjBLuTKWCpScL9H96g2+8oofF5X55UZR6BIZ0FsD9gh41GyhU=
X-Received: by 2002:a19:c014:: with SMTP id q20mr9884924lff.16.1543019465267; Fri, 23 Nov 2018 16:31:05 -0800 (PST)
MIME-Version: 1.0
References: <CA+-tSzxFxtVo6NbfSw4wzb--fSuN4zsSvX7R58iiYFgVF5cA6Q@mail.gmail.com> <CA+RyBmVXeCYAZhWTy-g6U_EJ7NOFQwV4twJaJ-7_LT5_wKFGFw@mail.gmail.com> <CA+-tSzxQp2x0hpAF253b9yKL1aD1J1CaGHs7T6VE8zuvg25R_Q@mail.gmail.com> <CA+RyBmXoOKS-Nq7bDfsgDZXou5-FcprEQeVkhWhAD4_1MoHqUQ@mail.gmail.com> <CA+-tSzzgKyfXzE+=eVLz7B3u1X_HFahQ6GCFTbL+-rfjsR03uA@mail.gmail.com> <CA+RyBmVeyOhBNANTfG87VbNkwh5HqxZnFc7AzFcCLo_6UcHSMQ@mail.gmail.com> <CA+-tSzyCKsQx9zTMjjTpwjF=tL2WOz7hNUff_KFQwL8n2Y+xUg@mail.gmail.com> <CA+RyBmVCbz7yw=97QVek5RM89PfqkcBijCNE8tPWdFdfgrvX3w@mail.gmail.com> <CA+-tSzy=9fJmMYK3RAnZgqj5-GVBAg1RAaMbfkEbxX-=d=VxRw@mail.gmail.com> <CA+RyBmWG1AST-6ukBTsipgLvv9RcxJBpFQ_av8w=aTTWV+7Wmg@mail.gmail.com> <CA+-tSzz21Tu-su1TXj6cHea5-H+-n2kmU3KdzdWnMUL4E52HMQ@mail.gmail.com> <CA+RyBmXypByBZSmA7g3bcXGo=p+1Hrj_2Mak1qa3FXbzgPfoHg@mail.gmail.com> <CA+-tSzz71ezd3GE+Uq4K7CvAh4_kzyjqYgKQmXdsKkq66bFk9A@mail.gmail.com>
In-Reply-To: <CA+-tSzz71ezd3GE+Uq4K7CvAh4_kzyjqYgKQmXdsKkq66bFk9A@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 23 Nov 2018 16:30:53 -0800
Message-ID: <CA+RyBmW76xkwbX4Vm+4OV3rWY28nOoEye2Y4DFa=5JSA-N5PLg@mail.gmail.com>
Subject: Re: WGLC comments on draft-ietf-bfd-vxlan
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000001c188d057b5e37dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/GlXfcriWV2HKm_UUzPP_HWydTY0>
X-Mailman-Approved-At: Sat, 24 Nov 2018 07:57:31 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Nov 2018 00:31:13 -0000

Hi Anoop,
thank you for your comments and the discussion, much appreciated. All that
helped to improve the specification. I've uploaded the -04 version with
updates resulting from your comments and our discussion. Hope I've got them
all right, please let me know. Attached is the diff and the new version of
the draft.

Regards,
Greg

On Fri, Nov 23, 2018 at 2:46 PM Anoop Ghanwani <anoop@alumni.duke.edu>
wrote:

> Hi Greg,
>
> That is fine.
>
> Thanks,
> Anoop
>
> On Fri, Nov 23, 2018 at 1:10 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> 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 <anoop@alumni.duke.edu>
>> 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 <gregimirsky@gmail.com>
>>> 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 <anoop@alumni.duke.edu>
>>>> wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> See below prefixed with [ag4].
>>>>>
>>>>> Thanks,
>>>>> Anoop
>>>>>
>>>>> On Wed, Nov 21, 2018 at 4:36 PM Greg Mirsky <gregimirsky@gmail.com>
>>>>> 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
>>>>>>
>>>>>>>