Overview and Principles of Internet Traffic Engineering
draft-ietf-teas-rfc3272bis-27

# Internet AD comments for draft-ietf-teas-rfc3272bis-26
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S5.1.3.3

* "an ingress LSRs and an egress LSRs"

  Maybe strike the two "an"s.

### S5.1.3.4

* "is comprised of" -> composed?

Thank you to the author and WG for a nicely written document! Just a few minor nits:

- Section 1.4 Terminology: "Egress node:" s/with/which/

- Section 1.4 Terminology: "Ingress node:" s/with/which/

- Section 5.1.1.1 - expand RSVP on first use which is the 2nd paragraph not the 3rd paragraph.

- Section 5.1.1.5 - "The DetNet service sub-layer provides a set of Packet Replication, Elimination, and Ordering Functions (PREOF) functions.." - Remove redundant 'functions' text.

- Section 5.1.2.2 - "ACTN facilitates composed, multi-domain connections and provides them to the user.". Should 'composed' be 'composite'?

- Section 5.1.3.3 - Expand 'LDP' on first use.

Thanks for this clear and well-written document.

Thanks to Bob Briscoe for an especially thorough TSVART review!

I have a few minor points from the Transport perspective:

(S1.4) Unless this is a well-understood alternate meaning of the term in the TE community, might I suggest "congestion response" instead of "congestion control"? It is both more descriptive and does not overload a very important concept in Layer 4.

(S1.4) "Egress node: The device (router) at with traffic" s/with/which?

(S2.4.1) s/if the router supports ECN/if the router and end host support ECN

The last paragraph of (S5.1.1.4) is a sentence fragment.

(S5.1.3.6) IPPM also designs measurement techniques and protocols to obtain those metrics. Probably worth mentioning?

(S5.1.3.8) As a transport AD, I had never heard of RFC3124. Perhaps I'm not working in the right cases, or maybe that's an indication that RFC3124 is no longer relevant. If the latter, I'd observe that the main lessons of that work ended up in HTTP/2 and later, directly in the transport in QUIC, in the way that they consolidate streams under a single connection and congestion control context. 

RFC3124 also references TCP control block interdependence (RFC2140, since replaced by RFC9040), which IIUC is very much alive. So maybe the right references for this concept are 9000, 9040, and 9113?

(S7) "Layer 4 multipath transport protocols are designed to move traffic between domains and to allow control of the selection of the paths."

Pedantically, it only allows control of the source and destination IP addresses. It cannot force any path through the network.

Thanks for this document. It is a good read and useful to for the community, especially new participants and users of IETF technologies.

Thanks to Shawn Emery for the SECDIR review.

** Section 6.6.  With the context that I don’t have a clear sense of what was chosen to be included in this document on traffic engineering, it seemed liked a few common traffic engineering design patterns related to survivability were not included.  I could also see discussion of these in the Security Considerations:

-- traffic filtering/scrubbing of any/every kind at the edge to prevent attacks from entering the network or leaving (a very primitive form of traffic engineering)

-- choosing optional security features in control plane protocols such as authentication to harden the control plan

-- relying on external packet scrubbing services to mitigate DDoS attacks

** Section 9
   In general, TE
   mechanisms are security-neutral: they may use tunnels which can
   slightly help protect traffic from inspection and which, in some
   cases, can be secured using encryption; they put traffic onto
   predictable paths within the network that may make it easier to find
   and attack; they increase the complexity or operation and management
   of the network; and they enable traffic to be steered onto more
   secure links or to more secure parts of the network.

Saying that TE mechanisms are security neutral” seems incongruent to the rest of the text.  For example, noting that a path “can be secured using encryption” doesn’t seem neutral at all and changes the security properties of the traffic carries.  Poorly configured traffic engineering seems like it could have disastrous consequences on security or “survivability” as discussed in Section 6.

Thanks for this document, it is a major rewrite.

Thanks as well to Brian Haberman for his int-dir review, which is also supportive for this document: 
https://datatracker.ietf.org/doc/review-ietf-teas-rfc3272bis-24-intdir-telechat-haberman-2023-07-18/