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 >> >> *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 >>>> >>>
