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. 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. 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]
