IETF Logo Mail Archive

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

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 04 November 2019 04:15 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A82120888; Sun, 3 Nov 2019 20:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 FG4OTueA4wbk; Sun, 3 Nov 2019 20:15:40 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04A7120251; Sun, 3 Nov 2019 20:15:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 475zx84XRHzwPfy; Sun, 3 Nov 2019 20:15:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; 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 b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 475zx800wQzFpVD; Sun, 3 Nov 2019 20:15:39 -0800 (PST)
To: Dinesh Dutt <didutt@gmail.com>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>
References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <CA+RyBmUn2zSME51_rDW+y-GdWTmOXQiV7BKkRbNwcy12q8ZjxA@mail.gmail.com> <CA+-tSzxvknwYwvh-s-UK_C7YoF04eiFhyBvVxoNmT=52=EUnWw@mail.gmail.com> <CA+RyBmU0FViBV8TrwpLN7hUVMkbp9h4E-N048T4BM7a=7F6MdA@mail.gmail.com> <CA+-tSzxNHF0pRq1-7sPz4eWqCVVpf52jDhhqq0iNFu02Eso1pQ@mail.gmail.com> <c5ff1b1f-4b07-9be5-0519-de3849ea5ce8@joelhalpern.com> <1572840465.25948.2@smtp.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <13b756b6-4a3f-e128-aeef-214e48727c6c@joelhalpern.com>
Date: Sun, 03 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: <1572840465.25948.2@smtp.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/zWVgUdUwVcg5K6dlAyY0a5jdlfE>
Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=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.

Yours,
Joel

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 <jmh@joelhalpern.com> 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:

v2.23.0 | Report a Bug | By Email