draft-ietf-netmod-yang-model-classification-05.txt   draft-ietf-netmod-yang-model-classification-06.txt 
NETMOD D. Bogdanovic NETMOD D. Bogdanovic
Internet-Draft Volta Networks, Inc. Internet-Draft Volta Networks, Inc.
Intended status: Informational B. Claise Intended status: Informational B. Claise
Expires: September 14, 2017 C. Moberg Expires: October 29, 2017 C. Moberg
Cisco Systems, Inc. Cisco Systems, Inc.
March 13, 2017 April 27, 2017
YANG Module Classification YANG Module Classification
draft-ietf-netmod-yang-model-classification-05 draft-ietf-netmod-yang-model-classification-06
Abstract Abstract
The YANG data modeling language is currently being considered for a The YANG data modeling language is currently being considered for a
wide variety of applications throughout the networking industry at wide variety of applications throughout the networking industry at
large. Many standards-defining organizations (SDOs), open source large. Many standards-defining organizations (SDOs), open source
software projects, vendors and users are using YANG to develop and software projects, vendors and users are using YANG to develop and
publish YANG modules for a wide variety of applications. At the same publish YANG modules for a wide variety of applications. At the same
time, there is currently no well-known terminology to categorize time, there is currently no well-known terminology to categorize
various types of YANG modules. various types of YANG modules.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on October 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4 2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4
2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6 2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6
2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7 2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7
3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7 3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7
3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8
3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8
3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Internet Engineering Steering Group (IESG) has been actively The Internet Engineering Steering Group (IESG) has been actively
encouraging IETF working groups to use the YANG data modeling encouraging IETF working groups to use the YANG data modeling
skipping to change at page 6, line 21 skipping to change at page 6, line 21
service module does not expose the detailed configuration parameters service module does not expose the detailed configuration parameters
of all participating network elements and features, but describes an of all participating network elements and features, but describes an
abstract model that allows instances of the service to be decomposed abstract model that allows instances of the service to be decomposed
into instance data according to the Network Element YANG Modules of into instance data according to the Network Element YANG Modules of
the participating network elements. The service-to-element the participating network elements. The service-to-element
decomposition is a separate process with details depending on how the decomposition is a separate process with details depending on how the
network operator chooses to realize the service. For the purpose of network operator chooses to realize the service. For the purpose of
this document we will use the term "orchestrator" to describe a this document we will use the term "orchestrator" to describe a
system implementing such a process. system implementing such a process.
As an example, the Network Service YANG Module defined in
[draft-ietf-l3sm-l3vpn-service-model] provides an abstract model for
Layer 3 IP VPN service configuration. This module includes e.g. the
concept of a 'site-network-access' to represent bearer and connection
parameters. An orchestrator receives operations on service instances
according to the service module and decomposes the data into specific
Network Element YANG Modules to configure the participating network
elements to the service. In the case of the L3VPN module, this would
include translating the 'site-network-access' parameters to the
appropriate parameters in the Network Element YANG Module implemented
on the constituent elements.
Network Service YANG Modules define service models to be consumed by Network Service YANG Modules define service models to be consumed by
external systems. External systems can be provisioning systems, external systems. External systems can be provisioning systems,
service orchestrators, Operations Support Systems, Business Support service orchestrators, Operations Support Systems, Business Support
Systems and applications exposed to network service consumers, being Systems and applications exposed to network service consumers, being
either internal network operations peole or extarnal customers. either internal network operations peole or extarnal customers.
These modules are commonly designed, developed and deployed by These modules are commonly designed, developed and deployed by
network infrastructure teams. network infrastructure teams.
YANG allows for different design patterns to describe network YANG allows for different design patterns to describe network
services, ranging from monolithic to component-based approaches. services, ranging from monolithic to component-based approaches.
skipping to change at page 7, line 19 skipping to change at page 7, line 7
speed. speed.
As an example, an L2VPN service can be built on many different types As an example, an L2VPN service can be built on many different types
of transport network technologies, including e.g. MPLS or carrier of transport network technologies, including e.g. MPLS or carrier
ethernet. A component-based approach would allow for reuse of e.g. ethernet. A component-based approach would allow for reuse of e.g.
UNI-interface definitions independent of the underlying transport UNI-interface definitions independent of the underlying transport
network (e.g. MEF UNI interface or MPLS interface). The monolithic network (e.g. MEF UNI interface or MPLS interface). The monolithic
approach would assume a specific set of transport technologies and approach would assume a specific set of transport technologies and
interface definitions. interface definitions.
Another example for a network service model is [RFC8049]. Although
it provides information that can be used to achieve customer service
service level agreement, which is more then network service module
classification describes in this document, it provides an abstract
model for Layer 3 IP VPN service configuration which is a good
network service model. This module includes e.g. the concept of a
'site-network-access' to represent bearer and connection parameters.
An orchestrator receives operations on service instances according to
the service module and decomposes the data into specific Network
Element YANG Modules to configure the participating network elements
to the service. In the case of the L3VPN module, this would include
translating the 'site-network-access' parameters to the appropriate
parameters in the Network Element YANG Module implemented on the
constituent elements.
2.2. Network Element YANG Modules 2.2. Network Element YANG Modules
Network Element YANG Modules describe the characteristics of a Network Element YANG Modules describe the characteristics of a
network device as defined by the vendor of that device. The modules network device as defined by the vendor of that device. The modules
are commonly structured around features of the device, e.g. interface are commonly structured around features of the device, e.g. interface
configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and
firewall rules definitions [I-D.ietf-netmod-acl-model]. firewall rules definitions [I-D.ietf-netmod-acl-model].
Although the [RFC7950], [RFC7950] doesn't explain the relationship of Although the [RFC7950], [RFC7950] doesn't explain the relationship of
the terms '(YANG) data model' and '(YANG) module', the authors the terms '(YANG) data model' and '(YANG) module', the authors
skipping to change at page 10, line 19 skipping to change at page 10, line 23
version 01: Language fixes, collapsing of vendor data models and version 01: Language fixes, collapsing of vendor data models and
extensions, and the introduction of user data models and extensions. extensions, and the introduction of user data models and extensions.
version 02: Updated the YANG Module Catalog section, terminology version 02: Updated the YANG Module Catalog section, terminology
alignment (YANG data model versus YANG module), explain better the alignment (YANG data model versus YANG module), explain better the
distinction between the Network Element and Service YANG data models distinction between the Network Element and Service YANG data models
even if sometimes there are grey areas, editorial pass. Changed the even if sometimes there are grey areas, editorial pass. Changed the
use of the term 'model' to 'module' to be better aligned with use of the term 'model' to 'module' to be better aligned with
RFC6020. RFC6020.
version 06: updates based on comments from Adrian Farrel about YANG
Data Model for L3VPN Service Delivery.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <http://www.rfc-editor.org/info/rfc7223>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
8.2. Informative References [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/
RFC8049, February 2017,
<http://www.rfc-editor.org/info/rfc8049>.
[draft-ietf-l3sm-l3vpn-service-model] 8.2. Informative References
"YANG Data Model for L3VPN service delivery",
<https://tools.ietf.org/id/draft-ietf-l3sm-l3vpn-service-
model>.
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
"Network Access Control List (ACL) YANG Data Model", "Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-10 (work in progress), March draft-ietf-netmod-acl-model-10 (work in progress), March
2017. 2017.
[I-D.ietf-ospf-yang] [I-D.ietf-ospf-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"Yang Data Model for OSPF Protocol", draft-ietf-ospf- "Yang Data Model for OSPF Protocol", draft-ietf-ospf-
yang-06 (work in progress), October 2016. yang-07 (work in progress), March 2017.
[Writable-MIB-Module-IESG-Statement] [Writable-MIB-Module-IESG-Statement]
"Writable MIB Module IESG Statement", "Writable MIB Module IESG Statement",
<https://www.ietf.org/iesg/statement/writable-mib- <https://www.ietf.org/iesg/statement/writable-mib-
module.html>. module.html>.
Authors' Addresses Authors' Addresses
Dean Bogdanovic Dean Bogdanovic
Volta Networks, Inc. Volta Networks, Inc.
 End of changes. 11 change blocks. 
23 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/