idnits 2.17.00 (12 Aug 2021) /tmp/idnits31451/draft-faq-anima-cpe-yang-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 2510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-unified-cpe' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-cui-dhc-dhcpv6-yang-03 == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-04 == Outdated reference: draft-ietf-netconf-call-home has been published as RFC 8071 == Outdated reference: A later version (-09) exists of draft-ietf-netconf-server-model-06 == Outdated reference: draft-ietf-netconf-zerotouch has been published as RFC 8572 == Outdated reference: draft-ietf-netmod-acl-model has been published as RFC 8519 == Outdated reference: draft-ietf-netmod-routing-cfg has been published as RFC 8022 == Outdated reference: A later version (-07) exists of draft-liu-dhc-dhcp-yang-model-00 == Outdated reference: draft-perrault-behave-natv2-mib has been published as RFC 7659 == Outdated reference: A later version (-05) exists of draft-sun-softwire-yang-03 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: draft-ietf-softwire-unified-cpe has been published as RFC 8026 Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Anima I. Farrer 3 Internet-Draft Q. Sun 4 Intended status: Informational S. Zoric 5 Expires: January 7, 2016 Deutsche Telekom AG 6 M. Abrahamsson 7 T-Systems 8 July 6, 2015 10 YANG Models Required for Managing Customer Premises Equipment (CPE) 11 Devices 12 draft-faq-anima-cpe-yang-profile-00 14 Abstract 16 This document collects together the YANG models necessary for 17 managing a NETCONF-enabled Customer Premises Equipment (CPE) device. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Management Requirements . . . . . . . . . . . . . . . . . . . 3 56 3.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1.1. Requirements . . . . . . . . . . . . . . . . . . . . 4 58 3.1.2. Development Status of Relevent YANG Models . . . . . 4 59 3.2. IP Management . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . 5 61 3.2.2. Development of Relevent YANG Models . . . . . . . . . 5 62 3.3. Routing Management . . . . . . . . . . . . . . . . . . . 5 63 3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . 5 64 3.3.2. Development of Relevent YANG Models . . . . . . . . . 5 65 3.4. NETCONF Server Management . . . . . . . . . . . . . . . . 6 66 3.4.1. Requirements . . . . . . . . . . . . . . . . . . . . 6 67 3.4.2. Development of Relevent YANG Models . . . . . . . . . 6 68 3.5. DHCP/SLAAC/ND Management . . . . . . . . . . . . . . . . 6 69 3.5.1. Requirements . . . . . . . . . . . . . . . . . . . . 6 70 3.5.2. Development of Relevent YANG Models . . . . . . . . . 7 71 3.6. NAT Management . . . . . . . . . . . . . . . . . . . . . 7 72 3.6.1. Requirements . . . . . . . . . . . . . . . . . . . . 7 73 3.6.2. Development of Relevent YANG Models . . . . . . . . . 7 74 3.7. IPv6 Transition Mechanisms Management . . . . . . . . . . 8 75 3.7.1. Requirements . . . . . . . . . . . . . . . . . . . . 8 76 3.7.2. Development of Relevent YANG Models . . . . . . . . . 8 77 3.8. Management of Specific Services . . . . . . . . . . . . . 8 78 3.8.1. Requirements . . . . . . . . . . . . . . . . . . . . 8 79 3.8.2. Development of Relevent YANG Models . . . . . . . . . 8 80 3.9. Management of Security Components . . . . . . . . . . . . 9 81 3.9.1. Requirements . . . . . . . . . . . . . . . . . . . . 9 82 3.9.2. Development of Relevent YANG Models . . . . . . . . . 9 83 3.10. CPE Software Upgrade Management . . . . . . . . . . . . . 9 84 3.10.1. Requirements . . . . . . . . . . . . . . . . . . . . 9 85 3.10.2. Development of Relevent YANG Models . . . . . . . . 9 86 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 91 7.2. Informative References . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 NETCONF is used for the monitoring and configuration of networked 97 devices. Implementing NETCONF on CPE devices, along with the 98 relevant YANG models, provides a flexible and exensible management 99 interface for operators. 101 This document describes the YANG models necessary for managing 102 NETCONF-enabled CPE devices. It defines the requirements for 103 managing a CPE through NETCONF/YANG. 105 Many of the YANG models which are referenced here are at early stages 106 in the development process and in some cases there is currently no 107 existing work. The aim of this document is to defined which models 108 are necessary and ror each required YANG model, provide information 109 about the current status of the existing work. It is intended as a 110 'living document', which will be updated as the required / referenced 111 YANG models change. Once finalised, the goal of the document is to 112 serve as a CPE YANG 'Device profile' to be used as a reference for 113 implementors who are adding YANG management capabilities to their 114 devices. 116 2. Terminology 118 CPE Customer Premises Equipment, which provides 119 access for devices connected to a Local Area 120 Network (LAN), typically at the customer's 121 site/home, to the Internet Service Provider's 122 (ISP's) network. The CPE device described in 123 this document supports NETCONF/YANG. 124 Existing RFCs Lists of published RFCs at the time of writing 125 the document. 126 Work In Progress Lists of currently active Internet Drafts, or 127 relevant standards documents being produced by 128 organisations other than the IETF. 129 To Be Defined The models that are necessary for a CPE, but 130 are not defined by the time of writing the 131 document. 133 3. Management Requirements 135 3.1. Interfaces 137 A CPE has a number of network interfaces, usually including some of 138 the following interface types: Ethernet LAN, Ethernet WAN, Ethernet 139 802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac). The IETF has 140 published a YANG model for general interface management, which 141 identifies the previously listed interface types. However, 142 standardisation for Ethernet is done by the IEEE, so it is probable 143 that the YANG models for managing these interfaces would be 144 developed. 146 NB - The list of interface types necessary for a complete, general 147 HGW model clearly needs to include xDSL (BBF) and DOCSIS (ITU) 148 interfaces. A future version of this document needs to be extended 149 to include these. 151 3.1.1. Requirements 153 A YANG-enabled CPE must implement the YANG model for general 154 Interface Management [RFC7223] and support Interface type model 155 defined in [RFC7224]. 157 Specific YANG model(s) for Ethernet LAN, Ethernet WAN, Ethernet 158 802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac) interfaces. 160 Needs to include support for optical parameter configuration in the 161 Ethernet WAN interface YANG model. 163 Support for Connectivity Fault Management (IEEE 802.1ag) in the 164 Ethernet WAN interface YANG model. 166 3.1.2. Development Status of Relevent YANG Models 168 Existing RFCs: 170 o YANG Data Model for Interface Management [RFC7223]. 171 o IANA Interface Type YANG Module [RFC7224]. 173 Work In Progress: 175 o IEEE Ethernet YANG Model [IEEE-ETH-YANG] 177 To Be Defined: 179 o Ethernet WAN 180 o Ethernet 802.1q 181 o Ethernet 802.1ag 182 o Ethernet LAN 183 o WLAN (802.11a/b/n/g/ac) 185 3.2. IP Management 186 3.2.1. Requirements 188 The CPE implementation requires the YANG models for managing IPv4 and 189 IPv6. 191 3.2.2. Development of Relevent YANG Models 193 Existing RFCs: 195 o YANG Data Model for IP Management [RFC7277]. 197 Work In Progress: 199 o [To be specified] 201 To Be Defined: 203 o [To be specified] 205 3.3. Routing Management 207 3.3.1. Requirements 209 A CPE requires support for the configuration and management of 210 traditional IPv4/IPv6 routing protocols, as well as static route 211 configuration. 213 YANG models for the management of the IS-IS routing protocol are 214 necessary for CPEs participating in home network IS-IS routing. 216 Management of Protocol Independent Multicast (PIM) is required. 218 Management of static multicast routes is required. 220 3.3.2. Development of Relevent YANG Models 222 Existing RFCs: 224 o None 226 Work In Progress: 228 o YANG Data Model for Routing Management: 229 [I-D.ietf-netmod-routing-cfg]. 230 o YANG model for static IPv4/IPv6 route: Appendix B in 231 [I-D.ietf-netmod-routing-cfg]. 232 o YANG Data Model for ISIS protocol: [I-D.ietf-isis-yang-isis-cfg]. 233 o YANG model for PIM: [I-D.liu-pim-yang]. 235 o YANG model for IGMP and MLD: [I-D.liu-pim-igmp-mld-yang]. 237 To Be Defined: 239 o Static Multicast Route 241 3.4. NETCONF Server Management 243 3.4.1. Requirements 245 A NETCONF/YANG enabled CPE requires support for management and 246 configuration of its local NETCONF server using the NETCONF protocol. 248 A CPE requires support for the base notification function to allow a 249 NETCONF client to retrieve notifications for common system events. 251 A CPE retrieves NETCONF server configuration automatically during the 252 bootstrap process (ZeroTouch). 254 A CPE, as a NETCONF server, requires the Call Home function so that a 255 secure connection to a NETCONF client can be initiated. 257 3.4.2. Development of Relevent YANG Models 259 Existing RFCs: 261 o YANG Module for NETCONF Monitoring: [RFC6022]. 262 o NETCONF Base Notifications: [RFC6470]. 264 Work In Progress: 266 o ZeroTouch: [I-D.ietf-netconf-zerotouch]. 267 o NETCONF Call Home: [I-D.ietf-netconf-call-home]. 268 o NETCONF Server Configuration Models: 269 [I-D.ietf-netconf-server-model]. 271 To Be Defined: 273 o [To be specified] 275 3.5. DHCP/SLAAC/ND Management 277 3.5.1. Requirements 279 A CPE requires support for the management of its DHCPv4 server, which 280 typically runs at the IPv4 LAN side. 282 A CPE requires support for the management of its DHCPv6 server, which 283 can run at the IPv6 LAN side. 285 A CPE requires support for the management of its DHCPv6 client, which 286 typically runs at the IPv6 WAN side. 288 A CPE requires support for the management of its DHCPv6 Prefix 289 Delegation configuration (as a requesting router). 291 A CPE requires support for the management of SLAAC for stateless IPv6 292 configuration. 294 A CPE requires support the for management of Neighbour Discovery 295 Protocol configuration, including Router Advertisements on its LAN 296 interface(s). 298 3.5.2. Development of Relevent YANG Models 300 Existing RFCs: 302 o [To be specified] 304 Work In Progress: 306 o YANG models for DHCPv4: [I-D.liu-dhc-dhcp-yang-model]. 307 o YANG Data Model for DHCPv6 Configuration: 308 [I-D.cui-dhc-dhcpv6-yang]. 310 To Be Defined: 312 o YANG for SLAAC (Router Advertisement) 313 o YANG for Neighbour Discovery Protocol (NDP) 314 o YANG for DHCPv6 Prefix Delegation (requesting router) 316 3.6. NAT Management 318 3.6.1. Requirements 320 A CPE requires support for the management for NAT44/NAPT44 321 configuration. 323 3.6.2. Development of Relevent YANG Models 325 Existing RFCs: 327 o [To be specified] 329 Work In Progress: 331 o [To be specified]: A possible way to do this is to start from the 332 NAT MIB document [I-D.perrault-behave-natv2-mib]. 334 To Be Defined: 336 o YANG model for NAT Management: there is suggestion to produce such 337 a model in the BEHAVE WG. 338 o Additional YANG models for specific protocol Application Layer 339 Gateways may also be needed. 341 3.7. IPv6 Transition Mechanisms Management 343 3.7.1. Requirements 345 A CPE intended for IPv6 transition, should be able to manage the 346 supported IPv6 transition mechanism(s) through NETCONF/YANG. 348 3.7.2. Development of Relevent YANG Models 350 Existing RFCs: 352 o [To be specified] 354 Work In Progress: 356 o YANG model for IPv4-in-IPv6 Softwire: [I-D.sun-softwire-yang]. 358 To Be Defined: 360 o DHCP 4o6 client: May be combined in DHCPv6 YANG model as a 361 feature. 362 o DNS64 364 3.8. Management of Specific Services 366 3.8.1. Requirements 368 Some specific services may be needed for a CPE, such as SIP, Web, NTP 369 and SSH services. A CPE may support the management of those services 370 through NETCONF/YANG. 372 3.8.2. Development of Relevent YANG Models 374 Existing RFCs: 376 o NTP Client: [RFC7317] 378 Work In Progress: 380 o [To be specified] 382 To Be Defined: 384 o SIP Client 385 o Web server: This is used for configuring the CPE device. 386 o NTP server 387 o SSH server: Temporary for operator's need of management. Will be 388 retired. 390 3.9. Management of Security Components 392 3.9.1. Requirements 394 A CPE requires support for the management of Firewall (v4/v6) and ACL 395 functions. 397 3.9.2. Development of Relevent YANG Models 399 Existing RFCs: 401 o [To be specified] 403 Work In Progress: 405 o IPv4 Firewall configuration: [I-D.ietf-netmod-acl-model] 406 o IPv6 Firewall configuration: [I-D.ietf-netmod-acl-model] 407 o Access Control List (ACL): [I-D.ietf-netmod-acl-model] 409 To Be Defined: 411 o IPv4/v6 Firewall (possible) 413 3.10. CPE Software Upgrade Management 415 3.10.1. Requirements 417 During the operational life of the CPE, the firmware and software 418 packages will need to be upgraded to fix bugs, enable new features 419 and resolve security issues, etc. A CPE requires RPCs for file 420 transfer to retrieve up-to-date files from an operator-managed date 421 centre. 423 3.10.2. Development of Relevent YANG Models 425 Existing RFCs: 427 o [To be specified] 428 Work In Progress: 430 o File transfer: [I-D.sf-netmod-file-transfer-yang] 432 To Be Defined: 434 o YANG model for firmware upgrade 436 4. Security Considerations 438 A NETCONF/YANG managed CPE should follow the Section 3.9 for enabling 439 and managing IPv4/IPv6 firewalls. Security considerations from the 440 related documents should be followed. 442 5. IANA Considerations 444 There are no IANA considerations for this document. 446 6. Acknowledgements 448 The authors would like to thank xxx for their contributions to this 449 work. 451 7. References 453 7.1. Normative References 455 [I-D.cui-dhc-dhcpv6-yang] 456 Cui, Y., Wang, H., Sun, L., Lemon, T., and I. Farrer, 457 "YANG Data Model for DHCPv6 Configuration", draft-cui-dhc- 458 dhcpv6-yang-03 (work in progress), July 2015. 460 [I-D.ietf-isis-yang-isis-cfg] 461 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 462 Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- 463 isis-yang-isis-cfg-04 (work in progress), July 2015. 465 [I-D.ietf-netconf-call-home] 466 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 467 draft-ietf-netconf-call-home-08 (work in progress), June 468 2015. 470 [I-D.ietf-netconf-server-model] 471 Watsen, K. and J. Schoenwaelder, "NETCONF Server and 472 RESTCONF Server Configuration Models", draft-ietf-netconf- 473 server-model-06 (work in progress), February 2015. 475 [I-D.ietf-netconf-zerotouch] 476 Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch 477 Provisioning for NETCONF Call Home (ZeroTouch)", draft- 478 ietf-netconf-zerotouch-02 (work in progress), March 2015. 480 [I-D.ietf-netmod-acl-model] 481 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 482 "Network Access Control List (ACL) YANG Data Model", 483 draft-ietf-netmod-acl-model-03 (work in progress), June 484 2015. 486 [I-D.ietf-netmod-routing-cfg] 487 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 488 Management", draft-ietf-netmod-routing-cfg-19 (work in 489 progress), May 2015. 491 [I-D.liu-dhc-dhcp-yang-model] 492 Liu, B. and K. Lou, "A YANG Data Model for DHCP 493 Configuration", draft-liu-dhc-dhcp-yang-model-00 (work in 494 progress), December 2014. 496 [I-D.liu-pim-igmp-mld-yang] 497 Liu, Y. and F. Guo, "Yang Model for Internet Group 498 Management Protocol (IGMP) and Multicast Listener 499 Discovery (MLD)", draft-liu-pim-igmp-mld-yang-01 (work in 500 progress), March 2015. 502 [I-D.liu-pim-yang] 503 Liu, Y., Guo, F., and M. Sivakumar, "YANG Data Model for 504 PIM", draft-liu-pim-yang-01 (work in progress), March 505 2015. 507 [I-D.perrault-behave-natv2-mib] 508 Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor, 509 "Definitions of Managed Objects for Network Address 510 Translators (NAT)", draft-perrault-behave-natv2-mib-05 511 (work in progress), June 2015. 513 [I-D.sf-netmod-file-transfer-yang] 514 Sun, Q. and I. Farrer, "A YANG Data Model for Transferring 515 Files", draft-sf-netmod-file-transfer-yang-00 (work in 516 progress), March 2015. 518 [I-D.sun-softwire-yang] 519 Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and 520 R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire", 521 draft-sun-softwire-yang-03 (work in progress), April 2015. 523 [IEEE-ETH-YANG] 524 "IEEE Ethernet YANG Model", 525 . 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 532 Monitoring", RFC 6022, October 2010. 534 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 535 Base Notifications", RFC 6470, February 2012. 537 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 538 Management", RFC 7223, May 2014. 540 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 541 7224, May 2014. 543 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 544 7277, June 2014. 546 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 547 System Management", RFC 7317, August 2014. 549 7.2. Informative References 551 [I-D.ietf-softwire-unified-cpe] 552 Boucadair, M., Farrer, I., Perreault, S., and S. 553 Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft- 554 ietf-softwire-unified-cpe-01 (work in progress), May 2013. 556 Authors' Addresses 558 Ian Farrer 559 Deutsche Telekom AG 560 CTO-ATI, Landgrabenweg 151 561 Bonn, NRW 53227 562 Germany 564 Email: ian.farrer@telekom.de 565 Qi Sun 566 Deutsche Telekom AG 567 CTO-ATI, Landgrabenweg 151 568 Bonn, NRW 53227 569 Germany 571 Email: qui.sun@external.telekom.de 573 Sladjana Zoric 574 Deutsche Telekom AG 575 CTO-IPT, Landgrabenweg 151 576 Bonn, NRW 53227 577 Germany 579 Email: sladjana.zoric@telekom.de 581 Mikael Abrahamsson 582 T-Systems 584 Email: mikael.abrahamsson@t-systems.se