Hi Rob, thank you for your comments and apologies for the delay. I've uploaded the new version with the updates to address your comments:
The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-16 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-16 Please let me know if you have any questions. Best regards, Greg On Fri, Oct 2, 2020 at 11:42 AM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Rob, > thank you for your review and helpful comments. Please find my notes > in-line below tagged GIM>>. > I've attached the diff highlighting the changes applied and the new > working version of the draft. > > Kind regards, > Greg > > On Fri, Oct 2, 2020 at 5:59 AM Robert Wilton via Datatracker < > nore...@ietf.org> wrote: > >> Robert Wilton has entered the following ballot position for >> draft-ietf-bfd-vxlan-15: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Hi, >> >> This document seems pretty straight forward to me. A few, non blocking, >> comments: >> >> Assigning a single unicast MAC address seems slightly odd in that it isn't >> globally unique, but I can't think of any good alternative. >> >> At the same time, a service layer BFD session may be used between the >> tenants of VTEPs IP1 and IP2 to provide end-to-end fault management >> (this use case is outside the scope of this document). In such a >> case, for VTEPs BFD Control packets of that session are >> indistinguishable from data packets. >> >> "for VTEPs BFD Control" => "for VTEPS, the BFD Control" >> > GIM>> Thank you. Accepted. > >> >> Ethernet Header: >> >> Destination MAC: A Management VNI, which does not have any >> tenants, will have no dedicated MAC address for decapsulated >> traffic. The value (TBD1) SHOULD be used in this field. >> >> Source MAC: MAC address associated with the originating VTEP. >> >> Should the TypeOrLen field in the Ethernet header also be specified >> (presumably >> set to IPv4 or IPv6)? >> > GIM>> Thank you for the suggestion. I've added the following: > NEW TEXT: > Ethertype: is set to 0x0800 if the inner IP header is IPv4, and > is set to 0x86DD if the inner IP header is IPv6. > >> >> Regards, >> Rob >> >> >> >>
