Common Interface Extension YANG Data Models
draft-ietf-netmod-intf-ext-yang-02

#x27;burnt-in' MAC address.  I.e the default MAC address
              assigned to the interface if none is explicitly
              configured.";
         }
       }
     }
   }
   <CODE ENDS>

7.  Acknowledgements

   The authors wish to thank Juergen Schoenwaelder, Mahesh Jethanandani,
   Michael Zitao, Neil Ketley and Qin Wu for their helpful comments
   contributing to this draft.

8.  IANA Considerations

   This document defines several new YANG module and the authors
   politely request that IANA assigns unique names to the YANG module
   files contained within this draft, and also appropriate URIs in the
   "IETF XML Registry".

9.  Security Considerations

   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 secure transport layer and the mandatory to implement secure
   transport is SSH RFC 6242 [RFC6242].  The NETCONF access control
   model RFC 6536 [RFC6536] provides the means to restrict access for
   particular NETCONF users to a pre-configured subset of all available
   NETCONF protocol operations and content.

   There are a number of data nodes defined in this YANG module which
   are writable/creatable/deletable (i.e. config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g. edit-config) to

Wilton, et al.           Expires April 30, 2017                [Page 22]
Internet-Draft          Interface Extensions YANG           October 2016

   these data nodes without proper protection can have a negative effect
   on network operations.  These are the subtrees and data nodes and
   their sensitivity/vulnerability:

9.1.  interfaces-common.yang

   The interfaces-common YANG module contains various configuration
   leaves that affect the behavior of interfaces.  Modifying these
   leaves can cause an interface to go down, or become unreliable, or to
   drop traffic forwarded over it.  More specific details of the
   possible failure modes are given below.

   The following leaf could cause the interface to go down, and stop
   processing any ingress or egress traffic on the interface:

   o  /if:interfaces/if:interface/loopback

   The following leaf could cause changes to the routing metrics.  Any
   change in routing metrics could cause too much traffic to be routed
   through the interface, or through other interfaces in the network,
   potentially causing traffic loss due to excesssive traffic on a
   particular interface or network device:

   o  /if:interfaces/if:interface/bandwidth

   The following leaves could cause instabilities at the interface link
   layer, and cause unwanted higher layer routing path changes if the
   leaves are modified, although they would generally only affect a
   device that had some underlying link stability issues:

   o  /if:interfaces/if:interface/carrier-delay/down

   o  /if:interfaces/if:interface/carrier-delay/up

   o  /if:interfaces/if:interface/dampening/half-life

   o  /if:interfaces/if:interface/dampening/reuse

   o  /if:interfaces/if:interface/dampening/suppress

   o  /if:interfaces/if:interface/dampening/max-suppress-time

   The following leaves could cause traffic loss on the interface
   because the received or transmitted frames do not comply with the
   frame matching criteria on the interface and hence would be dropped:

   o  /if:interfaces/if:interface/encapsulation

Wilton, et al.           Expires April 30, 2017                [Page 23]
Internet-Draft          Interface Extensions YANG           October 2016

   o  /if:interfaces/if:interface/l2-mtu

   o  /if:interfaces/if:interface/l3-mtu

   o  /if:interfaces/if:interface/transport-layer

   Normally devices will not allow the parent-interface leaf to be
   changed after the interfce has been created.  If an implementation
   did allow the parent-interface leaf to be changed then it could cause
   all traffic on the affected interface to be dropped.  The affected
   leaf is:

   o  /if:interfaces/if:interface/parent-interface

9.2.  interfaces-ethernet-like.yang

   Generally, the configuration nodes in the interfaces-ethernet-like
   YANG module are concerned with configuration that is common across
   all types of Ethernet-like interfaces.  Currently, the module only
   contains a node for configuring the operational MAC address to use on
   an interface.  Adding/modifying/deleting this leaf has the potential
   risk of causing protocol instability, excessive protocol traffic, and
   general traffic loss, particularly if the configuration change caused
   a duplicate MAC address to be present on the local network .  The
   following leaf is affected:

   o  interfaces/interface/ethernet-like/mac-address

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

   [RFC7224]  Bjorklund, M., "IANA Interface Type YANG Module",
              RFC 7224, DOI 10.17487/RFC7224, May 2014,
              <http://www.rfc-editor.org/info/rfc7224>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <http://www.rfc-editor.org/info/rfc7950>.

Wilton, et al.           Expires April 30, 2017                [Page 24]
Internet-Draft          Interface Extensions YANG           October 2016

10.2.  Informative References

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <http://www.rfc-editor.org/info/rfc6242>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <http://www.rfc-editor.org/info/rfc6536>.

Authors' Addresses

   Robert Wilton (editor)
   Cisco Systems

   Email: rwilton@cisco.com

   David Ball
   Cisco Systems

   Email: daviball@cisco.com

   Tapraj Singh
   Cisco Systems

   Email: tapsingh@juniper.net

   Selvakumar Sivaraj
   Juniper Networks

   Email: ssivaraj@juniper.net

Wilton, et al.           Expires April 30, 2017                [Page 25]