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

[Anoop Ghanwani <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[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
>>>>
>>>