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
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 t
+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://
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-mpl
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
d
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 specifica
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 Talau
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 keepaliv
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 P
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
___
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
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 th
12 matches
Mail list logo