LSP-based TE

[italobusi]

Multiple comments pushing to replace TE with "LSP-based TE":

• see Mahesh Jethanandani's Discuss on draft-ietf-teas-rfc8776-update-20 #329
• maybe see Éric Vyncke's Discuss on draft-ietf-teas-rfc8776-update-20 #332 (Title of RFC8776-bis #337): Eric has not cleaned-up the DISCUSS
• maybe see Éric Vyncke's Discuss on draft-ietf-teas-yang-te-41 #346: not clear what "I won't comment anymore about this model being LSP-only" means but the proposed title is "A YANG data model for LSP-based point-to-point TE and the associated interfaces"

[italobusi]

IMHO, the term "LSP-based TE" is quite confusing:

• what is difference between "TE" and "LSP-based TE"?
• what is a "non LSP-based TE" technology?
• why the models are not applicable to such "non LSP-based TE" technology?

I have not found any RFC defining what is "LSP-based TE".

This is what Gemini has replied to the question "what is non LSP-based TE":

Understanding Non LSP-based Traffic Engineering (TE)

Non LSP-based Traffic Engineering refers to methods used to control and optimize network traffic flow without relying on Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).

Common Methods

1. IGP Metric Manipulation

The most basic form of TE. By manually adjusting the cost/metric of specific links in protocols like OSPF or IS-IS, administrators can influence the "shortest path" calculation to steer traffic away from congested links.

2. Policy-Based Routing (PBR)

PBR allows traffic forwarding based on defined policies (source IP, port, or protocol) rather than just the destination. It provides a way to "force" specific applications onto different paths without using tunnels.

3. Segment Routing (SR-MPLS / SRv6)

A modern approach that encodes the path directly into the packet header as a stack of segments. It often removes the need for complex signaling protocols like RSVP-TE. Detailed documentation is available via Cisco Segment Routing.

4. SDN-Based Centralized Control

Software-Defined Networking controllers (like OpenFlow) use a global view of the network to program flow tables in switches, bypassing traditional distributed routing logic.

---

Comparison Table

Feature	LSP-based TE	Non LSP-based TE
Path Selection	Constraint-based (Bandwidth, Affinity)	Metric-based or Policy-based
Overhead	High (requires RSVP-TE signaling)	Low (uses existing IGP/PBR)
Granularity	Very High (per-flow tunnels)	Moderate to Low
State	State maintained in network core	Core is often stateless

This reply confirms that the definition of "non LSP-based TE" is quite problematic:

1. point 3 in the reply from Gemini seems in contradiction with the following text in section 2 of RFC 9603:

   Further, note that the term "LSP" used in the PCEP specifications
   would be equivalent to an SRv6 path (represented as a list of SRv6
   segments) in the context of supporting SRv6 in PCEP.

2. point 4 in the reply from Gemini seems in contradiction with common practice, especially at the northbound of optical transport network controllers, to use the same model to request the controller setup "tunnels" regardless of whether the controller uses GMPLS/RSVP-TE or static configuration (SDN or proprietary) to setup the optical connections

3. the comparison table assumes LSP-based TE is requires RSVP-TE and therefore does not consider static LSPs