Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt
Anoop Ghanwani <anoop@alumni.duke.edu> Mon, 04 November 2019 15:00 UTC
Return-Path: <ghanwani@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F06C120A62; Mon, 4 Nov 2019 07:00:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.139
X-Spam-Level:
X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 T3EUOhatCeIZ; Mon, 4 Nov 2019 07:00:43 -0800 (PST)
Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96371120986; Mon, 4 Nov 2019 07:00:42 -0800 (PST)
Received: by mail-vs1-f47.google.com with SMTP id y129so11163753vsc.6; Mon, 04 Nov 2019 07:00:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+xHobcSm4cxGdT5LCPpFYwZ5ktAQJo6VFhFSHG74+Dk=; b=l9vXdIiWn1vQqcearJZURuI2/7ey/A9JWE+k+YT9e7nh6wqdBbkLfo1uUk9zeYpDmw cdie8sBJrFwspzIedKhVyR8Y12pokH5rfui+ewRHeCLq06EojP1O4QPDuN5+Zbk4nQDE 28cThty8xiG/twpd6k0UXBsVJG90F15oWXfHaoyHlrvUtT1rSRN3dAuJzYuvFQj4FSKZ SsT71RROQKRmHtd92x4crR/xb/CttMPbrQ+t0b0SEzk9MyIHdjtjPlf43RTYmT9bmXuP +7SP/gr9UsxBUWb2fOMrsQogP4Pvi219h6Ud6I7hOckcsHPzNsTYEpM8BfUHY/wQafF0 cODg==
X-Gm-Message-State: APjAAAWCw7mvbGNhS0icqlPyDD9p0VXWXmzyBZBthBHp1wKq3AY+MOn6 nD62585WtG8NteRMI0Tn9Tg5LHnNzuhA1VAEj+RRgL6u
X-Google-Smtp-Source: APXvYqwd8D/dWVfQwJgG4YwJhIeTRG37KuYreiBi4EUv4E2yJO04uXIRJvZOMS8cu7AJBQ6OxXc9moyUvc2It6ydqrw=
X-Received: by 2002:a67:1a82:: with SMTP id a124mr12779625vsa.60.1572879641444; Mon, 04 Nov 2019 07:00:41 -0800 (PST)
MIME-Version: 1.0
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> <CA+-tSzw4TwmC_qxBX8Q4inWswMTS2nBmSVCJVcCN9PRpDa-ghw@mail.gmail.com> <CACi9rdvzrDXO=stf=fiiEOk_en=nTEvBhXYk33gdyjmRPJes-w@mail.gmail.com>
In-Reply-To: <CACi9rdvzrDXO=stf=fiiEOk_en=nTEvBhXYk33gdyjmRPJes-w@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Mon, 04 Nov 2019 07:00:27 -0800
Message-ID: <CA+-tSzy1zyrozrB17OmcG67QauU6Z5V3T0a-a9B9zQnFLjvnYg@mail.gmail.com>
Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: Santosh P K <santosh.pallagatti@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>, Dinesh Dutt <didutt@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000004d87360596869410"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/MjhCikaOwE1_zP6H-s3apQ4d1V0>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 15:00:50 -0000
Hi Santosh, I'm not aware of any implementation that uses a multicast MAC for this. The closest thing that I'm aware of that helps alleviate the need for knowing the MAC of the remote VTEP is what's done in open vswitch: http://www.openvswitch.org/support/dist-docs/vtep.5.html *b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:* *b**f**d**_**d**s**t**_**m**a**c*: optional string Set to an Ethernet address in the form *x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set the destination MAC to be used for transmitted BFD packets. The default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*. That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC would be the equivalent. Anoop On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.com> wrote: > Anoop, > Thanks for your comments. For non-managment VNI why do we need to have > multicast MAC address for backward compatibility for existing > implementation or there are any use cases such that we can avoid learning > of remote end VTEP? > > Thanks > Santosh P K > > On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani <anoop@alumni.duke.edu> > wrote: > >> Hi Joel, >> >> In that case I would propose the following text: >> >> "Destination MAC: If the BFD session is not using the Management VNI, >> the destination MAC address MUST be the address >> associated with the destination VTEP. If the BFD session uses >> the Management VNI, it may use any MAC address, since use of the >> Management VNI ensures that these packets will never be forwarded to a VM. >> The MAC address may be configured, or it may be learned via >> a control plane protocol. The details of how the MAC address >> to be used is obtained are outside the scope of this document." >> >> That said, for non-Management VNI, do we want to allow for flexibility >> for an implementation to use a multicast MAC of their choosing? If so, we >> should probably add a sentence for that too. >> >> Thanks, >> Anoop >> >> >> On Sun, Nov 3, 2019 at 7:52 PM 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: >>> > Hi Greg, >>> > >>> > In the case of the management VNI, are we trying to say that we would >>> > allow any MAC address other than a tenant MAC address? I would >>> suggest >>> > some more text be added to clarify what is permitted on the management >>> > VLAN. Assuming that we want to allow any MAC other than a tenant MAC, >>> > how does this get enforced? In other words, what can be done for the >>> > network to protect itself if a sender violates this? >>> > >>> > One possible answer is to restrict the MAC address that may be used to >>> > one that is owned by the VTEP or a "agreed on" multicast MAC address. >>> > That means the receiver only needs to validate for those, and just >>> > treats everything else as data. >>> > >>> > Also, for interoperability purposes, it would be best to specify that >>> a >>> > receiver MUST be able to handle any valid MAC address for the BFD >>> > session, while a sender MAY pick any of them. >>> > >>> > Thanks, >>> > Anoop >>> > >>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com >>> > <mailto:gregimirsky@gmail.com>> wrote: >>> > >>> > Hi Anoop, >>> > thank you for your comments and questions. Please find my notes >>> > in-line tagged GIM>>. >>> > >>> > Regards, >>> > Greg >>> > >>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >>> anoop@alumni.duke..edu <anoop@alumni.duke.edu> >>> > <mailto:anoop@alumni.duke.edu>> wrote: >>> > >>> > Hi Greg, >>> > >>> > A few comments. >>> > >>> > The draft has nits, specifically around the way the IPv6 >>> address >>> > is written. >>> > >>> > In section 4: >>> > >>> > BFD packet MUST be encapsulated -> >>> > >>> > BFD packets MUST be encapsulated >>> > >>> > GIM>> Thanks, will do. >>> > >>> > >>> > >>> >>> > >>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>> > addresses. The destination MAC address MAY be the >>> address >>> > associated with the destination VTEP. The MAC >>> address MAY be >>> > configured, or it MAY be learned via a control plane >>> protocol. >>> > The details of how the MAC address is obtained are >>> outside the >>> > scope of this document. >>> > >>> > >>> >>> > It looks like we have removed the option of using a well-known >>> > IANA assigned MAC. If so, why is the above a MAY and not a >>> > MUST? What else can it be? One interpretation is that it can >>> > be anything unicast, or multicast, as long as it's not a tenant >>> > MAC. Is that the intent? If so, it would be better to state >>> it >>> > that way. Also (and this is purely editorial), I think it >>> would >>> > be better if the first sentence above were moved to the end of >>> > the paragraph. >>> > >>> > GIM>> Yes, you're right, we've removed that option and have removed >>> > the request to IANA. I also agree that " MAY be the address >>> > associated with the destination VTEP" is not the right choice of >>> > normative language. On the other hand, MUST might be too >>> restrictive >>> > if BFD session is using the Management VNI. Would the following >>> > update address your concern: >>> > OLD TEXT: >>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>> > addresses. The destination MAC address MAY be the >>> address >>> > associated with the destination VTEP. The MAC address >>> MAY be >>> > configured, or it MAY be learned via a control plane >>> protocol. >>> > The details of how the MAC address is obtained are >>> outside the >>> > scope of this document. >>> > NEW TEXT: >>> > Destination MAC: If the BFD session is not using the >>> > Management VNI, >>> > the destination MAC address MUST be the address >>> > associated with the destination VTEP. The Destination >>> MAC >>> > MUST NOT be one of the tenant's MAC addresses. >>> > The MAC address MAY be configured, or it MAY be learned >>> via >>> > a control plane protocol. The details of how the MAC >>> address >>> > is obtained are outside the scope of this document. >>> > >>> > >>> > "The inner Ethernet frame carrying the BFD >>> > Control packet- has the following format:" >>> > >>> > Extraneous '-' after packet. >>> > >>> > GIM>> Thanks, will do that too. >>> > >>> > >>> > Thanks, >>> > Anoop >>> > >>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>> > <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote: >>> > >>> > Dear All, >>> > the new version includes updates resulting from the >>> > discussions of Joel's comments in the RtrDir review of BFD >>> > over VXLAN draft, comments from Anoop, and Dinesh. On >>> behalf >>> > of editors, thank you for your constructive comments and >>> for >>> > sharing your expertise, all much appreciated. >>> > I hope we've addressed all your comments, and the draft can >>> > proceed further. >>> > >>> > Regards, >>> > Greg >>> > >>> > ---------- Forwarded message --------- >>> > From: <internet-drafts@ietf.org >>> > <mailto:internet-drafts@ietf.org>> >>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>> > Subject: New Version Notification for >>> > draft-ietf-bfd-vxlan-08..txt >>> > To: Gregory Mirsky <gregimirsky@gmail.com >>> > <mailto:gregimirsky@gmail.com>>, Mallik Mudigonda >>> > <mmudigon@cisco.com <mailto:mmudigon@cisco.com>>, Sudarsan >>> > Paragiri <sudarsan.225@gmail.com >>> > <mailto:sudarsan.225@gmail.com>>, Vengada Prasad Govindan >>> > <venggovi@cisco.com <mailto:venggovi@cisco.com>>, Santosh >>> > Pallagatti <santosh.pallagatti@gmail.com >>> > <mailto:santosh.pallagatti@gmail.com>> >>> > >>> > >>> > >>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>> > has been successfully submitted by Greg Mirsky and posted >>> to the >>> > IETF repository. >>> > >>> > Name: draft-ietf-bfd-vxlan >>> > Revision: 08 >>> > Title: BFD for VXLAN >>> > Document date: 2019-11-01 >>> > Group: bfd >>> > Pages: 11 >>> > URL: >>> > >>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>> > Status: >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>> > Htmlized: >>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>> > Htmlized: >>> > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>> > Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>> > >>> > Abstract: >>> > This document describes the use of the Bidirectional >>> > Forwarding >>> > Detection (BFD) protocol in point-to-point Virtual >>> > eXtensible Local >>> > Area Network (VXLAN) tunnels forming up an overlay >>> network. >>> > >>> > >>> > >>> > >>> > Please note that it may take a couple of minutes from the >>> > time of submission >>> > until the htmlized version and diff are available at >>> > tools.ietf.org <http://tools..ietf.org> < >>> http://tools.ietf.org>. >>> > >>> > The IETF Secretariat >>> > >>> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >
- Fwd: New Version Notification for draft-ietf-bfd-… Greg Mirsky
- Re: New Version Notification for draft-ietf-bfd-v… Anoop Ghanwani
- Re: New Version Notification for draft-ietf-bfd-v… Greg Mirsky
- Re: New Version Notification for draft-ietf-bfd-v… Anoop Ghanwani
- Re: New Version Notification for draft-ietf-bfd-v… Joel M. Halpern
- Re: New Version Notification for draft-ietf-bfd-v… Dinesh Dutt
- Re: New Version Notification for draft-ietf-bfd-v… Joel M. Halpern
- Re: New Version Notification for draft-ietf-bfd-v… Anoop Ghanwani
- Re: New Version Notification for draft-ietf-bfd-v… Dinesh Dutt
- Re: New Version Notification for draft-ietf-bfd-v… Santosh P K
- Re: [nvo3] New Version Notification for draft-iet… Santosh P K
- Re: [nvo3] New Version Notification for draft-iet… Anoop Ghanwani
- Re: [nvo3] New Version Notification for draft-iet… Santosh P K
- Re: [nvo3] New Version Notification for draft-iet… Dinesh Dutt
- Re: [nvo3] New Version Notification for draft-iet… Anoop Ghanwani
- Re: [nvo3] New Version Notification for draft-iet… Greg Mirsky
- Re: [nvo3] New Version Notification for draft-iet… Dinesh Dutt
- Re: [nvo3] New Version Notification for draft-iet… Anoop Ghanwani
- Re: [nvo3] New Version Notification for draft-iet… Dinesh Dutt
- Re: [nvo3] New Version Notification for draft-iet… Anoop Ghanwani