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

[Gyan Mishra]

Excellent!


Many Thanks

Gyan
On Sun, Feb 13, 2022 at 3:19 PM Robert Raszuk  wrote:

> Gyan,
>
> The OSPF draft you quote does not make any assumptions nor restrictions on
> how BFD session itself is setup.
>
> So yes procedures described in draft-ietf-bfd-unsolicited could be used as
> a way to bring up BFD session between peers.
>
> Rgs,
> R.
>
>
> On Sun, Feb 13, 2022 at 9:05 PM Gyan Mishra  wrote:
>
>>
>> Hi Robert
>>
>> Would this BFD strict  mode apply to unsolicited BFD of which you are
>> author?
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-03
>>
>> I think if applicable I think would be a good idea.
>>
>> Many Thanks
>>
>> Gyan
>> On Thu, Feb 10, 2022 at 10:59 AM Acee Lindem (acee) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> Hi Robert,
>>>
>>> This is great to hear – I thought you wanted to make this required for
>>> implementation as opposed to a recommendation.
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Robert Raszuk 
>>> *Date: *Thursday, February 10, 2022 at 10:57 AM
>>> *To: *Acee Lindem 
>>> *Cc: *"lsr@ietf.org" , "
>>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
>>> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi Acee,
>>>
>>>
>>>
>>> > There was debate regarding making the delay timer described in section
>>> 5 a normative requirement.
>>>
>>>
>>>
>>> I see added into new version of the draft the following text into
>>> section 5:
>>>
>>>
>>>
>>>The use of OSPF BFD strict-
>>>mode along with mechanisms such as hold-down
>>> *(a delay in the initialOSPF adjacency bringup following BFD session
>>> establishment)* and/or
>>>dampening
>>> *(a delay in the OSPF adjacency bringup following failuredetected by
>>> BFD)* may help reduce the frequency of adjacency flaps and
>>>therefore reduce the associated routing churn.
>>>
>>>
>>>
>>> Not sure if this is normative or informative, but it addresses my point.
>>>
>>>
>>>
>>> Thx,
>>>
>>> Robert.
>>>
>>>
>>>
>>> On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee) >> 40cisco@dmarc.ietf.org> wrote:
>>>
>>> The WG last call has all but ended and we’ve had a lot of support, two
>>> implementations, and some good discussion. Please review the -05 version of
>>> the draft reflecting including changes reflecting this discussion. There
>>> was debate regarding making the delay timer described in section 5 a
>>> normative requirement. The consensus was to not make this a normative part
>>> of the specification. I feel this is the right decision – especially given
>>> that this is new functionality being requested at Working Group Last Call
>>> and implementations accomplish the dampening in vary ways.
>>>
>>>
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Lsr  on behalf of "Acee Lindem (acee)"
>>> 
>>> *Date: *Thursday, January 27, 2022 at 12:09 PM
>>> *To: *"lsr@ietf.org" 
>>> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
>>> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
>>> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> 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
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mis...@verizon.com *
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Gyan,

The OSPF draft you quote does not make any assumptions nor restrictions on
how BFD session itself is setup.

So yes procedures described in draft-ietf-bfd-unsolicited could be used as
a way to bring up BFD session between peers.

Rgs,
R.


On Sun, Feb 13, 2022 at 9:05 PM Gyan Mishra  wrote:

>
> Hi Robert
>
> Would this BFD strict  mode apply to unsolicited BFD of which you are
> author?
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-03
>
> I think if applicable I think would be a good idea.
>
> Many Thanks
>
> Gyan
> On Thu, Feb 10, 2022 at 10:59 AM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>> Hi Robert,
>>
>> This is great to hear – I thought you wanted to make this required for
>> implementation as opposed to a recommendation.
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> *From: *Robert Raszuk 
>> *Date: *Thursday, February 10, 2022 at 10:57 AM
>> *To: *Acee Lindem 
>> *Cc: *"lsr@ietf.org" , "
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
>> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> > There was debate regarding making the delay timer described in section
>> 5 a normative requirement.
>>
>>
>>
>> I see added into new version of the draft the following text into section
>> 5:
>>
>>
>>
>>The use of OSPF BFD strict-
>>mode along with mechanisms such as hold-down
>> *(a delay in the initialOSPF adjacency bringup following BFD session
>> establishment)* and/or
>>dampening
>> *(a delay in the OSPF adjacency bringup following failuredetected by
>> BFD)* may help reduce the frequency of adjacency flaps and
>>therefore reduce the associated routing churn.
>>
>>
>>
>> Not sure if this is normative or informative, but it addresses my point.
>>
>>
>>
>> Thx,
>>
>> Robert.
>>
>>
>>
>> On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee) > 40cisco@dmarc.ietf.org> wrote:
>>
>> The WG last call has all but ended and we’ve had a lot of support, two
>> implementations, and some good discussion. Please review the -05 version of
>> the draft reflecting including changes reflecting this discussion. There
>> was debate regarding making the delay timer described in section 5 a
>> normative requirement. The consensus was to not make this a normative part
>> of the specification. I feel this is the right decision – especially given
>> that this is new functionality being requested at Working Group Last Call
>> and implementations accomplish the dampening in vary ways.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> *From: *Lsr  on behalf of "Acee Lindem (acee)"
>> 
>> *Date: *Thursday, January 27, 2022 at 12:09 PM
>> *To: *"lsr@ietf.org" 
>> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
>> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
>> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> 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
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Robert

Would this BFD strict  mode apply to unsolicited BFD of which you are
author?

https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-03

I think if applicable I think would be a good idea.

Many Thanks

Gyan
On Thu, Feb 10, 2022 at 10:59 AM Acee Lindem (acee)  wrote:

> Hi Robert,
>
> This is great to hear – I thought you wanted to make this required for
> implementation as opposed to a recommendation.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Robert Raszuk 
> *Date: *Thursday, February 10, 2022 at 10:57 AM
> *To: *Acee Lindem 
> *Cc: *"lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Acee,
>
>
>
> > There was debate regarding making the delay timer described in section 5
> a normative requirement.
>
>
>
> I see added into new version of the draft the following text into section
> 5:
>
>
>
>The use of OSPF BFD strict-
>mode along with mechanisms such as hold-down
> *(a delay in the initialOSPF adjacency bringup following BFD session
> establishment)* and/or
>dampening
> *(a delay in the OSPF adjacency bringup following failuredetected by
> BFD)* may help reduce the frequency of adjacency flaps and
>therefore reduce the associated routing churn.
>
>
>
> Not sure if this is normative or informative, but it addresses my point.
>
>
>
> Thx,
>
> Robert.
>
>
>
> On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> The WG last call has all but ended and we’ve had a lot of support, two
> implementations, and some good discussion. Please review the -05 version of
> the draft reflecting including changes reflecting this discussion. There
> was debate regarding making the delay timer described in section 5 a
> normative requirement. The consensus was to not make this a normative part
> of the specification. I feel this is the right decision – especially given
> that this is new functionality being requested at Working Group Last Call
> and implementations accomplish the dampening in vary ways.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Thursday, January 27, 2022 at 12:09 PM
> *To: *"lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Robert,
This is great to hear – I thought you wanted to make this required for 
implementation as opposed to a recommendation.
Thanks,
Acee

From: Robert Raszuk 
Date: Thursday, February 10, 2022 at 10:57 AM
To: Acee Lindem 
Cc: "lsr@ietf.org" , 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 

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

Hi Acee,

> There was debate regarding making the delay timer described in section 5 a 
> normative requirement.

I see added into new version of the draft the following text into section 5:

   The use of OSPF BFD strict-
   mode along with mechanisms such as hold-down (a delay in the initial
   OSPF adjacency bringup following BFD session establishment) and/or
   dampening (a delay in the OSPF adjacency bringup following failure
   detected by BFD) may help reduce the frequency of adjacency flaps and
   therefore reduce the associated routing churn.

Not sure if this is normative or informative, but it addresses my point.

Thx,
Robert.

On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
The WG last call has all but ended and we’ve had a lot of support, two 
implementations, and some good discussion. Please review the -05 version of the 
draft reflecting including changes reflecting this discussion. There was debate 
regarding making the delay timer described in section 5 a normative 
requirement. The consensus was to not make this a normative part of the 
specification. I feel this is the right decision – especially given that this 
is new functionality being requested at Working Group Last Call and 
implementations accomplish the dampening in vary ways.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

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
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hi Acee,

> There was debate regarding making the delay timer described in section 5
a normative requirement.

I see added into new version of the draft the following text into section
5:

   The use of OSPF BFD strict-
   mode along with mechanisms such as hold-down
*(a delay in the initial   OSPF adjacency bringup following BFD session
establishment)* and/or
   dampening
*(a delay in the OSPF adjacency bringup following failure   detected by
BFD)* may help reduce the frequency of adjacency flaps and
   therefore reduce the associated routing churn.

Not sure if this is normative or informative, but it addresses my point.

Thx,
Robert.

On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee)  wrote:

> The WG last call has all but ended and we’ve had a lot of support, two
> implementations, and some good discussion. Please review the -05 version of
> the draft reflecting including changes reflecting this discussion. There
> was debate regarding making the delay timer described in section 5 a
> normative requirement. The consensus was to not make this a normative part
> of the specification. I feel this is the right decision – especially given
> that this is new functionality being requested at Working Group Last Call
> and implementations accomplish the dampening in vary ways.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Thursday, January 27, 2022 at 12:09 PM
> *To: *"lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

The WG last call has all but ended and we’ve had a lot of support, two 
implementations, and some good discussion. Please review the -05 version of the 
draft reflecting including changes reflecting this discussion. There was debate 
regarding making the delay timer described in section 5 a normative 
requirement. The consensus was to not make this a normative part of the 
specification. I feel this is the right decision – especially given that this 
is new functionality being requested at Working Group Last Call and 
implementations accomplish the dampening in vary ways.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org" 
Cc: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 

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

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Aijun,

A BFD session and/or neighborship going down between two DRother routers
does not impact the topology since there is no change in the Network LSA
for that LAN advertised by the DR. However, in the common scenario where a
DRother router goes down, a BFD session does help another DRother to detect
this failure and activate its FRR mechanism. Later, when the updated
Network LSA is received from the DR, the router can perform its primary
convergence. That is the use-case/benefit and so I disagree with your
comment that such sessions are useless.

This behavior is also independent of strict-mode.

We seem to be going in circles on this so perhaps we can just agree to
disagree on this point.

Thanks,
Ketan


On Tue, Feb 8, 2022 at 8:46 PM Aijun Wang  wrote:

> Hi, Ketan:
> I recommend that in Broadcast/NBMA network, the BFD session is
> bootstrapped after the DR/BDR election(but before the OSPF adjacency
> establishment). That is, only the BFD session between DRother and DR/BDR is
> checked.
> This can avoid many useless BFD sessions between DRothers and also
> accomplish your goal to assure the reliable OSPF adjacency establishment.
>
> Aijun Wang
> China Telecom
>
> 在 2022年2月8日，22:34，Ketan Talaulikar  写道：
>
> 
> Hi Aijun,
>
> The primary purpose of BFD session monitoring between two DROther routers
> is for fast detection so fast-reroute mechanisms can be triggered locally.
> This is the normal case. If such BFD sessions are not there, then there is
> a gap between the time when either the DR detects that a DROther router is
> down and then updates & floods its network LSA OR when the DRother routers
> learn the same after the dead interval. Neither of them meet the typical
> requirements of fast-reroute.
>
> There is a corner case where the DR has connectivity to the DRother
> routers but the connectivity between the DRother routers is broken (e.g.
> consider an emulated VPLS deployment). In such cases, the network LSA which
> provides the topology input for SPF will not reflect any change, but the
> adjacency between the DRother routers will remain down. However, OSPF on
> LAN depends on the mutuality of connections between routers for the DR
> mechanism to work effectively. Strict mode doesn't make much difference
> here.
>
> Thanks,
> Ketan
>
>
> On Mon, Feb 7, 2022 at 6:32 AM Aijun Wang 
> wrote:
>
>> Hi, Ketan:
>>
>>
>>
>> *From:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
>> Talaulikar
>> *Sent:* Monday, January 31, 2022 1:13 AM
>> *To:* Aijun Wang 
>> *Cc:* lsr ; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org;
>> Acee Lindem (acee) ; Albert Fu 
>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> Hi Aijun,
>>
>>
>>
>> There is a need for a BFD session to be established between neighboring
>> routers which directly forward data between them to ensure reachability
>> between them. That is my understanding of various implementations and
>> deployments at operators. This is independent of the strict mode of
>> operation.
>>
>> *[WAJ] What is the action when the BFD session between the DRothers is
>> not BROUGHT UP or DOWN then?*
>>
>>
>>
>> Perhaps you have a different requirement for "optimization of BFD
>> sessions on multi-access networks"? If so, it would be clearer if you could
>> put that requirement/proposal together as a draft for the WG to review.
>> Also, that would be in any way independent of this specification since what
>> you are referring to is the base use of BFD by OSPF.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>> On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang 
>> wrote:
>>
>> Hi, Acee and Ketan:
>>
>> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>>
>> What I want to express is that you brought up the full mesh BFD sessions
>> among the routers within such network type. Is it necessary to bring some
>> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
>> are established between the DRother and DR/BDR router?
>>
>> If the BFD session is bootstrapped after the OSPF adjacency is
>> established, there will be no such extra/useless BFD sessions
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>>
>> 
>>
>> Speaking as WG member:
>>
>>
>>
>> Hi Aijun,
>>
>> If you want a per-neighbor state and rout

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

[Muthu Arul Mozhi Perumal]

Thanks Albert..this is a useful piece of information.

Regards,
Muthu

On Wed, Feb 9, 2022 at 6:41 PM Albert Fu (BLOOMBERG/ 120 PARK) <
af...@bloomberg.net> wrote:

> Hi Muthu,
>
> We don't use virtual-links nor unnumbered links in our network.
>
> I checked the Junos and XR codes on our lab routers. I found that both do
> not support BFD over virtual-link. I believe virtual-link is not common,
> that might explain the lack of feature support.
>
> I did test OSPF BFD Strict mode for unnumbered link between Junos and XR.
> It work as per this draft, in that BFD must be operational before OSPF is
> allowed to come up. (* btw, you need to configure the hidden knob
> "backward-compatible-unnumbered-mask" on Junos router in order to interop
> OSPF unnumbered link with Cisco *).
>
> Thanks
> Albert
>
> From: ketant.i...@gmail.com At: 02/08/22 09:44:32 UTC-5:00
> To: Albert Fu (BLOOMBERG/ 120 PARK ) ,
> muthu.a...@gmail.com
> Cc: acee=40cisco@dmarc.ietf.org, lsr@ietf.org,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
> 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
>
>
> On Fri, Feb 4, 2022 at 10:52 PM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
>> 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 
>> 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.
>>>
>>> I hope that works for you.
>>>
>>> Thanks,
>>> Ketan
>>>
>>>
>>> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
>>> muthu.a...@gmail.com> wrote:
>>>
>>>> Hi Ketan,
>>>>
>>>> Thanks for your response..
>>>>
>>>> The draft says:
>>>> 
>>>>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.
>>>> 
>>>>
>>>> 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 <
>>>> ketant.i...@gmail.com> 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
>>>>>
>>>>>
>&g

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Muthu,

We don't use virtual-links nor unnumbered links in our network.

I checked the Junos and XR codes on our lab routers. I found that both do not 
support BFD over virtual-link. I believe virtual-link is not common, that might 
explain the lack of feature support.

I did test OSPF BFD Strict mode for unnumbered link between Junos and XR. It 
work as per this draft, in that BFD must be operational before OSPF is allowed 
to come up. (* btw, you need to configure the hidden knob 
"backward-compatible-unnumbered-mask" on Junos router in order to interop OSPF 
unnumbered link with Cisco *).

Thanks
Albert

From: ketant.i...@gmail.com At: 02/08/22 09:44:32 UTC-5:00To:  Albert Fu 
(BLOOMBERG/ 120 PARK ) ,  muthu.a...@gmail.com
Cc:  acee=40cisco@dmarc.ietf.org,  lsr@ietf.org,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

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


On Fri, Feb 4, 2022 at 10:52 PM Muthu Arul Mozhi Perumal  
wrote:

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

I hope that works for you.

Thanks,
Ketan


On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal  
wrote:

Hi Ketan,

Thanks for your response..

The draft says:

   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.


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  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 
 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) 
 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Ketan:
I recommend that in Broadcast/NBMA network, the BFD session is bootstrapped 
after the DR/BDR election(but before the OSPF adjacency establishment). That 
is, only the BFD session between DRother and DR/BDR is checked.
This can avoid many useless BFD sessions between DRothers and also accomplish 
your goal to assure the reliable OSPF adjacency establishment.

Aijun Wang
China Telecom

> 在 2022年2月8日，22:34，Ketan Talaulikar  写道：
> 
> 
> Hi Aijun,
> 
> The primary purpose of BFD session monitoring between two DROther routers is 
> for fast detection so fast-reroute mechanisms can be triggered locally. This 
> is the normal case. If such BFD sessions are not there, then there is a gap 
> between the time when either the DR detects that a DROther router is down and 
> then updates & floods its network LSA OR when the DRother routers learn the 
> same after the dead interval. Neither of them meet the typical requirements 
> of fast-reroute.
> 
> There is a corner case where the DR has connectivity to the DRother routers 
> but the connectivity between the DRother routers is broken (e.g. consider an 
> emulated VPLS deployment). In such cases, the network LSA which provides the 
> topology input for SPF will not reflect any change, but the adjacency between 
> the DRother routers will remain down. However, OSPF on LAN depends on the 
> mutuality of connections between routers for the DR mechanism to work 
> effectively. Strict mode doesn't make much difference here.
> 
> Thanks,
> Ketan
> 
> 
>> On Mon, Feb 7, 2022 at 6:32 AM Aijun Wang  wrote:
>> Hi, Ketan:
>> 
>>  
>> 
>> From: lsr-boun...@ietf.org  On Behalf Of Ketan 
>> Talaulikar
>> Sent: Monday, January 31, 2022 1:13 AM
>> To: Aijun Wang 
>> Cc: lsr ; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee 
>> Lindem (acee) ; Albert Fu 
>> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
>> draft-ietf-lsr-ospf-bfd-strict-mode-04
>> 
>>  
>> 
>> Hi Aijun,
>> 
>>  
>> 
>> There is a need for a BFD session to be established between neighboring 
>> routers which directly forward data between them to ensure reachability 
>> between them. That is my understanding of various implementations and 
>> deployments at operators. This is independent of the strict mode of 
>> operation.
>> 
>> [WAJ] What is the action when the BFD session between the DRothers is not 
>> BROUGHT UP or DOWN then?
>> 
>>  
>> 
>> Perhaps you have a different requirement for "optimization of BFD sessions 
>> on multi-access networks"? If so, it would be clearer if you could put that 
>> requirement/proposal together as a draft for the WG to review. Also, that 
>> would be in any way independent of this specification since what you are 
>> referring to is the base use of BFD by OSPF.
>> 
>>  
>> 
>> Thanks,
>> 
>> Ketan
>> 
>>  
>> 
>>  
>> 
>> On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang  wrote:
>> 
>> Hi, Acee and Ketan:
>> 
>> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>> 
>> What I want to express is that you brought up the full mesh BFD sessions 
>> among the routers within such network type. Is it necessary to bring some of 
>> them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency are 
>> established between the DRother and DR/BDR router?
>> 
>> If the BFD session is bootstrapped after the OSPF adjacency is established, 
>> there will be no such extra/useless BFD sessions 
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>> 
>> 
>> 
>> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>> 
>> 
>> 
>> Speaking as WG member:
>> 
>>  
>> 
>> Hi Aijun,
>> 
>> If you want a per-neighbor state and route, you have to use P2MP. This scope 
>> of this draft isn’t to try and make NBMA/Broadcast model something that it 
>> is not. This is should be common knowledge and the draft needn’t address it. 
>> Those of us who remember ATM emulated LANs (which were not always 
>> symmetrically reliable) will recall using P2MP on an inherently multi-access 
>> network.
>> 
>> Acee
>> 
>>  
>> 
>> From: Aijun Wang 
>> Date: Saturday, January 29, 2022 at 3:46 AM
>> To: 'Ketan Talaulikar' 
>> Cc: "lsr@ietf.org" , 
>> "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
>> , 'Albert Fu' 
>> , Acee Lindem 
>> Subject: RE: [Lsr] Working Group Last Call for 

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

[Ketan Talaulikar]

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


On Fri, Feb 4, 2022 at 10:52 PM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:

> 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 
> 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.
>>
>> I hope that works for you.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
>> muthu.a...@gmail.com> wrote:
>>
>>> Hi Ketan,
>>>
>>> Thanks for your response..
>>>
>>> The draft says:
>>> 
>>>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.
>>> 
>>>
>>> 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 
>>> 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 <
 muthu.a...@gmail.com> 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)  40cisco@dmarc.ietf.org> 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
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Aijun,

The primary purpose of BFD session monitoring between two DROther routers
is for fast detection so fast-reroute mechanisms can be triggered locally.
This is the normal case. If such BFD sessions are not there, then there is
a gap between the time when either the DR detects that a DROther router is
down and then updates & floods its network LSA OR when the DRother routers
learn the same after the dead interval. Neither of them meet the typical
requirements of fast-reroute.

There is a corner case where the DR has connectivity to the DRother routers
but the connectivity between the DRother routers is broken (e.g. consider
an emulated VPLS deployment). In such cases, the network LSA which provides
the topology input for SPF will not reflect any change, but the adjacency
between the DRother routers will remain down. However, OSPF on LAN depends
on the mutuality of connections between routers for the DR mechanism to
work effectively. Strict mode doesn't make much difference here.

Thanks,
Ketan


On Mon, Feb 7, 2022 at 6:32 AM Aijun Wang  wrote:

> Hi, Ketan:
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Monday, January 31, 2022 1:13 AM
> *To:* Aijun Wang 
> *Cc:* lsr ; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org;
> Acee Lindem (acee) ; Albert Fu 
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Aijun,
>
>
>
> There is a need for a BFD session to be established between neighboring
> routers which directly forward data between them to ensure reachability
> between them. That is my understanding of various implementations and
> deployments at operators. This is independent of the strict mode of
> operation.
>
> *[WAJ] What is the action when the BFD session between the DRothers is not
> BROUGHT UP or DOWN then?*
>
>
>
> Perhaps you have a different requirement for "optimization of BFD sessions
> on multi-access networks"? If so, it would be clearer if you could put that
> requirement/proposal together as a draft for the WG to review. Also, that
> would be in any way independent of this specification since what you are
> referring to is the base use of BFD by OSPF.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang 
> wrote:
>
> Hi, Acee and Ketan:
>
> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>
> What I want to express is that you brought up the full mesh BFD sessions
> among the routers within such network type. Is it necessary to bring some
> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
> are established between the DRother and DR/BDR router?
>
> If the BFD session is bootstrapped after the OSPF adjacency is
> established, there will be no such extra/useless BFD sessions
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>
> 
>
> Speaking as WG member:
>
>
>
> Hi Aijun,
>
> If you want a per-neighbor state and route, you have to use P2MP. This
> scope of this draft isn’t to try and make NBMA/Broadcast model something
> that it is not. This is should be common knowledge and the draft needn’t
> address it. Those of us who remember ATM emulated LANs (which were not
> always symmetrically reliable) will recall using P2MP on an inherently
> multi-access network.
>
> Acee
>
>
>
> *From: *Aijun Wang 
> *Date: *Saturday, January 29, 2022 at 3:46 AM
> *To: *'Ketan Talaulikar' 
> *Cc: *"lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' <
> af...@bloomberg.net>, Acee Lindem 
> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi, Ketan:
>
> OK, then back to my original question:
>
> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
> the OSPF adjacency(between the DRother and DR/BDR)?
>
> If not, then the traffic between these DRothers will be lost; If yes, it
> seems strange, because the BFD session between the DRother and DR/BDR may
> be still UP.
>
> I think here there are some mismatch between the BFD sessions and the OSPF
> adjacency in Broadcast/NBMA network, then some clarification for the
> procedures are needed.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *To:* Aijun Wang 
> *Cc

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

[Les Ginsberg (ginsberg)]

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

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) 
mailto:ginsb...@cisco.com>> wrote:
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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Ketan:

 

From: lsr-boun...@ietf.org  On Behalf Of Ketan Talaulikar
Sent: Monday, January 31, 2022 1:13 AM
To: Aijun Wang 
Cc: lsr ; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee 
Lindem (acee) ; Albert Fu 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

 

Hi Aijun,

 

There is a need for a BFD session to be established between neighboring routers 
which directly forward data between them to ensure reachability between them. 
That is my understanding of various implementations and deployments at 
operators. This is independent of the strict mode of operation.

[WAJ] What is the action when the BFD session between the DRothers is not 
BROUGHT UP or DOWN then?

 

Perhaps you have a different requirement for "optimization of BFD sessions on 
multi-access networks"? If so, it would be clearer if you could put that 
requirement/proposal together as a draft for the WG to review. Also, that would 
be in any way independent of this specification since what you are referring to 
is the base use of BFD by OSPF.

 

Thanks,

Ketan

 

 

On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Acee and Ketan:

No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.

What I want to express is that you brought up the full mesh BFD sessions among 
the routers within such network type. Is it necessary to bring some of them(the 
BFD sessions between DRothers) to DOWN after the OSPF adjacency are established 
between the DRother and DR/BDR router?

If the BFD session is bootstrapped after the OSPF adjacency is established, 
there will be no such extra/useless BFD sessions 

Aijun Wang

China Telecom





On Jan 30, 2022, at 02:45, Acee Lindem (acee) mailto:a...@cisco.com> > wrote:

 

Speaking as WG member:

 

Hi Aijun, 

If you want a per-neighbor state and route, you have to use P2MP. This scope of 
this draft isn’t to try and make NBMA/Broadcast model something that it is not. 
This is should be common knowledge and the draft needn’t address it. Those of 
us who remember ATM emulated LANs (which were not always symmetrically 
reliable) will recall using P2MP on an inherently multi-access network. 

Acee

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Date: Saturday, January 29, 2022 at 3:46 AM
To: 'Ketan Talaulikar' mailto:ketant.i...@gmail.com> >
Cc: "lsr@ietf.org <mailto:lsr@ietf.org> " mailto:lsr@ietf.org> 
>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org 
<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> " 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> >, 'Albert Fu' 
mailto:af...@bloomberg.net> >, Acee Lindem 
mailto:a...@cisco.com> >
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

 

Hi, Ketan:

OK, then back to my original question:

If one of the BFD session(between DRothers) is DOWN, will it bring DOWN the 
OSPF adjacency(between the DRother and DR/BDR)?

If not, then the traffic between these DRothers will be lost; If yes, it seems 
strange, because the BFD session between the DRother and DR/BDR may be still UP.

I think here there are some mismatch between the BFD sessions and the OSPF 
adjacency in Broadcast/NBMA network, then some clarification for the procedures 
are needed. 

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  mailto:lsr-boun...@ietf.org> > On Behalf Of Ketan Talaulikar
Sent: Saturday, January 29, 2022 4:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: lsr@ietf.org <mailto:lsr@ietf.org> ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org 
<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> ; Albert Fu 
mailto:af...@bloomberg.net> >; Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org> >
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

 

Hi Aijun,

 

The choice of the term "adjacency" was not accurate in my previous response to 
you. I meant "neighborship". 

 

That said, the substance of my response still remains the same.

 

Thanks,

Ketan

 

 

On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

For the Broadcast/NMBA network type, if you establish BFD sessions before 
the DR/BDR selection, then there will be full mesh BFD sessions within the 
routers on such media type? 

Instead of establishing the BFD sessions with DR/BDR only, the same as the OSPF 
adjacency relationship? If so, if one of the BFD session that not with the 
DR/BDR is DOWN, what’s the action then?

 

KT> I think there is perhaps a misunderstanding of the purpose of BFD use with 
OSPF. Perhaps a careful reading of RFC5882

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

[Robert Raszuk]

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) 
wrote:

> 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*
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Chris

On Sun, Feb 6, 2022 at 5:30 PM Christian Hopps  wrote:

>
> Robert Raszuk  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.
> >
> >
> > 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).
>
> If you publish an RFC that adds to or extends the BFD "UP" concept then it
> 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.



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


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

>
>
> Thanks,
> Chris.
> [as wg member]
>
> >
> > 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.
> >
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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  wrote:

>
> Robert Raszuk  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.
> >
> >
> > 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).
>
> 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]
>
> >
> > 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.
> >
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Les

On Sun, Feb 6, 2022 at 5:05 PM Les Ginsberg (ginsberg)  wrote:

> Robert –
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, February 6, 2022 10:42 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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.
>
> *[LES:] This is specifying the BFD State Machine and signaling between BFD
> peers – not signaling between BFD and its local clients.*
>

  Gyan> Agreed

> *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.”*
>
> * 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.*
>
> *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.*
>
> * Gyan> Agreed.  Makes sense.*
>
> *   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:
>
>
>
>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.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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) 
wrote:

> Robert –
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, February 6, 2022 10:42 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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.
>


> *[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*
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

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


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


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]



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.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Robert –


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

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


   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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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.

>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

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  wrote:

> 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
>
>
>
> On Sun, Feb 6, 2022 at 6:24 PM Gyan Mishra  wrote:
>
>> Hi Robert
>>
>> On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk  wrote:
>>
>>> 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.
>>>
>>
>> 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 

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

[Les Ginsberg (ginsberg)]

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  On Behalf Of Robert Raszuk
Sent: Sunday, February 6, 2022 5:11 AM
To: Acee Lindem (acee) 
Cc: Ketan Talaulikar ; Gyan Mishra 
; lsr@ietf.org
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.

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) 
mailto:a...@cisco.com>> 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 mailto:rob...@raszuk.net>>
Date: Sunday, February 6, 2022 at 6:11 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>
Cc: Acee Lindem mailto:a...@cisco.com>>, Ketan Talaulikar 
mailto:ketant.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
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

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.



On Sun, Feb 6, 2022 at 8:16 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> 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 probl

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

[Robert Raszuk]

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



On Sun, Feb 6, 2022 at 6:24 PM Gyan Mishra  wrote:

> Hi Robert
>
> On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk  wrote:
>
>> 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.
>>
>
> 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 

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

[Gyan Mishra]

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  wrote:

> Hi Robert
>
> On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk  wrote:
>
>> 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.
>>
>
> 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 

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

[Gyan Mishra]

Hi Robert

On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk  wrote:

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

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 

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

[Robert Raszuk]

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)  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 
> *Date: *Sunday, February 6, 2022 at 6:11 AM
> *To: *Gyan Mishra 
> *Cc: *Acee Lindem , Ketan Talaulikar <
> ketant.i...@gmail.com>, "lsr@ietf.org" 
> *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
>
>
>
> 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.
>
>
>
>
>
>
>
> On Sun, Feb 6, 2022 at 8:16 AM Gyan Mishra  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
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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 
Date: Sunday, February 6, 2022 at 6:11 AM
To: Gyan Mishra 
Cc: Acee Lindem , Ketan Talaulikar , 
"lsr@ietf.org" 
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

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.



On Sun, Feb 6, 2022 at 8:16 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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.



On Sun, Feb 6, 2022 at 8:16 AM Gyan Mishra  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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

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  wrote:

>
> 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)  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 
>> *Date: *Friday, February 4, 2022 at 12:48 PM
>> *To: *Muthu Arul Mozhi Perumal 
>> *Cc: *Ketan Talaulikar , "lsr@ietf.org" <
>> lsr@ietf.org>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, Acee Lindem <
>> a...@cisco.com>
>> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> 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 <
>> muthu.a...@gmail.com> wrote:
>>
>> 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 
>> 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.
>>
>>
>>
>> I hope that works for you.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
>> muthu.a...@gmail.com> wrote:
>>
>> Hi Ketan,
>>
>>
>>
>> Thanks for your response..
>>
>>
>>
>> The draft says:
>>
>> 
>>
>>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 isenabled on the link* and that the router
>> requests strict-mode for BFD.
>>
>> 
>>
>>
>>
>> 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
>

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

[Robert Raszuk]

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)  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 
> *Date: *Friday, February 4, 2022 at 12:48 PM
> *To: *Muthu Arul Mozhi Perumal 
> *Cc: *Ketan Talaulikar , "lsr@ietf.org" <
> lsr@ietf.org>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, Acee Lindem  >
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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 <
> muthu.a...@gmail.com> wrote:
>
> 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 
> 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.
>
>
>
> I hope that works for you.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
> Hi Ketan,
>
>
>
> Thanks for your response..
>
>
>
> The draft says:
>
> 
>
>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 isenabled on the link* and that the router
> requests strict-mode for BFD.
>
> 
>
>
>
> 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 
> 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 <
> muthu.a...@gmail.com> 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)  40cisco@dmarc.ietf.org> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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 
Date: Friday, February 4, 2022 at 12:48 PM
To: Muthu Arul Mozhi Perumal 
Cc: Ketan Talaulikar , "lsr@ietf.org" , 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
, Acee Lindem 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

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 
mailto:muthu.a...@gmail.com>> wrote:
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 
mailto:ketant.i...@gmail.com>> 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.

I hope that works for you.

Thanks,
Ketan


On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>> wrote:
Hi Ketan,

Thanks for your response..

The draft says:

   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.


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 
mailto:ketant.i...@gmail.com>> 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 
mailto:muthu.a...@gmail.com>> 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) 
mailto:40cisco@dmarc.ietf.org>> 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
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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 <
muthu.a...@gmail.com> wrote:

> 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 
> 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.
>>
>> I hope that works for you.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
>> muthu.a...@gmail.com> wrote:
>>
>>> Hi Ketan,
>>>
>>> Thanks for your response..
>>>
>>> The draft says:
>>> 
>>>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.
>>> 
>>>
>>> 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 
>>> 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 <
 muthu.a...@gmail.com> 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)  40cisco@dmarc.ietf.org> 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
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Muthu Arul Mozhi Perumal]

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 
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.
>
> I hope that works for you.
>
> Thanks,
> Ketan
>
>
> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com> wrote:
>
>> Hi Ketan,
>>
>> Thanks for your response..
>>
>> The draft says:
>> 
>>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.
>> 
>>
>> 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 
>> 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 <
>>> muthu.a...@gmail.com> 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) >>> 40cisco@dmarc.ietf.org> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

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 <
muthu.a...@gmail.com> wrote:

> Hi Ketan,
>
> Thanks for your response..
>
> The draft says:
> 
>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.
> 
>
> 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 
> 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 <
>> muthu.a...@gmail.com> 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) >> 40cisco@dmarc.ietf.org> 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
 Lsr@ietf.org
 https://www.ietf.org/mailman/listinfo/lsr

>>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Muthu Arul Mozhi Perumal]

On Thu, Feb 3, 2022 at 10:14 PM Acee Lindem (acee)  wrote:

> Hi Ketan,
>
> Do you remember who this comment came from?  I definitely think anyone who
> reads the abstract of the draft wouldn’t be confused and don’t agree with
> the comment.
>
>
>
> Also, this is meant to be a per-interface sub-option of the existing BFD
> configuration – right?
>

That's why I was asking whether multi-hop BFD is in scope (multi-hop BFD is
not enabled per interface). If so, then some suggestions:
https://mailarchive.ietf.org/arch/msg/lsr/wffR6A6Vq-wtKYPiLE2wuVyJDNY/

Regards,
Muthu


> There is at least one place that would lead one to believe it is pre-node.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Thursday, February 3, 2022 at 10:31 AM
> *To: *Acee Lindem 
> *Cc: *"Acee Lindem (acee)" , "
> lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Acee,
>
>
>
> The authors had picked the term "*OSPF BFD Strict-Mode*" originally -
> please refer to
> https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode-01.
> However, post IETF presentation, we got feedback from WG members that the
> term was misleading and gave an impression that the proposal was
> introducing a "strict-mode" in BFD. What we are doing is introducing a
> "strict-mode" of operation in OSPF for BFD usage.
>
>
>
> We are open to any suggestions for change/clarity.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Thu, Feb 3, 2022 at 2:07 AM Acee Lindem (acee)  wrote:
>
> Speaking as Document Shepherd:
>
>
>
> I have some editorial comments that I will pass on to the authors offline.
> One change I didn’t suggest since it was a big change was from “Strict-Mode
> for BFD” to simply “BFD Strict-Mode”. What are your thoughts on this?
>
>
>
> We’ve had some good discussion and an updated version is coming with some
> updates based on that discussion. Remember that we don’t necessarily have
> to incorporate every suggested change but simply need to conclude the
> discussion.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *"Acee Lindem (acee)" 
> *Date: *Friday, January 28, 2022 at 7:24 AM
> *To: *Acee Lindem , "lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Speaking as WG member:
>
>
>
> I support publication of the document. As indicated by the Albert Fu, it
> has been implemented by two vendors. I will provide WG Last Call comments
> when I prepare the Shepherd’s report.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Thursday, January 27, 2022 at 12:09 PM
> *To: *"lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Robert,

We were comparing OSPF and BGP and so it was the protocol FSMs. So we are
in sync on that part.

Thanks,
Ketan


On Tue, Feb 1, 2022 at 1:43 PM Robert Raszuk  wrote:

> Ketan,
>
>
>> What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where
>> even though the BFD session is established the protocol FSM does not
>> proceed further until a period of time has passed to ensure the stability
>> of the BFD session.
>>
>
> Which protocol FSM ? BFD FSM or OSPF FSM ?
>
> If BFD FSM then I think this is a false assumption or perhaps based on
> specific implementation. If OSPF FSM then we are all in sync.
>
> See the point being is that the BFD session UP the draft is referring to
> as a trigger for OSPF adj to come UP does not mean anything yet about
> path liveness (except proving that BFD control packets made it to a peer -
> depending on BFD mode of operation). So reacting on it immediately by any
> client would be a wrong thing to do.  I see nothing in section 6.2 of
> RFC5880 which would indicate any hold time or which would block BFD state
> transition to UP waiting for even single BFD Echo packet to be exchanged.
>
> BFD probing interval can be set to 2 sec and multiplier set to 3 which
> would mean that only after 6 sec from BFD UP state you would get some
> meaningful data about the link letting BFD Echo packets to get exchanged.
> If you bring OSPF adj. UP immediately after seeing BFD session UP you have
> not accomplished anything what wait-for-bfd is trying to do. With that I
> actually think the draft in the current form as stated in section 4 is
> harmful - it only mentions to wait for BFD session to get established.
>
> All along I was trying to highlight that point. And let me self correct
> one thing I said earlier ... In one of the emails to Albert I mentioned
> that such timer could be 0. Well not really - the min amount of time
> between BFD UP and OSPF adj. UP should be: (BFD probing interval x
> multiplier) + time it takes on a given platform to sent messages between
> LCs and RE/RP.
>
> Regards,
> Robert.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Searching the draft there are actually a lot of “Strict-Mode for BFD” w/o 
“OSPF” preceding it.

I agree w Acee’s suggestion – always use “OSPF BFD Strict-Mode”.

Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Thursday, February 3, 2022 9:57 AM
To: Ketan Talaulikar 
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee Lindem 
(acee) 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan,

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Thursday, February 3, 2022 at 12:41 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee,

I do not remember the persons (it was more than one) who provided this comment.

We will make the following changes (unless there are any objections):

s/ OSPF Strict-Mode for BFD/ OSPF BFD Strict-Mode
s/ Strict-Mode for BFD / BFD Strict-Mode
similar ...

I wouldn’t think there would be many of the latter. Perhaps, you could always 
use “OSPF BFD Strict-Mode” to avoid any confusion.

Thanks,
Ketan


On Thu, Feb 3, 2022 at 10:13 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,
Do you remember who this comment came from?  I definitely think anyone who 
reads the abstract of the draft wouldn’t be confused and don’t agree with the 
comment.

Also, this is meant to be a per-interface sub-option of the existing BFD 
configuration – right? There is at least one place that would lead one to 
believe it is pre-node.

Thanks,
Acee

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Thursday, February 3, 2022 at 10:31 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee,

The authors had picked the term "OSPF BFD Strict-Mode" originally - please 
refer to 
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode-01. 
However, post IETF presentation, we got feedback from WG members that the term 
was misleading and gave an impression that the proposal was introducing a 
"strict-mode" in BFD. What we are doing is introducing a "strict-mode" of 
operation in OSPF for BFD usage.

We are open to any suggestions for change/clarity.

Thanks,
Ketan


On Thu, Feb 3, 2022 at 2:07 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as Document Shepherd:

I have some editorial comments that I will pass on to the authors offline. One 
change I didn’t suggest since it was a big change was from “Strict-Mode for 
BFD” to simply “BFD Strict-Mode”. What are your thoughts on this?

We’ve had some good discussion and an updated version is coming with some 
updates based on that discussion. Remember that we don’t necessarily have to 
incorporate every suggested change but simply need to conclude the discussion.

Thanks,
Acee

From: "Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Friday, January 28, 2022 at 7:24 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Speaking as WG member:

I support publication of the document. As indicated by the Albert Fu, it has 
been implemented by two vendors. I will provide WG Last Call comments when I 
prepare the Shepherd’s report.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m..

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

[Acee Lindem (acee)]

Hi Ketan,

From: Ketan Talaulikar 
Date: Thursday, February 3, 2022 at 12:41 PM
To: Acee Lindem 
Cc: "Acee Lindem (acee)" , "lsr@ietf.org" 
, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 

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

Hi Acee,

I do not remember the persons (it was more than one) who provided this comment.

We will make the following changes (unless there are any objections):

s/ OSPF Strict-Mode for BFD/ OSPF BFD Strict-Mode
s/ Strict-Mode for BFD / BFD Strict-Mode
similar ...

I wouldn’t think there would be many of the latter. Perhaps, you could always 
use “OSPF BFD Strict-Mode” to avoid any confusion.

Thanks,
Ketan


On Thu, Feb 3, 2022 at 10:13 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,
Do you remember who this comment came from?  I definitely think anyone who 
reads the abstract of the draft wouldn’t be confused and don’t agree with the 
comment.

Also, this is meant to be a per-interface sub-option of the existing BFD 
configuration – right? There is at least one place that would lead one to 
believe it is pre-node.

Thanks,
Acee

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Thursday, February 3, 2022 at 10:31 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee,

The authors had picked the term "OSPF BFD Strict-Mode" originally - please 
refer to 
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode-01. 
However, post IETF presentation, we got feedback from WG members that the term 
was misleading and gave an impression that the proposal was introducing a 
"strict-mode" in BFD. What we are doing is introducing a "strict-mode" of 
operation in OSPF for BFD usage.

We are open to any suggestions for change/clarity.

Thanks,
Ketan


On Thu, Feb 3, 2022 at 2:07 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as Document Shepherd:

I have some editorial comments that I will pass on to the authors offline. One 
change I didn’t suggest since it was a big change was from “Strict-Mode for 
BFD” to simply “BFD Strict-Mode”. What are your thoughts on this?

We’ve had some good discussion and an updated version is coming with some 
updates based on that discussion. Remember that we don’t necessarily have to 
incorporate every suggested change but simply need to conclude the discussion.

Thanks,
Acee

From: "Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Friday, January 28, 2022 at 7:24 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Speaking as WG member:

I support publication of the document. As indicated by the Albert Fu, it has 
been implemented by two vendors. I will provide WG Last Call comments when I 
prepare the Shepherd’s report.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Acee,

I do not remember the persons (it was more than one) who provided this
comment.

We will make the following changes (unless there are any objections):

s/ OSPF Strict-Mode for BFD/ OSPF BFD Strict-Mode
s/ Strict-Mode for BFD / BFD Strict-Mode
similar ...

Thanks,
Ketan


On Thu, Feb 3, 2022 at 10:13 PM Acee Lindem (acee)  wrote:

> Hi Ketan,
>
> Do you remember who this comment came from?  I definitely think anyone who
> reads the abstract of the draft wouldn’t be confused and don’t agree with
> the comment.
>
>
>
> Also, this is meant to be a per-interface sub-option of the existing BFD
> configuration – right? There is at least one place that would lead one to
> believe it is pre-node.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Thursday, February 3, 2022 at 10:31 AM
> *To: *Acee Lindem 
> *Cc: *"Acee Lindem (acee)" , "
> lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Acee,
>
>
>
> The authors had picked the term "*OSPF BFD Strict-Mode*" originally -
> please refer to
> https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode-01.
> However, post IETF presentation, we got feedback from WG members that the
> term was misleading and gave an impression that the proposal was
> introducing a "strict-mode" in BFD. What we are doing is introducing a
> "strict-mode" of operation in OSPF for BFD usage.
>
>
>
> We are open to any suggestions for change/clarity.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Thu, Feb 3, 2022 at 2:07 AM Acee Lindem (acee)  wrote:
>
> Speaking as Document Shepherd:
>
>
>
> I have some editorial comments that I will pass on to the authors offline.
> One change I didn’t suggest since it was a big change was from “Strict-Mode
> for BFD” to simply “BFD Strict-Mode”. What are your thoughts on this?
>
>
>
> We’ve had some good discussion and an updated version is coming with some
> updates based on that discussion. Remember that we don’t necessarily have
> to incorporate every suggested change but simply need to conclude the
> discussion.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *"Acee Lindem (acee)" 
> *Date: *Friday, January 28, 2022 at 7:24 AM
> *To: *Acee Lindem , "lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Speaking as WG member:
>
>
>
> I support publication of the document. As indicated by the Albert Fu, it
> has been implemented by two vendors. I will provide WG Last Call comments
> when I prepare the Shepherd’s report.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Thursday, January 27, 2022 at 12:09 PM
> *To: *"lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Ketan,
Do you remember who this comment came from?  I definitely think anyone who 
reads the abstract of the draft wouldn’t be confused and don’t agree with the 
comment.

Also, this is meant to be a per-interface sub-option of the existing BFD 
configuration – right? There is at least one place that would lead one to 
believe it is pre-node.

Thanks,
Acee

From: Ketan Talaulikar 
Date: Thursday, February 3, 2022 at 10:31 AM
To: Acee Lindem 
Cc: "Acee Lindem (acee)" , "lsr@ietf.org" 
, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 

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

Hi Acee,

The authors had picked the term "OSPF BFD Strict-Mode" originally - please 
refer to 
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode-01. 
However, post IETF presentation, we got feedback from WG members that the term 
was misleading and gave an impression that the proposal was introducing a 
"strict-mode" in BFD. What we are doing is introducing a "strict-mode" of 
operation in OSPF for BFD usage.

We are open to any suggestions for change/clarity.

Thanks,
Ketan


On Thu, Feb 3, 2022 at 2:07 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as Document Shepherd:

I have some editorial comments that I will pass on to the authors offline. One 
change I didn’t suggest since it was a big change was from “Strict-Mode for 
BFD” to simply “BFD Strict-Mode”. What are your thoughts on this?

We’ve had some good discussion and an updated version is coming with some 
updates based on that discussion. Remember that we don’t necessarily have to 
incorporate every suggested change but simply need to conclude the discussion.

Thanks,
Acee

From: "Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Friday, January 28, 2022 at 7:24 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Speaking as WG member:

I support publication of the document. As indicated by the Albert Fu, it has 
been implemented by two vendors. I will provide WG Last Call comments when I 
prepare the Shepherd’s report.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Acee,

The authors had picked the term "OSPF BFD Strict-Mode" originally - please
refer to
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode-01.
However, post IETF presentation, we got feedback from WG members that the
term was misleading and gave an impression that the proposal was
introducing a "strict-mode" in BFD. What we are doing is introducing a
"strict-mode" of operation in OSPF for BFD usage.

We are open to any suggestions for change/clarity.

Thanks,
Ketan


On Thu, Feb 3, 2022 at 2:07 AM Acee Lindem (acee)  wrote:

> Speaking as Document Shepherd:
>
>
>
> I have some editorial comments that I will pass on to the authors offline.
> One change I didn’t suggest since it was a big change was from “Strict-Mode
> for BFD” to simply “BFD Strict-Mode”. What are your thoughts on this?
>
>
>
> We’ve had some good discussion and an updated version is coming with some
> updates based on that discussion. Remember that we don’t necessarily have
> to incorporate every suggested change but simply need to conclude the
> discussion.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *"Acee Lindem (acee)" 
> *Date: *Friday, January 28, 2022 at 7:24 AM
> *To: *Acee Lindem , "lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Speaking as WG member:
>
>
>
> I support publication of the document. As indicated by the Albert Fu, it
> has been implemented by two vendors. I will provide WG Last Call comments
> when I prepare the Shepherd’s report.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Thursday, January 27, 2022 at 12:09 PM
> *To: *"lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Speaking as Document Shepherd:

I have some editorial comments that I will pass on to the authors offline. One 
change I didn’t suggest since it was a big change was from “Strict-Mode for 
BFD” to simply “BFD Strict-Mode”. What are your thoughts on this?

We’ve had some good discussion and an updated version is coming with some 
updates based on that discussion. Remember that we don’t necessarily have to 
incorporate every suggested change but simply need to conclude the discussion.

Thanks,
Acee

From: "Acee Lindem (acee)" 
Date: Friday, January 28, 2022 at 7:24 AM
To: Acee Lindem , "lsr@ietf.org" 
Cc: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 

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

Speaking as WG member:

I support publication of the document. As indicated by the Albert Fu, it has 
been implemented by two vendors. I will provide WG Last Call comments when I 
prepare the Shepherd’s report.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org" 
Cc: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 

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

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Muthu Arul Mozhi Perumal]

Hi Ketan,

Thanks for your response..

The draft says:

   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.


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 
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 <
> muthu.a...@gmail.com> 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) > 40cisco@dmarc.ietf.org> 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
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Ketan,


> What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where
> even though the BFD session is established the protocol FSM does not
> proceed further until a period of time has passed to ensure the stability
> of the BFD session.
>

Which protocol FSM ? BFD FSM or OSPF FSM ?

If BFD FSM then I think this is a false assumption or perhaps based on
specific implementation. If OSPF FSM then we are all in sync.

See the point being is that the BFD session UP the draft is referring to as
a trigger for OSPF adj to come UP does not mean anything yet about
path liveness (except proving that BFD control packets made it to a peer -
depending on BFD mode of operation). So reacting on it immediately by any
client would be a wrong thing to do.  I see nothing in section 6.2 of
RFC5880 which would indicate any hold time or which would block BFD state
transition to UP waiting for even single BFD Echo packet to be exchanged.

BFD probing interval can be set to 2 sec and multiplier set to 3 which
would mean that only after 6 sec from BFD UP state you would get some
meaningful data about the link letting BFD Echo packets to get exchanged.
If you bring OSPF adj. UP immediately after seeing BFD session UP you have
not accomplished anything what wait-for-bfd is trying to do. With that I
actually think the draft in the current form as stated in section 4 is
harmful - it only mentions to wait for BFD session to get established.

All along I was trying to highlight that point. And let me self correct one
thing I said earlier ... In one of the emails to Albert I mentioned that
such timer could be 0. Well not really - the min amount of time between BFD
UP and OSPF adj. UP should be: (BFD probing interval x multiplier) + time
it takes on a given platform to sent messages between LCs and RE/RP.

Regards,
Robert.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi All,

The authors will work on and share the updated text to review with the WG.

Quickly want to point out that the draft does not bring any new
requirements in BFD for link quality monitoring; the stability issues that
we are discussing are related to BFD sessions going down due to
intermittent packet loss. If/when BFD WG brings any new enhancements,
protocols like OSPF will obviously leverage the same.

Thanks,
Ketan


On Tue, Feb 1, 2022 at 1:59 AM Jeffrey Haas  wrote:

> Les,
>
>
> On Jan 31, 2022, at 2:47 PM, Les Ginsberg (ginsberg) 
> wrote:
> I have not asked for BFD extensions.
> I have stated that “IF” additional functionality is required from BFD that
> the proper place to discuss that is in the BFD WG – and such discussions
> are definitely not in scope of this draft.
>
>
> Agreed.
>
>
> The main content of this lengthy thread is Robert asking for additional
> specification in this draft and other folks (myself, Albert, Ketan) saying
> it doesn’t belong in this draft. Which is why I agree with everything you
> say below except for your perception that you are agreeing with Robert. You
> are actually agreeing with myself, Albert, Ketan. 
>
>
> I was largely agreeing with Robert about the state of BFD and how it
> likely impacts the OSPF feature.  BFD isn't helpful beyond the Up/Down
> signaling, how it handles too much noise, etc.  So, I think we're all in
> agreement about these things.
>
> What the protocol chooses to do about the signaling BFD provides is up to
> the protocol. I think we're all agreeing that the strict mode helps with
> making sure implementations use the inputs to their state machines
> consistently.
>
> Whether there's any sort of "pause button" used by the implementation once
> the ordering is agreed upon seems to be where the disagreements have been.
> Such a pause button isn't appropriate for BFD.
>
> And now we're fully in sync. :-)
>
> -- Jeff
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Robert,

The comparison between the BFD strict-mode of operation proposals for OSPF
and BGP are not directly comparable since their FSMs are different. In
OSPF, the FSM is going to wait indefinitely in Init state until the BFD
session is set up, while that is not the case for BGP and hence BGP needs
the "BGP BFD Hold time" to close/restart the neighbor FSM.

Please correct me if I am reading this wrong.

What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where
even though the BFD session is established the protocol FSM does not
proceed further until a period of time has passed to ensure the stability
of the BFD session.

Thanks,
Ketan


On Mon, Jan 31, 2022 at 8:29 PM Robert Raszuk  wrote:

> Les & Ketan
>
>
>> Nowadays, it is also common to see the "break-in-middle" failures. we use
>> BFD to detect this sort of failure within sub-second. And to dampen this
>> sort of break-in-middle failures, we will need to use BFD
>> holdtime/dampening.
>>
>
> Another data point to the above and this discussion which Albert is
> co-author of.
>
> Ref:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode
>
> Please see the below paragraph which clearly says *BGP BFD Hold time*:
>
>If the BFD session does not transition to the Up state, and the
>HoldTimer has been negotiated to a non-zero value, the BGP FSM will
>close the session appropriately.  If the HoldTimer has been
>negotiated to a zero value, the session should be closed after a time
>of X.  This time X is referred as "BGP BFD Hold time".  The proposed
>default BGP BFD Hold time value is 30 seconds.  The BGP BFD Hold time
>value is configurable.
>
> To me it is clear that BGP BFD Hold time is on the client side and here
> affects BGP FSM.
>
> Thx,
> Robert.
>
>
>
>
>
>
>
> From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00
>> To: rob...@raszuk.net, ketant.i...@gmail.com
>> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) ,
>> a...@cisco.com, draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,
>> lsr@ietf.org
>> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
>> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>> Robert –
>>
>>
>>
>> Here is what you said (emphasis added):
>>
>>
>>
>> 
>>
>> 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.
>>
>> 
>>
>>
>>
>> Point #1: If you want BFD to do more testing (such as MTU testing) then
>> clearly you need extensions to BFD (such as
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )
>>
>>
>>
>> Point #2: The existing timers (as Ketan points out are mentioned in
>> Section 5) are applied today at the OSPF level precisely because OSPF does
>> not currently have strict-mode operation. So in a flapping scenario you
>> could see the following behavior:
>>
>>
>>
>> a)BFD goes down
>>
>> b)OSPF goes down in response to BFD
>>
>> c)OSPF comes back up
>>
>> d)Link is still unstable – so traffic is being dropped some of the time –
>> but perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often
>> enough to keep the OSPF adjacency up)
>>
>>
>>
>> So some implementations have chosen to insert a delay following “b”. This
>> doesn’t guarantee stability, but hopefully makes it less likely. And
>> because OSPF today does NOT wait for BFD to come up, the delay has to be
>> implemented at the OSPF level.
>>
>>
>>
>> Once you have strict mode support, the sequence becomes:
>>
>>
>>
>> a)BFD goes down
>>
>> b)OSPF goes down in response to BFD
>>
>> c)BFD comes back up
>>
>> d)OSPF comes back up
>>
>>
>>
>> Now, if the concern is that BFD comes back up while the link is still
>> unstable, the way to address that is to put a delay either before BFD
>> attempts to bring up a new session or a delay after achieving UP state
>> before it signals UP to its clients – such as OSPF. This is a better
>> solution because all BFD clients benefit from this. Ad if the link is still
>> unstable, it is more likely that the BFD session will go down during the
>> delay period than it would be for OSPF because the BFD timers

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

[Jeffrey Haas]

Les,


> On Jan 31, 2022, at 2:47 PM, Les Ginsberg (ginsberg)  
> wrote:
> I have not asked for BFD extensions.
> I have stated that “IF” additional functionality is required from BFD that 
> the proper place to discuss that is in the BFD WG – and such discussions are 
> definitely not in scope of this draft.

Agreed.

>  
> The main content of this lengthy thread is Robert asking for additional 
> specification in this draft and other folks (myself, Albert, Ketan) saying it 
> doesn’t belong in this draft. Which is why I agree with everything you say 
> below except for your perception that you are agreeing with Robert. You are 
> actually agreeing with myself, Albert, Ketan. 

I was largely agreeing with Robert about the state of BFD and how it likely 
impacts the OSPF feature.  BFD isn't helpful beyond the Up/Down signaling, how 
it handles too much noise, etc.  So, I think we're all in agreement about these 
things.

What the protocol chooses to do about the signaling BFD provides is up to the 
protocol. I think we're all agreeing that the strict mode helps with making 
sure implementations use the inputs to their state machines consistently.

Whether there's any sort of "pause button" used by the implementation once the 
ordering is agreed upon seems to be where the disagreements have been.  Such a 
pause button isn't appropriate for BFD.  

And now we're fully in sync. :-)

-- Jeff

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hey Albert,

Ok now we are in sync as far as what is the topic.

I think such a delay is very useful and completely in the spirit of OSPF or
ISIS strict-mode operation.

So I do recommend that the draft should discuss it.

The default can be 0 if you think that is the proper value. But the
operational section of that draft IMO is exactly the place where such
paragraph should be placed. Maybe I would not be so persistent in this
little thread if Les wouldn't indicate that current timer will be removed
(current timer acting as an artificial delay and being much longer then
time needed for BFD to come UP).

Author's choice. My mission is accomplished here for the WG mailing list
records :)

Cheers,
Robert.



On Mon, Jan 31, 2022 at 9:04 PM Albert Fu (BLOOMBERG/ 120 PARK) <
af...@bloomberg.net> wrote:

> Hi Robert,
>
> As mentioned in my previous email, I feel it is better not to specify in
> the draft the timer for when OSPF should come up after BFD is up.
>
> The current implementation is for OSPF to come up as soon as BFD is up. A
> user can change this behaviour via configuration, to delay when OSPF can
> come up after BFD is up. Different customers may have different delay
> requirements, and there may also be platform dependent limitation.
>
> Thanks
>
> Albert
>
> From: rob...@raszuk.net At: 01/31/22 14:52:43 UTC-5:00
> To: Albert Fu (BLOOMBERG/ 120 PARK ) 
> Cc: a...@cisco.com, draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,
> ginsb...@cisco.com, ketant.i...@gmail.com, lsr@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
> Hi Albert,
>
> On Mon, Jan 31, 2022 at 8:38 PM Albert Fu (BLOOMBERG/ 120 PARK) <
> af...@bloomberg.net> wrote:
>
>> Hi Robert,
>>
>> Do you mean we should make it mandatory in the draft to stipulate a delay
>> time between when OSPF should wait for BFD to come up?
>>
>
> No.
>
> The timer is for OSPF to bring adj up only after X timer expires from the
> moment BFD session came up and stayed up (never went down).
>
> No changes to BFD needed at all.
>
> Trivial to implement on the client side and very useful operationally.
>
> Thx,
> Robert
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

> I have stated that “IF” additional functionality is required from BFD

No one says so,
[LES:] Good. Can we end this thread then?
[
   Les
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Robert,

As mentioned in my previous email, I feel it is better not to specify in the 
draft the timer for when OSPF should come up after BFD is up. 

The current implementation is for OSPF to come up as soon as BFD is up. A user 
can change this behaviour via configuration, to delay when OSPF can come up 
after BFD is up. Different customers may have different delay requirements, and 
there may also be platform dependent limitation.

Thanks

Albert

From: rob...@raszuk.net At: 01/31/22 14:52:43 UTC-5:00To:  Albert Fu 
(BLOOMBERG/ 120 PARK ) 
Cc:  a...@cisco.com,  draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  
ginsb...@cisco.com,  ketant.i...@gmail.com,  lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Albert,
On Mon, Jan 31, 2022 at 8:38 PM Albert Fu (BLOOMBERG/ 120 PARK) 
 wrote:

Hi Robert,

Do you mean we should make it mandatory in the draft to stipulate a delay time 
between when OSPF should wait for BFD to come up?

No. 

The timer is for OSPF to bring adj up only after X timer expires from the 
moment BFD session came up and stayed up (never went down). 

No changes to BFD needed at all. 

Trivial to implement on the client side and very useful operationally. 

Thx,
Robert


 
I don't know how others feel, but I tend to agree the main author of this 
Draft, Ketan, that it is best to leave the delay timer out of this draft. 

There is already an implicit understanding that BFD must be up before OSPF can 
progress to the adjacency phase.

And I can think of deployments with many redundant links where the delay can be 
large value, and some scenario say sites with only 1 redundant link where it is 
not desirable for the delay not to be too lengthy, to avoid both links being 
down at the same time and cutting communication to the site completely.

I have also tested current implementations where the delays do not have to 
match (e.g. one side with delay, and one side no delay).

IMO, it is better not to make the delay a part of the standard.

Thanks

Albert


From: rob...@raszuk.net At: 01/31/22 13:51:56 UTC-5:00To:  Albert Fu 
(BLOOMBERG/ 120 PARK ) 
Cc:  ginsb...@cisco.com,  ketant.i...@gmail.com,  a...@cisco.com,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Albert,

> It serves as a sanity check that there's indeed a working 
> BFD for a period of time before OSPF adjacency is allowed 
> to progress.

And that is precisely what I am suggesting that should be both mandatory and 
part of this draft. Not an optional nice to have vendor knob. 

Clearly it does not belong to BFD spec or WG what Les and Ketan are trying to 
suggest. 

Regards,
R.


On Mon, Jan 31, 2022 at 6:52 PM Albert Fu (BLOOMBERG/ 120 PARK) 
 wrote:

Hi Robert,

The BGP BFD hold-time mentioned in the BGP BFD strict mode draft has different 
meaning from the holdtime/delay/dampening that has been discussed in this forum 
thus far. 

The BGP BFD hold-time, as per the BGP BFD draft below, is user configurable, 
and is used to bring down the BGP session if BFD session is not established 
within default of 30s, when the negotiated "BGP HoldTimer" is 0. 


The OSPF hold-time/delay/dampening that we have been discussing so far is the 
delay from when BFD comes up to when OSPF will be allowed to come up. This, as 
Ketan mentioned, is outside the scope of this draft. 

In my testing with both Cisco and Juniper implementation, the OSPF 
hold-time/delay/dampening timers are quite arbitrary. You could have no delay 
(which means bring up OSPF asap), or have it configured on one side only. It 
serves as a sanity check that there's indeed a working BFD for a period of time 
before OSPF adjacency is allowed to progress.

Thanks

Albert

From: rob...@raszuk.net At: 01/31/22 09:59:48 UTC-5:00To:  Albert Fu 
(BLOOMBERG/ 120 PARK ) ,  ginsb...@cisco.com,  ketant.i...@gmail.com
Cc:  a...@cisco.com,  draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  
lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Les & Ketan
 
Nowadays, it is also common to see the "break-in-middle" failures. we use BFD 
to detect this sort of failure within sub-second. And to dampen this sort of 
break-in-middle failures, we will need to use BFD holdtime/dampening. 


Another data point to the above and this discussion which Albert is co-author 
of. 

Ref: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode

Please see the below paragraph which clearly says BGP BFD Hold time: 

   If the BFD session does not transition to the Up state, and the
   HoldTimer has been negotiated to a non-zero value, the BGP FSM will
   close the session appropriately.  If the HoldTimer has been
   negotiated to a zero value, 

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

[Robert Raszuk]

> I have stated that “IF” additional functionality is required from BFD

No one says so, It would be not realistic to require for BFD to come up in
a hidden mode, operate for timer X then when timer X expires signal that to
clients. And this is precisely what you are suggesting as a push back.

It is client thing to delay their action according to the operational
needs.

Many thx,
R.

On Mon, Jan 31, 2022 at 8:48 PM Les Ginsberg (ginsberg) 
wrote:

> Jeff –
>
>
>
> I appreciate that you have been pulled into reading a very lengthy thread
> and then commenting  on it – which is a difficult/time consuming  thing to
> do accurately.
>
> And I certainly welcome your input and agree with your input.
>
>
>
> I have not asked for BFD extensions.
>
> I have stated that “IF” additional functionality is required from BFD that
> the proper place to discuss that is in the BFD WG – and such discussions
> are definitely not in scope of this draft.
>
>
>
> The main content of this lengthy thread is Robert asking for additional
> specification in this draft and other folks (myself, Albert, Ketan) saying
> it doesn’t belong in this draft. Which is why I agree with everything you
> say below except for your perception that you are agreeing with Robert. You
> are actually agreeing with myself, Albert, Ketan. 
>
>
>
> Thanx for your participation.
>
>
>
> Les
>
>
>
> *From:* Jeffrey Haas 
> *Sent:* Monday, January 31, 2022 11:28 AM
> *To:* Robert Raszuk 
> *Cc:* Ketan Talaulikar ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee
> Lindem (acee) ; Albert Fu ; lsr <
> lsr@ietf.org>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> [Note that I read the LSR mailing list infrequently, but this thread was
> brought to my attention.]
>
>
>
> I wish to largely support Robert's point here.  BFD is not intended as a
> link quality protocol.  It's a very simple hello protocol that can operate
> quite quickly and provide simple edge transition events of Up and Down.
>
>
>
> There has been work in the BFD Working Group over the years to attempt to
> bring more of "link quality" behaviors to the protocol.  One, of interest
> to this thread, is the BFD for Large Packets work, which can support MTU
> probes as part of BFD operation.
>
>
>
> draft-ietf-bfd-stability discusses leveraging BFD internal state to help
> look at link instability issues as BFD sees them.
>
>
>
> And, of course, Greg Mirsky had several times he wanted to get BFD to do
> more active behaviors.  He was encouraged to leverage the BFD machinery in
> his own non-BFD draft if he found it helpful.  I suspect he'll respond to
> this thread with comments on his thinking here.
>
>
>
> That said, the BFD strict work is about removing control-plane protocol
> ambiguity with regards to how it uses BFD and how the state machines
> interact with each other.  I think that work has been reasonably done.
>
>
>
> The thing that BFD isn't about in such contexts is being more than a
> simple proxy for the link being of bad enough quality for BFD to go down
> taking the client protocols down with it.  It's important for those client
> protocols and the operators to set the timers and Detection Multiplier
> (number of lost packets) to speeds they think support their needs.  If you
> have a noisy link that can drop several packets in succession and that's
> what you want to be your trigger, BFD is your protocol.  If you want it to
> take an apparently continuous loss over most of a second, BFD can do that
> too if you tune your timers appropriately.
>
>
>
> But, as you say Robert, it's not intended to be a general IPPM style
> tool.  I don't believe the BFD strict drafts should try to treat BFD as if
> it is one.
>
>
>
> -- Jeff
>
>
>
>
>
>
>
> On Jan 31, 2022, at 5:31 AM, Robert Raszuk  wrote:
>
>
>
> HI Ketan & Les,
>
>
>
> To finish this topic I would like to observe that IMHO you have it quite
> backwords.
>
>
>
> *Comment #1*
>
>
>
> The tone of your expressions is trying to illustrate that there can be
> many clients for given link probing tool (here BFD). In reality the
> situation is vastly different. There is usually one link state IGP running
> on the node and given set of probing protocols are associated with it.
> Moreover, the world does not end on BFD. BFD is just one possible tool, but
> more and more path probing tools are emerging or are already deployed.
> Asking for each of them to introduce into their

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

[Robert Raszuk]

Hi Albert,

On Mon, Jan 31, 2022 at 8:38 PM Albert Fu (BLOOMBERG/ 120 PARK) <
af...@bloomberg.net> wrote:

> Hi Robert,
>
> Do you mean we should make it mandatory in the draft to stipulate a delay
> time between when OSPF should wait for BFD to come up?
>

No.

The timer is for OSPF to bring adj up only after X timer expires from the
moment BFD session came up and stayed up (never went down).

No changes to BFD needed at all.

Trivial to implement on the client side and very useful operationally.

Thx,
Robert




> I don't know how others feel, but I tend to agree the main author of this
> Draft, Ketan, that it is best to leave the delay timer out of this draft.
>
> There is already an implicit understanding that BFD must be up before OSPF
> can progress to the adjacency phase.
>
> And I can think of deployments with many redundant links where the delay
> can be large value, and some scenario say sites with only 1 redundant link
> where it is not desirable for the delay not to be too lengthy, to avoid
> both links being down at the same time and cutting communication to the
> site completely.
>
> I have also tested current implementations where the delays do not have to
> match (e.g. one side with delay, and one side no delay).
>
> IMO, it is better not to make the delay a part of the standard.
>
> Thanks
>
> Albert
>
>
> From: rob...@raszuk.net At: 01/31/22 13:51:56 UTC-5:00
> To: Albert Fu (BLOOMBERG/ 120 PARK ) 
> Cc: ginsb...@cisco.com, ketant.i...@gmail.com, a...@cisco.com,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
> Albert,
>
> > It serves as a sanity check that there's indeed a working
> > BFD for a period of time before OSPF adjacency is allowed
> > to progress.
>
> And that is precisely what I am suggesting that should be both mandatory
> and part of this draft. Not an optional nice to have vendor knob.
>
> Clearly it does not belong to BFD spec or WG what Les and Ketan are trying
> to suggest.
>
> Regards,
> R.
>
>
>
>
>
>
>
>
> On Mon, Jan 31, 2022 at 6:52 PM Albert Fu (BLOOMBERG/ 120 PARK) <
> af...@bloomberg.net> wrote:
>
>> Hi Robert,
>>
>> The BGP BFD hold-time mentioned in the BGP BFD strict mode draft has
>> different meaning from the holdtime/delay/dampening that has been discussed
>> in this forum thus far.
>>
>> The BGP BFD hold-time, as per the BGP BFD draft below, is user
>> configurable, and is used to bring down the BGP session if BFD session is
>> not established within default of 30s, when the negotiated "BGP HoldTimer"
>> is 0.
>>
>>
>> The OSPF hold-time/delay/dampening that we have been discussing so far is
>> the delay from when BFD comes up to when OSPF will be allowed to come up.
>> This, as Ketan mentioned, is outside the scope of this draft.
>>
>> In my testing with both Cisco and Juniper implementation, the OSPF
>> hold-time/delay/dampening timers are quite arbitrary. You could have no
>> delay (which means bring up OSPF asap), or have it configured on one side
>> only. It serves as a sanity check that there's indeed a working BFD for a
>> period of time before OSPF adjacency is allowed to progress.
>>
>> Thanks
>>
>> Albert
>>
>> From: rob...@raszuk.net At: 01/31/22 09:59:48 UTC-5:00
>> To: Albert Fu (BLOOMBERG/ 120 PARK ) ,
>> ginsb...@cisco.com, ketant.i...@gmail.com
>> Cc: a...@cisco.com, draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,
>> lsr@ietf.org
>> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
>> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>> Les & Ketan
>>
>>
>>> Nowadays, it is also common to see the "break-in-middle" failures. we
>>> use BFD to detect this sort of failure within sub-second. And to dampen
>>> this sort of break-in-middle failures, we will need to use BFD
>>> holdtime/dampening.
>>>
>>
>> Another data point to the above and this discussion which Albert is
>> co-author of.
>>
>> Ref:
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode
>>
>> Please see the below paragraph which clearly says *BGP BFD Hold time*:
>>
>>If the BFD session does not transition to the Up state, and the
>>HoldTimer has been negotiated to a non-zero value, the BGP FSM will
>>close the session appropriately.  If the HoldTimer has been
>>negotiated to a zero value, the session should be clo

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

[Les Ginsberg (ginsberg)]

Jeff –

I appreciate that you have been pulled into reading a very lengthy thread and 
then commenting  on it – which is a difficult/time consuming  thing to do 
accurately.
And I certainly welcome your input and agree with your input.

I have not asked for BFD extensions.
I have stated that “IF” additional functionality is required from BFD that the 
proper place to discuss that is in the BFD WG – and such discussions are 
definitely not in scope of this draft.

The main content of this lengthy thread is Robert asking for additional 
specification in this draft and other folks (myself, Albert, Ketan) saying it 
doesn’t belong in this draft. Which is why I agree with everything you say 
below except for your perception that you are agreeing with Robert. You are 
actually agreeing with myself, Albert, Ketan. 

Thanx for your participation.

Les

From: Jeffrey Haas 
Sent: Monday, January 31, 2022 11:28 AM
To: Robert Raszuk 
Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg) 
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee Lindem 
(acee) ; Albert Fu ; lsr 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

[Note that I read the LSR mailing list infrequently, but this thread was 
brought to my attention.]

I wish to largely support Robert's point here.  BFD is not intended as a link 
quality protocol.  It's a very simple hello protocol that can operate quite 
quickly and provide simple edge transition events of Up and Down.

There has been work in the BFD Working Group over the years to attempt to bring 
more of "link quality" behaviors to the protocol.  One, of interest to this 
thread, is the BFD for Large Packets work, which can support MTU probes as part 
of BFD operation.

draft-ietf-bfd-stability discusses leveraging BFD internal state to help look 
at link instability issues as BFD sees them.

And, of course, Greg Mirsky had several times he wanted to get BFD to do more 
active behaviors.  He was encouraged to leverage the BFD machinery in his own 
non-BFD draft if he found it helpful.  I suspect he'll respond to this thread 
with comments on his thinking here.

That said, the BFD strict work is about removing control-plane protocol 
ambiguity with regards to how it uses BFD and how the state machines interact 
with each other.  I think that work has been reasonably done.

The thing that BFD isn't about in such contexts is being more than a simple 
proxy for the link being of bad enough quality for BFD to go down taking the 
client protocols down with it.  It's important for those client protocols and 
the operators to set the timers and Detection Multiplier (number of lost 
packets) to speeds they think support their needs.  If you have a noisy link 
that can drop several packets in succession and that's what you want to be your 
trigger, BFD is your protocol.  If you want it to take an apparently continuous 
loss over most of a second, BFD can do that too if you tune your timers 
appropriately.

But, as you say Robert, it's not intended to be a general IPPM style tool.  I 
don't believe the BFD strict drafts should try to treat BFD as if it is one.

-- Jeff




On Jan 31, 2022, at 5:31 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

HI Ketan & Les,

To finish this topic I would like to observe that IMHO you have it quite 
backwords.

Comment #1

The tone of your expressions is trying to illustrate that there can be many 
clients for given link probing tool (here BFD). In reality the situation is 
vastly different. There is usually one link state IGP running on the node and 
given set of probing protocols are associated with it. Moreover, the world does 
not end on BFD. BFD is just one possible tool, but more and more path probing 
tools are emerging or are already deployed. Asking for each of them to 
introduce into their state machine a new behaviour to delay reporting UP state 
on a per client basis is nothing else then just pushing the problem aways and 
not caring for the cost associated with it.

Comment #2

BFD is a great tool to tell you if the end to end path is UP or DOWN. It was 
not designed to give you any characteristics or metrics for the path quality.

So all assertions of that notion in your draft are simply wrong. While sure 
there are proposals to extend BFD probe packets with arbitrary large payload to 
tell you if at some packet size you can still reach the other end they are 
still nothing close to measure any form of link performance or detect "A 
degraded or poor quality link"

Thx a lot,
R.

On Mon, Jan 31, 2022 at 5:48 AM Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:
Hi Les,

I agree with you that mechanisms like dampening and hold-down are best achieved 
at the lowest levels (in this case in the monitoring protocol like BFD) instead 
of in each routing protocol on the top.

Now whether this means we include/support the signaling of the para

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Robert,

Do you mean we should make it mandatory in the draft to stipulate a delay time 
between when OSPF should wait for BFD to come up?

I don't know how others feel, but I tend to agree the main author of this 
Draft, Ketan, that it is best to leave the delay timer out of this draft. 

There is already an implicit understanding that BFD must be up before OSPF can 
progress to the adjacency phase.

And I can think of deployments with many redundant links where the delay can be 
large value, and some scenario say sites with only 1 redundant link where it is 
not desirable for the delay not to be too lengthy, to avoid both links being 
down at the same time and cutting communication to the site completely.

I have also tested current implementations where the delays do not have to 
match (e.g. one side with delay, and one side no delay).

IMO, it is better not to make the delay a part of the standard.

Thanks

Albert


From: rob...@raszuk.net At: 01/31/22 13:51:56 UTC-5:00To:  Albert Fu 
(BLOOMBERG/ 120 PARK ) 
Cc:  ginsb...@cisco.com,  ketant.i...@gmail.com,  a...@cisco.com,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Albert,

> It serves as a sanity check that there's indeed a working 
> BFD for a period of time before OSPF adjacency is allowed 
> to progress.

And that is precisely what I am suggesting that should be both mandatory and 
part of this draft. Not an optional nice to have vendor knob. 

Clearly it does not belong to BFD spec or WG what Les and Ketan are trying to 
suggest. 

Regards,
R.


On Mon, Jan 31, 2022 at 6:52 PM Albert Fu (BLOOMBERG/ 120 PARK) 
 wrote:

Hi Robert,

The BGP BFD hold-time mentioned in the BGP BFD strict mode draft has different 
meaning from the holdtime/delay/dampening that has been discussed in this forum 
thus far. 

The BGP BFD hold-time, as per the BGP BFD draft below, is user configurable, 
and is used to bring down the BGP session if BFD session is not established 
within default of 30s, when the negotiated "BGP HoldTimer" is 0. 


The OSPF hold-time/delay/dampening that we have been discussing so far is the 
delay from when BFD comes up to when OSPF will be allowed to come up. This, as 
Ketan mentioned, is outside the scope of this draft. 

In my testing with both Cisco and Juniper implementation, the OSPF 
hold-time/delay/dampening timers are quite arbitrary. You could have no delay 
(which means bring up OSPF asap), or have it configured on one side only. It 
serves as a sanity check that there's indeed a working BFD for a period of time 
before OSPF adjacency is allowed to progress.

Thanks

Albert

From: rob...@raszuk.net At: 01/31/22 09:59:48 UTC-5:00To:  Albert Fu 
(BLOOMBERG/ 120 PARK ) ,  ginsb...@cisco.com,  ketant.i...@gmail.com
Cc:  a...@cisco.com,  draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  
lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Les & Ketan
 
Nowadays, it is also common to see the "break-in-middle" failures. we use BFD 
to detect this sort of failure within sub-second. And to dampen this sort of 
break-in-middle failures, we will need to use BFD holdtime/dampening. 


Another data point to the above and this discussion which Albert is co-author 
of. 

Ref: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode

Please see the below paragraph which clearly says BGP BFD Hold time: 

   If the BFD session does not transition to the Up state, and the
   HoldTimer has been negotiated to a non-zero value, the BGP FSM will
   close the session appropriately.  If the HoldTimer has been
   negotiated to a zero value, the session should be closed after a time
   of X.  This time X is referred as "BGP BFD Hold time".  The proposed
   default BGP BFD Hold time value is 30 seconds.  The BGP BFD Hold time
   value is configurable.

To me it is clear that BGP BFD Hold time is on the client side and here affects 
BGP FSM. 

Thx,
Robert.


From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00To:  rob...@raszuk.net,  
ketant.i...@gmail.com
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  a...@cisco.com,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  lsr@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

 

Robert – 
  
Here is what you said (emphasis added): 
  
 
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. 
 
  
Point #1: If you want BFD to do more testing (such as MTU testing) then clearly 
you need ex

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

[Robert Raszuk]

> what new signal should BFD send to OSPF when this is done?

None. Lack of DOWN signal is enough for OSPF to proceed.

Thx,
R.

On Mon, Jan 31, 2022 at 6:50 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> The paragraph you quote below has to do with BGP behavior in the event
> “BFD session does not transition to the Up state”.
>
> There is no disagreement about what the protocol (BGP or OSPF) should do
> in this case. The point of strict-mode is to “wait-for-BFD”.
>
>
>
> You, however, are trying to introduce some additional requirements. To
> this end you said:
>
>
>
> *“What I find missing in the draft is a mutually (between OSPF peers)
> timer fired after BFD session is up which in OSPF could hold on allowing
> BFD to do some more testing before declaring adj to be established. I think
> just bringing OSPF adj immediately after the BFD session is up is not a
> good thing.”*
>
>
>
> So apparently you want BFD to signal UP – but have the protocol do nothing
> until BFD completes some additional testing. What then was the point of BFD
> signaling UP to OSPF? And since you want the additional testing to be done
> by BFD, what new signal should BFD send to OSPF when this is done?
>
> The point of BFD sending UP to its clients is to indicate that BFD thinks
> the link has been verified from the BFD perspective. I do not see the point
> of sending two such signals. If you think current BFD testing is inadequate
> please ask for extensions to BFD (in the BFD WG).
>
>
>
> You also said:
>
>
>
> “BFD is a great tool to tell you if the end to end path is UP or DOWN. It
> was not designed to give you any characteristics or metrics for the path
> quality.”
>
>
>
> I agree. But if you are now proposing that protocol adjacencies should not
> come up until certain link quality metrics are met (e.g., link loss, delay)
> – you are moving into an area that is completely out of scope of this draft.
>
> I won’t dig deeper into what could be a very lengthy discussion. If you
> really want to pursue this idea, I suggest you write a new draft.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, January 31, 2022 6:59 AM
> *To:* Albert Fu ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Ketan Talaulikar 
> *Cc:* Acee Lindem (acee) ;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; lsr 
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Les & Ketan
>
>
>
> Nowadays, it is also common to see the "break-in-middle" failures. we use
> BFD to detect this sort of failure within sub-second. And to dampen this
> sort of break-in-middle failures, we will need to use BFD
> holdtime/dampening.
>
>
>
> Another data point to the above and this discussion which Albert is
> co-author of.
>
>
>
> Ref:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode
>
>
>
> Please see the below paragraph which clearly says *BGP BFD Hold time*:
>
>
>
>If the BFD session does not transition to the Up state, and the
>HoldTimer has been negotiated to a non-zero value, the BGP FSM will
>close the session appropriately.  If the HoldTimer has been
>negotiated to a zero value, the session should be closed after a time
>of X.  This time X is referred as "BGP BFD Hold time".  The proposed
>default BGP BFD Hold time value is 30 seconds.  The BGP BFD Hold time
>value is configurable.
>
>
>
> To me it is clear that BGP BFD Hold time is on the client side and here
> affects BGP FSM.
>
>
>
> Thx,
>
> Robert.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00
>
> To: rob...@raszuk.net, ketant.i...@gmail.com
> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , a...@cisco.com,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Robert –
>
>
>
> Here is what you said (emphasis added):
>
>
>
> 
>
> 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.
>
> 
>
>
>
> Point #1: If you want BFD to do more testing (such as MTU testing) then
> clearly you need extensions to BFD (suc

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Robert,

The BGP BFD hold-time mentioned in the BGP BFD strict mode draft has different 
meaning from the holdtime/delay/dampening that has been discussed in this forum 
thus far. 

The BGP BFD hold-time, as per the BGP BFD draft below, is user configurable, 
and is used to bring down the BGP session if BFD session is not established 
within default of 30s, when the negotiated "BGP HoldTimer" is 0. 


The OSPF hold-time/delay/dampening that we have been discussing so far is the 
delay from when BFD comes up to when OSPF will be allowed to come up. This, as 
Ketan mentioned, is outside the scope of this draft. 

In my testing with both Cisco and Juniper implementation, the OSPF 
hold-time/delay/dampening timers are quite arbitrary. You could have no delay 
(which means bring up OSPF asap), or have it configured on one side only. It 
serves as a sanity check that there's indeed a working BFD for a period of time 
before OSPF adjacency is allowed to progress.

Thanks

Albert

From: rob...@raszuk.net At: 01/31/22 09:59:48 UTC-5:00To:  Albert Fu 
(BLOOMBERG/ 120 PARK ) ,  ginsb...@cisco.com,  ketant.i...@gmail.com
Cc:  a...@cisco.com,  draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  
lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Les & Ketan
 
Nowadays, it is also common to see the "break-in-middle" failures. we use BFD 
to detect this sort of failure within sub-second. And to dampen this sort of 
break-in-middle failures, we will need to use BFD holdtime/dampening. 


Another data point to the above and this discussion which Albert is co-author 
of. 

Ref: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode

Please see the below paragraph which clearly says BGP BFD Hold time: 

   If the BFD session does not transition to the Up state, and the
   HoldTimer has been negotiated to a non-zero value, the BGP FSM will
   close the session appropriately.  If the HoldTimer has been
   negotiated to a zero value, the session should be closed after a time
   of X.  This time X is referred as "BGP BFD Hold time".  The proposed
   default BGP BFD Hold time value is 30 seconds.  The BGP BFD Hold time
   value is configurable.

To me it is clear that BGP BFD Hold time is on the client side and here affects 
BGP FSM. 

Thx,
Robert.


From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00To:  rob...@raszuk.net,  
ketant.i...@gmail.com
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  a...@cisco.com,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  lsr@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

 

Robert – 
  
Here is what you said (emphasis added): 
  
 
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. 
 
  
Point #1: If you want BFD to do more testing (such as MTU testing) then clearly 
you need extensions to BFD (such as 
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ ) 
  
Point #2: The existing timers (as Ketan points out are mentioned in Section 5) 
are applied today at the OSPF level precisely because OSPF does not currently 
have strict-mode operation. So in a flapping scenario you could see the 
following  behavior: 
  
a)BFD goes down 
b)OSPF goes down in response to BFD 
c)OSPF comes back up  
d)Link is still unstable – so traffic is being dropped some of the time – but 
perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often enough to 
keep the OSPF adjacency up) 
  
So some implementations have chosen to insert a delay following “b”. This 
doesn’t guarantee stability, but hopefully makes it less likely. And because 
OSPF today does NOT wait for BFD to come up, the delay has to be implemented at 
the OSPF  level. 
  
Once you have strict mode support, the sequence becomes: 
  
a)BFD goes down 
b)OSPF goes down in response to BFD 
c)BFD comes back up 
d)OSPF comes back up 
  
Now, if the concern is that BFD comes back up while the link is still unstable, 
the way to address that is to put a delay either before BFD attempts to bring 
up a new session or a delay after achieving UP state before it signals UP to 
its  clients – such as OSPF. This is a better solution because all BFD clients 
benefit from this. Ad if the link is still unstable, it is more likely that the 
BFD session will go down during the delay period than it would be for OSPF 
because the BFD timers are  significantly more aggressive. 
(BTW, this behavior can be done w/o a BFD protocol extension – it is purely an 
implementation choice.) 
  
From a design perspective, dampening is always best done at the lowest layer 
poss

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

[Les Ginsberg (ginsberg)]

Robert –

The paragraph you quote below has to do with BGP behavior in the event “BFD 
session does not transition to the Up state”.
There is no disagreement about what the protocol (BGP or OSPF) should do in 
this case. The point of strict-mode is to “wait-for-BFD”.

You, however, are trying to introduce some additional requirements. To this end 
you said:

“What I find missing in the draft is a mutually (between OSPF peers) timer 
fired after BFD session is up which in OSPF could hold on allowing BFD to do 
some more testing before declaring adj to be established. I think just bringing 
OSPF adj immediately after the BFD session is up is not a good thing.”

So apparently you want BFD to signal UP – but have the protocol do nothing 
until BFD completes some additional testing. What then was the point of BFD 
signaling UP to OSPF? And since you want the additional testing to be done by 
BFD, what new signal should BFD send to OSPF when this is done?
The point of BFD sending UP to its clients is to indicate that BFD thinks the 
link has been verified from the BFD perspective. I do not see the point of 
sending two such signals. If you think current BFD testing is inadequate please 
ask for extensions to BFD (in the BFD WG).

You also said:

“BFD is a great tool to tell you if the end to end path is UP or DOWN. It was 
not designed to give you any characteristics or metrics for the path quality.”

I agree. But if you are now proposing that protocol adjacencies should not come 
up until certain link quality metrics are met (e.g., link loss, delay) – you 
are moving into an area that is completely out of scope of this draft.
I won’t dig deeper into what could be a very lengthy discussion. If you really 
want to pursue this idea, I suggest you write a new draft.

   Les

From: Robert Raszuk 
Sent: Monday, January 31, 2022 6:59 AM
To: Albert Fu ; Les Ginsberg (ginsberg) 
; Ketan Talaulikar 
Cc: Acee Lindem (acee) ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; lsr 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Les & Ketan

Nowadays, it is also common to see the "break-in-middle" failures. we use BFD 
to detect this sort of failure within sub-second. And to dampen this sort of 
break-in-middle failures, we will need to use BFD holdtime/dampening.

Another data point to the above and this discussion which Albert is co-author 
of.

Ref: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode

Please see the below paragraph which clearly says BGP BFD Hold time:

   If the BFD session does not transition to the Up state, and the
   HoldTimer has been negotiated to a non-zero value, the BGP FSM will
   close the session appropriately.  If the HoldTimer has been
   negotiated to a zero value, the session should be closed after a time
   of X.  This time X is referred as "BGP BFD Hold time".  The proposed
   default BGP BFD Hold time value is 30 seconds.  The BGP BFD Hold time
   value is configurable.

To me it is clear that BGP BFD Hold time is on the client side and here affects 
BGP FSM.

Thx,
Robert.







From: ginsb...@cisco.com<mailto:ginsb...@cisco.com> At: 01/30/22 14:38:37 
UTC-5:00
To: rob...@raszuk.net<mailto:rob...@raszuk.net>, 
ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) <mailto:af...@bloomberg.net> , 
a...@cisco.com<mailto:a...@cisco.com>, 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>,
 lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Robert –

Here is what you said (emphasis added):


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.


Point #1: If you want BFD to do more testing (such as MTU testing) then clearly 
you need extensions to BFD (such as 
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )

Point #2: The existing timers (as Ketan points out are mentioned in Section 5) 
are applied today at the OSPF level precisely because OSPF does not currently 
have strict-mode operation. So in a flapping scenario you could see the 
following behavior:

a)BFD goes down
b)OSPF goes down in response to BFD
c)OSPF comes back up
d)Link is still unstable – so traffic is being dropped some of the time – but 
perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often enough to 
keep the OSPF adjacency up)

So some implementations have chosen to insert a delay following “b”. This 
doesn’t guarantee stability, but hopefully makes it less likely. And

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

[Robert Raszuk]

Les,

BFD does not have a notion to come up in a hidden way, start testing
the link and only after some defined per client protocol or per interface
peer period signal to the client its "UP" state.

BFD holdtime as defined in RFC5880 is to keep BFD sessions and therefore
data probes down (for example to smooth in time control plane churn when
1000s of BFD peers are to all come up in the same time) so it is completely
unrelated to the discussion about BFD clients and link testing before
brining OSPF adj up.

If you want to extend BFD further you are welcome to take it to the BFD WG.
I am cc-ing Greg here as he is one of the best active BFD experts.

But if so this draft should wait till that happens. Alternatively as it has
been suggested we could choose to keep BFD simple and have such timer on
the client side. The behaviour on the client is trivial - Do your client
action (bring IGP adj. up or BGP session up or insert static to the RIB etc
...) if timer X elapsed from BFD session going UP and during that time
there was no transition to DOWN.

Regards,
R.




On Mon, Jan 31, 2022 at 6:31 PM Les Ginsberg (ginsberg) 
wrote:

> Albert –
>
>
>
> We are in full agreement.
>
>
>
> Delays in bringing BFD backup after a previous failure may well be
> warranted in the break-in-middle scenarios.
>
> I am not convinced this needs to be standardized – seems quite appropriate
> as an implementation choice. But if any discussion were to occur in RFCs, I
> think it should be in some BFD document.
>
>
>
> As this draft is focused on OSPF protocol extensions, I don’t think BFD
> dampening needs to be discussed. In any case it should not alter the
> interaction between BFD and protocols. If it takes longer for BFD to come
> up that just means the OSPF adjacency will not come up either – which is
> exactly the behavior that is desired.
>
>
>
> Les
>
>
>
>
>
> *From:* Albert Fu (BLOOMBERG/ 120 PARK) 
> *Sent:* Monday, January 31, 2022 6:50 AM
> *To:* Les Ginsberg (ginsberg) ; ketant.i...@gmail.com;
> rob...@raszuk.net
> *Cc:* Acee Lindem (acee) ;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; lsr@ietf.org
> *Subject:* RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Les,
>
>
>
> Your scenario below is indeed something we have encountered in our
> production network in the non-strict scenario, due to "flapping" links,
> where routing protocol could come up before BFD due to "break-in-middle"
> link issue (interface stayed up, so routing protocol remained active).
> Strict mode will address this issue.
>
>
>
> Another point to add is that we do have as a standard on our interfaces to
> safeguard against flapping link by configuring interface
> hold-time/carrier-delay. However, this is only useful in situations where
> the link physically goes down (and fast detection is automatic in most
> implementation).
>
>
>
> Nowadays, it is also common to see the "break-in-middle" failures. we use
> BFD to detect this sort of failure within sub-second. And to dampen this
> sort of break-in-middle failures, we will need to use BFD
> holdtime/dampening.
>
>
>
> Thanks
>
>
>
> Albert
>
>
>
>
>
>
>
> From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00
>
> To: rob...@raszuk.net, ketant.i...@gmail.com
> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , a...@cisco.com,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Robert –
>
>
>
> Here is what you said (emphasis added):
>
>
>
> 
>
> 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.
>
> 
>
>
>
> Point #1: If you want BFD to do more testing (such as MTU testing) then
> clearly you need extensions to BFD (such as
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )
>
>
>
> Point #2: The existing timers (as Ketan points out are mentioned in
> Section 5) are applied today at the OSPF level precisely because OSPF does
> not currently have strict-mode operation. So in a flapping scenario you
> could see the following behavior:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)OSPF comes back up
>
> d)Link is still unstable – so traff

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

[Les Ginsberg (ginsberg)]

Albert –

We are in full agreement.

Delays in bringing BFD backup after a previous failure may well be warranted in 
the break-in-middle scenarios.
I am not convinced this needs to be standardized – seems quite appropriate as 
an implementation choice. But if any discussion were to occur in RFCs, I think 
it should be in some BFD document.

As this draft is focused on OSPF protocol extensions, I don’t think BFD 
dampening needs to be discussed. In any case it should not alter the 
interaction between BFD and protocols. If it takes longer for BFD to come up 
that just means the OSPF adjacency will not come up either – which is exactly 
the behavior that is desired.

Les


From: Albert Fu (BLOOMBERG/ 120 PARK) 
Sent: Monday, January 31, 2022 6:50 AM
To: Les Ginsberg (ginsberg) ; ketant.i...@gmail.com; 
rob...@raszuk.net
Cc: Acee Lindem (acee) ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; lsr@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Les,

Your scenario below is indeed something we have encountered in our production 
network in the non-strict scenario, due to "flapping" links, where routing 
protocol could come up before BFD due to "break-in-middle" link issue 
(interface stayed up, so routing protocol remained active). Strict mode will 
address this issue.

Another point to add is that we do have as a standard on our interfaces to 
safeguard against flapping link by configuring interface 
hold-time/carrier-delay. However, this is only useful in situations where the 
link physically goes down (and fast detection is automatic in most 
implementation).

Nowadays, it is also common to see the "break-in-middle" failures. we use BFD 
to detect this sort of failure within sub-second. And to dampen this sort of 
break-in-middle failures, we will need to use BFD holdtime/dampening.

Thanks

Albert



From: ginsb...@cisco.com<mailto:ginsb...@cisco.com> At: 01/30/22 14:38:37 
UTC-5:00
To: rob...@raszuk.net<mailto:rob...@raszuk.net>, 
ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) <mailto:af...@bloomberg.net> , 
a...@cisco.com<mailto:a...@cisco.com>, 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>,
 lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Robert –

Here is what you said (emphasis added):


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.


Point #1: If you want BFD to do more testing (such as MTU testing) then clearly 
you need extensions to BFD (such as 
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )

Point #2: The existing timers (as Ketan points out are mentioned in Section 5) 
are applied today at the OSPF level precisely because OSPF does not currently 
have strict-mode operation. So in a flapping scenario you could see the 
following behavior:

a)BFD goes down
b)OSPF goes down in response to BFD
c)OSPF comes back up
d)Link is still unstable – so traffic is being dropped some of the time – but 
perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often enough to 
keep the OSPF adjacency up)

So some implementations have chosen to insert a delay following “b”. This 
doesn’t guarantee stability, but hopefully makes it less likely. And because 
OSPF today does NOT wait for BFD to come up, the delay has to be implemented at 
the OSPF level.

Once you have strict mode support, the sequence becomes:

a)BFD goes down
b)OSPF goes down in response to BFD
c)BFD comes back up
d)OSPF comes back up

Now, if the concern is that BFD comes back up while the link is still unstable, 
the way to address that is to put a delay either before BFD attempts to bring 
up a new session or a delay after achieving UP state before it signals UP to 
its clients – such as OSPF. This is a better solution because all BFD clients 
benefit from this. Ad if the link is still unstable, it is more likely that the 
BFD session will go down during the delay period than it would be for OSPF 
because the BFD timers are significantly more aggressive.
(BTW, this behavior can be done w/o a BFD protocol extension – it is purely an 
implementation choice.)

From a design perspective, dampening is always best done at the lowest layer 
possible. In most cases, interface layer dampening is best. If that is not 
reliable for some reason, then move one layer up – not two layers up.

   Les


From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Sunday, January 30, 2022 10:05 AM
To: Ket

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

[Robert Raszuk]

Les & Ketan


> Nowadays, it is also common to see the "break-in-middle" failures. we use
> BFD to detect this sort of failure within sub-second. And to dampen this
> sort of break-in-middle failures, we will need to use BFD
> holdtime/dampening.
>

Another data point to the above and this discussion which Albert is
co-author of.

Ref:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode

Please see the below paragraph which clearly says *BGP BFD Hold time*:

   If the BFD session does not transition to the Up state, and the
   HoldTimer has been negotiated to a non-zero value, the BGP FSM will
   close the session appropriately.  If the HoldTimer has been
   negotiated to a zero value, the session should be closed after a time
   of X.  This time X is referred as "BGP BFD Hold time".  The proposed
   default BGP BFD Hold time value is 30 seconds.  The BGP BFD Hold time
   value is configurable.

To me it is clear that BGP BFD Hold time is on the client side and here
affects BGP FSM.

Thx,
Robert.







From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00
> To: rob...@raszuk.net, ketant.i...@gmail.com
> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , a...@cisco.com,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
> Robert –
>
>
>
> Here is what you said (emphasis added):
>
>
>
> 
>
> 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.
>
> 
>
>
>
> Point #1: If you want BFD to do more testing (such as MTU testing) then
> clearly you need extensions to BFD (such as
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )
>
>
>
> Point #2: The existing timers (as Ketan points out are mentioned in
> Section 5) are applied today at the OSPF level precisely because OSPF does
> not currently have strict-mode operation. So in a flapping scenario you
> could see the following behavior:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)OSPF comes back up
>
> d)Link is still unstable – so traffic is being dropped some of the time –
> but perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often
> enough to keep the OSPF adjacency up)
>
>
>
> So some implementations have chosen to insert a delay following “b”. This
> doesn’t guarantee stability, but hopefully makes it less likely. And
> because OSPF today does NOT wait for BFD to come up, the delay has to be
> implemented at the OSPF level.
>
>
>
> Once you have strict mode support, the sequence becomes:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)BFD comes back up
>
> d)OSPF comes back up
>
>
>
> Now, if the concern is that BFD comes back up while the link is still
> unstable, the way to address that is to put a delay either before BFD
> attempts to bring up a new session or a delay after achieving UP state
> before it signals UP to its clients – such as OSPF. This is a better
> solution because all BFD clients benefit from this. Ad if the link is still
> unstable, it is more likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> (BTW, this behavior can be done w/o a BFD protocol extension – it is
> purely an implementation choice.)
>
>
>
> From a design perspective, dampening is always best done at the lowest
> layer possible. In most cases, interface layer dampening is best. If that
> is not reliable for some reason, then move one layer up – not two layers up.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, January 30, 2022 10:05 AM
> *To:* Ketan Talaulikar 
> *Cc:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>; lsr 
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Ketan,
>
>
>
> I would like to point out that the draft discusses the BFD "dampening" or
> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
> include such mechanisms in a protocol-agnostic manner.
>
>
>
> BFD dampening or hold-time are completely orth

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Les,

Your scenario below is indeed something we have encountered in our production 
network in the non-strict scenario, due to "flapping" links, where routing 
protocol could come up before BFD due to "break-in-middle" link issue 
(interface stayed up, so routing protocol remained active). Strict mode will 
address this issue. 

Another point to add is that we do have as a standard on our interfaces to 
safeguard against flapping link by configuring interface 
hold-time/carrier-delay. However, this is only useful in situations where the 
link physically goes down (and fast detection is automatic in most 
implementation). 

Nowadays, it is also common to see the "break-in-middle" failures. we use BFD 
to detect this sort of failure within sub-second. And to dampen this sort of 
break-in-middle failures, we will need to use BFD holdtime/dampening. 

Thanks

Albert


From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00To:  rob...@raszuk.net,  
ketant.i...@gmail.com
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  a...@cisco.com,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  lsr@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

 

Robert – 
  
Here is what you said (emphasis added): 
  
 
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. 
 
  
Point #1: If you want BFD to do more testing (such as MTU testing) then clearly 
you need extensions to BFD (such as 
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ ) 
  
Point #2: The existing timers (as Ketan points out are mentioned in Section 5) 
are applied today at the OSPF level precisely because OSPF does not currently 
have strict-mode operation. So in a flapping scenario you could see the 
following  behavior: 
  
a)BFD goes down 
b)OSPF goes down in response to BFD 
c)OSPF comes back up  
d)Link is still unstable – so traffic is being dropped some of the time – but 
perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often enough to 
keep the OSPF adjacency up) 
  
So some implementations have chosen to insert a delay following “b”. This 
doesn’t guarantee stability, but hopefully makes it less likely. And because 
OSPF today does NOT wait for BFD to come up, the delay has to be implemented at 
the OSPF  level. 
  
Once you have strict mode support, the sequence becomes: 
  
a)BFD goes down 
b)OSPF goes down in response to BFD 
c)BFD comes back up 
d)OSPF comes back up 
  
Now, if the concern is that BFD comes back up while the link is still unstable, 
the way to address that is to put a delay either before BFD attempts to bring 
up a new session or a delay after achieving UP state before it signals UP to 
its  clients – such as OSPF. This is a better solution because all BFD clients 
benefit from this. Ad if the link is still unstable, it is more likely that the 
BFD session will go down during the delay period than it would be for OSPF 
because the BFD timers are  significantly more aggressive. 
(BTW, this behavior can be done w/o a BFD protocol extension – it is purely an 
implementation choice.) 
  
From a design perspective, dampening is always best done at the lowest layer 
possible. In most cases, interface layer dampening is best. If that is not 
reliable for some reason, then move one layer up – not two layers up. 
  
   Les 
  
  

From: Robert Raszuk  
Sent: Sunday, January 30, 2022 10:05 AM
To: Ketan Talaulikar 
Cc: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
; lsr 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04 
  

Hi Ketan, 

  


I would like to point out that the draft discusses the BFD "dampening" or 
"hold-down" mechanism in Sec 5. We are aware of BFD implementations that 
include such mechanisms in a protocol-agnostic manner. 
 

  

BFD dampening or hold-time are completely orthogonal to my point. Both have 
nothing to do with it.  

  

Those timers only fire when BFD goes down. In my example BFD does not go down. 
But we want to bring up the client adj. only after X ms/sec/min etc ...of 
normal BFD operation if no failure is detected during that timer. 

  

This draft indicates that OSPF adjacency will "advance" in the neighbor FSM 
only after BFD reports UP.  
 

  

And that is exactly too soon. In fact if you do that today without waiting some 
time (if you retire the current OSPF timer) you will not help at all in the 
case you are trying to address.  

  

Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF adj. 
will get already es

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

[Jeff Tantsura]

Yes/support 

Cheers,
Jeff

> On Jan 27, 2022, at 09:08, Acee Lindem (acee) 
>  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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

gt;>
>>>>
>>>>
>>>> OLD
>>>>
>>>>
>>>>When BFD is enabled on an interface over which we already have an
>>>>existing OSPF adjacency, it would result in the router setting the
>>>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>>>up (i.e., in its terminal state of Full or 2-way with non-DR routers
>>>>on a multi-access interface) with a neighbor that also supports
>>>>strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>>
>>>>
>>>>
>>>> Gyan> 2-way is not terminal state even for DROther routers
>>>>
>>>
>>> KT> We are talking about the Neighbor FSM State here.
>>>
>>>
>> Gyan> Yes.  The verbiage is not clear.  Non DR is technically called
>> DROther router I believe.  Also the DROther router would be in Full state
>> and not 2-way, correct?
>>
>
> KT2> This document is talking of OSPF Neighbor FSM state. I don't see the
> need to discuss DR-Other or such terminologies in this document.
>

Gyan2> Ack

>
>
>>
>>>> NEW
>>>>
>>>>When BFD is enabled on an interface over which we already have an
>>>>existing OSPF adjacency, it would result in the router setting the
>>>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>>>up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther 
>>>> routers
>>>>on a multi-access interface) with a neighbor that also supports
>>>>    strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>>
>>>>
>>>>
>>>> Section 4.1 OSPFv3 IPv4 address family specifics
>>>>
>>>> Gyan> Why would you not have also OSPFV3 IPv6 address family specifics
>>>>
>>>
>>> KT> Could you please check RFC5838 to know more about multi-AF
>>> operations for OSPFv3?
>>>
>>
>> Gyan>  I understand OSPFv3 MI separate control plane and data plane
>> separate v4 and v6 adjacency I would think that as we have link local
>> address and link local local LSA we need to still set the B bit flag to
>> block the adjacency from forming for v6 control plane.   Imagine if no v4
>> and v6 congruency and v6 had to signal the B bit as we cannot rely on v4
>> instance for v6 adjacency since it’s separate adjacencies.  Also for IPv6
>> only scenario as well now you have to signal the B bit somehow so that flag
>> needs to be specified in the specification.
>>
>
> KT2> I hope my response to a previous comment clarifies this.
>

 Gyan2> Yes it does, Thanks

>
> Thanks,
> Ketan
>
>
>
>>
>>> Thanks,
>>> Ketan
>>>
>>>
>>>>
>>>> Kind Regards
>>>>
>>>> Gyan
>>>>
>>>> On Sat, Jan 29, 2022 at 9:28 PM Aijun Wang 
>>>> wrote:
>>>>
>>>>> Hi, Acee and Ketan:
>>>>> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>>>>> What I want to express is that you brought up the full mesh BFD
>>>>> sessions among the routers within such network type. Is it necessary to
>>>>> bring some of them(the BFD sessions between DRothers) to DOWN after the
>>>>> OSPF adjacency are established between the DRother and DR/BDR router?
>>>>> If the BFD session is bootstrapped after the OSPF adjacency is
>>>>> established, there will be no such extra/useless BFD sessions
>>>>>
>>>>> Aijun Wang
>>>>> China Telecom
>>>>>
>>>>> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>>>>>
>>>>> 
>>>>>
>>>>> Speaking as WG member:
>>>>>
>>>>>
>>>>>
>>>>> Hi Aijun,
>>>>>
>>>>> If you want a per-neighbor state and route, you have to use P2MP. This
>>>>> scope of this draft isn’t to try and make NBMA/Broadcast model something
>>>>> that it is not. This is should be common knowledge and the draft needn’t
>>>>> address it. Those of us who remember ATM emulated LANs (which were not
>>>>> always symmetrically reliable) will recall using P2MP on an inherently
>>>>> multi-access network.
>>>>>
>>>>> Acee
>>>>>
>>

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

[Ketan Talaulikar]

n motivation. Normally, when all routers on a LAN support this spec,
>> they would all likely do strict-mode and not a mix.
>>
>>
>
> Gyan> The main motivation is to fix the problem with OSPF starting before
> BFD to be implemented so that there is backwards compatibility.I think
> you should break out scenarios into P2P and LAN scenario.  This is how I
> would reword.
>

KT2> I am not sure what text and in which section you are suggesting to be
reworded. I do not see the difference in the behavior based on the type of
link when it comes to BFD strict mode.


>
>For Multi-access interfaces when BFD is enabled, but the strict-mode for
>operation has been signaled by multiple but not all neighbors, then an
>implementation SHOULD start the BFD session establishment only in
>2-Way state or higher state.  This makes it possible for an OSPF
>router to support BFD operation in both strict-mode and normal mode
>across different interfaces or even different neighbors.
>
>
>
>For interface with P2P subnet when BFD is enabled, but strict-mode for
>operation has been signaled by both neighbors, then an
>implementation SHOULD start the BFD session establishment at init state.
>
>In case one end of P2P link supports Strict mode and the other neighbor
>
>does not then BFD would come up in Normal mode.
>
>
>
>
>>> So I think that is what you are trying to say that BFD can come up after 
>>> OSPF is Up
>>>
>>> I see you mention 2-way but not fully Up.
>>>
>>>
>> KT> Full state comes after 2-way.
>>
>>
>>>  How would you stagger it allow BFD to come up
>>>
>>> in parallel to ospf still coming to Full state.
>>>
>>>
>> KT> I am not sure if I follow this question. In the non-strict mode of
>> operation, the OSPF adjacency can progress to its terminal state (e.g.
>> full) without any dependence on the BFD session establishment.
>>
>>
> Gyan> This was related to the interoperability with devices not
> supporting on LAN with mix of devices.  I think if we reword as I stated
> above specifying P2P and LAN scenario that would make it clearer.
>
>>
>>>
>>> Nit
>>>
>>>
>>>
>>> OLD
>>>
>>>
>>>When BFD is enabled on an interface over which we already have an
>>>existing OSPF adjacency, it would result in the router setting the
>>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>>up (i.e., in its terminal state of Full or 2-way with non-DR routers
>>>on a multi-access interface) with a neighbor that also supports
>>>strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>
>>>
>>>
>>> Gyan> 2-way is not terminal state even for DROther routers
>>>
>>
>> KT> We are talking about the Neighbor FSM State here.
>>
>>
> Gyan> Yes.  The verbiage is not clear.  Non DR is technically called
> DROther router I believe.  Also the DROther router would be in Full state
> and not 2-way, correct?
>

KT2> This document is talking of OSPF Neighbor FSM state. I don't see the
need to discuss DR-Other or such terminologies in this document.


>
>>> NEW
>>>
>>>When BFD is enabled on an interface over which we already have an
>>>existing OSPF adjacency, it would result in the router setting the
>>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>>up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther 
>>> routers
>>>on a multi-access interface) with a neighbor that also supports
>>>    strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>
>>>
>>>
>>> Section 4.1 OSPFv3 IPv4 address family specifics
>>>
>>> Gyan> Why would you not have also OSPFV3 IPv6 address family specifics
>>>
>>
>> KT> Could you please check RFC5838 to know more about multi-AF operations
>> for OSPFv3?
>>
>
> Gyan>  I understand OSPFv3 MI separate control plane and data plane
> separate v4 and v6 adjacency I would think that as we have link local
> address and link local local LSA we need to still set the B bit flag to
> block the adjacency from forming for v6 control plane.   Imagine if no v4
> and v6 congruency and v6 had to signal the B bit as we cannot rely on v4
> instance for v6 adjacency since it’s separate adjacencies.  Also for IPv6
> only scenario as well now you have to signal the B bit somehow so that fl

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

[Ketan Talaulikar]

Hi Les,

I agree with you that mechanisms like dampening and hold-down are best
achieved at the lowest levels (in this case in the monitoring protocol like
BFD) instead of in each routing protocol on the top.

Now whether this means we include/support the signaling of the parameters
for these mechanisms in BFD or whether they are achieved by provisioning
(as done currently by some implementations) is best discussed in the BFD WG.

Thanks,
Ketan


On Mon, Jan 31, 2022 at 1:08 AM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Here is what you said (emphasis added):
>
>
>
> 
>
> 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.
>
> 
>
>
>
> Point #1: If you want BFD to do more testing (such as MTU testing) then
> clearly you need extensions to BFD (such as
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )
>
>
>
> Point #2: The existing timers (as Ketan points out are mentioned in
> Section 5) are applied today at the OSPF level precisely because OSPF does
> not currently have strict-mode operation. So in a flapping scenario you
> could see the following behavior:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)OSPF comes back up
>
> d)Link is still unstable – so traffic is being dropped some of the time –
> but perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often
> enough to keep the OSPF adjacency up)
>
>
>
> So some implementations have chosen to insert a delay following “b”. This
> doesn’t guarantee stability, but hopefully makes it less likely. And
> because OSPF today does NOT wait for BFD to come up, the delay has to be
> implemented at the OSPF level.
>
>
>
> Once you have strict mode support, the sequence becomes:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)BFD comes back up
>
> d)OSPF comes back up
>
>
>
> Now, if the concern is that BFD comes back up while the link is still
> unstable, the way to address that is to put a delay either before BFD
> attempts to bring up a new session or a delay after achieving UP state
> before it signals UP to its clients – such as OSPF. This is a better
> solution because all BFD clients benefit from this. Ad if the link is still
> unstable, it is more likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> (BTW, this behavior can be done w/o a BFD protocol extension – it is
> purely an implementation choice.)
>
>
>
> From a design perspective, dampening is always best done at the lowest
> layer possible. In most cases, interface layer dampening is best. If that
> is not reliable for some reason, then move one layer up – not two layers up.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, January 30, 2022 10:05 AM
> *To:* Ketan Talaulikar 
> *Cc:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>; lsr 
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Ketan,
>
>
>
> I would like to point out that the draft discusses the BFD "dampening" or
> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
> include such mechanisms in a protocol-agnostic manner.
>
>
>
> BFD dampening or hold-time are completely orthogonal to my point. Both
> have nothing to do with it.
>
>
>
> Those timers only fire when BFD goes down. In my example BFD does not go
> down. But we want to bring up the client adj. only after X ms/sec/min etc
> ...of normal BFD operation if no failure is detected during that timer.
>
>
>
> This draft indicates that OSPF adjacency will "advance" in the neighbor
> FSM only after BFD reports UP.
>
>
>
> And that is exactly too soon. In fact if you do that today without waiting
> some time (if you retire the current OSPF timer) you will not help at all
> in the case you are trying to address.
>
>
>
> Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF
> adj. will get already established. It is really pretty simple.
>
>
>
> Thx,
>
> Robert.
>
>
>
> PS. And yes I think ISIS should also get fixed in that respect.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Robert,

We can update this text in the Introduction section as follows:

OLD

   Note that it is possible
   in some failure scenarios for the network to be in a state such that
   an OSPF adjacency can be established but a BFD session cannot be
   established and maintained.  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.

NEW

   A degraded or poor quality link may result in intermittent packet

   drops. In such scenarios, sometimes an OSPF adjacency may be still

   get established over such link, but a BFD session may get

   established or maintained over it given the more aggressive

   monitoring intervals supported by BFD.  The traffic that gets forwarded

 over such a link would experience packet drops and the failure of the

   BFD session establishment would not enable fast routing convergence.

   Frequent OSPF adjaceny flaps may occur over such links as OSPF brings up the

  adjacency only for it to be brought down again by BFD.


Thanks,
Ketan


On Sun, Jan 30, 2022 at 11:41 PM Robert Raszuk  wrote:

> Hi Ketan,
>
> > It explains the scenario of a noisy link that experiences traffic drops.
>
> The point is that BFD may or may not detect noisy links or links with
> "degraded or poor quality". There are many failure scenarios - especially
> brownouts - where BFD will continue to run just fine over a link and where
> at the same time user data will experience very poor performance.
>
> So stating in the RFC that BFD may help to detect such cases is simply
> very misleading (to say it gently :).
>
> And you are stating so exactly in the below sentence:
>
> *"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.*
>
> Thx,
> R.
>
>
> On Sun, Jan 30, 2022 at 6:03 PM Ketan Talaulikar 
> wrote:
>
>> Hi Robert,
>>
>> Thanks for your review and comments.
>>
>> This email is in response to your first point "overpromise".
>>
>> First, there is no text in the draft that "overpromises" that the strict
>> mode of operation detects "all forwarding" issues. We are talking about BFD
>> and its capabilities are well-known. It is not in the scope of this
>> document to discuss BFD capabilities and shortcomings (e.g. the MTU issue
>> you describe).
>>
>> The draft text that you have asked to remove is important. It explains
>> the scenario of a noisy link that experiences traffic drops. I am aware of
>> issues in production networks, where we've had OSPF adjacency flaps
>> continuously or sporadically due to OSPF adjacency coming up somehow but
>> then BFD bringing it down. This causes routing churn and service
>> degradation. This is one of the key drivers for this draft.
>>
>> However, welcome any text clarifications/suggestions for improving the
>> document.
>>
>> Thanks,
>> Ketan
>>
>>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Robert,

The draft text refers to dampening and hold-down. The latter can be used
also for the initial session bring-up. The descriptions of those BFD
mechanisms are outside the scope of this document. If this needs to be
standardized at the IETF, then (IMHO) it would be best taken up in the BFD
WG so it can be leveraged for other protocols and use-cases as well.

We can update the text in Sec 5 to clarify this aspect as below.

OLD

   In network deployments with noisy links or those with packet loss,
   BFD sessions may flap frequently.  In such scenarios, OSPF strict-
   mode for BFD may be deployed in conjunction with a BFD dampening or
   hold-down mechanism to avoid frequent adjacency flaps that cause
   routing churn.

NEW

   In network deployments with noisy links with packet loss,
   BFD sessions may flap frequently.  In such scenarios, OSPF strict-
   mode for BFD may be deployed in conjunction with mechanisms such as

   hold-down (to delay initial adjacency bring up) and dampening (to avoid

   frequent adjacency flaps) in BFD to avoid frequent OSPF adjacency

   flaps that cause routing churn. The details of these BFD mechanisms

   are outside the scope of this document.



Thanks,
Ketan


On Sun, Jan 30, 2022 at 11:35 PM Robert Raszuk  wrote:

> Hi Ketan,
>
> I would like to point out that the draft discusses the BFD "dampening" or
>> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
>> include such mechanisms in a protocol-agnostic manner.
>>
>
> BFD dampening or hold-time are completely orthogonal to my point. Both
> have nothing to do with it.
>
> Those timers only fire when BFD goes down. In my example BFD does not go
> down. But we want to bring up the client adj. only after X ms/sec/min etc
> ...of normal BFD operation if no failure is detected during that timer.
>
> This draft indicates that OSPF adjacency will "advance" in the neighbor
>> FSM only after BFD reports UP.
>>
>
> And that is exactly too soon. In fact if you do that today without waiting
> some time (if you retire the current OSPF timer) you will not help at all
> in the case you are trying to address.
>
> Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF
> adj. will get already established. It is really pretty simple.
>
> Thx,
> Robert.
>
> PS. And yes I think ISIS should also get fixed in that respect.
>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

sible for an OSPF
>>>router to support BFD operation in both strict-mode and normal mode
>>>across different interfaces or even different neighbors on the same
>>>multi-access interface.
>>>
>>>
>>> Gyan> So in the LAN case RFC 5882 OSPF should not be blocked with LLS data 
>>> block.
>>>
>>>
>> KT> We need to be able to interop and be backward compatible. That is the
>> main motivation. Normally, when all routers on a LAN support this spec,
>> they would all likely do strict-mode and not a mix.
>>
>>
>
> Gyan> The main motivation is to fix the problem with OSPF starting before
> BFD to be implemented so that there is backwards compatibility.I think
> you should break out scenarios into P2P and LAN scenario.  This is how I
> would reword.
>
>For Multi-access interfaces when BFD is enabled, but the strict-mode for
>operation has been signaled by multiple but not all neighbors, then an
>implementation SHOULD start the BFD session establishment only in
>2-Way state or higher state.  This makes it possible for an OSPF
>router to support BFD operation in both strict-mode and normal mode
>across different interfaces or even different neighbors.
>
>
>
>For interface with P2P subnet when BFD is enabled, but strict-mode for
>operation has been signaled by both neighbors, then an
>implementation SHOULD start the BFD session establishment at init state.
>
>In case one end of P2P link supports Strict mode and the other neighbor
>
>does not then BFD would come up in Normal mode.
>
>
>
>
>>> So I think that is what you are trying to say that BFD can come up after 
>>> OSPF is Up
>>>
>>> I see you mention 2-way but not fully Up.
>>>
>>>
>> KT> Full state comes after 2-way.
>>
>>
>>>  How would you stagger it allow BFD to come up
>>>
>>> in parallel to ospf still coming to Full state.
>>>
>>>
>> KT> I am not sure if I follow this question. In the non-strict mode of
>> operation, the OSPF adjacency can progress to its terminal state (e.g.
>> full) without any dependence on the BFD session establishment.
>>
>>
> Gyan> This was related to the interoperability with devices not
> supporting on LAN with mix of devices.  I think if we reword as I stated
> above specifying P2P and LAN scenario that would make it clearer.
>
>>
>>>
>>> Nit
>>>
>>>
>>>
>>> OLD
>>>
>>>
>>>When BFD is enabled on an interface over which we already have an
>>>existing OSPF adjacency, it would result in the router setting the
>>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>>up (i.e., in its terminal state of Full or 2-way with non-DR routers
>>>on a multi-access interface) with a neighbor that also supports
>>>strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>
>>>
>>>
>>> Gyan> 2-way is not terminal state even for DROther routers
>>>
>>
>> KT> We are talking about the Neighbor FSM State here.
>>
>>
> Gyan> Yes.  The verbiage is not clear.  Non DR is technically called
> DROther router I believe.  Also the DROther router would be in Full state
> and not 2-way, correct?
>
>>
>>> NEW
>>>
>>>When BFD is enabled on an interface over which we already have an
>>>existing OSPF adjacency, it would result in the router setting the
>>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>>up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther 
>>> routers
>>>on a multi-access interface) with a neighbor that also supports
>>>strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>
>>>
>>>
>>> Section 4.1 OSPFv3 IPv4 address family specifics
>>>
>>> Gyan> Why would you not have also OSPFV3 IPv6 address family specifics
>>>
>>
>> KT> Could you please check RFC5838 to know more about multi-AF operations
>> for OSPFv3?
>>
>
> Gyan>  I understand OSPFv3 MI separate control plane and data plane
> separate v4 and v6 adjacency I would think that as we have link local
> address and link local local LSA we need to still set the B bit flag to
> block the adjacency from forming for v6 control plane.   Imagine if no v4
> and v6 congruency and v6 had to signal the B bit as we cannot rely on v4
> instance for v

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

[Robert Raszuk]

Hi Les,

> the way to address that is to put a delay either before BFD attempts to
bring up a new session

No this will not work. The BFD session must be fully up and BFD has to have
a chance for normal operation for X units of time. (By normal I mean with
existing or new BFD extensions which is out of scope of this discussion).

> or a delay after achieving UP state before it signals UP to its clients –
such as OSPF.

This is exactly what I am describing. Except you think that now BFD should
hold on on a per client or per OSPF neighbor basis and I think that it is
clients who should hold on from reacting to signaled UP state.

The way you are suggesting puts unnecessary burden on BFD where from BFD
POV link went up at t0 and never went down. It is the client who may need
to delay his action depending on the nature of the client.

At least we got to the point that both of us are clear on the topic.
Before when I see dampening or hold times insertion only indicates that
there was a mismatch in understanding. And to your examples imagine that
this is a new interface and BFD was never up before on it. The
behavior should be identical.

Thx,
R.

On Sun, Jan 30, 2022 at 8:38 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Here is what you said (emphasis added):
>
>
>
> 
>
> 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.
>
> 
>
>
>
> Point #1: If you want BFD to do more testing (such as MTU testing) then
> clearly you need extensions to BFD (such as
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )
>
>
>
> Point #2: The existing timers (as Ketan points out are mentioned in
> Section 5) are applied today at the OSPF level precisely because OSPF does
> not currently have strict-mode operation. So in a flapping scenario you
> could see the following behavior:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)OSPF comes back up
>
> d)Link is still unstable – so traffic is being dropped some of the time –
> but perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often
> enough to keep the OSPF adjacency up)
>
>
>
> So some implementations have chosen to insert a delay following “b”. This
> doesn’t guarantee stability, but hopefully makes it less likely. And
> because OSPF today does NOT wait for BFD to come up, the delay has to be
> implemented at the OSPF level.
>
>
>
> Once you have strict mode support, the sequence becomes:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)BFD comes back up
>
> d)OSPF comes back up
>
>
>
> Now, if the concern is that BFD comes back up while the link is still
> unstable, the way to address that is to put a delay either before BFD
> attempts to bring up a new session or a delay after achieving UP state
> before it signals UP to its clients – such as OSPF. This is a better
> solution because all BFD clients benefit from this. Ad if the link is still
> unstable, it is more likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> (BTW, this behavior can be done w/o a BFD protocol extension – it is
> purely an implementation choice.)
>
>
>
> From a design perspective, dampening is always best done at the lowest
> layer possible. In most cases, interface layer dampening is best. If that
> is not reliable for some reason, then move one layer up – not two layers up.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, January 30, 2022 10:05 AM
> *To:* Ketan Talaulikar 
> *Cc:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>; lsr 
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Ketan,
>
>
>
> I would like to point out that the draft discusses the BFD "dampening" or
> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
> include such mechanisms in a protocol-agnostic manner.
>
>
>
> BFD dampening or hold-time are completely orthogonal to my point. Both
> have nothing to do with it.
>
>
>
> Those timers only fire when BFD goes down. In my example BFD does not go
> down. But we want to bring up the client adj. only after X ms/se

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

