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

Anoop Ghanwani <anoop@alumni.duke.edu> Fri, 23 November 2018 18:47 UTC

Return-Path: <ghanwani@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 8EE2B129C6A; Fri, 23 Nov 2018 10:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 Mu015y32aK4W; Fri, 23 Nov 2018 10:47:37 -0800 (PST)
Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (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 95BC21288EB; Fri, 23 Nov 2018 10:47:37 -0800 (PST)
Received: by mail-ua1-f50.google.com with SMTP id u19so4378120uae.4; Fri, 23 Nov 2018 10:47:37 -0800 (PST)
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=Xoh0WGkQxyiYyyeciVxfVL88e3w3h/ub3ftpMz9Sric=; b=gZkZKRu+K1J0k7/jkkLYN3WN0jgA1TUCm4qOEFGIGtDbwubNLK71fgVRVH7HzOrYJV lZsc0olHy+OXcIcIxirjoPtWbM8RWueIgSIU2UBOIU8YbBI7v9YH+O3NqTU/vLcS3mxA Nd+L27BzKMtZdqJJKtMC3V5udqP7GS7dEfBWk1kPbxAWYHiuu0luymPvUH/WEwfzoOQr +PU7NC3FM9Lr/N4uQj9MfepLSG31VaxGr/MNmheYyUedrZ9OEJdFynojD89jxZuLjmg/ bF+JQblGYsVpdEikXJ3VbLP6TTTRbE18Durqfm9lGG+fWCKU5biThTqeHOlMGNMUY4oS zxPQ==
X-Gm-Message-State: AA+aEWbpqitgbO7JVTwWw8JG+TO+YQTznDS9CFazvfQsVliIjndF2NPu sN8LOKfepQw8Ls8dCdffpI5rXgpOvnbtvCs8zpE=
X-Google-Smtp-Source: AFSGD/VpLls1kwphVSWsRSfWvIWlMQOgiXkl5lq5Zc4pafN/lpaFofUDIgdYpHc/YfQA8bB747htWbWZTeDf/l/Bybo=
X-Received: by 2002:ab0:8d9:: with SMTP id o25mr7315388uaf.127.1542998856469; Fri, 23 Nov 2018 10:47:36 -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>
In-Reply-To: <CA+RyBmWG1AST-6ukBTsipgLvv9RcxJBpFQ_av8w=aTTWV+7Wmg@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Fri, 23 Nov 2018 10:47:23 -0800
Message-ID: <CA+-tSzz21Tu-su1TXj6cHea5-H+-n2kmU3KdzdWnMUL4E52HMQ@mail.gmail.com>
Subject: Re: WGLC comments on draft-ietf-bfd-vxlan
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: rtg-bfd@ietf.org, nvo3@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ba94b2057b596a93"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/K0M-fzpMHCSILpcaonHYrnmWm24>
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 18:47:40 -0000

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