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", . [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]