Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 31 October 2019 15:59 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A7C12012C; Thu, 31 Oct 2019 08:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 Mp9JBc4jlFlY; Thu, 31 Oct 2019 08:59:19 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A484912022C; Thu, 31 Oct 2019 08:59:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 473qkv3mV3zG0X6; Thu, 31 Oct 2019 08:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572537559; bh=fBkgjbTDgS4xUWP5vf07Dy79b5fK2vHCWTvIRoprwYE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QNB/6QqMNX41ozPK5g/dBoDDAuJLX+tP2T6CaHuLPLPDeX3V9GW069HVzRqW9N4/j kQQkRSn/+8XrrCw83EYMcVddmJbvf7F/a0a2D5BQU+MInOsctbZwIxOc1E5h0Lz66G iqToorWlQjKcWbA+aEELkL7Akrgl8d/vTUe8Vass=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 473qks1frgzFpgT; Thu, 31 Oct 2019 08:59:16 -0700 (PDT)
To: Greg Mirsky <gregimirsky@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>
Cc: Dinesh Dutt <didutt@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, Santosh P K <santosh.pallagatti@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
References: <CA+-tSzw76E0AM2AJR=2GQsXJ3MtFUtsug7KoGQzAP-=Ds8u7Fg@mail.gmail.com> <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com> <1572400778.28051.7@smtp.gmail.com> <CA+-tSzyNu8XVqL7=cGVaT7Mbg5yO6d3ohgv2qPTrMHRV1vw0rg@mail.gmail.com> <1a38424c-6bc1-4414-a7fd-c1e2105b581a@Spark> <CA+-tSzzSNnR=fKRU+mEX=d+tL5B0u8eNUAoGcPvfrna_qHL7Hg@mail.gmail.com> <1572435956.28051.12@smtp.gmail.com> <CA+RyBmWgvjDLdxEz7oZEfYjtJT=7CZbiV5bRkx=gf3hQHHokOw@mail.gmail.com> <20191030203051.GD10145@pfrc.org> <CA+RyBmVTWMOuXaWVk_i1Lk7i+GgfiESkfVcLXARNnPD0Y3N5zQ@mail.gmail.com> <20191030211742.GE10145@pfrc.org> <CA+RyBmUfKi79pnPqsA6KNFR9e6cqG42z8yo3c40BcZHL4D79zQ@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <34b67556-a405-e4d7-7f72-d097f1201860@joelhalpern.com>
Date: Thu, 31 Oct 2019 11:59:14 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CA+RyBmUfKi79pnPqsA6KNFR9e6cqG42z8yo3c40BcZHL4D79zQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/-J3edqwxqPoqRaVkujDfaHblOtE>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2019 15:59:23 -0000
Explicitly restricting the discard behavior to the management VNI takes care of my concern. Thank you, Joel On 10/31/2019 11:48 AM, Greg Mirsky wrote: > Hi Jeff, > thank you for the detailed clarification of your questions. Please find > my follow-up notes in-lined tagged GIM2>>. > > Regards, > Greg > > On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas <jhaas@pfrc.org > <mailto:jhaas@pfrc.org>> wrote: > > Greg, > > On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky wrote: > > On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas <jhaas@pfrc.org > <mailto:jhaas@pfrc.org>> wrote: > > > > > Greg, > > > > > > From the updated text: > > > > > > "At the same time, a service layer BFD session may be used > between the > > > tenants of VTEPs IP1 and IP2 to provide end-to-end fault > management. In > > > such case, for VTEPs BFD Control packets of that session are > > > indistinguishable from data packets. If end-to-end defect > detection is > > > realized as the set of concatenated OAM domains, e.g., VM1-1 - > IP1 -- > > > IP2 - VM2-1, then the BFD session over VXLAN between VTEPs SHOULD > > > follow the procedures described in Section 6.8.17 [RFC5880]." > > > > > > In the case that two VMs are running BFD to each other as a user > > > application > > > rather than as part of the virtualized environment, it's > unlikely that > > > they'd be treated as concatenated domains. To do so, the > tenant VMs would > > > have to have a sense that they are indeed virtual. > > > > > > Is your intent in this text that BFD implementations on the > server should > > > detect BFD sessions between servers and change them to a > concatenated > > > session? > > > > > GIM>> No, we do not suggest that the concatenation of BFD sessions be > > automagical. That may be controlled via the management plane though. > > Then my suggestion is we may not want this text. > > It's fine to say "if tenants want to run BFD to each other, and that is > standard BFD (RFC 5881) from the perspective of those tenants" if that's > your intent. Leave automagic out of the spec. :-) > > GIM2>> I'd take the passage referring to the concatenated path out. That > will leave it as: > At the same time, a service layer BFD session may be used between the > tenants of VTEPs IP1 and IP2 to provide end-to-end fault management. > In such case, for VTEPs BFD Control packets of that session are > indistinguishable from data packets. > > > > > Section 5 comment: > > > > > > : The UDP destination port and the TTL of the inner IP packet > MUST be > > > : validated to determine if the received packet can be > processed by > > > : BFD. BFD Control packets with unknown MAC address MUST NOT be > > > : forwarded to VMs. > > > > > > I'd suggest pushing the second sentence into the prior section > since it > > > deals with MAC addresses rather than the UDP procedures. > > > > > GIM>> Could you please clarify your suggestion - move to Section > 4 or to > > the preceding paragraph? I think it is the latter but wanted to > make sure. > > Full section 5 from your draft-8 candidate: > : 5. Reception of BFD Packet from VXLAN Tunnel > : > : Once a packet is received, the VTEP MUST validate the packet. > If the > : Destination MAC of the inner Ethernet frame matches one of the MAC > : addresses associated with the VTEP the packet MUST be processed > : further. If the Destination MAC of the inner Ethernet frame > doesn't > : match any of VTEP's MAC addresses, then the processing of the > : received VXLAN packet MUST follow the procedures described in > : Section 4.1 [RFC7348]. > > It's not clear what that procedure is, with respect to BFD. Section 4.1 > basically says is that when a mapping is discovered, deliver it to > that VM > with headers removed. > > Section 4.1 really doesn't discuss dropping behavior. > > : > : The UDP destination port and the TTL of the inner IP packet MUST be > : validated to determine if the received packet can be processed by > : BFD. > > This is fine. > > : BFD Control packets with unknown MAC address MUST NOT be > : forwarded to VMs. > > This appears to be clarifying the missing point in the prior > paragraph. If > that's the case, why is this sentence not part of the prior paragraph? > > GIM>> So I thought. Moving the sentence to the first paragraph > highlighted the contradiction others had pointed earlier: > On the one hand: > If the Destination MAC of the inner Ethernet frame doesn't > match any of VTEP's MAC addresses, then the processing of the > received VXLAN packet MUST follow the procedures described in > Section 4.1 [RFC7348]. > To which we add: > BFD Control packets with unknown MAC address > MUST NOT be forwarded to VMs. > But the unknown MACs are treated as BUM according to the last paragraph > in Section 4.2 of RFC 7348: > Note that multicast frames and "unknown MAC destination" frames are > also sent using the multicast tree, similar to the broadcast frames. > In light of that, can this draft require that BFD packets with unknown > MAC be dropped and not flooded over the corresponding to the VNI domain? > I think that in addition to moving the sentence up the statement must be > updated: > OLD TEXT: > BFD Control packets with unknown MAC address > MUST NOT be forwarded to VMs. > NEW TEXT: > If the BFD session is using the Management VNI (Section 6), > BFD Control packets with unknown MAC address > MUST NOT be forwarded to VMs. > Comments? Suggestions? > > > > -- Jeff >
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… John E Drake
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel Halpern Direct
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K