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. 2) Section 3-Overhead and Scalability Challenges: Telemetry usually works in a publish/subscribe mode, rather than "flooding". "telemetry streaming" may be better. 3) Section 4: "before congestion or micro-loops develop". "develop" might imply a gradual progress. Perhaps "occur" 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. 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)? [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. Regards, Fan
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
