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

["Joel M. Halpern" <[e-mail]>]

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]
>     <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>.
> 
>             The IETF Secretariat
>