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

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

Return-Path: <jhaas@slice.pfrc.org>
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 0A727120825; Wed, 30 Oct 2019 14:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V-2rpqV4hoCY; Wed, 30 Oct 2019 14:14:07 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 33823120103; Wed, 30 Oct 2019 14:14:07 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id C608E1E2D3; Wed, 30 Oct 2019 17:17:42 -0400 (EDT)
Date: Wed, 30 Oct 2019 17:17:42 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Dinesh Dutt <didutt@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, "Joel M. Halpern" <jmh@joelhalpern.com>, 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
Message-ID: <20191030211742.GE10145@pfrc.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+RyBmVTWMOuXaWVk_i1Lk7i+GgfiESkfVcLXARNnPD0Y3N5zQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/JLBdJkE6VEDsozWAWPYE3RWsmDQ>
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: Wed, 30 Oct 2019 21:14:09 -0000

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> 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. :-)

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


-- Jeff