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

From: Reshad Rahman <[email-masked]>
Date: Fri, 3 Dec 2021 18:06:55 +0000 (UTC)

Fixed in 09:https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unsolicited-09

    On Sunday, November 28, 2021, 06:32:58 PM EST, Reshad Rahman <reshad=[email-masked]> wrote:  
 
  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:  
 
 On 26/11/2021 17:23, Reshad Rahman wrote:
>  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.

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

> Regards,Reshad.
>      On Friday, November 26, 2021, 12:12:01 PM EST, t petch <[email-masked]> wrote:
>
>  On 26/11/2021 14:20, Robert Raszuk wrote:
>> 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.
>
> 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
>
>
>> Many thx,
>> R.
>>
>> On Fri, Nov 26, 2021 at 1:27 PM t petch <[email-masked]> wrote:
>>
>>> 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: Jeffrey Haas <[email-masked]>
Date: Fri, 3 Dec 2021 13:12:27 -0500

Are we ready to ship this?  If we think so, I'll audit the threads once more and update the shepherd report.  I can then submit it to the IESG.

-- Jeff

> On Dec 3, 2021, at 1:06 PM, Reshad Rahman <reshad=[email-masked]> wrote:
> 
> Fixed in 09:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unsolicited-09 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unsolicited-09>
> 
> 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 <https://github.com/bfd-wg/bfd-unsolicited/issues/2>
> 
> Regards,
> Reshad.
> 
> 
> >      On Friday, November 26, 2021, 12:12:01 PM EST, t petch <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> On Fri, Nov 26, 2021 at 1:27 PM t petch <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc/ <https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc/>
> >>>>

---

From: Reshad Rahman <[email-masked]>
Date: Fri, 3 Dec 2021 18:15:05 +0000 (UTC)

I believe so, i.e. no open items on my side.
Regards,Reshad.
    On Friday, December 3, 2021, 01:12:44 PM EST, Jeffrey Haas <[email-masked]> wrote:  

 

Reshad,

Tom Petch