Applicability of RFC8795 YANG data model to SIMAP
draft-busi-nmop-simap-rfc8795-applicability-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Italo Busi , Aihua Guo , Vishnu Pavan Beeram , Sergio Belotti , Tarek Saad | ||
| Last updated | 2026-03-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-busi-nmop-simap-rfc8795-applicability-00
Network Management Operations I. Busi
Internet-Draft Huawei
Intended status: Informational A. Guo
Expires: 3 September 2026 Futurewei Technologies
V. P. Beeram
Juniper Networks
S. Belotti
Nokia
T. Saad
Cisco Systems Inc.
2 March 2026
Applicability of RFC8795 YANG data model to SIMAP
draft-busi-nmop-simap-rfc8795-applicability-00
Abstract
This document analyses the applicability of the RFC 8795 YANG data
model to Service & Infrastructure Maps (SIMAP) and in particular
analysis which requirements can be supported by the existing YANG
data model defined in RFC 8795.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://italobusi.github.io/simap-yang/draft-xyz-nmop-simap-yang-
applicability.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-busi-nmop-simap-
rfc8795-applicability/.
Discussion of this document takes place on the Network Management
Operations Working Group mailing list (mailto:nmop@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/nmop/.
Subscribe at https://www.ietf.org/mailman/listinfo/nmop/.
Source for this draft and an issue tracker can be found at
https://github.com/italobusi/simap-yang.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Busi, et al. Expires 3 September 2026 [Page 1]
Internet-Draft RFC8795 for SIMAP March 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 September 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Bidirectional Links . . . . . . . . . . . . . . . . . . . 4
3.2. Multipoint Links . . . . . . . . . . . . . . . . . . . . 4
3.3. Links and nodes down in topology . . . . . . . . . . . . 5
3.4. Multi-Layer Topologies . . . . . . . . . . . . . . . . . 5
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example of deviation statements . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Busi, et al. Expires 3 September 2026 [Page 2]
Internet-Draft RFC8795 for SIMAP March 2026
1. Introduction
The concept of Service & Infrastructure Maps (SIMAP) is being defined
in [I-D.ietf-nmop-simap-concept] together with a set of SIMP
requirements and use cases.
SIMAP is defined in [I-D.ietf-nmop-simap-concept], as:
SIMAP is a data model that provides a topological view of the
operator's networks and services, including how it is connected to
other models (e.g., inventory) and external data sources (e.g.,
observability data, and operational knowledge). This model
represents a multi-layered topology and offers mechanisms to
navigate amongst layers and correlate between them. This includes
layers from physical topology to service topology. This model is
applicable to multiple domains (access, core, data center, etc.)
and technologies (Optical, IP, etc.).
It is worth noting that the YANG data model in [RFC8795] defines a
topology model which:
* represents a multi-layered topology;
* offers mechanisms to navigate amongst layers and correlate between
them;
* is applicable to multiple domains (access, core, data center,
etc.) and technologies (Optical, IP, etc.).
[I-D.ietf-teas-te-topology-profiles] clarifies that
It is therefore worthwhile analyzing the applicability of the YANG
data model in [RFC8795] to meet the SIMAP requirements and identify
any gaps that need to be addressed before starting the work on new
YANG data models to meet the SIMAP requirements, as outlined in
[I-D.ietf-nmop-simap-concept].
Understanding the degree of standardization and identifying potential
gaps are crucial for supporting the SIMAP applications while ensuring
multi-vendor interoperability and compatibility with other
applications which can run on top of the same network controller.
2. Conventions and Definitions
TODO Conventions and Definitions
3. Gap Analysis
Busi, et al. Expires 3 September 2026 [Page 3]
Internet-Draft RFC8795 for SIMAP March 2026
3.1. Bidirectional Links
Bidirectional links can be modelled as two unidirectional links, one
for each direction, terminated on the same two termination points, as
described in Section 4.4.5 of [RFC8345].
It is worth noting that a bidirectional link can be unambiguously
distinguished from two unidirectional links between the same two
nodes since the two unidirectional links will be terminated on
different termination points, as shown in Figure 1.
+-----------------+ +-----------------+
| +-------------+ | | +-------------+ |
| | | | | | | |
| | +---+ +---+ | |
| | | +------------------------>| | | |
| | A |TP1| |TP2| B | |
| | | |<------------------------+ | | |
| | +---+ +---+ | |
| | | | | | | |
| +-------------+ | | +-------------+ |
+-----------------+ +-----------------+
+-----------------+ +-----------------+
| +-------------+ | | +-------------+ |
| | | | | | | |
| | +---+ +---+ | |
| | |TP3+------------------------>|TP4| | |
| | +---+ +---+ | |
| | C | | | | D | |
| | +---+ +---+ | |
| | |TP4|<------------------------+TP5| | |
| | +---+ +---+ | |
| | | | | | | |
| +-------------+ | | +-------------+ |
+-----------------+ +-----------------+
Figure 1: Difference between one bidirectional link and two
unidirectional links
3.2. Multipoint Links
Multipoint links can be modelled as pseudonodes, as described in
Section 4.4.5 of [RFC8345].
Busi, et al. Expires 3 September 2026 [Page 4]
Internet-Draft RFC8795 for SIMAP March 2026
The type of multipoint link (e.g., point-to-multipoint or multipoint-
to-multipoint, as defined in [I-D.ietf-nmop-simap-concept]) and the
role of the termination points in the link (e.g., source,
destination, hub, spoke, as defined in [I-D.ietf-nmop-simap-concept])
can be unambiguously understood from: - the links entering to or
departing from the termination points of the pseudonode, and - the
'is-allowed' attribute of the connectivity matrix of the pseudonode,
as defined in [RFC8795].
Note: some examples for multipoint links are described in
Section 2.5 of [I-D.ietf-teas-te-topology-profiles]. More
examples can be provided in future versions of this document.
3.3. Links and nodes down in topology
[RFC8795] defines the 'oper-status' attribute for nodes, links and
termination points, therefore allowing to report links and nodes down
in the topology, and to unambiguously distinguishing between nodes
and links which are up or down.
3.4. Multi-Layer Topologies
As outlined in Section 2 of [I-D.ietf-nmop-simap-concept]:
[RFC8345] is flexible and can support both the same network
topology instance with multiple layers (e.g., Layer 2 and Layer 3)
or separate network topology instances with supporting relations
between them (e.g., separate Layer 2 and Layer 3). Therefore,
multiple topology layers can be grouped into the same network
topology instance, if solution requires.
[RFC8795] augments [RFC8345] and therefore provide the same
flexibility.
As described in Section 3 of [I-D.havel-nmop-simap-yang]:
- Layering relationships are expressed solely through the
supporting construct, without additional semantics such as
underlay, primary, backup, load-sharing, path, sequential, or
parallel roles.
This issue was taken into account when designing the YANG data model
in [RFC8795] and the 'underlay' relationship has been properly
defined to support navigation between overlay and underlay layers, as
described in Section 2.3 of [I-D.ietf-teas-te-topology-profiles].
Busi, et al. Expires 3 September 2026 [Page 5]
Internet-Draft RFC8795 for SIMAP March 2026
Some guidelines on how to unambiguously use the supporting
relationship, defined in [RFC8345], and the 'underlay' relationship
defined in [RFC8795], have been clarified in Section 2.3.1 of
[I-D.ietf-teas-te-topology-profiles].
As outlined in REQ-BIDIR of [I-D.ietf-nmop-simap-concept], a
bidirectional link can be supported by two unidirectional links in
the lower layer. For example, a Ethernet (bidirectional) link can be
supported by two physical layer links associated with two
unidirectional fibers.
This relationship can be modelled using the link 'underlay'
relationship, as shown in Figure 2:
+-----------------+ +-----------------+
| +-------------+ | | +-------------+ |
| | | | | | | |
| | +---+ +---+ | |
| | | +-------+---------------->| | | |
| | A |TP1| | |TP2| B | |
| | | |<----------------+-------+ | | |
| | +---+ | | +---+ | |
| | | | | | | | | |
| +-------------+ | | | | +-------------+ |
+-----------------+ | | +-----------------+
| |
| |
+-----------------+ | | +-----------------+
| +-------------+ | | | | +-------------+ |
| | | | | | | | | |
| | +---+ V | +---+ | |
| | |TP3+------------------------>|TP4| | |
| | +---+ | +---+ | |
| | C | | | | | D | |
| | +---+ V +---+ | |
| | |TP4|<------------------------+TP5| | |
| | +---+ +---+ | |
| | | | | | | |
| +-------------+ | | +-------------+ |
+-----------------+ +-----------------+
Figure 2: Example of two unidirectional links supporting one
bidirectional link
Note: in this case each link is supported by a primary path composed
by a single link.
Busi, et al. Expires 3 September 2026 [Page 6]
Internet-Draft RFC8795 for SIMAP March 2026
It is worth noting that modelling the bidirectional link is modelled
as two unidirectional link instances allows also to unambiguously
understand which unidirectional underlay link/path supports which
direction (forward or reverse) of the overlay bidirectional link. ls
## Multi-domain Links
Multi-domain links can be represented as open-ended links on each
topology instance and unambiguously associated as multi-domain links
using either the remote node ID / link ID attribute or the inter-
domain-plug-id, as described in Section 4.2 of [RFC8795].
4. Design Considerations
Reusing existing YANG data models to support multiple applications is
a key enabler to achieve multi-vendor interoperability.
A network controller needs to support multiple applications (some of
which may not be defined at the time the network controller is
defined) and different applications have different requirements on
the data model they use internally to perform their tasks.
Exposing application-specific data models at the northbound of a
network controller appears making the application simpler to
implement when it is the only application to be implemented on top of
a given controller but results in more complex implementations for
network controllers and the applications and increase complexity to
achieve multi-vendor interoperability and integration.
Figure 3 shows a case where a controller-A is interfacing an
Application-1 through the application-specific data model designed
for Application-1 (i.e., AS1-DM) and a controller-B is interfacing
another Application-2 through the application-specific data model
designed for Application-2 (i.e., AS2-DM).
Busi, et al. Expires 3 September 2026 [Page 7]
Internet-Draft RFC8795 for SIMAP March 2026
+-------+ +-------+ +-------+ +-------+
| APP-1 | | APP-2 | | APP-1 | | APP-2 |
|(Core) | |(Core) | |(Core) | |(Core) |
+-------+ +-------+ +-------+ +-------+
^ ^ ^ ^
| / \ |
| / ??? ??? \ |
| / \ |
+--------+ / \ +--------+
| / \ |
AS1-DM | / \ | AS2-DM
| / \ |
|/ \|
+------------+------------+ +------------+------------+
| Controller-A | | Controller-B |
+-------------------------+ +-------------------------+
Notes:
- AS1-DM: Application 1 (APP-1) application-specific data model
- AS2-DM: Application 1 (APP-2) application-specific data model
Figure 3: Concerns with defining application-specific data models
The two application-specific data models can provide the same
information but with different formatting. For example,
Application-1 may need to model bidirectional links as a single
entity (link of type bidirectional) while Application-2 may need to
model bidirectional links as two unidirectional links.
This solution works well as long as Application-1 and controller-A
are deployed in different silos than Application-2 and controller-B.
Otherwise, operational and implementation issues have to be faces
when there is the need to run Application-1 over network controller-B
or, Application-2 over network controller-A.
This would require the operator to negotiate with the vendor and
controller vendors customized solutions before integrating a new
application or a new controller in the network and increased
complexity in the application and network controller implementations.
Figure 4 describes an architecture based on a common and standardized
data model to support multi-vendor integration.
Busi, et al. Expires 3 September 2026 [Page 8]
Internet-Draft RFC8795 for SIMAP March 2026
+-------+ +-------+ +-------+ +-------+
| APP-1 | | APP-2 | | APP-1 | | APP-2 |
|(Core) | |(Core) | |(Core) | |(Core) |
+-------+ +-------+ +-------+ +-------+
^ ^ ^ ^
| AS1-DM AS2-DM | | AS1-DM AS2-DM |
| | | |
+---------+ +---------+ +---------+ +---------+
| APP-1 | | APP-2 | | APP-1 | | APP-2 |
|(DM-Map1)| | (DM-Map)| | (DM-Map)| |(DM-Map2)|
+---------+ +---------+ +---------+ +---------+
^ ^ ^ ^
| | /-----------\ | |
+--------+--------+ / Common \ +--------+--------+
| \ Standard / |
NBI-DM | \-----------/ NBI-DM |
| |
| |
+------------+------------+ +------------+------------+
| Controller-A | | Controller-B |
+-------------------------+ +-------------------------+
Notes:
- AS1-DM: Application 1 (APP-1) application-specific data model
- AS2-DM: Application 1 (APP-2) application-specific data model
- NBI DM: Standard data model exposed by both network controllers
- DM-Map1: Application specific data model mapper between the NBI DM
and the AS1-DM
- DM-Map2: Application specific data model mapper between the NBI DM
and the AS2-DM
Figure 4: Use of a common and standardized data model to support
multi-vendor integration
In this case, the data model exposed by network controllers (e.g.,
controller-A and controller-B) is the same and each application needs
to translate/map the standardized data model exposed by the network
controller to its own application-specific data model.
Following this approach an existing application (e.g., Application-1)
can be ported from one controller to another controller (e.g., from
controller-A to controller-B) ideally with no change and additional
testing.
Reusing RFC8795 YANG data model for SIMAP applications will allow TE
and SIMAP application to co-exist on top of the same network
controller, allowing seamless migration from network scenarios
supporting only on of these application to network scenarios where
Busi, et al. Expires 3 September 2026 [Page 9]
Internet-Draft RFC8795 for SIMAP March 2026
both applications are supported at the same time or even scenarios
where either or both applications are supported together with new
applications not yet defined.
5. Security Considerations
TODO Security
6. IANA Considerations
This document has no IANA actions.
7. References
7.1. Normative References
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/rfc/rfc8345>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/rfc/rfc8795>.
7.2. Informative References
[I-D.havel-nmop-simap-yang]
Havel, O., Davis, N., Claise, B., de Dios, O. G., and T.
Graf, "A YANG Data Model for SIMAP", Work in Progress,
Internet-Draft, draft-havel-nmop-simap-yang-01, 20 October
2025, <https://datatracker.ietf.org/doc/html/draft-havel-
nmop-simap-yang-01>.
[I-D.ietf-nmop-simap-concept]
Havel, O., Claise, B., de Dios, O. G., and T. Graf,
"SIMAP: Concept, Requirements, and Use Cases", Work in
Progress, Internet-Draft, draft-ietf-nmop-simap-concept-
08, 23 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
simap-concept-08>.
[I-D.ietf-teas-te-topology-profiles]
Busi, I., Liu, X., Bryskin, I., Saad, T., and O. G. de
Dios, "Profiles for Traffic Engineering (TE) Topology Data
Model and Applicability to non-TE-centric Use Cases", Work
Busi, et al. Expires 3 September 2026 [Page 10]
Internet-Draft RFC8795 for SIMAP March 2026
in Progress, Internet-Draft, draft-ietf-teas-te-topology-
profiles-05, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-
topology-profiles-05>.
Appendix A. Example of deviation statements
[I-D.ietf-teas-te-topology-profiles] notes that existing
implementations of [RFC8795] have described the implemented profiled
by manually pruning/profiling the YANG tree generated fom the YANG
module defined in [RFC8795] and those pruned/profiled YANG trees
provided sufficient input for the implementers to generate proper
APIs.
However, [I-D.ietf-teas-te-topology-profiles] is also exploring the
possibility to use the YANG deviation statements to programmatically
generate pruned/profiled YANG trees.
An example of a YANG deviation module for SIMAP applications is
provided below.
module ietf-simap-deviation-example {
yang-version 1.1;
namespace "https://example.com/ns/ietf-simap-deviation-example";
prefix simapd;
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-te-topology {
prefix tet;
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
organization
"Network Management Operations (NMOP) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/group/nmop/>
WG List: <mailto:nmop@ietf.org>
Busi, et al. Expires 3 September 2026 [Page 11]
Internet-Draft RFC8795 for SIMAP March 2026
Editor: Italo Busi
<Italo.Busi@huawei.com>";
description
"This module defines an example of a YANG data model containing
the YANG deviation statements to support the implementation of
the SIMAP YANG data model re-using a sub-set of the TE topology
model.
Copyright (c) 2026 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices..";
revision 2026-03-02 {
description
"Initial version";
reference
"RFC XXXX: Applicability of existing YANG data models to
SIMAP";
}
/*
* Deviations
*/
deviation "/nw:networks/tet:te" {
description
"SIMAP implementations are not required to implement TE
templates.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/tet:te-topology-identifier" {
description
"SIMAP implementations are not required to implement TE
topology identifiers.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/tet:te" {
Busi, et al. Expires 3 September 2026 [Page 12]
Internet-Draft RFC8795 for SIMAP March 2026
description
"SIMAP implementations are not required to implement the
augmentation for TE topologies.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te-node-id" {
description
"SIMAP implementations are not required to implement TE node
identifiers.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te" {
description
"SIMAP implementations are not required to implement TE node
identifiers.";
deviate delete {
must '../te-node-id';
}
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-template" {
description
"SIMAP implementations are not required to implement TE node
templates.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:admin-status" {
description
"SIMAP implementations are not required to implement the TE
node administrative status.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:label-restrictions" {
description
"SIMAP implementations are not required to implement the label
restrictions for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
Busi, et al. Expires 3 September 2026 [Page 13]
Internet-Draft RFC8795 for SIMAP March 2026
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:underlay" {
description
"SIMAP implementations are not required to implement the
underlay paths for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:path-constraints" {
description
"SIMAP implementations are not required to implement the
path constraints for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:optimizations" {
description
"SIMAP implementations are not required to implement the
path optimizations for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:tiebreaker" {
description
"SIMAP implementations are not required to implement the
tiebreaker for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:path-properties" {
description
"SIMAP implementations are not required to implement the
path properties for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:connectivity-matrix/tet:from"
+ "/tet:label-restrictions" {
Busi, et al. Expires 3 September 2026 [Page 14]
Internet-Draft RFC8795 for SIMAP March 2026
description
"SIMAP implementations are not required to implement the label
restrictions for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:connectivity-matrix/tet:to"
+ "/tet:label-restrictions" {
description
"SIMAP implementations are not required to implement the label
restrictions for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:connectivity-matrix/tet:underlay" {
description
"SIMAP implementations are not required to implement the
underlay paths for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:connectivity-matrix/tet:path-constraints" {
description
"SIMAP implementations are not required to implement the
path constraints for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:connectivity-matrix/tet:optimizations" {
description
"SIMAP implementations are not required to implement the
path optimizations for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:connectivity-matrix/tet:tiebreaker" {
description
"SIMAP implementations are not required to implement the
Busi, et al. Expires 3 September 2026 [Page 15]
Internet-Draft RFC8795 for SIMAP March 2026
tiebreaker for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:connectivity-matrices"
+ "/tet:connectivity-matrix/tet:path-properties" {
description
"SIMAP implementations are not required to implement the
path properties for the connectivity matrix.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes/tet:signaling-address" {
description
"SIMAP implementations are not required to implement the
node's signaling address.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:geolocation" {
description
"SIMAP implementations are not required to implement the
node's geolocation.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:is-multi-access-dr" {
description
"SIMAP implementations are not required to implement the
designated router information.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:information-source" {
description
"SIMAP implementations are not required to implement the
node's information source (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:information-source-instance" {
description
Busi, et al. Expires 3 September 2026 [Page 16]
Internet-Draft RFC8795 for SIMAP March 2026
"SIMAP implementations are not required to implement the
node's information source (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:information-source-state" {
description
"SIMAP implementations are not required to implement the
node's information source (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:information-source-entry" {
description
"SIMAP implementations are not required to implement the
node's information source (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:statistics" {
description
"SIMAP implementations are not required to implement the
node's statistics (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:tunnel-termination-point" {
description
"SIMAP implementations are not required to implement the
tunnel termination points (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:bundle-stack-level/tet:component" {
description
"SIMAP implementations are not required to implement the
bundle links as a set of component interfaces.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-template" {
description
Busi, et al. Expires 3 September 2026 [Page 17]
Internet-Draft RFC8795 for SIMAP March 2026
"SIMAP implementations are not required to implement the
TE link templates.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:underlay/tet:primary-path"
+ "/tet:path-element/tet:type/tet:label" {
description
"SIMAP implementations are not required to implement the
label hop.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:underlay/tet:primary-path"
+ "/tet:path-element/tet:type/tet:as-number" {
description
"SIMAP implementations are not required to implement the
AS hop.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:underlay/tet:backup-path"
+ "/tet:path-element/tet:type/tet:label" {
description
"SIMAP implementations are not required to implement the
label hop.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:underlay/tet:backup-path"
+ "/tet:path-element/tet:type/tet:as-number" {
description
"SIMAP implementations are not required to implement the
AS hop.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:underlay/"
+ "tet:protection-type" {
description
"SIMAP implementations are not required to implement the
protection type for the backup paths of a link.";
deviate not-supported;
Busi, et al. Expires 3 September 2026 [Page 18]
Internet-Draft RFC8795 for SIMAP March 2026
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:underlay"
+ "/tet:tunnel-termination-points" {
description
"SIMAP implementations are not required to implement the
underlay tunnel termination points of a link
(to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:underlay"
+ "/tet:tunnels" {
description
"SIMAP implementations are not required to implement the
underlay tunnels of a link (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:admin-status" {
description
"SIMAP implementations are not required to implement the
administrative status of a link.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:link-index" {
description
"SIMAP implementations are not required to implement the
link identifier.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:administrative-group" {
description
"SIMAP implementations are not required to implement the
administrative groups of a link.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes"
+ "/tet:interface-switching-capability"
Busi, et al. Expires 3 September 2026 [Page 19]
Internet-Draft RFC8795 for SIMAP March 2026
+ "/tet:max-lsp-bandwidth" {
description
"SIMAP implementations are not required to implement the
maximum LSP bandwidth.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:label-restrictions" {
description
"SIMAP implementations are not required to implement the
label restrictions of a link.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:link-protection-type" {
description
"SIMAP implementations are not required to implement the
link protection type.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:max-link-bandwidth" {
description
"SIMAP implementations are not required to implement the
bandwidth information (capacity) of a link.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:max-resv-link-bandwidth" {
description
"SIMAP implementations are not required to implement the
bandwidth information (capacity) of a link.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:unreserved-bandwidth" {
description
"SIMAP implementations are not required to implement the
bandwidth information (capacity) of a link.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
Busi, et al. Expires 3 September 2026 [Page 20]
Internet-Draft RFC8795 for SIMAP March 2026
+ "/tet:te-link-attributes/tet:te-default-metric" {
description
"SIMAP implementations are not required to implement the
TE default metric of a link (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:te-delay-metric" {
description
"SIMAP implementations are not required to implement the
delay of a link (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:te-igp-metric" {
description
"SIMAP implementations are not required to implement the
IGP metric of a link (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:te-srlgs" {
description
"SIMAP implementations are not required to implement the
Shared Risk Link Groups (SRLGs) of a link (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes/tet:te-nsrlgs" {
description
"SIMAP implementations are not required to implement the
Non-Shared Risk Link Groups (NSRLGs) of a link
(to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:information-source" {
description
"SIMAP implementations are not required to implement the
link's information source (to be confirmed).";
deviate not-supported;
}
Busi, et al. Expires 3 September 2026 [Page 21]
Internet-Draft RFC8795 for SIMAP March 2026
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:information-source-instance" {
description
"SIMAP implementations are not required to implement the
link's information source (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:information-source-state" {
description
"SIMAP implementations are not required to implement the
link's information source (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:information-source-entry" {
description
"SIMAP implementations are not required to implement the
link's information source (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:recovery" {
description
"SIMAP implementations are not required to report the status
of the recovery process on a link.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:underlay" {
description
"SIMAP implementations are not required to report the state
attributes for the TE link underlay.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:statistics" {
description
"SIMAP implementations are not required to implement the
link's statistics (to be confirmed).";
deviate not-supported;
}
Busi, et al. Expires 3 September 2026 [Page 22]
Internet-Draft RFC8795 for SIMAP March 2026
deviation "/nw:networks/nw:network/nw:node/nt:termination-point"
+ "/tet:te-tp-id" {
description
"SIMAP implementations are not required to implement TE
termination point identifier.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/nt:termination-point"
+ "/tet:te" {
description
"SIMAP implementations are not required to implement TE
termination point identifier.";
deviate delete {
must '../te-tp-id';
}
}
deviation "/nw:networks/nw:network/nw:node/nt:termination-point"
+ "/tet:te/tet:admin-status" {
description
"SIMAP implementations are not required to implement the
administrative status of a termination point.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/nt:termination-point"
+ "/tet:te/tet:interface-switching-capability" {
description
"SIMAP implementations are not required to report the
'interface-switching-capability' on the termination points.";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/nt:termination-point"
+ "/tet:te/tet:inter-layer-lock-id" {
description
"SIMAP implementations are not required to implement the
inter-layer lock-id (to be confirmed).";
deviate not-supported;
}
deviation "/nw:networks/nw:network/nw:node/nt:termination-point"
+ "/tet:te/tet:geolocation" {
description
"SIMAP implementations are not required to implement the
geolocation of a termination point.";
deviate not-supported;
Busi, et al. Expires 3 September 2026 [Page 23]
Internet-Draft RFC8795 for SIMAP March 2026
}
}
Figure 5: Example of SIMA deviation YANG module
The pruned/profiled YANG tree, generated using 'pyang' tool, is
provided below:
module: ietf-network
+--rw networks
+--rw network* [network-id]
+--rw network-id network-id
+--rw network-types
| +--rw tet:te-topology!
+--rw supporting-network* [network-ref]
| +--rw network-ref -> /networks/network/network-id
+--rw node* [node-id]
| +--rw node-id node-id
| +--rw supporting-node* [network-ref node-ref]
| | +--rw network-ref
| | | -> ../../../supporting-network/network-ref
| | +--rw node-ref -> /networks/network/node/node-id
| +--rw nt:termination-point* [tp-id]
| | +--rw nt:tp-id tp-id
| | +--rw nt:supporting-termination-point*
| | | [network-ref node-ref tp-ref]
| | | +--rw nt:network-ref
| | | | -> ../../../nw:supporting-node/network-ref
| | | +--rw nt:node-ref
| | | | -> ../../../nw:supporting-node/node-ref
| | | +--rw nt:tp-ref leafref
| | +--rw tet:te!
| | +--rw tet:name? string
| | +--rw tet:inter-domain-plug-id? binary
| | +--ro tet:oper-status?
| | te-types:te-oper-status
| +--rw tet:te!
| +--rw tet:te-node-attributes
| | +--rw tet:connectivity-matrices
| | | +--rw tet:number-of-entries? uint16
| | | +--rw tet:is-allowed? boolean
| | | +--rw tet:connectivity-matrix* [id]
| | | +--rw tet:id uint32
| | | +--rw tet:from
| | | | +--rw tet:tp-ref? leafref
| | | +--rw tet:to
| | | | +--rw tet:tp-ref? leafref
| | | +--rw tet:is-allowed? boolean
Busi, et al. Expires 3 September 2026 [Page 24]
Internet-Draft RFC8795 for SIMAP March 2026
| | +--rw tet:domain-id? uint32
| | +--rw tet:is-abstract? empty
| | +--rw tet:name? string
| | +--rw tet:underlay-topology {te-topology-hierarchy}?
| | +--rw tet:network-ref?
| | -> /nw:networks/network/network-id
| +--ro tet:oper-status? te-types:te-oper-status
+--rw nt:link* [link-id]
+--rw nt:link-id link-id
+--rw nt:source
| +--rw nt:source-node? -> ../../../nw:node/node-id
| +--rw nt:source-tp? leafref
+--rw nt:destination
| +--rw nt:dest-node? -> ../../../nw:node/node-id
| +--rw nt:dest-tp? leafref
+--rw nt:supporting-link* [network-ref link-ref]
| +--rw nt:network-ref
| | -> ../../../nw:supporting-network/network-ref
| +--rw nt:link-ref leafref
+--rw tet:te!
+--rw (tet:bundle-stack-level)?
| +--:(tet:bundle)
| +--rw tet:bundled-links
| +--rw tet:bundled-link* [sequence]
| +--rw tet:sequence uint32
| +--rw tet:src-tp-ref? leafref
| +--rw tet:des-tp-ref? leafref
+--rw tet:te-link-attributes
| +--rw tet:access-type?
| | te-types:te-link-access-type
| +--rw tet:external-domain
| | +--rw tet:network-ref?
| | | -> /nw:networks/network/network-id
| | +--rw tet:remote-te-node-id?
| | | te-types:te-node-id
| | +--rw tet:remote-te-link-tp-id?
| | te-types:te-tp-id
| +--rw tet:is-abstract? empty
| +--rw tet:name? string
| +--rw tet:underlay {te-topology-hierarchy}?
| | +--rw tet:enabled? boolean
| | +--rw tet:primary-path
| | | +--rw tet:network-ref?
| | | | -> /nw:networks/network/network-id
| | | +--rw tet:path-element* [path-element-id]
| | | +--rw tet:path-element-id
| | | | uint32
| | | +--rw (tet:type)?
Busi, et al. Expires 3 September 2026 [Page 25]
Internet-Draft RFC8795 for SIMAP March 2026
| | | +--:(tet:numbered-node-hop)
| | | | +--rw tet:numbered-node-hop
| | | | +--rw tet:node-id-uri?
| | | | | nw:node-id
| | | | +--rw tet:node-id?
| | | | | te-node-id
| | | | +--rw tet:hop-type?
| | | | te-hop-type
| | | +--:(tet:numbered-link-hop)
| | | | +--rw tet:numbered-link-hop
| | | | +--rw tet:link-tp-id te-tp-id
| | | | +--rw tet:hop-type?
| | | | | te-hop-type
| | | | +--rw tet:direction?
| | | | te-link-direction
| | | +--:(tet:unnumbered-link-hop)
| | | +--rw tet:unnumbered-link-hop
| | | +--rw tet:link-tp-id-uri?
| | | | nt:tp-id
| | | +--rw tet:link-tp-id?
| | | | te-tp-id
| | | +--rw tet:node-id-uri?
| | | | nw:node-id
| | | +--rw tet:node-id?
| | | | te-node-id
| | | +--rw tet:hop-type?
| | | | te-hop-type
| | | +--rw tet:direction?
| | | te-link-direction
| | +--rw tet:backup-path* [index]
| | +--rw tet:index uint32
| | +--rw tet:network-ref?
| | | -> /nw:networks/network/network-id
| | +--rw tet:path-element* [path-element-id]
| | +--rw tet:path-element-id
| | | uint32
| | +--rw (tet:type)?
| | +--:(tet:numbered-node-hop)
| | | +--rw tet:numbered-node-hop
| | | +--rw tet:node-id-uri?
| | | | nw:node-id
| | | +--rw tet:node-id?
| | | | te-node-id
| | | +--rw tet:hop-type?
| | | te-hop-type
| | +--:(tet:numbered-link-hop)
| | | +--rw tet:numbered-link-hop
| | | +--rw tet:link-tp-id te-tp-id
Busi, et al. Expires 3 September 2026 [Page 26]
Internet-Draft RFC8795 for SIMAP March 2026
| | | +--rw tet:hop-type?
| | | | te-hop-type
| | | +--rw tet:direction?
| | | te-link-direction
| | +--:(tet:unnumbered-link-hop)
| | +--rw tet:unnumbered-link-hop
| | +--rw tet:link-tp-id-uri?
| | | nt:tp-id
| | +--rw tet:link-tp-id?
| | | te-tp-id
| | +--rw tet:node-id-uri?
| | | nw:node-id
| | +--rw tet:node-id?
| | | te-node-id
| | +--rw tet:hop-type?
| | | te-hop-type
| | +--rw tet:direction?
| | te-link-direction
| +--rw tet:interface-switching-capability*
| [switching-capability encoding]
| +--rw tet:switching-capability identityref
| +--rw tet:encoding identityref
+--ro tet:oper-status?
| te-types:te-oper-status
+--ro tet:is-transitional? empty
Acknowledgments
TODO acknowledge.
Authors' Addresses
Italo Busi
Huawei
Email: italo.busi@huawei.com
Aihua Guo
Futurewei Technologies
Email: aihuaguo.ietf@gmail.com
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Busi, et al. Expires 3 September 2026 [Page 27]
Internet-Draft RFC8795 for SIMAP March 2026
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Tarek Saad
Cisco Systems Inc.
Email: tsaad.net@gmail.com
Busi, et al. Expires 3 September 2026 [Page 28]