Subject: Re: Progressing BFD unsolicited (failure thereof:-)

From: t petch <[email-masked]>
Date: Fri, 26 Nov 2021 12:26:47 +0000

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
>
> .
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Nov 2021 15:20:07 +0100

Tom,

I have personally addressed most if not all of your comments.

Do you see in version -07 used "aligned" or "explicitely" ?

If something was not addressed it was based on the discussion with
co-authors.

Many thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 26 Nov 2021 11:08:08 -0500

[Largely for the WG mail list archive.]

> On Nov 26, 2021, at 7:26 AM, t petch <[email-masked]> wrote:
> 
> My comments from 28oct21 and thereabouts, some of which were first made in August 2020,  have not been addressed (or are being ignored:-(

I still have your comments queued up as "must be addressed before we ship the document".  And, if you'll check your inbox, you should find some edits form Reshad that will address most of those.  Please review and Reshad can post them for broader WG review.

It's not unusual for IETF to have extra latency this time of year.  I've even given a presentation on the the timing impacts of the last few months during IETF WG chairs training on project management. :-)

While this is moving about as fast as an attempt to reach the far end of a hallway during an IETF cookie break, please have some patience.  We want to make sure your comments are addressed.

-- Jeff

---

From: Reshad Rahman <[email-masked]>
Date: Fri, 26 Nov 2021 16:43:09 +0000 (UTC)

I'll address the comment below on missing normative reference to 8349 and will upload 08. I believe the other comments have been addressed in the copy in github.
Regards,Reshad.
    On Friday, November 26, 2021, 11:08:11 AM EST, Jeffrey Haas <[email-masked]> wrote:  

Jeff

---

From: t petch <[email-masked]>
Date: Fri, 26 Nov 2021 17:11:55 +0000

> If something was not addressed it was based on the discussion with

Robert

I cannot recall commenting on 'explicitely'.

My comments about import needing a reference, about Security 
Considerations being out-of-date and the mismatch of prefix between YANG 
module and IANA Considerations are all based on YANG Guidelines where I 
would expect that BCP to trump the discussions of co-authors, whereas my 
comment on a seeming mismatch of references to authors is, of course, up 
to the authors:-)

I would expect the obsolete reference to bfd-yang to have been picked up 
by IDNits which suggests to me that that had not been run on -07 which I 
always take as a red light!

Tom Petch

---

From: t petch <[email-masked]>
Date: Fri, 26 Nov 2021 17:18:30 +0000

> While this is moving about as fast as an attempt to reach the far end of a hallway during an IETF cookie break, please have some patience.  We want to make sure your comments are addressed.

Jeff,

As I said, I just go on making the comments!  I have not seen a -08 but 
as I said, I do like seeing the announcement on I-D Announce - that is 
what triggers me to act (eventually).  At the other end of the spectrum 
is Github - I used to get 'cannot display the webpage' whereas now I get 
(courtesy of updated security software) 'this website is dangerous - do 
not go there' which suits my way of working (albeit I do not see that as 
a factor here!).

Tom Petch

---

From: Reshad Rahman <[email-masked]>
Date: Fri, 26 Nov 2021 17:23:51 +0000 (UTC)

I just posted 08, it passed id-nits :-) Seriously, regarding the old reference to bfd-yang it could be because 07 was posted before RFC9127?
Tom, this should address most (hopefully all) of the outstanding comments you've provided from Aug 2020, Oct 2021 and Nov 2021. The Aug 2020 ones went through the cracks, but I did make sure to add it in github when we were reminded.
Regards,Reshad.
    On Friday, November 26, 2021, 12:12:01 PM EST, t petch <[email-masked]> wrote:  

Robert

Tom Petch

---

From: t petch <[email-masked]>
Date: Sat, 27 Nov 2021 12:33:29 +0000

> Tom, this should address most (hopefully all) of the outstanding comments you've provided from Aug 2020, Oct 2021 and Nov 2021. The Aug 2020 ones went through the cracks, but I did make sure to add…

Reshad,

Yes, this addresses my comments.

I note the use of 'we' in a couple of places and there is currently an 
AD who often comments on such.

I note that under the first augment in the tree diagram there is
           +--rw enabled?                          boolean
while under the second there is
          +--rw enabled                           boolean
The '?' means optional and I do not understand why one is and the other 
is not.  I did wonder if the Tree diagram reflects an earlier version of 
the YANG module or has been crafted by hand.  I note that -07 had 
'enable?' without the 'd' in all places.

I would be happy to see you pressing ahead with -08.

Tom Petch

---

From: Reshad Rahman <[email-masked]>
Date: Sun, 28 Nov 2021 23:32:34 +0000 (UTC)

Thank you Tom. I did modify the YANG tree by hand because something was wrong in my environment. Tracking this with https://github.com/bfd-wg/bfd-unsolicited/issues/2
Regards,Reshad.

    On Saturday, November 27, 2021, 07:33:55 AM EST, t petch <[email-masked]> wrote:  

Reshad,

Tom Petch