Well... My idea with the initial mail was: a) Check if there is anything hindering the evolution of this draft to an RFC. b) Bet in try to make possible a thing that nowadays could be considered impossible, like: "How to enable the BFD capability on a route-server with 2000 BGP Sessions without crashing the box?" And maybe: c) How about suggesting a standard best practice dor ARP-Timeout for IXPs. And creating tools to measure the ARP-Timeout configurations of each participant, and make this info available trough standard protocols. Em qua., 16 de set. de 2020 às 18:14, Christopher Morrow < morrowc.lists@gmail.com> escreveu:
On Wed, Sep 16, 2020 at 4:55 PM Randy Bush <randy@psg.com> wrote:
So, I was searching on how to solve that and I found a draft (8th
release)
with the intention to solve that... https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
If understood correctly, the effective implementation of it will depend on new code on any BGP engine that will want to do that check. It is kind of frustrating... At least 10 years after the release of RFC until the refresh os every router involved in IXPs in the world.
you have a better (== easier to implement and deploy) signaling path?
the draft passed wglc in 1948. it is awaiting two implementations, as is the wont of the idr wg.
I think you also mean to say: "this is actually still a DRAFT and not an RFC, so really no BGP implementor is beholden to this document, unless they have coin bearing customers who wish to see this feature implemented"
if i had meant to say that, i probably would have. no one on this thread has called it anything other than a draft, so i am quite unsure what your point is; and i will not put words in your mouth.
I think the OP said: " At least 10 years after the release of RFC
until the refresh os every router involved in IXPs in the world."
it's not an rfc yet.
sadly, these years, vendors do not seem to care a lot about drafts, rfcs, ... anything which sells.
sure :(
-- Douglas Fernando Fischer Engº de Controle e Automação