Subject: Progressing BFD unsolicited

From: Jeffrey Haas <[email-masked]>
Date: Fri, 15 Oct 2021 15:18:09 -0400

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 Oct 2021 21:39:06 +0200

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 Oct 2021 17:47:33 -0700

Hi Robert and the Authors,
thank you for your kind consideration of my comments and for addressing
them so thoughtfully. I have two editorial suggestions that can be used, if
you decide so, at a later date:

   - as the text refers to the format of a BFD control message, then it
   seems appropriate to s/"Discriminator"/"My Discriminator"
   - Minor re-wording:

OLD TEXT:
When on the passive side Unsolicited BFD sessions goes down an
implementation MAY keep such session state for a configurable amount
of time.  Temporarily keeping such local state may permit retrieving
additional operational information of such session which went down.
NEW TEXT:
When a session goes down on the passive side of an Unsolicited BFD,
an implementation MAY keep such a state for a configurable amount of
time. Temporarily keeping such a local state may permit retrieving
additional operational information of such session which went down.

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Oct 2021 09:07:16 -0400

I have one minor additional tweak suggested to Greg's change.  I think once we converge on this point, I'll do the document shepherd report and submit to the IESG.

> On Oct 18, 2021, at 8:47 PM, Greg Mirsky <[email-masked]> wrote:
> 
> thank you for your kind consideration of my comments and for addressing them so thoughtfully. I have two editorial suggestions that can be used, if you decide so, at a later date:
> as the text refers to the format of a BFD control message, then it seems appropriate to s/"Discriminator"/"My Discriminator"
> Minor re-wording:
> OLD TEXT:

When an Unsolicted BFD session goes down, implementations MAY retain
the session state for a period of time, which may be configurable.  Retaining 
this state can be useful for operational purposes.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Oct 2021 15:19:57 +0200

Jeff,

I have already added that text based on your previous comments. Is what is
added not sufficient ?

Many thx,
R.

PS. I will add Greg's suggestions latter today and repost to -05.

"

On Tue, Oct 19, 2021 at 3:07 PM Jeffrey Haas <[email-masked]> wrote:

> I have one minor additional tweak suggested to Greg's change.  I think
> once we converge on this point, I'll do the document shepherd report and
> submit to the IESG.
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Oct 2021 09:27:11 -0400

Robert,

Greg has suggested a minor change to your most recent text.
I have added a comment to Greg's suggestion. (See below.)

You have addressed all of the other comments previously requested in my post on 15 October.

-- Jeff

> On Oct 19, 2021, at 9:19 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Jeff,
> 
> I have already added that text based on your previous comments. Is what is added not sufficient ? 
> 
> Many thx,
> R.
> 
> On Tue, Oct 19, 2021 at 3:07 PM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> On Oct 18, 2021, at 8:47 PM, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
>>