draft-ietf-netmod-intf-ext-yang-06.txt   draft-ietf-netmod-intf-ext-yang-07.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: January 3, 2019 Cisco Systems Expires: September 6, 2019 Cisco Systems
S. Sivaraj S. Sivaraj
Juniper Networks Juniper Networks
July 2, 2018 March 5, 2019
Common Interface Extension YANG Data Models Common Interface Extension YANG Data Models
draft-ietf-netmod-intf-ext-yang-06 draft-ietf-netmod-intf-ext-yang-07
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
routers and switches and are implemented by multiple network The YANG data model in this document conforms to the Network
equipment vendors with similar semantics, even though some of the Management Datastore Architecture (NMDA) defined in RFC 8342.
features are not formally defined in any published standard.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 3, 2019. This Internet-Draft will expire on September 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 8 3.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7
3.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 8 3.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7
3.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8 3.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7
3.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8 3.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7
3.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 10 3.7. 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 . . . . . . . . . . . . 22 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 21
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Carrier delay configuration . . . . . . . . . . . . . . . 25 7.1. Carrier delay configuration . . . . . . . . . . . . . . . 24
7.2. Dampening configuration . . . . . . . . . . . . . . . . . 26 7.2. Dampening configuration . . . . . . . . . . . . . . . . . 25
7.3. MAC address configuration . . . . . . . . . . . . . . . . 27 7.3. MAC address configuration . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 29 9.2. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 28
9.3. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 28
9.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 29 9.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 28
9.5. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 29 9.5. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9.6. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 31 11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document defines two NMDA compatible [RFC8342] YANG 1.1 This document defines two NMDA compatible [RFC8342] YANG 1.1
[RFC7950] modules for the management of network interfaces. It [RFC7950] modules for the management of network interfaces. It
defines various augmentations to the generic interfaces data model defines various augmentations to the generic interfaces data model
[RFC8343] to support configuration of lower layer interface [RFC8343] to support configuration of lower layer interface
properties that are common across many types of network interface. properties that are common 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 4, line 15 skipping to change at page 4, line 15
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
1.2. Tree Diagrams 1.2. Tree Diagrams
A simplified graphical representation of the data model is used in Tree diagrams used in this document follow the notation defined in
this document. The meaning of the symbols in these diagrams is as [RFC8340].
follows:
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" means state data (read-only).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list or leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
2. Objectives 2. Objectives
The aim 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
skipping to change at page 6, line 39 skipping to change at page 5, line 48
3.1. Carrier Delay 3.1. 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.2 to provide effective dampening feature described in Section 3.2 to provide effective
control of unstable links and unwanted state transitions. control of unstable links and unwanted state transitions.
The principal of the carrier delay feature is to use a short per The principle of the carrier delay feature is to use a short per
interface timer to ensure that any interface link state transition interface timer to ensure that any interface link state transition
that occurs and reverts back within the specified time interval is that occurs and reverts back within the specified time interval is
entirely suppressed without providing any signalling to any upper entirely suppressed without providing any signalling to any upper
layer protocols that the state transition has occurred. E.g. in the layer protocols that the state transition has occurred. E.g. in the
case that the link state transition is suppressed then there is no case that the link state transition is suppressed then there is no
change of the /if:interfaces-state/if:interface/oper-status or change of the /if:interfaces-state/if:interface/oper-status or
/if:interfaces-state/if:interfaces/last-change leaves for the /if:interfaces-state/if:interfaces/last-change leaves for the
interface that the feature is operating on. One obvious side effect interface that the feature is operating on. One obvious side effect
of using this feature that is worth noting is that any state of using this feature that is that any state transition will always
transition will always be delayed by the specified time interval. be delayed by the specified time interval.
The configuration allows for separate timer values to be used in the The configuration allows for separate timer values to be used in the
suppression of down->up->down link transitions vs up->down->up link suppression of down->up->down link transitions vs up->down->up link
transitions. transitions.
The carrier delay down timer leaf specifies the amount of time that The carrier delay down timer leaf specifies the amount of time that
an interface that is currently in link up state must be continuously an interface that is currently in link up state must be continuously
down before the down state change is reported to higher level down before the down state change is reported to higher level
protocols. Use of this timer can cause traffic to be black holed for protocols. Use of this timer can cause traffic to be black holed for
the configured value and delay reconvergence after link failures, the configured value and delay reconvergence after link failures,
skipping to change at page 9, line 42 skipping to change at page 9, line 7
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
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) 802.1Q VLAN tags.
3.6. Sub-interface 3.6. 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.
skipping to change at page 11, line 38 skipping to change at page 10, line 48
+--rw mac-address? yang:mac-address +--rw 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 8343 This YANG module augments the interface container defined in RFC 8343
[RFC8343]. [RFC8343].
<CODE BEGINS> file "ietf-interfaces-common@2018-07-02.yang" <CODE BEGINS> file "ietf-interfaces-common@2019-03-05.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-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
skipping to change at page 12, line 33 skipping to change at page 11, line 44
<mailto:joelja@gmail.com> <mailto:joelja@gmail.com>
WG Chair: Kent Watsen WG Chair: Kent Watsen
<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 8343) with common configurable layer 2
properties. properties.
Copyright (c) 2016-2018 IETF Trust and the persons identified Copyright (c) 2016-2019 IETF Trust and the persons identified
as 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 2018-07-02 { revision 2019-03-05 {
description description
"Initial version"; "Initial version";
reference "Internet draft: draft-ietf-netmod-intf-ext-yang-06"; reference "Internet draft: draft-ietf-netmod-intf-ext-yang-07";
} }
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 "RFC XXX, Section 3.1 Carrier Delay"; reference "RFC XXX, Section 3.1 Carrier Delay";
} }
skipping to change at page 20, line 48 skipping to change at page 20, line 11
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) 802.1Q VLAN tags.";
reference "RFC XXX, Section 3.5 Layer 2 MTU"; reference "RFC XXX, Section 3.5 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;
} }
skipping to change at page 22, line 4 skipping to change at page 21, line 14
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.6 Sub-interface"; reference "RFC XXX, Section 3.6 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 8343 This YANG module augments the interface container defined in RFC 8343
[RFC8343] for Ethernet-like interfaces. This includes Ethernet [RFC8343] 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-07-03.yang" <CODE BEGINS> file "ietf-interfaces-ethernet-like@2019-03-05.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 22, line 44 skipping to change at page 22, line 9
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Lou Berger WG Chair: Lou Berger
<mailto:lberger@labn.net> <mailto:lberger@labn.net>
WG Chair: Joel Jaeggli
<mailto:joelja@gmail.com>
WG Chair: Kent Watsen WG Chair: Kent Watsen
<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 YANG definitions for configuration for "This module contains YANG definitions for configuration for
'Ethernet-like' interfaces. It is applicable to all interface 'Ethernet-like' interfaces. It is applicable to all interface
types that use Ethernet framing and expose an Ethernet MAC types that use Ethernet framing and expose an Ethernet MAC
layer, and includes such interfaces as physical Ethernet layer, and includes such interfaces as physical Ethernet
interfaces, Ethernet LAG interfaces and VLAN sub-interfaces. interfaces, Ethernet LAG interfaces and VLAN sub-interfaces.
Copyright (c) 2016 IETF Trust and the persons identified as Copyright (c) 2016-2019 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 2017-07-03 { revision 2019-03-05 {
description "Updated to conform to NMDA architecture"; description "Initial revision";
reference reference
"Internet draft: draft-ietf-netmod-intf-ext-yang-05"; "Internet draft: draft-ietf-netmod-intf-ext-yang-07";
} }
/* /*
* 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')" {
skipping to change at page 25, line 32 skipping to change at page 24, line 42
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common"> xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<type>ianaift:ethernetCsmacd</type> <type>ianaift:ethernetCsmacd</type>
<if-cmn:carrier-delay> <if-cmn:carrier-delay>
<if-cmn:down>0</if-cmn:down> <if-cmn:down>0</if-cmn:down>
<if-cmn:up>1000</if-cmn:up> <if-cmn:up>50</if-cmn:up>
</if-cmn:carrier-delay> </if-cmn:carrier-delay>
</interface> </interface>
</interfaces> </interfaces>
The following example shows explicit carrier delay up and down values The following example shows explicit carrier delay up and down values
have been configured. A 50 msec down leaf value has been used to have been configured. A 50 msec down leaf value has been used to
potentially allow optical protection to recover the link before the potentially allow optical protection to recover the link before the
higher layer protocol state is flapped. A 1 second (1000 higher layer protocol state is flapped. A 1 second (1000
milliseconds) up leaf value has been used to ensure that the link is milliseconds) up leaf value has been used to ensure that the link is
always reasonably stable before allowing traffic to be carried over always reasonably stable before allowing traffic to be carried over
skipping to change at page 29, line 9 skipping to change at page 28, line 9
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, Xufeng Liu, and Andy Bierman for Neil Ketley, Qin Wu, William Lupton, Xufeng Liu, and Andy Bierman for
their helpful comments contributing to this draft. their helpful comments contributing to this draft.
9. ChangeLog 9. ChangeLog
XXX, RFC Editor, please delete this change log before publication. XXX, RFC Editor, please delete this change log before publication.
9.1. Version -06 9.1. Version -07
o Minor editorial updates
9.2. Version -06
o Remove reservable-bandwidth, based on Acee's suggestion o Remove reservable-bandwidth, based on Acee's suggestion
o Add examples o Add examples
o Add additional state parameters for carrier-delay and dampening o Add additional state parameters for carrier-delay and dampening
9.2. Version -05 9.3. Version -05
o Incorporate feedback from Andy Bierman o Incorporate feedback from Andy Bierman
9.3. Version -04 9.4. 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.4. Version -03 9.5. Version -03
o Fixed incorrect module name references, and updated tree output o Fixed incorrect module name references, and updated tree output
9.5. Version -02 9.6. 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 two YANG
files contained within this draft, and also appropriate URIs in the module files contained within this draft, and also appropriate URIs
"IETF XML Registry". in the "IETF XML Registry".
11. 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.
skipping to change at page 31, line 14 skipping to change at page 30, line 18
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
11.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. The module currently 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
12. References 12. References
skipping to change at page 32, line 10 skipping to change at page 31, line 14
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-netmod-sub-intf-vlan-model] [I-D.ietf-netmod-sub-intf-vlan-model]
Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
Sivaraj, "Sub-interface VLAN YANG Data Models", draft- Sivaraj, "Sub-interface VLAN YANG Data Models", draft-
ietf-netmod-sub-intf-vlan-model-03 (work in progress), ietf-netmod-sub-intf-vlan-model-04 (work in progress),
October 2017. July 2018.
[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,
<https://www.rfc-editor.org/info/rfc6241>. <https://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,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
skipping to change at page 32, line 35 skipping to change at page 31, line 39
<https://www.rfc-editor.org/info/rfc6536>. <https://www.rfc-editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[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,
<https://www.rfc-editor.org/info/rfc7224>. <https://www.rfc-editor.org/info/rfc7224>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Authors' Addresses Authors' Addresses
Robert Wilton (editor) Robert Wilton (editor)
Cisco Systems Cisco Systems
Email: rwilton@cisco.com Email: rwilton@cisco.com
David Ball David Ball
Cisco Systems Cisco Systems
Email: daviball@cisco.com Email: daviball@cisco.com
Tapraj Singh Tapraj Singh
Cisco Systems Cisco Systems
Email: tapsingh@juniper.net Email: tapsingh@juniper.net
Selvakumar Sivaraj Selvakumar Sivaraj
Juniper Networks Juniper Networks
Email: ssivaraj@juniper.net Email: ssivaraj@juniper.net
 End of changes. 38 change blocks. 
86 lines changed or deleted 84 lines changed or added

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