draft-ietf-opsawg-service-model-explained-02.txt   draft-ietf-opsawg-service-model-explained-03.txt 
OPS Area Working Group Q. Wu OPS Area Working Group Q. Wu
Internet-Draft W. Liu Internet-Draft W. Liu
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: February 25, 2018 A. Farrel Expires: March 9, 2018 A. Farrel
Juniper Networks Juniper Networks
August 24, 2017 September 5, 2017
Service Models Explained Service Models Explained
draft-ietf-opsawg-service-model-explained-02 draft-ietf-opsawg-service-model-explained-03
Abstract Abstract
The IETF has produced many data modules in the YANG modeling The IETF has produced many data modules in the YANG modeling
language. The majority of these modules are used to construct data language. The majority of these modules are used to construct data
models to model devices or monolithic functions. models to model devices or monolithic functions.
A small number of YANG modules have been defined to model services A small number of YANG modules have been defined to model services
(for example, the Layer Three Virtual Private Network Service Model (for example, the Layer Three Virtual Private Network Service Model
produced by the L3SM working group and documented in RFC 8049). produced by the L3SM working group and documented in RFC 8049).
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 February 25, 2018. This Internet-Draft will expire on March 9, 2018.
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 3, line 6 skipping to change at page 3, line 6
1. Introduction 1. Introduction
In recent years the number of data modules written in the YANG In recent years the number of data modules written in the YANG
modeling language [RFC6020] for configuration and monitoring has modeling language [RFC6020] for configuration and monitoring has
blossomed. Many of these are used for device-level configuration blossomed. Many of these are used for device-level configuration
(for example, [RFC7223]) or for control of monolithic functions or (for example, [RFC7223]) or for control of monolithic functions or
protocol instances (for example, [RFC7407]). protocol instances (for example, [RFC7407]).
Within the context of Software Defined Networking (SDN) [RFC7149] Within the context of Software Defined Networking (SDN) [RFC7149]
[RFC7426] YANG data models may be used on the interface between a [RFC7426], YANG data models may be used on the interface between a
controller and network devices, and between network orchestrators and controller and network devices, and between network orchestrators and
controllers. There may also be a hierarchy of such components with controllers. There may also be a hierarchy of such components with
super controllers, domain controllers, and device controllers all super controllers, domain controllers, and device controllers all
exchanging information and instructions using YANG models. exchanging information and instructions using YANG models.
There has been interest in using YANG to define and document data There has been interest in using YANG to define and document data
models that describe services in a portable way that is independent models that describe services in a portable way that is independent
of which network operator uses the model. For example, the Layer of which network operator uses the model. For example, the Layer
Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such
models may be used in manual and even paper-driven service request models may be used in manual and even paper-driven service request
skipping to change at page 4, line 28 skipping to change at page 4, line 28
but some companies may operate with internal customers so that, but some companies may operate with internal customers so that,
for example, an IP/MPLS packet network may be the customer of an for example, an IP/MPLS packet network may be the customer of an
optical transport network. optical transport network.
Service: A network operator delivers one or more services to a Service: A network operator delivers one or more services to a
customer. A service in the context of this document (sometimes customer. A service in the context of this document (sometimes
called a Network Service) is some form of connectivity between called a Network Service) is some form of connectivity between
customer sites and the Internet, or between customer sites across customer sites and the Internet, or between customer sites across
the network operator's network and across the Internet. However, the network operator's network and across the Internet. However,
a distinction should be drawn between the parameters that describe a distinction should be drawn between the parameters that describe
a service as included in a customer service model (q.v.) and a a service as included in a customer service model (see the
Service Level Agreement (SLA) as discussed in Section 5 and definition of this term, below) and a Service Level Agreement
Section 7.2. (SLA) as discussed in Section 5 and Section 7.2.
A service may be limited to simple connectivity (such as IP-based A service may be limited to simple connectivity (such as IP-based
Internet access), may be a tunnel (such as a virtual circuit), or Internet access), may be a tunnel (such as a virtual circuit), or
may be a more complex connectivity model (such as a multi-site may be a more complex connectivity model (such as a multi-site
virtual private network). Services may be further enhanced by virtual private network). Services may be further enhanced by
additional functions providing security, load-balancing, additional functions providing security, load-balancing,
accounting, and so forth. Additionally, services usually include accounting, and so forth. Additionally, services usually include
guarantees of quality, throughput, and fault reporting. guarantees of quality, throughput, and fault reporting.
This document makes a distinction between a service as delivered This document makes a distinction between a service as delivered
skipping to change at page 5, line 44 skipping to change at page 5, line 44
network operators: additional features that are specific to the network operators: additional features that are specific to the
offerings of individual network operators would be defined in offerings of individual network operators would be defined in
extensions or augmentations of the model. Except where extensions or augmentations of the model. Except where
specific technology details (such as encapsulations, or specific technology details (such as encapsulations, or
mechanisms applied on access links) are directly pertinent to mechanisms applied on access links) are directly pertinent to
the customer, customer service models are technology agnostic the customer, customer service models are technology agnostic
so that the customer does not have influence over or knowledge so that the customer does not have influence over or knowledge
of how the network operator engineers the service. of how the network operator engineers the service.
An example of where such details are relevant to the customer An example of where such details are relevant to the customer
are when they describe the behavior or interactions on the is when they describe the behavior or interactions on the
interface between the equipment at the customer site (often interface between the equipment at the customer site (often
referred to as the Customer Edge or CE equipment) and the referred to as the Customer Edge or CE equipment) and the
equipment at the network operator's site (usually referred to equipment at the network operator's site (usually referred to
as the Provider Edge or PE equipment). as the Provider Edge or PE equipment).
Service Delivery Model: A service delivery model is used by a Service Delivery Model: A service delivery model is used by a
network operator to define and manage how a service is network operator to define and manage how a service is
engineered in the network. It can be used by a human operator engineered in the network. It can be used by a human operator
(such as via a management station) or by a software tool to (such as via a management station) or by a software tool to
instruct network components. Such models are sometimes instruct network components. Such models are sometimes
skipping to change at page 6, line 21 skipping to change at page 6, line 21
consumed by "external systems" such as Operations Support consumed by "external systems" such as Operations Support
System (OSS). A service delivery model is expressed as a core System (OSS). A service delivery model is expressed as a core
set of parameters that are common across a network type and set of parameters that are common across a network type and
technology: additional features that are specific to the technology: additional features that are specific to the
configuration of individual vendor equipment or proprietary configuration of individual vendor equipment or proprietary
protocols would be defined in extensions or augmentations of protocols would be defined in extensions or augmentations of
the model. Service delivery models include technology-specific the model. Service delivery models include technology-specific
modules. modules.
The distinction between a customer service model and a service The distinction between a customer service model and a service
delivery model needs to be repeatedly clarified. A customer service delivery model needs to be clarified. A customer service model is
model is not a data model used to directly configure network devices, not a data model used to directly configure network devices,
protocols, or functions: it is not something that is sent to network protocols, or functions: it is not something that is sent to network
devices (i.e., routers or switches) for processing. Equally, a devices (i.e., routers or switches) for processing. Equally, a
customer service model is not a data model that describes how a customer service model is not a data model that describes how a
network operator realizes and delivers the service described by the network operator realizes and delivers the service described by the
model. This distinction is discussed further in later sections. model. This distinction is discussed further in later sections.
3. Using Service Models 3. Using Service Models
As already indicated, customer service models are used on the As already indicated, customer service models are used on the
interface between customers and network operators. This is shown interface between customers and network operators. This is shown
skipping to change at page 8, line 39 skipping to change at page 8, line 39
: . . : : . . :
: . . : : . . :
--------- --------- --------- --------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- --------- --------- --------- ---------
Figure 2: A Sample SDN Architecture Figure 2: A Sample SDN Architecture
But a customer's service request is (or should be) technology- But a customer's service request is (or should be) technology-
agnostic. That is, there should be an independence between the agnostic. That is, the technology that the network operator has
behavior and functions that a customer requests and the technology available to deliver the service should not influence the behavior
that the network operator has available to deliver the service. The and functions that a customer requests. The orchestrator must map
orchestrator must map the service request to its view, and this the service request to its view, and this mapping may include a
mapping may include a choice of which networks and technologies to choice of which networks and technologies to use depending on which
use depending on which service features have been requested. service features have been requested.
One implementation option to achieve this mapping is to split the One implementation option to achieve this mapping is to split the
orchestration function between a "Service Orchestrator" and a orchestration function between a "Service Orchestrator" and a
"Network Orchestrator" as shown in Figure 3. "Network Orchestrator" as shown in Figure 3.
Customer Customer
------------------ Service ---------- ------------------ Service ----------
| | Model | | | | Model | |
| Service |<-------->| Customer | | Service |<-------->| Customer |
| Orchestrator | (a) | | | Orchestrator | (a) | |
skipping to change at page 11, line 39 skipping to change at page 11, line 39
standardized customer service models. standardized customer service models.
o Service Level Agreements (SLAs) have a high degree of overlap with o Service Level Agreements (SLAs) have a high degree of overlap with
the definition of services present in customer service models. the definition of services present in customer service models.
Requests for specific bandwidth, for example, might be present in Requests for specific bandwidth, for example, might be present in
a customer service model, and agreement to deliver a service is a a customer service model, and agreement to deliver a service is a
commitment to the description of the service in the customer commitment to the description of the service in the customer
service model. However, SLAs typically include a number of fine- service model. However, SLAs typically include a number of fine-
grained details about how services are allowed to vary, by how grained details about how services are allowed to vary, by how
much, and how often. SLAs are also linked to commercial terms much, and how often. SLAs are also linked to commercial terms
with penalties and so forth, and so are also not good topics for with penalties and so forth, and thus are also not good topics for
standardization. As with commercial terms, it is expected that standardization. As with commercial terms, it is expected that
some network operators will enhance standard customer service some network operators will enhance standard customer service
models to include SLA parameters either using their own work or models to include SLA parameters either using their own work or
depending on material from standards bodies that specialize in depending on material from standards bodies that specialize in
this topic, but this feature is out of scope for the IETF's this topic, but this feature is out of scope for the IETF's
customer service models. customer service models.
If a network operator chooses to express an SLA using a data If a network operator chooses to express an SLA using a data
model, that model might be referenced as an extension or an model, that model might be referenced as an extension or an
augmentation of the customer service model. augmentation of the customer service model.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
briefly examines that other work and shows how it fits with the briefly examines that other work and shows how it fits with the
description of service models introduced in this document. description of service models introduced in this document.
6.1. Comparison With Network Service Models 6.1. Comparison With Network Service Models
As previously noted, [RFC8199] provides a classification of YANG data As previously noted, [RFC8199] provides a classification of YANG data
models. It introduces the term "Network Service YANG Module" to models. It introduces the term "Network Service YANG Module" to
identify the type of model used to "describe the configuration, state identify the type of model used to "describe the configuration, state
data, operations and notifications of abstract representations of data, operations and notifications of abstract representations of
services implemented on one or multiple network elements." These are services implemented on one or multiple network elements." These are
service delivery models as described in this document, that is, they service delivery models as described in this document; that is, they
are the models used on the interface between the Service Orchestrator are the models used on the interface between the Service Orchestrator
or OSS/BSS and the Network Orchestrator as shown in Figure 3. or OSS/BSS and the Network Orchestrator as shown in Figure 3.
Figure 1 of [RFC8199] can be modified to make this more clear and to Figure 1 of [RFC8199] can be modified to make this more clear and to
add an additional example of a Network Service YANG model as shown in add an additional example of a Network Service YANG model as shown in
Figure 4. This figure illustrates a functional architecture and an Figure 4. This figure illustrates a functional architecture, and an
implementation might choose to make different distinctions and implementation might choose to make different distinctions and
separations between components so that the functional units and separations between components so that the functional units and
interfaces illustrated might fall within a single implementation. interfaces illustrated might fall within a single implementation.
+---------------+ +---------------+
| | | |
| Customers | | Customers |
| | | |
+---------------+ +---------------+
skipping to change at page 14, line 10 skipping to change at page 14, line 10
VPWS: Virtual Private Wire Service VPWS: Virtual Private Wire Service
VPLS: Virtual Private LAN Service VPLS: Virtual Private LAN Service
Figure 4: YANG Module Layers Showing Service Models Figure 4: YANG Module Layers Showing Service Models
6.2. Service Delivery and Network Element Model Work 6.2. Service Delivery and Network Element Model Work
A number of IETF working groups are developing YANG models related to A number of IETF working groups are developing YANG models related to
services. These models focus on how the network operator configures services. These models focus on how the network operator configures
the network through protocols and devices to deliver a service. Some the network through protocols and devices to deliver a service. Some
of these models are classified as service delivery models while of these models are classified as service delivery models, while
others have details that are related to specific element others have details that are related to specific element
configuration and so are classed as network element models (also configuration and so are classed as network element models (also
called device models). called device models).
A sample set of these models is listed here: A sample set of these models is listed here:
o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG model that can be o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG model that can be
used to configure and manage BGP L3VPNs. used to configure and manage BGP L3VPNs.
o [I-D.ietf-bess-l2vpn-yang] documents a YANG model that it is o [I-D.ietf-bess-l2vpn-yang] documents a YANG model that it is
expected will be used by the management tools run by the network expected will be used by the management tools run by the network
operators in order to manage and monitor the network resources operators in order to manage and monitor the network resources
that they use to deliver L2VPN services. that they use to deliver L2VPN services.
o [I-D.ietf-bess-evpn-yang] defines YANG models for delivering an o [I-D.ietf-bess-evpn-yang] defines YANG models for delivering an
Ethernet VPN service. Ethernet VPN service.
6.3. Customer Service Model Work 6.3. Customer Service Model Work
Several initiatives within the IETF are developing customer service Several initiatives within the IETF are developing customer service
models. The most advanced presents the L3VPN service as described by models. The L3SM presents the L3VPN service as described by a
a network operator to a customer. The L3SM is described as in network operator to a customer. Figure 5, which is reproduced from
Figure 5 which is reproduced from [RFC8049]. As can be seen, the [RFC8049], shows that the L3SM is a customer service model as
L3SM is a customer service model as described in this document. described in this document.
L3VPN-SVC | L3VPN-SVC |
MODEL | MODEL |
| |
+------------------+ +-----+ +------------------+ +-----+
| Orchestration | < --- > | OSS | | Orchestration | < --- > | OSS |
+------------------+ +-----+ +------------------+ +-----+
| | | |
+----------------+ | +----------------+ |
| Config manager | | | Config manager | |
skipping to change at page 16, line 47 skipping to change at page 16, line 47
The MEF Forum has developed an architecture for network management The MEF Forum has developed an architecture for network management
and operation. It is documented as the Lifecycle Service and operation. It is documented as the Lifecycle Service
Orchestration (LSO) Reference Architecture and illustrated in Orchestration (LSO) Reference Architecture and illustrated in
Figure 2 of [MEF-55]. Figure 2 of [MEF-55].
The work of the MEF Forum embraces all aspects of Lifecycle Service The work of the MEF Forum embraces all aspects of Lifecycle Service
Orchestration including billing, SLAs, order management, and life- Orchestration including billing, SLAs, order management, and life-
cycle management. The IETF's work on service models is typically cycle management. The IETF's work on service models is typically
smaller offering a simple, self-contained service YANG module. Thus, smaller offering a simple, self-contained service YANG module. Thus,
it may be impractical to fit IETF service models into the MEF Forum it may be impractical to fit IETF service models into the MEF Forum
LSO architecture. This does not invalidate either approach, but only LSO architecture. This does not invalidate either approach: it only
observes that they are different. observes that they are different approaches.
7. Further Concepts 7. Further Concepts
This section introduces a few further, more advanced concepts This section introduces a few further, more advanced concepts
7.1. Technology Agnostic 7.1. Technology Agnostic
Service models should generally be technology agnostic. That is to Service models should generally be technology agnostic. That is to
say, the customer should not care how the service is provided so long say, the customer should not care how the service is provided so long
as the service is delivered. as the service is delivered.
skipping to change at page 17, line 50 skipping to change at page 17, line 50
The policies that express desired behavior of services on occurrence The policies that express desired behavior of services on occurrence
of specific events are close to SLA definitions: they should only be of specific events are close to SLA definitions: they should only be
included in the base service model where they are common to all included in the base service model where they are common to all
network operators' offerings. Policies that describe who at a network operators' offerings. Policies that describe who at a
customer may request or modify services (that is, authorization) are customer may request or modify services (that is, authorization) are
close to commercial terms: they, too, should only be included in the close to commercial terms: they, too, should only be included in the
base service model where they are common to all network operators' base service model where they are common to all network operators'
offerings. offerings.
As with commercial terms and SLAs discussed in Section 5 it is As with commercial terms and SLAs discussed in Section 5, it is
expected that some network operators will enhance standard customer expected that some network operators will enhance standard customer
service models to include policy parameters either using their own service models to include policy parameters either using their own
work or depending on specific policy models built in the IETF or work or depending on specific policy models built in the IETF or
other standards bodies. other standards bodies.
Nevertheless, policy is so important that all service models should Nevertheless, policy is so important that all service models should
be designed to be easily extensible to allow policy components to be be designed to be easily extensible to allow policy components to be
added and associated with services as needed. added and associated with services as needed.
7.3. Operator-Specific Features 7.3. Operator-Specific Features
When work on the L3SM was started, there was some doubt as to whether When work on the L3SM was started, there was some doubt as to whether
network operators would be able to agree on a common description of network operators would be able to agree on a common description of
the services that they offer to their customers because, in a the services that they offer to their customers because, in a
competitive environment, each markets the services in a different way competitive environment, each markets the services in a different way
with different additional features. However, the working group was with different additional features. However, the working group was
able to agree on a core set of features that multiple network able to agree on a core set of features that multiple network
operators were willing to consider as "common". They also understood operators were willing to consider as "common". They also understood
that should an individual network operator want to describe that, should an individual network operator want to describe
additional features (operator-specific features) they could do so by additional features (operator-specific features), they could do so by
extending or augmenting the L3SM model. extending or augmenting the L3SM model.
Thus, when a basic description of a core service is agreed and Thus, when a basic description of a core service is agreed and
documented in a service model, it is important that that model should documented in a service model, it is important that that model should
be easily extended or augmented by each network operator so that the be easily extended or augmented by each network operator so that the
standardized model can be used in a common way and only the operator- standardized model can be used in a common way and only the operator-
specific features varied from one environment to another. specific features varied from one environment to another.
7.4. Supporting Multiple Services 7.4. Supporting Multiple Services
Network operators will, in general, offer many different services to Network operators will, in general, offer many different services to
their customers. Each would normally be the subject of a separate their customers. Each would normally be the subject of a separate
service model. service model.
It is an implementation and deployment choice whether all service Whether each service model is handled by a specialized Service
models are processed by a single Service Orchestrator that can Orchestrator able to provide tuned behavior for a specific service or
coordinate between the different services, or whether each service whether all service models are handled by a single Service
model is handled by a specialized Service Orchestrator able to Orchestrator is an implementation and deployment choice.
provide tuned behavior for a specific service.
It is expected that, over time, certain elements of the service It is expected that, over time, certain elements of the service
models will be seen to repeat in each model. An example of such an models will be seen to repeat in each model. An example of such an
element is the postal address of the customer. element is the postal address of the customer.
It is anticipated that, while access to such information from each It is anticipated that, while access to such information from each
service model is important, the data will be described in its own service model is important, the data will be described in its own
module and may form part of the service model either by inclusion or module and may form part of the service model either by inclusion or
by index. by index.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
Clearly, the ability to modify information exchanges between customer Clearly, the ability to modify information exchanges between customer
and network operator may result in bogus requests, unwarranted and network operator may result in bogus requests, unwarranted
billing, and false expectations. Furthermore, in an automated billing, and false expectations. Furthermore, in an automated
system, modifications to service requests or the injection of bogus system, modifications to service requests or the injection of bogus
requests may lead to attacks on the network and delivery of customer requests may lead to attacks on the network and delivery of customer
traffic to the wrong place. traffic to the wrong place.
Therefore it is important that the protocol interface used to Therefore it is important that the protocol interface used to
exchange service request information between customer and network exchange service request information between customer and network
operator is subject to authorization, authentication, and encryption. operator is subject to authorization, authentication, and encryption.
Equally, all external intefaces, such as any of those between the Equally, all external interfaces, such as any of those between the
functional components in Figure 3 needs to be correctly secured. functional components in Figure 3 needs to be correctly secured.
This document discusses modeling the information, not how it is This document discusses modeling the information, not how it is
exchanged. exchanged.
9. Manageability Considerations 9. Manageability Considerations
This whole document discusses issues related to network management This whole document discusses issues related to network management
and control. and control.
skipping to change at page 20, line 7 skipping to change at page 20, line 7
The operational state of a service does not form part of a customer The operational state of a service does not form part of a customer
service model. However, it is likely that a network operator may service model. However, it is likely that a network operator may
want to report some state information about various components of the want to report some state information about various components of the
service, and that could be achieved through extensions to the core service, and that could be achieved through extensions to the core
service model just as SLA extensions could be made as described in service model just as SLA extensions could be made as described in
Section 5. Section 5.
10. IANA Considerations 10. IANA Considerations
This document makes no requests for IANA action This document makes no requests for IANA action.
11. Acknowledgements 11. Acknowledgements
Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, and Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, and
Luis Miguel Contreras Murillo for useful review and comments. Luis Miguel Contreras Murillo for useful review and comments.
Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their
help coordinating with [RFC8199]. help coordinating with [RFC8199].
Many thanks to Jerry Bonner for spotting a tiny, one-word, but Many thanks to Jerry Bonner for spotting a tiny, one-word, but
critical typo. critical typo.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, <https://www.rfc- DOI 10.17487/RFC3444, January 2003,
editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>. 2017, <https://www.rfc-editor.org/info/rfc8199>.
12.2. Informative References 12.2. Informative References
[I-D.dhjain-bess-bgp-l3vpn-yang] [I-D.dhjain-bess-bgp-l3vpn-yang]
Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
skipping to change at page 21, line 16 skipping to change at page 21, line 16
Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data
Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-
service-model-02 (work in progress), July 2017. service-model-02 (work in progress), July 2017.
[MEF-55] MEF Forum, "Service Operations Specification MEF 55 : [MEF-55] MEF Forum, "Service Operations Specification MEF 55 :
Lifecycle Service Orchestration (LSO) Reference Lifecycle Service Orchestration (LSO) Reference
Architecture and Framework", March 2016. Architecture and Framework", March 2016.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- DOI 10.17487/RFC6020, October 2010,
editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[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,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
[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,
<https://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, <https://www.rfc- DOI 10.17487/RFC7297, July 2014,
editor.org/info/rfc7297>. <https://www.rfc-editor.org/info/rfc7297>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <https://www.rfc-editor.org/info/rfc7407>. December 2014, <https://www.rfc-editor.org/info/rfc7407>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, <https://www.rfc- DOI 10.17487/RFC7491, March 2015,
editor.org/info/rfc7491>. <https://www.rfc-editor.org/info/rfc7491>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049, Model for L3VPN Service Delivery", RFC 8049,
DOI 10.17487/RFC8049, February 2017, <https://www.rfc- DOI 10.17487/RFC8049, February 2017,
editor.org/info/rfc8049>. <https://www.rfc-editor.org/info/rfc8049>.
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Technologies Huawei Technologies
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Will Liu Will Liu
Huawei Technologies Huawei Technologies
 End of changes. 25 change blocks. 
47 lines changed or deleted 46 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/