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

Santosh P K <> Mon, 04 November 2019 13:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A77471201EA; Mon, 4 Nov 2019 05:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I4OiuB7Lb5Y6; Mon, 4 Nov 2019 05:12:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABB0912081B; Mon, 4 Nov 2019 05:12:05 -0800 (PST)
Received: by with SMTP id w18so17028793wrt.3; Mon, 04 Nov 2019 05:12:05 -0800 (PST)
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=6eDOeA2o5nZh+Z5V3ejB/rURnI9oM0BLbn4ANLuyBEc=; b=uhx4JeVmc0LZhOvewQK5+nhjHs6OvbIQm+gN98NBO6Wwbi2IBIvb5ACV7r6/1i1MPA vl39qzCoP1jptOnueg2uuEJNsMcngRkwqVgHPeELW+7MItNlcWPYDB3uIcWDW0e9aCPf 9b4cYYmOCyU5HVdoLJTv2CRVB7kb+sflINjFGFcN+1UNgKaDXSfR4vR6QXV0X/SleEP8 hvDe0FMwYZL5HOUwSfZnBbHw8g6je6Pl4/qsqLKQksTXbdjnsOX3X2V0hgyF7aEbslvY argi2kMIeUKIafZtZO7n5BjHyLmErlzfVUSJIzF97/hbXZfwikRZ2DpMo601EeXwIgvv ub9A==
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=6eDOeA2o5nZh+Z5V3ejB/rURnI9oM0BLbn4ANLuyBEc=; b=G1s6VtQkGKyZ686cODZY2qrUyngTPSRkwcbChFBE3Khe5M7STt9ieIM2hEkjygQZNY pzNDF70b1UYw9tsZN9ECuZeAa6XhfPNg+Bx95tpXaUE+BTGEISLdPszK7Dxmr7WzXwDs xjc6iUTQzxkEvVjcgrTrJBTA9xBTNPCb8i1MsWRxm8ZN0xTx58fRNP5wir3soe8+8peB YmPfUoBqF6Vqiv4tZE4vQa9c33YLuvOu3xz7MKoiW2GLHEVTxu6kpYNSoSzw7UuiD75T eB2yiBCB9m04h8OOTzTjyfCNCEQfnrnIj5Hgp2r0PRLOOitSEz1HOKxwFUic0LFPmA4B l8qQ==
X-Gm-Message-State: APjAAAUpL7hw+K/wP6hZdyblOUn0pn6pYoCGrvj9RfEfygZ+hyOv6e0j lNLZtjZoOvKpIgPr3AhE3uuNhExIIIvLdTgTXL/IwdiCs4I=
X-Google-Smtp-Source: APXvYqzHbKh556GRVdk/9At82HGS8lF0Nt252hLFPQ8GxRioi6+jmZ3x9N/gzdSG/1GmGAdphlAVkiOkWvKdmo7Z8Dg=
X-Received: by 2002:adf:e9c7:: with SMTP id l7mr23486809wrn.57.1572873124203; Mon, 04 Nov 2019 05:12:04 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Santosh P K <>
Date: Mon, 4 Nov 2019 18:41:52 +0530
Message-ID: <>
Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: Dinesh Dutt <>
Cc: "Joel M. Halpern" <>, rtg-bfd WG <>, NVO3 <>
Content-Type: multipart/alternative; boundary="000000000000d8525d0596850ff8"
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 13:12:07 -0000

     Thanks for your comments. Having fixed or multicast MAC addresses is
something was considered earlier in the draft based on the comments we
removed it in updated draft. If management VNI is used then MAC address
should not matter at right? as the packet has to take the exception path
and reach the CPU.

Santosh P K

On Mon, Nov 4, 2019 at 11:35 AM Dinesh Dutt <> wrote:

> Hi Joel,
> I'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a (or
> whatever else) for the maagement VNI. That fixes the additional burden of
> configuring BFD for the management VNI. Requiring another forwarding
> behavior for a VNI is additional overhead and *may* not be supported by
> existing implementations.
> Dinesh
> On Mon, Nov 4, 2019 at 9:45 AM, Joel M. Halpern <>
> wrote:
> 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 <
>> 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: