Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 2 Feb 2022 11:05:42 +0530

Hi Ketan,

Thanks for your response..

The draft says:
<snip>
   This document defines the B-bit in the LLS Type 1 Extended Options
   and Flags field.  This bit is defined for the LLS block included in
   Hello and Database Description (DD) packets and
*indicates that BFD is   enabled on the link* and that the router requests
strict-mode for BFD.
</smip>

You don't enable multi-hop BFD on a link, instead you enable it b/w two
(multi-hop) routers, right?

How about replacing it with:
indicates that (1) single-hop BFD [RFC5881] is enabled on the link in case
of point-to-point (numbered) and LAN interfaces, and (2) multi-hop BFD
[RFC5883] is enabled between the neighbors in case of virtual links and
point-to-point unnumbered interfaces.

Also, add a note at the beginning of the draft that BFD refers to both
single-hop and multi-hop BFD when not explicitly specified..

Regards,
Muthu

On Sun, Jan 30, 2022 at 10:40 PM Ketan Talaulikar <[email-masked]>
wrote:

> Hi Muthu,
>
> Thanks for your review and your support.
>
> Regarding your question, I would like to clarify that this document
> doesn't specify BFD operations with OSPF. That was done by RFC5882. Indeed
> for virtual links, there would need to be a BFD multi-hop session and the
> same would apply to p-t-p unnumbered.
>
> However, I am not sure what specific applicability or operations need to
> be called out for Strict Mode of operations for those links.
>
> Thanks,
> Ketan
>
>
> On Sun, Jan 30, 2022 at 12:52 PM Muthu Arul Mozhi Perumal <
> [email-masked]> wrote:
>
>> Hi,
>>
>> I support the draft. A quick question:
>> Should it describe the applicability of the mechanism over OSPF virtual
>> links and unnumbered interfaces? With virtual links, one would have to
>> establish a multi-hop BFD session, so it is slightly different from a BFD
>> operational standpoint. For e.g, capability to support single-hop BFD may
>> not translate to the capability to support multi-hop BFD..
>>
>> Regards,
>> Muthu
>>
>> On Thu, Jan 27, 2022 at 10:38 PM Acee Lindem (acee) <acee=
>> [email-masked]> wrote:
>>
>>> LSR WG,
>>>
>>>
>>>
>>> This begins a two week last call for the subject draft. Please indicate
>>> your support or objection on this list prior to 12:00 AM UTC on February 11
>>> th, 20222. Also, review comments are certainly welcome.
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 4 Feb 2022 17:36:25 +0530

Hi Muthu,

When we say a "link" here, it is in the context of the OSPF interface and
neighbor FSM. My understanding is that this term includes virtual links as
well. As such, we can add some text in the introduction section to clarify
the same and also put a reference to RFC5883 for BFD multi-hop use for
VLINKs.

I hope that works for you.

Thanks,
Ketan

On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
[email-masked]> wrote:

> *indicates that BFD is   enabled on the link* and that the router
> requests strict-mode for BFD.
> </smip>
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 4 Feb 2022 22:52:02 +0530

Hi Ketan,

Sure, looking forward to the clarification in the draft on multi-hop BFD..

Just curious, are there interoperable implementations for OSPF multi-hop
BFD strict mode for virtual links or p2p unnumbered interfaces?

Regards,
Muthu

On Fri, Feb 4, 2022 at 5:36 PM Ketan Talaulikar <[email-masked]>
wrote:

>> indicates that (1) single-hop BFD [RFC5881] is enabled on the link in
>> case of point-to-point (numbered) and LAN interfaces, and (2) multi-hop BFD
>>>>> This begins a two week last call for the subject draft. Please
>>>>> indicate your support or objection on this list prior to 12:00 AM UTC on
>>>>> February 11th, 20222. Also, review comments are certainly welcome.
>>>>>
>>>>> Thanks,
>>>>> Acee
>>>>>
>>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Feb 2022 18:46:57 +0100

Muthu,

If you are using virtual link why is this still multihop BFD ?

Thx,
R.

On Fri, Feb 4, 2022 at 6:22 PM Muthu Arul Mozhi Perumal <
[email-masked]> wrote:

>>>> However, I am not sure what specific applicability or operations need
>>>> to be called out for Strict Mode of operations for those links.
>>>>
>>>> Thanks,
>>>> Ketan
>>>>
>>>>
>>>>> Should it describe the applicability of the mechanism over OSPF
>>>>> virtual links and unnumbered interfaces? With virtual links, one would have
>>>>> to establish a multi-hop BFD session, so it is slightly different from a
>>>>> BFD operational standpoint. For e.g, capability to support single-hop BFD
>>>>> may not translate to the capability to support multi-hop BFD..
>>>>>
>>>>> Regards,
>>>>> Muthu
>>>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 4 Feb 2022 18:14:34 +0000

Hi Robert,
There is no tunnel for an OSPF virtual link, the transit area will require leaking of backbone routes without summarization. Also note that the virtual link endpoint could be reachable in the transit area but may not be up. Multi-hop BFD would still be useful for a virtual link.
Thanks,
Acee

From: Robert Raszuk <[email-masked]>
Date: Friday, February 4, 2022 at 12:48 PM
To: Muthu Arul Mozhi Perumal <[email-masked]>
Cc: Ketan Talaulikar <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Muthu,

Thx,
R.

On Fri, Feb 4, 2022 at 6:22 PM Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

Just curious, are there interoperable implementations for OSPF multi-hop BFD strict mode for virtual links or p2p unnumbered interfaces?

Regards,
Muthu

On Fri, Feb 4, 2022 at 5:36 PM Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Muthu,

When we say a "link" here, it is in the context of the OSPF interface and neighbor FSM. My understanding is that this term includes virtual links as well. As such, we can add some text in the introduction section to clarify the same and also put a reference to RFC5883 for BFD multi-hop use for VLINKs.

Thanks,
Ketan

On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

