| Internet-Draft | RFC8795 for SIMAP | March 2026 |
| Busi, et al. | Expires 3 September 2026 | [Page] |
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.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 (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.¶
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.¶
TODO Conventions and Definitions¶
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.¶
Multipoint links can be modelled as pseudonodes, as described in Section 4.4.5 of [RFC8345].¶
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.¶
[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.¶
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].¶
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:¶
Note: in this case each link is supported by a primary path composed by a single link.¶
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].¶
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).¶
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.¶
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 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.¶
TODO Security¶
This document has no IANA actions.¶
[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>
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" {
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"
+ "/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" {
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
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
"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
"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;
}
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"
+ "/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"
+ "/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;
}
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;
}
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;
}
}
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
| | +--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)?
| | | +--:(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
| | | +--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
¶
TODO acknowledge.¶