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

Greg Mirsky <gregimirsky@gmail.com> Fri, 23 November 2018 21:10 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 0522C127133; Fri, 23 Nov 2018 13:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 RH1oKoeBctIj; Fri, 23 Nov 2018 13:10:30 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 87B3C12426A; Fri, 23 Nov 2018 13:10:29 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id v5so9492783lfe.7; Fri, 23 Nov 2018 13:10:29 -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=C1nzAP0bSyJijoHg9YkYcMfH1gaoeg+hsXTQ6DHUE2M=; b=YVQp3utLFfUix2G5AxzqjcASDuh9fghRsbaBWQhUyQA7jnKM91/C0weEQrFo3MJYlW m28yEnNWKNE+mMSNOpxnPVIwllwiFRRysH9cETF7knESeiG5Jz+Dk3zM1i+E3rYJMWKK Sao+F2stsvBvT0si6nrWXV76YQWNhLm1rxQqJQu29kn6TiaV3OVfBIbcDqMELf9nDrGs HkCWjny95u7lRDqV04OBjfHqk3SCrYWLxaZqhsdhN7Neb4Fxh/foVf/EyfUNlrraG29i IN39xUdo6znaY35Igel02JsKOFecL23YZ/ge21ZB8VYncSzn0rtjk3uUCEAVE9RS9bqS nSWw==
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=C1nzAP0bSyJijoHg9YkYcMfH1gaoeg+hsXTQ6DHUE2M=; b=B3ceCuAQtWmgux0R53UYkNd3BTmGHPtEeRab8L1H2YvXbD/8XpXtEbRLxsku3wIlWi ez1CBoxmh/UncWqzcEWtH9jfls0g1wm4gwy9vBpqa5TZp/n/Gi51JeY0ysUt0yxTUmtw hwhBS5FAQdy1tSMxWZvBWMXmj8WBLXFcOPvJoH97b/FRgXS3FKYZl2OsHcRy6Og5pElD lpEll5Xgr0nhoRfezrqVOWN0hMYlR4opQKz/HBM8nAYAAIiXSPwic4F8IiSsMd2hyfOT eUtnTpTJtw4zABfjI5LPFuSfmnu8i3Gz8DKIOXUvW6mJU52Ve+cutSJkRhACrZW0P0EW ETBQ==
X-Gm-Message-State: AGRZ1gLZivW4CvAAJmSU6+Z9jNJLrtQSXCTbMnvhlrFr9gyK1unut2qa GiwszXGPWtxJlwa2ZxkOKjO4JYUXjor3FxQinjs=
X-Google-Smtp-Source: AJdET5f+dRak3YqUF5EGovLIvIdwu5jmU7EH7tK5YvFJ2bK2DdLT66eK/eSVdHPpGAXfJkjBTF/4znRdCFd75GvfbV8=
X-Received: by 2002:a19:26ce:: with SMTP id m197mr9914818lfm.23.1543007427433; Fri, 23 Nov 2018 13:10:27 -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>
In-Reply-To: <CA+-tSzz21Tu-su1TXj6cHea5-H+-n2kmU3KdzdWnMUL4E52HMQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 23 Nov 2018 13:10:16 -0800
Message-ID: <CA+RyBmXypByBZSmA7g3bcXGo=p+1Hrj_2Mak1qa3FXbzgPfoHg@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/alternative; boundary="000000000000991b78057b5b6953"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/MsE-wxv9G45OxbaehS9BDnVtvNk>
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: Fri, 23 Nov 2018 21:10:32 -0000

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