The draft says:
<snip>
   This document defines the B-bit in the LLS Type 1 Extended Options
   and Flags field.  This bit is defined for the LLS block included in
   Hello and Database Description (DD) packets and indicates that BFD is
   enabled on the link and that the router requests strict-mode for BFD.
</smip>

You don't enable multi-hop BFD on a link, instead you enable it b/w two (multi-hop) routers, right?

How about replacing it with:
indicates that (1) single-hop BFD [RFC5881] is enabled on the link in case of point-to-point (numbered) and LAN interfaces, and (2) multi-hop BFD [RFC5883] is enabled between the neighbors in case of virtual links and point-to-point unnumbered interfaces.

Also, add a note at the beginning of the draft that BFD refers to both single-hop and multi-hop BFD when not explicitly specified..

Regards,
Muthu

On Sun, Jan 30, 2022 at 10:40 PM Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Muthu,

Regarding your question, I would like to clarify that this document doesn't specify BFD operations with OSPF. That was done by RFC5882. Indeed for virtual links, there would need to be a BFD multi-hop session and the same would apply to p-t-p unnumbered.

However, I am not sure what specific applicability or operations need to be called out for Strict Mode of operations for those links.

Thanks,
Ketan

On Sun, Jan 30, 2022 at 12:52 PM Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I support the draft. A quick question:
Should it describe the applicability of the mechanism over OSPF virtual links and unnumbered interfaces? With virtual links, one would have to establish a multi-hop BFD session, so it is slightly different from a BFD operational standpoint. For e.g, capability to support single-hop BFD may not translate to the capability to support multi-hop BFD..

Regards,
Muthu

On Thu, Jan 27, 2022 at 10:38 PM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
LSR WG,

This begins a two week last call for the subject draft. Please indicate your support or objection on this list prior to 12:00 AM UTC on February 11th, 20222. Also, review comments are certainly welcome.
Thanks,
Acee

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Feb 2022 20:13:17 +0100

Ahh ok .. this is "OSPF virtual link" not an emulated "virtual link" seen
as p2p to any routing protocol.

Thx,
R.

On Fri, Feb 4, 2022 at 7:14 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> There is no tunnel for an OSPF virtual link, the transit area will require
> leaking of backbone routes without summarization. Also note that the
> virtual link endpoint could be reachable in the transit area but may not be
> up. Multi-hop BFD would still be useful for a virtual link.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Friday, February 4, 2022 at 12:48 PM
> *To: *Muthu Arul Mozhi Perumal <[email-masked]>
> *Cc: *Ketan Talaulikar <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, Acee Lindem <[email-masked]
> >
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Muthu,
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Feb 2022 02:16:20 -0500

All

I have finally caught up with this thread and I agree with  Les, Ketan and
Albert that the “wait for BFD” goal is accomplished with both the OSPF and
BGP draft.  There is extra verbiage in BGP draft in case BFD does not come
up for BGP to wait.  Agreed not applicable to OSPF.

I agree with the spirit of Roberts idea of a delay as it would help as far
as stability having a “pause” button for degraded links and quality issues,
however I do agree with the WG that this is outside of LSRs scope and
should really be with BFD or better yet IPPM for link quality monitoring.

Overall I believe the goal of the strict mode BFD “wait for BFD” is
accomplished and solve all problems except issues related to poor link
quality issues.

I support both the OSPF and BGP strict mode drafts and I think think this
will be a big gain in itself for operators.

As mentioned in the OSPF draft section 5 on use of hold down timers, BFD
dampening and on ML use of  carrier delay and interface dampening can help
operators with link quality issues until we are able to make some headway
in BFD and IPPM WG.

I would be happy to work with Greg and IPPM WGs as a follow up to this
thread related to link quality issues.

Kind Regards

Gyan

On Fri, Feb 4, 2022 at 2:13 PM Robert Raszuk <[email-masked]> wrote:

>> There is no tunnel for an OSPF virtual link, the transit area will
>> require leaking of backbone routes without summarization. Also note that
>> the virtual link endpoint could be reachable in the transit area but may
>> not be up. Multi-hop BFD would still be useful for a virtual link.
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> [email-masked]>, Acee Lindem <
>> [email-masked]>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Feb 2022 12:11:14 +0100

Gyan,

> Overall I believe the goal of the strict mode BFD “wait for BFD” is
accomplished
> and solve all problems

I do not agree with this statement.

As currently defined in the posted version of the draft "wait for BFD"
means wait for BFD control packets to bring the session up.

The session comes up - yet no BFD Echo packets have been exchanged. That in
turn triggers OSPF adj. to come up.

So we bring OSPF adj UP knowing literally nothing about BFD test results
over subject link. If the BFD timer is set to 2 seconds and the multiplier
is 3 only in 6 seconds the BFD session could go down and take OSPF adj.
down with it which means nothing what this draft aims to accomplish has
been achieved.

Sure one can argue if this is proper for BFD to signal UP state without at
least once exchanging a set of Echo packets - but this is currently not the
case in BFD FSM. If you want to "fix" BFD go for it, but for now the delay
associated with any client action should be based on how BFD works
per definition in RFC5880 and therefore should be specified on the client
side.

Rgs,
Robert.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 6 Feb 2022 12:51:34 +0000

Hi Robert,
I think that much of the additional functionality you are proposing is beyond the scope of the draft and IGP BFD usage today. You could propose all these additional capabilities (e.g., MTU testing and link quality determination beyond what is already in BFD) in a separate draft.
Thanks,
Acee

From: Robert Raszuk <[email-masked]>
Date: Sunday, February 6, 2022 at 6:11 AM
To: Gyan Mishra <[email-masked]>
Cc: Acee Lindem <[email-masked]>, Ketan Talaulikar <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Gyan,

> Overall I believe the goal of the strict mode BFD “wait for BFD” is accomplished
> and solve all problems

As currently defined in the posted version of the draft "wait for BFD" means wait for BFD control packets to bring the session up.

