Re: Barry Leiba's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Barry,
thank you for your review, comments, and suggestions. Please find my
answers in-line below under GIM>> tag.
Attached, please find the diff attached (apologies that it includes also
updates to several other reviews).

Best regards,
Greg

On Mon, Dec 16, 2019 at 9:39 PM Barry Leiba via Datatracker <
[e-mail]> wrote:

> Barry Leiba has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: 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:
> ----------------------------------------------------------------------
>
> I support Ben’s DISCUSS.  In addition, I have a number of editorial
> comments.
>
> General: there are a lot of missing or incorrect articles, making the
> document
> harder to read than it should be.  It would be good to fix that.  If you
> let
> the RFC Editor fix it, it will require careful review during AUTH48 to make
> sure it’s correct.
>
> — Abstract —
> The phrase “forming up” is odd; I suggest just “forming”.
>
GIM>> It was suggested to s/forming up/used to form/. Do you think it reads
better?

>
> — Section 3 —
>
>    BFD packets intended for a VTEP MUST
>    NOT be forwarded to a VM as a VM may drop BFD packets leading to a
>    false negative.
>
> This needs two commas: one before “as” and one before “leading”.  And what
> does
> “leading to a false negative” mean here?  I don’t understand.
>
GIM>> Thank you for your suggestion to improve the text. If BFD Control
packets are not processed at the egress BFD system, even though the VXLAN
tunnel is operational, the state of the session will be changed to Down
once the Detection timer expires. We consider that such failure
notification is "false" as it does not indicate a failure of the monitored
VXLAN tunnel but something else, perhaps misconfiguration or an
implementation problem.

>
>    It is RECOMMENDED to allow
>    addresses from the loopback range through a firewall only if it is
>    used as the destination IP address in the inner IP header, and the
>    destination UDP port is set to 3784 [RFC5881].
>
> I THINK the antecedent for “it” is meant to be “addresses from the loopback
> range”, though because of the number mismatch it looks like the antecedent
> is
> “a firewall”.  One fix is to change “addresses” to “an address”,
> correcting the
> number error, but that leaves the ambiguity.  Maybe betterto make it “only
> if
> they are used as destination IP addresses”.  Also, remove the comma.


> That fixes the sentence as written, but I also agree with Ben’s comment
> that
> this might need more significant rewording.
>
GIM>> Thank you for your thorough consideration of the text and your
thoughtful suggestion. I've followed the second of your suggested changes.
Will work on improving the text with Ben.

>
> — Section 4 —
>
>    BFD packet MUST be encapsulated and sent to a remote VTEP as
>    explained in this section.
>
> This needs to be either “A BFD packet” or “BFD packets” and “VTEPs”.
>
GIM>>  I've followed the second option as the next sentence uses the plural
form.

>
>          The MAC address MAY be
>          configured, or it MAY be learned via a control plane protocol.
>
> Are those the only two choices?  As both “MAY” are optional, as written it
> allows for others.  I suggest not using BCP 14 key words here, and instead
> saying, “The MAC address is either configured or learned via a control
> plane
> protocol.”
>
GIM>> I agree.

>
>          This
>          addresses the scenario when the inner IP destination address is
>          of VXLAN gateway and there is a router in underlay which
>          removes the VXLAN header, then it is possible to route the
>          packet as VXLAN  gateway address is routable address.
>
> This sentence is too fractured for me to make any sense of it, so I can’t
> suggest a fix.  Please fix it.  It looks like Ben made more sense of it
> than I
> could, so maybe his suggestion will work.
>
GIM>> I agree. I'll update the passage while discussing Ben's comments.

>
> — Section 5 —
>
>    received VXLAN packet MUST follow the procedures described in
>    Section 4.1 [RFC7348].
>
> This needs to say “Section 4.1 of [RFC7348].”
>
GIM>> Accepted, done.