YANG Models Required for Managing Residential Gateway (RG) Devices
draft-faq-netmod-cpe-yang-profile-01

Abstract

This document collects together the set of YANG models necessary for managing NETCONF-enabled Residential Gateway (RG) devices.

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 September 14, 2017.

Copyright Notice

Copyright (c) 2017 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. General Requirements
• 3.1.1. Requirements
• 3.1.2. Development Status of Relevant YANG Models
• 3.2. Interfaces
• 3.2.1. Requirements
• 3.2.2. Development Status of Relevant YANG Models
• 3.3. IP Management
• 3.3.1. Requirements
• 3.3.2. Development Status of Relevant YANG Models
• 3.4. Routing and Multicast Management
• 3.4.1. Requirements
• 3.4.2. Development of Relevant YANG Models
• 3.5. RG NETCONF Server Management
• 3.5.1. Requirements
• 3.5.2. Development Status of Relevant YANG Models
• 3.6. DHCP/SLAAC/ND Management
• 3.6.1. Requirements
• 3.6.2. Development Status of Relevant YANG Models
• 3.7. NAT Management
• 3.7.1. Requirements
• 3.7.2. Development Status of Relevant YANG Models
• 3.8. IPv6 Transition Mechanisms Management
• 3.8.1. Requirements
• 3.8.2. Development of Relevant YANG Models
• 3.9. Management of Specific Services
• 3.9.1. Requirements
• 3.9.2. Development of Relevant YANG Models
• 3.10. Management of Security Components
• 3.10.1. Requirements
• 3.10.2. Development of Relevant YANG Models
• 3.11. Remote RG Software Upgrade
• 3.11.1. Requirements
• 3.11.2. Development of Relevant YANG Models
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

This document defines the requirements and specifies the necessary YANG models for managing RG devices using NETCONF [RFC6241] and YANG [RFC6020]. Implementing NETCONF on RG devices, along with the relevant YANG models, provides operators with a flexible and extensible management interface.

Many of the YANG models referenced here are in various stages in the development process. In some cases there is currently no existing work. The aim of this document is to catalog which models are necessary, and for each referenced 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 progress. Once finalised, the goal of the document is to serve as a RG YANG 'Device profile' that can be used as a reference for operators and implementors who are adding YANG management capabilities to their devices.

2. Terminology

RG

Residential Gateway; provides access between a customer's LAN connected devices and their ISP's network. In the context of this document, the RG device implements NETCONF/YANG. This document focuses on the type of Residential Gateway that typically exists between the Internet Service Provider access line and residential customer home, performing functions such as those described in [RFC7084].

Existing RFCs

Lists YANG models defined in published RFCs.

Work In Progress

YANG models under development in active Internet Drafts, or relevant documents being produced by SDOs other than the IETF.

To Be Defined

YANG models that are identified as necessary for RG management, but are not currently known to be in development at the time of writing.

3. Management Requirements

3.1. General Requirements

The following requirements are necessary for basic RG hardware management.

3.1.1. Requirements

GEN-1

The RG YANG implementation MUST provide a model for the management of hardware.

3.1.2. Development Status of Relevant YANG Models

Existing RFCs:

• None

Work In Progress:

• A YANG Data Model for Hardware Management: [I-D.han-netmod-intf-ext-ppp-yang]

To Be Defined (and SDOs that might be responsible for the standards)

• None

3.2. Interfaces

A RG 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). [RFC7223] defines a YANG model for general interface management, which identifies these (and other) interface types.

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

3.2.1. Requirements

The following requirements are necessary for basic RG interface management functionality.

INT-1:

The RG YANG implementation MUST implement general interface management.

INT-2:

The RG YANG implementation MUST enable the configuration and management (incl operational information) for the following interface types:

o

Ethernet LAN

o

Ethernet 802.1q

o

Ethernet 802.1ag (including Ethernet CFM)

o

Ethernet WAN

o

WLAN (802.11a/b/n/g/ac)

INT-3:

The RG YANG implementation MUST provide support for optical parameter configuration for the Ethernet WAN interface YANG model.

INT-4