The session comes up - yet no BFD Echo packets have been exchanged. That in turn triggers OSPF adj. to come up.

So we bring OSPF adj UP knowing literally nothing about BFD test results over subject link. If the BFD timer is set to 2 seconds and the multiplier is 3 only in 6 seconds the BFD session could go down and take OSPF adj. down with it which means nothing what this draft aims to accomplish has been achieved.

Sure one can argue if this is proper for BFD to signal UP state without at least once exchanging a set of Echo packets - but this is currently not the case in BFD FSM. If you want to "fix" BFD go for it, but for now the delay associated with any client action should be based on how BFD works per definition in RFC5880 and therefore should be specified on the client side.

Rgs,
Robert.

On Sun, Feb 6, 2022 at 8:16 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

All

I have finally caught up with this thread and I agree with  Les, Ketan and Albert that the “wait for BFD” goal is accomplished with both the OSPF and BGP draft.  There is extra verbiage in BGP draft in case BFD does not come up for BGP to wait.  Agreed not applicable to OSPF.

I agree with the spirit of Roberts idea of a delay as it would help as far as stability having a “pause” button for degraded links and quality issues, however I do agree with the WG that this is outside of LSRs scope and should really be with BFD or better yet IPPM for link quality monitoring.

Overall I believe the goal of the strict mode BFD “wait for BFD” is accomplished and solve all problems except issues related to poor link quality issues.

I support both the OSPF and BGP strict mode drafts and I think think this will be a big gain in itself for operators.

As mentioned in the OSPF draft section 5 on use of hold down timers, BFD dampening and on ML use of  carrier delay and interface dampening can help operators with link quality issues until we are able to make some headway in BFD and IPPM WG.

I would be happy to work with Greg and IPPM WGs as a follow up to this thread related to link quality issues.

Kind Regards
Gyan

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Feb 2022 14:10:55 +0100

Hello Acee,

I am afraid you completely missed my point. Perhaps this is my fault as in
this way too looong email thread I indeed brought additional testing
requirements - but never said those need to be part of this draft nor
specified in LSR WG. Those were just examples on what can occur in this
delta time we are talking about.

I am not asking for any additional BFD capabilities at all in respect to
this draft. I 100% agree those are out of scope of LSR WG.

*I am asking to let at least vanilla BFD probing cycle** to occur (at least
once) before doing any action on the client side. *

Doing any action on the client/protocol  just because BFD control packets
to setup the session got exchanged is a wrong thing to do. When BFD
control packets brought the session UP BFD probing did not even occur yet.

That's it. Subtle yet extremely important point.

** Cycle == probing frequency x multiplier - basic BFD parameters.

Many thx,
R.

On Sun, Feb 6, 2022 at 1:51 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> I think that much of the additional functionality you are proposing is
> beyond the scope of the draft and IGP BFD usage today. You could propose
> all these additional capabilities (e.g., MTU testing and link quality
> determination beyond what is already in BFD) in a separate draft.
>
> Thanks,
>
> Acee
>
>
>
> *Date: *Sunday, February 6, 2022 at 6:11 AM
> *To: *Gyan Mishra <[email-masked]>
> *Cc: *Acee Lindem <[email-masked]>, Ketan Talaulikar <
> [email-masked]>, "[email-masked]" <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Feb 2022 12:24:34 -0500

Hi Robert

> in turn triggers OSPF adj. to come up.

Gyan>. My understanding with RFC 5880 is that BFD control packets have been
sent in asynchronous mode per the interval and multiplier period specified
with the 3 way handshake being completed which tests the bi directional
path between the client endpoints before the session BFD FSM transitions to
the “UP” state.  We can get confirmation from Greg on the behavior.

Key Excerpts  from RFC 5880 below related to this topic.  BFD control
packets are sent during init and 3 way handshake in async mode until BFD
FSM transitions to UP state and only in UP state is Echo if configured is
sent.  So the 3 way handshake from reading below verifies the bi
directional communication between the endpoints which according to the
draft would all occur prior to client coming UP.  However if Echo is
configured for looping the packets for testing that would happen after OSPF
FSM has started.

Section 1

   The goal of Bidirectional Forwarding Detection (BFD) is to provide
   low-overhead, short-duration detection of failures in the path
   between adjacent forwarding engines, including the interfaces, data
   link(s), and, to the extent possible, the forwarding engines
   themselves.

   An additional goal is to provide a single mechanism that can be used
   for liveness detection over any media, at any protocol layer, with a
   wide range of Detection Times and overhead, to avoid a proliferation
   of different methods.

   An additional goal is to provide a single mechanism that can be used
   for liveness detection over any media, at any protocol layer, with a
   wide range of Detection Times and overhead, to avoid a proliferation
   of different methods.

BFD had a per link concept “BFD over bundle member”

   BFD can provide failure detection on any kind of path between
   systems, including direct physical links, virtual circuits, tunnels,
   MPLS Label Switched Paths (LSPs), multihop routed paths, and
   unidirectional links (so long as there is some return path, of
   course).  Multiple BFD sessions can be established between the same
   pair of systems when multiple paths between them are present in at
   least one direction, even if a lesser number of paths are available
   in the other direction (multiple parallel unidirectional links or
   MPLS LSPs, for example).

Section 2

   The BFD state machine implements a three-way handshake, both when
   establishing a BFD session and when tearing it down for any reason,
   to ensure that both systems are aware of the state change.

   BFD can be abstracted as a simple service.  The service primitives
   provided by BFD are to create, destroy, and modify a session, given
   the destination address and other parameters.  BFD in return provides
   a signal to its clients indicating when the BFD session goes up or
   down.

