Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt
Dinesh Dutt <didutt@gmail.com> Mon, 04 November 2019 17:36 UTC
Return-Path: <didutt@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 2834C120BBA; Mon, 4 Nov 2019 09:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.536
X-Spam-Level:
X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.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 9Z8OkQo0UQfE; Mon, 4 Nov 2019 09:36:24 -0800 (PST)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 9BD77120BAD; Mon, 4 Nov 2019 09:36:24 -0800 (PST)
Received: by mail-pg1-x535.google.com with SMTP id 29so454915pgm.6; Mon, 04 Nov 2019 09:36:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=1Glmi7fk9WAipwghDMWJDXH2fl/cVkYgnq1+gUAhhVM=; b=c5DKFNKA6w5YtuR5aS88aXkEZhd8Gbmme/OYY0SwMxS2FwcbS1I+joCyOzYzzJubT6 vjGu+uHvA6kO7+ehClZwr3UpNwHizBziB2KJa4TaeQxpqRhpRhj3YaixDTZ2Cl6hdsAJ coVOUqieITM6sXoz/34qpP1z0lJa28V7y0OGuAMCB/VPbHUqupCfZVCOuyLJsEIq9M7t r8XGsu0wclSQrUMXtJBL2n8ZPv8H1I1p4v4myEzgpOrvqjQGj0JpvVI+tgjvk984lOJm azuhRQRTz0BhTpZ5IpQmvd+UUEtXbP9BrcK5pe0KdLyrqsLKnnfzhOZNMpShcfj7HCJf y80A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=1Glmi7fk9WAipwghDMWJDXH2fl/cVkYgnq1+gUAhhVM=; b=rgu04X8yUwRwioX7CqujWQzI2qxMTgRy/NoJQQxBR7kxC/prL2q1DxANW9XYJvgDW4 eMIxppy4sCVPx7i6SdrCBHkT3YasBLR/XFndE2vnZh6GaLVkOWit5VYeYuhph2/mDEEp RXkUPzMyW7+Ug37SRmF0Shsx99TR3i7oY8EFNZTmoSXESOruKeWmkrzAbGXHV69wUf6H 27p/DVggzHhW5woiaPlIFJoaueGXM+rCsz7g3UwpXKrY8Syo/yoLRlF5p/Jy+N86KpUP ruZllsuKOTi/5GBiWJyu6lhg/36oCZBxEMS/l8EEPGE7NKu6/tM8YhfV/Ozk5c/fhAPZ mcqw==
X-Gm-Message-State: APjAAAUFM1ZnCiXxpi7oCX1q7D20j/O4HQi7sIX+9qP+1m/McnjJc4nN r5tp0OMbb3YxYOU7SseATRk=
X-Google-Smtp-Source: APXvYqyChcbFrRmK0Ei0LF9W15jDnmtB+O0S73N3xwGUgTlvEzLQo7+ClTIY03oOJxpaykxuO9ZBCA==
X-Received: by 2002:aa7:8b4d:: with SMTP id i13mr33110836pfd.226.1572888983982; Mon, 04 Nov 2019 09:36:23 -0800 (PST)
Received: from [192.168.0.105] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id g19sm8855718pfi.65.2019.11.04.09.36.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Nov 2019 09:36:22 -0800 (PST)
Date: Mon, 04 Nov 2019 22:36:17 +0500
From: Dinesh Dutt <didutt@gmail.com>
Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>
Message-Id: <1572888977.25948.5@smtp.gmail.com>
In-Reply-To: <CA+-tSzy1zyrozrB17OmcG67QauU6Z5V3T0a-a9B9zQnFLjvnYg@mail.gmail.com>
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> <CA+-tSzy1zyrozrB17OmcG67QauU6Z5V3T0a-a9B9zQnFLjvnYg@mail.gmail.com>
X-Mailer: geary/0.12.4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-w8Y5Woiq3+aBHyCgs3YL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZgKkVdXNbLdbehlHtFqMwj-VUp4>
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 17:36:32 -0000
I didn't suggest the use of a multicast MAC, any MAC would be fine in the management VNI since there can be no tenant VMs on a management VNI. I was recommending specifying a unicast MAC. Santosh, as I mentioned to Joel, I don't want to add additional forwarding requirements--such as VNI-specific behavior--in VXLAN. The existing mechanism is sufficient for the case we're discussing here. Just pick a MAC in management VNI for the sake of configuration simplicity. Dinesh On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote: > 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 > bfd_config_remote : bfd_dst_mac: optional string > Set to an Ethernet address in the form > xx:xx:xx:xx:xx:xx to set > the destination MAC to be used for transmitted BFD > packets. The > default is 00:23:20:00:00:01. > 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 >>>> > <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>. >>>> > >>>> > 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