Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Acee Lindem (acee)]

Hi Greg,
We’ll take your opinion under consideration.
Thanks,
Acee
From: Lsr  on behalf of Greg Mirsky 

Date: Thursday, July 25, 2019 at 6:41 PM
To: Acee Lindem 
Cc: IDR List , Albert Bloomberg , "Ketan 
Talaulikar (ketant)" , "lsr@ietf.org" , 
"rtg-...@ietf.org" , Albert F , Susan 
Hares 
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Acee,
I imagine that there could be multiple clients of the same BFD session with 
different requirements in regard to dampening behavior. For example, the delay 
each client desires to use may be different for each client of the BFD session. 
If that is a plausible use case, I think that placing dampening to a client may 
be a better choice.

Regards,
Greg

On Thu, Jul 25, 2019 at 6:23 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Albert, Ketan,
The authors will document dampening in the operational considerations. I’m also 
of the mind that the dampening should be done in BFD rather than the BFD 
clients (e.g., BGP).
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Albert F mailto:albert.f...@gmail.com>>
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.com>>
Cc: IDR List mailto:i...@ietf.org>>, 
"rtg-...@ietf.org" 
mailto:rtg-...@ietf.org>>, Albert Bloomberg 
mailto:af...@bloomberg.net>>, Susan Hares 
mailto:sha...@ndzh.com>>, "lsr@ietf.org" 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large 
networks concerned with network stability impacted by link flaps to enable the 
BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the 
other side does not, the BGP keepalive message from one side may be delayed 
even if BFD is up. This may have implication on the BGP session transitiining 
to established phase.

Thanks
Albert



On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This 
“BFD hold up” behaviour that you desire is best handled by BFD since I would 
expect that similar behaviour would be desired across routing protocols (OSPF, 
ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this 
BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should 
however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' mailto:af...@bloomberg.net>>; 
i...@ietf.org
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG 
process.  Can this small change be made after adoption or should it be made 
before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120 
PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: i...@ietf.org
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make 
this draft more operationally useful.

We have encountered several traffic blackhole problems in our production 
network without this feature. As such, we have deployed BGP with strict BFD 
mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
break in the middle issues, the traditional knobs like interface 
hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like 
to request that an option be added in "Section 4 Operation:" to delay BGP from 
coming up until BFD is proven stable continuously for a period of time (i.e. 
BFD hold up feature).

This is a feature that we are currently using in the proprietary vendor 
deployment. In our case, since we have multiple redundant paths, we have some 
links where we delay BGP from coming up until BFD has been stable continuously 
for 60 seconds.

Thanks
Albert Fu
Bloomberg

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

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Susan Hares]

Ketan and Acee:

 

The IDR co-chairs (John and I) wish to reduce the number of trivial drafts for 
BGP-LS allocations that could be done with 1 sentence.   We discussed with the 
LSR chairs (Acee and Chris) that it would be reasonable for LSR to do what 
Ketan has requested. 

 

We suggest that the WG LC is sent to IDR and LSR in case someone wants to 
discuss a concern.   The LSR chairs are capable and smart.   Acee and Chris can 
help shepherd these LSR drafts with BGP TLV language.  

 

Sue  

 

PS – has anyone heard if Chris Hopps is a father yet? 

 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 25, 2019 6:43 PM
To: Acee Lindem (acee); lsr@ietf.org
Cc: i...@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org
Subject: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

 

Hi Acee/All,

 

During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
aspects of the following two IGP drafts in those drafts instead of requiring a 
separate document:

 

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/

https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

 

Originally, these IGP drafts introduced a new node capability that required a 
new BGP-LS TLV and this was captured in the IDR WG document 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

 

However after the discussion in the LSR WG over the last few months, the 
approach has changed such that the IGP signalling is being done by introduction 
of new flags and MSD-type. This makes the corresponding BGP-LS updates quite 
trivial and as discussed in the LSR WG, I would recommend to add some text 
(proposed below) to the two IGP documents.

 

OSPF:

The OSPF extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for OSPF by this document is advertised using 
the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
 

 

ISIS:

The IS-IS extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV where 
the ELC Flag is introduced in this document is advertised using the Prefix 
Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for IS-IS by this document is advertised 
using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
 

 

I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for their 
inputs/feedback.

 

Thanks,

Ketan

 

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 25 July 2019 16:28
To: lsr@ietf.org
Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes

 

I think we had some very good discussions in our sessions this week. I’ve 
uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
Yingzhen Qu for taking them. 

 

https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00

 

Thanks,
Acee

 

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

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Jeff Tantsura]

+1 Ketan

