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

Anoop Ghanwani <anoop@alumni.duke.edu> Fri, 23 November 2018 22:46 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 35371128CB7; Fri, 23 Nov 2018 14:46:54 -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 iJ404sDQ0pJl; Fri, 23 Nov 2018 14:46:52 -0800 (PST)
Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.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 45593128AFB; Fri, 23 Nov 2018 14:46:52 -0800 (PST)
Received: by mail-vs1-f50.google.com with SMTP id g68so7976045vsd.11; Fri, 23 Nov 2018 14:46:52 -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=M8tsQlVKK97UCot7wecXYcEu826Ce08DczWAxmVcqN8=; b=UbIM4/7TMQL/ucty2GKLGk1WSw/FgKNdbKGN7e4aJDruyND393Igm9yyG2WwFGVso6 ztNhIGqzTqbhraS8D5RfXWHCSwCiGVsn4mozG3Szz2LS9QzFURU6uToNpJP9i2P1dpbs htMTip68zq0ngFzetArGFHFxVkGWXI9CY1rPSARPTIiLAX5vDt/hFHYRLV90FjlBJ79P gO++s68AZt2tvhmDuUmfdapnhg2riuNFKr3Fd2yuqRgce2X2VFdcbUBrgT1GkdIDgRG7 Bz9kM4AL3MUGGsqgJQ/GtBz6/DrQmug+m5zzhMd4co3ryBx3y89BvJGVe90dhJaigbqw dDiA==
X-Gm-Message-State: AGRZ1gJPvJpwHK+FahsDDrBeI0583kS8kT25OcS6DGj17Nd1DvU3ewgX KbSSTYO9+B1F6n8SF+FnGuUn+CG6kvS4ZYMBaGI=
X-Google-Smtp-Source: AFSGD/VfMArYeFz5wSLzaQDnKOmtFE2tGanEEm6SvkcCqCey2Ni/F+ZO3/TXssUO2ICSVBYXP32j1660qVacp/HjEn0=
X-Received: by 2002:a67:f851:: with SMTP id b17mr7763118vsp.23.1543013211269; Fri, 23 Nov 2018 14:46:51 -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>
In-Reply-To: <CA+RyBmXypByBZSmA7g3bcXGo=p+1Hrj_2Mak1qa3FXbzgPfoHg@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Fri, 23 Nov 2018 14:46:38 -0800
Message-ID: <CA+-tSzz71ezd3GE+Uq4K7CvAh4_kzyjqYgKQmXdsKkq66bFk9A@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="000000000000576f26057b5cc29a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/jGRcZmDH_6L0Tc5e0Rl351fDmMQ>
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 22:46:54 -0000

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