YANG Model for Logical Network Elements
Extracted elements (22)
An LNE is modeled as an independently managed virtual device analogous to a virtual machine guest: it has its own management interfaces, YANG models, and namespace, so multiple LNEs may each define a 'Tunnel0' without conflict. This independence is expressed via the YANG Schema Mount 'root' mount point rather than a flat namespace.
Interface assignment is performed at the host level via bind-lne-name augmenting ietf-interfaces; to assign an interface to both an LNE and a Network Instance (NI), it is first assigned to the LNE, and then within that LNE's interface model it is assigned to an NI using RFC 8529 mechanisms.
The 'inline' schema-mount approach is anticipated for self-managed LNEs (managed=false) where each LNE may have a different module set, while 'shared-schema' is expected when all LNEs share the same schema, enabling more efficient representation at the host level.
The 'managed' boolean distinguishes host-device-managed LNEs (where the host can read/write the LNE's mounted data tree) from self-managed LNEs (where only the LNE's own management sessions have access). This distinction is necessary because some implementations—particularly those using traditional hypervisors—cannot expose LNE internals to the host.
The logical-network-element module currently defines only a single augmentation for interface assignment (bind-lne-name). Future modules defining other host device resources (hardware, QoS, etc.) are expected to provide parallel augmentations for assigning those resources to LNEs.
The name of the system-created interface within the LNE is a local matter and may be identical or completely different from the name used in the host device context; implementations may rename assigned interfaces (e.g., host 'Ethernet0/1' becomes LNE 'eth1').
An LNE root MUST contain at least the YANG library (RFC 7895) and the interface module (RFC 8343).
Attempts to access information below a root node whose associated 'managed' boolean is set to 'false' MUST result in the error message indicated (error-tag 'access-denied', error-app-tag 'lne-not-managed').
If an interface assignment fails for any reason other than a missing leafref, the operation SHALL fail with error-tag 'operation-failed' and error-app-tag 'lne-assignment-failed'; a meaningful error-info SHOULD also be provided.
On a successful interface assignment to an LNE, an implementation MUST also make the resource available to the LNE by providing a system-created interface to the LNE.
The system-created interface representing an assigned resource within the LNE SHOULD be exposed via the LNE-specific instance of the interface model (RFC 8343).
When bind-lne-name is set to a valid LNE name, an implementation MUST take whatever steps are internally necessary to assign the interface to the LNE or provide an error message with an indication of why the assignment failed.
When LNE information is available from both the host device and from within the context of the LNE, the same information MUST be made available via the 'root' element, with paths modified as described in RFC 8528.
When 'shared-schema' is used with an LNE mount point, the YANG library rooted in the LNE's mount point MUST match the associated schema defined according to the ietf-yang-schema-mount module.
When the 'managed' boolean is 'true', LNE information SHALL be accessible from the context of the host device; when the associated schema-mount 'config' leaf is 'true', LNE information SHALL also be modifiable from the host device context.
The 'bind-lne-name-failed' notification is generated asynchronously when an interface-to-LNE assignment fails after initial success was returned; it carries mandatory 'name' and 'bind-lne-name' leafrefs and an optional 'error-info' string.
The ietf-logical-network-element YANG module defines a container 'logical-network-elements' holding a list 'logical-network-element' keyed by 'name', with leaves for 'name' (string), 'managed' (boolean, default true), 'description' (string), and a schema mount point 'root'.
The module augments /if:interfaces/if:interface with a 'bind-lne-name' leaf (type leafref pointing to /logical-network-elements/logical-network-element/name) to associate an interface with an LNE.
The 'root' container within each logical-network-element entry is a YANG Schema Mount point (RFC 8528) that exposes the root of the LNE's independent YANG data tree; it SHALL always contain a YANG library (RFC 7895) and interfaces (RFC 8343) instance.
This document registers a URI 'urn:ietf:params:xml:ns:yang:ietf-logical-network-element' in the IETF XML Registry (RFC 3688) and registers the module name 'ietf-logical-network-element' with prefix 'lne' in the YANG Module Names registry (RFC 6020).
The bind-lne-name leaf is a high-impact configuration parameter: removing an interface from an LNE is similar to physically removing a hardware interface and can severely disrupt the LNE's operation. Implementations should carefully control when changes to this leaf are permitted.
The YANG module MUST be accessed via secure transports: NETCONF over SSH (RFC 6242) or RESTCONF over HTTPS/TLS (RFC 8446); access control is provided by NACM (RFC 8341). The 'managed' leaf is particularly sensitive in multi-party environments where the LNE operator may not wish to share LNE information with the host device operator.