Cheers,
Jeff
On Jul 25, 2019, 6:43 PM -0400, Ketan Talaulikar (ketant) , 
wrote:
> Hi Acee/All,
>
> During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
> aspects of the following two IGP drafts in those drafts instead of requiring 
> a separate document:
>
> https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
>
> Originally, these IGP drafts introduced a new node capability that required a 
> new BGP-LS TLV and this was captured in the IDR WG document 
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/
>
> However after the discussion in the LSR WG over the last few months, the 
> approach has changed such that the IGP signalling is being done by 
> introduction of new flags and MSD-type. This makes the corresponding BGP-LS 
> updates quite trivial and as discussed in the LSR WG, I would recommend to 
> add some text (proposed below) to the two IGP documents.
>
> OSPF:
> The OSPF extensions defined in this document can be advertised via BGP-LS 
> [RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
> Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
> document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
> BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
>  The new ERLD MSD-type introduced for OSPF by this document is advertised 
> using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
>
> ISIS:
> The IS-IS extensions defined in this document can be advertised via BGP-LS 
> [RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV 
> where the ELC Flag is introduced in this document is advertised using the 
> Prefix Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI 
> Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
>  The new ERLD MSD-type introduced for IS-IS by this document is advertised 
> using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
>
> I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for 
> their inputs/feedback.
>
> Thanks,
> Ketan
>
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: 25 July 2019 16:28
> To: lsr@ietf.org
> Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes
>
> I think we had some very good discussions in our sessions this week. I’ve 
> uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
> Yingzhen Qu for taking them.
>
> https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00
>
> 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] Regd covering BGP-LS extensions for IGP ELC drafts

[Ketan Talaulikar (ketant)]

Hi Acee/All,

During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
aspects of the following two IGP drafts in those drafts instead of requiring a 
separate document:

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

Originally, these IGP drafts introduced a new node capability that required a 
new BGP-LS TLV and this was captured in the IDR WG document 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

However after the discussion in the LSR WG over the last few months, the 
approach has changed such that the IGP signalling is being done by introduction 
of new flags and MSD-type. This makes the corresponding BGP-LS updates quite 
trivial and as discussed in the LSR WG, I would recommend to add some text 
(proposed below) to the two IGP documents.

OSPF:

The OSPF extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for OSPF by this document is advertised using 
the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].

ISIS:

The IS-IS extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV where 
the ELC Flag is introduced in this document is advertised using the Prefix 
Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for IS-IS by this document is advertised 
using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].



I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for their 
inputs/feedback.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 25 July 2019 16:28
To: lsr@ietf.org
Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes

I think we had some very good discussions in our sessions this week. I’ve 
uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
Yingzhen Qu for taking them.

https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00

Thanks,
Acee

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

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Greg Mirsky]

Hi Acee,
I imagine that there could be multiple clients of the same BFD session with
different requirements in regard to dampening behavior. For example, the
delay each client desires to use may be different for each client of the
BFD session. If that is a plausible use case, I think that placing
dampening to a client may be a better choice.

Regards,
Greg

On Thu, Jul 25, 2019 at 6:23 PM Acee Lindem (acee)  wrote:

