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 >
