I support WG adoption. This is important work and I would be happy to collaborate on the work.
The problem statement is very clear. There was a post recently on LinkedIn related by Colby Barth from Juniper related to bandwidth aware TE. M One of the major day 1 gaps with traditional FRR that exists today is that FRR is locally computed in a distributed fashion and not by a centralized controller. For any feasible fast notification solution I believe a centralized controller is a must that has a global view of the fabric and all flows, so when the FRR occurs across the bypass loop to the merge point, the backup path across the bypass loop must not be congested. The only way that is possible AFAIK is using a centralized controller. Kind Regards Gyan On Thu, Jan 15, 2026 at 4:09 PM Joel Halpern <[email protected]> wrote: > I have several basic concerns with the draft. > > 1) The draft starts by asserting that there is a need for lossless > traffic delivery. It is possible you actually mean lossless. In which > case I consider the target impossible for any general use network. It > is mor elikely you mean very low loss (e.g 1 in 10^6 packet loss over > any 1 minute time period.) If so, you need to state that and not refer > to "lossless". > > 2) Unless I missed it, other than in terms of examples the draft does > not seem to state whether it wants to solve an intra-data-center problem > (a interesting, important, and solvable problem), one hop wide are > anetwork ( aproblem where it may be possible to do something, depending > upon the link delay, srbitrary but special constructed wide area > interconnects (demonstrated to be addressable by throwing money at the > problem), or arbitrary multi-use, multi-hop wide area networks. The > demands and difficulties of these different cases are different. > > 3) There is also an assertion that "faster" responsiveness to issues is > needed. Without some quantification of what kind of speed is needed, I > do not see how this claim can be evaluated, nor how solutions can be > considered. > > Net: While I see a nice sketch of a topic for investigation, I do not > see enough clarity for adoption. > > Yours, > > Joel > > On 1/15/2026 2:12 PM, Yingzhen Qu via Datatracker wrote: > > This message starts a rtgwg WG Call for Adoption of: > > draft-dong-fantel-problem-statement-03 > > > > This Working Group Call for Adoption ends on 2026-01-30 > > > > Abstract: > > Modern networks require adaptive traffic manipulation including > > Traffic Engineering (TE), load balancing, flow control, and > > protection, to support high-throughput, low-latency, and lossless > > applications such as Artificial Intelligence (AI) /Machine Learning > > (ML) training and real-time services. A good and timely > > understanding of network operational status, such as congestion and > > failures, can help to improve network utilization, enable the > > selection of paths with reduced latency, and enable faster response > > to critical events. This document describes the existing problems > > and why a new set of fast network notification solutions are needed. > > > > Please reply to this message and indicate whether or not you support > adoption > > of this Internet-Draft by the rtgwg WG. Comments to explain your > preference > > are greatly appreciated. Please reply to all recipients of this message > and > > include this message in your response. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-dong-fantel-problem-statement/ > > > > There is also an HTMLized version available at: > > > https://datatracker.ietf.org/doc/html/draft-dong-fantel-problem-statement-03 > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-dong-fantel-problem-statement-03 > > > > _______________________________________________ > > fantel mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > rtgwg mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
