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

Dinesh Dutt <didutt@gmail.com> Fri, 02 August 2019 22:41 UTC

Return-Path: <didutt@gmail.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 0E6CD120018; Fri, 2 Aug 2019 15:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rxk_ymvw6YsG; Fri, 2 Aug 2019 15:41:38 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DA9120024; Fri, 2 Aug 2019 15:41:37 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id x4so25497990wrt.6; Fri, 02 Aug 2019 15:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UpCGH6Q1CELB09CkBKKGYLowvCj5SRgKdUmxuNFEZ44=; b=JBAf9OjQmjbO2YRc9uaRjTeb7EQ1zZNU79tiEfBedrSSfSNFmZEAZ9y17YG6N2qRcw O6n8V2DxCcls4Id8UIXBQOVZRGHA3gaZdlV935J3WaTS6G6LAoCMrzU3DKyHy9Naxxqc VYVT7KBvY31CyD95CADTF/lfbfOjxZkMITS2Otiod8li5tUieKT4V4cOKQCq3j20YFXt YTeDgPg1FZm29JUSSL153l5IuOJ7mODMBs+BU+RmTKQpEJb/BcWoUFabC6+X0p5nMNLc hmxiN23jiOCPT3Q9f11gpMgirFLZEIJqVrHG06yWXJVbtNt8j7B4DNGGZPWChRdmNrDS tzdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UpCGH6Q1CELB09CkBKKGYLowvCj5SRgKdUmxuNFEZ44=; b=hQwOgjNK9AADK4vbvQ33rd6pNPWVZT06F35gfAo/+JAQQObIZKVpA2omm9DSwbNw1Z CLOKb1L/o5uiiEFIHSziztdbsZPSHsz8Aa5n9WBSwgz0Zn891VfALRDALyyL3wl0OEQZ h82avsLIwW6TaWCw3XaVYKowlVIBgO1JJagFn9Q4q/Nz4CpuhreI7ZiB3yY2Vwmj1Fvi JsBACcjelJos2y8+ewDrmXoAvqpLONqKQ7iFaxakkgi12SoFe3X5ZSxFAkvfiul9IjIC fmVf03rPnxFhfkvTY0G1TQe564gS07+WLB/SUNabyBZe4aLDlNgg8ki354zJt8APZ6DQ IqNQ==
X-Gm-Message-State: APjAAAWP4kjjhJpjQDyub+UYrDWnjYk7ZA06tXzZiWsAjqnsz61XWkQj Bm7DjT4Z1Unvt+33229B501lq8tyWi8s0xnOvDM=
X-Google-Smtp-Source: APXvYqy3N4UAi6SuV4ADEzXg6xsRvDNZOD25W2klBuLEgCrkqTnYFiz5T+Xx4ow1TRq3OOEcJiWqMWfUfaLKofygXNQ=
X-Received: by 2002:adf:cf0d:: with SMTP id o13mr1709092wrj.291.1564785695903; Fri, 02 Aug 2019 15:41:35 -0700 (PDT)
MIME-Version: 1.0
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> <7437a61e-133c-c53e-fd1d-c3a31e4e90a9@joelhalpern.com>
In-Reply-To: <7437a61e-133c-c53e-fd1d-c3a31e4e90a9@joelhalpern.com>
From: Dinesh Dutt <didutt@gmail.com>
Date: Fri, 2 Aug 2019 15:41:23 -0700
Message-ID: <CAOPNUTB+fNXmB8jctUrVh5aAYd-R=CC6cv=1QpzMoYcVs0EUtw@mail.gmail.com>
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: "Joel M. Halpern" <jmh@joelhalpern.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
Content-Type: multipart/alternative; boundary="0000000000008dd2f5058f2a0fee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/EpuH7Wq908JTXOezROIeGaZNsKA>
X-Mailman-Approved-At: Fri, 02 Aug 2019 15:43:49 -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: Fri, 02 Aug 2019 22:41:41 -0000

The assumption of an IP address within any VNI is suspect that way. What's
special about a single VNI, the management VNI? The VTEP IP address does
not belong in reality in any VNI.

Dinesh

On Fri, Aug 2, 2019 at 3:17 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

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