Internet DRAFT - draft-faq-anima-cpe-yang-profile

draft-faq-anima-cpe-yang-profile







Anima                                                          I. Farrer
Internet-Draft                                                    Q. Sun
Intended status: Informational                                  S. Zoric
Expires: January 7, 2016                             Deutsche Telekom AG
                                                          M. Abrahamsson
                                                               T-Systems
                                                            July 6, 2015


  YANG Models Required for Managing Customer Premises Equipment (CPE)
                                Devices
                  draft-faq-anima-cpe-yang-profile-00

Abstract

   This document collects together the YANG models necessary for
   managing a NETCONF-enabled Customer Premises Equipment (CPE) device.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Farrer, et al.           Expires January 7, 2016                [Page 1]

Internet-Draft           CPE YANG Device Profile               July 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Management Requirements . . . . . . . . . . . . . . . . . . .   3
     3.1.  Interfaces  . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  Development Status of Relevent YANG Models  . . . . .   4
     3.2.  IP Management . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Development of Relevent YANG Models . . . . . . . . .   5
     3.3.  Routing Management  . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Development of Relevent YANG Models . . . . . . . . .   5
     3.4.  NETCONF Server Management . . . . . . . . . . . . . . . .   6
       3.4.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   6
       3.4.2.  Development of Relevent YANG Models . . . . . . . . .   6
     3.5.  DHCP/SLAAC/ND Management  . . . . . . . . . . . . . . . .   6
       3.5.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   6
       3.5.2.  Development of Relevent YANG Models . . . . . . . . .   7
     3.6.  NAT Management  . . . . . . . . . . . . . . . . . . . . .   7
       3.6.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   7
       3.6.2.  Development of Relevent YANG Models . . . . . . . . .   7
     3.7.  IPv6 Transition Mechanisms Management . . . . . . . . . .   8
       3.7.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   8
       3.7.2.  Development of Relevent YANG Models . . . . . . . . .   8
     3.8.  Management of Specific Services . . . . . . . . . . . . .   8
       3.8.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   8
       3.8.2.  Development of Relevent YANG Models . . . . . . . . .   8
     3.9.  Management of Security Components . . . . . . . . . . . .   9
       3.9.1.  Requirements  . . . . . . . . . . . . . . . . . . . .   9
       3.9.2.  Development of Relevent YANG Models . . . . . . . . .   9
     3.10. CPE Software Upgrade Management . . . . . . . . . . . . .   9
       3.10.1.  Requirements . . . . . . . . . . . . . . . . . . . .   9
       3.10.2.  Development of Relevent YANG Models  . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12






Farrer, et al.           Expires January 7, 2016                [Page 2]

Internet-Draft           CPE YANG Device Profile               July 2015


1.  Introduction

   NETCONF is used for the monitoring and configuration of networked
   devices.  Implementing NETCONF on CPE devices, along with the
   relevant YANG models, provides a flexible and exensible management
   interface for operators.

   This document describes the YANG models necessary for managing
   NETCONF-enabled CPE devices.  It defines the requirements for
   managing a CPE through NETCONF/YANG.

   Many of the YANG models which are referenced here are at early stages
   in the development process and in some cases there is currently no
   existing work.  The aim of this document is to defined which models
   are necessary and ror each required YANG model, provide information
   about the current status of the existing work.  It is intended as a
   'living document', which will be updated as the required / referenced
   YANG models change.  Once finalised, the goal of the document is to
   serve as a CPE YANG 'Device profile' to be used as a reference for
   implementors who are adding YANG management capabilities to their
   devices.

2.  Terminology

   CPE                   Customer Premises Equipment, which provides
                         access for devices connected to a Local Area
                         Network (LAN), typically at the customer's
                         site/home, to the Internet Service Provider's
                         (ISP's) network.  The CPE device described in
                         this document supports NETCONF/YANG.
   Existing RFCs         Lists of published RFCs at the time of writing
                         the document.
   Work In Progress      Lists of currently active Internet Drafts, or
                         relevant standards documents being produced by
                         organisations other than the IETF.
   To Be Defined         The models that are necessary for a CPE, but
                         are not defined by the time of writing the
                         document.

3.  Management Requirements

3.1.  Interfaces

   A CPE has a number of network interfaces, usually including some of
   the following interface types: Ethernet LAN, Ethernet WAN, Ethernet
   802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac).  The IETF has
   published a YANG model for general interface management, which
   identifies the previously listed interface types.  However,



Farrer, et al.           Expires January 7, 2016                [Page 3]

Internet-Draft           CPE YANG Device Profile               July 2015


   standardisation for Ethernet is done by the IEEE, so it is probable
   that the YANG models for managing these interfaces would be
   developed.

   NB - The list of interface types necessary for a complete, general
   HGW model clearly needs to include xDSL (BBF) and DOCSIS (ITU)
   interfaces.  A future version of this document needs to be extended
   to include these.

3.1.1.  Requirements

   A YANG-enabled CPE must implement the YANG model for general
   Interface Management [RFC7223] and support Interface type model
   defined in [RFC7224].

   Specific YANG model(s) for Ethernet LAN, Ethernet WAN, Ethernet
   802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac) interfaces.

   Needs to include support for optical parameter configuration in the
   Ethernet WAN interface YANG model.

   Support for Connectivity Fault Management (IEEE 802.1ag) in the
   Ethernet WAN interface YANG model.

3.1.2.  Development Status of Relevent YANG Models

   Existing RFCs:

   o  YANG Data Model for Interface Management [RFC7223].
   o  IANA Interface Type YANG Module [RFC7224].

   Work In Progress:

   o  IEEE Ethernet YANG Model [IEEE-ETH-YANG]

   To Be Defined:

   o  Ethernet WAN
   o  Ethernet 802.1q
   o  Ethernet 802.1ag
   o  Ethernet LAN
   o  WLAN (802.11a/b/n/g/ac)

3.2.  IP Management







Farrer, et al.           Expires January 7, 2016                [Page 4]

Internet-Draft           CPE YANG Device Profile               July 2015


3.2.1.  Requirements

   The CPE implementation requires the YANG models for managing IPv4 and
   IPv6.

3.2.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  YANG Data Model for IP Management [RFC7277].

   Work In Progress:

   o  [To be specified]

   To Be Defined:

   o  [To be specified]

3.3.  Routing Management

3.3.1.  Requirements

   A CPE requires support for the configuration and management of
   traditional IPv4/IPv6 routing protocols, as well as static route
   configuration.

   YANG models for the management of the IS-IS routing protocol are
   necessary for CPEs participating in home network IS-IS routing.

   Management of Protocol Independent Multicast (PIM) is required.

   Management of static multicast routes is required.

3.3.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  None

   Work In Progress:

   o  YANG Data Model for Routing Management:
      [I-D.ietf-netmod-routing-cfg].
   o  YANG model for static IPv4/IPv6 route: Appendix B in
      [I-D.ietf-netmod-routing-cfg].
   o  YANG Data Model for ISIS protocol: [I-D.ietf-isis-yang-isis-cfg].
   o  YANG model for PIM: [I-D.liu-pim-yang].



Farrer, et al.           Expires January 7, 2016                [Page 5]

Internet-Draft           CPE YANG Device Profile               July 2015


   o  YANG model for IGMP and MLD: [I-D.liu-pim-igmp-mld-yang].

   To Be Defined:

   o  Static Multicast Route

3.4.  NETCONF Server Management

3.4.1.  Requirements

   A NETCONF/YANG enabled CPE requires support for management and
   configuration of its local NETCONF server using the NETCONF protocol.

   A CPE requires support for the base notification function to allow a
   NETCONF client to retrieve notifications for common system events.

   A CPE retrieves NETCONF server configuration automatically during the
   bootstrap process (ZeroTouch).

   A CPE, as a NETCONF server, requires the Call Home function so that a
   secure connection to a NETCONF client can be initiated.

3.4.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  YANG Module for NETCONF Monitoring: [RFC6022].
   o  NETCONF Base Notifications: [RFC6470].

   Work In Progress:

   o  ZeroTouch: [I-D.ietf-netconf-zerotouch].
   o  NETCONF Call Home: [I-D.ietf-netconf-call-home].
   o  NETCONF Server Configuration Models:
      [I-D.ietf-netconf-server-model].

   To Be Defined:

   o  [To be specified]

3.5.  DHCP/SLAAC/ND Management

3.5.1.  Requirements

   A CPE requires support for the management of its DHCPv4 server, which
   typically runs at the IPv4 LAN side.





Farrer, et al.           Expires January 7, 2016                [Page 6]

Internet-Draft           CPE YANG Device Profile               July 2015


   A CPE requires support for the management of its DHCPv6 server, which
   can run at the IPv6 LAN side.

   A CPE requires support for the management of its DHCPv6 client, which
   typically runs at the IPv6 WAN side.

   A CPE requires support for the management of its DHCPv6 Prefix
   Delegation configuration (as a requesting router).

   A CPE requires support for the management of SLAAC for stateless IPv6
   configuration.

   A CPE requires support the for management of Neighbour Discovery
   Protocol configuration, including Router Advertisements on its LAN
   interface(s).

3.5.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  [To be specified]

   Work In Progress:

   o  YANG models for DHCPv4: [I-D.liu-dhc-dhcp-yang-model].
   o  YANG Data Model for DHCPv6 Configuration:
      [I-D.cui-dhc-dhcpv6-yang].

   To Be Defined:

   o  YANG for SLAAC (Router Advertisement)
   o  YANG for Neighbour Discovery Protocol (NDP)
   o  YANG for DHCPv6 Prefix Delegation (requesting router)

3.6.  NAT Management

3.6.1.  Requirements

   A CPE requires support for the management for NAT44/NAPT44
   configuration.

3.6.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  [To be specified]

   Work In Progress:



Farrer, et al.           Expires January 7, 2016                [Page 7]

Internet-Draft           CPE YANG Device Profile               July 2015


   o  [To be specified]: A possible way to do this is to start from the
      NAT MIB document [I-D.perrault-behave-natv2-mib].

   To Be Defined:

   o  YANG model for NAT Management: there is suggestion to produce such
      a model in the BEHAVE WG.
   o  Additional YANG models for specific protocol Application Layer
      Gateways may also be needed.

3.7.  IPv6 Transition Mechanisms Management

3.7.1.  Requirements

   A CPE intended for IPv6 transition, should be able to manage the
   supported IPv6 transition mechanism(s) through NETCONF/YANG.

3.7.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  [To be specified]

   Work In Progress:

   o  YANG model for IPv4-in-IPv6 Softwire: [I-D.sun-softwire-yang].

   To Be Defined:

   o  DHCP 4o6 client: May be combined in DHCPv6 YANG model as a
      feature.
   o  DNS64

3.8.  Management of Specific Services

3.8.1.  Requirements

   Some specific services may be needed for a CPE, such as SIP, Web, NTP
   and SSH services.  A CPE may support the management of those services
   through NETCONF/YANG.

3.8.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  NTP Client: [RFC7317]

   Work In Progress:



Farrer, et al.           Expires January 7, 2016                [Page 8]

Internet-Draft           CPE YANG Device Profile               July 2015


   o  [To be specified]

   To Be Defined:

   o  SIP Client
   o  Web server: This is used for configuring the CPE device.
   o  NTP server
   o  SSH server: Temporary for operator's need of management.  Will be
      retired.

3.9.  Management of Security Components

3.9.1.  Requirements

   A CPE requires support for the management of Firewall (v4/v6) and ACL
   functions.

3.9.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  [To be specified]

   Work In Progress:

   o  IPv4 Firewall configuration: [I-D.ietf-netmod-acl-model]
   o  IPv6 Firewall configuration: [I-D.ietf-netmod-acl-model]
   o  Access Control List (ACL): [I-D.ietf-netmod-acl-model]

   To Be Defined:

   o  IPv4/v6 Firewall (possible)

3.10.  CPE Software Upgrade Management

3.10.1.  Requirements

   During the operational life of the CPE, the firmware and software
   packages will need to be upgraded to fix bugs, enable new features
   and resolve security issues, etc.  A CPE requires RPCs for file
   transfer to retrieve up-to-date files from an operator-managed date
   centre.

3.10.2.  Development of Relevent YANG Models

   Existing RFCs:

   o  [To be specified]



Farrer, et al.           Expires January 7, 2016                [Page 9]

Internet-Draft           CPE YANG Device Profile               July 2015


   Work In Progress:

   o  File transfer: [I-D.sf-netmod-file-transfer-yang]

   To Be Defined:

   o  YANG model for firmware upgrade

4.  Security Considerations

   A NETCONF/YANG managed CPE should follow the Section 3.9 for enabling
   and managing IPv4/IPv6 firewalls.  Security considerations from the
   related documents should be followed.

5.  IANA Considerations

   There are no IANA considerations for this document.

6.  Acknowledgements

   The authors would like to thank xxx for their contributions to this
   work.

7.  References