[Gyan Mishra]

that would make it clearer.

>
>>
>> Nit
>>
>>
>>
>> OLD
>>
>>
>>When BFD is enabled on an interface over which we already have an
>>existing OSPF adjacency, it would result in the router setting the
>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>up (i.e., in its terminal state of Full or 2-way with non-DR routers
>>on a multi-access interface) with a neighbor that also supports
>>strict-mode for BFD, then an implementation SHOULD NOT bring this
>>
>>
>>
>> Gyan> 2-way is not terminal state even for DROther routers
>>
>
> KT> We are talking about the Neighbor FSM State here.
>
>
Gyan> Yes.  The verbiage is not clear.  Non DR is technically called
DROther router I believe.  Also the DROther router would be in Full state
and not 2-way, correct?

>
>> NEW
>>
>>When BFD is enabled on an interface over which we already have an
>>existing OSPF adjacency, it would result in the router setting the
>>B-bit in its subsequent Hello packets.  If the adjacency is already
>>up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther 
>> routers
>>on a multi-access interface) with a neighbor that also supports
>>strict-mode for BFD, then an implementation SHOULD NOT bring this
>>
>>
>>
>> Section 4.1 OSPFv3 IPv4 address family specifics
>>
>> Gyan> Why would you not have also OSPFV3 IPv6 address family specifics
>>
>
> KT> Could you please check RFC5838 to know more about multi-AF operations
> for OSPFv3?
>

Gyan>  I understand OSPFv3 MI separate control plane and data plane
separate v4 and v6 adjacency I would think that as we have link local
address and link local local LSA we need to still set the B bit flag to
block the adjacency from forming for v6 control plane.   Imagine if no v4
and v6 congruency and v6 had to signal the B bit as we cannot rely on v4
instance for v6 adjacency since it’s separate adjacencies.  Also for IPv6
only scenario as well now you have to signal the B bit somehow so that flag
needs to be specified in the specification.

>
> Thanks,
> Ketan
>
>
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Jan 29, 2022 at 9:28 PM Aijun Wang 
>> wrote:
>>
>>> Hi, Acee and Ketan:
>>> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>>> What I want to express is that you brought up the full mesh BFD sessions
>>> among the routers within such network type. Is it necessary to bring some
>>> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
>>> are established between the DRother and DR/BDR router?
>>> If the BFD session is bootstrapped after the OSPF adjacency is
>>> established, there will be no such extra/useless BFD sessions
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>>>
>>> 
>>>
>>> Speaking as WG member:
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>> If you want a per-neighbor state and route, you have to use P2MP. This
>>> scope of this draft isn’t to try and make NBMA/Broadcast model something
>>> that it is not. This is should be common knowledge and the draft needn’t
>>> address it. Those of us who remember ATM emulated LANs (which were not
>>> always symmetrically reliable) will recall using P2MP on an inherently
>>> multi-access network.
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Aijun Wang 
>>> *Date: *Saturday, January 29, 2022 at 3:46 AM
>>> *To: *'Ketan Talaulikar' 
>>> *Cc: *"lsr@ietf.org" , "
>>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' <
>>> af...@bloomberg.net>, Acee Lindem 
>>> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi, Ketan:
>>>
>>> OK, then back to my original question:
>>>
>>> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
>>> the OSPF adjacency(between the DRother and DR/BDR)?
>>>
>>> If not, then the traffic between these DRothers will be lost; If yes, it
>>> seems strange, because the BFD session between the DRother and DR/BDR may
>>> be still UP.
>>>
>>> I think here ther

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

[Les Ginsberg (ginsberg)]

Robert –

Here is what you said (emphasis added):


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.


Point #1: If you want BFD to do more testing (such as MTU testing) then clearly 
you need extensions to BFD (such as 
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )

Point #2: The existing timers (as Ketan points out are mentioned in Section 5) 
are applied today at the OSPF level precisely because OSPF does not currently 
have strict-mode operation. So in a flapping scenario you could see the 
following behavior:

a)BFD goes down
b)OSPF goes down in response to BFD
c)OSPF comes back up
d)Link is still unstable – so traffic is being dropped some of the time – but 
perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often enough to 
keep the OSPF adjacency up)

So some implementations have chosen to insert a delay following “b”. This 
doesn’t guarantee stability, but hopefully makes it less likely. And because 
OSPF today does NOT wait for BFD to come up, the delay has to be implemented at 
the OSPF level.

Once you have strict mode support, the sequence becomes:

a)BFD goes down
b)OSPF goes down in response to BFD
c)BFD comes back up
d)OSPF comes back up

Now, if the concern is that BFD comes back up while the link is still unstable, 
the way to address that is to put a delay either before BFD attempts to bring 
up a new session or a delay after achieving UP state before it signals UP to 
its clients – such as OSPF. This is a better solution because all BFD clients 
benefit from this. Ad if the link is still unstable, it is more likely that the 
BFD session will go down during the delay period than it would be for OSPF 
because the BFD timers are significantly more aggressive.
(BTW, this behavior can be done w/o a BFD protocol extension – it is purely an 
implementation choice.)

From a design perspective, dampening is always best done at the lowest layer 
possible. In most cases, interface layer dampening is best. If that is not 
reliable for some reason, then move one layer up – not two layers up.

   Les


From: Robert Raszuk 
Sent: Sunday, January 30, 2022 10:05 AM
To: Ketan Talaulikar 
Cc: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
; lsr 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan,

I would like to point out that the draft discusses the BFD "dampening" or 
"hold-down" mechanism in Sec 5. We are aware of BFD implementations that 
include such mechanisms in a protocol-agnostic manner.

BFD dampening or hold-time are completely orthogonal to my point. Both have 
nothing to do with it.

Those timers only fire when BFD goes down. In my example BFD does not go down. 
But we want to bring up the client adj. only after X ms/sec/min etc ...of 
normal BFD operation if no failure is detected during that timer.

This draft indicates that OSPF adjacency will "advance" in the neighbor FSM 
only after BFD reports UP.

And that is exactly too soon. In fact if you do that today without waiting some 
time (if you retire the current OSPF timer) you will not help at all in the 
case you are trying to address.

Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF adj. 
will get already established. It is really pretty simple.

Thx,
Robert.

PS. And yes I think ISIS should also get fixed in that respect.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hi Ketan,

> It explains the scenario of a noisy link that experiences traffic drops.

The point is that BFD may or may not detect noisy links or links with
"degraded or poor quality". There are many failure scenarios - especially
brownouts - where BFD will continue to run just fine over a link and where
at the same time user data will experience very poor performance.

So stating in the RFC that BFD may help to detect such cases is simply very
misleading (to say it gently :).

And you are stating so exactly in the below sentence:

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

Thx,
R.


On Sun, Jan 30, 2022 at 6:03 PM Ketan Talaulikar 
wrote:

> Hi Robert,
>
> Thanks for your review and comments.
>
> This email is in response to your first point "overpromise".
>
> First, there is no text in the draft that "overpromises" that the strict
> mode of operation detects "all forwarding" issues. We are talking about BFD
> and its capabilities are well-known. It is not in the scope of this
> document to discuss BFD capabilities and shortcomings (e.g. the MTU issue
> you describe).
>
> The draft text that you have asked to remove is important. It explains the
> scenario of a noisy link that experiences traffic drops. I am aware of
> issues in production networks, where we've had OSPF adjacency flaps
> continuously or sporadically due to OSPF adjacency coming up somehow but
> then BFD bringing it down. This causes routing churn and service
> degradation. This is one of the key drivers for this draft.
>
> However, welcome any text clarifications/suggestions for improving the
> document.
>
> Thanks,
> Ketan
>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hi Ketan,

I would like to point out that the draft discusses the BFD "dampening" or
> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
> include such mechanisms in a protocol-agnostic manner.
>

BFD dampening or hold-time are completely orthogonal to my point. Both have
nothing to do with it.

Those timers only fire when BFD goes down. In my example BFD does not go
down. But we want to bring up the client adj. only after X ms/sec/min etc
...of normal BFD operation if no failure is detected during that timer.

This draft indicates that OSPF adjacency will "advance" in the neighbor FSM
> only after BFD reports UP.
>

And that is exactly too soon. In fact if you do that today without waiting
some time (if you retire the current OSPF timer) you will not help at all
in the case you are trying to address.

Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF
adj. will get already established. It is really pretty simple.

Thx,
Robert.

PS. And yes I think ISIS should also get fixed in that respect.

>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

 am not sure if I follow this question. In the non-strict mode of
operation, the OSPF adjacency can progress to its terminal state (e.g.
full) without any dependence on the BFD session establishment.


>
>
> Nit
>
>
>
> OLD
>
>
>When BFD is enabled on an interface over which we already have an
>existing OSPF adjacency, it would result in the router setting the
>B-bit in its subsequent Hello packets.  If the adjacency is already
>up (i.e., in its terminal state of Full or 2-way with non-DR routers
>on a multi-access interface) with a neighbor that also supports
>strict-mode for BFD, then an implementation SHOULD NOT bring this
>
>
>
> Gyan> 2-way is not terminal state even for DROther routers
>

KT> We are talking about the Neighbor FSM State here.


>
> NEW
>
>When BFD is enabled on an interface over which we already have an
>existing OSPF adjacency, it would result in the router setting the
>B-bit in its subsequent Hello packets.  If the adjacency is already
>up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther routers
>on a multi-access interface) with a neighbor that also supports
>strict-mode for BFD, then an implementation SHOULD NOT bring this
>
>
>
> Section 4.1 OSPFv3 IPv4 address family specifics
>
> Gyan> Why would you not have also OSPFV3 IPv6 address family specifics
>

KT> Could you please check RFC5838 to know more about multi-AF operations
for OSPFv3?

Thanks,
Ketan


>
> Kind Regards
>
> Gyan
>
> On Sat, Jan 29, 2022 at 9:28 PM Aijun Wang 
> wrote:
>
>> Hi, Acee and Ketan:
>> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>> What I want to express is that you brought up the full mesh BFD sessions
>> among the routers within such network type. Is it necessary to bring some
>> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
>> are established between the DRother and DR/BDR router?
>> If the BFD session is bootstrapped after the OSPF adjacency is
>> established, there will be no such extra/useless BFD sessions
>>
>> Aijun Wang
>> China Telecom
>>
>> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>>
>> 
>>
>> Speaking as WG member:
>>
>>
>>
>> Hi Aijun,
>>
>> If you want a per-neighbor state and route, you have to use P2MP. This
>> scope of this draft isn’t to try and make NBMA/Broadcast model something
>> that it is not. This is should be common knowledge and the draft needn’t
>> address it. Those of us who remember ATM emulated LANs (which were not
>> always symmetrically reliable) will recall using P2MP on an inherently
>> multi-access network.
>>
>> Acee
>>
>>
>>
>> *From: *Aijun Wang 
>> *Date: *Saturday, January 29, 2022 at 3:46 AM
>> *To: *'Ketan Talaulikar' 
>> *Cc: *"lsr@ietf.org" , "
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' <
>> af...@bloomberg.net>, Acee Lindem 
>> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> Hi, Ketan:
>>
>> OK, then back to my original question:
>>
>> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
>> the OSPF adjacency(between the DRother and DR/BDR)?
>>
>> If not, then the traffic between these DRothers will be lost; If yes, it
>> seems strange, because the BFD session between the DRother and DR/BDR may
>> be still UP.
>>
>> I think here there are some mismatch between the BFD sessions and the
>> OSPF adjacency in Broadcast/NBMA network, then some clarification for the
>> procedures are needed.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
>> Talaulikar
>> *Sent:* Saturday, January 29, 2022 4:22 PM
>> *To:* Aijun Wang 
>> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
>> Fu ; Acee Lindem (acee) > 40cisco@dmarc.ietf.org>
>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> Hi Aijun,
>>
>>
>>
>> The choice of the term "adjacency" was not accurate in my previous
>> response to you. I meant "neighborship".
>>
>

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

[Ketan Talaulikar]

Hi Aijun,

There is a need for a BFD session to be established between neighboring
routers which directly forward data between them to ensure reachability
between them. That is my understanding of various implementations and
deployments at operators. This is independent of the strict mode of
operation.

Perhaps you have a different requirement for "optimization of BFD sessions
on multi-access networks"? If so, it would be clearer if you could put that
requirement/proposal together as a draft for the WG to review. Also, that
would be in any way independent of this specification since what you are
referring to is the base use of BFD by OSPF.

Thanks,
Ketan


On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang 
wrote:

> Hi, Acee and Ketan:
> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
> What I want to express is that you brought up the full mesh BFD sessions
> among the routers within such network type. Is it necessary to bring some
> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
> are established between the DRother and DR/BDR router?
> If the BFD session is bootstrapped after the OSPF adjacency is
> established, there will be no such extra/useless BFD sessions
>
> Aijun Wang
> China Telecom
>
> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>
> 
>
> Speaking as WG member:
>
>
>
> Hi Aijun,
>
> If you want a per-neighbor state and route, you have to use P2MP. This
> scope of this draft isn’t to try and make NBMA/Broadcast model something
> that it is not. This is should be common knowledge and the draft needn’t
> address it. Those of us who remember ATM emulated LANs (which were not
> always symmetrically reliable) will recall using P2MP on an inherently
> multi-access network.
>
> Acee
>
>
>
> *From: *Aijun Wang 
> *Date: *Saturday, January 29, 2022 at 3:46 AM
> *To: *'Ketan Talaulikar' 
> *Cc: *"lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' <
> af...@bloomberg.net>, Acee Lindem 
> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi, Ketan:
>
> OK, then back to my original question:
>
> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
> the OSPF adjacency(between the DRother and DR/BDR)?
>
> If not, then the traffic between these DRothers will be lost; If yes, it
> seems strange, because the BFD session between the DRother and DR/BDR may
> be still UP.
>
> I think here there are some mismatch between the BFD sessions and the OSPF
> adjacency in Broadcast/NBMA network, then some clarification for the
> procedures are needed.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *To:* Aijun Wang 
> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
> Fu ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Aijun,
>
>
>
> The choice of the term "adjacency" was not accurate in my previous
> response to you. I meant "neighborship".
>
>
>
> That said, the substance of my response still remains the same.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang 
> wrote:
>
> Hi, Ketan:
>
> For the Broadcast/NMBA network type, if you establish BFD sessions
> before the DR/BDR selection, then there will be full mesh BFD sessions
> within the routers on such media type?
>
> Instead of establishing the BFD sessions with DR/BDR only, the same as the
> OSPF adjacency relationship? If so, if one of the BFD session that not with
> the DR/BDR is DOWN, what’s the action then?
>
>
>
> KT> I think there is perhaps a misunderstanding of the purpose of BFD use
> with OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD
> is used to verify bidirectional connectivity between neighbors to ensure
> data may be forwarded between them. OSPF adjacency is built between every
> router in a LAN since they can directly forward packets between themselves.
>
> *[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between the
> routers and DR/BDR.  *
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
&

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

[Ketan Talaulikar]

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 <
muthu.a...@gmail.com> 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)  40cisco@dmarc.ietf.org> 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
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

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


On Sun, Jan 30, 2022 at 8:43 PM Robert Raszuk  wrote:

> 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) <
> af...@bloomberg.net> 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.
>>
>>
>>
>>
>> From: rob...@raszuk.net At: 01/29/22 15:20:06 UTC-5:00
>> To: ginsb...@cisco.com
>> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) ,
>> a...@cisco.com, ketant.i...@gmail.com,
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
>> 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 

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

[Ketan Talaulikar]

Hi Robert,

Thanks for your review again and your comments/discussions.

This thread is about your second point "timer".

I would like to point out that the draft discusses the BFD "dampening" or
"hold-down" mechanism in Sec 5. We are aware of BFD implementations that
include such mechanisms in a protocol-agnostic manner.

This draft indicates that OSPF adjacency will "advance" in the neighbor FSM
only after BFD reports UP.  The BFD mechanisms/timers are outside the scope
of this document.

Please also see a further response on this point in your latest email on
this thread.

Thanks,
Ketan


On Sun, Jan 30, 2022 at 2:19 AM Robert Raszuk  wrote:

> Hi Les,
>
> That timer and its consistency on both ends clearly belongs to OSPF not to
>> BFD.
>>
>
>
>> *[LES:] I disagree. The definition of UP state belongs to the BFD
>> protocol/implementation.*
>>
>> *If you don’t want BFD clients (like OSPF) to react “too quickly” then
>> build additional config/logic into your BFD implementation so it does not
>> signal UP state before additional criteria is met – do not make each BFD
>> client (and there could be multiple for a given session) configure its own
>> definition of BFD UP.*
>>
>
> I think we are looking at this from different perspectives.
>
> I am saying bring BFD UP and allow X seconds/minutes/hours to run a
> sequence of testing before bringing OSPF adj up.
>
> You are saying do not declare BFD as UP before all of those testing
> passes. That test sequence could be just running vanilla normal BFD for X
> seconds/minutes/hours.
>
> That would require introducing a completely new BFD state. Worse, that
> timer may be very different on a per type of interface basis as each
> interface type has completely different characteristics. Also such timer
> would need to have a different value on a per BFD client basis. (For
> example OSPF adj UP could be very different then PE-PE BFD for BGP as PULSE
> alternative :)
>
> Sorry I really do not think this belongs to BFD at all. It is a local
> client thing how long from t0 = BFD UP it will wait before proceeding
> further.
>
> And last but not least - such extended testing does not need to kick in
> every time interface flaps. Maybe the operator only wants to run it during
> maintenance windows once per day ? Or once per week ?
>
> But I am not going to even remotely hope I can convince you :) So let's
> forget it.
>
> Cheers,
> R/
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Robert,

Thanks for your review and comments.

This email is in response to your first point "overpromise".

First, there is no text in the draft that "overpromises" that the strict
mode of operation detects "all forwarding" issues. We are talking about BFD
and its capabilities are well-known. It is not in the scope of this
document to discuss BFD capabilities and shortcomings (e.g. the MTU issue
you describe).

The draft text that you have asked to remove is important. It explains the
scenario of a noisy link that experiences traffic drops. I am aware of
issues in production networks, where we've had OSPF adjacency flaps
continuously or sporadically due to OSPF adjacency coming up somehow but
then BFD bringing it down. This causes routing churn and service
degradation. This is one of the key drivers for this draft.

However, welcome any text clarifications/suggestions for improving the
document.

Thanks,
Ketan


On Sun, Jan 30, 2022 at 12:54 AM Robert Raszuk  wrote:

> 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.
>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Robert


On Sun, Jan 30, 2022 at 10:13 AM Robert Raszuk  wrote:

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

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?

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

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
> determine if the link over which we are to establish IGP adj. meets the
> requirements.
>

 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.

>
> Kind regards,
> Robert
>
>
> On Sun, Jan 30, 2022 at 3:28 PM Albert Fu (BLOOMBERG/ 120 PARK) <
> af...@bloomberg.net> 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.
>>
>>
>>
>>
>> From: rob...@raszuk.net At: 01/29/22 15:20:06 UTC-5:00
>> To: ginsb...@cisco.com
>> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) ,
>> a...@cisco.com, ketant.i...@gmail.com,
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
>> Subject: Re: [Lsr] Working Group Last Call for "OSPF

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

[Gyan Mishra]

