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

2022-02-13 Thread 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
>>>
>> --
>>
>> 
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mis...@verizon.com *
>>
>>
>>
>> *M 301 502-1347*
>>
>> --



*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

2022-02-13 Thread 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
>>
> --
>
> 
>
> *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

2022-02-13 Thread 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
>
-- 



*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