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
>
