Early Review of draft-ietf-teas-yang-te-40
review-ietf-teas-yang-te-40-opsdir-early-mishra-2025-12-23-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-teas-yang-te-40

- Reviewer: Gyan Mishra

- Review Date: 12/23/25

- Intended Status: [Proposed Status, e.g., Standards Track]

---

## Summary

Choose one:

- Has Major Issues - I have some  concerns about this document that I think
should be resolved before publication.

## Major Issues

> This document defines a mechanism for a generic TE yang model proposal that
is data plane independent and thus can apply to all data planes. While the
technical approach is sound, Section 3 and 4 lacks clarity on how the generic
TE yang model would deployed.

In section 4.1 this draft mentions the generic yang model design as shown in
figure 1 where RSVP-TE control plane and MPLS data plane are mentioned.

However there is no mention of segment routing data plane RFC 8402 as being
supported data planes for this yang model.  SR has the ability to provide
steering just as does RSVP-TE.  As SR is stateless and MPLS data plane with
RSVP-TE control is stateful, for clarity throughout the draft I recommend
mentioning that the Genetic TE yang model is only applicable to MPLS data plane
with RSVP-TE control plane.  Figure 1 does allude to that but it is not stated
explicitly that SR technology although is TE capable that SR is does not apply
to the generic TE yang model being proposed.

On the other hand if the intention was to be inclusive of all TE data planes
including SR to be applicable then it is still possible as the TE tech
semantics are very similar and almost everything that TE design involves from
metric types and constraint and include / exclude and SRLG all of that is
ported into SR technology in a stateless manner.  The main difference is IGP
providing the label distribution and no stateful neighboring protocol where
state is in the packet and not the network.  The other major difference is
PCALC stateful path and reserve messages send from head to tail to allocate
labels and tail to head to reserve bandwidth does not exist in SR.  SR does
have bandwidth as an IGP metric but is not signaled in a distributed manner as
is with RSVP-TE, however bandwidth reservation can be done via SR PCE/SDN
controller.

I noticed that RSVP TE FA RFC 3477 forwarding adjacent LSP one hop tunnel for
signaling unnumbered link used for auto bandwidth and full mesh PE to PE
tunnels for bandwidth management with container LSPs is missing in the generic
yang model.

I do see generic protection mentioned but I don’t see IP LFA, MPLS LDP RLFA and
if SR is inclusive then TI-LFA. Also RSVP TE FRR RFC 4090 details of bypass
loop from PLR to merge point link failure facility protection and node failure
node protection with SRLG. Also RSVP-TE automatic tunneling 1 hop tunnels for
FRR.

For Multicast P-Tree PTA per RFC 6513 6524 for RSVP-TE P2MP I don’t see RFC
4875 mentioned. Also  RSVP-TE P2MP FRR.

> The Operational Considerations section should be expanded to address all the
data plane related caveats and everything I mentioned in the issues section.

Explicitly evaluate compliance with operational guidelines (optional but
recommended):

For example the check list:

- Fault Management: Are failure detection/recovery mechanisms specified?

- Configuration Management: Are configuration changes to enable/disable the
feature clearly defined?

- Performance Monitoring: Are metrics (e.g., latency, resource usage) clearly
identified?

| Review Item                | RFC 5706 Considerations
|-------------------------------
|-------------------------------------------------------------------------------------------------------
| Deployment                     | Does the document include a description of
how this protocol or technology is going to be deployed and managed? |
Installation and Initial Setup | Are configuration parameters clearly
identified and do they have reasonable default values? | Migration Path        
        | Is a path to migrate existing configuration clearly articualted? Are
there any backward compatibility issues? | Requirements on Other Protocols|
What other protocol operations are expected to be performed relative to the new
protocol or technology? | Impact on Network Operation    | Will the new
protocol significantly increase traffic load on existing networks or affect the
control plane? | Verifying Correct Operation    | For example, how can one test
end-to-end connectivity and throughput?

For routing protocols, example as

[RFC 6123 – Inclusion of Manageability Sections in Path Computation Element
(PCE) Working Group Drafts](https://www.rfc-editor.org/rfc/rfc6123.html)

## Major Issues

List critical problems blocking publication (e.g., protocol flaws, missing
operational safeguards, or lack of manageability considerations). Include
section/paragraph references.

- Example:

 > Section 4.2 describes [feature] but does not specify how operators can
 monitor its performance (RFC 5706 Section 3.6). This omission could lead to
 undiagnosed failures in production networks.

- If none:

 > No major issues found.

---

## Minor Issues

List non-blocking but important clarifications (e.g., ambiguous terminology or
incomplete examples).

- Example:

 > Section 2.1 uses "node" without defining its scope (physical/virtual). Add a
 reference to RFC 8345 for consistency.

- If none:

 > No minor issues found.

---

## Nits

Optional editorial suggestions (e.g., acronym expansions or grammar fixes).

- Example:

 > Abstract: Expand "NFV" on first use.

 > Section 3.1: "it’s" -> "its".

---