A YANG Data Model for
Layer 3 TopologiesHuaweiludwig@clemm.orgCiscojmedved@cisco.comPantheon Technologies SROrobert.varga@pantheon.techJabilXufeng_Liu@jabil.comPacket Designhari@packetdesign.comBracket Computingnitin_bahadur@yahoo.comThis document defines a YANG data model for layer 3 network
topologies.
This document introduces a YANG
data model for Layer 3 network topologies, specifically Layer 3 Unicast.
The model
allows an application to have a holistic view of the topology of a Layer
3 network, all contained in a single conceptual YANG datastore.
The data
model builds on top of, and augments, the data model for network
topologies defined in
.This document also shows how the model
can be further refined to cover different
Layer 3 Unicast topology types. For this purpose, an example model is
introduced that covers OSPF . This example is intended purely for illustrative purpose;
we expect that a complete OSPF model will be more comprehensive
and refined than the example shown here. There are multiple applications for a topology data model.
A number of
use cases have been defined in section 6 of
.
For example,
nodes within the network can use the data model to capture their
understanding of the overall network topology and expose it to a network
controller. A network controller can then use the instantiated topology
data to compare and reconcile its own view of the network topology with
that of the network elements that it controls. Alternatively, nodes
within the network could propagate this understanding to compare and
reconcile this understanding either amongst themselves or with help of a
controller. Beyond the network element itself, a network controller
might even use the data model to represent its view of the topology that
it controls and expose it to applications north of itself.
The data model for Layer 3 Unicast topologies
defined in this document
is specified
in a YANG module "ietf-l3-unicast-topology".
To do so, it augments the general network
topology model defined in
with
information specific to Layer 3 Unicast. This way, the general
topology model is extended to be able to meet the needs
of Layer 3 Unicast topologies.Information that is kept in the
Traffic Engineering Database (TED) will be
specified in a separate model
and outside the scope of this
specification.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they
appear in all capitals, as shown here.
As this document defines a YANG data model, in this document many
terms are used that have been defined in conjunction
with YANG
and NETCONF . Some terms, such as
datastore and data tree, are repeated here for clarity and to
put them in context.Datastore: A conceptual place to store and access information. A
datastore might be implemented, for example, using files, a
database, flash memory locations, or combinations thereof. A
datastore maps to an instantiated YANG data tree. (Definition adopted from )Data subtree: An instantiated data node and the data nodes that are
hierarchically contained within it.IGP: Interior Gateway ProtocolIS-IS: Intermediate System to Intermediate System protocolLSP: Label Switched PathNETCONF: Network Configuration ProtocolNMDA: Network Management Datastore ArchitectureOSPF: Open Shortest Path First, a link state routing protocolURI: Uniform Resource IdentifierSRLG: Shared Risk Link GroupTED: Traffic Engineering DatabaseYANG: YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network
management protocols The Layer 3 Unicast topology model is defined by YANG module
"l3-unicast-topology". The relationship of this module with
other YANG modules is roughly depicted in the figure below.
YANG modules "ietf-network" and "ietf-network-topology"
collectively define the basic network topology
model .
YANG module "ietf-l3-unicast-topology" augments those models
with additional definitions needed to represent Layer 3 Unicast
topologies. This module in turn can be augmented by YANG modules with
additional definitions for specific types of Layer 3 Unicast topologies,
such as OSPF and for IS-IS topologies.
The YANG modules ietf-network and ietf-network-topology are designed to be used
in conjunction with implementations that support the Network Management
Datastore Architecture (NMDA) defined in .
Accordingly, the same is true for the YANG modules that augment it.
In order to allow implementations to use the model even in cases when NMDA is not
supported, companion YANG modules (that SHOULD NOT be supported by implementations
that support NMDA) are defined in an Appendix, see .
The Layer 3 Unicast topology model is defined by YANG module
"ietf-l3-unicast-topology". Its structure is depicted in the following
diagram. The notation syntax
follows . For purposes of brevity, notifications are not depicted.
The module augments the original ietf-network and
ietf-network-topology modules as
follows: A new network topology type is introduced,
l3-unicast-topology. The corresponding container
augments the network-types of the ietf-network module. Additional topology attributes are introduced, defined in a
grouping, which augments the "network" list of the network
module. The attributes include a name for the topology, as well as a
set of flags (represented through a leaf-list). Each type of flag
is represented by a separate identity. This allows to introduce
additional flags in augmenting modules using additional identities
without needing to revise this module.Additional data objects for nodes are introduced by augmenting
the "node" list of the network module. New objects
include again a set of flags, as well as a list of prefixes. Each
prefix in turn includes an ip prefix, a metric, and a
prefix-specific set of flags.Links (in the ietf-network-topology module) are augmented
with a set of parameters as well, allowing
to associate a link with a link name, another set of flags, and a
link metric.Termination points (in the ietf-network-topology module as well)
are augmented with a choice of IP address,
identifier, or name.In addition, the module defines a set of notifications to alert
clients of any events concerning links, nodes, prefixes, and
termination points. Each notification includes an indication of the
type of event, the topology from which it originated, and the affected
node, or link, or prefix, or termination point. In addition, as a
convenience to applications, additional data of the affected node, or
link, or termination point (respectively) is included. While this
makes notifications larger in volume than they would need to be, it
avoids the need for subsequent retrieval of context information, which
also might have changed in the meantime.
As described in section ,
the model builds on top of, and augments, the YANG modules defined in
. Specifically,
module ietf-l3-unicast-topology augments modules "ietf-network" and
"ietf-network-topology". In addition, the model makes use of data types
that have been defined in .
The model defines a protocol independent YANG data model with
layer 3 topology information.
It is separate from and not linked with data models that are used to
configure routing protocols or routing information.
This includes e.g. model "ietf-routing"
and model "ietf-fb-rib" .
The model obeys the requirements for the ephemeral state found in the document
.
For ephemeral topology data that is server provided,
the process tasked with maintaining topology information will load information from the routing process
(such as OSPF) into the data model without relying on a configuration datastore.
This document registers the following namespace URIs in the "IETF XML
Registry" :
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG
Module Names" registry :
Name: ietf-l3-unicast-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Prefix: l3t
Reference: draft-ietf-i2rs-yang-l3-topology-15.txt (RFC form)
Name: ietf-l3-unicast-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
Prefix: l3t-s
Reference: draft-ietf-i2rs-yang-l3-topology-15.txt (RFC form)
The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS .
The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
In general, Layer 3 Unicast topologies are system-controlled and provide ephemeral
topology information. In an NMDA-complient server, they are only part of <operational> which provides read-only access to clients, they are less
vulnerable. That said, the YANG module does in principle allow information to be configurable.
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability in the ietf-network module:
l3-topology-attributes: A malicious client could attempt to sabotage the configuration of any of the ctonained attributes, i.e. the name or the flag data nodes. l3-node-attributes: A malicious client could attempt to sabotage the configuration of important node attributes, such as the router-id or node prefix. l3-link-attributes: A malicious client could attempt to sabotage the configuration of important link attributes, such as name, flag, and metrics of the link respectively corresponding data nodes.l3-termination-point-attributes: A malicious client could attempt to sabotage the configuration information of a termination point, such as its ip-address and interface name, respectively the corresponding data nodes. The model presented in this document was contributed to by more people
than can be listed on the author list. Additional contributors include:
Vishnu Pavan Beeram, JuniperIgor Bryskin, HuaweiKen Gray, CiscoAihua Guo, HuaweiTom Nadeau, BrocadeTony TkacikAleksandr Zhdankin, CiscoWe wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Alia
Atlas, Andy Bierman, Benoit Claise, Joel Halpern, Susan Hares, Ladislav Lhotka,
Carl Moberg, Carlos Pignataro, Juergen Schoenwaelder, Michal Vasco, and Kent Watsen. Use of OSI IS-IS for Routing in TCP/IP and Dual
EnvironmentsKey words for use in RFCs to indicate requirement levelsOSPF Version 2The Interfaces Group MIBThe IETF XML RegistryThe Transport Layer Security (TLS) Protocol Version 1.2YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)Network Configuration Protocol (NETCONF)Using the NETCONF Protocol over Secure Shell (SSH)Network Configuration Protocol (NETCONF) Access Control ModelCommon YANG Data TypesThe YANG 1.1 Data Modeling LanguageJSON Encoding of Data Modeled with YANGA YANG Data Model for Network TopologiesA Revised Conceptual Model for YANG DatastoresA YANG Data Model for Routing ManagementA YANG Data Model for Routing ManagementRESTCONF ProtocolAmbiguity of Uppercase vs Lowercase in RFC 2119 Key WordsI2RS Ephemeral State RequirementsSummary of I2RS Use Case RequirementsYANG Data Model for RIB ExtensionsYANG Data Model for TE TopologiesYANG Tree Diagrams
The YANG module ietf-l3-unicast-topology defined in this document
augments two modules, ietf-network
and ietf-network-topology, that are designed
to be used in conjunction with implementations that support the Network Management
Datastore Architecture (NMDA) defined in
.
In order to allow implementations to use the model even in cases
when NMDA is not supported, a set of companion modules have been defined
that represent a state model of networks and network topologies,
ietf-network-state and ietf-network-topology-state, respectively.
In order to be able to use the model for layer 3 topologies defined in this
in this document in conjunction with non-NMDA compliant implementations,
a corresponding companion module needs to be introduced as well.
This companion module, ietf-l3-unicast-topology-state,
mirrors ietf-l3-unicast-topology. However,
the module augments ietf-network-state and ietf-network-topology-state
(instead of ietf-network and ietf-network-topology) and all
of its data nodes are non-configurable.
Similar considerations apply for any modules that augment ietf-l3-unicast-topology,
such as the example modules defined in see , example-ospf-topology.
For non-NMDA compliant implementations, companion
modules will need to be introduced that represent state information and are
non-configurable, augmenting ietf-l3-unicast-topology-state instead of
ietf-l3-unicast-topology. Because they served as examples only, companion modules
for those examples are not given.
Like ietf-network-state and ietf-network-topology-state, ietf-l3-unicast-topology
SHOULD NOT be supported by implementations
that support NMDA. It is for this reason that the module is defined in the Appendix.
The definition of the module follows below. As the structure of the module mirrors that of its underlying
module, the YANG tree is not depicted separately.
The model can be extended for specific Layer 3 Unicast types.
Examples include OSPF and IS-IS topologies.
In the following, one additional YANG module is introduced
that define simple
topology model for OSPF.
This module is intended to serve as an example that illustrates
how the general topology model can be refined across multiple levels.
It does not constitute full-fledged OSPF topology model
which may be more comprehensive and refined than the model
that is described here.The following model shows how the Layer 3 Unicast topology model can be
extended, in this case to cover OSFP topologies.
For this purpose, a set of augmentations are introduced
in a separate YANG module, "example-ospf-topology", whose structure is depicted
in the following diagram.
As before, the notation syntax
follows .
The module augments "ietf-l3-unicast-topology" as follows: A new topology type for an OSPF topology is introduced.Additional topology attributes are defined in a new grouping
which augments l3-topology-attributes of the
ietf-l3-unicast-topology module. The attributes include an OSPF
area-id identifying the OSPF area.Additional data objects for nodes are introduced by augmenting
the l3-node-attributes of the l3-unicast-topology module. New
objects include router-type and dr-interface-id for pseudonodes.
Links are augmented with ospf link attributes. In addition, the module extends notifications for events
concerning Layer 3
nodes and links with OSPF attributes.
It should be noted that the model defined here
represents topology and is intended as an example.
It does not define how to configure
OSPF routers or interfaces.
The OSPF Topology YANG Module is specified below.
As mentioned, the module is intended as an example for how
the Layer 3 Unicast topology model can be
extended to cover OSFP topologies,
but it is not normative. Accordingly, the module is not delimited
with CODE BEGINS and CODE ENDS tags.
This section contains an example of an instance data tree in JSON
encoding . The example instantiates ietf-l3-unicast-topology for the topology that is depicted in the following diagram.
There are three nodes, D1, D2, and D3. D1 has three termination points, 1-0-1, 1-2-1, and 1-3-1. D2 has three termination points as well, 2-1-1, 2-0-1, and 2-3-1. D3 has two termination points, 3-1-1 and 3-2-1. In addition there are six links, two between each pair of nodes with one going in each direction.
The corresponding instance data tree is depicted below: