IETF Logo Mail Archive

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

Jeffrey Haas <jhaas@pfrc.org> Wed, 30 October 2019 11:21 UTC

Return-Path: <jhaas@pfrc.org>
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 5233A1200CE; Wed, 30 Oct 2019 04:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 VBwnA_CfRJsR; Wed, 30 Oct 2019 04:21:49 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AA70A120046; Wed, 30 Oct 2019 04:21:49 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 887F11E2D2; Wed, 30 Oct 2019 07:25:23 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9F5E4E3E-1804-4C1F-BD6B-AA6E8EE02DA9"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <14104891-8e3e-ba70-4744-4e9f6d52561a@joelhalpern.com>
Date: Wed, 30 Oct 2019 07:21:47 -0400
Cc: Dinesh Dutt <didutt@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, Santosh P K <santosh.pallagatti@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
Message-Id: <34B881C2-252D-462D-B15B-5881F36D7934@pfrc.org>
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <CACi9rduyvhweJd_aNx6miiUGyu-nCeqnNHGbPjyCfswHx1RD5A@mail.gmail.com> <CA+RyBmXLBLARxhA4MUvD6DE8vvY1oDP0opkxDqiPA4zYw9Jpug@mail.gmail.com> <1571860470.2855.11@smtp.gmail.com> <CACi9rdtwiuH2VjuUkzeg3+PhwcFMSqFepbcM0tgmRxSbcR3AQQ@mail.gmail.com> <CA+-tSzyi=uDdqSDq4u7kytAucX136mO2XtPtR=DG+KKAC5PjCQ@mail.gmail.com> <88a1320e-093a-a101-d8a6-6ae6d7648466@joelhalpern.com> <CA+-tSzxCpLOmhpBXP1k5vLY20qA5db9nbq4qEiH00jo=EH+w8g@mail.gmail.com> <d7b25f3a-5f1e-30da-8a41-0d11e3c2d04c@joelhalpern.com> <CA+-tSzzBfp9Wy8KO6MbxFNXZBhC3bL7u92VwqJTA82WrwGUAgg@mail.gmail.com> <c773cd4f-320c-fb15-3b7b-d0016b7d5978@joelhalpern.com> <CA+-tSzxUs9PGv+y1PBquaAhuq4wK_=TkR+b_ET6j7OBHf4Mq7Q@mail.gmail.com> <97bdb8b4-b334-53fb-05a6-2d1fc8684ad3@joelhalpern.com> <CA+-tSzw76E0AM2AJR=2GQsXJ3MtFUtsug7KoGQzAP-=Ds8u7Fg@mail.gmail.com> <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com> <1572400778.28051.7@smtp.gmail.com> <14104891-8e3e-ba70-4744-4e9f6d52561a@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/TNXtLe42qUtElDnb6bW2l8INsak>
X-Mailman-Approved-At: Wed, 30 Oct 2019 04:22:37 -0700
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: Wed, 30 Oct 2019 11:21:51 -0000

Joel,


> On Oct 29, 2019, at 10:08 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> 
> I presume that most silicon implementations of VxLAN VTEPs do not have any logic for trapping out BFD packets under any circumstances.  While some may have been built anticipating this draft, we have to assume that many will not be able to support this.  So it goes when you add features to a protocol.

Just to be clear, BFD itself (RFC 5880) doesn't necessarily require the IP portion of the stack. What's required is sufficient information for an implementation to manage the BFD session for the transport in question.

Things that tend to run IP usually end up with a bit of programming that tells it that the forwarding layer can trap on a given 5-tuple signature.  Things like BFD on LAG will catch a layer deeper in some circumstances such as startup.

This discussion is running rather similar (albeit more publicly) to the BFD on LAG discussion as various vendors try to figure out how they can successfully trap BFD for the testing point in question.

-- Jeff

v2.23.0 | Report a Bug | By Email