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

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

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

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

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

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

[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/

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

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

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

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

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

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

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

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

[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

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

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

Re: [Lsr] Dynamic flow control for flooding

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