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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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: <[email protected]
<mailto:[email protected]>>
Date: Fri, Nov 1, 2019 at 10:45 AM
Subject: New Version Notification for
draft-ietf-bfd-vxlan-08.txt
To: Gregory Mirsky <[email protected]
<mailto:[email protected]>>, Mallik Mudigonda
<[email protected] <mailto:[email protected]>>, Sudarsan
Paragiri <[email protected]
<mailto:[email protected]>>, Vengada Prasad Govindan
<[email protected] <mailto:[email protected]>>, Santosh
Pallagatti <[email protected]
<mailto:[email protected]>>
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
