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 >>>>> >>>>>>
- WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky