Camilo, On Tue, Mar 25, 2025 at 08:49:19AM -0500, Camilo Cardona wrote: > > Perhaps this motivates the question about the desire for this bit of state? > > Is it wanted real-time? Is it solely to avoid running proxy analysis on the > > BMP receiver when it can't fully understand the implementation's route > > selection algorithm? > > My use cases do not require *real* time, and therefore having the marking > later is fine with me. If you ask me, I would prefer this to be > configurable, but again, we are getting into implementations details.
A strong motivation to raise these points is it's not "just implementation details". It changes how bits on the wire get seen and when. Enabling this use case disrupts others. To give a concrete example, if you need baseline adj-rib-out-post as a view, getting churn in it isn't necessarily helpful for your traffic shaping mechanism. Thus, especially for initial dump, you don't want to see this stuff until after end-of-rib. And even for after initial convergence, traffic shaping tools would likely want to distinguish an actual topology change or churn in routes from internal state changes that require adverising with new marking TLVs. Perhaps this might be "use the old timestamp" but that procedure isn't covered in the current draft. > Is there something we could add to the document to make it better? A > warning about the churn? What do you suggest? Definitely discuss the churn beyond the abstract. BMP is there to cover BGP state, and this draft peeks underneath the curtain to deeper machinery. Exposing that machinery has BMP visible consequences. Understanding the motivation potentially has some options. Perhaps this is never turned on for applications using BMP for traffic shaping. Perhaps you turn this on a "side session" that is only there for exposing this information. Potentially such a side session uses "triggered BMP". Or potentially BMP is just the wrong tool and this should get done in something using a YANG model. As an example, see the identify base "bgp-not-selected-bestpath" for similar coverage in https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-18 Unlike current BMP, YANG is amenable to RPCs that let you query slices of state if you care about more real-time diagnostics. Please understand my questions aren't trying to kill this draft. However, I find the consequences of the encoding to be problematic enough that I'd not recommend it for my implementation right now. It may be that all I can do is recommend that the draft note the scaling and operational consequences and let people that want to implement it do so. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
