]> Deutsche Telekom AG

CTO-ATI, Landgrabenweg 151 Bonn NRW 53227 Germany ian.farrer@telekom.de

Deutsche Telekom AG

CTO-ATI, Landgrabenweg 151 Bonn NRW 53227 Germany qui.sun@external.telekom.de

Deutsche Telekom AG

CTO-IPT, Landgrabenweg 151 Bonn NRW 53227 Germany sladjana.zoric@telekom.de

T-Systems

mikael.abrahamsson@t-systems.se

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

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.

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. Lists of published RFCs at the time of writing the document. Lists of currently active Internet Drafts, or relevant standards documents being produced by organisations other than the IETF. The models that are necessary for a CPE, but are not defined by the time of writing the document.

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, 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.

A YANG-enabled CPE must implement the YANG model for general Interface Management and support Interface type model defined in . 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.

Existing RFCs: YANG Data Model for Interface Management . IANA Interface Type YANG Module . Work In Progress: IEEE Ethernet YANG Model To Be Defined: Ethernet WAN Ethernet 802.1q Ethernet 802.1ag Ethernet LAN WLAN (802.11a/b/n/g/ac)

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

Existing RFCs: YANG Data Model for IP Management . Work In Progress: [To be specified] To Be Defined: [To be specified]

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.

Existing RFCs: None Work In Progress: YANG Data Model for Routing Management: . YANG model for static IPv4/IPv6 route: Appendix B in . YANG Data Model for ISIS protocol: . YANG model for PIM: . YANG model for IGMP and MLD: . To Be Defined: Static Multicast Route

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.

Existing RFCs: YANG Module for NETCONF Monitoring: . NETCONF Base Notifications: . Work In Progress: ZeroTouch: . NETCONF Call Home: . NETCONF Server Configuration Models: . To Be Defined: [To be specified]

A CPE requires support for the management of its DHCPv4 server, which typically runs at the IPv4 LAN side. 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).

Existing RFCs: [To be specified] Work In Progress: YANG models for DHCPv4: . YANG Data Model for DHCPv6 Configuration: . To Be Defined: YANG for SLAAC (Router Advertisement) YANG for Neighbour Discovery Protocol (NDP) YANG for DHCPv6 Prefix Delegation (requesting router)

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

Existing RFCs: [To be specified] Work In Progress: [To be specified]: A possible way to do this is to start from the NAT MIB document . To Be Defined: YANG model for NAT Management: there is suggestion to produce such a model in the BEHAVE WG. Additional YANG models for specific protocol Application Layer Gateways may also be needed.

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

Existing RFCs: [To be specified] Work In Progress: YANG model for IPv4-in-IPv6 Softwire: . To Be Defined: DHCP 4o6 client: May be combined in DHCPv6 YANG model as a feature. DNS64

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.

Existing RFCs: NTP Client: Work In Progress: [To be specified] To Be Defined: SIP Client Web server: This is used for configuring the CPE device. NTP server SSH server: Temporary for operator's need of management. Will be retired.

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

Existing RFCs: [To be specified] Work In Progress: IPv4 Firewall configuration: IPv6 Firewall configuration: Access Control List (ACL): To Be Defined: IPv4/v6 Firewall (possible)

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.

Existing RFCs: [To be specified] Work In Progress: File transfer: To Be Defined: YANG model for firmware upgrade

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

There are no IANA considerations for this document.

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

&rfc2119; &rfc7277; &rfc7223; &rfc7224; &rfc6470; &rfc6022; &rfc7317;