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
>