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

Dinesh Dutt <> Wed, 31 July 2019 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34715120018; Wed, 31 Jul 2019 09:03:51 -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 SHvYZ3bDszCc; Wed, 31 Jul 2019 09:03:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E916E1202B5; Wed, 31 Jul 2019 09:03:48 -0700 (PDT)
Received: by with SMTP id c2so67077094wrm.8; Wed, 31 Jul 2019 09:03:48 -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=lm4L3A7OlPYMFgGhUe4DRvQYzeXl4XN3ID0apwPQrcc=; b=GGbSr+Zp0Xku6SByKHiP+VcKPL+AOLsHAFQ3nmQv0BTWMS8KammDiidho3MZAF+q10 jcMZ5ARrB1V2eWIGWiLNyCn0NNWRAm4Y46b7Am7OpULIjySv4OFhjTzoB+xpnTsEha3l FCFk+eX0JOhrW9HKYep6biJf7g21/dcQz6mbQp+1s/IaC/M54N7sTfdxOES+nYterYGB pzJhto9nYNdbDb48E9b/hHuTZXb6WoNsI+Zim1sbu7CLBuUeA7GZbaTilE6GI77lIQee HF91FNgExkfJEQ3kdCs8Nru1Eu927zXRgwiSy4pgpVqGGWh47ZxckH7/H70+nqeGiUtW 0QuQ==
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=lm4L3A7OlPYMFgGhUe4DRvQYzeXl4XN3ID0apwPQrcc=; b=bFbVVZh0DgeBIiJ0/TcPvtqiqj91+FVufPApdH4LR5kjeACAlXAu2jOdYZS/7iuYiB wt1N7NdGXnTq73VL3uW61SKvP+Y+V6KEFs7lupdLVwRv+ypSdfumr8kFibLu2PvISFh6 c4LO7Ber1cccVnrzWksiqaQCPcF7YFvoe7GcbqlCn2mxX5659QEV9LcKZK5UsxvKEwWN xv0N3XMIjB6rnjrCGEjcJH6wmZbzj5zc+W/72+e6llU6iNMBwn16mzIf+gUMuPrK/BBj QCblrRj5RyzgxZQ4rUMJAxsAhbGGhRBhs1E3G4CJ9ZJd27bRLsUbwpLAfBvH32WxAmpt KslQ==
X-Gm-Message-State: APjAAAWmQWw5MA3+edpEDFDBlqu4YcRGW6mPkFXUyU6ZcWI+T4u+hefU rhuRfMjwCxJz41vGozGsg3ix2VJMOxatcBIFzes=
X-Google-Smtp-Source: APXvYqzmKCS0eAoMMG0L5FgDRVj0qhfB/lnLE234Yw7WuPJiRxtwuuIGSdgnS/0quqZqFvsut61GibMyvLDP5iFqMt0=
X-Received: by 2002:adf:cd04:: with SMTP id w4mr86484709wrm.230.1564589026660; Wed, 31 Jul 2019 09:03:46 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dinesh Dutt <>
Date: Wed, 31 Jul 2019 09:03:34 -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="0000000000002756e2058efc455a"
Archived-At: <>
X-Mailman-Approved-At: Wed, 31 Jul 2019 10:38:52 -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: Wed, 31 Jul 2019 16:03:51 -0000

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 ?


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