NETMOD WG I. Farrer
Internet-Draft Q. Sun
Intended status: Informational S. Zoric
Expires: April 18, 2016 Deutsche Telekom AG
M. Abrahamsson
T-Systems
October 16, 2015
YANG Models Required for Managing Customer Premises Equipment (CPE)
Devices
draft-faq-netmod-cpe-yang-profile-00
Abstract
This document collects together the YANG models necessary for
managing NETCONF-enabled Customer Premises Equipment (CPE) 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 April 18, 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 April 18, 2016 [Page 1]
Internet-Draft CPE YANG Device Profile October 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 Relevant YANG Models . . . . . 4
3.2. IP Management . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Development of Relevant YANG Models . . . . . . . . . 5
3.3. Routing and Multicast Management . . . . . . . . . . . . 5
3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . 5
3.3.2. Development of Relevant YANG Models . . . . . . . . . 6
3.4. CPE NETCONF Server Management . . . . . . . . . . . . . . 6
3.4.1. Requirements . . . . . . . . . . . . . . . . . . . . 6
3.4.2. Development Status of Relevant YANG Models . . . . . 6
3.5. DHCP/SLAAC/ND Management . . . . . . . . . . . . . . . . 7
3.5.1. Requirements . . . . . . . . . . . . . . . . . . . . 7
3.5.2. Development Status of Relevant YANG Models . . . . . 7
3.6. NAT Management . . . . . . . . . . . . . . . . . . . . . 8
3.6.1. Requirements . . . . . . . . . . . . . . . . . . . . 8
3.6.2. Development Status of Relevant YANG Models . . . . . 8
3.7. IPv6 Transition Mechanisms Management . . . . . . . . . . 8
3.7.1. Requirements . . . . . . . . . . . . . . . . . . . . 8
3.7.2. Development of Relevant YANG Models . . . . . . . . . 9
3.8. Management of Specific Services . . . . . . . . . . . . . 9
3.8.1. Requirements . . . . . . . . . . . . . . . . . . . . 9
3.8.2. Development of Relevant YANG Models . . . . . . . . . 9
3.9. Management of Security Components . . . . . . . . . . . . 10
3.9.1. Requirements . . . . . . . . . . . . . . . . . . . . 10
3.9.2. Development of Relevant YANG Models . . . . . . . . . 10
3.10. Remote CPE Software Upgrade . . . . . . . . . . . . . . . 10
3.10.1. Requirements . . . . . . . . . . . . . . . . . . . . 10
3.10.2. Development of Relevant YANG Models . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Farrer, et al. Expires April 18, 2016 [Page 2]
Internet-Draft CPE YANG Device Profile October 2015
1. Introduction
This document defines the requirements and specifies the necessary
YANG models for managing residential CPE devices using NETCONF and
YANG. Implementing NETCONF on CPE 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 CPE 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
CPE Customer Premises Equipment; provides access
between a customer's LAN connected devices and
their ISP's network. In the context of this
document, the CPE device implements NETCONF/YANG.
This document focuses on the type of residential
CPE that typically exists between the Internet
Service Provider access line and residential
customer home, doing similar functions that for
example [RFC7084] lists.
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
CPE management, but are not currently known to be
in development at the time of writing.
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). [RFC7223]
defines a YANG model for general interface management, which
identifies these (and other) interface types. However, Ethernet
Farrer, et al. Expires April 18, 2016 [Page 3]
Internet-Draft CPE YANG Device Profile October 2015
standardisation is carried out by the IEEE, so it is probable where
YANG models for managing these interfaces would be developed.
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.1.1. Requirements
The following requirements are necessary for basic CPE management
functionality.
INT-1: The CPE YANG implementation MUST implement general interface
management.
INT-2: The CPE YANG implementation MUST enable the configuration and
management 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 CPE YANG implementation MUST provide support for optical
parameter configuration for the Ethernet WAN interface YANG
model.
3.1.2. Development Status of Relevant YANG Models
Existing RFCs:
o YANG Data Model for Interface Management [RFC7223].
o IANA Interface Type YANG Module [RFC7224].
Work In Progress:
o IEEE 802.1q YANG Model [IEEE-ETH-YANG]
o Common Interface Extension YANG Data Models:
[I-D.wilton-netmod-intf-ext-yang].
o Interface VLAN YANG Data Models:
[I-D.wilton-netmod-intf-vlan-yang].
To Be Defined:
o Ethernet WAN
o Ethernet 802.1ag
o Ethernet LAN
o WLAN (802.11a/b/n/g/ac)
Farrer, et al. Expires April 18, 2016 [Page 4]
Internet-Draft CPE YANG Device Profile October 2015
3.2. IP Management
3.2.1. Requirements
The following requirements are necessary for the management and
configuration of IPv4 and IPv6.
IP-1: The CPE YANG implementation MUST enable the configuration and
management of IPv4 addresses and associated parameters on L3
interfaces.
IP-2: The CPE YANG implementation MUST enable the configuration and
management of IPv6 addresses and associated parameters on L3
interfaces.
3.2.2. Development of Relevant YANG Models
Existing RFCs:
o YANG Data Model for IP Management [RFC7277].
Work In Progress:
o YANG Model for DiffServ: [I-D.asechoud-netmod-diffserv-model].
To Be Defined:
o None
3.3. Routing and Multicast Management
3.3.1. Requirements
The following requirements are necessary for routing management.
ROUT-1: The CPE 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 CPE YANG implementation MUST include YANG models for the
management of static IPv4/IPv6 routes.
ROUT-3: The CPE YANG implementation MUST provide support for the
management of Protocol Independent Multicast (PIM).
ROUT-4: The CPE YANG implementation MUST provide support for the
management of static multicast routes.
Farrer, et al. Expires April 18, 2016 [Page 5]
Internet-Draft CPE YANG Device Profile October 2015
3.3.2. Development of Relevant 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.mcallister-pim-yang].
o YANG model for IGMP and MLD: [I-D.liu-pim-igmp-mld-yang].
To Be Defined:
o Static Multicast Route
o What is the HOMENET relevant dynamic routing protocol.
3.4. CPE NETCONF Server Management
3.4.1. Requirements
The following requirements are necessary for management of the CPE's
NETCONF Server.
NETCONF-1: The CPE YANG implementation MUST provide support for
management and configuration of its local NETCONF server
using the NETCONF protocol.
NETCONF-2: The CPE 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 CPE YANG implementation MUST be able to retrieve
NETCONF server configuration automatically during the
bootstrap process (ZeroTouch).
NETCONF-4: The CPE 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.4.2. Development Status of Relevant YANG Models
Existing RFCs:
o YANG Module for NETCONF Monitoring: [RFC6022].
o NETCONF Base Notifications: [RFC6470].
Farrer, et al. Expires April 18, 2016 [Page 6]
Internet-Draft CPE YANG Device Profile October 2015
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 None
3.5. DHCP/SLAAC/ND Management
3.5.1. Requirements
The following requirements are necessary for management of DHCP,
SLAAC and ND.
V6CONF-1: The CPE YANG implementation MUST provide support for
management of its DHCPv4 server, which typically runs at
the IPv4 LAN side.
V6CONF-2: The CPE YANG implementation MUST provide support for the
management of its DHCPv6 server, which can run at the IPv6
LAN side.
V6CONF-3: The CPE YANG implementation MUST provide support for the
management of its DHCPv6 client, which typically runs at
the IPv6 WAN side.
V6CONF-4: The CPE YANG implementation MUST provide support for the
management of its DHCPv6 Prefix Delegation configuration
(as a requesting router).
V6CONF-5: The CPE YANG implementation MUST provide support for the
management of SLAAC for stateless IPv6 configuration.
3.5.2. Development Status of Relevant YANG Models
Existing RFCs:
o None
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 model for SLAAC (Router Advertisement)
Farrer, et al. Expires April 18, 2016 [Page 7]
Internet-Draft CPE YANG Device Profile October 2015
o YANG model for Neighbour Discovery Protocol (NDP)
o YANG model for DHCPv6 Prefix Delegation (requesting router)
o YANG model for IPCP.
o YANG model for IPv6CP.
3.6. NAT Management
3.6.1. Requirements
The following requirements are necessary for NAT Management.
NAT-1: The CPE YANG implementation MUST provide support for
management of NAT44 configuration, as well as NAPT44
configuration.
3.6.2. Development Status of Relevant YANG Models
Existing RFCs:
o None
Work In Progress:
o YANG Data Model for NAT44 and stateful NAT64 function
[I-D.sivakumar-yang-nat].
To Be Defined:
o None
3.7. IPv6 Transition Mechanisms Management
3.7.1. Requirements
The following requirements are necessary for management of IPv6
Transition Mechanisms.
TRAN-2: The CPE YANG implementation must include configuration and
management for 6rd [RFC5969].
TRAN-2: The CPE YANG implementation must include configuration and
management for DS-Lite [RFC6333].
TRAN-3: The CPE YANG implementation must include configuration and
management for Lightweight 4over6 [RFC7596].
TRAN-4: The CPE YANG implementation must include configuration and
management for MAP-E [RFC7597].
TRAN-5: The CPE YANG implementation must include configuration and
management for MAP-T [RFC7599].
Farrer, et al. Expires April 18, 2016 [Page 8]
Internet-Draft CPE YANG Device Profile October 2015
3.7.2. Development of Relevant YANG Models
Existing RFCs:
o None
Work In Progress:
o YANG model for IPv4-in-IPv6 Softwire: [I-D.sun-softwire-yang].
o YANG Data Model for the DS-Lite Address Family Transition Router
(AFTR): [I-D.boucadair-softwire-dslite-yang].
To Be Defined:
o YANG model for 6rd.
o DHCP 4o6 client: May be combined in DHCPv6 YANG model as a
feature.
o DNS64
o Stateless NAT64 (required for MAP-T and 464xlat).
3.8. Management of Specific Services
3.8.1. Requirements
The following requirements are necessary for management of specific
services which the CPE may offer.
SERVICE-1: The CPE YANG implementation MUST provide support for the
management of a SIP client.
SERVICE-2: The CPE YANG implementation MUST provide support for the
management of a the CPEs Web server (used to provide a
local management interface).
SERVICE-3: The CPE YANG implementation MUST provide support for the
management of an NTP client and server.
SERVICE-4: The CPE YANG implementation MUST provide support for the
management of the SSH server.
3.8.2. Development of Relevant YANG Models
Existing RFCs:
o NTP Client: [RFC7317]
Work In Progress:
o None
To Be Defined:
Farrer, et al. Expires April 18, 2016 [Page 9]
Internet-Draft CPE YANG Device Profile October 2015
o SIP Client
o Web server, used by the customer for configuring their CPE device.
o NTP server
o SSH server
3.9. Management of Security Components
3.9.1. Requirements
The following requirements are necessary for management of security
components.
SEC-1: The CPE YANG implementation MUST provide support for the
management of IPv4 firewall and ACL functions.
SEC-1: The CPE YANG implementation MUST provide support for the
management of IPv6 firewall and ACL functions.
3.9.2. Development of Relevant YANG Models
Existing RFCs:
o None
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 (if needed in addition to the above)
o Parental controls
3.10. Remote CPE Software Upgrade
3.10.1. Requirements
The following requirements are necessary to perform remote CPE
Software file transfer and software upgrades.
SWUPG-1: The CPE 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 CPE YANG implementation MUST enable RPCs for file
transfer in order to retrieve files from an operator-
managed data centre, or upload logging.
Farrer, et al. Expires April 18, 2016 [Page 10]
Internet-Draft CPE YANG Device Profile October 2015
3.10.2. Development of Relevant YANG Models
Existing RFCs:
o None
Work In Progress:
o File transfer: [I-D.sf-netmod-file-transfer-yang]
To Be Defined:
o YANG model for firmware upgrade RPCs
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.asechoud-netmod-diffserv-model]
Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N.
Strahle, "YANG Model for Diffserv", draft-asechoud-netmod-
diffserv-model-03 (work in progress), June 2015.
[I-D.boucadair-softwire-dslite-yang]
Boucadair, M., Jacquenet, C., and S. Sivakumar, "YANG Data
Model for the DS-Lite Address Family Transition Router
(AFTR)", draft-boucadair-softwire-dslite-yang-02 (work in
progress), September 2015.
[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-04 (work in progress), September 2015.
Farrer, et al. Expires April 18, 2016 [Page 11]
Internet-Draft CPE YANG Device Profile October 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-06 (work in progress), September 2015.
[I-D.ietf-netconf-call-home]
Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
draft-ietf-netconf-call-home-11 (work in progress),
September 2015.
[I-D.ietf-netconf-server-model]
Watsen, K. and J. Schoenwaelder, "NETCONF Server and
RESTCONF Server Configuration Models", draft-ietf-netconf-
server-model-08 (work in progress), October 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-03 (work in progress), July 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-01 (work in
progress), July 2015.
[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.mcallister-pim-yang]
Liu, X., McAllister, P., and A. Peter, "A YANG data model
for Protocol-Independent Multicast (PIM)", draft-
mcallister-pim-yang-00 (work in progress), July 2015.
Farrer, et al. Expires April 18, 2016 [Page 12]
Internet-Draft CPE YANG Device Profile October 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.sivakumar-yang-nat]
Sivakumar, S., Boucadair, M., and S. <>, "YANG Data Model
for Network Address Translation (NAT)", draft-sivakumar-
yang-nat-03 (work in progress), September 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-04 (work in progress), October
2015.
[I-D.wilton-netmod-intf-ext-yang]
Wilton, R., Ball, D., Singh, T., and S. Sivaraj, "Common
Interface Extension YANG Data Models", draft-wilton-
netmod-intf-ext-yang-00 (work in progress), July 2015.
[I-D.wilton-netmod-intf-vlan-yang]
Wilton, R., Ball, D., Singh, T., and S. Sivaraj,
"Interface VLAN YANG Data Models", draft-wilton-netmod-
intf-vlan-yang-00 (work in progress), July 2015.
[IEEE-ETH-YANG]
"IEEE 802.1q YANG Model",
<http://www.ieee802.org/1/files/public/docs2015/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF
Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010,
<http://www.rfc-editor.org/info/rfc6022>.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
February 2012, <http://www.rfc-editor.org/info/rfc6470>.
Farrer, et al. Expires April 18, 2016 [Page 13]
Internet-Draft CPE YANG Device Profile October 2015
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC
7224, DOI 10.17487/RFC7224, May 2014,
<http://www.rfc-editor.org/info/rfc7224>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC
7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>.
7.2. Informative References
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", RFC
5969, DOI 10.17487/RFC5969, August 2010,
<http://www.rfc-editor.org/info/rfc5969>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/
RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>.
Farrer, et al. Expires April 18, 2016 [Page 14]
Internet-Draft CPE YANG Device Profile October 2015
Authors' Addresses
Ian Farrer
Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151
Bonn, NRW 53227
Germany
Email: ian.farrer@telekom.de
Qi Sun
Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151
Bonn, NRW 53227
Germany
Email: sunqi.ietf@gmail.com
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 April 18, 2016 [Page 15]