draft-ietf-netmod-intf-ext-yang-04.txt   draft-ietf-netmod-intf-ext-yang-05.txt 
Internet Engineering Task Force R. Wilton, Ed. Internet Engineering Task Force R. Wilton, Ed.
Internet-Draft D. Ball Internet-Draft D. Ball
Intended status: Standards Track T. Singh Intended status: Standards Track T. Singh
Expires: September 14, 2017 Cisco Systems Expires: January 4, 2018 Cisco Systems
S. Sivaraj S. Sivaraj
Juniper Networks Juniper Networks
March 13, 2017 July 3, 2017
Common Interface Extension YANG Data Models Common Interface Extension YANG Data Models
draft-ietf-netmod-intf-ext-yang-04 draft-ietf-netmod-intf-ext-yang-05
Abstract Abstract
This document defines two YANG modules that augment the Interfaces This document defines two YANG modules that augment the Interfaces
data model defined in the "YANG Data Model for Interface Management" data model defined in the "YANG Data Model for Interface Management"
with additional configuration and operational data nodes to support with additional configuration and operational data nodes to support
common lower layer interface properties, such as interface MTU. common lower layer interface properties, such as interface MTU.
These properties are common to many types of interfaces on network These properties are common to many types of interfaces on network
routers and switches and are implemented by multiple network routers and switches and are implemented by multiple network
equipment vendors with similar semantics, even though some of the equipment vendors with similar semantics, even though some of the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Interfaces Common Module . . . . . . . . . . . . . . . . . . 4 3. Interfaces Common Module . . . . . . . . . . . . . . . . . . 4
3.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Reservable Bandwidth . . . . . . . . . . . . . . . . . . 6
3.2. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7 3.3.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7
3.3.2. Half-Life Period . . . . . . . . . . . . . . . . . . 8 3.3.2. Half-Life Period . . . . . . . . . . . . . . . . . . 8
3.3.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8 3.3.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8
3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8 3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8
3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9 3.8. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 10
4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 10 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 10
5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 10 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 11
6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 19 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 20
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24
9.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23 9.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.4. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 25 11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document defines two YANG 1.1 [RFC7950] modules for the This document defines two YANG 1.1 [RFC7950] modules for the
management of network interfaces. It defines various augmentations management of network interfaces. It defines various augmentations
to the generic interfaces data model [RFC7223] to support to the generic interfaces data model [RFC7223] to support
configuration of lower layer interface properties that are common configuration of lower layer interface properties that are common
across many types of network interface. across many types of network interface.
One of the aims of this draft is to provide a standard namespace and One of the aims of this draft is to provide a standard namespace and
skipping to change at page 5, line 34 skipping to change at page 5, line 34
o A forwarding mode leaf to indicate the OSI layer at which the o A forwarding mode leaf to indicate the OSI layer at which the
interface handles traffic interface handles traffic
o A parent interface leaf useable for all types of sub-interface o A parent interface leaf useable for all types of sub-interface
that are children of parent interfaces. that are children of parent interfaces.
The "ietf-interfaces-common" YANG module has the following structure: The "ietf-interfaces-common" YANG module has the following structure:
module: ietf-interfaces-common module: ietf-interfaces-common
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw bandwidth? uint64 {bandwidth}? +--rw reservable-bandwidth? uint64 {reservable-bandwidth}?
+--rw carrier-delay {carrier-delay}? +--rw carrier-delay {carrier-delay}?
| +--rw down? uint32 | +--rw down? uint32
| +--rw up? uint32 | +--rw up? uint32
+--rw dampening! {dampening}? +--rw dampening! {dampening}?
| +--rw half-life? uint32 | +--rw half-life? uint32
| +--rw reuse? uint32 | +--rw reuse? uint32
| +--rw suppress? uint32 | +--rw suppress? uint32
| +--rw max-suppress-time? uint32 | +--rw max-suppress-time? uint32
+--rw encapsulation +--rw encapsulation
| +--rw (encaps-type)? | +--rw (encaps-type)?
+--rw loopback? identityref {loopback}? +--rw loopback? identityref {loopback}?
+--rw l2-mtu? uint16 {configurable-l2-mtu}? +--rw l2-mtu? uint16 {configurable-l2-mtu}?
+--rw forwarding-mode? identityref {forwarding-mode}? +--rw forwarding-mode? identityref {forwarding-mode}?
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw parent-interface if:interface-ref {sub-interfaces}? +--rw parent-interface if:interface-ref {sub-interfaces}?
3.1. Bandwidth 3.1. Reservable Bandwidth
The bandwidth configuration leaf allows the specified bandwidth of an
interface to be reduced from the inherent interface bandwidth. The
bandwidth leaf affects the routing metric cost associated with the
interface.
Note that the bandwidth leaf does not actually limit the amount of
traffic that can be sent/received over the interface. If required,
interface traffic can be limited to the required bandwidth by
configuring an explicit QoS policy.
Note for reviewers: Given that the bandwidth only controls routing The reservable-bandwidth configuration leaf allows the bandwidth of
metrics, it may be more appropriate for this leaf, or an equivalent, an interface reported to upper layer protocols to be changed (either
to be defined as part of one of the routing YANG modules. Although higher or lower) from the inherent interface bandwidth. The
conversely, it is also worth considering that the corresponding reservable-bandwidth leaf can affect the routing metric cost
existing CLI configuration command is an interface level bandwidth associated with the interface, but it does not directly limit the
command in many implementations. amount of traffic that can be sent/received over the interface. If
required, interface traffic can be limited to the required bandwidth
by configuring an explicit QoS policy.
3.2. Carrier Delay 3.2. Carrier Delay
The carrier delay feature augments the IETF interfaces data model The carrier delay feature augments the IETF interfaces data model
with configuration for a simple algorithm that is used, generally on with configuration for a simple algorithm that is used, generally on
physical interfaces, to suppress short transient changes in the physical interfaces, to suppress short transient changes in the
interface link state. It can be used in conjunction with the interface link state. It can be used in conjunction with the
dampening feature described in Section 3.3 to provide effective dampening feature described in Section 3.3 to provide effective
control of unstable links and unwanted state transitions. control of unstable links and unwanted state transitions.
skipping to change at page 8, line 36 skipping to change at page 8, line 31
interface can remain dampened when a penalty is assigned to an interface can remain dampened when a penalty is assigned to an
interface. The default of the maximum suppress timer is four times interface. The default of the maximum suppress timer is four times
the half-life period. The maximum value of the accumulated penalty the half-life period. The maximum value of the accumulated penalty
is calculated using the maximum suppress time, reuse threshold and is calculated using the maximum suppress time, reuse threshold and
half-life period. half-life period.
3.4. Encapsulation 3.4. Encapsulation
The encapsulation container holds a choice node that is to be The encapsulation container holds a choice node that is to be
augmented with datalink layer specific encapsulations, such as HDLC, augmented with datalink layer specific encapsulations, such as HDLC,
PPP, or sub-interface 802.1Q tag match encapsulations. It ensures PPP, or sub-interface 802.1Q tag match encapsulations. The use of a
that an interface can only have a single datalink layer protocol choice statement ensures that an interface can only have a single
configured. datalink layer protocol configured.
The different encapsulations themselves are defined in separate YANG
modules defined in other documents that augument the encapsulation
choice statement. For example the Ethernet specific basic 'dot1q-
vlan' encapsulation is defined in ietf-if-l3-vlan.yang and the
'flexible' encapsulation is defined in ietf-flexible-
encapsulation.yang, both modules from
[I-D.ietf-netmod-sub-intf-vlan-model].
3.5. Loopback 3.5. Loopback
The loopback configuration leaf allows any physical interface to be The loopback configuration leaf allows any physical interface to be
configured to be in one of the possible following physical loopback configured to be in one of the possible following physical loopback
modes, i.e. internal loopback, line loopback, or use of an external modes, i.e. internal loopback, line loopback, or use of an external
loopback connector. The use of YANG identities allows for the model loopback connector. The use of YANG identities allows for the model
to be extended with other modes of loopback if required. to be extended with other modes of loopback if required.
3.6. MTU The following loopback modes are defined:
o Internal loopback - All egress traffic on the interface is
internally looped back within the interface to be received on the
ingress path.
o Line loopback - All ingress traffic received on the interface is
internally looped back within the interface to the egress path.
o Loopback Connector - The interface has a physical loopback
connector attached that loops all egress traffic back into the
interface's ingress path, with equivalent semantics to internal
loopback.
3.6. Layer 2 MTU
A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the
maximum size of a layer 2 frame that may be transmitted or received maximum size of a layer 2 frame that may be transmitted or received
on an interface. The layer 2 MTU includes the overhead of the layer on an interface. The layer 2 MTU includes the overhead of the layer
2 header and the maximum length of the payload, but excludes any 2 header and the maximum length of the payload, but excludes any
frame check sequence (FCS) bytes. The payload MTU available to frame check sequence (FCS) bytes. The payload MTU available to
higher layer protocols is calculated from the l2-mtu leaf after higher layer protocols is calculated from the l2-mtu leaf after
taking the layer 2 header size into account. taking the layer 2 header size into account.
For Ethernet interfaces carrying 802.1Q VLAN tagged frames, the For Ethernet interfaces carrying 802.1Q VLAN tagged frames, the
skipping to change at page 9, line 37 skipping to change at page 9, line 49
interface to be processed in the context of a given sub-interface. interface to be processed in the context of a given sub-interface.
All egress traffic processed on a sub-interface is given to the All egress traffic processed on a sub-interface is given to the
parent interface for transmission. Otherwise, a sub-interface is parent interface for transmission. Otherwise, a sub-interface is
like any other interface in /if:interfaces and supports the standard like any other interface in /if:interfaces and supports the standard
interface features and configuration. interface features and configuration.
For some vendor specific interface naming conventions the name of the For some vendor specific interface naming conventions the name of the
child interface is sufficient to determine the parent interface, child interface is sufficient to determine the parent interface,
which implies that the child interface can never be reparented to a which implies that the child interface can never be reparented to a
different parent interface after it has been created without deleting different parent interface after it has been created without deleting
the existing the sub-interface and recreating a new sub-interface. the existing sub-interface and recreating a new sub-interface. Even
Even in this case it is useful to have a well defined leaf to cleanly in this case it is useful to have a well defined leaf to cleanly
identify the parent interface. identify the parent interface.
The model also allows for arbitrarily named sub-interfaces by having The model also allows for arbitrarily named sub-interfaces by having
an explicit parent-interface leaf define the child -> parent an explicit parent-interface leaf define the child -> parent
relationship. In this naming scenario it is also possible for relationship. In this naming scenario it is also possible for
implementations to allow for logical interfaces to be reparented to implementations to allow for logical interfaces to be reparented to
new parent interfaces without needing the sub-interface to be new parent interfaces without needing the sub-interface to be
destroyed and recreated. destroyed and recreated.
3.8. Forwarding Mode 3.8. Forwarding Mode
The forwarding mode leaf provides additional information as to what The forwarding mode leaf provides additional information as to what
mode or layer an interface is logically operating and forwarding mode or layer an interface is logically operating and forwarding
traffic at. The implication of this leaf is that for traffic traffic at. The implication of this leaf is that for traffic
forwarded at a given layer that any headers for lower layers are forwarded at a given layer that any headers for lower layers are
stripped off before the packet is forwarded at the given layer. stripped off before the packet is forwarded at the given layer.
Conversely, on egress any lower layer headers must be added to the Conversely, on egress any lower layer headers must be added to the
packet before it is transmitted out of the interface. packet before it is transmitted out of the interface.
This leaf can also be used as a simple mechanism to determine whether YANG Modules can conditionally use this leaf as a simple mechanism to
particular types of configuration are valid. E.g. a layer 2 QoS determine whether particular types of configuration are valid. YANG
policy could ensure that it is only applied to a interface forwarding modules can write 'must' statements to check whether the forwarding
traffic at layer 2. mode leaf has been configured, and if it is, then validate that the
specified configuration is consistent with any forwarding mode that
has also been configured. E.g., a layer 2 QoS policy YANG module
could ensure that it is only applied to a interface forwarding
traffic at layer 2 by checking whether the forwarding-mode leaf
exists, and if it does then also ensure that it has been set to
'layer-2-forwarding'.
The following forwarding modes are defined:
o Optical Layer - Traffic is being forwarded at the optical layer.
This includes DWDM or OTN based switching.
o Layer 2 - Layer 2 based forwarding, such as Ethernet/VLAN based
switching, or L2VPN services.
o Network Layer - Network layer based forwarding, such as IP, MPLS,
or L3VPNs.
4. Interfaces Ethernet-Like Module 4. Interfaces Ethernet-Like Module
The Interfaces Ethernet-Like Module is a small module that contains The Interfaces Ethernet-Like Module is a small module that contains
all configuration and operational data that is common across all configuration and operational data that is common across
interface types that use Ethernet framing as their datalink layer interface types that use Ethernet framing as their datalink layer
encapsulation. encapsulation.
This module currently contains leaves for the configuration and This module currently contains leaves for the configuration and
reporting of the operational MAC address and the burnt-in MAC address reporting of the operational MAC address and the burnt-in MAC address
(BIA) associated with any interface using Ethernet framing. (BIA) associated with any interface using Ethernet framing.
The "ietf-interfaces-ethernet-like" YANG module has the following The "ietf-interfaces-ethernet-like" YANG module has the following
structure: structure:
module: ietf-interfaces-ethernet-like module: ietf-interfaces-ethernet-like
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw ethernet-like +--rw ethernet-like
+--rw mac-address? yang:mac-address +--rw mac-address? yang:mac-address
augment /if:interfaces-state/if:interface:
+--ro ethernet-like
+--ro mac-address? yang:mac-address
+--ro bia-mac-address? yang:mac-address +--ro bia-mac-address? yang:mac-address
+--ro statistics +--ro statistics
+--ro in-drop-unknown-dest-mac-pkts? yang:counter64 +--ro in-drop-unknown-dest-mac-pkts? yang:counter64
5. Interfaces Common YANG Module 5. Interfaces Common YANG Module
This YANG module augments the interface container defined in RFC 7223 This YANG module augments the interface container defined in RFC 7223
[RFC7223]. [RFC7223].
<CODE BEGINS> file "ietf-interfaces-common@2017-03-13.yang" <CODE BEGINS> file "ietf-interfaces-common@2017-07-03.yang"
module ietf-interfaces-common { module ietf-interfaces-common {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-common"; namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-common";
prefix if-cmn; prefix if-cmn;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
} }
skipping to change at page 11, line 48 skipping to change at page 12, line 29
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of XXX; see the RFC This version of this YANG module is part of XXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision 2017-03-13 { revision 2017-07-03 {
description description
"Initial version"; "Initial version";
reference "Internet draft: draft-ietf-netmod-intf-ext-yang-04"; reference "Internet draft: draft-ietf-netmod-intf-ext-yang-05";
} }
feature bandwidth { feature reservable-bandwidth {
description description
"This feature indicates that the device supports configurable "This feature indicates that the device supports configuring
interface bandwidth."; 'reservable-bandwidth' on interfaces.";
reference "Section 3.1 Bandwidth"; reference "RFC XXX, Section 3.1 Reservable Bandwidth";
} }
feature carrier-delay { feature carrier-delay {
description description
"This feature indicates that configurable interface "This feature indicates that configurable interface
carrier delay is supported, which is a feature is used to carrier delay is supported, which is a feature is used to
limit the propagation of very short interface link state limit the propagation of very short interface link state
flaps."; flaps.";
reference "Section 3.2 Carrier Delay"; reference "RFC XXX, Section 3.2 Carrier Delay";
} }
feature dampening { feature dampening {
description description
"This feature indicates that the device supports interface "This feature indicates that the device supports interface
dampening, which is a feature that is used to limit the dampening, which is a feature that is used to limit the
propagation of interface link state flaps over longer propagation of interface link state flaps over longer
periods"; periods";
reference "Section 3.3 Dampening"; reference "RFC XXX, Section 3.3 Dampening";
} }
feature loopback { feature loopback {
description description
"This feature indicates that configurable interface loopback "This feature indicates that configurable interface loopback
is supported."; is supported.";
reference "Section 3.5 Loopback"; reference "RFC XXX, Section 3.5 Loopback";
} }
feature configurable-l2-mtu { feature configurable-l2-mtu {
description description
"This feature indicates that the device supports configuring "This feature indicates that the device supports configuring
layer 2 MTUs on interfaces. Such MTU configurations include layer 2 MTUs on interfaces. Such MTU configurations include
the layer 2 header overheads (but exclude any FCS overhead). the layer 2 header overheads (but exclude any FCS overhead).
The payload MTU available to higher layer protocols is either The payload MTU available to higher layer protocols is either
derived from the layer 2 MTU, taking into account the size of derived from the layer 2 MTU, taking into account the size of
the layer 2 header, or is further restricted by explicit layer the layer 2 header, or is further restricted by explicit layer
3 or protocol specific MTU configuration."; 3 or protocol specific MTU configuration.";
reference "Section 3.6 MTU"; reference "RFC XXX, Section 3.6 Layer 2 MTU";
} }
feature sub-interfaces { feature sub-interfaces {
description description
"This feature indicates that the device supports the "This feature indicates that the device supports the
instantiation of sub-interfaces. Sub-interfaces are defined instantiation of sub-interfaces. Sub-interfaces are defined
as logical child interfaces that allow features and forwarding as logical child interfaces that allow features and forwarding
decisions to be applied to a subset of the traffic processed decisions to be applied to a subset of the traffic processed
on the specified parent interface."; on the specified parent interface.";
reference "Section 3.7 Sub-interface"; reference "RFC XXX, Section 3.7 Sub-interface";
} }
feature forwarding-mode { feature forwarding-mode {
description description
"This feature indicates that the device supports the "This feature indicates that the device supports the
configurable forwarding mode leaf"; configurable forwarding mode leaf";
reference "Section 3.8 Forwarding Mode"; reference "RFC XXX, Section 3.8 Forwarding Mode";
} }
/* /*
* Define common identities to help allow interface types to be * Define common identities to help allow interface types to be
* assigned properties. * assigned properties.
*/ */
identity sub-interface { identity sub-interface {
description "Base type for generic sub-interfaces. New or custom description
interface types can derive from this type to "Base type for generic sub-interfaces.
inherit generic sub-interface configuration";
New or custom interface types can derive from this type to
inherit generic sub-interface configuration";
reference "RFC XXX, Section 3.7 Sub-interface";
} }
identity ethSubInterface{ identity ethSubInterface{
base ianaift:l2vlan; base ianaift:l2vlan;
base sub-interface; base sub-interface;
description description
"Sub-interface of any interface types that uses Ethernet "This identity represents the child sub-interface of any
framing (with or without 802.1Q tagging)"; interface types that uses Ethernet framing (with or without
802.1Q tagging)";
} }
identity loopback { identity loopback {
description "Base identity for interface loopback options"; description "Base identity for interface loopback options";
reference "RFC XXX, section 3.5";
} }
identity loopback-internal { identity loopback-internal {
base loopback; base loopback;
description description
"All egress traffic on the interface is internally looped back "All egress traffic on the interface is internally looped back
within the interface to be received on the ingress path."; within the interface to be received on the ingress path.";
reference "RFC XXX, section 3.5";
} }
identity loopback-line { identity loopback-line {
base loopback; base loopback;
description description
"All ingress traffic received on the interface is internally "All ingress traffic received on the interface is internally
looped back within the interface to the egress path."; looped back within the interface to the egress path.";
reference "RFC XXX, section 3.5";
} }
identity loopback-connector { identity loopback-connector {
base loopback; base loopback;
description description
"The interface has a physical loopback connector attached to "The interface has a physical loopback connector attached
that loops all egress traffic back into the interface's that loops all egress traffic back into the interface's
ingress path, with equivalent semantics to loopback-internal"; ingress path, with equivalent semantics to loopback-internal";
reference "RFC XXX, section 3.5";
} }
identity forwarding-mode { identity forwarding-mode {
description "Base identity for forwarding-mode options"; description "Base identity for forwarding-mode options.";
reference "RFC XXX, section 3.8";
} }
identity optical-layer { identity optical-layer {
base forwarding-mode; base forwarding-mode;
description description
"Traffic is being forwarded at the optical layer. This "Traffic is being forwarded at the optical layer. This
includes DWDM or OTN based switching"; includes DWDM or OTN based switching.";
reference "RFC XXX, section 3.8";
} }
identity layer-2-forwarding { identity layer-2-forwarding {
base forwarding-mode; base forwarding-mode;
description description
"Layer 2 based forwarding, such as Ethernet/VLAN based "Layer 2 based forwarding, such as Ethernet/VLAN based
switching, or L2VPN services."; switching, or L2VPN services.";
reference "RFC XXX, section 3.8";
} }
identity network-layer { identity network-layer {
base forwarding-mode; base forwarding-mode;
description description
"Network layer based forwarding, such as IP, MPLS, or L3VPNs"; "Network layer based forwarding, such as IP, MPLS, or L3VPNs.";
reference "RFC XXX, section 3.8";
} }
/* /*
* Augments the IETF interfaces model with a leaf to explicitly * Augments the IETF interfaces model with a leaf to explicitly
* specify the bandwidth available on an interface. * specify the bandwidth available on an interface.
*/ */
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
description description
"Augments the IETF interface model with optional common "Augments the IETF interface model with optional common
interface level commands that are not formally covered by any interface level commands that are not formally covered by any
specific standard"; specific standard.";
leaf bandwidth { leaf reservable-bandwidth {
if-feature "bandwidth"; if-feature "reservable-bandwidth";
type uint64; type uint64;
units kbps; units kbps;
description description
"The bandwidth available on the interface in Kb/s. This "The reservable-bandwidth configuration leaf allows the
configuration is used by routing protocols to adjust the bandwidth of an interface reported to upper layer protocols
metrics associated with the interface, but does not limit to be changed (either higher or lower) from the inherent
the amount of traffic that can be sent or received on the interface bandwidth. The reservable-bandwidth leaf can
interface. A separate QoS policy would need to be configured affect the routing metric cost associated with the
to limit the ingress or egress traffic. If not configured, interface, but it does not directly limit the amount of
the default bandwidth is the maximum available bandwidth of traffic that can be sent/received over the interface. If
the underlying interface."; required, interface traffic can be limited to the required
bandwidth by configuring an explicit QoS policy.";
reference "RFC XXX, section 3.1";
} }
/* /*
* Defines standard YANG for the Carrier Delay feature. * Defines standard YANG for the Carrier Delay feature.
*/ */
container carrier-delay { container carrier-delay {
if-feature "carrier-delay"; if-feature "carrier-delay";
description description
"Holds carrier delay related feature configuration"; "Holds carrier delay related feature configuration";
leaf down { leaf down {
skipping to change at page 15, line 36 skipping to change at page 16, line 32
command allows short link flaps to be suppressed. The command allows short link flaps to be suppressed. The
configured value indicates the minimum time interval (in configured value indicates the minimum time interval (in
milliseconds) that the carrier signal must be continuously milliseconds) that the carrier signal must be continuously
down before the interface state is brought down. If not down before the interface state is brought down. If not
configured, the behaviour on loss of carrier signal is configured, the behaviour on loss of carrier signal is
vendor/interface specific, but with the general vendor/interface specific, but with the general
expectation that there should be little or no delay."; expectation that there should be little or no delay.";
} }
leaf up { leaf up {
type uint32; type uint32;
units milliseconds; units milliseconds;
description description
"Defines the minimum time interval (in milliseconds) that "Defines the minimum time interval (in milliseconds) that
the carrier signal must be continuously present and the carrier signal must be continuously present and error
error free before the interface state is allowed to free before the interface state is allowed to transition
transition from down to up. If not configured, the from down to up. If not configured, the behaviour is
behaviour is vendor/interface specific, but with the vendor/interface specific, but with the general
general expectation that sufficient default delay expectation that sufficient default delay should be used
should be used to ensure that the interface is stable to ensure that the interface is stable when enabled before
when enabled before being reported as being up. being reported as being up. Configured values that are
Configured values that are too low for the hardware too low for the hardware capabilties may be rejected.";
capabilties may be rejected.";
} }
reference "RFC XXX, Section 3.2 Carrier Delay";
} }
/* /*
* Augments the IETF interfaces model with a container to hold * Augments the IETF interfaces model with a container to hold
* generic interface dampening * generic interface dampening
*/ */
container dampening { container dampening {
if-feature "dampening"; if-feature "dampening";
presence presence
"Enable interface link flap dampening with default settings "Enable interface link flap dampening with default settings
(that are vendor/device specific)"; (that are vendor/device specific)";
description description
"Interface dampening limits the propagation of interface link "Interface dampening limits the propagation of interface link
state flaps over longer periods"; state flaps over longer periods";
reference "RFC XXX, Section 3.3 Dampening";
leaf half-life { leaf half-life {
type uint32; type uint32;
units seconds; units seconds;
description description
"The Time (in seconds) after which a penalty reaches half "The Time (in seconds) after which a penalty reaches half
its original value. Once the interface has been assigned its original value. Once the interface has been assigned
a penalty, the penalty is decreased by half after the a penalty, the penalty is decreased by half after the
half-life period. For some devices, the allowed values may half-life period. For some devices, the allowed values may
be restricted to particular multiples of seconds. The be restricted to particular multiples of seconds. The
default value is vendor/device specific."; default value is vendor/device specific.";
reference "RFC XXX, Section 3.3.2 Half-Life Period";
} }
leaf reuse { leaf reuse {
type uint32; type uint32;
description description
"Penalty value below which a stable interface is "Penalty value below which a stable interface is
unsuppressed (i.e. brought up) (no units). The default unsuppressed (i.e. brought up) (no units). The default
value is vendor/device specific. The penalty value for a value is vendor/device specific. The penalty value for a
link up->down state change is nominally 1000 units."; link up->down state change is nominally 1000 units.";
reference "RFC XXX, Section 3.3.3 Reuse Threshold";
} }
leaf suppress { leaf suppress {
type uint32; type uint32;
description description
"Limit at which an interface is suppressed (i.e. held down) "Limit at which an interface is suppressed (i.e. held down)
when its penalty exceeds that limit (no units). The value when its penalty exceeds that limit (no units). The value
must be greater than the reuse threshold. The default must be greater than the reuse threshold. The default
value is vendor/device specific. The penalty value for a value is vendor/device specific. The penalty value for a
link up->down state change is nominally 1000 units."; link up->down state change is nominally 1000 units.";
reference "RFC XXX, Section 3.3.1 Suppress Threshold";
} }
leaf max-suppress-time { leaf max-suppress-time {
type uint32; type uint32;
units seconds; units seconds;
description description
"Maximum time (in seconds) that an interface can be "Maximum time (in seconds) that an interface can be
suppressed. This value effectively acts as a ceiling that suppressed. This value effectively acts as a ceiling that
the penalty value cannot exceed. The default value is the penalty value cannot exceed. The default value is
vendor/device specific."; vendor/device specific.";
reference "RFC XXX, Section 3.3.4 Maximum Suppress Time";
} }
} }
/* /*
* Various types of interfaces support a configurable layer 2 * Various types of interfaces support a configurable layer 2
* encapsulation, any that are supported by YANG should be * encapsulation, any that are supported by YANG should be
* listed here. * listed here.
* *
* Different encapsulations can hook into the common encaps-type * Different encapsulations can hook into the common encaps-type
* choice statement. * choice statement.
skipping to change at page 17, line 30 skipping to change at page 18, line 31
derived-from-or-self(../if:type, derived-from-or-self(../if:type,
'ianaift:ieee8023adLag') or 'ianaift:ieee8023adLag') or
derived-from-or-self(../if:type, 'ianaift:pos') or derived-from-or-self(../if:type, 'ianaift:pos') or
derived-from-or-self(../if:type, derived-from-or-self(../if:type,
'ianaift:atmSubInterface') or 'ianaift:atmSubInterface') or
derived-from-or-self(../if:type, 'ethSubInterface')" { derived-from-or-self(../if:type, 'ethSubInterface')" {
description description
"All interface types that can have a configurable L2 "All interface types that can have a configurable L2
encapsulation"; encapsulation";
/*
* TODO - Should we introduce an abstract type to make this
* extensible to new interface types, or vendor
* specific interface types?
*/
} }
description description
"Holds the OSI layer 2 encapsulation associated with an "Holds the OSI layer 2 encapsulation associated with an
interface"; interface";
choice encaps-type { choice encaps-type {
description "Extensible choice of L2 encapsulations"; description
"Extensible choice of layer 2 encapsulations";
reference "RFC XXX, Section 3.4 Encapsulation";
} }
} }
/* /*
* Various types of interfaces support loopback configuration, * Various types of interfaces support loopback configuration,
* any that are supported by YANG should be listed here. * any that are supported by YANG should be listed here.
*/ */
leaf loopback { leaf loopback {
when "derived-from-or-self(../if:type, when "derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or 'ianaift:ethernetCsmacd') or
skipping to change at page 18, line 16 skipping to change at page 19, line 13
derived-from-or-self(../if:type, 'ianaift:atm') or derived-from-or-self(../if:type, 'ianaift:atm') or
derived-from-or-self(../if:type, 'ianaift:otnOtu')" { derived-from-or-self(../if:type, 'ianaift:otnOtu')" {
description description
"All interface types that support loopback configuration."; "All interface types that support loopback configuration.";
} }
if-feature "loopback"; if-feature "loopback";
type identityref { type identityref {
base loopback; base loopback;
} }
description "Enables traffic loopback."; description "Enables traffic loopback.";
reference "RFC XXX, Section 3.5 Loopback";
} }
/* /*
* Many types of interfaces support a configurable layer 2 MTU. * Many types of interfaces support a configurable layer 2 MTU.
*/ */
leaf l2-mtu { leaf l2-mtu {
if-feature "configurable-l2-mtu"; if-feature "configurable-l2-mtu";
type uint16 { type uint16 {
range "64 .. 65535"; range "64 .. 65535";
} }
description description
"The maximum size of layer 2 frames that may be transmitted "The maximum size of layer 2 frames that may be transmitted
or received on the interface (excluding any FCS overhead). or received on the interface (excluding any FCS overhead).
In the case of Ethernet interfaces it also excludes the In the case of Ethernet interfaces it also excludes the
4-8 byte overhead of any known (i.e. explicitly matched by 4-8 byte overhead of any known (i.e. explicitly matched by
a child sub-interface) 801.1Q VLAN tags."; a child sub-interface) 801.1Q VLAN tags.";
reference "RFC XXX, Section 3.6 Layer 2 MTU";
} }
/* /*
* Augments the IETF interfaces model with a leaf that indicates * Augments the IETF interfaces model with a leaf that indicates
* which mode, or layer, is being used to forward the traffic. * which mode, or layer, is being used to forward the traffic.
*/ */
leaf forwarding-mode { leaf forwarding-mode {
if-feature "forwarding-mode"; if-feature "forwarding-mode";
type identityref { type identityref {
base forwarding-mode; base forwarding-mode;
} }
description description
"The forwarding mode that the interface is operating in"; "The forwarding mode that the interface is operating in.";
reference "RFC XXX, Section 3.8 Forwarding Mode";
} }
} }
/* /*
* Add generic support for sub-interfaces. * Add generic support for sub-interfaces.
* *
* This should be extended to cover all interface types that are * This should be extended to cover all interface types that are
* child interfaces of other interfaces. * child interfaces of other interfaces.
*/ */
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
skipping to change at page 19, line 27 skipping to change at page 20, line 28
"Add a parent interface field to interfaces that model "Add a parent interface field to interfaces that model
sub-interfaces"; sub-interfaces";
leaf parent-interface { leaf parent-interface {
type if:interface-ref; type if:interface-ref;
mandatory true; mandatory true;
description description
"This is the reference to the parent interface of this "This is the reference to the parent interface of this
sub-interface."; sub-interface.";
reference "RFC XXX, Section 3.7 Sub-interface";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6. Interfaces Ethernet-Like YANG Module 6. Interfaces Ethernet-Like YANG Module
This YANG module augments the interface container defined in RFC 7223 This YANG module augments the interface container defined in RFC 7223
[RFC7223] for Ethernet-like interfaces. This includes Ethernet [RFC7223] for Ethernet-like interfaces. This includes Ethernet
interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces, interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces,
Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces. Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces.
<CODE BEGINS> file "ietf-interfaces-ethernet-like@2017-03-13.yang" <CODE BEGINS> file "ietf-interfaces-ethernet-like@2017-07-03.yang"
module ietf-interfaces-ethernet-like { module ietf-interfaces-ethernet-like {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like"; "urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like";
prefix ethlike; prefix ethlike;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
} }
skipping to change at page 20, line 51 skipping to change at page 22, line 5
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of XXX; see the RFC This version of this YANG module is part of XXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision 2017-03-13 { revision 2017-07-03 {
description "Updated reference to new internet draft name."; description "Updated to conform to NMDA architecture";
reference reference
"Internet draft: draft-ietf-netmod-intf-ext-yang-04"; "Internet draft: draft-ietf-netmod-intf-ext-yang-05";
} }
/* /*
* Configuration parameters for Ethernet-like interfaces. * Configuration parameters for Ethernet-like interfaces.
*/ */
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
derived-from-or-self(if:type, 'ianaift:l2vlan') or derived-from-or-self(if:type, 'ianaift:l2vlan') or
derived-from-or-self(if:type, 'ianaift:ifPwType')" { derived-from-or-self(if:type, 'ianaift:ifPwType')" {
description "Applies to all Ethernet-like interfaces"; description "Applies to all Ethernet-like interfaces";
} }
skipping to change at page 21, line 18 skipping to change at page 22, line 23
* Configuration parameters for Ethernet-like interfaces. * Configuration parameters for Ethernet-like interfaces.
*/ */
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
derived-from-or-self(if:type, 'ianaift:l2vlan') or derived-from-or-self(if:type, 'ianaift:l2vlan') or
derived-from-or-self(if:type, 'ianaift:ifPwType')" { derived-from-or-self(if:type, 'ianaift:ifPwType')" {
description "Applies to all Ethernet-like interfaces"; description "Applies to all Ethernet-like interfaces";
} }
description description
"Augment the interface model with configuration parameters for "Augment the interface model with parameters for all
all Ethernet-like interfaces"; Ethernet-like interfaces";
container ethernet-like {
description "Contains configuration parameters for interfaces
that use Ethernet framing and expose an Ethernet
MAC layer.";
leaf mac-address {
type yang:mac-address;
description
"The configured MAC address of the interface.";
}
}
}
/*
* Operational state for Ethernet-like interfaces.
*/
augment "/if:interfaces-state/if:interface" {
when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
derived-from-or-self(if:type, 'ianaift:l2vlan') or
derived-from-or-self(if:type, 'ianaift:ifPwType')" {
description "Applies to all Ethernet-like interfaces";
}
description
"Augments the interface model with operational state parameters
for all Ethernet-like interfaces.";
container ethernet-like { container ethernet-like {
description "Contains operational state parameters for description
interfaces that use Ethernet framing and expose an "Contains parameters for interfaces that use Ethernet framing
Ethernet MAC layer."; and expose an Ethernet MAC layer.";
leaf mac-address { leaf mac-address {
type yang:mac-address; type yang:mac-address;
description description
"The operational MAC address of the interface, if "The MAC address of the interface.";
applicable";
} }
leaf bia-mac-address { leaf bia-mac-address {
type yang:mac-address; type yang:mac-address;
config false;
description description
"The 'burnt-in' MAC address. I.e the default MAC address "The 'burnt-in' MAC address. I.e the default MAC address
assigned to the interface if none is explicitly assigned to the interface if no MAC address has been
configured."; explicitly configured on it.";
} }
container statistics { container statistics {
config false;
description description
"Packet statistics that apply to all Ethernet-like "Packet statistics that apply to all Ethernet-like
interfaces"; interfaces";
leaf in-drop-unknown-dest-mac-pkts { leaf in-drop-unknown-dest-mac-pkts {
type yang:counter64; type yang:counter64;
units frames; units frames;
description description
"A count of the number of frames that were well formed, "A count of the number of frames that were well formed,
but otherwise dropped because the destination MAC but otherwise dropped because the destination MAC
address did not pass any ingress destination MAC address address did not pass any ingress destination MAC address
skipping to change at page 23, line 9 skipping to change at page 23, line 33
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. Open Issues 7. Open Issues
Open issues: Open issues:
1. Should the loopback leaf be extended to also cover features such 1. Consider whether to use interface property identities (as per
as dataplane loopback? draft-wilton-netmod-interface-properties).
2. Does loopback need a action statement to allow it to be enabled 2. Provide configuration examples?
in an ephemeral way (specifically lost on reboot)?
3. Should the bandwidth leaf be renamed 'reported-bandwidth'? 3. Provide -state module for Ethernet-like
Should this leaf be defined in a routing YANG module?
8. Acknowledgements 8. Acknowledgements
The authors wish to thank Eric Gray, Ing-Wher Chen, Juergen The authors wish to thank Eric Gray, Ing-Wher Chen, Juergen
Schoenwaelder, Ladislav Lhotka, Mahesh Jethanandani, Michael Zitao, Schoenwaelder, Ladislav Lhotka, Mahesh Jethanandani, Michael Zitao,
Neil Ketley, Qin Wu, William Lupton, and Xufeng Liu for their helpful Neil Ketley, Qin Wu, William Lupton, Xufeng Liu, and Andy Bierman for
comments contributing to this draft. their helpful comments contributing to this draft.
9. ChangeLog 9. ChangeLog
9.1. Version -04 9.1. Version -05
o Incorporate feedback from Andy Bierman
9.2. Version -04
o Incorporate feedback from Lada, some comments left as open issues. o Incorporate feedback from Lada, some comments left as open issues.
9.2. Version -03 9.3. Version -03
o Fixed incorrect module name references, and updated tree output o Fixed incorrect module name references, and updated tree output
9.3. Version -02 9.4. Version -02
o Minor changes only: Fix errors in when statements, use derived- o Minor changes only: Fix errors in when statements, use derived-
from-or-self() for future proofing. from-or-self() for future proofing.
10. IANA Considerations 10. IANA Considerations
This document defines several new YANG module and the authors This document defines several new YANG module and the authors
politely request that IANA assigns unique names to the YANG module politely request that IANA assigns unique names to the YANG module
files contained within this draft, and also appropriate URIs in the files contained within this draft, and also appropriate URIs in the
"IETF XML Registry". "IETF XML Registry".
skipping to change at page 26, line 15 skipping to change at page 27, line 5
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014, RFC 7224, DOI 10.17487/RFC7224, May 2014,
<http://www.rfc-editor.org/info/rfc7224>. <http://www.rfc-editor.org/info/rfc7224>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-netmod-sub-intf-vlan-model]
Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
Sivaraj, "Sub-interface VLAN YANG Data Models", draft-
ietf-netmod-sub-intf-vlan-model-01 (work in progress),
March 2017.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<http://www.rfc-editor.org/info/rfc6242>. <http://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
 End of changes. 81 change blocks. 
159 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/