> Hi Albert, Ketan,
>
> The authors will document dampening in the operational considerations. I’m
> also of the mind that the dampening should be done in BFD rather than the
> BFD clients (e.g., BGP).
>
> Thanks,
> Acee
>
>
>
> *From: *Lsr  on behalf of Albert F <
> albert.f...@gmail.com>
> *Date: *Thursday, July 25, 2019 at 5:14 PM
> *To: *"Ketan Talaulikar (ketant)" 
> *Cc: *IDR List , "rtg-...@ietf.org" ,
> Albert Bloomberg , Susan Hares , "
> lsr@ietf.org" 
> *Subject: *Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> Hi Ketan,
>
>
>
> I think it will be good to mention this in the doc, as I expect most large
> networks concerned with network stability impacted by link flaps to enable
> the BFD hold-up feature.
>
>
>
> For example, if one side has BFD hold-up enabled (> BGP hold time) and the
> other side does not, the BGP keepalive message from one side may be delayed
> even if BFD is up. This may have implication on the BGP session
> transitiining to established phase.
>
>
>
> Thanks
>
> Albert
>
>
>
>
>
>
>
> On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) 
> wrote:
>
> Hi Albert,
>
>
>
> Thanks for your feedback from an operator perspective – it is valuable.
> This “BFD hold up” behaviour that you desire is best handled by BFD since I
> would expect that similar behaviour would be desired across routing
> protocols (OSPF, ISIS, BGP) and perhaps other clients.
>
>
>
> IMHO this is not something that we should be tackling within the scope of
> this BGP draft. Would you agree?
>
>
>
> That said, this seems like a local implementation aspect to me. We should
> however discuss within the BFD WG if there is value in documenting this.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Idr  *On Behalf Of *Susan Hares
> *Sent:* 25 July 2019 16:21
> *To:* 'Albert Fu' ; i...@ietf.org
> *Subject:* Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> Albert:
>
>
>
> To clarify, do you support WG adoption with the draft as is.
>
>
>
> As a WG chair, I have to trust that all  drafts are improved during the WG
> process.  Can this small change be made after adoption or should it be made
> before the draft is considered for adoption.
>
>
>
> Sue Hares
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org ] *On
> Behalf Of *Albert Fu (BLOOMBERG/ 120 PARK)
> *Sent:* Thursday, July 25, 2019 4:19 PM
> *To:* i...@ietf.org
> *Subject:* [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> I am in support of this draft, and would like to request a small change to
> make this draft more operationally useful.
>
> We have encountered several traffic blackhole problems in our production
> network without this feature. As such, we have deployed BGP with strict BFD
> mode on a proprietary vendor implementation for a while.
>
> Since a lot of MetroE circuit failures occur with interfaces still up, ie..
> break in the middle issues, the traditional knobs like interface
> hold-time/debounce timer can not be used to dampen interface flaps.
>
>
> We have observed that interface issues tend to occur in bursts and would
> like to request that an option be added in "Section 4 Operation:" to delay
> BGP from coming up until BFD is proven stable continuously for a period of
> time (i.e. BFD hold up feature).
>
>
> This is a feature that we are currently using in the proprietary vendor
> deployment. In our case, since we have multiple redundant paths, we have
> some links where we delay BGP from coming up until BFD has been stable
> continuously for 60 seconds.
>
> Thanks
> Albert Fu
> Bloomberg
>
>
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Mercia Zheng (merciaz)]

Hi Albert,

Thanks for the support and valuable comments from a customer’s perspective.

This BFD ‘hold-up’ request actually applies to all BFD clients (e.g. control 
protocols).
I think that BFD would be a better component to apple this BFD hold-up as Ketan 
also mentioned.
However, some specification will be included in the next revision of the doc.

Thanks,
-Mercia

From: Lsr  on behalf of Albert F 
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" 
Cc: "i...@ietf.org" , "rtg-...@ietf.org" , 
Albert Bloomberg , Susan Hares , 
"lsr@ietf.org" 
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large 
networks concerned with network stability impacted by link flaps to enable the 
BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the 
other side does not, the BGP keepalive message from one side may be delayed 
even if BFD is up. This may have implication on the BGP session transitiining 
to established phase.

Thanks
Albert



On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This 
“BFD hold up” behaviour that you desire is best handled by BFD since I would 
expect that similar behaviour would be desired across routing protocols (OSPF, 
ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this 
BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should 
however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' mailto:af...@bloomberg.net>>; 
i...@ietf.org
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG 
process.  Can this small change be made after adoption or should it be made 
before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120 
PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: i...@ietf.org
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make 
this draft more operationally useful.

We have encountered several traffic blackhole problems in our production 
network without this feature. As such, we have deployed BGP with strict BFD 
mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
break in the middle issues, the traditional knobs like interface 
hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like 
to request that an option be added in "Section 4 Operation:" to delay BGP from 
coming up until BFD is proven stable continuously for a period of time (i.e. 
BFD hold up feature).

This is a feature that we are currently using in the proprietary vendor 
deployment. In our case, since we have multiple redundant paths, we have some 
links where we delay BGP from coming up until BFD has been stable continuously 
for 60 seconds.

Thanks
Albert Fu
Bloomberg

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

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Acee Lindem (acee)]

Hi Albert, Ketan,
The authors will document dampening in the operational considerations. I’m also 
of the mind that the dampening should be done in BFD rather than the BFD 
clients (e.g., BGP).
Thanks,
Acee

From: Lsr  on behalf of Albert F 
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" 
Cc: IDR List , "rtg-...@ietf.org" , Albert 
Bloomberg , Susan Hares , "lsr@ietf.org" 

Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large 
networks concerned with network stability impacted by link flaps to enable the 
BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the 
other side does not, the BGP keepalive message from one side may be delayed 
even if BFD is up. This may have implication on the BGP session transitiining 
to established phase.

Thanks
Albert



On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This 
“BFD hold up” behaviour that you desire is best handled by BFD since I would 
expect that similar behaviour would be desired across routing protocols (OSPF, 
ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this 
BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should 
however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' mailto:af...@bloomberg.net>>; 
i...@ietf.org
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG 
process.  Can this small change be made after adoption or should it be made 
before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120 
PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: i...@ietf.org
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make 
this draft more operationally useful.

We have encountered several traffic blackhole problems in our production 
network without this feature. As such, we have deployed BGP with strict BFD 
mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
break in the middle issues, the traditional knobs like interface 
hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like 
to request that an option be added in "Section 4 Operation:" to delay BGP from 
coming up until BFD is proven stable continuously for a period of time (i.e. 
BFD hold up feature).

This is a feature that we are currently using in the proprietary vendor 
deployment. In our case, since we have multiple redundant paths, we have some 
links where we delay BGP from coming up until BFD has been stable continuously 
for 60 seconds.

Thanks
Albert Fu
Bloomberg

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

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Albert F]

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large
networks concerned with network stability impacted by link flaps to enable
the BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the
other side does not, the BGP keepalive message from one side may be delayed
even if BFD is up. This may have implication on the BGP session
transitiining to established phase.

Thanks
Albert



On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) 
wrote:

> Hi Albert,
>
>
>
> Thanks for your feedback from an operator perspective – it is valuable.
> This “BFD hold up” behaviour that you desire is best handled by BFD since I
> would expect that similar behaviour would be desired across routing
> protocols (OSPF, ISIS, BGP) and perhaps other clients.
>
>
>
> IMHO this is not something that we should be tackling within the scope of
> this BGP draft. Would you agree?
>
>
>
> That said, this seems like a local implementation aspect to me. We should
> however discuss within the BFD WG if there is value in documenting this.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Idr  *On Behalf Of *Susan Hares
> *Sent:* 25 July 2019 16:21
> *To:* 'Albert Fu' ; i...@ietf.org
> *Subject:* Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> Albert:
>
>
>
> To clarify, do you support WG adoption with the draft as is.
>
>
>
> As a WG chair, I have to trust that all  drafts are improved during the WG
> process.  Can this small change be made after adoption or should it be made
> before the draft is considered for adoption.
>
>
>
> Sue Hares
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org ] *On
> Behalf Of *Albert Fu (BLOOMBERG/ 120 PARK)
> *Sent:* Thursday, July 25, 2019 4:19 PM
> *To:* i...@ietf.org
> *Subject:* [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> I am in support of this draft, and would like to request a small change to
> make this draft more operationally useful.
>
> We have encountered several traffic blackhole problems in our production
> network without this feature. As such, we have deployed BGP with strict BFD
> mode on a proprietary vendor implementation for a while.
>
> Since a lot of MetroE circuit failures occur with interfaces still up, ie..
> break in the middle issues, the traditional knobs like interface
> hold-time/debounce timer can not be used to dampen interface flaps.
>
>
> We have observed that interface issues tend to occur in bursts and would
> like to request that an option be added in "Section 4 Operation:" to delay
> BGP from coming up until BFD is proven stable continuously for a period of
> time (i.e. BFD hold up feature).
>
>
> This is a feature that we are currently using in the proprietary vendor
> deployment. In our case, since we have multiple redundant paths, we have
> some links where we delay BGP from coming up until BFD has been stable
> continuously for 60 seconds.
>
> Thanks
> Albert Fu
> Bloomberg
>
>
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Jeff Tantsura]

Sue,

I support progress of this draft, it addresses real problem.
On Redback side of things we have implemented this around 2013, logic 
(proprietary) kept in BFD indeed, so +1 Ketan. I’d document it as an informal 
feature, that is recommended (same for YANG)

Cheers,
Jeff
On Jul 25, 2019, 4:27 PM -0400, Ketan Talaulikar (ketant) , 
wrote:
> Hi Albert,
>
> Thanks for your feedback from an operator perspective – it is valuable. This 
> “BFD hold up” behaviour that you desire is best handled by BFD since I would 
> expect that similar behaviour would be desired across routing protocols 
> (OSPF, ISIS, BGP) and perhaps other clients.
>
> IMHO this is not something that we should be tackling within the scope of 
> this BGP draft. Would you agree?
>
> That said, this seems like a local implementation aspect to me. We should 
> however discuss within the BFD WG if there is value in documenting this.
>
> Thanks,
> Ketan
>
> From: Idr  On Behalf Of Susan Hares
> Sent: 25 July 2019 16:21
> To: 'Albert Fu' ; i...@ietf.org
> Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
> Albert:
>
> To clarify, do you support WG adoption with the draft as is.
>
> As a WG chair, I have to trust that all  drafts are improved during the WG 
> process.  Can this small change be made after adoption or should it be made 
> before the draft is considered for adoption.
>
> Sue Hares
>
> From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 
> 120 PARK)
> Sent: Thursday, July 25, 2019 4:19 PM
> To: i...@ietf.org
> Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
> I am in support of this draft, and would like to request a small change to 
> make this draft more operationally useful.
>
> We have encountered several traffic blackhole problems in our production 
> network without this feature. As such, we have deployed BGP with strict BFD 
> mode on a proprietary vendor implementation for a while.
>
> Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
> break in the middle issues, the traditional knobs like interface 
> hold-time/debounce timer can not be used to dampen interface flaps.
>
> We have observed that interface issues tend to occur in bursts and would like 
> to request that an option be added in "Section 4 Operation:" to delay BGP 
> from coming up until BFD is proven stable continuously for a period of time 
> (i.e. BFD hold up feature).
>
> This is a feature that we are currently using in the proprietary vendor 
> deployment. In our case, since we have multiple redundant paths, we have some 
> links where we delay BGP from coming up until BFD has been stable 
> continuously for 60 seconds.
>
> Thanks
> Albert Fu
> Bloomberg
> >
> ___
> 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] IETF 105 LSR Working Group Meeting Minutes

