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

Dinesh Dutt <> Thu, 01 August 2019 04:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14962120137; Wed, 31 Jul 2019 21:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R_VNVekf2E1P; Wed, 31 Jul 2019 21:48:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B15112003E; Wed, 31 Jul 2019 21:48:54 -0700 (PDT)
Received: by with SMTP id v15so63129402wml.0; Wed, 31 Jul 2019 21:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RMXKLi7VYQIsq62QoPtgdLVg41oA7OO+zyAhbv/H8ps=; b=YPD1e3rtTV8Jb4LuVMlIWRP7Whxtnl/8fSJnQtn55X9x4RWz9/i2gubnQVWqswf2Ig u9yjaPK0VlX13beLPg2tO6S2zHUwGezxgrlD4y3IaetYwOElbS3EITiuPCEzPeTKtbdI nzPvOrdmE7vrjh3YZ34yrVonyaQUNEWFXJEfU3on6qX8IOFkRWYdmaWGx1ugtLfEzv1I mRKjBF9tSi9Pw5HxCYEnX/JdB9ZreAOZnHl3p6pxLNHaKpiXxFkmbrorEfdV4uHjyqyS J3tbZT6JMw9rMVQx4W0GrMEkegiTj5i3DDMF/08gkJhJgDiQj4yVWyA+CiA+isoF/op7 PUOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RMXKLi7VYQIsq62QoPtgdLVg41oA7OO+zyAhbv/H8ps=; b=Ywm2Tb0bFAtHbg6WJUVg6EtDxFBNOPdTGb74E687niRbJHSwt+NwSEAR8YtXAxWjBp MuiA1hJP9z+5WeFQq5J7jeC2Us87WFjwOXFW8nEWDUUbUp/yqpFfAJR3hrBOoXUkk+OK MEZP9+72pO0lXvn9uoMyw8A1K9yJZdQrykHLBI171cKINFDYhEIZZDwdG9aQ5Gp42Zc1 FDzvrYbyo87e2m0UREr88ObzYdG+D7FwthflovNY3g4e2yZjzskR+4lm1hQMxGh00yig Sm03w106VWzH2emhuotKAjtUChr7JwIUuB11LMrcL1SnOObggYk+8qNBF/hs0e1aN54j +8KQ==
X-Gm-Message-State: APjAAAXxPzEU8VCGF5JVrmMVoAGTbnBtOtz3sn1uOBJlgkH30CWEbN9M W7q/RccLAuqm3orxh2j0LfflF4wgPWKmBjzyaBg=
X-Google-Smtp-Source: APXvYqwZ344B/Ybj+1jLbdQnBFGcCHOPb9VWrmBAsuuABX7jUThG4KWu6d3DvxPDz3qkG9OHWre8Oa4/kz7PDNQrXTM=
X-Received: by 2002:a7b:c74a:: with SMTP id w10mr108181365wmk.99.1564634932770; Wed, 31 Jul 2019 21:48:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Dinesh Dutt <>
Date: Wed, 31 Jul 2019 21:48:41 -0700
Message-ID: <>
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Greg Mirsky <>
Cc: rtg-bfd WG <>, "T. Sridhar" <>, Joel Halpern <>,, Martin Vigoureux <>,
Content-Type: multipart/alternative; boundary="0000000000005efede058f06f593"
Archived-At: <>
X-Mailman-Approved-At: Thu, 01 Aug 2019 08:34:44 -0700
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Aug 2019 04:48:57 -0000

 I don't understand his objection. My recommendation is to understand that
before we propose new text. I fear otherwise that we'll have a new draft in
a few months to address the issue of using non-mgmt VNI.

On Jul 31, 2019, 12:07 PM -0700, Greg Mirsky <>om>, wrote:

Hi Dinesh,
if I recall correctly, T.Sridhar has noted that VTEP's MAC must not be used
as the destination MAC address in the inner Ethernet frame.

Also, I should have been more precise in the proposed text, please see the
updated version to stress that the management VNI MUST NOT be one of the
tenant's VNIs:

An operator MUST select a VNI number to be used as Management VNI.
Management VNI number MUST NOT be one of the tenant's VNIs to prevent
sending VXLAN packets received on Management VNI to a tenant. VNI number 1
is RECOMMENDED as the default for Management VNI.

On Wed, Jul 31, 2019 at 2:25 PM Dinesh Dutt <> wrote:

> Hi Greg,
> On Wed, Jul 31, 2019 at 9:20 AM Greg Mirsky <> 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.
> If you use the inner IP address as the VTEP IP address, then use the MAC
> address that the VTEP would respond with when replying to an ARP for that
> VTEP IP address. If a VXLAN expert disagrees with this, could you kindly
> tell me who it is so that I can understand their disagreement? So this
> handles the case where the VNI is not a user-tenant VNI. If the VNI used in
> the BFD packet is a user-tenant VNI, then the receiving VTEP MUST have an
> IP address in that VNI (mapped to a VRF) else you cannot use that VNI in
> the BFD packet. Why won't this combination address all the cases you've
> listed? What am I missing? Define VNI 1 as a possible use, not VNI 0. I
> objected to VNI 0 because there are too many switching siicon out there and
> some of them will not be able to handle this scenario.
> Dinesh
>> Regards,
>> Greg
>> On Wed, Jul 31, 2019 at 12:03 PM Dinesh Dutt <> 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 <>
>>> 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