Re: BFD over VXLAN: Trapping BFD Control packet at VTEP

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 02 August 2019 22:17 UTC

Return-Path: <jmh@joelhalpern.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 2B58D1200A4; Fri, 2 Aug 2019 15:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 iFwxg1rszY55; Fri, 2 Aug 2019 15:17:08 -0700 (PDT)
Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 A5F19120077; Fri, 2 Aug 2019 15:17:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 460hNN3zwlz26ggY; Fri, 2 Aug 2019 15:17:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1564784228; bh=uhSgHD/kW5tTVQ2OKU5PkjJ72CTpBTF/TSqLfVup5Uk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=E7htyAbfBXS6oaRXjTqc744JYqCkbRXXnD7zYllCxtzk9BB8Ugda5j5a4Zn73ikNG U1PIYvK2TZVwEwpdYCHr+0DDadtgHWgRUiTOhf7haieVB+0VYFFpzjxtToN3ha4HQ0 WgmNgQ+ZaK4hkzmNgFwhfw5wekFfPMN/8Slj1W6Y=
X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net
Received: from [172.20.7.244] (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 mailb1.tigertech.net (Postfix) with ESMTPSA id 460hNM1qkXz26gZm; Fri, 2 Aug 2019 15:17:07 -0700 (PDT)
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Dinesh Dutt <didutt@gmail.com>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, bfd-chairs@ietf.org, Martin Vigoureux <martin.vigoureux@nokia.com>, draft-ietf-bfd-vxlan@ietf.org
References: <CA+RyBmW=byLBNfVQSdaEoMf-QnJtj13k788XhbZ9tqH4bcgqNQ@mail.gmail.com> <CAOPNUTBJztjmNgrDyHgMo8-nRazAaXACGJJZ6Lx8z8aRVBM+GA@mail.gmail.com> <CA+RyBmWrM3v37BO8O_VOGG-NJ+UbrtSVQ_2GwW0R+vLkxbtvHw@mail.gmail.com> <CACi9rdvKTLwBQn9mcJksGTW79QTFj0d45DOpDT1Jee4QpGnv3Q@mail.gmail.com> <c57a3cf3-ab77-99df-0f78-104edef3275c@joelhalpern.com> <CACi9rdubTnzgCVZK0syRf3fsrpTU45SpQV57n2rNcNCqk+3+7Q@mail.gmail.com> <CACi9rdsmP8SFwP+Her45XKFwQZ3SQgwLpr62kAY-kP4vZtnFnQ@mail.gmail.com> <CAOPNUTD4nQ4YROxUA9hxdTFOtv4XpmazA=apm2ceuCxt3yM=XA@mail.gmail.com> <bf019ac6-2580-7f9e-66c4-5a24c1b2eb2b@joelhalpern.com> <CAOPNUTC=q4O=QUhFFiuv8UnU1uuCjHYkJV-Oha07NTJ_X7SODQ@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <7437a61e-133c-c53e-fd1d-c3a31e4e90a9@joelhalpern.com>
Date: Fri, 02 Aug 2019 18:17:05 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAOPNUTC=q4O=QUhFFiuv8UnU1uuCjHYkJV-Oha07NTJ_X7SODQ@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/rtg-bfd/qZZQ-hql0YaGn08PSaMpbQuQboU>
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, 02 Aug 2019 22:17:11 -0000

Your response seems to miss two points:

First, the problem you describe is not what the document says it is 
solving.  To the degree it discusses it at all, the document says "   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. "

Second, you assume the existence of an IP address for a VTEP within a 
VNI.  As with the MAC address, the VTEP does not have an IP address 
within the VNI.  Some implementations may have created such a thing, but 
the general construct, as defined to date, does not support such.

In short, you are requiring a behavior that violates the architectural 
structure of overlay / underlay separation, and common usage.  And you 
are doing so to support a use case that the working group has not 
indicated in the document as important.

Yours,
Joel

On 8/2/2019 5:01 PM, Dinesh Dutt wrote:
> Joel,
> 
> You understood correctly.
> 
> The VNIs may not share fate due to misconfiguration. And I strongly 
> suspect someone will want to use BFD for that because its about checking 
> path continuity as stated by the draft. As long as there's a valid IP 
> (because it's BFD) owned by the VTEP in that VNI, you can use BFD in 
> that VNI. Thats all that you need to dictate.  That IP address has a MAC 
> address and you can use that on the inner frame. That is all normal 
> VXLAN processing. The outer IP is always that of the VTEP.
> 
> Dinesh
> 
> On Fri, Aug 2, 2019 at 11:03 AM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     If I am reading your various emails correctly Dinesh (and I may have
>     missed something) you are trying to use the MAC address because you
>     want
>     to be able to send these BFD packets over arbitrary VNI to monitor the
>     VNI.  That is not a requirement identified in the document.  It is not
>     even a problem I understand, since all the VNI between an ingress and
>     egress VTEP share fate.
> 
>     Yours,
>     Joel
> 
>     On 8/2/2019 1:44 PM, Dinesh Dutt wrote:
>      > Thanks for verifying this. On Linux and hardware routers that I'm
>     aware
>      > of (Cisco circa 2012 and Cumulus), the physical MAC address is
>     reused
>      > across the VNIs on the VTEP. Did you check on a non-VMW device?
>     This is
>      > more for my own curiosity.
>      >
>      > To address the general case, can we not define a well-known (or
>     reserve
>      > one) unicast MAC address for use with VTEP? If the MAC address is
>      > configurable in BFD command, this can be moot.
>      >
>      > Dinesh
>      >
>      > On Fri, Aug 2, 2019 at 10:27 AM Santosh P K
>      > <santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>> wrote:
>      >
>      >     I have cross checked point raised about MAC address usage. It is
>      >     possible that tenant could be using physical MAC address and
>     when a
>      >     packet comes with valid VNI with a MAC address that is being
>     used by
>      >     tenant then packet will be sent to that tenant. This rules
>     out the
>      >     fact that we could use physical MAC address as inner MAC to
>     ensure
>      >     packets get terminated at VTEP itself.
>      >
>      >     Thanks
>      >     Santosh P K
>      >
>      >     On Wed, Jul 31, 2019 at 11:00 AM Santosh P K
>      >     <santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>>
>      >     wrote:
>      >
>      >         Joel,
>      >             Thanks for your inputs. I checked implementation within
>      >         Vmware. Perhaps I should have been more clear about MAC
>     address
>      >         space while checking internally. I will cross check again for
>      >         the same and get back on this list.
>      >
>      >         Thanks
>      >         Santosh P K
>      >
>      >         On Wed, Jul 31, 2019 at 10:54 AM Joel M. Halpern
>      >         <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrote:
>      >
>      >             Sorry to ask a stupid question.  Whose implementation?
>      >
>      >             The reason I ask is that as far as I can tell, since the
>      >             tenant does not
>      >             have any control access to the VTEP, there is no
>     reason for
>      >             the VTEP to
>      >             have a MAC address in the tenant space.  Yes, the
>     device has
>      >             a physical
>      >             MAC address.  But the tenant could well be using that MAC
>      >             address.  Yes,
>      >             they would be violating the Ethernet spec.  But the whole
>      >             point of
>      >             segregation is not to care about such issues.
>      >
>      >             On the other hand, if you tell me that the VMWare
>      >             implementation has an
>      >             Ethernet address that is part of the tenant space, well,
>      >             they made up
>      >             this particular game.
>      >
>      >             Yours,
>      >             Joel
>      >
>      >             On 7/31/2019 1:44 PM, Santosh P K wrote:
>      >              > I have checked with implementation in data path.
>     When we
>      >             receive a
>      >              > packet with valid VNI then lookup for MAC will
>     happen and
>      >             it is VTEP own
>      >              > MAC then it will be trapped to control plane for
>      >             processing. I think we
>      >              > can have following options
>      >              > 1. Optional managment VNI
>      >              > 2. Mandatory inner MAC set to VTEP mac
>      >              > 3. Inner IP TTL set to 1 to avoid forwarding of packet
>      >             via inner IP
>      >              > address.
>      >              >
>      >              >
>      >              > Thoughts?
>      >              >
>      >              > Thansk
>      >              > Santosh P K
>      >              >
>      >              > On Wed, Jul 31, 2019 at 9:20 AM Greg Mirsky
>      >             <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
>     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>      >              > <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>
>      >             <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>>> wrote:
>      >              >
>      >              >     Hi Dinesh,
>      >              >     thank you for your consideration of the
>     proposal and
>      >             questions. What
>      >              >     would you see as the scope of testing the
>      >             connectivity for the
>      >              >     specific VNI? If it is tenant-to-tenant, then
>     VTEPs
>      >             will treat these
>      >              >     packets as regular user frames. More likely, these
>      >             could be Layer 2
>      >              >     OAM, e.g. CCM frames. The reason to use 127/8 for
>      >             IPv4, and
>      >              >     0:0:0:0:0:FFFF:7F00:0/104 for IPv6 is to safeguard
>      >             from leaking
>      >              >     Ethernet frames with BFD Control packet to a
>     tenant.
>      >              >     You've suggested using a MAC address to trap the
>      >             control packet at
>      >              >     VTEP. What that address could be? We had proposed
>      >             using the
>      >              >     dedicated MAC and VTEP's MAC and both raised
>     concerns
>      >             among VXLAN
>      >              >     experts. The idea of using Management VNI may
>     be more
>      >             acceptable
>      >              >     based on its similarity to the practice of using
>      >             Management VLAN.
>      >              >
>      >              >     Regards,
>      >              >     Greg
>      >              >
>      >              >     On Wed, Jul 31, 2019 at 12:03 PM Dinesh Dutt
>      >             <didutt@gmail.com <mailto:didutt@gmail.com>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>
>      >              >     <mailto:didutt@gmail.com
>     <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
>     <mailto:didutt@gmail.com>>>>
>      >             wrote:
>      >              >
>      >              >         Hi Greg,
>      >              >
>      >              >         As long as the inner MAC address is such
>     that the
>      >             packet is
>      >              >         trapped to the CPU, it should be fine for
>     use as
>      >             an inner MAC is
>      >              >         it not? Stating that is better than trying to
>      >             force a management
>      >              >         VNI. What if someone wants to test
>     connectivity
>      >             on a specific
>      >              >         VNI? I would not pick a loopback IP
>     address for
>      >             this since that
>      >              >         address range is host/node local only. Is
>     there a
>      >             reason you're
>      >              >         not using the VTEP IP as the inner IP
>     address ?
>      >              >
>      >              >         Dinesh
>      >              >
>      >              >         On Wed, Jul 31, 2019 at 5:48 AM Greg Mirsky
>      >              >         <gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>
>      >             <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>> <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>
>      >             <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>>> wrote:
>      >              >
>      >              >             Dear All,
>      >              >             thank you for your comments,
>     suggestions on
>      >             this issue,
>      >              >             probably the most challenging for this
>      >             specification. In the
>      >              >             course of our discussions, we've agreed to
>      >             abandon the
>      >              >             request to allocate the dedicated MAC
>     address
>      >             to be used as
>      >              >             the destination MAC address in the inner
>      >             Ethernet frame.
>      >              >             Also, earlier using VNI 0 was changed from
>      >             mandatory to one
>      >              >             of the options an implementation may
>     offer to
>      >             an operator.
>      >              >             The most recent discussion was whether
>     VTEP's
>      >             MAC address
>      >              >             might be used as the destination MAC
>     address
>      >             in the inner
>      >              >             Ethernet frame. As I recall it, the
>     comments
>      >             from VXLAN
>      >              >             experts equally split with one for it
>     and one
>      >             against. Hence
>      >              >             I would like to propose a new text to
>     resolve
>      >             the issue. The
>      >              >             idea is to let an operator select
>     Management
>      >             VNI and use
>      >              >             that VNI in VXLAN encapsulation of BFD
>      >             Control packets:
>      >              >             NEW TEXT:
>      >              >
>      >              >                 An operator MUST select a VNI
>     number to
>      >             be used as
>      >              >                 Management VNI. VXLAN packet for
>      >             Management VNI MUST NOT
>      >              >                 be sent to a tenant. VNI number 1 is
>      >             RECOMMENDED as the
>      >              >                 default for Management VNI.
>      >              >
>      >              >             With that new text, what can be the
>     value of
>      >             the destination
>      >              >             MAC in the inner Ethernet? I tend to
>     believe
>      >             that it can be
>      >              >             anything and ignored by the reciever VTEP.
>      >             Also, if the
>      >              >             trapping is based on VNI number, the
>      >             destination IP address
>      >              >             of the inner IP packet can from the range
>      >             127/8 for IPv4,
>      >              >             and for IPv6 from the range
>      >             0:0:0:0:0:FFFF:7F00:0/104. And
>      >              >             lastly, the TTL to be set to 1 (no
>     change here).
>      >              >
>      >              >             Much appreciate your comments,
>     questions, and
>      >             suggestions.
>      >              >
>      >              >             Best regards,
>      >              >             Greg
>      >              >
>      >
>