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

Dinesh Dutt <didutt@gmail.com> Sat, 03 August 2019 01:08 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 E72C4120018; Fri, 2 Aug 2019 18:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 qRaRF3KL08n9; Fri, 2 Aug 2019 18:07:57 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 B84D012001E; Fri, 2 Aug 2019 18:07:56 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id f17so67882484wme.2; Fri, 02 Aug 2019 18:07:56 -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=j2U0O270eDA4gDw8gtgMG/LJeKmjB98dBgNme7kUWXE=; b=lHJenMZ/fFoY+vN7pwEnXjOZH4vpuouv6+m0V/NsyK29qEot8Z2uYNJI1vWEFzF9hv RDxhytFVlXzesg8QQTOtjGQL+fu0K8U3Chjv4ymhvhd4YiBl3MsXaKO1LNhc8z9C+gQk 2iWLo/6Y02s5pfjH5BqGjDO48Na5uitJdAsW2xDFVQOsjs4xfaJm40CS5b5Qv4RO7I6A 62dDWlsmOJIcOx5DJ3o08L4n7wVm8hSvWpwoEgHeUeXDMxfJ8+ztOja08R4YkbyEbxIe 07JHLmnEy8YiWsvidHva3AVksnpD3NDlOw22TdvFT2iEszHx0C0ReGDfBdJa6tt2c/0A iLyw==
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=j2U0O270eDA4gDw8gtgMG/LJeKmjB98dBgNme7kUWXE=; b=YRLMc1/PzYi3jIH4JXqjKHgQhSFCMgZZr7TBFr7w5X4+qq1ypXYiIlZpUYPcIL0i/G NkE636zrcn6Bu0gFIMeIolkomsaVmpcOt8d1RvCjWi51uGX/dnUkKBTCHDbcGw1gwc3y a+4L8iEZdpMChsHXoBTLdXNdBl4NGt4+vgculBctfZ+iKnTdNyM85YeGqjqpcW7RuxBk EMMRWWYtFwA2sFkZdD9WkLjP6N3GODVo2cj1Tv2t+7gWX1XL1LH0kvfwgBQICSEgnsGE /4HHwmiG343RwKmx6CiqgbM2n4e5C3Q3RSsRvB0yaj8CU64PtfXg72LeioDCltcTHdaf IBQQ==
X-Gm-Message-State: APjAAAVo9CuR5MST1gisEAsbwwA2GjrNZR7b0rgzQ2SskkflZAgL6VzY e92jmdSR9WZ3uJc1CqoiTAnjVjHxbyTgbwR49xGrxg0D
X-Google-Smtp-Source: APXvYqx5sa8JJcPOxAHfb0Q6pLx5Ebwx7bpFk7Ll2Z+ZQ6ut2A3HmaCwXwm6CLYzfwbLnaw89gnQkNvXU+jza7Lfp3o=
X-Received: by 2002:a1c:238e:: with SMTP id j136mr6035450wmj.144.1564793030326; Fri, 02 Aug 2019 17:43:50 -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> <CAOPNUTB+fNXmB8jctUrVh5aAYd-R=CC6cv=1QpzMoYcVs0EUtw@mail.gmail.com> <df39e2b9-598a-5121-525c-f435d72e2184@joelhalpern.com> <CAOPNUTDHu2Ywy2=1eNzM-1jAmSOxOrHXGC2uZ3x7jVb7+vhoig@mail.gmail.com> <7500b927-4b05-0e65-0afc-4bf57770f15c@joelhalpern.com> <CAOPNUTAD9-CSBz2dFvRzyggM2JgemN54JK5p=Qj7weni7QKrHQ@mail.gmail.com>
In-Reply-To: <CAOPNUTAD9-CSBz2dFvRzyggM2JgemN54JK5p=Qj7weni7QKrHQ@mail.gmail.com>
From: Dinesh Dutt <didutt@gmail.com>
Date: Fri, 2 Aug 2019 17:43:38 -0700
Message-ID: <CAOPNUTCSXm5maOmYnh8_7oxZsCn=9rJPFS7O9P+1a8ie-u=7Cg@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="000000000000b840a7058f2bc403"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/sJ6GBkyJ80pxO_yF6t_tH0W3yMw>
X-Mailman-Approved-At: Sat, 03 Aug 2019 10:13:30 -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: Sat, 03 Aug 2019 01:08:02 -0000