The RG YANG implementation MUST provide a model for the management of hardware.

3.2.2. Development Status of Relevant YANG Models

Existing RFCs:

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

Work In Progress:

• IEEE 802.1q YANG Model [IEEE-ETH-YANG]
• Interface VLAN YANG Data Models: [I-D.ietf-netmod-sub-intf-vlan-model].
• Common Interface Extension YANG Data Models: [I-D.ietf-netmod-intf-ext-yang]
• YANG Model for the PPP Protocol: [I-D.han-netmod-intf-ext-ppp-yang]
• A YANG Data Model for Hardware Management: [I-D.han-netmod-intf-ext-ppp-yang]

To Be Defined (and SDOs that might be responsible for the standards)

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

3.3. IP Management

3.3.1. Requirements

The following requirements are necessary for the management and configuration of IPv4 and IPv6.

IP-1:

The RG YANG implementation MUST enable the configuration and management of IPv4 addresses and associated parameters on L3 interfaces.

IP-2:

The RG YANG implementation MUST enable the configuration and management of IPv6 addresses and associated parameters on L3 interfaces.

IP-3

The RG YANG implementation MUST allow for the configuration of differentiated services [RFC2474] related parameters on its interfaces.

3.3.2. Development Status of Relevant YANG Models

Existing RFCs:

• YANG Data Model for IP Management [RFC7277].

Work In Progress:

• YANG Model for DiffServ: [I-D.asechoud-netmod-diffserv-model].

To Be Defined:

• None

3.4. Routing and Multicast Management

3.4.1. Requirements

The following requirements are necessary for routing management.

ROUT-1:

The RG YANG implementation MUST provide support for the configuration and management of relevant IPv4/IPv6 dynamic routing protocols (for instance the ones relevant to IETF HOMENET WG).

ROUT-2:

The RG YANG implementation MUST include YANG models for the management of static IPv4/IPv6 routes.

ROUT-3:

The RG YANG implementation MUST provide support for the management of Protocol Independent Multicast (PIM).

ROUT-4:

The RG YANG implementation MUST provide support for the management of static multicast routes.

3.4.2. Development of Relevant YANG Models

Existing RFCs:

• None

Work In Progress:

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

To Be Defined:

• Static Multicast Route
• What is the HOMENET relevant dynamic routing protocol(s).

3.5. RG NETCONF Server Management

3.5.1. Requirements

The following requirements are necessary for management of the RG's NETCONF Server.

NETCONF-1:

The RG YANG implementation MUST provide support for management and configuration of its local NETCONF server using the NETCONF protocol.

NETCONF-2:

The RG YANG implementation MUST provide support for the base notification function in order to allow a NETCONF client to retrieve notifications for common system events.

NETCONF-3:

The RG YANG implementation MUST be able to retrieve NETCONF server configuration automatically during the bootstrap process (ZeroTouch).

NETCONF-4:

The RG YANG implementation as a NETCONF server MUST provide support for the Call Home function so that a secure connection to a NETCONF client can be initiated.

3.5.2. Development Status of Relevant 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: [RFC8071].
• NETCONF Server Configuration Models: [I-D.ietf-netconf-netconf-client-server].

To Be Defined:

• None

3.6. DHCP/SLAAC/ND Management

3.6.1. Requirements

The following requirements are necessary for management of DHCP, SLAAC and ND.

V6CONF-1:

The RG YANG implementation MUST provide support for management of its DHCPv4 server, which typically runs at the IPv4 LAN side.

V6CONF-2:

The RG YANG implementation MUST provide support for the management of its DHCPv6 server, which can run at the IPv6 LAN side.

V6CONF-3:

The RG YANG implementation MUST provide support for the management of its DHCPv6 client, which typically runs at the IPv6 WAN side.

V6CONF-4:

The RG YANG implementation MUST provide support for the management of its DHCPv6 Prefix Delegation configuration (as a requesting router).

V6CONF-5:

The RG YANG implementation MUST provide support for the management of SLAAC for stateless IPv6 configuration (as router on its LAN interfaces).

3.6.2. Development Status of Relevant YANG Models

Existing RFCs:

• IPv6 Router Advertisements: [RFC8022]

Work In Progress:

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

To Be Defined:

• YANG model for SLAAC (Router Advertisement). (IETF)
• YANG model for Neighbour Discovery Protocol (NDP). (IETF)
• YANG model for DHCPv6 Prefix Delegation (requesting router). (IETF)
• YANG model for IPCP. (IETF)
• YANG model for IPv6CP. (IETF)

3.7. NAT Management

3.7.1. Requirements

The following requirements are necessary for NAT Management.

NAT-1:

The RG YANG implementation MUST provide support for management of NAT44 configuration, as well as NAPT44 configuration.

3.7.2. Development Status of Relevant YANG Models

Existing RFCs:

• None

Work In Progress:

• YANG Data Model for NAT44 and stateful NAT64 function [I-D.sivakumar-yang-nat].

To Be Defined:

• None

3.8. IPv6 Transition Mechanisms Management

3.8.1. Requirements

The following requirements are necessary for management of IPv6 Transition Mechanisms.

TRAN-2:

The RG YANG implementation must include configuration and management for 6rd [RFC5969].

TRAN-2:

The RG YANG implementation must include configuration and management for DS-Lite [RFC6333].

TRAN-3:

The RG YANG implementation must include configuration and management for Lightweight 4over6 [RFC7596].

TRAN-4:

The RG YANG implementation must include configuration and management for MAP-E [RFC7597].

TRAN-5:

The RG YANG implementation must include configuration and management for MAP-T [RFC7599].

3.8.2. Development of Relevant YANG Models

Existing RFCs:

• None

Work In Progress:

• YANG model for IPv4-in-IPv6 Softwire: [I-D.ietf-softwire-yang].
• YANG Data Model for the DS-Lite Address Family Transition Router (AFTR): [I-D.ietf-softwire-dslite-yang].

To Be Defined:

• YANG model for 6rd. (IETF)
• DHCP 4o6 client: May be combined in DHCPv6 YANG model as a feature. (IETF)
• DNS64. (IETF)
• Stateless NAT64 (required for MAP-T and 464xlat). (IETF)

3.9. Management of Specific Services

3.9.1. Requirements

The following requirements are necessary for management of specific services which the RG may offer.

SERVICE-1:

The RG YANG implementation MUST provide support for the management of a SIP client.

SERVICE-2:

The RG YANG implementation MUST provide support for the management of a the RG Web server (used to provide a local management interface).

SERVICE-3:

The RG YANG implementation MUST provide support for the management of an NTP client and server.

SERVICE-4:

The RG YANG implementation MUST provide support for the management of the SSH server.

3.9.2. Development of Relevant YANG Models

Existing RFCs:

• NTP Client: [RFC7317]

Work In Progress:

• None

To Be Defined:

• SIP/VoIP Client. (IETF)
• Web server, used by the customer for configuring their RG. (?)
• NTP server. (IETF)
• SSH server. (IETF)

3.10. Management of Security Components

3.10.1. Requirements

The following requirements are necessary for management of security components.

SEC-1:

The RG YANG implementation MUST provide support for the management of IPv4 firewall and ACL functions.

SEC-1:

The RG YANG implementation MUST provide support for the management of IPv6 firewall and ACL functions.

3.10.2. Development of Relevant YANG Models

Existing RFCs:

• None

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 (if needed in addition to the above) (IETF?)
• Parental controls (?)

3.11. Remote RG Software Upgrade

3.11.1. Requirements

The following requirements are necessary to perform remote RG Software file transfer and software upgrades.

SWUPG-1:

The RG implementation must provide a YANG model for the upgrade of firmware and software packages in order to fix bugs, enable new features, and resolve security issues.

SWUPG-2:

The RG YANG implementation MUST enable RPCs for file transfer in order to retrieve files from an operator-managed data centre, or upload logging.

3.11.2. Development of Relevant YANG Models

Existing RFCs:

• None

Work In Progress:

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

To Be Defined:

• YANG model for firmware upgrade RPCs. (BBF?)

4. Security Considerations

A NETCONF/YANG managed RG should follow the Section 3.10 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