Hi Jurgen, thank you for the review, questions, and suggestions to improve the document. I've applied the changes to the working version of the draft. The attached diff highlights the updates (including those suggested by Adam). Please find my notes in-line tagged GIM>>,
Best regards, Greg On Tue, Dec 17, 2019 at 12:05 AM Jürgen Schönwälder via Datatracker < nore...@ietf.org> wrote: > Reviewer: Jürgen Schönwälder > Review result: Has Nits > > I have only a limited understanding of VXLAN and BFD technology. > Hence, some of my question may look odd to the insiders. > > - Never heard of this IPv6 loopback address space before. Is it OK to > allocate and use it this way? > GIM>> As Adam had explained, the correct wording for these addresses (and that is what used in the working version) is "IPv4-mapped IPv4 loopback addresses". Using an address from this range as the destination IP address of an OAM packet encapsulated in a tunnel was, to the best of my knowledge, first defined in RFC 4379 (now RFC 8029). Then RFC 5884 applied it to BFD over MPLS LSP. > > - Why is echo BFD outside the scope of this document? Can I just turn > on echo mode or will extra specifications be needed? > GIM>> I believe that the support of the Echo mode of BFD has not been requested by the BFD WG. I think that some amount of work to define the use of Echo BFD over VXLAN may be needed. > > - Nits: > > OLD > > Ability to monitor path continuity > > NEW > > The ability to monitor path continuity > > OLD > > BFD packet MUST be encapsulated > > NEW > > BFD packets MUST be encapsulated > >
<<< text/html; charset="UTF-8"; name="Diff_ draft-ietf-bfd-vxlan-09.txt - draft-ietf-bfd-vxlan-10.txt.html": Unrecognized >>>
