Hi Mahesh,
Thanks for the thorough, and again apologies for the delay.
Please see inline.
On Monday, January 3, 2022, 04:41:47 PM EST, Mahesh Jethanandani
<[email protected]> wrote:
Hi Authors,
I read through the draft. Thanks for putting together a short and readable
document. I had the following comments/questions on the Unsolicited BFD for
Sessionless Applications draft. Some of the comments are nits, while others are
a little more substantive.
Abstract:
I believe that by proposing this solution, you are updating RFC 5880. But the
Abstract or draft makes no mention of it.<RR> As you may recall, initially this
document was informational and that got changed when the YANG model got added.
So in the authors view, at least when we last discussed this, this is an
implementation addition and not a change to the BFD protocol as specified in
RFC5880. But if the WG consensus is that we should treat this document as an
update to RFC5880, that's acceptable to me.
Introduction:
The Abstract mentions that a YANG model is also proposed, but the Introduction
section does not. I believe a clear mention that the YANG model proposed is a
YANG 1.1 model (RFC 7950) would be helpful. The fact that the model in NMDA
compliant can then be mentioned in this section, rather than in Abstract, which
is as its name suggests - an Abstract. The details should be mentioned in the
Introduction.<RR> Will add in next rev.
Procedures for Unsolicited BFD & State Variable:
The procedure seems simple enough, although a few more updates would be
helpful. For example, can a given router be configured both globally and per
interface? If not, it should be added in the procedure, and a must statement to
that effect should be added to the YANG model. If both can be supported, then
there should be an explanation as to which parameters take effect for a given
session, and if per-interface parameters override global parameters.<RR>Both
can be supported, will add text specifying that per-interface overrides global.
s/per-router/globally/g just to keep consistency in the text.<RR>Ack.
The third paragraph says “The passive side does not send Control packets”. I
think you mean to say that the passive side does not send Control packets
initially or on its own, but does in response to the active side sending
them.<RR>Will clarify.
In the fifth paragraph it is not clear what “It” means. Does “it" mean the
active or the passive side? If this paragraph was part of the fourth paragraph
I could deduce that you are talking about passive side, but since this is a new
paragraph, it is not clear. Also, I see the use of word “would” in the
paragraph. Do you mean should, or more precisely SHOULD instead?<RR>It is the
passive side, will update. Wrt would/should/SHOULD, I think it is MUST because
of the MAY at the end of the 4th paragraph.
The sixth paragraph makes mention of a configurable parameter, but there is no
such parameter in the YANG model.<RR>You are referring to the "period of time"?
I'd rather remove the text which says "which may be configurable" than add this
in the YANG. Implementations which support this can augment and add the config
parameter.
The draft mentions an active and passive role towards the end of this section,
and the beginning of the next section. The next section is titled “State
Variable”, but there is talk of “configuring" operational mode. State variables
are not configurable, are ‘config false’, and operational mode is certainly not
“configured”. I think you mean administrative mode. If so, a separate state
variable is not required per NMDA, and the same variable will represent both
admin and operational status. I would drop section 3, and roll the discussion
of the UnsolictedRole into Section 2, and explain how the UnsolictedRole is
both configured and its operational status retrieved using NMDA. <RR>By
operational mode, we are not referring to the operational data in NMDA/YANG
parlance, instead we mean "mode of operation" of BFD (which is configurable).
And the state variable was meant to be an addition to RFC 5880 - Bidirectional
Forwarding Detection (BFD) (so we do update 5880 after all...). I think you are
right and that this section is confusing.
YANG Data Model:
Who is “We”? Also, please update reference of RFC 9127 to
draft-ietf-bfd-rfc9127-bis.<RR> We will get rid of the "we" :-) Ack for
9127-bis.
Unsolicited BFD Hierarchy:
Remove reference to a separate container for operational data. See above
point.<RR>Which container are you referring to? There is an unsolicited
container under interfaces and globally for config. There is an unsolicited
container under single-hop for unsolicited session state.
Unsolicited BFD Module
There is a redundant reference statement right after the Copyright paragraph
and before the revision statement.<RR>I thought this was standard procedure.
That's what 9127 has anyway.
In YANG, the parent name is not repeated. Therefore
s/unsolicted-active/actives/unsolicited-passive/passive<RR>Ack.
YANG Module Security Considerations:
The section highlights the data nodes that are sensitive/vulnerable, but most
of the nodes it describes as sensitive are imported from RFC 9127. It should
defer to the Security Considerations of that RFC, unless it is changing those
variables meaningfully. <RR> It talks about sensitivity of unsolicited specific
nodes. Which 9127 nodes are you referring to?
Regards,Reshad.
Thanks.
Mahesh [email protected]
