Hi, On Wed, Oct 9, 2024 at 12:58 PM <[email protected]> wrote:
> Hi Dhruv, > > > Thanks for your review and comments. > > Please see inline. > Original > *From: *DhruvDhodyviaDatatracker <[email protected]> > *To: *[email protected] <[email protected]>; > *Cc: *[email protected] < > [email protected]>;[email protected] < > [email protected]>;[email protected] <[email protected]>; > *Date: *2024年10月09日 01:33 > *Subject: **[Last-Call] Opsdir last call review of > draft-ietf-bfd-unaffiliated-echo-11* > Reviewer: 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? > > time it's not necessary for the local system to differentiate the > > Unaffiliated BFD Echo session from other BFD session. > Dhruv: But you have text that says Unaffiliated BFD Echo does not use AdminDown and thus there has to be some differentiation? > 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? > > > Dhruv: I was reading that incorrectly, apologies. There is only 1 instance in security consideration that needs fixing - 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]." > > > Dhruv: Yes please! <snip> > - 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 > <https://datatracker.ietf.org/doc/rfc5880/>, 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". > > " > Dhruv: In that case can you update the text in section 1 - "This document, on the other hand, specifies the contents of the Unaffiliated BFD Echo packet and what to do with them." with the explanation above. > > - 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. > > > Dhruv: Yes, just a sentence or two on usecase would be fine. > > - 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? > > > Dhruv: Sorry! I meant to state that the reference to RFC 5082 is unclear here. Perhaps rephrase or remove. > > - 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. > > > Dhruv: But how would an implementer know that it is not an issue for their code or the operator-deployment that will eventually use it? Is there an implementation that would suffer if the RFC says MUST for this? > ## 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. > > > Dhruv: Good! Thanks! Dhruv Best Regards, > > Xiao Min > > > Thanks! > Dhruv > > > -- > last-call mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > -- > last-call mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
