Hi Marcus, Thank you for the review and comments. Ver -18 will address your comments. Pls see inline for replies... Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Marcus Ihlar via Datatracker <noreply@xxxxxxxx> Sent: 19 December 2024 23:52 To: tsv-art@xxxxxxxx Cc: draft-ietf-lsr-flex-algo-bw-con.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx Subject: Tsvart last call review of draft-ietf-lsr-flex-algo-bw-con-17 [External Email. Be cautious of content] Reviewer: Marcus Ihlar Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. The document is well written and looks good from a technical perspective. One small concern, coming from a total outsider perspective, so apologies if this is something obvious. I'm thinking of how flows map to Flex algorithms, and specifically misclassification of flows (through fault or malicious intent). For instance, cases where a large set of flows all map to the same flex algo that has some constraints on the available paths (e.g., exclude paths based on max delay). Can the introduction of these metrics lead to new types of overload scenarios? Would it be the role of a PCE to detect and mitigate such scenarios? Is this something that needs mentioning in this document? <SH> Your concern is valid but addressing the issue is outside the scope of this document. The document has clarified below "Thus, the procedures described in this document are not a replacement to the capability of a PCE which has a dynamic view of the network and provides real-time bandwidth management or a distributed bandwidth management protocol." Which I think is sufficient to clarify. A few, mostly editorial comments below. The term Elephant flow is used a number of times in the document, for instance in section 3: "In networks that carry elephant flows, directing an elephant flow down a low-bandwidth link would be catastrophic." In what sense is it catastrophic? Flows should be congestion controlled and therefore adapt to link conditions. Some applications performance might suffer from slow transfer of bulk data, whereas others aren't noticeably affected. I think it could be good to have a slightly more clear definition of the term elephant flow, or even better, use a more concrete example of the type of application flow you are considering here. <SH> Catastrophic in the sense it might affect other critical application traffic due to congestion. Will add more text here. In section 3 you also have the following text: "Delay is an important consideration in High Frequency Trading applications, networks with transparent L2 link recovery, or in satellite networks, where link delay may fluctuate." There's a bit of an editorial inconsistency here (imo), mixing application types and network types. I assume you want to give an example of an application for which it could make sense to exclude links based on a Max delay constraint. Perhaps write it something like this: "Applications, such as High-Frequency Trading are sensitive to link delays and may perform poorly in networks prone to delay variability, such as those with transparent Layer 2 link recovery mechanisms or satellite links." <SH> ok. Will take this text -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
