Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt

[Anoop Ghanwani <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
>> 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 <[e-mail]>
>>> 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 <[e-mail]
>>>> > <mailto:[e-mail]>> 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 <
>>>> [e-mail]..edu <[e-mail]>
>>>> >     <mailto:[e-mail]>> 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
>>>> >         <[e-mail] <mailto:[e-mail]>> 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: <[e-mail]
>>>> >             <mailto:[e-mail]>>
>>>> >             Date: Fri, Nov 1, 2019 at 10:45 AM
>>>> >             Subject: New Version Notification for
>>>> >             draft-ietf-bfd-vxlan-08..txt
>>>> >             To: Gregory Mirsky <[e-mail]
>>>> >             <mailto:[e-mail]>>, Mallik Mudigonda
>>>> >             <[e-mail] <mailto:[e-mail]>>,
>>>> Sudarsan
>>>> >             Paragiri <[e-mail]
>>>> >             <mailto:[e-mail]>>, Vengada Prasad Govindan
>>>> >             <[e-mail] <mailto:[e-mail]>>, Santosh
>>>> >             Pallagatti <[e-mail]
>>>> >             <mailto:[e-mail]>>
>>>> >
>>>> >
>>>> >
>>>> >             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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>