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

Dinesh Dutt <didutt@gmail.com> Mon, 04 November 2019 04:07 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 4B4451208DE; Sun, 3 Nov 2019 20:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) 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 8hrTViSlkleK; Sun, 3 Nov 2019 20:07:51 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 B31B2120122; Sun, 3 Nov 2019 20:07:51 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id c184so11280937pfb.0; Sun, 03 Nov 2019 20:07:51 -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=KknlE3iPQ+kpOaoGckMCIOJa12P4AlEm/m2TPwkJXaw=; b=cE3mg9OmEBPuJaWoBIoqCx+UBrd8UJQtuh01poQGG6UgUq377/6FM7o7CMo6+1A9yY ihTMblbWG877zfjihlcSgd4ItQH2S1i8vqiYwN+eC6db0BpaNmBMptqquQNOWoYjixIJ Owl9NwioZCBHwXwzYnHScWRpbO6FbhFAy+JUocLlz61NSng1epZdNdh6PK27vFL0fIg/ nXqbC540YOw1bFRYdalTkbkVmzjPDNTSfIVgI35Egay8mCNkKlfwf0BnLuJeDJWD85rB O5uOevvCu6LqIvY/gY0hCc1uAan7ufrbNztKTGdidtVx2NutQR8uKCR/s/8OmKLVf5zk H6gQ==
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=KknlE3iPQ+kpOaoGckMCIOJa12P4AlEm/m2TPwkJXaw=; b=RE7DifW+RmxyrstBW2oAGAxqFDj+F27dP50ushwWfiG5fgeZl+paOLi8zShswcxRqp MFESn9VLuSuboYGwV5iTaWuwW+iOJL/pMJN4lOJH1mx8I0AKVrIYRaegw00Eq5IkJO9P 5Tyt6XioMcGJ6wPjR46WRP3YYGl1L9kAa7JHP4pnkZQC6j4Y2p1AoVoGPIDVTO+fTHOD 8IvIabYLzB8ja08JuauGZHKyFNqJL4v+16PWRggwIuU7Kf1xwNZcf41mYgxsGB/CzDvv RggTqtbn+Kcbi+WbY1we5xHGjiq+QGeRmpx9fwE91jJNYJDPgXRU1V93pkJkKHRRvnUJ 26Ug==
X-Gm-Message-State: APjAAAVOb7AzWlEFO3QbSuSzz/KSi3F6Dyg1LCNYKUogrKNFonZLSxR3 RgUT9tFBylCkji+97VI9Ykk=
X-Google-Smtp-Source: APXvYqyY4owCa2RFxeifjPofXyGERMa9j46MdzdVvTUP1WKj///+maGYyjH6nFTtYHPek+H/1VBKyw==
X-Received: by 2002:a63:fe06:: with SMTP id p6mr27020749pgh.245.1572840470953; Sun, 03 Nov 2019 20:07:50 -0800 (PST)
Received: from [192.168.0.105] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id o7sm21366532pjo.7.2019.11.03.20.07.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Nov 2019 20:07:49 -0800 (PST)
Date: Mon, 04 Nov 2019 09:07:45 +0500
From: Dinesh Dutt <didutt@gmail.com>
Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>
Message-Id: <1572840465.25948.2@smtp.gmail.com>
In-Reply-To: <c5ff1b1f-4b07-9be5-0519-de3849ea5ce8@joelhalpern.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>
X-Mailer: geary/0.12.4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-qVqwxBFkaVO+qtFLQG+7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/NcGHye0hBHe7UtFbMUMEwqUeRJ8>
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 04:07:54 -0000

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:
>> 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
>>