draft-ietf-netmod-intf-ext-yang-03.txt   draft-ietf-netmod-intf-ext-yang-04.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: April 30, 2017 Cisco Systems Expires: September 14, 2017 Cisco Systems
S. Sivaraj S. Sivaraj
Juniper Networks Juniper Networks
October 27, 2016 March 13, 2017
Common Interface Extension YANG Data Models Common Interface Extension YANG Data Models
draft-ietf-netmod-intf-ext-yang-03 draft-ietf-netmod-intf-ext-yang-04
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 April 30, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Suppress Threshold . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 9 3.3.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8
3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 9 3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8
3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 3.8. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9
4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 11 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 10
5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 11 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 10
6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 20 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document defines two YANG RFC 7950 [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 defined in RFC 7223 [RFC7223] to to the generic interfaces data model [RFC7223] to support
support configuration of lower layer interface properties that are configuration of lower layer interface properties that are common
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
path for these configuration items regardless of the underlying path for these configuration items regardless of the underlying
interface type. For example a standard namespace and path for interface type. For example a standard namespace and path for
configuring or reading the MAC address associated with an interface configuring or reading the MAC address associated with an interface
is provided that can be used for any interface type that uses is provided that can be used for any interface type that uses
Ethernet framing. Ethernet framing.
Several of the augmentations defined here are not backed by any Several of the augmentations defined here are not backed by any
formal standard specification. Instead, they are for features that formal standard specification. Instead, they are for features that
skipping to change at page 4, line 33 skipping to change at page 4, line 33
means a presence container, and "*" denotes a list or leaf-list. means a presence container, and "*" denotes a list or leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
2. Objectives 2. Objectives
The aim of of the YANG modules contained in this draft is to provide The aim of the YANG modules contained in this draft is to provide
standard definitions for common interface based configuration on standard definitions for common interface based configuration on
network devices. network devices.
The expectation is that the YANG leaves that are being defined are The expectation is that the YANG leaves that are being defined are
fairly widely implemented by network vendors. However, the features fairly widely implemented by network vendors. However, the features
described here are mostly not backed by formal standards because they described here are mostly not backed by formal standards because they
are fairly basic in their behavior and do not need to interoperate are fairly basic in their behavior and do not need to interoperate
with other devices. Where required a concise explanation of the with other devices. Where required a concise explanation of the
expected behavior is also provided to ensure consistency between expected behavior is also provided to ensure consistency between
vendors. vendors.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
o An encapsulation container and extensible choice statement for use o An encapsulation container and extensible choice statement for use
by any interface types that allow for configurable L2 by any interface types that allow for configurable L2
encapsulations. encapsulations.
o A loopback configuration leaf that is primarily aimed at loopback o A loopback configuration leaf that is primarily aimed at loopback
at the physical layer. at the physical layer.
o MTU configuration leaves applicable to all packet/frame based o MTU configuration leaves applicable to all packet/frame based
interfaces. interfaces.
o A transport layer leaf to indicate whether the interface handles o A forwarding mode leaf to indicate the OSI layer at which the
traffic at L1, L2 or L3. 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 bandwidth? uint64 {bandwidth}?
augment /if:interfaces/if:interface:
+--rw carrier-delay {carrier-delay}? +--rw carrier-delay {carrier-delay}?
+--rw down? uint32 | +--rw down? uint32
+--rw up? uint32 | +--rw up? uint32
augment /if:interfaces/if:interface:
+--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
augment /if:interfaces/if:interface:
+--rw encapsulation +--rw encapsulation
+--rw (encaps-type)? | +--rw (encaps-type)?
augment /if:interfaces/if:interface: +--rw loopback? identityref {loopback}?
+--rw loopback? identityref {loopback}? +--rw l2-mtu? uint16 {configurable-l2-mtu}?
augment /if:interfaces/if:interface: +--rw forwarding-mode? identityref {forwarding-mode}?
+--rw l2-mtu? uint16 {configurable-l2-mtu}?
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}?
augment /if:interfaces/if:interface:
+--rw transport-layer? enumeration {transport-layer}?
3.1. Bandwidth 3.1. Bandwidth
The bandwidth configuration leaf allows the specified bandwidth of an The bandwidth configuration leaf allows the specified bandwidth of an
interface to be reduced from the inherent interface bandwidth. The interface to be reduced from the inherent interface bandwidth. The
bandwidth leaf affects the routing metric cost associated with the bandwidth leaf affects the routing metric cost associated with the
interface. interface.
Note that the bandwidth leaf does not actually limit the amount of Note that the bandwidth leaf does not actually limit the amount of
traffic that can be sent/received over the interface. If required, traffic that can be sent/received over the interface. If required,
skipping to change at page 9, line 39 skipping to change at page 9, line 7
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 3.6. MTU
Two MTU configuration leaves are provided to program the layer 2 A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the
interface in two different ways. Different mechanisms are provided maximum size of a layer 2 frame that may be transmitted or received
to reflect the fact that devices handle their MTU configuration in on an interface. The layer 2 MTU includes the overhead of the layer
different ways. A given device would only normally be expected to 2 header and the maximum length of the payload, but excludes any
support MTU configuration using one of these mechanisms. frame check sequence (FCS) bytes. The payload MTU available to
higher layer protocols is calculated from the l2-mtu leaf after
The preferable way to configure MTU is using the l2-mtu leaf that taking the layer 2 header size into account.
specifies the maximum size of a layer 2 frame including header and
payload, but excluding any frame check sequence (FCS) bytes. The
payload MTU available to higher layer protocols is calculated from
the l2-mtu after 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
l2-mtu excludes the 4-8 byte overhead of any known (e.g. explicitly l2-mtu excludes the 4-8 byte overhead of any known (e.g. explicitly
matched by a child sub-interface) 801.1Q VLAN tags. matched by a child sub-interface) 801.1Q VLAN tags.
The alternative way to configure MTU is using the l3-mtu leaf that
specifies the maximum size of payload carried by a layer 2 frame.
The maximum size of the layer 2 frame can then be derived by adding
on the size of the layer 2 header overheads.
Note for reviewers: Is it correct/beneficial to support l3-mtu? It
would be easier for clients if they only had a single MTU that they
could configure. Can all devices sensibly handle an l2-mtu
configuration leaf?
3.7. Sub-interface 3.7. Sub-interface
The sub-interface feature specifies the minimal leaves required to The sub-interface feature specifies the minimal leaves required to
define a child interface that is parented to another interface. define a child interface that is parented to another interface.
A sub-interface is a logical interface that handles a subset of the A sub-interface is a logical interface that handles a subset of the
traffic on the parent interface. Separate configuration leaves are traffic on the parent interface. Separate configuration leaves are
used to classify the subset of ingress traffic received on the parent used to classify the subset of ingress traffic received on the parent
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
skipping to change at page 10, line 48 skipping to change at page 9, line 48
Even in this case it is useful to have a well defined leaf to cleanly Even 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. Transport Layer 3.8. Forwarding Mode
The transport layer leaf provides additional information as to which The forwarding mode leaf provides additional information as to what
layer an interface is logically operating and forwarding traffic at. mode or layer an interface is logically operating and forwarding
The implication of this leaf is that for traffic forwarded at a given traffic at. The implication of this leaf is that for traffic
layer that any headers for lower layers are stripped off before the forwarded at a given layer that any headers for lower layers are
packet is forwarded at the given layer. Conversely, on egress any stripped off before the packet is forwarded at the given layer.
lower layer headers must be added to the packet before it is Conversely, on egress any lower layer headers must be added to the
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 This leaf can also be used as a simple mechanism to determine whether
particular types of configuration are valid. E.g. a layer 2 QoS particular types of configuration are valid. E.g. a layer 2 QoS
policy could ensure that it is only applied to a interface running at policy could ensure that it is only applied to a interface forwarding
transport layer 2. traffic at layer 2.
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
skipping to change at page 11, line 36 skipping to change at page 10, line 36
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: augment /if:interfaces-state/if:interface:
+--ro ethernet-like +--ro ethernet-like
+--ro mac-address? yang:mac-address +--ro mac-address? yang:mac-address
+--ro bia-mac-address? yang:mac-address +--ro bia-mac-address? yang:mac-address
+--ro statistics
+--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@2016-10-27.yang" <CODE BEGINS> file "ietf-interfaces-common@2017-03-13.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;
} }
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
skipping to change at page 12, line 32 skipping to change at page 11, line 35
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Editor: Robert Wilton Editor: Robert Wilton
<mailto:rwilton@cisco.com>"; <mailto:rwilton@cisco.com>";
description description
"This module contains common definitions for extending the IETF "This module contains common definitions for extending the IETF
interface YANG model (RFC 7223) with common configurable layer 2 interface YANG model (RFC 7223) with common configurable layer 2
properties. properties.
Copyright (c) 2016 IETF Trust and the persons identified as Copyright (c) 2016, 2017 IETF Trust and the persons identified
authors of the code. All rights reserved. as authors of the code. All rights reserved.
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 2016-10-27 { revision 2017-03-13 {
description description
"Initial version"; "Initial version";
reference "Internet draft: draft-ietf-netmod-intf-ext-yang-03"; reference "Internet draft: draft-ietf-netmod-intf-ext-yang-04";
} }
feature bandwidth { feature bandwidth {
description description
"This feature indicates that the device supports configurable "This feature indicates that the device supports configurable
interface bandwidth."; interface bandwidth.";
reference "Section 3.1 Bandwidth"; reference "Section 3.1 Bandwidth";
} }
feature carrier-delay { feature carrier-delay {
skipping to change at page 14, line 9 skipping to change at page 13, line 13
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 "Section 3.7 Sub-interface";
} }
feature transport-layer { feature forwarding-mode {
description description
"This feature indicates that the device supports configurable "This feature indicates that the device supports the
transport layer."; configurable forwarding mode leaf";
reference "Section 3.8 Transport Layer"; reference "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 "Base type for generic sub-interfaces. New or custom
interface types can derive from this type to interface types can derive from this type to
inherit generic sub-interface configuration"; inherit generic sub-interface configuration";
} }
identity ethSubInterface{ identity ethSubInterface{
base ianaift:l2vlan; base ianaift:l2vlan;
base sub-interface; base sub-interface;
description "Sub-interface of any interface types that uses description
Ethernet framing (with or without 802.1Q tagging)"; "Sub-interface of any interface types that uses Ethernet
framing (with or without 802.1Q tagging)";
} }
identity loopback { identity loopback {
description "Base type for interface loopback options"; description "Base identity for interface loopback options";
} }
identity loopback-internal { identity loopback-internal {
base loopback; base loopback;
description "All egress traffic on the interface is internally description
looped back within the interface to be received on "All egress traffic on the interface is internally looped back
the ingress path."; within the interface to be received on the ingress path.";
} }
identity loopback-line { identity loopback-line {
base loopback; base loopback;
description "All ingress traffic received on the interface is description
internally looped back within the interface to the "All ingress traffic received on the interface is internally
egress path."; looped back within the interface to the egress path.";
} }
identity loopback-connector { identity loopback-connector {
base loopback; base loopback;
description "The interface has a physical loopback connector description
attached to that loops all egress traffic back into "The interface has a physical loopback connector attached to
the interface's ingress path, with equivalent that loops all egress traffic back into the interface's
semantics to loopback-internal"; ingress path, with equivalent semantics to loopback-internal";
}
identity forwarding-mode {
description "Base identity for forwarding-mode options";
}
identity optical-layer {
base forwarding-mode;
description
"Traffic is being forwarded at the optical layer. This
includes DWDM or OTN based switching";
}
identity layer-2-forwarding {
base forwarding-mode;
description
"Layer 2 based forwarding, such as Ethernet/VLAN based
switching, or L2VPN services.";
}
identity network-layer {
base forwarding-mode;
description
"Network layer based forwarding, such as IP, MPLS, or L3VPNs";
} }
/* /*
* 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" {
if-feature "bandwidth"; description
"Augments the IETF interface model with optional common
interface level commands that are not formally covered by any
specific standard";
description "Add a top level node for interface bandwidth.";
leaf bandwidth { leaf bandwidth {
if-feature "bandwidth";
type uint64; type uint64;
units kbps; units kbps;
description description
"The bandwidth available on the interface in Kb/s. This "The bandwidth available on the interface in Kb/s. This
configuration is used by routing protocols to adjust the configuration is used by routing protocols to adjust the
metrics associated with the interface, but does not limit metrics associated with the interface, but does not limit
the amount of traffic that can be sent or received on the the amount of traffic that can be sent or received on the
interface. A separate QoS policy would need to be configured interface. A separate QoS policy would need to be configured
to limit the ingress or egress traffic. If not configured, to limit the ingress or egress traffic. If not configured,
the default bandwidth is the maximum available bandwidth of the default bandwidth is the maximum available bandwidth of
the underlying interface."; the underlying interface.";
} }
}
/* /*
* Defines standard YANG for the Carrier Delay feature. * Defines standard YANG for the Carrier Delay feature.
*/ */
augment "/if:interfaces/if:interface" {
if-feature "carrier-delay";
description "Augments the IETF interface model with
carrier delay configuration for interfaces that
support it.";
container carrier-delay { container carrier-delay {
description "Holds carrier delay related feature if-feature "carrier-delay";
configuration"; description
"Holds carrier delay related feature configuration";
leaf down { leaf down {
type uint32; type uint32;
units milliseconds; units milliseconds;
description description
"Delays the propagation of a 'loss of carrier signal' event "Delays the propagation of a 'loss of carrier signal' event
that would cause the interface state to go down, i.e. the that would cause the interface state to go down, i.e. the
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
skipping to change at page 16, line 25 skipping to change at page 15, line 50
error free before the interface state is allowed to error free before the interface state is allowed to
transition from down to up. If not configured, the transition from down to up. If not configured, the
behaviour is vendor/interface specific, but with the behaviour is vendor/interface specific, but with the
general expectation that sufficient default delay general expectation that sufficient default delay
should be used to ensure that the interface is stable should be used to ensure that the interface is stable
when enabled before being reported as being up. when enabled before being reported as being up.
Configured values that are too low for the hardware Configured values that are too low for the hardware
capabilties may be rejected."; capabilties may be rejected.";
} }
} }
}
/*
* Augments the IETF interfaces model with a container to hold
* generic interface dampening
*/
augment "/if:interfaces/if:interface" {
if-feature "dampening";
description
"Add a container for interface dampening configuration";
/*
* Augments the IETF interfaces model with a container to hold
* generic interface dampening
*/
container dampening { container dampening {
presence "Enable interface link flap dampening with default if-feature "dampening";
settings (that are vendor/device specific)"; presence
description "Interface dampening limits the propagation of "Enable interface link flap dampening with default settings
interface link state flaps over longer periods"; (that are vendor/device specific)";
description
"Interface dampening limits the propagation of interface link
state flaps over longer periods";
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.";
skipping to change at page 17, line 33 skipping to change at page 17, line 7
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.";
} }
} }
}
/* /*
* 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.
*/ */
augment "/if:interfaces/if:interface" { container encapsulation {
when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or when
derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or "derived-from-or-self(../if:type,
derived-from-or-self(if:type, 'ianaift:pos') or 'ianaift:ethernetCsmacd') or
derived-from-or-self(if:type, 'ianaift:atmSubInterface') or derived-from-or-self(../if:type,
derived-from-or-self(if:type, 'ethSubInterface')" { 'ianaift:ieee8023adLag') or
description "All interface types that can have a configurable derived-from-or-self(../if:type, 'ianaift:pos') or
L2 encapsulation"; derived-from-or-self(../if:type,
/* 'ianaift:atmSubInterface') or
* TODO - Should we introduce an abstract type to make this derived-from-or-self(../if:type, 'ethSubInterface')" {
* extensible to new interface types, or vendor specific
* interface types?
*/
}
description "Add encapsulation top level node to interface types description
that support a configurable L2 encapsulation"; "All interface types that can have a configurable L2
encapsulation";
/*
* TODO - Should we introduce an abstract type to make this
* extensible to new interface types, or vendor
* specific interface types?
*/
}
container encapsulation {
description description
"Holds the L2 encapsulation associated with an interface"; "Holds the OSI layer 2 encapsulation associated with an
interface";
choice encaps-type { choice encaps-type {
description "Extensible choice of L2 encapsulations"; description "Extensible choice of L2 encapsulations";
} }
} }
}
/*
* Various types of interfaces support loopback configuration, any
* that are supported by YANG should be listed here.
*/
augment "/if:interfaces/if:interface" {
when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
derived-from-or-self(if:type, 'ianaift:sonet') or
derived-from-or-self(if:type, 'ianaift:atm') or
derived-from-or-self(if:type, 'ianaift:otnOtu')" {
description
"All interface types that support loopback configuration.";
}
if-feature "loopback";
description "Augments the IETF interface model with loopback
configuration for interfaces that support it.";
/*
* Various types of interfaces support loopback configuration,
* any that are supported by YANG should be listed here.
*/
leaf loopback { leaf loopback {
when "derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or
derived-from-or-self(../if:type, 'ianaift:sonet') or
derived-from-or-self(../if:type, 'ianaift:atm') or
derived-from-or-self(../if:type, 'ianaift:otnOtu')" {
description
"All interface types that support loopback configuration.";
}
if-feature "loopback";
type identityref { type identityref {
base loopback; base loopback;
} }
description "Enables traffic loopback."; description "Enables traffic loopback.";
} }
}
/*
* Many types of interfaces support a configurable layer 2 MTU.
*/
augment "/if:interfaces/if:interface" {
description "Add configurable layer 2 MTU to all appropriate
interface types.";
/*
* 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.";
} }
/*
* Augments the IETF interfaces model with a leaf that indicates
* which mode, or layer, is being used to forward the traffic.
*/
leaf forwarding-mode {
if-feature "forwarding-mode";
type identityref {
base forwarding-mode;
}
description
"The forwarding mode that the interface is operating in";
}
} }
/* /*
* 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" {
when "derived-from(if:type, 'sub-interface') or when "derived-from(if:type, 'sub-interface') or
derived-from-or-self(if:type, 'ianaift:atmSubInterface') or derived-from-or-self(if:type, 'ianaift:atmSubInterface') or
derived-from-or-self(if:type, 'ianaift:frameRelay')" { derived-from-or-self(if:type, 'ianaift:frameRelay')" {
description description
"Any ianaift:types that explicitly represent sub-interfaces "Any ianaift:types that explicitly represent sub-interfaces
or any types that derive from the sub-interface identity"; or any types that derive from the sub-interface identity";
} }
if-feature "sub-interfaces"; if-feature "sub-interfaces";
description "Add a parent interface field to interfaces that
model sub-interfaces"; description
"Add a parent interface field to interfaces that model
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.";
} }
} }
/*
* Augments the IETF interfaces model with a leaf that indicates
* which layer traffic is to be transported at.
*/
augment "/if:interfaces/if:interface" {
if-feature "transport-layer";
description "Add a top level node to appropriate interfaces to
indicate which tranport layer an interface is
operating at";
leaf transport-layer {
type enumeration {
enum layer-1 {
value 1;
description "Layer 1 transport.";
}
enum layer-2 {
value 2;
description "Layer 2 transport";
}
enum layer-3 {
value 3;
description "Layer 3 transport";
}
}
default layer-3;
description
"The transport layer at which the interface is operating at";
}
}
} }
<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@2016-10-27.yang" <CODE BEGINS> file "ietf-interfaces-ethernet-like@2017-03-13.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;
skipping to change at page 21, line 47 skipping to change at page 20, line 51
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 2016-10-27 { revision 2017-03-13 {
description "Updated reference to new internet draft name."; description "Updated reference to new internet draft name.";
reference reference
"Internet draft: draft-ietf-netmod-intf-ext-yang-03"; "Internet draft: draft-ietf-netmod-intf-ext-yang-04";
} }
/* /*
* 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 23, line 4 skipping to change at page 22, line 7
for all Ethernet-like interfaces."; for all Ethernet-like interfaces.";
container ethernet-like { container ethernet-like {
description "Contains operational state parameters for description "Contains operational state parameters for
interfaces that use Ethernet framing and expose an interfaces that use Ethernet framing and expose an
Ethernet MAC layer."; 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 operational MAC address of the interface, if
applicable"; applicable";
} }
leaf bia-mac-address { leaf bia-mac-address {
type yang:mac-address; type yang:mac-address;
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 none is explicitly
configured."; configured.";
} }
container statistics {
description
"Packet statistics that apply to all Ethernet-like
interfaces";
leaf in-drop-unknown-dest-mac-pkts {
type yang:counter64;
units frames;
description
"A count of the number of frames that were well formed,
but otherwise dropped because the destination MAC
address did not pass any ingress destination MAC address
filter.
For consistency, frames counted against this drop
counters are also counted against the IETF interfaces
statistics. In particular, they are included in
in-octets and in-discards, but are not included in
in-unicast-pkts, in-multicast-pkts or in-broadcast-pkts,
because they are not delivered to a higher layer.
Discontinuities in the values of this counters in this
container can occur at re-initialization of the
management system, and at other times as indicated by
the value of the 'discontinuity-time' leaf defined in
the ietf-interfaces YANG module (RFC 7223).";
}
}
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. Acknowledgements 7. Open Issues
Open issues:
1. Should the loopback leaf be extended to also cover features such
as dataplane loopback?
2. Does loopback need a action statement to allow it to be enabled
in an ephemeral way (specifically lost on reboot)?
3. Should the bandwidth leaf be renamed 'reported-bandwidth'?
Should this leaf be defined in a routing YANG module?
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, Mahesh Jethanandani, Michael Zitao, Neil Ketley, Qin Schoenwaelder, Ladislav Lhotka, Mahesh Jethanandani, Michael Zitao,
Wu, William Lupton, and Xufeng Liu for their helpful comments Neil Ketley, Qin Wu, William Lupton, and Xufeng Liu for their helpful
contributing to this draft. comments contributing to this draft.
8. ChangeLog 9. ChangeLog
8.1. Version -03 9.1. Version -04
o Incorporate feedback from Lada, some comments left as open issues.
9.2. Version -03
o Fixed incorrect module name references, and updated tree output o Fixed incorrect module name references, and updated tree output
8.2. Version -02 9.3. 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.
9. 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".
10. Security Considerations 11. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is
the secure transport layer and the mandatory to implement secure the secure transport layer and the mandatory to implement secure
transport is SSH RFC 6242 [RFC6242]. The NETCONF access control transport is SSH RFC 6242 [RFC6242]. The NETCONF access control
model RFC 6536 [RFC6536] provides the means to restrict access for model RFC 6536 [RFC6536] provides the means to restrict access for
particular NETCONF users to a pre-configured subset of all available particular NETCONF users to a pre-configured subset of all available
NETCONF protocol operations and content. NETCONF protocol operations and content.
There are a number of data nodes defined in this YANG module which There are a number of data nodes defined in this YANG module which
are writable/creatable/deletable (i.e. config true, which is the are writable/creatable/deletable (i.e. config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g. edit-config) to in some network environments. Write operations (e.g. edit-config) to
these data nodes without proper protection can have a negative effect these data nodes without proper protection can have a negative effect
on network operations. These are the subtrees and data nodes and on network operations. These are the subtrees and data nodes and
their sensitivity/vulnerability: their sensitivity/vulnerability:
10.1. interfaces-common.yang 11.1. interfaces-common.yang
The interfaces-common YANG module contains various configuration The interfaces-common YANG module contains various configuration
leaves that affect the behavior of interfaces. Modifying these leaves that affect the behavior of interfaces. Modifying these
leaves can cause an interface to go down, or become unreliable, or to leaves can cause an interface to go down, or become unreliable, or to
drop traffic forwarded over it. More specific details of the drop traffic forwarded over it. More specific details of the
possible failure modes are given below. possible failure modes are given below.
The following leaf could cause the interface to go down, and stop The following leaf could cause the interface to go down, and stop
processing any ingress or egress traffic on the interface: processing any ingress or egress traffic on the interface:
skipping to change at page 24, line 48 skipping to change at page 25, line 4
o /if:interfaces/if:interface/carrier-delay/down o /if:interfaces/if:interface/carrier-delay/down
o /if:interfaces/if:interface/carrier-delay/up o /if:interfaces/if:interface/carrier-delay/up
o /if:interfaces/if:interface/dampening/half-life o /if:interfaces/if:interface/dampening/half-life
o /if:interfaces/if:interface/dampening/reuse o /if:interfaces/if:interface/dampening/reuse
o /if:interfaces/if:interface/dampening/suppress o /if:interfaces/if:interface/dampening/suppress
o /if:interfaces/if:interface/dampening/max-suppress-time o /if:interfaces/if:interface/dampening/max-suppress-time
The following leaves could cause traffic loss on the interface The following leaves could cause traffic loss on the interface
because the received or transmitted frames do not comply with the because the received or transmitted frames do not comply with the
frame matching criteria on the interface and hence would be dropped: frame matching criteria on the interface and hence would be dropped:
o /if:interfaces/if:interface/encapsulation o /if:interfaces/if:interface/encapsulation
o /if:interfaces/if:interface/l2-mtu o /if:interfaces/if:interface/l2-mtu
o /if:interfaces/if:interface/l3-mtu o /if:interfaces/if:interface/forwarding-mode
o /if:interfaces/if:interface/transport-layer
Normally devices will not allow the parent-interface leaf to be Normally devices will not allow the parent-interface leaf to be
changed after the interfce has been created. If an implementation changed after the interfce has been created. If an implementation
did allow the parent-interface leaf to be changed then it could cause did allow the parent-interface leaf to be changed then it could cause
all traffic on the affected interface to be dropped. The affected all traffic on the affected interface to be dropped. The affected
leaf is: leaf is:
o /if:interfaces/if:interface/parent-interface o /if:interfaces/if:interface/parent-interface
10.2. interfaces-ethernet-like.yang 11.2. interfaces-ethernet-like.yang
Generally, the configuration nodes in the interfaces-ethernet-like Generally, the configuration nodes in the interfaces-ethernet-like
YANG module are concerned with configuration that is common across YANG module are concerned with configuration that is common across
all types of Ethernet-like interfaces. Currently, the module only all types of Ethernet-like interfaces. Currently, the module only
contains a node for configuring the operational MAC address to use on contains a node for configuring the operational MAC address to use on
an interface. Adding/modifying/deleting this leaf has the potential an interface. Adding/modifying/deleting this leaf has the potential
risk of causing protocol instability, excessive protocol traffic, and risk of causing protocol instability, excessive protocol traffic, and
general traffic loss, particularly if the configuration change caused general traffic loss, particularly if the configuration change caused
a duplicate MAC address to be present on the local network . The a duplicate MAC address to be present on the local network . The
following leaf is affected: following leaf is affected:
o interfaces/interface/ethernet-like/mac-address o interfaces/interface/ethernet-like/mac-address
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <http://www.rfc-editor.org/info/rfc7223>.
[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>.
11.2. Informative References 12.2. Informative References
[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>.
 End of changes. 80 change blocks. 
242 lines changed or deleted 262 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/