Hi Camilo, I was curious if we would provide a discrete churn color/marker only would it not address your overall need ?
Example: Let's consider 5 default markings (it could be more if needed - this is just to describe the idea) - the defaults are just for illustration purposes and they could be configurable locally to override the default thresholds: green - less then 10 transitions per minute yellow - 10-100 transitions per minute orange - 100-500 transitions per minute red - 500-1000 transitions per minute black - more then 1000 transitions per minute Moreover BMP may be configured to only advertise some of the above. Then while advertising the colors we may also introduce optional counter of transitions between colors such that we don't need to advertise each transition in a separate messages. Would that address the overall need yet do not generate excessive BMP churn :) ? Cheers, Robert On Mon, Mar 24, 2025 at 8:29 PM Camilo Cardona <[email protected]> wrote: > Hello Jeff, > > I’m sad you couldn’t sleep on your way back, but happy you rewarded us > with this analysis. Thank you. > > First, it seems to me that the extra churn caused by enabling this TLV > would depend on (1) The BMP feed’s RIB source. (2) Whether reason codes are > enabled. Do we agree that with reason codes off, churn would be lower? > Also, sourcing from adj-rib-in-pre, for instance, would result in less > churn than sourcing from loc-rib? > > My questions aim to stress that the proposed marking mechanism creates > scenario-dependent churn—worse in some cases than others. We could add text > describing the churn in the document, but the end goal of the document is > still to standardize the TLV (where to mark), rather than analyze every > situation that stems from it. > > Regarding your question and the scenario you describe, I personally care > more about the final state than transient churn. Therefore, it would be > nice to use as many tricks as we can to hide the churn behind state > compression, but I accept some churn is unavoidable, and we will have to > handle this on the receiving end. > > You suggest delayed marking to reduce (not avoid) churn. Is this something > we could propose to be configurable (something like a timer?), or would > this be too implementation-dependent to be generalized? > > Thanks, > Camilo > > On 23/3/25, 10:09, "Jeffrey Haas" <[email protected] <mailto:[email protected]>> > wrote: > > > Camilo, > > > On Fri, Mar 21, 2025 at 08:19:57PM -0500, Camilo Cardona wrote: > > Yes, and not only for the backup paths, we also have options for marking > non-selected paths and their churn might be even worse. > > > I should have been more precise. When I typed "backup", it would have been > better to say "non-active paths". > > > > We know that this might be complicated for the devices. Section 3. > explains that the reason code should be optional, and devices should > provide options for enable or disable the reason code. Do you think there > are other implementation guidelines that we can consider that would > facilitate this on the devices? > > > In addition to looking at the draft again as part of inbox cleanup, I spent > a few moments of under-slept time while traveling home from IETF-122 > pondering what my employer's implementation would need to do to support the > draft. I suspect some many of my conclusions would apply to other > implementations. > > > Consider the case where the system is in initial route learning state. For > simplicitly, we have N (N >= 2) feeds of the Internet. > > > During route learning, it's possible for us to learn a route and cause the > prior active route to lose best path status each time, resulting in N-1 > changes. If we had a fast enough loc-rib feed, it would be possible to see > this churn in many circumstances depending on the route properties. In > practice, this churn doesn't make it all the way to a monitoring station > due > to state compression. Our implementation prioritizes advertisement of > loc-rib after rib-in which further helps suppress the churn. > > > With path marking on rib-in for the scenario above, we are not only having > to report the newly learned route, but also eventually enqueue the route > that just lost being best path to have the path-marking TLV. > > > We are lucky in most circumstances that once a route has lost best path > status, the reason why is likely to be fairly consistent. This means that > for the above worst case, we're having to advertise O(2*N) rib-in messages > rather than O(N) during learning. > > > There's also a matter that if we were engaging in active path marking > during > route learning and passing the reason for the churn in actively to the feed > that we may delay end-of-rib status for the learned routes. > > > That's perhaps problematic. > > > So, what if the marking happened somewhat later to avoid churning the > system. What could this look like? > > > One answer would be that the inactive paths have their rib-in entries > re-queued for bmp advertisement with the path marking TLV. If N-1 paths are > re-sent for the entire rib-in, that's still substantial traffic. > > > An interesting related question is what time-stamp should you use in the > per-peer header? RFC 7854 suggests it's the route-learning time. As we > discussed during grow in IETF 122 one's "faith" in timestamp accuracy may > be > low but perhaps mostly good enough for rib-in for most implementations. > Very likely we'd like to use the original learning time-stamp in such a > "path-marking status only update". That could permit receiving stations to > avoid treating this metadata update as actual path churn. > > > For the hypothetical situation above, the active path may churn much less > than N-1 times. So, perhaps this doesn't appear as problematic as it could? > > > A second scenario for consideration is a change of policy or even IGP cost > due to IGP churn. > > > For a change in policy impacting the rib-in (import policy), this means > that > not only is the rib-in-post for the impacted peer that has had its policy > changed, but also other rib-in views to reflect a potentially new reason > the > route is now inactive. > > > For IGP cost, this isn't previously reflected in the rib-in-post view. > However, now such a change may directly manifest in the status changes. > > > ----- > > > Overall, for a few simple situations it seems like the overall churn in BMP > is significantly higher. > > > I'm not going to press the point that it is impossible to reflect these > things in the protocol. What I'm curious about is whether users of BMP find > this churn problematic or not? > > > Do the authors have implementations for this feature that they can share > their observations about these potential extension consequences and how > they've mitigated them? > > > -- Jeff > > > > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