What I mean is "How do you infer that it excludes the case I'm talking
about?".

Dinesh

On Fri, Aug 2, 2019 at 5:41 PM Dinesh Dutt <didutt@gmail.com> wrote:

> The abstract reads this: "
>
> This document describes the use of the Bidirectional Forwarding
>    Detection (BFD) protocol in point-to-point Virtual eXtensible Local
>    Area Network (VXLAN) tunnels forming up an overlay network."
>
> How do you infer what you said?
>
> Dinesh
>
>
> On Fri, Aug 2, 2019 at 5:38 PM Joel M. Halpern <jmh@joelhalpern.com>
> wrote:
>
>> I am going by what the draft says its purpose is.  If you (Dinesh) want
>> the draft to fulfill a different purpose, then either ask the chairs to
>> take this draft back to the WG, or write a separate draft.
>> As currently written, the behavior Greg proposed meets the needs, and
>> does so in a way that is consistent with VxLAN.
>>
>> Yours,
>> Joel
>>
>> On 8/2/2019 8:30 PM, Dinesh Dutt wrote:
>> > What is the stated purpose of this BFD session? The VTEP reachability
>> is
>> > determined by the underlay, I don't need VXLAN-encaped packet for that.
>> > Do we agree?
>> >
>> > If I want to test the VXLAN encap/decap functionality alone, picking
>> any
>> > single VNI maybe fine. But is this all any network operator wants? Why?
>> > In what situations has this been a problem? I suspect operators also
>> > want to verify path continuity over a specific VNI. If you say this is
>> > not defined by the document, I disagree because the current version
>> > talks about controlling the number of BFD sessions between the VTEPs
>> > (see section 3). More importantly, this is a real problem that
>> operators
>> > like to verify.
>> >
>> > Dinesh
>> >
>> > On Fri, Aug 2, 2019 at 5:08 PM Joel M. Halpern <jmh@joelhalpern.com
>> > <mailto:jmh@joelhalpern.com>> wrote:
>> >
>> >     What is special about the management VNI is precisely that it is
>> NOT a
>> >     tenant VNI.  The VxLAN administration does know how it allocates
>> VNI to
>> >     tenants, and which VNI it has allocated.  In contrast, it does not
>> know
>> >     which IP addresses or MAC adddresses teh tenant is using or may plan
>> >     to use.
>> >
>> >     Yours,
>> >     Joel
>> >
>> >     On 8/2/2019 6:41 PM, Dinesh Dutt wrote:
>> >      > 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 <mailto:jmh@joelhalpern.com>
>> >      > <mailto:jmh@joelhalpern.com <mailto: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>
>> >     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>> >      >      > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>> >     <mailto: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>>
>> >      >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>
>> >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>>>
>> >      >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>
>> >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>>
>> >      >      >     <mailto: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>>
>> >      >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>
>> >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>>>
>> >      >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>
>> >      >     <mailto:santosh.pallagatti@gmail.com
>> >     <mailto:santosh.pallagatti@gmail.com>>
>> >      >      >     <mailto: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>>
>> >      >     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>> >     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>
>> >      >      >     <mailto:jmh@joelhalpern.com
>> >     <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com
>> >     <mailto:jmh@joelhalpern.com>>
>> >      >     <mailto: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
>> >>>
>> >      >      >     <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 <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> <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
>> >     <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>>>
>> >      >      >     <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 <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>
>> >     <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 <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>>>
>> >      >      >      >             <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
>> >     <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> <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
>> >     <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
>> >      >      >      >              >
>> >      >      >      >
>> >      >      >
>> >      >
>> >
>>
>