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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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

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

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

Work In Progress:

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

To Be Defined:

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

3.2. IP Management

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:

• YANG Data Model for IP Management [RFC7277].

Work In Progress:

• [To be specified]

To Be Defined:

• [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:

• None

Work In Progress:

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

To Be Defined:

• 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:

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

Work In Progress:

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

To Be Defined:

• [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.

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:

• [To be specified]

Work In Progress:

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

To Be Defined:

• YANG for SLAAC (Router Advertisement)
• YANG for Neighbour Discovery Protocol (NDP)
• 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:

• [To be specified]

Work In Progress:

• [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:

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

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:

• [To be specified]

Work In Progress:

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

To Be Defined:

• DHCP 4o6 client: May be combined in DHCPv6 YANG model as a feature.
• 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:

• NTP Client: [RFC7317]

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.

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:

• [To be specified]

Work In Progress:

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

To Be Defined:

• 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:

• [To be specified]

Work In Progress:

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

To Be Defined:

• 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

7.2. Informative References

Authors' Addresses