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

From: "Albert Fu (BLOOMBERG/ 120 PARK)" <[email-masked]>
Date: Sun, 30 Jan 2022 14:28:55 -0000

I feel it is better to keep the standard simple and not add timer delay as part of BFD strict draft, as different customers may have different requirements, and there may also be vendor/platform dependency.

For example, in the core where there are a lot of link redundancy/diversity, we could afford to have longer time delay since we can tolerate multiple link failures. For majority of the edge connectivity, there are typically only 2 links - in this situation, we would want a lower time delay.

I found the current BFD Strict holddown/dampening mechanism as implemented by the two vendors sufficient for our need. If there is an issue causing BFD to fail during this time, OSPF will take longer time to come up. And the delay only needs to be configured on one side. 

So, in current implementation, there's some sanity "check" that BFD is stable for a period of time before OSPF can come up. 

In discussion with the BFD working group on my other MTU draft, there's a keen interest among the WG to keep the BFD simple.

From: [email-masked] At: 01/29/22 15:20:06 UTC-5:00To:  [email-masked]
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  [email-masked],  [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

Hi Les,

> Discussion of how to make BFD failure detection more robust belongs in the BFD WG
> If you do not want the BFD session to come back up too quickly after a failure

Nothing I suggested is related to any of the above. 

Let me perhaps provide a very simple example. 

BFD being used is *AS*IS*.  

All the operator wants is to run it for say X sec without ever going down before bringing OSPF adj up. 

That timer and its consistency on both ends clearly belongs to OSPF not to BFD. 

Now what happens within those 30 sec, what BFD packets are formed and how they are exchanged is all BFD business - but I am not suggesting to include any of those in this draft. 

Do we have a common understanding so far ? 

Hint: Albert already stated that he needs that timer and that both vendors provided it via cfg. All that confirms is that timer is needed. All I am suggesting (even before being aware of the manual cfg for it) was to synchronize the value or pick lower configured between two peers. 

Kind regards,
R.

On Sat, Jan 29, 2022 at 9:08 PM Les Ginsberg (ginsberg) <[email-masked]> wrote:

Robert – 
  
It is good that you take an active interest in this technology – but I think the suggestions you are making should not be targeted at IGP use of BFD. 
  
Discussion of how to make BFD failure detection more robust belongs in the BFD WG – and – as you know – that WG has taken an interest in such problems e.g., MTU. 
  
In regards to “dampening” = which I think is the relevant term for the timer related suggestions you are making - this also does not belong in the IGP. If you do not want the BFD session to come back up too quickly after a failure, the  proper place to put timers is either at the interface layer or in the BFD implementation. 
I am familiar with implementations which apply this timer at the protocol level (AKA BFD client in this context) and this is done precisely because the protocol does NOT have the functionality being defined in this draft. Once you have  implemented “wait-for-BFD” logic as defined in this draft you do not need additional delay timers in the protocol. 
  
I don’t think the suggestions you are making belong in this document. 
  
    Les 

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

Hi Acee, 

Can you suggest text which with you’d be happy? I’m sure the authors would add you to the acknowledgements.

Actually instead of suggesting any new text I would suggest to delete the two below sentences and it will be fine:  

"In certain other scenarios, a degraded or poor quality link will allow OSPF adjacency formation to succeed 

but the BFD session establishment will fail or the BFD session will flap.  In this case, traffic that gets  

forwarded over such a link may experience packet drops while the failure of the BFD session establishment  

would not enable fast routing convergence if the link were to go down or flap." 

This could be described but I don’t think it should be normative. This begs the question as to why a hold down timer is not a part of the BFD protocol itself.

There is one - BFD calls it multiplier.  

But the timer I am suggesting is not related to BFD operation, but to OSPF (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about allowing BFD for more testing (with various parameters (for example increasing test packet  size in some discrete steps) before OSPF is happy to bring the adj. up.  

Thx, 

R.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Jan 2022 16:13:21 +0100

Hi Albert,

Thank you for confirming that BFD needs to be kept simple and there is
already reluctance to add to it. So Les's suggestion to put additional
logic into BFD is likely not a realistic one.

Your note also confirms my points that there is likely to be different
holdtime timer requirements depending on the link type and peer type.

With that please notice what Les said:

*And once OSPF strict-mode support becomes widely deployed there won’t be a
need for such a timer for OSPF either.*

That to me clearly means that he is going to retire the current timer once
we get that RFC out of the door. That is why I proposed to add it to the
document. But of course authors will decide.

Dear WG,

After thinking about this draft I would suggest that what we really need is
not a point solution, but a general mechanism which will allow us to bring
the protocol full up after some time from the moment the test suite is up.

BFD is only one way to detect if the path to a peer is up or down. There
are shipping alternatives to this today which could be used instead of BFD
(for example any form of object tracking). As the current version of the
draft says there is need to not only detect if the path is up or down but
also if it meets quality expectations. New wave of INT tools is becoming
available to allow us to measure those characteristics today.

So while the draft could still bring BFD as one example of such a tool - in
my opinion it deserves to be generalized a bit to allow other ways to
determine if the link over which we are to establish IGP adj. meets the
requirements.

Kind regards,
Robert

On Sun, Jan 30, 2022 at 3:28 PM Albert Fu (BLOOMBERG/ 120 PARK) <
[email-masked]> wrote:

> I feel it is better to keep the standard simple and not add timer delay as
> part of BFD strict draft, as different customers may have different
> requirements, and there may also be vendor/platform dependency.
>
> For example, in the core where there are a lot of link
> redundancy/diversity, we could afford to have longer time delay since we
> can tolerate multiple link failures. For majority of the edge connectivity,
> there are typically only 2 links - in this situation, we would want a lower
> time delay.
>
> I found the current BFD Strict holddown/dampening mechanism as implemented
> by the two vendors sufficient for our need. If there is an issue causing
> BFD to fail during this time, OSPF will take longer time to come up. And
> the delay only needs to be configured on one side.
>
> So, in current implementation, there's some sanity "check" that BFD is
> stable for a period of time before OSPF can come up.
>
> In discussion with the BFD working group on my other MTU draft, there's a
> keen interest among the WG to keep the BFD simple.
>
>
>
>
> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) <[email-masked]>, [email-masked],
> [email-masked], [email-masked],
> [email-masked]
> Now what happens within those 30 sec, what BFD packets are formed and how
> they are exchanged is all BFD business - but I am not suggesting to include
> any of those in this draft.
>
> Hint: Albert already stated that he needs that timer and that both vendors
> provided it via cfg. All that confirms is that timer is needed. All I am
> suggesting (even before being aware of the manual cfg for it) was to
> synchronize the value or pick lower configured between two peers.
>
> Kind regards,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> It is good that you take an active interest in this technology – but I
>> think the suggestions you are making should not be targeted at IGP use of
>> BFD.
>>
>>
>>
>> Discussion of how to make BFD failure detection more robust belongs in
>> the BFD WG – and – as you know – that WG has taken an interest in such
>> problems e.g., MTU.
>>
>>
>>
>> In regards to “dampening” = which I think is the relevant term for the
>> timer related suggestions you are making - this also does not belong in the
>> IGP. If you do not want the BFD session to come back up too quickly after a
>> failure, the proper place to put timers is either at the interface layer or
>> in the BFD implementation.
>>
>> I am familiar with implementations which apply this timer at the protocol
>> level (AKA BFD client in this context) and this is done precisely because
>> the protocol does NOT have the functionality being defined in this draft.
>> Once you have implemented “wait-for-BFD” logic as defined in this draft you
>> do not need additional delay timers in the protocol.
>>
>>
>>
>> *From:* Lsr <[email-masked]> *On Behalf Of * Robert Raszuk
>> *Sent:* Saturday, January 29, 2022 11:25 AM
>> *To:* Acee Lindem (acee) <[email-masked]>
>> *Cc:* Ketan Talaulikar <[email-masked]>;
>> [email-masked]; Albert Fu <
>> [email-masked]>; lsr <[email-masked]>
>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> *"In certain other scenarios, a degraded or poor quality link will allow
>> OSPF adjacency formation to succeed*
>>
>> *but the BFD session establishment will fail or the BFD session
>> will flap.  In this case, traffic that gets *
>>
>> *forwarded over such a link may experience packet drops while the failure
>> of the BFD session establishment *
>>
>> *would not enable fast routing convergence if the link were to go down or
>> flap."*
>>
>>
>>
>> This could be described but I don’t think it should be normative. This
>> begs the question as to why a hold down timer is not a part of the BFD
>> protocol itself.
>>
>>
>>
>> But the timer I am suggesting is not related to BFD operation, but to
>> OSPF (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is
>> about allowing BFD for more testing (with various parameters (for example
>> increasing test packet size in some discrete steps) before OSPF is happy to
>> bring the adj. up.
>>
>>
>>
>> Thx,
>>
>> R.
>>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 30 Jan 2022 11:37:30 -0500

Hi Robert

On Sun, Jan 30, 2022 at 10:13 AM Robert Raszuk <[email-masked]> wrote:

> *And once OSPF strict-mode support becomes widely deployed there won’t be
> a need for such a timer for OSPF either.*
>

Gyan> The goal is to make sure the link quality is good by ensuring BFD
session comes up prior to OSPF coming Up.  Once BFD is Up the path has been
verified by BFD to be good so I don’t see any need for any additional
timer.  Is the idea to have a timer just to test for initial deployment by
operators and then remove from code for widespread implementation and
deployment.  Also is the idea to have a delay stable period similar to IGP
sync delay timer for test tools to run successfully prior?

>
>
> Dear WG,
>
> After thinking about this draft I would suggest that what we really need
> is not a point solution, but a general mechanism which will allow us to
> bring the protocol full up after some time from the moment the test suite
> is up.
>

    Gyan> IPPM WG has OAM and IOAM test tools that can work as well as many
other performance monitoring tools that can be integrated similar to
integration we are seeing with Flex Algo.  However BFD is bootstrapped to
the IGP for fast convergence.  So are you suggesting during the time after
BFD comes up during the delay timer period that a general test suite of
applications run?

> available to allow us to measure those characteristics today.

Gyan> Agreed but are you suggesting this test suite of performance
monitoring tools get kicked off to run after BFD is up during the stable
delay timer period before OSPF comes Up.  Would we add a similar delay
timer to ISIS and test suite to be consistent?

>
> So while the draft could still bring BFD as one example of such a tool -
> in my opinion it deserves to be generalized a bit to allow other ways to

     Gyan> BFD is a requirement for operators as it’s bootstrapped to the
IGP for fast convergence.  So any test suite we are talking about would be
external to BFD that would run during the IGP delay timer or all the time
once any link is Up.

>> I feel it is better to keep the standard simple and not add timer delay
>> as part of BFD strict draft, as different customers may have different
>> I found the current BFD Strict holddown/dampening mechanism as
>> implemented by the two vendors sufficient for our need. If there is an
>> issue causing BFD to fail during this time, OSPF will take longer time to
>> come up. And the delay only needs to be configured on one side.
>>
>> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) <[email-masked]>,
>> [email-masked], [email-masked],
>> [email-masked], [email-masked]
>> the BFD WG
>> Hint: Albert already stated that he needs that timer and that both
>> vendors provided it via cfg. All that confirms is that timer is needed. All
>> I am suggesting (even before being aware of the manual cfg for it) was to
>>> I am familiar with implementations which apply this timer at the
>>> protocol level (AKA BFD client in this context) and this is done precisely
>>> because the protocol does NOT have the functionality being defined in this
>>> draft. Once you have implemented “wait-for-BFD” logic as defined in this
>>> draft you do not need additional delay timers in the protocol.
>>>
>>>
>>>
>>> Actually instead of suggesting any new text I would suggest to delete
>>> the two below sentences and it will be fine:
>>>
>>>
>>>
>>> *forwarded over such a link may experience packet drops while the
>>> failure of the BFD session establishment *
>>>
>>> *would not enable fast routing convergence if the link were to go down
>>> or flap."*
>>>
>>>
>>>
>> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 30 Jan 2022 22:40:19 +0530

Hi Robert,

If I've understood correctly, your point is :
a) That there are several other mechanisms for "link" verification that do
various levels of monitoring from basic reachability to more advanced
metrics (BFD is just one of them)
b) That there are several protocols that can leverage (a) before their
protocol sessions are established (OSPF is just one of them)

One can argue that implementations can (and do) some of the above with
implementation-specific mechanisms (e.g. similar to object-tracking). There
is the part of what monitoring mechanism to be used and then their
respective parameters. This could be added to protocols or done via
provisioning (cfg knobs).

This draft covers just the indication of the use of BFD with OSPF. There is
similar work already published as RFC for ISIS (that Les points out) and
there is a WG draft for the same in BGP.

IMHO, there is value in progressing this draft while the broader
discussions for your points continue.

Thanks,
Ketan