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