Section 3

   A path is only declared to be operational when two-way communication
   has been established between systems, though this does not preclude
   the use of unidirectional links.

   A separate BFD session is created for each communications path and
   data protocol in use between two systems.

   Each system estimates how quickly it can send and receive BFD packets
   in order to come to an agreement with its neighbor about how rapidly
   detection of failure will take place.  These estimates can be
   modified in real time in order to adapt to unusual situations.  This
   design also allows for fast systems on a shared medium with a slow
   system to be able to more rapidly detect failures between the fast
   systems while allowing the slow system to participate to the best of
   its ability.

Section 3.2 - we are taking about asynchronous mode primarily

   The primary mode is known as Asynchronous mode.  In this mode, the
   systems periodically send BFD Control packets to one another, and if
   a number of those packets in a row are not received by the other
   system, the session is declared to be down.

**note the echo can be enabled for dirty links for additional testing
looping the packets**

Caveat with echo mode is the interval has to be greater then 2 seconds

   An adjunct to both modes is the Echo function.  When the Echo
   function is active, a stream of BFD Echo packets is transmitted in
   such a way as to have the other system loop them back through its
   forwarding path.  If a number of packets of the echoed data stream
   are not received, the session is declared to be down.  The Echo
   function may be used with either Asynchronous or Demand mode.  Since
   the Echo function is handling the task of detection, the rate of
   periodic transmission of Control packets may be reduced (in the case
   of Asynchronous mode) or eliminated completely (in the case of Demand
   mode).

Section 4.1 FSM

         0 -- AdminDown
         1 -- Down
         2 -- Init
         3 -- Up

Section 6.1 - So here in order for the session to come up one or both
clients must take active role to send control packets - so here it’s stated
that control packets are being sent during that 3 way handshake process
that tests the link prior to FSM going to the UP state.

   A system may take either an Active role or a Passive role in session
   initialization.  A system taking the Active role MUST send BFD
   Control packets for a particular session, regardless of whether it
   has received any BFD packets for that session.  A system taking the
   Passive role MUST NOT begin sending BFD packets for a particular
   session until it has received a BFD packet for that session, and thus
   has learned the remote system's discriminator value.  At least one
   system MUST take the Active role (possibly both).  The role that a
   system takes is specific to the application of BFD, and is outside
   the scope of this specification.

   A session begins with the periodic, slow transmission of BFD Control
   packets.  When bidirectional communication is achieved, the BFD
   session becomes Up.

   Once the BFD session is Up, a system can choose to start the Echo
   function if it desires and the other system signals that it will
   allow it.  The rate of transmission of Control packets is typically
   kept low when the Echo function is active.

   If the Echo function is not active, the transmission rate of Control
   packets may be increased to a level necessary to achieve the
   Detection Time requirements for the session.

   If sufficient Echo packets are lost, the session is declared Down in
   the same manner.  See section 6.8.5
<https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.5>.

**so here when session goes down slow packets are still sent**

   If the session goes Down, the transmission of Echo packets (if any)
   ceases, and the transmission of Control packets goes back to the slow
   rate.

**there is still control packet signaling in both directions before
down state is declared by both ends**

   Once a session has been declared Down, it cannot come back up until
   the remote end first signals that it is down (by leaving the Up
   state), thus implementing a three-way handshake.

Section 6.2 this is really important as it describes the 3 way handshake
and transition to Up state and that connectivity between the end systems
have been verified and in UP state.

Up state means that the BFD session has successfully been established, and
implies that connectivity between the systems is working. The session will
remain in the Up state until either connectivity fails or the session is
taken down administratively. If either the remote system signals Down state
or the Detection Time expires, the session advances to Down state.

Section 6.8

When the BFD session transitions to Up state once 3 way handshake is
completed of control packets in async mode are sent  up to this point at
which time if configured for Echo or demand the session transitions to Echo
in which case both Echo and Async control packets are sent or demand mode
where async control packet cease.

   When a system is said to have "the Echo function active" it means
   that the system is sending BFD Echo packets, implying that the
   session is Up and the other system has signaled its willingness to
   loop back Echo packets.

   When the local system is said to have "Demand mode active," it means
   that bfd.DemandMode is 1 in the local system (see section 6.8.1
<https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.1>), the
   session is Up, and the remote system is signaling that the session is
   in state Up.

6.8.1 state variables

   When the text refers to initializing a state variable, this takes
   place only at the time that the session (and the corresponding state
   variables) is created.  The state variables are subsequently
   manipulated by the state machine and are never reinitialized, even if
   the session fails and is reestablished.

   Once session state is created, and at least one BFD Control packet is
   received from the remote end, it MUST be preserved for at least one
   Detection Time (see section 6.8.4
<https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.4>)
subsequent to the receipt of the
   last BFD Control packet, regardless of the session state.  This
   preserves timing parameters in case the session flaps.  A system MAY
   preserve session state longer than this.  The preservation or
   destruction of session state when no BFD Control packets for this
   session have been received from the remote system is outside the
   scope of this specification.

Section 7

It is worth noting that a single BFD session does not consume a large
   amount of bandwidth.  An aggressive session that achieves a detection
   time of 50 milliseconds, by using a transmit interval of 16.7
   milliseconds and a detect multiplier of 3, will generate 60 packets
   per second.  The maximum length of each packet on the wire is on the
   order of 100 bytes, for a total of around 48 kilobits per second of
   bandwidth consumption in each direction.

BFD is bootstrapped to the IGP client per RFC 5882 which states that BFD
should block the client adjacency from coming Up prior to BFD coming up.
Ketan has added this text to the next revision and we should add as well to
the BGP draft.

Section 4.1

   BFD sessions are typically bootstrapped by the control protocol,
   using the mechanism (discovery, configuration) used by the control
   protocol to find neighbors.  Note that it is possible in some failure
   scenarios for the network to be in a state such that the control
   protocol is capable of coming up, but the BFD session cannot be
   established, and, more particularly, data cannot be forwarded.  To
   avoid this situation, it would be beneficial not to allow the control
   protocol to establish a neighbor adjacency.  However, this would
   preclude the operation of the control protocol in an environment in
   which not all systems support BFD.

   Therefore, the establishment of control protocol adjacencies SHOULD
   be blocked if both systems are willing to establish a BFD session but
   a BFD session cannot be established.  One method for determining that
   both systems are willing to establish a BFD session is if the control
   protocol carries explicit signaling of this fact.  If there is no
   explicit signaling, the willingness to establish a BFD session may be
   determined by means outside the scope of this specification.

> over subject link.

Gyan> See above

If the BFD timer is set to 2 seconds and the multiplier is 3 only in 6
> seconds the BFD session could go down and take OSPF adj. down with it which
> means nothing what this draft aims to accomplish has been achieved.
>

> case in BFD FSM.

Gyan> BFD FSM control packets are sent async mode for the 3 way handshake
to complete before the session transitions to the Up state.  The major
caveat with echo mode is it can only be used if the interval is greater
than 2 seconds as the packets have to be looped and when enabled it’s on
top of the async mode control packets still sent.  Most operators don’t use
echo mode for that reason.

If you want to "fix" BFD go for it, but for now the delay associated with
> any client action should be based on how BFD works per definition in
> RFC5880 and therefore should be specified on the client side.
>
> Rgs,
> Robert.
>
>
>
>> I have finally caught up with this thread and I agree with  Les, Ketan
>> and Albert that the “wait for BFD” goal is accomplished with both the OSPF
>> and BGP draft.  There is extra verbiage in BGP draft in case BFD does not
>> come up for BGP to wait.  Agreed not applicable to OSPF.
>>
>> I agree with the spirit of Roberts idea of a delay as it would help as
>> far as stability having a “pause” button for degraded links and quality
>> issues, however I do agree with the WG that this is outside of LSRs scope
>> and should really be with BFD or better yet IPPM for link quality
>> monitoring.
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Feb 2022 12:51:00 -0500

Hi Robert

Applicable to the congestion scenario most implementations prioritize
routing protocol traffic marking as CS6 or CS7 as well as explicit QOS
routing class can be created to classify and schedule all RE/RP sourced
control plane traffic so that BFD packets are protected and not dropped.

Gyan

On Sun, Feb 6, 2022 at 12:24 PM Gyan Mishra <[email-masked]> wrote:

> Gyan>. My understanding with RFC 5880 is that BFD control packets have
> been sent in asynchronous mode per the interval and multiplier period
> specified with the 3 way handshake being completed which tests the bi
> directional path between the client endpoints before the session BFD FSM
> transitions to the “UP” state.  We can get confirmation from Greg on the
> behavior.
>
> **note the echo can be enabled for dirty links for additional testing looping the packets**
>
>
>    the same manner.  See section 6.8.5 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.5>.
>
>
> **there is still control packet signaling in both directions before down state is declared by both ends**
>
>    that bfd.DemandMode is 1 in the local system (see section 6.8.1 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.1>), the
>    Detection Time (see section 6.8.4 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.4>) subsequent to the receipt of the
>> Sure one can argue if this is proper for BFD to signal UP state without
>> at least once exchanging a set of Echo packets - but this is currently not
>> the case in BFD FSM.
>>
>
>>> I support both the OSPF and BGP strict mode drafts and I think think
>>> this will be a big gain in itself for operators.
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Feb 2022 18:52:04 +0100

Gyan,

Exchanging BFD control packets does not guarantee data path liveness nor it
guarantees that subsequent BFD Echo packets will succeed.

BFD UDP control packets can use a different IP address (src or dst)
than the one used for data path probing. Both UDP ports are also different
(3784 vs 3785). Please also observe that BFD control packets are handled by
RE/RP while BFD Echo packet processing is very often offloaded to the line
card(s).

So to me bringing up OSPF adj. immediately after BFD session transitions to
UP state is neither a good thing nor should be stated so by the subject
draft to bring up OSPF adj. without risk of it to shortly go down.

Thx,
R

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 6 Feb 2022 18:08:57 +0000

Robert –

Part of the reason this discussion is long is because we continue to discuss things that are out of scope for the draft in question.

There is nothing in RFC 5880 (nor in, what I consider to be even more relevant, RFC 5882) that requires a BFD implementation to signal UP state to a BFD client within a specific time following transition of the BFD state machine to UP . An implementation is free to introduce a delay (as you suggest) before such signaling.
By insisting that OSPF has a responsibility in this regard you place the burden on the BFD client – which is architecturally the wrong place to do it.

Let’s move this draft forward as it does an excellent job of defining the OSPF behavior necessary to support strict-mode – and that is all it is trying to do and all that it should be doing.

If you feel that there are operational considerations regarding the use of BFD that require additional specification, I suggest you ask the BFD WG to take up this work.

   Les

From: Lsr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Sunday, February 6, 2022 5:11 AM
To: Acee Lindem (acee) <[email-masked]>
Cc: Ketan Talaulikar <[email-masked]>; Gyan Mishra <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hello Acee,

I am afraid you completely missed my point. Perhaps this is my fault as in this way too looong email thread I indeed brought additional testing requirements - but never said those need to be part of this draft nor specified in LSR WG. Those were just examples on what can occur in this delta time we are talking about.

I am not asking for any additional BFD capabilities at all in respect to this draft. I 100% agree those are out of scope of LSR WG.

I am asking to let at least vanilla BFD probing cycle** to occur (at least once) before doing any action on the client side.

Doing any action on the client/protocol  just because BFD control packets to setup the session got exchanged is a wrong thing to do. When BFD control packets brought the session UP BFD probing did not even occur yet.

Many thx,
R.

On Sun, Feb 6, 2022 at 1:51 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,
I think that much of the additional functionality you are proposing is beyond the scope of the draft and IGP BFD usage today. You could propose all these additional capabilities (e.g., MTU testing and link quality determination beyond what is already in BFD) in a separate draft.
Thanks,
Acee

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Sunday, February 6, 2022 at 6:11 AM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Gyan,

Rgs,
Robert.

All

Kind Regards
Gyan

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Feb 2022 13:41:52 -0500

Hi Robert

See RFC 5880 Section 3 - Operating modes.

BFD can run in async or demand mode and “echo” is an adjunct function to
both modes.  The default mode when BFD initializes FSM.

All BFD packets are control packets sent for Async / Demand mode and with
or without Echo function which can be set on one or both ends for forward
path detection.

See RFC 5881 single hop BFD control packets for async and Echo

All BFD control packets use Source / Destination
IP /UDP
UDP destination port
Async-UDP 3784
Echo-UDP 3785

See RFC 5883 Multi hop BFD control packets
Uses UDP port 4784

   Pure Asynchronous mode is advantageous in that it requires half as
   many packets to achieve a particular Detection Time as does the Echo
   function.  It is also used when the Echo function cannot be supported
   for some reason.

   The Echo function has the advantage of truly testing only the
   forwarding path on the remote system.  This may reduce round-trip
   jitter and thus allow more aggressive Detection Times, as well as
   potentially detecting some classes of failure that might not
   otherwise be detected.

   The Echo function may be enabled individually in each direction.  It
   is enabled in a particular direction only when the system that loops
   the Echo packets back signals that it will allow it, and when the
   system that sends the Echo packets decides it wishes to.

I believe all vendor implementations on hardware based distributed
platforms the BFD session is on the LC and not RP/RE for scalability.

Cisco

https://community.cisco.com/t5/service-providers-documents/bfd-support-on-cisco-asr9000/ta-p/3153191#bfd-protocl-overview

Juniper

https://www.juniper.net/documentation/en_US/junos-prototype/topics/concept/bfd-distributed.html

Kind Regards

Gyan

On Sun, Feb 6, 2022 at 12:52 PM Robert Raszuk <[email-masked]> wrote:

> Gyan,
>
> Exchanging BFD control packets does not guarantee data path liveness nor
> it guarantees that subsequent BFD Echo packets will succeed.
>
> So to me bringing up OSPF adj. immediately after BFD session transitions
> to UP state is neither a good thing nor should be stated so by the subject
>> Up state means that the BFD session has successfully been established,
>> and implies that connectivity between the systems is working. The session
>> will remain in the Up state until either connectivity fails or the session
>> is taken down administratively. If either the remote system signals Down
>> state or the Detection Time expires, the session advances to Down state.
>>
>>
>>
>> Section 6.8
>>
>>>> As mentioned in the OSPF draft section 5 on use of hold down timers,
>>>> BFD dampening and on ML use of  carrier delay and interface dampening can
>>>> help operators with link quality issues until we are able to make some
>>>> headway in BFD and IPPM WG.
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Feb 2022 19:42:26 +0100

Hi Les,

> There is nothing in RFC 5880 (nor in, what I consider to be even more
> relevant, RFC 5882) that requires a BFD implementation to signal UP state
> to a BFD client within a specific time following transition of the BFD
> state machine to UP . An implementation is free to introduce a delay (as
> you suggest) before such signaling.
>

My reading of section 6.2 of RFC5880 clearly indicates that BFD is
signalling UP state when BFD session has been established without any
delay.

I am not sure if BFD implementation is free to introduce any delay there
yet still to claim full compliance to RFC5880 (even if technically it would
make sense to have such delay).

Quote:

   Up state means that the BFD session has successfully been
   established, and implies that connectivity between the systems is
   working.  The session will remain in the Up state until either
   connectivity fails or the session is taken down administratively.

Rgs,
Robert.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 6 Feb 2022 22:05:20 +0000

Robert –

From: Robert Raszuk <[email-masked]>
Sent: Sunday, February 6, 2022 10:42 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Les,

My reading of section 6.2 of RFC5880 clearly indicates that BFD is signalling UP state when BFD session has been established without any delay.
[LES:] This is specifying the BFD State Machine and signaling between BFD peers – not signaling between BFD and its local clients.
RFC 5882 has some discussion of the latter – particularly https://www.rfc-editor.org/rfc/rfc5882.html#section-3

It is worth quoting this sentence:

“The interaction between a BFD session and its associated client
   applications is, for the most part, an implementation issue that is
   outside the scope of this specification.”

Indeed, one way of implementing “BFD Dampening” (as some vendors have done) is to delay notification of BFD UP state to BFD clients.

The obvious benefits of implementing such a delay (if desired) before BFD signals UP to clients are that it is client agnostic and does not require any knowledge on the part of the clients as to when BFD has completed any additional procedures. The client simply operates as if BFD session is DOWN until it gets an UP indication from BFD.

   Les

I am not sure if BFD implementation is free to introduce any delay there yet still to claim full compliance to RFC5880 (even if technically it would make sense to have such delay).

Quote:

Rgs,
Robert.

---

From: Christian Hopps <[email-masked]>
Date: Sun, 06 Feb 2022 17:14:25 -0500

Robert Raszuk <[email-masked]> writes:

> Hi Les,
>  
>
>
>     There is nothing in RFC 5880 (nor in, what I consider to be even
>     more relevant, RFC 5882) that requires a BFD implementation to
>     signal UP state to a BFD client within a specific time following
>     transition of the BFD state machine to UP . An implementation is
>     free to introduce a delay (as you suggest) before such signaling.
>
>
> I am not sure if BFD implementation is free to introduce any delay
> there yet still to claim full compliance to RFC5880 (even if
> technically it would make sense to have such delay). 

If you publish an RFC that adds to or extends the BFD "UP" concept then it can simply "updates 5880", if required.

In any case, the delay concept you are talking about is not without merit, but I don't see how it is OSPF specific; it would also benefit IS-IS and other BFD clients as well, right? To me that says do this in BFD so everyone can benefit.

Thanks,
Chris.
[as wg member]

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Feb 2022 23:30:05 +0100

Hi Les,

