Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt

"Joel M. Halpern" <> Mon, 04 November 2019 04:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22A82120888; Sun, 3 Nov 2019 20:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FG4OTueA4wbk; Sun, 3 Nov 2019 20:15:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B04A7120251; Sun, 3 Nov 2019 20:15:40 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 475zx84XRHzwPfy; Sun, 3 Nov 2019 20:15:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1572840940; bh=KCFY8gDhutxmXEBfV3KADvIJo+BW6Ku9VzovXA/LXzQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JS1V1U+pokKDfEyUYmRGTQIjWLlTqzEQ06py1T1RWHZ+4iXmlxHbR5F6qqqmsrXOA dgsmYVbCPuiuLNsI3sujvUPy6ICW7LkdE8jxXarP+fQsmd23jp1B6bdsHjaaBiZZtq FURFj/3CaiAfdFFqEU5D2j9DyCy/pHy6dw+g97n4=
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 475zx800wQzFpVD; Sun, 3 Nov 2019 20:15:39 -0800 (PST)
Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: Dinesh Dutt <>
Cc: rtg-bfd WG <>, NVO3 <>
References: <> <> <> <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Sun, 3 Nov 2019 23:15:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
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: Mon, 04 Nov 2019 04:15:43 -0000

Are you referring to the Ethernet MAC addresses that the VTEP probably 
has on its underlay physical network?  I can see why those would be good 
candidates to use on the management VNI.  What I do not see is why we 
want to require it?  Using those would seem to complicate configuring 
BFD, since as far as I know those addresses are not known to remote VTEPs.


On 11/3/2019 11:07 PM, Dinesh Dutt wrote:
> While I agree that there are no tenant MACs on a management VNI, I'm 
> loathe to introduce another forwarding behavior, one that's 
> VNI-specific. MUST use a MAC thats owned by the VTEP is all that's 
> required. All VTEPs, existing and past work with this, because that's 
> the VTEP decapsulate and forward behavior.
> Dinesh
> On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern <> wrote:
>> Anoop, I think I at least am misunderstanding you. If one is using the 
>> management VNI, as I understand it there is no tenant. So there are no 
>> tenant MAC addresses. (This is one of the reasons I like using the 
>> management VNI.) Yours, Joel On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: