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