BFD dampening as per some documentation is applicable or is triggered by
flapping BFD session(s). And indeed it has its own very valid use case. But
IMHO it is only partially a solution for what we need in the light of this
thread.

Here in this context assume I am looking at a new interface being
provisioned.

So DOWN transitions happened infinitely long before to first UP and stays
UP. I see nowhere in BFD Dampening description that it will also
suppress for time T even first UP notification after a long enough DOWN
event. In bringing the new interface UP all dampening parameters have
expired.

To me dampening may kick in when you go DOWN and suppress excessive UP
events before presumed link stability is achieved as expressed in dampening
[ half-life-period reuse-threshold suppress-threshold max-suppress-time]
cli. But I see nowhere in the docs any indication that BFD Dampening can be
used as an unconditional UP transition suppression buffer.

The same applies to interfaces which went down and came UP after
max-suppress-time had already expired.

Thx,
R.

On Sun, Feb 6, 2022 at 11:05 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Sunday, February 6, 2022 10:42 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for

> *[LES:] This is specifying the BFD State Machine and signaling between BFD
> peers – not signaling between BFD and its local clients.*
>
> *RFC 5882 has some discussion of the latter – particularly
> https://www.rfc-editor.org/rfc/rfc5882.html#section-3
> <https://www.rfc-editor.org/rfc/rfc5882.html#section-3> *
>
>
>
> *It is worth quoting this sentence:*
>
>
>
> *“The interaction between a BFD session and its associated client*
>
> *   applications is, for the most part, an implementation issue that is*
>
> *   outside the scope of this specification.”*
>
>
>
> *Indeed, one way of implementing “BFD Dampening” (as some vendors have
> done) is to delay notification of BFD UP state to BFD clients.*
>
>
>
> *The obvious benefits of implementing such a delay (if desired) before BFD
> signals UP to clients are that it is client agnostic and does not require
> any knowledge on the part of the clients as to when BFD has completed any
> additional procedures. The client simply operates as if BFD session is DOWN
> until it gets an UP indication from BFD.*
>
>
>
> *   Les*
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Feb 2022 17:38:52 -0500

Hi Les

> peers – not signaling between BFD and its local clients.*

      Gyan> Agreed

> * Gyan> Agreed that Interaction between BFD and local client is an
> implementation issue.  Section 3.3 Hitless establishment and
> reestablishment of BFD state in cases where BFD state changes should not be
> signaled to the clients such as process restart -GR. That is one of the
> reasons why the BFD to local client  signaling is an implementation issue
> due to these types of caveats and thus devoid of the specification.*
>
> * Gyan> Agreed.  Makes sense.*
>
> *   Les*
>
>
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Feb 2022 23:40:44 +0100

Hi Chris,

> but I don't see how it is OSPF specific

I have brought this in the context of the waif-for-bfd OSPF proposal. This
is the first time LSR WG is facing such a requirement so IMO it would be
proper to at least discuss this in the draft.

And if so all I merely suggested was to mention this in the draft and make
sure readers understand what this draft should wait for to trigger OSPF
adj, to come up.  But as retrospect of this 100 mail thread I am drawing a
conclusion that maybe I am asking for too much perfection in the spec.
Maybe not many folks will even notice this. They will just spend hours on
troubleshooting why packets got dropped and will blame telco for providing
such a crappy circuit physical or an emulated one :)

And you have seen a clear recommendation from Jeff that such change or
delay is not likely going to happen on the BFD side and it is up to
the client to change its FSM in that respect. I do not see why this should
not be at least described in the draft.

Anyhow enough time spent on this ...

Many thx,
Robert

On Sun, Feb 6, 2022 at 11:29 PM Christian Hopps <[email-masked]> wrote:

> In any case, the delay concept you are talking about is not without merit,
> but I don't see how it is OSPF specific; it would also benefit IS-IS and
> other BFD clients as well, right? To me that says do this in BFD so
> everyone can benefit.
>
> Thanks,
> Chris.
> [as wg member]
>
> >
> > Quote:
> >
> >

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Feb 2022 18:02:07 -0500

Hi Chris

> can simply "updates 5880", if required.

  Gyan> I think the difficulty maybe in updating RFC 5882  is what Les
pointed out in section 3 signaling between BFD and local client is an
implementation issue out of scope.  Reading section 3.1 session hysteresis
below maybe reasons why the signaling is out of scope below due to process
restart.

   A BFD session can be tightly coupled to its client applications;  for
   example, any transition out of the Up state could cause signaling to
   the clients to take failure action.  However, in some cases, this may
   not always be the best course of action.

   “Implementors may choose to hide rapid Up/Down/Up transitions of the
   BFD session from its clients.  This is useful in order to support
   process restarts without necessitating complex protocol mechanisms,
   for example.

   As such, a system MAY choose not to notify clients if a BFD session
   transitions from Up to Down state, and returns to Up state, if it
   does so within a reasonable period of time (the length of which is
   outside the scope of this specification).  If the BFD session does
   not return to Up state within that time frame, the clients SHOULD be
   notified that a session failure has occurred”

I think the only option is dampening delay.

> other BFD clients as well, right? To me that says do this in BFD so

    Gyan> Agreed the delay would benefit OSPF, ISIS and BGP.

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 6 Feb 2022 23:14:02 +0000

Robert –

I have brought this in the context of the waif-for-bfd OSPF proposal. This is the first time LSR WG is facing such a requirement so IMO it would be proper to at least discuss this in the draft.

[LES:] Well – no – that statement isn’t true.
The strict-mode drafts (OSPF and BGP) are specifying behavior which has long been deployed.
IS-IS specified this in RFC 6213 many years ago.
Proprietary implementations of the equivalent functionality in OSPF have been deployed for many years – but they lack a means to successfully interoperate with implementations which do not have the functionality and/or are not configured to enable it.

All this draft is doing is defining protocol extensions for OSPF to support strict-mode as it has been deployed for many years.
As such, most of the discussion is out of scope and we should simply approve the document.