7.1.  Normative References

   [I-D.cui-dhc-dhcpv6-yang]
              Cui, Y., Wang, H., Sun, L., Lemon, T., and I. Farrer,
              "YANG Data Model for DHCPv6 Configuration", draft-cui-dhc-
              dhcpv6-yang-03 (work in progress), July 2015.

   [I-D.ietf-isis-yang-isis-cfg]
              Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L.
              Lhotka, "YANG Data Model for ISIS protocol", draft-ietf-
              isis-yang-isis-cfg-04 (work in progress), July 2015.

   [I-D.ietf-netconf-call-home]
              Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
              draft-ietf-netconf-call-home-08 (work in progress), June
              2015.

   [I-D.ietf-netconf-server-model]
              Watsen, K. and J. Schoenwaelder, "NETCONF Server and
              RESTCONF Server Configuration Models", draft-ietf-netconf-
              server-model-06 (work in progress), February 2015.





Farrer, et al.           Expires January 7, 2016               [Page 10]

Internet-Draft           CPE YANG Device Profile               July 2015


   [I-D.ietf-netconf-zerotouch]
              Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch
              Provisioning for NETCONF Call Home (ZeroTouch)", draft-
              ietf-netconf-zerotouch-02 (work in progress), March 2015.

   [I-D.ietf-netmod-acl-model]
              Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair,
              "Network Access Control List (ACL) YANG Data Model",
              draft-ietf-netmod-acl-model-03 (work in progress), June
              2015.

   [I-D.ietf-netmod-routing-cfg]
              Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", draft-ietf-netmod-routing-cfg-19 (work in
              progress), May 2015.

   [I-D.liu-dhc-dhcp-yang-model]
              Liu, B. and K. Lou, "A YANG Data Model for DHCP
              Configuration", draft-liu-dhc-dhcp-yang-model-00 (work in
              progress), December 2014.

   [I-D.liu-pim-igmp-mld-yang]
              Liu, Y. and F. Guo, "Yang Model for Internet Group
              Management Protocol (IGMP) and Multicast Listener
              Discovery (MLD)", draft-liu-pim-igmp-mld-yang-01 (work in
              progress), March 2015.

   [I-D.liu-pim-yang]
              Liu, Y., Guo, F., and M. Sivakumar, "YANG Data Model for
              PIM", draft-liu-pim-yang-01 (work in progress), March
              2015.

   [I-D.perrault-behave-natv2-mib]
              Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
              "Definitions of Managed Objects for Network Address
              Translators (NAT)", draft-perrault-behave-natv2-mib-05
              (work in progress), June 2015.

   [I-D.sf-netmod-file-transfer-yang]
              Sun, Q. and I. Farrer, "A YANG Data Model for Transferring
              Files", draft-sf-netmod-file-transfer-yang-00 (work in
              progress), March 2015.

   [I-D.sun-softwire-yang]
              Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and
              R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire",
              draft-sun-softwire-yang-03 (work in progress), April 2015.




Farrer, et al.           Expires January 7, 2016               [Page 11]

Internet-Draft           CPE YANG Device Profile               July 2015


   [IEEE-ETH-YANG]
              "IEEE Ethernet YANG Model",
              <https://github.com/YangModels/yang/tree/master/
              experimental/ieee>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6022]  Scott, M. and M. Bjorklund, "YANG Module for NETCONF
              Monitoring", RFC 6022, October 2010.

   [RFC6470]  Bierman, A., "Network Configuration Protocol (NETCONF)
              Base Notifications", RFC 6470, February 2012.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, May 2014.

   [RFC7224]  Bjorklund, M., "IANA Interface Type YANG Module", RFC
              7224, May 2014.

   [RFC7277]  Bjorklund, M., "A YANG Data Model for IP Management", RFC
              7277, June 2014.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, August 2014.

7.2.  Informative References

   [I-D.ietf-softwire-unified-cpe]
              Boucadair, M., Farrer, I., Perreault, S., and S.
              Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft-
              ietf-softwire-unified-cpe-01 (work in progress), May 2013.

Authors' Addresses

   Ian Farrer
   Deutsche Telekom AG
   CTO-ATI, Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: ian.farrer@telekom.de









Farrer, et al.           Expires January 7, 2016               [Page 12]

Internet-Draft           CPE YANG Device Profile               July 2015


   Qi Sun
   Deutsche Telekom AG
   CTO-ATI, Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: qui.sun@external.telekom.de


   Sladjana Zoric
   Deutsche Telekom AG
   CTO-IPT, Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: sladjana.zoric@telekom.de


   Mikael Abrahamsson
   T-Systems

   Email: mikael.abrahamsson@t-systems.se





























Farrer, et al.           Expires January 7, 2016               [Page 13]