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
