Anoop , I fear 0 may not be supported by a bunch of existing switching silicon.
Dinesh On Nov 6, 2019, 7:08 AM +0530, Anoop Ghanwani <[email protected]>, wrote: > Greg, > > What is the resistance to getting an address assigned by IANA? > > (Apologies if I missed the discussion.) > > Also not sure about the value of the statement > >> > An implementation MAY use VNI number 1 as the > default value for the Management VNI. > >> > What prompted this, and if we need to recommend a value, why not 0? > > Thanks, > Anoop > > > On Tue, Nov 5, 2019 at 4:29 PM Dinesh Dutt <[email protected]> wrote: > > > I understand Greg. Maybe suggest a value, rather than recommend it? Its > > > just to reduce configuration. The key parts are to not change the > > > existing VXLAN forwarding behavior and ensure that BFD between VTEPs > > > doesn't leak to tenants (which typically don't exist in case of a > > > management VNI). > > > > > > Dinesh > > > > > > On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky <[email protected]> > > > wrote: > > > > Hi Dinesh, > > > > I agree that using a particular MAC over the Management VNI will > > > > minimize configuration and thus reduce the operator's headache. I'm > > > > concerned that adding RECOMMENDATION to use the specific MAC address > > > > over the Management VNI comes very close to requesting the assignment > > > > of the MAC for the Management VNI. > > > > > > > > Regards, > > > > Greg > > > > > > > > > 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 > > > > > > > bfd_config_remote : bfd_dst_mac: optional string > > > > > > > Set to an Ethernet address in the form > > > > > > > xx:xx:xx:xx:xx:xx to set > > > > > > > the destination MAC to be used for transmitted BFD > > > > > > > packets. The > > > > > > > default is 00:23:20:00:00:01. > > > > > > > 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] > > > > > > > > > > > > > > <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 > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nvo3 mailing list > > > > > > > > > > > [email protected] > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/nvo3
