Network Instance Model
draft-ietf-rtgwg-ni-model-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8529.
|
|
|---|---|---|---|
| Authors | Lou Berger , Christian Hopps , Acee Lindem , Dean Bogdanović | ||
| Last updated | 2016-06-25 | ||
| Replaces | draft-rtgyangdt-rtgwg-ni-model | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
RTGDIR Early review
(of
-02)
by John Scudder
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8529 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-rtgwg-ni-model-00
Network Working Group L. Berger
Internet-Draft LabN Consulting, L.L.C.
Intended status: Standards Track C. Hopps
Expires: December 25, 2016 Deutsche Telekom
A. Lindem
Cisco Systems
D. Bogdanovic
June 23, 2016
Network Instance Model
draft-ietf-rtgwg-ni-model-00
Abstract
This document defines a network instance module. This module along
with the logical network element module can be used to manage the
logical and virtual resource representations that may be present on a
network device. Examples of common industry terms for logical
resource representations are Logical Systems or Logical Routers.
Examples of common industry terms for virtual resource
representations are Virtual Routing and Forwarding (VRF) instances
and Virtual Switch Instances (VSIs).
Status of This Memo
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 http://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 December 25, 2016.
Copyright Notice
Copyright (c) 2016 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
Berger, et al. Expires December 25, 2016 [Page 1]
Internet-Draft LNE Model June 2016
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Status of Work and Open Issues . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Network Instance Policy . . . . . . . . . . . . . . . . . 6
3.2. Network Instance Management . . . . . . . . . . . . . . . 7
3.3. Network Instance Instantiation . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
This document defines the second of two new modules that are defined
to support the configuration and operation of network-devices that
allow for the partitioning of resources from both, or either,
management and networking perspectives. Both make use of emerging
YANG functionality supported by YANG Schema Mount
[I-D.ietf-netmod-schema-mount]. This document is expected to use
whatever Schema Mount solution is agreed upon by the Netmod Working
Group.
Two forms of resource partitioning are supported:
The first form, which is defined in [LNE-MODEL], provides a logical
partitioning of a network device where each partition is separately
managed as essentially an independent network element which is
'hosted' by the base network device. These hosted network elements
are referred to as logical network elements, or LNEs, and are
supported by the logical-network-element module defined in
[LNE-MODEL]. The module is used to identify LNEs and associate
resources from the network-device with each LNE. LNEs themselves are
Berger, et al. Expires December 25, 2016 [Page 2]
Internet-Draft LNE Model June 2016
represented in YANG as independent network devices; each accessed
independently. Optionally, and when supported by the implementation,
they may also be accessed from the host system. Examples of vendor
terminology for an LNE include logical system or logical router, and
virtual switch, chassis, or fabric.
The second form, which is defined in this document, provides support
what is commonly referred to as Virtual Routing and Forwarding (VRF)
instances as well as Virtual Switch Instances (VSI), see [RFC4026].
In this form of resource partitioning multiple control plane and
forwarding/bridging instances are provided by and managed via a
single (physical or logical) network device. This form of resource
partitioning is referred to as Network Instances and are supported by
the network-instance module defined below. Configuration and
operation of each network-instance is always via the network device
and the network-instance module.
This document was motivated by, and derived from, [RTG-DEVICE-MODEL].
1.1. Status of Work and Open Issues
The top open issues are:
1. This document will need to match the evolution and
standardization of [I-D.openconfig-netmod-opstate] or
[I-D.ietf-netmod-opstate-reqs] by the Netmod WG.
2. Overview
In this document, we consider network devices that support protocols
and functions defined within the IETF Routing Area, e.g, routers,
firewalls and hosts. Such devices may be physical or virtual, e.g.,
a classic router with custom hardware or one residing within a
server-based virtual machine implementing a virtual network function
(VNF). Each device may sub-divide their resources into logical
network elements (LNEs) each of which provides a managed logical
device. Examples of vendor terminology for an LNE include logical
system or logical router, and virtual switch, chassis, or fabric.
Each LNE may also support virtual routing and forwarding (VRF) and
virtual switching instance (VSI) functions, which are referred to
below as a network instances (NIs). This breakdown is represented in
Figure 1.
Berger, et al. Expires December 25, 2016 [Page 3]
Internet-Draft LNE Model June 2016
,''''''''''''''''''''''''''''''''''''''''''''''`.
| Network Device (Physical or Virtual) |
| ..................... ..................... |
| : Logical Network : : Logical Network : |
| : Element : : Element : |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| :| Net | Net | Net |: :| Net | Net | Net |: |
| :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | |
Interfaces Interfaces
Figure 1: Module Element Relationships
A model for LNEs is described in [LNE-MODEL] and the model for
network instances is covered in Section 3. For more information on
how these models may be used within an overall device model
structure, see [RTG-DEVICE-MODEL].
The interface management model [RFC7223] is an existing model that is
impacted by the definition of LNEs and network instances. This
document and [LNE-MODEL] define augmentations to the interface module
to support LNEs and NIs. Similar elements, although perhaps only for
LNEs, may also need to be included as part of the definition of the
future hardware and QoS modules.
Interfaces are a crucial part of any network device's configuration
and operational state. They generally include a combination of raw
physical interfaces, link-layer interfaces, addressing configuration,
and logical interfaces that may not be tied to any physical
interface. Several system services, and layer 2 and layer 3
protocols may also associate configuration or operational state data
with different types of interfaces (these relationships are not shown
for simplicity). The interface management model is defined by
[RFC7223].
The logical-network-element and network-instance modules augment the
existing interface management model in two ways: The first, by the
logical-network-element module, adds an identifier which is used on
physical interface types to identify an associated LNE. The second,
by the network-instance module, adds a name which is used on
interface or sub-interface types to identify an associated network
instance. Similarly, this name is also added for IPv4 and IPv6
types, as defined in [RFC7277].
Berger, et al. Expires December 25, 2016 [Page 4]
Internet-Draft LNE Model June 2016
The interface related augmentations are as follows:
module: ietf-logical-network-element
augment /if:interfaces/if:interface:
+--rw bind-lne-name? string
module: ietf-network-instance
augment /if:interfaces/if:interface:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-network-instance-name? string
The following is an example of envisioned combined usage. The
interfaces container includes a number of commonly used components as
examples:
+--rw if:interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw bind-lne-name? string
| +--rw ethernet
| | +--rw ni:bind-network-instance-name? string
| | +--rw aggregates
| | +--rw rstp
| | +--rw lldp
| | +--rw ptp
| +--rw vlans
| +--rw tunnels
| +--rw ipv4
| | +--rw ni:bind-network-instance-name? string
| | +--rw arp
| | +--rw icmp
| | +--rw vrrp
| | +--rw dhcp-client
| +--rw ipv6
| +--rw ni:bind-network-instance-name? string
| +--rw vrrp
| +--rw icmpv6
| +--rw nd
| +--rw dhcpv6-client
The [RFC7223] defined interface model is structured to include all
interfaces in a flat list, without regard to logical or virtual
instances (e.g., VRFs) supported on the device. The bind-lne-name
and bind-network-instance-name leaves provide the association between
an interface and its associated LNE and NI (e.g., VRF or VSI).
Berger, et al. Expires December 25, 2016 [Page 5]
Internet-Draft LNE Model June 2016
3. Network Instances
The network instance container is used to represent virtual routing
and forwarding instances (VRFs) and virtual switching instances
(VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate
routing and switching domains, for example to create virtual private
networks, each with their own active protocols and routing/switching
policies. The model represents both core/provider and virtual
instances. Network instances reuse and build on
[I-D.ietf-netmod-routing-cfg] and are shown below:
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw type? identityref
+--rw enabled? boolean
+--rw description? string
+--rw network-instance-policy
| ...
+--rw root? schema-mount
| ...
augment /if:interfaces/if:interface:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-network-instance-name? string
A network instance is identified by a `name` string. This string is
used both as an index within the network-instance module and to
associate resources with a network instance as shown above in the
interface augmentation. Type is used to indicate the type NI, such
as L3-VRF, VPLS, L2-VSI, etc. Network instance policy and root are
discussed in greater detail below.
3.1. Network Instance Policy
Network instance policies are used to control how NI information is
represented at the device level, VRF routing policies, and VRF/VSI
identifiers. Examples include BGP route targets (RTs) and route
distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS
neighbors, etc. The structure is expected to be:
Berger, et al. Expires December 25, 2016 [Page 6]
Internet-Draft LNE Model June 2016
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw network-instance-policy
(TBD)
3.2. Network Instance Management
Modules that may be used to represent network instance specific
information will be available under `root`. As with LNEs, actual
module availability is expected to be implementation dependent. The
yang library module [I-D.ietf-netconf-yang-library] is expected to be
the primary method used to identify supported modules. Resource
related control and assignment is expected to be managed at the
network-device level, not the network instance level, based on the
`bind-network-instance-name` augmentation mentioned above.
As an example, consider the case where a network instance with a
`name` of "green" is defined on a network device. In this case the
following structure might be made available:
+--rw yanglib:modules-state [I-D.ietf-netconf-yang-library]
+--rw if:interfaces [RFC7223]
| +--rw bind-network-instance-name="green" string
+--rw network-instances
+--rw network-instance* [name]
+--rw name="green" string
+--rw type? identityref
+--rw enabled=true boolean
+--rw description="The Green VRF" string
+--rw network-instance-policy
| ... (RT=1000:1, RD=1.2.3.4)
+--rw root? schema-mount
+--rw yanglib:modules-state [I-D.ietf-netconf-yang-library]
+--rw if:intefaces [RFC7223]
+--rw mm:network-services
+--rw nn:oam-protocols
+--rw oo:routing
+--rw pp:mpls
All modules that represent control-plane and data-plane information
may be present at the `root`, and be accessible via paths modified
per [I-D.ietf-netmod-schema-mount]. The list of available modules is
expected to be implementation dependent. As is the method used by an
implementation to support NIs.
Berger, et al. Expires December 25, 2016 [Page 7]
6. Security Considerations ........................................16
7. Acknowledgements ...............................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
2. Entity State
The goal in adding state objects to the Entity MIB [RFC4133] is to
define a useful subset of the possible state attributes that could be
tracked for a given entity and that both fit into the state models
such as those used in the Interfaces MIB [RFC2863] as well as
leverage existing well-deployed models. The entStateTable contains
state objects that are a subset of the popular ISO/OSI states that
are also defined in ITU's X.731 specification [X.731]. Objects are
defined to capture administrative, operational, and usage states. In
addition, there are further state objects defined to provide more
information for these three basic states.
Administrative state indicates permission to use or prohibition
against using the entity and is imposed through the management
services.
Operational state indicates whether or not the entity is physically
installed and working. Note that unlike the ifOperStatus [RFC2863],
this operational state is independent of the administrative state.
Usage state indicates whether or not the entity is in use at a
specific instance, and if so, whether or not it currently has spare
capacity to serve additional users. In the context of this MIB, the
usage state refers to the ability of an entity to service other
entities within its containment hierarchy.
Chisholm & Perkins Standards Track [Page 2]
RFC 4268 Entity State MIB November 2005
Alarm state indicates whether or not there are any alarms active
against the entity. In addition to those alarm states defined in
X.731 [X.731], warning and indeterminate status are also defined to
provide a more complete mapping to the Alarm MIB [RFC3877].
Standby state indicates whether the entity is currently running as
hot standby or cold standby or is currently providing service.
The terms "state" and "status" are used interchangeably in this memo.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.1. Hierarchical State Management
Physical entities exist within a containment hierarchy. Physical
containment is defined by the entPhysicalContainedIn object[RFC4133].
This raises some interesting issues not addressed in existing work on
state management.
There are two types of state for an entity:
1) The state of the entity independent of the states of its parents
and children in its containment hierarchy. This is often referred to
as raw state.
2) The state of the entity, as it may be influenced by the state of
its parents and children. This is often referred to as computed
state.
All state objects in this memo are raw state.
2.2. Entity Redundancy
While this memo is not attempting to address the entire problem space
around redundancy, the entStateStandby object provides an important
piece of state information for entities, which helps identify which
pieces of redundant equipment are currently providing service, and
which are waiting in either hot or cold standby mode.
2.3. Physical Entity Users
There are three ways to define the 'user' of a physical entity
1. Direct containment in physical hierarchy
2. Anywhere in physical hierarchy
Chisholm & Perkins Standards Track [Page 3]
RFC 4268 Entity State MIB November 2005
3. As defined by a means outside the scope of this MIB. This could
include logical interfaces that could run on a port, software that
could run on a module, etc.
Administrative, operational, alarm, and standby state use all three
definitions of 'user'. Usage state supports only the concept of
direct containment to simplify implementations of this object.
2.4. Physical Class Behavior
This MIB makes no effort to standardize the behaviors and
characteristics of the various physical classes [RFC4133], but rather
how this information is reported. In looking at real-world products,
items within the same physical class vary substantially. The MIB has
therefore provided guidance on how to support objects where a
particular instance of a physical class cannot support part or all of
a particular state.
3. Relation to Other MIBs
3.1. Relation to the Interfaces MIB
The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which
has states of up, down, and testing, and the ifOperStatus object,
which has states of up, down, testing, unknown, dormant, notPresent,
and lowerLayerDown.
An ifAdminStatus of 'up' is equivalent to setting the entStateAdmin
object to 'unlocked'. An ifAdminStatus of 'down' is equivalent to
setting the entStateAdmin object to either 'locked' or
'shuttingDown', depending on a system's interpretation of 'down'.
An ifOperStatus of 'up' is equivalent to an entStateOper value of
'enabled'. An ifOperStatus of 'down' due to operational failure is
equivalent to an entStateOper value of 'disabled'. An ifOperStatus
of 'down' due to being administratively disabled is equivalent to an
entStateAdmin value of 'locked' and an entStateOper value of either
'enabled' or 'disabled' depending on whether there are any known
issues that would prevent the entity from becoming operational when
its entStateAdmin is set to 'unlocked'. An ifOperStatus of 'unknown'
is equivalent to an entStateOper value of 'unknown'. The
ifOperStatus values of 'testing' and 'dormant' are not explicitly
supported by this MIB, but the state objects will be able to reflect
other aspects of the entities' administrative and operational state.
The ifOperStatus values of 'notPresent' and 'lowerLayerDown&
Internet-Draft LNE Model June 2016
3.3. Network Instance Instantiation
TBD -- need to resolve if instantiation is based on new list entry
creation per the pending Schema Mount solution definition.
4. Security Considerations
LNE portion is TBD
NI portion is TBD
5. IANA Considerations
This YANG model currently uses a temporary ad-hoc namespace. If it
is placed or redirected for the standards track, an appropriate
namespace URI will be registered in the "IETF XML Registry"
[RFC3688]. The YANG structure modules will be registered in the
"YANG Module Names" registry [RFC6020].
6. Network Instance Model
The structure of the model defined in this document is described by
the YANG module below.
<CODE BEGINS> file "ietf-network-instance@2016-06-23.yang"
module ietf-network-instance {
yang-version "1";
// namespace
namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";
prefix "ni";
// import some basic types
import ietf-interfaces {
prefix if;
}
import ietf-ip {
prefix ip;
}
// meta
organization "IETF Routing Area Working Group (rtgwg)";
contact
"Routing Area Working Group - <rtgwg@ietf.org>";
Berger, et al. Expires December 25, 2016 [Page 8]
Internet-Draft LNE Model June 2016
description
"This module is used to support multiple network instances
within a single physical or virtual device. Network
instances are commonly know as VRFs (virtual routing
and forwarding) and VSIs (virtual switching instances).";
revision "2016-06-23" {
description
"Initial revision.";
reference "RFC TBD";
}
// extension statements
feature bind-network-instance-name {
description
"Network Instance to which an interface instance is bound";
}
// identity statements
identity network-instance-type {
description
"Base identity from which identities describing
network instance types are derived.";
}
identity ipv4-interface-protocol-type {
description
"Base identity for derivation of IPv4 interface
protocols";
}
identity ipv6-interface-protocol-type {
description
"Base identity for derivation of IPv6 interface
protocols";
}
// typedef statements
// grouping statements
grouping interface-ip-common {
description
"interface-specific configuration for IP interfaces, IPv4 and
IPv6";
Berger, et al. Expires December 25, 2016 [Page 9]
Internet-Draft LNE Model June 2016
}
grouping ipv4-interface-protocols {
container ipv4-interface-protocols {
list ipv4-interface-protocol {
key "type";
leaf type {
type identityref {
base ipv4-interface-protocol-type;
}
mandatory true;
description
"ARP, ICMP, VRRP, DHCP Client, etc.";
}
description
"List of IPv4 protocols configured
on an interface";
}
description
"Container for list of IPv4 protocols configured
on an interface";
}
description
"Grouping for IPv4 protocols configured on an interface";
}
grouping ipv6-interface-protocols {
description
"Grouping for IPv6 protocols configured on
an interface.";
container ipv6-interface-protocols {
description
"Container for list of IPv6 protocols configured
on an interface.";
list ipv6-interface-protocol {
key "type";
description
"List of IPv6 protocols configured
on an interface";
leaf type {
type identityref {
base ipv6-interface-protocol-type;
}
mandatory true;
description
"ND, ICMPv6, VRRP, DHCPv6 Client, etc.";
}
}
Berger, et al. Expires December 25, 2016 [Page 10]
Internet-Draft LNE Model June 2016#x27; are in
some ways computed states and so are therefore not supported in this
Chisholm & Perkins Standards Track [Page 4]
RFC 4268 Entity State MIB November 2005
MIB. They can, though, be computed by examining the states of
entities within this object's containment hierarchy and other
available related states.
3.2. Relation to Alarm MIB
The entStateAlarm object indicates whether or not there are any
active alarms against this entity. If there are active alarms, then
the alarmActiveTable in the Alarm MIB [RFC3877] should be searched
for rows whose alarmActiveResourceId matches this entPhysicalIndex.
Alternatively, if the alarmActiveTable is queried first and an active
alarm with a value of alarmActiveResourceId that matches this
entPhysicalIndex is found, then entStateAlarm can be used to quickly
determine if there are additional active alarms with a different
severity against this physical entity.
3.3 Relation to Bridge MIB
For entities of physical type of 'port' that support the
dot1dStpPortEnable object in the Bridge MIB [RFC4188], a value of
'enabled' is equivalent to setting the entStateAdmin object to
'unlocked'. Setting dot1dStpPortEnable to 'disabled' is equivalent
to setting the entStateAdmin object to 'locked'.
3.4 Relation to the Host Resources MIB
The hrDeviceStatus object in the Host Resources MIB [RFC2790]
provides an operational state for devices. For entities that
logically correspond to the concept of a device, a value of 'unknown'
for hrDeviceStatus corresponds to an entStateOper value of 'unknown'.
A value of 'running' corresponds to an entStateOper value of
'enabled'. A value of 'warning' also corresponds to an entStateOper
value of 'enabled', but with appropriate bits set in the
entStateAlarm object to indicate the alarms corresponding to the
unusual error condition detected. A value of 'testing' or 'down' is
equivalent to an entStateOper value of 'disabled'.
Chisholm & Perkins Standards Track [Page 5]
RFC 4268 Entity State MIB November 2005
4. Textual Conventions
ENTITY-STATE-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
entityStateTc MODULE-IDENTITY
LAST-UPDATED "200511220000Z"
ORGANIZATION "IETF Entity MIB Working Group"
CONTACT-INFO
"General Discussion: entmib@ietf.org
To Subscribe:
http://www.ietf.org/mailman/listinfo/entmib
http://www.ietf.org/html.charters/entmib-charter.html
Sharon Chisholm
Nortel Networks
PO Box 3511 Station C
Ottawa, Ont. K1Y 4H7
Canada
schishol@nortel.com
David T. Perkins
548 Qualbrook Ct
San Jose, CA 95110
USA
Phone: 408 394-8702
dperkins@snmpinfo.com"
DESCRIPTION
"This MIB defines state textual conventions.
Copyright (C) The Internet Society 2005. This version
of this MIB module is part of RFC 4268; see the RFC
itself for full legal notices."
REVISION "200511220000Z"
DESCRIPTION
"Initial version, published as RFC 4268."
::= { mib-2 130 }
EntityAdminState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
" Represents the various possible administrative states.
Chisholm & Perkins Standards Track [Page 6]
RFC 4268 Entity State MIB November 2005
A value of 'locked' means the resource is administratively
prohibited from use. A value of 'shuttingDown' means that
usage is administratively limited to current instances of
use. A value of 'unlocked' means the resource is not
administratively prohibited from use. A value of
'unknown' means that this resource is unable to
report administrative state."
SYNTAX INTEGER
{
unknown (1),
locked (2),
shuttingDown (3),
unlocked (4)
}
EntityOperState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
" Represents the possible values of operational states.
A value of 'disabled' means the resource is totally
inoperable. A value of 'enabled' means the resource
is partially or fully operable. A value of 'testing'
means the resource is currently being tested
and cannot therefore report whether it is operational
or not. A value of 'unknown' means that this
resource is unable to report operational state."
SYNTAX INTEGER
{
unknown (1),
disabled (2),
enabled (3),
testing (4)
}
EntityUsageState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
" Represents the possible values of usage states.
A value of 'idle' means the resource is servicing no
users. A value of 'active' means the resource is
currently in use and it has sufficient spare capacity
to provide for additional users. A value of 'busy'
means the resource is currently in use, but it
currently has no spare capacity to provide for
additional users. A value of 'unknown' means
that this resource is unable to report usage state."
SYNTAX INTEGER
Chisholm & Perkins Standards Track [Page 7]
RFC 4268 Entity State MIB November 2005
{
unknown (1),
idle (2),
active (3),
busy (4)
}
EntityAlarmStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
" Represents the possible values of alarm status.
An Alarm [RFC3877] is a persistent indication
of an error or warning condition.
When no bits of this attribute are set, then no active
alarms are known against this entity and it is not under
repair.
When the 'value of underRepair' is set, the resource is
currently being repaired, which, depending on the
implementation, may make the other values in this bit
string not meaningful.
When the value of 'critical' is set, one or more critical
alarms are active against the resource. When the value
of 'major' is set, one or more major alarms are active
against the resource. When the value of 'minor' is set,
one or more minor alarms are active against the resource.
When the value of 'warning' is set, one or more warning
alarms are active against the resource. When the value
of 'indeterminate' is set, one or more alarms of whose
perceived severity cannot be determined are active
against this resource.
A value of 'unknown' means that this resource is
unable to report alarm state."
SYNTAX BITS
{
unknown (0),
underRepair (1),
critical(2),
major(3),
minor(4),
-- The following are not defined in X.733
warning (5),
indeterminate (6)
}
Chisholm & Perkins Standards Track [Page 8]
RFC 4268 Entity State MIB November 2005
EntityStandbyStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
" Represents the possible values of standby status.
A value of
}
}
grouping network-instance-policy {
description
"Network instance policies such as route
distinguisher, route targets, VPLS ID and neighbor,
Ethernet ID, etc. ";
reference
"RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs)
RFC 6074 - Provisioning, Auto-Discovery, and Signaling
in Layer 2 Virtual Private Networks (L2VPNs)
RFC 7432 - BGP MPLS-Based Ethernet VPN";
container network-instance-policy {
description "Network Instance Policy -- details TBD";
}
}
// top level device definition statements
container network-instances {
description "Network instances each of which have
an independent IP/IPv6 addressing space
and protocol instantiations. For layer 3,
this consistent with the routing-instance
definition in ietf-routing";
reference "draft-ietf-netmod-routing-cfg";
list network-instance {
key name;
description "List of network-instances";
leaf name {
type string;
description "device scoped
identifier for the network
instance";
}
leaf type {
type identityref {
base network-instance-type;
}
description
"The network instance type -- details TBD
Likely types include core, L3-VRF, VPLS,
L2-cross-connect, L2-VSI, etc.";
}
leaf enabled {
type boolean;
default "true";
description
Berger, et al. Expires December 25, 2016 [Page 11]
Internet-Draft LNE Model June 2016
"Flag indicating whether or not the network
instance is enabled.";
}
leaf description {
type string;
description
"Description of the network instance
and its intended purpose";
}
uses network-instance-policy;
leaf root {
type schema-mount;
description "Root for models supported per
network instance";
}
}
}
// augment statements
augment "/if:interfaces/if:interface" {
description
"Add a node for the identification of the logical network
instance (which is within the interface's identified logical
network element) associated with the IP information
configured on an interface";
leaf bind-network-instance-name {
type string;
description
"Network Instance to which an interface is bound";
}
}
augment "/if:interfaces/if:interface/ip:ipv4" {
description
"Add a node for the identification of the logical
network instance (which is within the interface's
identified physical or virtual device) associated with
the IP information configured on an interface";
leaf bind-network-instance-name {
type string;
description
"Network Instance to which IPv4 interface is bound";
}
}
Berger, et al. Expires December 25, 2016 [Page 12]
Internet-Draft LNE Model June 2016
augment "/if:interfaces/if:interface/ip:ipv6" {
description
"Add a node for the identification of the logical
network instance (which is within the interface's
identified physical or virtual device) associated with
the IP information configured on an interface";
leaf bind-network-instance-name {
type string;
description
"Network Instance to which IPv6 interface is bound";
}
}
// rpc statements
// notification statements
}
<CODE ENDS>
7. References
7.1. Normative References
[I-D.ietf-netmod-schema-mount]
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
ietf-netmod-schema-mount-01 (work in progress), April
2016.
[LNE-MODEL]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
"Logical Network Element Model", draft-ietf-rtgwg-lne-
model-00.txt (work in progress), June 2016.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
Berger, et al. Expires December 25, 2016 [Page 13]
Internet-Draft LNE Model June 2016
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
7.2. Informative References
[I-D.ietf-netconf-yang-library]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", draft-ietf-netconf-yang-library-06 (work in
progress), April 2016.
[I-D.ietf-netmod-opstate-reqs]
Watsen, K. and T. Nadeau, "Terminology and Requirements
for Enhanced Handling of Operational State", draft-ietf-
netmod-opstate-reqs-04 (work in progress), January 2016.
[I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-21 (work in
progress), March 2016.
[I-D.openconfig-netmod-opstate]
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
of Operational State Data in YANG", draft-openconfig-
netmod-opstate-01 (work in progress), July 2015.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<http://www.rfc-editor.org/info/rfc4026>.
[RTG-DEVICE-MODEL]
Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C.
Hopps, "Network Device YANG Organizational Models", draft-
rtgyangdt-rtgwg-device-model-04.txt (work in progress),
May 2016.
Appendix A. Acknowledgments
The Routing Area Yang Architecture design team members included Acee
Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger,
Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang.
The RFC text was produced using Marshall Rose's xml2rfc tool.
Berger, et al. Expires December 25, 2016 [Page 14]
Internet-Draft LNE Model June 2016
Appendix B. Contributors
Contributors' Addresses
TBD
Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Christan Hopps
Deutsche Telekom
Email: chopps@chopps.org
Acee Lindem
Cisco Systems
301 Midenhall Way
Cary, NC 27513
USA
Email: acee@cisco.com
Dean Bogdanovic
Email: ivandean@gmail.com
Berger, et al. Expires December 25, 2016 [Page 15]