It is both understandable and potentially useful that the context here has revived other concerns that you may have had for a long time. But addressing those concerns is new work, outside the scope of this draft, and likely demands a broader audience than LSR WG provides.

Let’s move on with this draft as is.
If you or others want to pursue new work related to this functionality, please do so – but NOT in the context of this draft.

   Les

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Feb 2022 00:31:04 +0100

Les,

Please kindly present the facts.

The facts are that equivalent functionality in OSPF which has been approved
for years uses a configurable timer which allows both - to wait for BFD as
well to make sure that BFD stays UP till that timer expires. The point I
even started this discussion was about your threat *that this timer will be
removed* once this draft goes to RFC.

So today without this timer when the interface goes UP both OSPF and BFD go
in parallel and OSPF can win. That is bad as BFD when it comes UP and
shortly goes down causes routing churn and packet drops. Note that can
happen in the vast majority of cases when either links have problems with
unicast (possible but pretty rare) or when BFD came up some time (say 100
ms) after OSPF brought adj. UP and then BFD declared failure during Echo
packet exchange.

So how does the situation above change with this draft ...

When the interface goes UP OSPF will not bring adj UP till BFD comes UP.
But then we are back in square one as OSPF adj comes UP and BFD after a
full cycle of testing brings it back down. So what have we accomplished
with this draft/RFC - nothing.

In both cases you have to be pretty unlucky to get a link failure either
between OSPF adj UP and BFD full cycle of Echo packets. But the entire
purpose of this draft is to address that very unfortunate sequence of
events.

We all seem to agree we need to wait a bit longer. We have whatsoever no
agreement across WGs who should take it on it's shoulder. Should this be
BFD to delay UP notification to the client, should this be the client to
take UP but only move on if no DOWN was seen within a timer or maybe this
should be middlemen like RIB which is likely acting as a postman here.

I still believe all of this should be at least reflected in the draft even
if the conclusion is to leave it up to implementation choice.

IMO refusing to even mention this is equal to proceeding with
architecturally broken specification.

Cheers,
Robert.

On Mon, Feb 7, 2022 at 12:14 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *[LES:] Well – no – that statement isn’t true.*
>
> *The strict-mode drafts (OSPF and BGP) are specifying behavior which has
> long been deployed.*
>
> *IS-IS specified this in RFC 6213 many years ago.*
>
> *Proprietary implementations of the equivalent functionality in OSPF have
> been deployed for many years – but they lack a means to successfully
> interoperate with implementations which do not have the functionality
> and/or are not configured to enable it.*
>
>
>
> *All this draft is doing is defining protocol extensions for OSPF to
> support strict-mode as it has been deployed for many years.*
>
> *As such, most of the discussion is out of scope and we should simply
> approve the document.*
>
>
>
> *It is both understandable and potentially useful that the context here
> has revived other concerns that you may have had for a long time. But
> addressing those concerns is new work, outside the scope of this draft, and
> likely demands a broader audience than LSR WG provides.*
>
>
>
> *Let’s move on with this draft as is.*
>
> *If you or others want to pursue new work related to this functionality,
> please do so – but NOT in the context of this draft.*
>
>
>
> *   Les*
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 7 Feb 2022 01:05:51 +0000

Robert –

I am hoping to bring closure to the question of progressing the OSPF BFD strict mode draft. To that end I will not address each of your points in detail.
I will say that what you have presented is NOT an accurate history.

Strict-mode behavior has been deployed for many years – first with IS-IS – later (with proprietary implementations) in OSPF. BFD Dampening was not in the picture.
The issue BFD Dampening tries to address came later – and the mechanisms used to implement it have not been broadly agreed upon.
There certainly is an argument to be made that the BFD Client is the worst possible choice if one were to implement a form of dampening. There may not be consensus on that point – but there is also not consensus against it either.

If you are drawing a line and saying the draft should not go forward without discussing dampening/delay – I am decidedly on the other side of that line.

   Les

From: Lsr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Sunday, February 6, 2022 3:31 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: lsr <[email-masked]>; Christian Hopps <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Les,

The facts are that equivalent functionality in OSPF which has been approved for years uses a configurable timer which allows both - to wait for BFD as well to make sure that BFD stays UP till that timer expires. The point I even started this discussion was about your threat that this timer will be removed once this draft goes to RFC.

So today without this timer when the interface goes UP both OSPF and BFD go in parallel and OSPF can win. That is bad as BFD when it comes UP and shortly goes down causes routing churn and packet drops. Note that can happen in the vast majority of cases when either links have problems with unicast (possible but pretty rare) or when BFD came up some time (say 100 ms) after OSPF brought adj. UP and then BFD declared failure during Echo packet exchange.

When the interface goes UP OSPF will not bring adj UP till BFD comes UP. But then we are back in square one as OSPF adj comes UP and BFD after a full cycle of testing brings it back down. So what have we accomplished with this draft/RFC - nothing.

In both cases you have to be pretty unlucky to get a link failure either between OSPF adj UP and BFD full cycle of Echo packets. But the entire purpose of this draft is to address that very unfortunate sequence of events.

We all seem to agree we need to wait a bit longer. We have whatsoever no agreement across WGs who should take it on it's shoulder. Should this be BFD to delay UP notification to the client, should this be the client to take UP but only move on if no DOWN was seen within a timer or maybe this should be middlemen like RIB which is likely acting as a postman here.

I still believe all of this should be at least reflected in the draft even if the conclusion is to leave it up to implementation choice.

IMO refusing to even mention this is equal to proceeding with architecturally broken specification.

Cheers,
Robert.

On Mon, Feb 7, 2022 at 12:14 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

   Les

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 8 Feb 2022 20:13:53 +0530

Hi Muthu,

I don't have the data for BFD strict-mode interop over virtual links.
However, p2p unnumbered is commonly deployed and I'll let my co-author
clarify on interop.

Thanks,
Ketan