Hi Robert and the Authors, thank you for your kind consideration of my comments and for addressing them so thoughtfully. I have two editorial suggestions that can be used, if you decide so, at a later date:
- as the text refers to the format of a BFD control message, then it seems appropriate to s/"Discriminator"/"My Discriminator" - Minor re-wording: OLD TEXT: When on the passive side Unsolicited BFD sessions goes down an implementation MAY keep such session state for a configurable amount of time. Temporarily keeping such local state may permit retrieving additional operational information of such session which went down. NEW TEXT: When a session goes down on the passive side of an Unsolicited BFD, an implementation MAY keep such a state for a configurable amount of time. Temporarily keeping such a local state may permit retrieving additional operational information of such session which went down. Regards, Greg On Mon, Oct 18, 2021 at 12:39 PM Robert Raszuk <rob...@raszuk.net> wrote: > Hi Jeff & Greg, > > I have just submitted -04 version. I believe together with co-authors we > have addressed all the comments received so far. > > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ > > Hope that we can move forward with this work. > > Kind regards, > Robert > > > > On Fri, Oct 15, 2021 at 9:18 PM Jeffrey Haas <jh...@pfrc.org> wrote: > >> Working Group, >> >> Now that the BFD YANG work is getting ready to pop out of the RFC Editor's >> queue, it's an appropriate time to finish the last minor details for the >> BFD Unsolicited draft. >> >> Previously, the draft had exited Working Group Last Call with minor things >> to be resolved, and a process question about where this draft should be >> with >> regards to the standard process. Our conversation with our Area Director >> at >> that time and other associated IESG members suggested that Proposed >> Standard >> status was appropriate. >> >> Greg Mirsky had made a number of comments, several which have been at >> least >> partially addressed in the current version of the draft. Note that the >> top >> of the thread corresponds to the Working Group feedback during WGLC. >> >> https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc/ >> >> I encourage the Working Group to review the draft and the comments to >> date. >> After resolving them, I believe we're ready to have a shepherd writeup and >> send this to the IESG. >> >> ----- >> >> Addressing points Greg has raised: >> - "Does this document update RFC 5881?" >> >> In my opinion, we're introducing no procedural changes vs. RFC >> 5880/5881. >> The passive mode documented in RFC 5880 is being leveraged. We're >> simply >> not explicitly provisioning the session. Others in the WGLC thread >> support not marking this as an update. >> >> - "node-wise configuration" >> >> I believe that has been addressed in the current version of the draft. >> >> - Greg writes: "The fourth paragraph in Section 2 explains the handling of >> the first BFD control packet with Your Discriminator == 0, i.e., "it >> does >> not find an existing session with the same source address". What happens >> if the matching BFD session has been found?" >> >> This case could use a small amount of normative text. For reference, >> here >> is the text from RFC 5880, §6.8.6: >> >> : If the Your Discriminator field is zero, the session MUST be >> : selected based on some combination of other fields, possibly >> : including source addressing information, the My Discriminator >> : field, and the interface over which the packet was received. The >> : exact method of selection is application specific and is thus >> : outside the scope of this specification. If a matching session is >> : not found, a new session MAY be created, or the packet MAY be >> : discarded. This choice is outside the scope of this >> : specification. >> >> One easy possibility is that there is an existing session, or one that >> may >> be failing shortly. Discarding the received packets in this >> circumstance >> until there is no existing session might be an appropriate response. >> >> - Greg write: "Does that mean that there will be only one session >> with the same source address despite different destination addresses >> listed?" >> >> One point of comparison is that the single-hop BFD YANG module is >> indexed >> on interface and destination address and not source address. >> >> - Greg writes: "the local BFD system assigns My Discriminator to the >> session. Though it is standard (RFC 5880) step, it might be useful to >> mention it." >> >> Since I don't think it brings clarity and distracts from "see the base >> RFC", I would suggest not mentioning it. >> >> - Greg asks about what happens to session state for a session that was >> passive and went down. >> >> Much like Greg, I believe this is an implementation detail but it's one >> that has impact to things like YANG modules. Since single-hop sessions >> are indexed based on interface and destination address, permitting them >> to >> linger for some period of time might be useful with low danger of being >> a >> denial of service vs. the operational state. This would permit a YANG >> notification sent for a session that went down to be able to query >> information from the operational state portion of the module. >> >> If the authors agree, it might be worth a sentence or two mentioning >> that >> session state may linger for an implementation-defined period of time >> for >> management purposes. >> >> - Session changing from passive to active. >> >> This isn't a normative MAY. >> >> - TTL=255 only RECOMMENDED? >> >> RFC 5881 provides for circumstances where the send-side will always use >> TTL 255 but validation on reception is optional. >> >> I would support Greg's point by suggesting that the text in the current >> draft simply be updated to say "follow RFC 5881's GTSM procedures". >> >> ----- >> >> Other notes: >> - The BFD YANG module references will be able to be filled out shortly as >> RFC 9127. >> >> - Update dates appropriately throuhgout the YANG module. Copyright, >> revision, etc. >> >> - The YANG module defines a role. I suggest that the draft should define >> a >> State Variable covering this. See RFC 5880, §6.8.1. >> >> ----- >> >> Minor comments on the draft from my most current review. (Line numbers >> from >> IETF nits tool.) >> >> 140 On the passive side, the "unsolicited BFD" SHOULD be >> explicitely >> >> s/explicitely/explicitly/ >> >> 391 interfaces the above check should be alinged with routing >> protocol >> >> s/alinged/aligned/ >> >> >> -- Jeff >> >
