Skip to main content

Last Call Review of draft-ietf-lsr-flex-algo-bw-con-17
review-ietf-lsr-flex-algo-bw-con-17-tsvart-lc-ihlar-2024-12-19-00

Request Review of draft-ietf-lsr-flex-algo-bw-con
Requested revision No specific revision (document currently at 22)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2024-12-17
Requested 2024-12-03
Authors Shraddha Hegde , William Britto , Rajesh Shetty , Bruno Decraene , Peter Psenak , Tony Li
I-D last updated 2024-12-19
Completed reviews Rtgdir Last Call review of -08 by Stewart Bryant (diff)
Tsvart Last Call review of -17 by Marcus Ihlar (diff)
Genart Last Call review of -17 by Christer Holmberg (diff)
Opsdir Telechat review of -18 by Jürgen Schönwälder (diff)
Assignment Reviewer Marcus Ihlar
State Completed
Request Last Call review on draft-ietf-lsr-flex-algo-bw-con by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/NSaK23UvxRE_vFZ2c0H9I2CgT7M
Reviewed revision 17 (document currently at 22)
Result Ready w/nits
Completed 2024-12-19
review-ietf-lsr-flex-algo-bw-con-17-tsvart-lc-ihlar-2024-12-19-00
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@ietf.org 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?

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.

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