Hi Tony Li and all reviewers,
Many thanks to all of you for your insightful comments. Your feedback has given me substantial new perspectives and allowed me to reorganize my thinking and provide clarifications for this proposal. Microbursts have long been a persistent pain point in IP networks, yet effective mitigation solutions remain lacking. In my opinion，three distinct approaches can be used to mitigate the adverse impact of microbursts on networks: 1. Eliminate microburst-induced packet loss entirely. This approach demands sub-millisecond ultra-fast response, which relies on hardware-triggered mechanisms such as PFC. Such solutions fall outside the scope of routing protocol and path computation design. 2. Perform coarse-grained traffic tuning based on real-time detection of burst conditions. Streaming Telemetry and IPFIX are widely adopted industry-standard solutions for this purpose, delivering high-performance real-time traffic visibility. 3. Avoid links with historically and statistically high microburst susceptibility during traffic planning and path calculation. This draft focuses primarily on the third approach. The core motivation is that certain links exhibit inherently higher microburst risk than others, stemming from insufficient local buffer capacity, mismatched ingress/egress port speeds, and other persistent hardware or deployment factors. Our objective is to identify such high-risk links and advertise a relatively stable link attribute indicating microburst susceptibility. Controllers and ingress routers shall reference this attribute when executing end-to-end path planning. The proposed device-side logic works as follows: Operators configure microburst packet loss alarm thresholds together with hysteresis mechanisms to filter transient short-term traffic spikes. The router maintains a multi-day to multi-week sliding aggregation window for continuous microburst statistics. After completing long-term statistical evaluation, the device generates a final verdict on whether the link is persistently prone to microbursts. This binary risk flag is then advertised via extended IS-IS TE sub-TLVs. The risk flag will only flip and trigger a new LSP flooding event when major network upgrades, hardware reconfigurations, or drastic shifts in service traffic bearing patterns take place. In short, this design converts volatile, time-variant microburst transient events into a quasi-static binary link attribute indicating persistent microburst risk. I plan to revise the technical details within this draft accordingly. Detailed quantitative microburst counters will be removed entirely; only a single binary flag indicating microburst susceptibility will be retained. We may either reuse the existing A-bit (Anomaly Bit) defined in RFC 8570 or define a dedicated new flag bit. The semantic definition shall be as follows: When long-term aggregation statistics confirm a link is persistently susceptible to microbursts, this flag shall be set to 1, signaling ingress routers and PCEs to avoid selecting this link for new tunnel paths whenever feasible. This design ensures the flooding frequency of the microburst risk flag is suppressed to an extremely low level. I hope the above clarifications fully address the concerns raised by the working group. Please feel free to raise further questions or comments for additional discussion. Best Regards， RuanZheng From: Tony Li Date: 2026-07-20 16:25 To: lsr Subject: [Lsr] Questions on draft-ruan-lsr-isis-te-extensions-for-microburst 【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】 1. It seems like you're using the IGP here as a mechanism for transferring data, not actually affecting the path computations that routers will be selecting. Is this really the right approach? The IGP is not a dump truck. 2. How often should this information should be propagated? Your operational consideration puts this responsibility on the operator, but gives him no guidance. Given that the subject is microbursts, the natural tendency would be to pick something very rapid, leading to IGP churn. 3. Could you please expound on the definition of the A bit? Advertising every single anomaly would strongly suggest IGP churn. 4. Would this information be better in telemetry?
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