t; No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>> What I want to express is that you brought up the full mesh BFD sessions
>> among the routers within such network type. Is it necessary to bring some
>> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
>> are established between the DRother and DR/BDR router?
>> If the BFD session is bootstrapped after the OSPF adjacency is
>> established, there will be no such extra/useless BFD sessions
>>
>> Aijun Wang
>> China Telecom
>>
>> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
>>
>> 
>>
>> Speaking as WG member:
>>
>>
>>
>> Hi Aijun,
>>
>> If you want a per-neighbor state and route, you have to use P2MP. This
>> scope of this draft isn’t to try and make NBMA/Broadcast model something
>> that it is not. This is should be common knowledge and the draft needn’t
>> address it. Those of us who remember ATM emulated LANs (which were not
>> always symmetrically reliable) will recall using P2MP on an inherently
>> multi-access network.
>>
>> Acee
>>
>>
>>
>> *From: *Aijun Wang 
>> *Date: *Saturday, January 29, 2022 at 3:46 AM
>> *To: *'Ketan Talaulikar' 
>> *Cc: *"lsr@ietf.org" , "
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' <
>> af...@bloomberg.net>, Acee Lindem 
>> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> Hi, Ketan:
>>
>> OK, then back to my original question:
>>
>> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
>> the OSPF adjacency(between the DRother and DR/BDR)?
>>
>> If not, then the traffic between these DRothers will be lost; If yes, it
>> seems strange, because the BFD session between the DRother and DR/BDR may
>> be still UP.
>>
>> I think here there are some mismatch between the BFD sessions and the
>> OSPF adjacency in Broadcast/NBMA network, then some clarification for the
>> procedures are needed.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
>> Talaulikar
>> *Sent:* Saturday, January 29, 2022 4:22 PM
>> *To:* Aijun Wang 
>> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
>> Fu ; Acee Lindem (acee) > 40cisco@dmarc.ietf.org>
>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> Hi Aijun,
>>
>>
>>
>> The choice of the term "adjacency" was not accurate in my previous
>> response to you. I meant "neighborship".
>>
>>
>>
>> That said, the substance of my response still remains the same.
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang 
>> wrote:
>>
>> Hi, Ketan:
>>
>> For the Broadcast/NMBA network type, if you establish BFD sessions
>> before the DR/BDR selection, then there will be full mesh BFD sessions
>> within the routers on such media type?
>>
>> Instead of establishing the BFD sessions with DR/BDR only, the same as
>> the OSPF adjacency relationship? If so, if one of the BFD session that not
>> with the DR/BDR is DOWN, what’s the action then?
>>
>>
>>
>> KT> I think there is perhaps a misunderstanding of the purpose of BFD use
>> with OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD
>> is used to verify bidirectional connectivity between neighbors to ensure
>> data may be forwarded between them. OSPF adjacency is built between every
>> router in a LAN since they can directly forward packets between themselves.
>>
>> *[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between
>> the routers and DR/BDR.  *
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Ketan Talaulikar 
>> *Sent:* Saturday, January 29, 2022 11:13 AM
>> *To:* Aijun Wang 
>> *Cc:* Acee Lindem (acee) ; lsr

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

[Robert Raszuk]

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) <
af...@bloomberg.net> 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.
>
>
>
>
> From: rob...@raszuk.net At: 01/29/22 15:20:06 UTC-5:00
> To: ginsb...@cisco.com
> Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , a...@cisco.com,
> ketant.i...@gmail.com, draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,
> lsr@ietf.org
> 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) <
> ginsb...@cisco.com> 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 

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

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: rob...@raszuk.net At: 01/29/22 15:20:06 UTC-5:00To:  ginsb...@cisco.com
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  a...@cisco.com,  
ketant.i...@gmail.com,  draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  
lsr@ietf.org
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)  
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  On Behalf Of  Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) 
Cc: Ketan Talaulikar ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu ; 
lsr 
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 a

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

[Muthu Arul Mozhi Perumal]

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)  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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

ng 
> *Date: *Saturday, January 29, 2022 at 3:46 AM
> *To: *'Ketan Talaulikar' 
> *Cc: *"lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' <
> af...@bloomberg.net>, Acee Lindem 
> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi, Ketan:
>
> OK, then back to my original question:
>
> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
> the OSPF adjacency(between the DRother and DR/BDR)?
>
> If not, then the traffic between these DRothers will be lost; If yes, it
> seems strange, because the BFD session between the DRother and DR/BDR may
> be still UP.
>
> I think here there are some mismatch between the BFD sessions and the OSPF
> adjacency in Broadcast/NBMA network, then some clarification for the
> procedures are needed.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *To:* Aijun Wang 
> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
> Fu ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Aijun,
>
>
>
> The choice of the term "adjacency" was not accurate in my previous
> response to you. I meant "neighborship".
>
>
>
> That said, the substance of my response still remains the same.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang 
> wrote:
>
> Hi, Ketan:
>
> For the Broadcast/NMBA network type, if you establish BFD sessions
> before the DR/BDR selection, then there will be full mesh BFD sessions
> within the routers on such media type?
>
> Instead of establishing the BFD sessions with DR/BDR only, the same as the
> OSPF adjacency relationship? If so, if one of the BFD session that not with
> the DR/BDR is DOWN, what’s the action then?
>
>
>
> KT> I think there is perhaps a misunderstanding of the purpose of BFD use
> with OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD
> is used to verify bidirectional connectivity between neighbors to ensure
> data may be forwarded between them. OSPF adjacency is built between every
> router in a LAN since they can directly forward packets between themselves.
>
> *[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between the
> routers and DR/BDR.  *
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Saturday, January 29, 2022 11:13 AM
> *To:* Aijun Wang 
> *Cc:* Acee Lindem (acee) ; lsr@ietf.org;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Aijun,
>
>
>
> Please check inline below.
>
>
>
>
>
> On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang 
> wrote:
>
> Hi, Acee:
>
>
>
> Yes. Then I think the sentence in
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode#section-2
> as the following should be relaxed:
>
> “A router MUST include the LLS block with the LLS Type 1 Extended
>
>Options and Flags TLV with the B-bit set in its Hello and DD packets
>
>when strict-mode for BFD is enabled on the link.”
>
> It seems that there is no use for such information being included in the
> DD packets.
>
>
>
> KT> Since LLS is present in both Hello and DD packets, not including the B
> bit in DD packets will result in a different LLS options being seen in
> Hello and DD. This can trigger the change in LLS option logic
> unnecessarily. Hence, to keep things simple and consistent (and this should
> be for technically all LLS options), it makes sense to include them in both
> Hello and DD packets.
>
>
>
>
>
> And, one more question to the Authors of this draft:
>
> What’s the procedures for the interaction of BFD session and OSPF
> adjacency establishment in the Broadcast/NBMA network type interface, which
> is involved the DR/BDR election procedures?  The BFD session establishment
> should be after the DR/BDR election?
>
> Should the procedures in section 4 be

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

[Aijun Wang]

Hi, Acee and Ketan:
No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
What I want to express is that you brought up the full mesh BFD sessions among 
the routers within such network type. Is it necessary to bring some of them(the 
BFD sessions between DRothers) to DOWN after the OSPF adjacency are established 
between the DRother and DR/BDR router?
If the BFD session is bootstrapped after the OSPF adjacency is established, 
there will be no such extra/useless BFD sessions 

Aijun Wang
China Telecom

> On Jan 30, 2022, at 02:45, Acee Lindem (acee)  wrote:
> 
> 
> Speaking as WG member:
>  
> Hi Aijun,
> If you want a per-neighbor state and route, you have to use P2MP. This scope 
> of this draft isn’t to try and make NBMA/Broadcast model something that it is 
> not. This is should be common knowledge and the draft needn’t address it. 
> Those of us who remember ATM emulated LANs (which were not always 
> symmetrically reliable) will recall using P2MP on an inherently multi-access 
> network.
> Acee
>  
> From: Aijun Wang 
> Date: Saturday, January 29, 2022 at 3:46 AM
> To: 'Ketan Talaulikar' 
> Cc: "lsr@ietf.org" , 
> "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
> , 'Albert Fu' 
> , Acee Lindem 
> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>  
> Hi, Ketan:
> OK, then back to my original question:
> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN the 
> OSPF adjacency(between the DRother and DR/BDR)?
> If not, then the traffic between these DRothers will be lost; If yes, it 
> seems strange, because the BFD session between the DRother and DR/BDR may be 
> still UP.
> I think here there are some mismatch between the BFD sessions and the OSPF 
> adjacency in Broadcast/NBMA network, then some clarification for the 
> procedures are needed.
>  
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: lsr-boun...@ietf.org  On Behalf Of Ketan 
> Talaulikar
> Sent: Saturday, January 29, 2022 4:22 PM
> To: Aijun Wang 
> Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
> ; Acee Lindem (acee) 
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>  
> Hi Aijun,
>  
> The choice of the term "adjacency" was not accurate in my previous response 
> to you. I meant "neighborship". 
>  
> That said, the substance of my response still remains the same.
>  
> Thanks,
> Ketan
>  
>  
> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang  wrote:
> Hi, Ketan:
> For the Broadcast/NMBA network type, if you establish BFD sessions before 
> the DR/BDR selection, then there will be full mesh BFD sessions within the 
> routers on such media type? 
> Instead of establishing the BFD sessions with DR/BDR only, the same as the 
> OSPF adjacency relationship? If so, if one of the BFD session that not with 
> the DR/BDR is DOWN, what’s the action then?
>  
> KT> I think there is perhaps a misunderstanding of the purpose of BFD use 
> with OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD is 
> used to verify bidirectional connectivity between neighbors to ensure data 
> may be forwarded between them. OSPF adjacency is built between every router 
> in a LAN since they can directly forward packets between themselves. 
> [WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between the 
> routers and DR/BDR. 
>  
> Thanks,
> Ketan
>  
>  
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: Ketan Talaulikar  
> Sent: Saturday, January 29, 2022 11:13 AM
> To: Aijun Wang 
> Cc: Acee Lindem (acee) ; lsr@ietf.org; 
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>  
> Hi Aijun,
>  
> Please check inline below.
>  
>  
> On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang  wrote:
> Hi, Acee:
>  
> Yes. Then I think the sentence in 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode#section-2
>  as the following should be relaxed:
> “A router MUST include the LLS block with the LLS Type 1 Extended
>Options and Flags TLV with the B-bit set in its Hello and DD packets
>when strict-mode for BFD is enabled on the link.”
> It seems that there is no use for such information being included in the DD 
> packets.
>  
> KT> Since LLS is present in both Hello and DD packets, not including the B 
> bit in DD packets will result in a 

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

[Robert Raszuk]

Hi Les,

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


> *[LES:] I disagree. The definition of UP state belongs to the BFD
> protocol/implementation.*
>
> *If you don’t want BFD clients (like OSPF) to react “too quickly” then
> build additional config/logic into your BFD implementation so it does not
> signal UP state before additional criteria is met – do not make each BFD
> client (and there could be multiple for a given session) configure its own
> definition of BFD UP.*
>

I think we are looking at this from different perspectives.

I am saying bring BFD UP and allow X seconds/minutes/hours to run a
sequence of testing before bringing OSPF adj up.

You are saying do not declare BFD as UP before all of those testing passes.
That test sequence could be just running vanilla normal BFD for X
seconds/minutes/hours.

That would require introducing a completely new BFD state. Worse, that
timer may be very different on a per type of interface basis as each
interface type has completely different characteristics. Also such timer
would need to have a different value on a per BFD client basis. (For
example OSPF adj UP could be very different then PE-PE BFD for BGP as PULSE
alternative :)

Sorry I really do not think this belongs to BFD at all. It is a local
client thing how long from t0 = BFD UP it will wait before proceeding
further.

And last but not least - such extended testing does not need to kick in
every time interface flaps. Maybe the operator only wants to run it during
maintenance windows once per day ? Or once per week ?

But I am not going to even remotely hope I can convince you :) So let's
forget it.

Cheers,
R/
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Robert -

From: Robert Raszuk 
Sent: Saturday, January 29, 2022 12:20 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Ketan Talaulikar 
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert 
Fu ; lsr 
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.
[LES:] I disagree. The definition of UP state belongs to the BFD 
protocol/implementation.
If you don’t want BFD clients (like OSPF) to react “too quickly” then build 
additional config/logic into your BFD implementation so it does not signal UP 
state before additional criteria is met – do not make each BFD client (and 
there could be multiple for a given session) configure its own definition of 
BFD UP.

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.

[LES:] I don’t know if Albert and I disagree.
I am saying that the implementations I am familiar with have introduced this 
capability for OSPF precisely because OSPF did not have strict mode support as 
defined in this draft.
There has been no need for this with IS-IS – which has had equivalent support 
(RFC 6213) for many years.
And once OSPF strict-mode support becomes widely deployed there won’t be a need 
for such a timer for OSPF either.

   Les

Kind regards,
R.
















On Sat, Jan 29, 2022 at 9:08 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> 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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>
Cc: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>;
 Albert Fu mailto:af...@bloomberg.net>>; lsr 
mailto:lsr@ietf.org>>
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 B

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

[Robert Raszuk]

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) 
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  *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, January 29, 2022 11:25 AM
> *To:* Acee Lindem (acee) 
> *Cc:* Ketan Talaulikar ;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>; lsr 
> *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.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

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  On Behalf Of Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) 
Cc: Ketan Talaulikar ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu ; 
lsr 
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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Acee,


> I don’t anyone has implemented the later capability. This MTU test
> extension could be added in a separate draft if there were a strong
> requirement.
>

I think you are mixing an example of what BFD could be doing to make sure
the link is fine with the delay timer allowing it to do whatever it needs.

The former is a local operator's decision. The latter IMO could be added to
the draft to make the interoperability seamless. But this is just a
suggestion/hint. Nothing more.

Many thx,
R.


>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Saturday, January 29, 2022 at 2:25 PM
To: Acee Lindem 
Cc: Ketan Talaulikar , lsr , 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
, Albert Fu 
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."

That would be fine with me but I’ll defer to the authors.

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.

I don’t anyone has implemented the later capability. This MTU test extension 
could be added in a separate draft if there were a strong requirement.

Thanks,
Acee

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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.

>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Speaking as Document Shepherd:

Hi Robert,

From: Robert Raszuk 
Date: Saturday, January 29, 2022 at 11:15 AM
To: Ketan Talaulikar 
Cc: lsr , "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
, Albert Fu 
, Acee Lindem 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan and all,

I support this draft - it is a useful addition.

There are two elements which I would suggest to adjust in the text before 
publication.

#1 Overpromise

Even below you say:

> Since there is a issue with forwarding (which is what BFD detects)

and in the text we see:

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

Reader may get an impression that if he enables strict mode he is 100% safe. 
Sure he is safer then before but not 100% safe.

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

Real networks prove that there are classes of failures which BFD can not 
detect. And Albert knows them too :)

For example some emulated circuits can experience periodic drops only at some 
MTUs and only when link utilization reaches X %. While there is ongoing 
extension to BFD to fill it with payload I don't think that BFD can be useful 
to also saturate say in 80% 10G link with probes to test it well before 
allowing OSPF to be established.

#2 Timer

What I find missing in the draft is a mutually (between OSPF peers) timer fired 
after BFD session is up which in OSPF could hold on allowing BFD to do some 
more testing before declaring adj to be established. I think just bringing OSPF 
adj immediately after the BFD session is up is not a good thing. Keep in mind 
that we are bringing the interface up so by applying such a timer we are not 
dropping packets .. in fact quite the reverse we are making sure user packets 
would not be dropped.

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.

Thanks,
Acee

Cheers,
Robert

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Speaking as WG member:

Hi Aijun,
If you want a per-neighbor state and route, you have to use P2MP. This scope of 
this draft isn’t to try and make NBMA/Broadcast model something that it is not. 
This is should be common knowledge and the draft needn’t address it. Those of 
us who remember ATM emulated LANs (which were not always symmetrically 
reliable) will recall using P2MP on an inherently multi-access network.
Acee

From: Aijun Wang 
Date: Saturday, January 29, 2022 at 3:46 AM
To: 'Ketan Talaulikar' 
Cc: "lsr@ietf.org" , 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
, 'Albert Fu' 
, Acee Lindem 
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:
OK, then back to my original question:
If one of the BFD session(between DRothers) is DOWN, will it bring DOWN the 
OSPF adjacency(between the DRother and DR/BDR)?
If not, then the traffic between these DRothers will be lost; If yes, it seems 
strange, because the BFD session between the DRother and DR/BDR may be still UP.
I think here there are some mismatch between the BFD sessions and the OSPF 
adjacency in Broadcast/NBMA network, then some clarification for the procedures 
are needed.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org  On Behalf Of Ketan Talaulikar
Sent: Saturday, January 29, 2022 4:22 PM
To: Aijun Wang 
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
; Acee Lindem (acee) 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

The choice of the term "adjacency" was not accurate in my previous response to 
you. I meant "neighborship".

That said, the substance of my response still remains the same.

Thanks,
Ketan


On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Ketan:
For the Broadcast/NMBA network type, if you establish BFD sessions before 
the DR/BDR selection, then there will be full mesh BFD sessions within the 
routers on such media type?
Instead of establishing the BFD sessions with DR/BDR only, the same as the OSPF 
adjacency relationship? If so, if one of the BFD session that not with the 
DR/BDR is DOWN, what’s the action then?

KT> I think there is perhaps a misunderstanding of the purpose of BFD use with 
OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD is used to 
verify bidirectional connectivity between neighbors to ensure data may be 
forwarded between them. OSPF adjacency is built between every router in a LAN 
since they can directly forward packets between themselves.
[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between the 
routers and DR/BDR.

Thanks,
Ketan



Best Regards

Aijun Wang
China Telecom

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>;
 Albert Fu mailto:af...@bloomberg.net>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

Please check inline below.


On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Acee:

Yes. Then I think the sentence in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode#section-2
 as the following should be relaxed:
“A router MUST include the LLS block with the LLS Type 1 Extended
   Options and Flags TLV with the B-bit set in its Hello and DD packets
   when strict-mode for BFD is enabled on the link.”
It seems that there is no use for such information being included in the DD 
packets.

KT> Since LLS is present in both Hello and DD packets, not including the B bit 
in DD packets will result in a different LLS options being seen in Hello and 
DD. This can trigger the change in LLS option logic unnecessarily. Hence, to 
keep things simple and consistent (and this should be for technically all LLS 
options), it makes sense to include them in both Hello and DD packets.


And, one more question to the Authors of this draft:
What’s the procedures for the interaction of BFD session and OSPF adjacency 
establishment in the Broadcast/NBMA network type interface, which is involved 
the DR/BDR election procedures?  The BFD session establishment should be after 
the DR/BDR election?
Should the procedures in section 4 be updated to cover such scenario?

KT> The procedures in Sec 4 update the transition to INIT state in the OSPF 
Neighbor FSM. This happens before DR election and is independent of the type of 
network/link - applies also to Broadcast/NMBA. The main

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

[Robert Raszuk]

Hi Albert,

> [AF] This draft ensures that BFD can be used to detect failure quickly
> when there is a complete path failure between the nodes. You are right that
> there are many other types of failure that BFD cannot detect.
>
> Indeed, but the draft says otherwise. I think that needs to be adjusted
before publication. If you say it detects complete path failure then
perfect. It could detect more than that ... say path failure at some MTUs
if more time is allowed to test the link before ospf adj comes up.

[AF] This is a good point you brought up. Both router vendors that I have
> tested (Cisco & Juniper) do indeed have timer mechanism to delay when OSPF
> would be allowed to come up, which we have tested (useful to guard against
> flapping links). I am not sure if this "hold down" mechanism needs to be
> included in the draft.
>
>
Sure one option is to keep it as a cfg knob.

But If you do not exchange this timer with agreement to choose a lower one
between peers you are both risking misconfiguration as well as adding a bit
more operational complexity.

Even if this is not exchanged, draft/rfc should still mention it and
recommend some wise default timer - say 5 sec. Maybe more. But I see no
harm to signal it explicitly between peers.

Moreover there can be implementations which will not support that timer and
it will be needed to ask them each time to add it.

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Robert,

Thanks for your comment. Please see my response inline.

From: rob...@raszuk.net At: 01/29/22 11:14:59 UTC-5:00To:  ketant.i...@gmail.com
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  lsr@ietf.org,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  acee=40cisco@dmarc.ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan and all,

I support this draft - it is a useful addition. 

There are two elements which I would suggest to adjust in the text before 
publication. 

#1 Overpromise

Even below you say: 

> Since there is a issue with forwarding (which is what BFD detects)

and in the text we see: 

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

Reader may get an impression that if he enables strict mode he is 100% safe. 
Sure he is safer then before but not 100% safe. 

Real networks prove that there are classes of failures which BFD can not 
detect. And Albert knows them too :) 

For example some emulated circuits can experience periodic drops only at some 
MTUs and only when link utilization reaches X %. While there is ongoing 
extension to BFD to fill it with payload I don't think that BFD can be useful 
to also saturate say in 80% 10G link with probes to test it well before 
allowing OSPF to be established. 

[AF] This draft ensures that BFD can be used to detect failure quickly when 
there is a complete path failure between the nodes. You are right that there 
are many other types of failure that BFD cannot detect. For example, one other 
one we have seen from time to time is when an interface fails to forward 
configured MTU-sized packet (see the other draft that we have proposed to 
address this is 
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets). 

There are also other types of failures, such as link errors. 

Another error type that we have encountered are errors due to pattern sensitive 
pattern where BFD/Routing protocols are working fine, but user traffic cannot 
be forwarded due to bit flip.

I tend to think that these type of errors are best handled outside this draft, 
and from previous discussions with various people in the BFD working group, 
they are keen to keep BFD as simple as possible.


#2 Timer 

What I find missing in the draft is a mutually (between OSPF peers) timer fired 
after BFD session is up which in OSPF could hold on allowing BFD to do some 
more testing before declaring adj to be established. I think just bringing OSPF 
adj immediately after the BFD session is up is not a good thing. Keep in mind 
that we are bringing the interface up so by applying such a timer we are not 
dropping packets .. in fact quite the reverse we are making sure user packets 
would not be dropped. 

[AF] This is a good point you brought up. Both router vendors that I have 
tested (Cisco & Juniper) do indeed have timer mechanism to delay when OSPF 
would be allowed to come up, which we have tested (useful to guard against 
flapping links). I am not sure if this "hold down" mechanism needs to be 
included in the draft.


Cheers,
Robert


Thanks,
Albert___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr