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