Dhruv: I am not able to parse this sentence. Do you mean that the ""My Discriminator" used by the local systems for unaffiliated BFD echo session should be different from affiliated ones?Hi Dhruv,
Thanks for your review and comments.
Please see inline.
OriginalFrom: DhruvDhodyviaDatatracker <noreply@xxxxxxxx>To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>;Cc: draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx <draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;rtg-bfd@xxxxxxxx <rtg-bfd@xxxxxxxx>;Date: 2024年10月09日 01:33Subject: [Last-Call] Opsdir last call review of draft-ietf-bfd-unaffiliated-echo-11Reviewer: Dhruv Dhody
Review result: Has Issues
# OPSDIR review of draft-ietf-bfd-unaffiliated-echo-11
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in the last call may be
included in AD reviews during the IESG review. Document editors and WG chairs
should treat these comments just like any other last-call comments.
The document describes the use of BFD Echo when the peer does not support BFD
but only loops packets back.
The document does not include an explicit manageability & operational
considerations section. Authors could consider adding it. RFC 5880 has it and
it would make sense to call out considerations that are specific to
Unaffiliated BFD Echo (if any). For instance - Does BFD enabled system A know
that the BFD Echo session is unaffiliated? Is there a configuration? How does
it work with affiliated BFD Echo sessions?
[XM]>>> OK. Propose to add a new section 4 as below.
NEW
4. Operational Considerations
All Operational Considerations from [RFC5880] apply, except that
the Unaffiliated BFD Echo can only be used across one hop, which
result in unneccessity of a congestion control mechanism.
Some devices that would benefit from the use of BFD may be unable to
support the full BFD protocol. Examples of such devices include
servers running virtual machines, or Internet of Things (IoT)
devices.
As specified in Section 2 of this document, some configurations are
needed to make the Unaffiliated BFD Echo work, although the
configurations won't be beyond the scope of [RFC5880].
At a BFD-enabled local system, the Unaffiliated BFD Echo session
can coexist with other BFD session, in which scenario the remote
systems and the local discriminators must be different, at the same
time it's not necessary for the local system to differentiate the
Unaffiliated BFD Echo session from other BFD session.
END
## Minor
- There are many instances where you use normative BCP14 keywords when
restating text from existing RFCs. It would be best if you either used
lowercase when paraphrasing or converted those to Verbatim with the use of "".
[XM]>>> The measures you suggested make sense to me. However, after checking the whole document, I couldn't find those instances (except for the section 3 "Updates to RFC 5880"), could you please point them out to me?
As specified in Section 5 of [RFC5880], since BFD Echo packets may be spoofed, some form of authentication SHOULD be included.
- Section 1; "It also supports an Echo function to reduce the device
requirement for BFD." - This needs more explanation or a reference if it is
already described in the existing RFC. I am guessing you mean control plane
processing but I am unsure.
[XM]>>> In Section 3.2 of RFC 5880, it says
"
Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode)."
So propose to add a reference: "as described in Section 3.2 of [RFC5880]."
- Section 1; "Section 5 of [RFC5880] indicates that the payload of an
affiliated BFD Echo packet is a local matter and hence its contents are outside
the scope of that specification. This document, on the other hand, specifies
the contents of the Unaffiliated BFD Echo packet and what to do with them." -
Why is there no OLD/NEW text for Section 5 of [RFC5880] in Section 3? Also,
does the last paragraph of section 9 of RFC 5880 that should be updated?
[XM]>>> I suggest NOT to update the corresponding text in Section 5 and 9 of RFC 5880. In the shepherd write-up of this document it says
"
2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter"."
- It would make sense to have the use case described in this document itself
with suitable references. Reading section 6.2.2 of [BBF-TR-146] does not help
in having a clear description of why an Unaffiliated BFD Echo is needed.
[XM]>>> The original section 4 "Unaffiliated BFD Echo Applicability" was removed in version -11 as per suggestion from Eric Vyncke. In order to address your comments, I suggest to add some text from the original section 4 to the new added section 4 "Operational Considerations" as above.
- All Unaffiliated BFD Echo packets for the session MUST be sent with a Time to
Live (TTL) or Hop Limit value of 255, and received with a TTL or Hop Limit
value of 254, otherwise the received packets MUST be dropped [RFC5082].
[XM]>>> This is a copy/paste, so what's the comments on the quoted text?
- For handling "unset values" in section 2 and section 4, why SHOULD and not a?
MUST?
[XM]>>> Because for some implementer and operator "a potential vector for disclosure of uninitialized memory" may not be an issue.
## Nits
- Expand BFD in title
[XM]>>> OK, will do it.
- s/make use of Unicast Reverse Path Forwarding (URPF) [RFC3704] in strict
mode/make use of Unicast Strict Reverse Path Forwarding (RPF) [RFC3704]/ -> to
match with RFC3704. Perhaps you can also explicitly state why for the reader.
[XM]>>> OK. Propose to add some text as below.
OLD
Unaffiliated BFD Echo requires the remote device to loop Unaffiliated BFD Echo packets. In order to provide this service, the remote device cannot make use of Unicast Reverse Path Forwarding (URPF) [RFC3704] in strict mode.NEW
Unaffiliated BFD Echo requires the remote device to loop Unaffiliated BFD Echo packets. In order to provide this service, the remote device cannot make use of Unicast Strict Reverse Path Forwarding (RPF) [RFC3704], otherwise the Unaffiliated BFD Echo packets might not pass the RPF check at the remote device.
--Best Regards,
Xiao Min
Thanks!
Dhruv
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
