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
*b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:*
*b**f**d**_**d**s**t**_**m**a**c*: optional string
Set to an Ethernet address in the form
*x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set
the destination MAC to be used for transmitted BFD packets. The
default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*.
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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> 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 <[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] <[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> <
>>> http://tools.ietf.org>.
>>> >
>>> > The IETF Secretariat
>>> >
>>>
>> _______________________________________________
>> nvo3 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>
