Subject: Fwd: New Version Notification for draft-ietf-bfd-vxlan-08.txt

From: Greg Mirsky <[email-masked]>
Date: Fri, 1 Nov 2019 10:53:29 -0700

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-masked]>
Date: Fri, Nov 1, 2019 at 10:45 AM
Subject: New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: Gregory Mirsky <[email-masked]>, Mallik Mudigonda <
[email-masked]>, Sudarsan Paragiri <[email-masked]>, Vengada
Prasad Govindan <[email-masked]>, Santosh Pallagatti <
[email-masked]>

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.

The IETF Secretariat

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 1 Nov 2019 16:24:07 -0700

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

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.

"The inner Ethernet frame carrying the BFD
   Control packet- has the following format:"

Extraneous '-' after packet.

Thanks,
Anoop

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 3 Nov 2019 18:50:13 -0800

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-masked]> wrote:

> GIM>> Thanks, will do.

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

> Extraneous '-' after packet.
GIM>> Thanks, will do that too.

>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 3 Nov 2019 19:32:44 -0800

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-masked]> wrote:

>>> 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.
>>> [email-masked]>, Sudarsan Paragiri <[email-masked]>,
>>> Vengada Prasad Govindan <[email-masked]>, Santosh Pallagatti <
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08
>>>
>>> Abstract:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 3 Nov 2019 22:52:05 -0500

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.
> 
> 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-masked] 
> <mailto:[email-masked]>> 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-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Greg,
> 
>         A few comments.
> 
>         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: If the BFD session is not using the
>     Management VNI,
>         On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky
>         <[email-masked] <mailto:[email-masked]>> 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.
>             From: <[email-masked]
>             <mailto:[email-masked]>>
>             To: Gregory Mirsky <[email-masked]
>             <mailto:[email-masked]>>, Mallik Mudigonda
>             <[email-masked] <mailto:[email-masked]>>, Sudarsan
>             Paragiri <[email-masked]
>             <mailto:[email-masked]>>, Vengada Prasad Govindan
>             <[email-masked] <mailto:[email-masked]>>, Santosh
>             Pallagatti <[email-masked]
>             <mailto:[email-masked]>>
> 
> 
> 
>             until the htmlized version and diff are available at
>             tools.ietf.org <http://tools.ietf.org>.
> 
>             The IETF Secretariat
>

---

From: Dinesh Dutt <[email-masked]>
Date: Mon, 04 Nov 2019 09:07:45 +0500

While I agree that there are no tenant MACs on a management VNI, I'm 
loathe to introduce another forwarding behavior, one that's 
VNI-specific. MUST use a MAC thats owned by the VTEP is all that's 
required. All VTEPs, existing and past work with this, because that's 
the VTEP decapsulate and forward behavior.

Dinesh

On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern <[email-masked]> 
wrote:
>> 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
>> 
>>         The draft has nits, specifically around the way the IPv6 
>> address
>>         is written.
>> 
>>         In section 4:
>> 
>>             I hope we've addressed all your comments, and the draft 
>> can
>>             proceed further.
>> 
>>             Regards,
>>             Greg
>> 
>>             Status: 
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>>             Htmlized: 
>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>>             Htmlized:
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 3 Nov 2019 23:15:37 -0500

Are you referring to the Ethernet MAC addresses that the VTEP probably 
has on its underlay physical network?  I can see why those would be good 
candidates to use on the management VNI.  What I do not see is why we 
want to require it?  Using those would seem to complicate configuring 
BFD, since as far as I know those addresses are not known to remote VTEPs.

Yours,
Joel

On 11/3/2019 11:07 PM, Dinesh Dutt wrote:
> On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern <[email-masked]> 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:

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 3 Nov 2019 21:10:37 -0800

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

---

From: Dinesh Dutt <[email-masked]>
Date: Mon, 04 Nov 2019 11:05:22 +0500

Hi Joel,

I'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a 
(or whatever else) for the maagement VNI. That fixes the additional 
burden of configuring BFD for the management VNI. Requiring another 
forwarding behavior for a VNI is additional overhead and *may* not be 
supported by existing implementations.

Dinesh

On Mon, Nov 4, 2019 at 9:45 AM, Joel M. Halpern <[email-masked]> 
wrote:
> Are you referring to the Ethernet MAC addresses that the VTEP 
> probably has on its underlay physical network?  I can see why those 
> would be good candidates to use on the management VNI.  What I do not 
> see is why we want to require it?  Using those would seem to 
> complicate configuring BFD, since as far as I know those addresses 
> are not known to remote VTEPs.
> 
> Yours,
> Joel
> 
>> required. All VTEPs, existing and past work with this, because 
>> that's the VTEP decapsulate and forward behavior.
>> 
>> Dinesh
>> 
>>> 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:

---

From: Santosh P K <[email-masked]>
Date: Mon, 4 Nov 2019 18:41:52 +0530

Dinesh,
     Thanks for your comments. Having fixed or multicast MAC addresses is
something was considered earlier in the draft based on the comments we
removed it in updated draft. If management VNI is used then MAC address
should not matter at right? as the packet has to take the exception path
and reach the CPU.