[Acee Lindem (acee)]

I think we had some very good discussions in our sessions this week. I’ve 
uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
Yingzhen Qu for taking them.

https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00

Thanks,
Acee

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

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This 
“BFD hold up” behaviour that you desire is best handled by BFD since I would 
expect that similar behaviour would be desired across routing protocols (OSPF, 
ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this 
BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should 
however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr  On Behalf Of Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' ; i...@ietf.org
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG 
process.  Can this small change be made after adoption or should it be made 
before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120 
PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: i...@ietf.org
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make 
this draft more operationally useful.

We have encountered several traffic blackhole problems in our production 
network without this feature. As such, we have deployed BGP with strict BFD 
mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
break in the middle issues, the traditional knobs like interface 
hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like 
to request that an option be added in "Section 4 Operation:" to delay BGP from 
coming up until BFD is proven stable continuously for a period of time (i.e. 
BFD hold up feature).

This is a feature that we are currently using in the proprietary vendor 
deployment. In our case, since we have multiple redundant paths, we have some 
links where we delay BGP from coming up until BFD has been stable continuously 
for 60 seconds.

Thanks
Albert Fu
Bloomberg

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

Re: [Lsr] Dynamic flow control for flooding

[Henk Smit]

Hello Les,

Thanks for taking the time to respond.


[Les:] Base specification defines partialSNPInterval (2 seconds).
Clearly w faster flooding we should look at decreasing this
timer - but we certainly should not do away with it.


That was the point I was trying to make:
You kept mentioning that your "tx based flow control" only needed
changes to the internal implementation of the LSP-sender.
That's not the case. Your algorithm also depends on behaviour
of the LSP-receiver. I did not see that mentioned anywhere before.
Good to see that you (and Tony) now acknowledge this necessity.

I hope you also realize (and agree) that changing the algorithm
to send PSNPs on the LSP-receiver, in a way to improve the
flow-control algorithm for the LSP-sender, will probably have a
negative impact on the current efficiency of bundling acks in
PSNPs. And that change can multiply the number of PSNPs (and thus
ISIS PDUs in input queues) that need to be received on routers.

If you don’t like the name we can certainly find something more 
appealing.


I don't care much about the name.
(In general I do care about naming in programming. And even 10x more 
about

naming in protocol documents. But that's not important in the discussion
at the moment).

The point I was trying to get across is that your proposal is not
something that happens internally on a single individual router. It is
an algorithm that involves 2 routers. And thus it is a protocol issue.


What I am proposing does not require protocol extensions -
therefore no draft is required.


Protocols do no only describe octets on the wire. They also describe
behaviour. Thus, as Tony has already said, your proposed algorithm
also need to be documented. In an RFC probably.


Whether a BCP draft is desired is something I am open to considering.


I don't know much about process in the IETF. But I was always under
the assumptions that BCPs were mostly network design/configuration
recommendations for network operators.


From an earlier email:

[Les:] I think you know what I am about to say.. :)


Yes, my question of why use exponential backoffs was a rethorical
question (as I wrote at the end of my email).
I wrote:
I hope it is clear to everyone that these are not serious questions. 
I'm

just saying: "sometimes fast is slow".


FYI, few people probably know this, but I happen to be the guy that
intially came up with the idea of exponential backoffs in IGPs.
(Back in 1999 when I was at cisco).

Anyway, to reiterate my point: "sometimes fast is slow". It seems we
now all agree that sending LSPs "rapidly" and then assuming 
retransmissions

will fix any problems, is an approach that is way too naive. Good.

henk.

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