Hi Dhruv,
Please see inline.
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
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
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?
[XM]>>> Yes. Exactly there is no affiliated BFD Echo session, because in RFC 5880 the Echo function is an adjunct to Asynchronous mode or Demand mode. For the relationship between the local discriminator and the "My Discriminator" field in the BFD Control packet, please refer to Section 6.3 of RFC 5880, it says
"
Each system MUST choose an opaque discriminator value that identifies each session, and which MUST be unique among all BFD sessions on the system. The local discriminator is sent in the My Discriminator field in the BFD Control packet, and is echoed back in the Your Discriminator field of packets sent from the remote end.
"
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.
[XM]>>> I'm discussing with Stephen Farrell on an update to the text you quoted. The proposed update is as below.
OLD
As specified in Section 5 of [RFC5880], since BFD Echo packets may be spoofed, some form of authentication SHOULD be included.
NEW
As specified in Section 5 of [RFC5880], BFD Echo packets may be spoofed. Specifically for Unaffiliated BFD Echo, a DoS attacker may send spoofed Unaffiliated BFD Echo packets to the loop-back device, so some form of authentication SHOULD be included.
Does that update also address your comment?
- 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"."
[XM]>>> OK. Propose to add some explanation text as below.
OLD
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.
NEW
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. This would appear to contravene Section 5 of [RFC5880]. However, the core behavior in that RFC simply states that the contents of the Echo packets are a local matter, and this document is simply defining "the local matter".
END
- 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.
support the full BFD protocol. Examples of such devices include
servers running virtual machines, or Internet of Things (IoT)
devices. By using the Unaffiliated BFD Echo, what such devices need to support is only a simple loop-back function."
Is that ok for you?
- 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.
[XM]>>> I agree that's not a big deal, so will change SHOULD to MUST. :-)
Cheers,
Xiao Min
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