Thanks
Santosh P K

On Mon, Nov 4, 2019 at 11:35 AM Dinesh Dutt <[email-masked]> wrote:

> Hi Joel,
>
> I'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a (or
> whatever else) for the maagement VNI. That fixes the additional burden of
> configuring BFD for the management VNI. Requiring another forwarding
> behavior for a VNI is additional overhead and *may* not be supported by
> existing implementations.
>
> Dinesh
>
> Are you referring to the Ethernet MAC addresses that the VTEP probably has
> on its underlay physical network? I can see why those would be good
> candidates to use on the management VNI. What I do not see is why we want
> to require it? Using those would seem to complicate configuring BFD, since
> as far as I know those addresses are not known to remote VTEPs. Yours, Joel
> loathe to introduce another forwarding behavior, one that's VNI-specific.
> MUST use a MAC thats owned by the VTEP is all that's required. All VTEPs,
> existing and past work with this, because that's the VTEP decapsulate and
> forward behavior. Dinesh On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern <
> [email-masked]> wrote:
>

---

From: Santosh P K <[email-masked]>
Date: Mon, 4 Nov 2019 18:44:27 +0530

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-masked]>
wrote:

>> >     On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <
>> [email-masked]..edu <[email-masked]>
>> >             Subject: New Version Notification for
>> >             draft-ietf-bfd-vxlan-08..txt
>> >             tools.ietf.org <http://tools..ietf.org> <
>> http://tools.ietf.org>.
>> >
>> >             The IETF Secretariat
>> >
>>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 4 Nov 2019 07:00:27 -0800

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

---

From: Santosh P K <[email-masked]>
Date: Mon, 4 Nov 2019 21:29:38 +0530

Thanks Anoop this helps. I guess in that case we may not restrict it to
VTEP MAC only and leave it to implementation but we might need to add text
for interop in cases if someone uses fixed mac like this for valid
non-managment VNI then how it should be handled?

We can wait for others also to comment on this before we can make these
changes to draft.

Thanks
Santosh P K

On Mon, Nov 4, 2019 at 8:30 PM Anoop Ghanwani <[email-masked]> wrote:

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

---

From: Dinesh Dutt <[email-masked]>
Date: Mon, 04 Nov 2019 22:36:17 +0500

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-masked]> 
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:
>    bfd_config_remote : bfd_dst_mac: optional string
> xx:xx:xx:xx:xx:xx to set
>               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-masked]> 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-masked]> wrote:
>>> Hi Joel,
>>> 
>>>> would
>>>> that a
>>>> >     On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani 
>>>> <[email-masked]..edu
>>>> >             I hope we've addressed all your comments, and the 
>>>> draft can
>>>> >             proceed further.
>>>> >
>>>> >             Regards,
>>>> >             Greg
>>>> >
>>>> >                 This document describes the use of the 
>>>> Bidirectional
>>>> >             Forwarding
>>>> >                 Detection (BFD) protocol in point-to-point 
>>>> Virtual
>>>> >             eXtensible Local
>>>> >             Please note that it may take a couple of minutes 
>>>> from the
>>>> >             time of submission

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 4 Nov 2019 11:43:06 -0800

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-masked]> 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
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 5 Nov 2019 09:54:03 -0800

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

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 06 Nov 2019 05:29:05 +0500

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-masked]> 
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
> 
>> 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.
>> 
>> 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 
>>>>    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
>>>> 
>>>>>> >         The draft has nits, specifically around the way the 
>>>>>> IPv6 address
>>>>>> >         is written.
>>>>>> >
>>>>>> >         In section 4:
>>>>>> >

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 5 Nov 2019 17:38:14 -0800

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-masked]> wrote:

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

---

From: Dinesh Dutt <[email-masked]>
Date: Wed, 6 Nov 2019 07:29:18 +0530

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-masked]>, 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-masked]> 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
> > > >
> > > > > > 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-masked]> 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:
> > > > > > >              Set  to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set
> > > > > > > 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-masked]> 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-masked]> wrote:
> > > > > > > > > > > Hi Joel,
> > > > > > > > > > >
> > > > > > > > > > > > > >     On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <[email-masked]..edu
> > > > > > > > > > > > > >          >>>
> > > > > > > > > > > > > >          >>>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 5 Nov 2019 21:51:58 -0800

Hi Dinesh,

OK, assuming you are aware of some such silicon.  I know that all the
implementations I have dealt with support VNI 0 for BFD.

But my concern is with how the statement is worded.  As written, it
basically conveys nothing because while it MAY be 1, it MAY be any other
number too.  I suspect what we want to say is that "any VNI that is not
provisioned for tenant systems may be used for the management VNI and a
default value of 1 is RECOMMENDED."

Anoop

On Tue, Nov 5, 2019 at 5:59 PM Dinesh Dutt <[email-masked]> wrote:

>>> the management VNI since there can be no tenant VMs on a management VNI. I
>>> was recommending specifying a unicast MAC.
>>>
>>>>>> >             Please note that it may take a couple of minutes from
>>>>>> the
>>>>>> >             time of submission