Dinesh, The multicast MAC was mentioned by me (because I incorrectly assumed that is what the original proposal was), hence Santosh's question. Sorry for the confusion.
Anoop On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt <[email protected]> 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 <[email protected]> > 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 > > *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 >>> >>
