On 15/10/2021 20:18, Jeffrey Haas 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.
Jeff
My comments from 28oct21 and thereabouts, some of which were first made
in August 2020, have not been addressed (or are being ignored:-(
The IANA Considerations registers a different prefix to that in the YANG
module; this is a showstopper.
The Security Considerations for YANG modules are out-of-date. See the
pointer in YANG Guidelines, RFC8407. Fixing this will cause updates to
the I-D References.
The reference to bfd-yang is out of date - it is an RFC now.
YANG import MUST be Normative Reference (eg RFC8349)
Tom Petch
-----
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
.
