Hi Jie, Thanks for your reply. Please see inline comments at [Fan].
Regards, Fan On Wed, Dec 3, 2025 at 11:09 AM Dongjie (Jimmy) <[email protected]> wrote: > Hi Fan, > > > > Thanks for your detailed review of this draft. They are helpful for > polishing the document. > > > > Please see some replies inline: > > > > *From:* Fan Zhang <[email protected]> > *Sent:* Tuesday, December 2, 2025 11:24 AM > *To:* [email protected] > *Cc:* RTGWG <[email protected]>; FANTEL <[email protected]> > *Subject:* [fantel] Some comments on > draft-dong-fantel-problem-statement-02 > > > > Hi authors, > > Thanks for the draft. It's good to have a draft that helps clarify the > problems and scope of FANTEL. I've read it and have some comments below. > > [Comments] > > 1) "fast network notification" and "fast notification" are both used in > the document. Is there any difference between them? If not, it may be > better to align the terminology. > > [Jie] Thanks for pointing this out. I agree it is better to align the > terminology. IMO this is a good question and we would like to hear opinions > from participants on both the RTGWG and FANTEL lists: > > [Jie] "fast notification" is what was firstly used in FANTEL BoF, "network > notification" is what we used in initial versions of this draft following > the guidance from our AD, and "fast network notification" is what we hear > people proposing during the RTGWG meeting at IETF 124. > > [Jie] Which one should we use in future version of this draft and other > related drafts? We are open to feedbacks. > [Fan] Just my personal view. "fast network notification" might be clearer in indicating that the notifications are propagated across the network. > > 2) Section 3-Overhead and Scalability Challenges: Telemetry usually works > in a publish/subscribe mode, rather than "flooding". "telemetry streaming" > may be better. > > [Jie] I agree telemetry streaming is more accurate, thanks for the > suggestion, will fix it in next revision. > > > 3) Section 4: "before congestion or micro-loops develop". "develop" might > imply a gradual progress. Perhaps "occur" would be clearer. > > [Jie] My personal opinion is develop may be better here. “develop” > indicates the congestion and micro-loop can become more significant if it > takes longer time to send the notification. With fast notification and > action, it is possible to avoid severe congestion and micro-loop, while > they may still exist for a short period. > [Fan] Got it. I understand your intention to imply more severe consequences if congestion or micro-loops persist for a longer time. So you might want to avoid a possible misunderstanding like "before congestion or micro-loops occur", which could sound too strict about the notification timing. Perhaps "further develop" would be clearer? > > 4) Section 4.1.1-BFD: "nor can it notify the failure or congestion to > other nodes". IMHO, BFD can trigger the local IGP process to notify the > failure to other nodes. > > [Jie] Yes BFD can be used for the detection of IGP neighbor failure, then > IGP will act accordingly and propagate state updates to other nodes in the > network. While BFD itself is not used as a notification to other nodes > about the failure. Also BFD is not used for the notification of congestion > or other state changes. > > 5) Section 4.1.2: "Fast notification alerts upstream nodes". I agree that > it's obvious that upstream nodes might need to be notified in some cases. > But I'm wondering whether there are other cases where fast notification > might alert other nodes (such as neighbors)? > > [Jie] In the example described in section 4, the notification is used to > notify the nodes which are sending traffic towards the failure point, so as > to shift the traffic to alternate link/path, thus from the perspective of > traffic flow, the notification needs to be sent to the upstream nodes. > Depending on the traffic flows to be shifted, the notification may be sent > to different nodes (which are considered as the upstream nodes of the > traffic flow under consideration). We will consider how to make this > clearer. > > > > [Nits, take it or leave it] > > > > 1) Section 4.1: "exchange terabits per second of data" --> "exchange > terabits of data per second" > > 2) Section 4.1.1-FRR: "The former lacks of global network situation" --> > "The former lacks a global view of the network state" > > 3) Section 4.1.1: "may already be missed" --> "may have already been > missed" > > 4) Section 5.2: "protocols, analytics, NMS, etc." --> "protocols, > analytics systems, NMS, etc." > > 5) Section 5.4: "but not limit to" --> "but not limited to" > > 6) Section 5.4: "Switch all traffic" --> "Switches all traffic". Might > need to align with other bullets. > > 7) Section 6: "too slow, too coarse, or too resource-intensive" --> "too > slow, too coarse, or too resource-intensive to ......" Might need to > clarify the specific consequences. > > > > [Jie] Thanks for catching the nits, they will definitely help in improving > the readability of this document. > > > > Best regards, > > Jie > > > > Regards, > > Fan >
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
