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

Dinesh Dutt <didutt@gmail.com> Wed, 06 November 2019 01:59 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 A68CC120274; Tue, 5 Nov 2019 17:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level:
X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GYr35f_ydiqB; Tue, 5 Nov 2019 17:59:45 -0800 (PST)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 DA529120236; Tue, 5 Nov 2019 17:59:30 -0800 (PST)
Received: by mail-pg1-x530.google.com with SMTP id r18so288764pgu.13; Tue, 05 Nov 2019 17:59:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=NnxM5GeWiC6+3Z90Ooy4THesBSVzZ04q5FE1HvLrgMg=; b=lFAOr+Tr4RYnz8UfM+sR911EUBxiqoDJKhB+AQ8i3D10zFRgluKxkxr7p2eeZ5p/xr 90YNytS7NwpAQB1jgkh3RRQT68stQARpWvBc0sCjMmzpTL3AN/eXZbll0zl7lTozloY7 Ejct4DTQmnivmwf3OSbqAji5nuUF/GAveiR6pJfGPEOb+qwCstehXmcjLJsBSnIeGfmh geCBiEIucUdh+cr1Kfy6HvUSiXH70+Afs8WjWkk2rVXf437MSQDo0AnsHh+qhK/QkdOU JTFRE9k98sY9FG9Ai7kObXUo6dIubp1SbjyDKCZmFIHpVHiea46mITstkHG/4Y+m+eZh U6/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=NnxM5GeWiC6+3Z90Ooy4THesBSVzZ04q5FE1HvLrgMg=; b=U1B09phEmozkuJJwTYhPs78hHcve/SxLG1xDnXe0NVhzHHD1HK1ppzfAh62CZsok95 Ewc/LBoxEsdFOakmTv4nDN81PNUfBjuSYmcFFiL/OVaYN1sVaqdYduy3nVdYOmlR1Rfz bibQTJwTl2he7q+qDNthMlf8zNt4BNDbVPJJrrefqPCRTUfT8YYd0R9N4lNY+sbfM5gC pSUfgUWd8+2NxAL9Pb42fjg6oo+6F3pH3ZCv4AmGX+8PZhl+1q75LBu308D3M9JbVGvT OK2zZRCgr+940B98Um0EYVJXC5AJqyBsy0iSH98/Jr0RTqYzx5kh25vcX7p+ziBRSPlb /pdg==
X-Gm-Message-State: APjAAAVNM9+GBJlo2WseHmTStZ0Q2wqA10ilKHtBolAOKLX6Y/WEabeN RSN+es+qCyLjQ9qlbdb3Fo0=
X-Google-Smtp-Source: APXvYqy7m3yS83HovtSEQSrQdln/e/n0jrCCl285aaR4V2qk4pzhtZ7oXzUEqlFul6YbHC/j6qJvKA==
X-Received: by 2002:a63:d308:: with SMTP id b8mr40123949pgg.246.1573005570146; Tue, 05 Nov 2019 17:59:30 -0800 (PST)
Received: from [192.168.0.104] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id w27sm20326925pgc.20.2019.11.05.17.59.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 17:59:29 -0800 (PST)
Date: Wed, 6 Nov 2019 07:29:18 +0530
From: Dinesh Dutt <didutt@gmail.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Santosh P K <santosh.pallagatti@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>
Message-ID: <7e9b8c35-bf9b-4de7-ae30-a2c74b7fb834@Spark>
In-Reply-To: <CA+-tSzz3vD9OzrM6m-WETVzHc=+1v30skYfx4_dTtGybzZiFEA@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> <1572888977.25948.5@smtp.gmail.com> <CA+RyBmX3Y_dBih9_E=n2_qPkLHHFqWNN1OtNMYvsEataebyoSQ@mail.gmail.com> <1573000145.25948.19@smtp.gmail.com> <CA+-tSzz3vD9OzrM6m-WETVzHc=+1v30skYfx4_dTtGybzZiFEA@mail.gmail.com>
Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt
X-Readdle-Message-ID: 7e9b8c35-bf9b-4de7-ae30-a2c74b7fb834@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5dc228fb_47432df2_7cc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/xx5KC7AOb-51IvY0kerc6JR_cP8>
X-Mailman-Approved-At: Tue, 05 Nov 2019 18:42:42 -0800
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: Wed, 06 Nov 2019 01:59:49 -0000

Anoop
,

I fear 0 may not be supported by a bunch of existing switching silicon.

Dinesh
On Nov 6, 2019, 7:08 AM +0530, Anoop Ghanwani <anoop@alumni.duke.edu>;, wrote:
> Greg,
>
> What is the resistance to getting an address assigned by IANA?
>
> (Apologies if I missed the discussion.)
>
> Also not sure about the value of the statement
> >>
> An implementation MAY use VNI number 1 as the
>   default value for the Management VNI.
> >>
> What prompted this, and if we need to recommend a value, why not 0?
>
> Thanks,
> Anoop
>
> > On Tue, Nov 5, 2019 at 4:29 PM Dinesh Dutt <didutt@gmail.com>; wrote:
> > > I understand Greg. Maybe suggest a value, rather than recommend it? Its just to reduce configuration. The key parts are to not change the existing VXLAN forwarding behavior and ensure that BFD between VTEPs doesn't leak to tenants (which typically don't exist in case of a management VNI).
> > >
> > > Dinesh
> > >
> > > On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
> > > > Hi Dinesh,
> > > > I agree that using a particular MAC over the Management VNI will minimize configuration and thus reduce the operator's headache. I'm concerned that adding RECOMMENDATION to use the specific MAC address over the Management VNI comes very close to requesting the assignment of the MAC for the Management VNI.
> > > >
> > > > Regards,
> > > > Greg
> > > >
> > > > > On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt <didutt@gmail.com>; wrote:
> > > > > > 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