< draft-wu-model-driven-management-virtualization-04.txt   draft-wu-model-driven-management-virtualization-05.txt >
Networking Working Group Q. Wu Networking Working Group Q. Wu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational M. Boucadair Intended status: Informational M. Boucadair
Expires: December 21, 2019 Orange Expires: January 4, 2020 C. Jacquenet
Orange
L. Miguel Contreras Murillo
Telifonica
D. Lopez
Telefonica I+D
C. Xie
China Telecom
W. Cheng
China Mobile
Y. Lee Y. Lee
Futurewei Futurewei
June 19, 2019 July 3, 2019
A Framework for Automating Service and Network Management with YANG A Framework for Automating Service and Network Management with YANG
draft-wu-model-driven-management-virtualization-04 draft-wu-model-driven-management-virtualization-05
Abstract Abstract
Model-driven service and network management provides a programmatic Data models for service and network management provides a
and standard-based approach for representing (virtual) services or programmatic approach for representing (virtual) services or networks
networks and configuration to the network device that are used to and deriving configuration information that will be forwarded to
build and deliver the service. Models can be used at various phases network and service components that are used to build and deliver the
of service and network management life cycle such as service service. Data Models can be used during various phases of the
instantiation, service provisionning, optimization, monitoring, and service and network management life cycle, such as service
diagnostic. Also, models can be designed to automate network instantiation, service provisioning, optimization, monitoring, and
management and provide closed-loop control for the sake of adaptive diagnostic. Also, data models are are instrumental in the automation
and deterministic service creation, delivery, and maintenance. of network management. They also provide closed-loop control for the
sake of adaptive and deterministic service creation, delivery, and
maintenance.
This document provides a framework that describes and discusses an This document provides a framework that describes and discusses an
architecture for service and network management automation with YANG architecture for service and network management automation that takes
modeling technologies. An applicability of YANG data models to advantage of YANG modeling technologies. This framework is drawn
automation of virtualized network service is also investigated. from a network provider perspective irrespective of the origin of a
data module andcan accommodate even modules that are developed
outside the IETF.
The document aims to exemplify an approach to illustrate the journey The document aims to exemplify an approach that specifies the journey
from technology-agnostic services to technology-specific actions. from technology-agnostic services to technology-specific actions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 21, 2019. This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IETF YANG Modules: An Overview . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Network Service and Resource Models . . . . . . . . . . . 5 2. Layered YANG Modules: An Overview . . . . . . . . . . . . . . 6
2.1.1. Network Service Models: Definition and Samples . . . 6 2.1. Network Service and Resource Models . . . . . . . . . . . 6
2.1.2. Network Resource Models . . . . . . . . . . . . . . . 7 2.1.1. Network Service Models: Definition and Samples . . . 7
2.2. Network Element Models . . . . . . . . . . . . . . . . . 10 2.1.2. Network Resource Models: Definitions and Samples . . 7
2.2. Network Element Models: Definitions and Samples . . . . . 10
2.2.1. Model Composition . . . . . . . . . . . . . . . . . . 11 2.2.1. Model Composition . . . . . . . . . . . . . . . . . . 11
2.2.2. Protocol/Function Configuration Models . . . . . . . 12 2.2.2. Protocol/Function Configuration Models: Definitions
and Samples . . . . . . . . . . . . . . . . . . . . . 12
3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 15 3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 15
3.1. Data Models: Layering and Representation . . . . . . . . 15 3.1. Data Models: Layering and Representation . . . . . . . . 15
3.2. Service Activation, Provision, and Invocation Automation 15 3.2. Automation of service delivery procedures . . . . . . . . 15
3.3. Service Enforcement Automation . . . . . . . . . . . . . 16 3.3. Service Fullfillment Automation . . . . . . . . . . . . . 16
3.4. Modules Decomposition and Composition . . . . . . . . . . 16 3.4. Module Decomposition and Composition . . . . . . . . . . 16
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 17 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 17
4.1. End-to-End Service Delivery and Service Assurance 4.1. End-to-End Service Delivery and Service Assurance
Procedure . . . . . . . . . . . . . . . . . . . . . . . . 17 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.1. Resource Collection and Abstraction (a) . . . . . . . 17 4.1.1. Resource Collection and Abstraction (a) . . . . . . . 18
4.1.2. Service Exposure & Abstraction (b) . . . . . . . . . 18 4.1.2. Service Exposure & Abstraction (b) . . . . . . . . . 18
4.1.3. IP Service Mapping (c) . . . . . . . . . . . . . . . 19 4.1.3. IP Service Mapping (c) . . . . . . . . . . . . . . . 19
4.1.4. IP Service Composition (d) . . . . . . . . . . . . . 20 4.1.4. IP Service Composition (d) . . . . . . . . . . . . . 19
4.1.5. IP Service Provision (e) . . . . . . . . . . . . . . 20 4.1.5. IP Service Provision (e) . . . . . . . . . . . . . . 20
4.1.6. Performance Measurement and Alarm Telemetry (f) . . . 20 4.1.6. Performance Measurement and Alarm Telemetry (g) . . . 20
4.1.7. IP Service to TE Mapping (g) . . . . . . . . . . . . 20 4.1.7. IP Service to TE Mapping (f) . . . . . . . . . . . . 20
4.1.8. Path Management (h) . . . . . . . . . . . . . . . . . 21 4.1.8. Path Management (h) . . . . . . . . . . . . . . . . . 21
4.1.9. TE Resource Exposure (i) . . . . . . . . . . . . . . 21 4.1.9. TE Resource Exposure (i) . . . . . . . . . . . . . . 21
5. Sample Service Coordination via YANG Moodules . . . . . . . . 22 5. Sample Service Coordination via YANG Moodules . . . . . . . . 22
5.1. L3VPN Service Delivery via Coordinated YANG Modules . . . 22 5.1. L3VPN Service Delivery via Coordinated YANG Modules . . . 22
5.2. 5G Transport Service Delivery via Coordinated YANG 5.2. 5G Transport Service Delivery via Coordinated YANG
Modules . . . . . . . . . . . . . . . . . . . . . . . . . 22 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Modules Usage in Automated Virtualized Network Environment: 6. Modules Usage in Automated Virtualized Network Environment:
Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 24 Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Network-initiated Resource Creation . . . . . . . . . . . 24 6.1. Network-initiated Resource Creation . . . . . . . . . . . 24
6.2. Customer-initiated Dynamic Resource Creation . . . . . . 26 6.2. Customer-initiated Dynamic Resource Creation . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. Informative References . . . . . . . . . . . . . . . . . . . 29 11. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The service management system usually comprises service activation/ The service management system usually comprises service activation/
provision and service enforcement. Traditional service delivery work provision and service operation. Current service delivery
flow process, from customer order to the actual service provision, procedures, from the processing of customer's requirements and order
typically involves input data sequentially into multiple OSS/BSS to service delivery and operation, typically assume the manipulation
applications managed by different departments. Many of these of data sequentially into multiple OSS/BSS applications that may be
applications are custom built over the years and operating in a silo managed by different departments within the service provider's
mode. The lack of standard data input/output also causes many organization (e.g., billing factory, design factory, network
challenges in system integration and results in manual data entry. operation center, etc.). In addition, many of these applications
Secondly, traditional service fulfillment lack a programmatic and have been developed in-house over the years and operating in a silo
standards-based way of writing configurations to any network device mode. The lack of standard data input/output (i.e., data model) also
and has slow response to the network changes and doesn't provide real raises many challenges in system integration and often results in
time monitoring capability in high frequency and in high throughput manual configuration tasks. Secondly, many current service
on the current state of networking. Therefore, model-driven network fulfillment might not support real time streaming telemetry
management becomes crucial to address these challenges. capability in high frequency and in high throughput on the current
state of networking and therefore have slow response to the network
changes. Software Defined Networking (SDN) becomes crucial to
address these challenges.
For years, the IETF has been driving the industry transition from an Software-Defined Networking techniques [RFC7149] are meant to
overloaded Software Defined Networking (SDN) buzzword to focus on automate the overall service delivery procedures and typically rely
specific areas such as modeling-driven network management. [RFC7149] upon (standard) data models that are used to not only reflect service
provides a first tentative to rationalize that space by identifying providers'savoir-faire but also to dynamically instantiate and
concrete technical domains that need to be considered and for which enforce a set of (service-inferred) policies that best accommodate
solutions can be provided: what has been (contractually) defined (and possibly negotiated) with
the customer. [RFC7149] provides a first tentative to rationalize
that service provider's view on the SDN space by identifying concrete
technical domains that need to be considered and for which solutions
can be provided:
o Techniques for the dynamic discovery of topology, devices, and o Techniques for the dynamic discovery of topology, devices, and
capabilities, along with relevant information and data models that capabilities, along with relevant information and data models that
are meant to precisely document such topology, devices, and their are meant to precisely document such topology, devices, and their
capabilities. capabilities.
o Techniques for exposing network services [RFC8309] and their o Techniques for exposing network services [RFC8309] and their
characteristics. characteristics.
o Techniques used by service-requirement-derived dynamic resource o Techniques used by service-requirement-derived dynamic resource
allocation and policy enforcement schemes, so that networks can be allocation and policy enforcement schemes, so that networks can be
programmed accordingly. programmed accordingly.
o Dynamic feedback mechanisms that are meant to assess how o Dynamic feedback mechanisms that are meant to assess how
efficiently a given policy (or a set thereof) is enforced from a efficiently a given policy (or a set thereof) is enforced from a
service fulfillment and assurance perspective. service fulfillment and assurance perspective.
Models are key for each of these technical items. Automation is an Models are key for each of these technical items. Service and
important step to improve the agility of network operations and network management automation is an important step to improve the
infrastructure. agility of network operations and infrastructures.
In the later development, as described in [RFC8199], YANG module
developers have taken both top-down and bottom-up approaches to
develop modules and establish mapping between network technology and
customer requirements on the top or abstracting common construct from
various network technologies. At the time of writing this document
(2019), we see the large number of data models including
configuration models and service models developed or under
development in IETF covering much of networking protocols and
techniques. In addition, how these models work together to fully
configure a device, manage a set of devices involved in a service, or
even provide a service aren't developed yet in IETF.
This document takes both bottom up approach and top down approach to YANG module developers have taken both top-down and bottom-up
provide an architectural framework for network management automation, approaches to develop modules [RFC8199] and to establish a mapping
with a focus on network virtualization environment. between network technology and customer requirements on the top or
abstracting common construct from various network technologies on the
bottom. At the time of writing this document (2019), there are many
data models including configuration and service models that have been
specified or are being specified by the IETF. They cover many of the
networking protocols and techniques. However, how these models work
together to configure a device, manage a set of devices involved in a
service, or even provide a service is something that is not currently
documented either within the IETF or other SDOs (e.g., MEF).
This document also describes specific YANG modules needed to realize This document provides a framework that describes and discusses an
connectivity services and investigates how top down built model architecture for service and network management automation that takes
(e.g., customer-facing data models) interact with bottom up built advantage of YANG modeling technologies and investigates how
model (network resource-facing data models) in the context of service different layer YANG data models interact with each other (e.g.,
delivery and assurance. service mapping, model composing) in the context of service delivery
and fulfillment. This framework is drawn from a network provider
perspective irrespective of the origin of a data module andcan
accommodate even modules that are developed outside the IETF.
The document identifies a comprehensive list of modules to exemplify The document also identifies a list of modules and use cases to
the proposed approach, but the document does not claim to be exemplify the proposed approach, but it does not claim to be
exhaustive. exhaustive.
It is not the intent of this document to provide an inventory of It is not the intent of this document to provide an inventory of
tools and mechanisms used in specific network and service management tools and mechanisms used in specific network and service management
domains; such inventory can be found in documents such as [RFC7276]. domains; such inventory can be found in documents such as [RFC7276].
2. IETF YANG Modules: An Overview 1.1. Terminology
Figure 1 provides an overview of various macro-functional blocks to The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
which belong the various IETF-defined modules. "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
<<Network Service and Resource Models>> The following terms are defined in [RFC8309][RFC8199] and are not
+-----------------------------------------------------------------------+ redefined here:
| << Network Service Models>> |
| +----------------+ +----------------+ +-------------+ +-------------+ |
| | L3SM | | L2SM | | TEAS VN | | L1CSM | |
| | Service Model | | Service Model | |Service Model| |Service Model| |
| +----------------+ +----------------+ +-------------+ +-------------+ |
|------------------------------------------------------------------- |
| << Network Resource Models >> |
| +------------+ +-------+ +----------------+ +------------+ |
| |Network Topo| | Tunnel| |Path Computation| |FM/PM/Alarm | |
| | Models | | Models| | API Models | | OAM Models| |
| +------------+ +-------+ +----------------+ +------------+ |
+-----------------------------------------------------------------------+
--------------------------------------------------------------------
<Network Element Models>>
+-----------------------------------------------------------------------+
| <<Composition Models>> |
| +-------------+ +---------------+ +----------------+ |
| |Device Model | |Logical Network| |Network Instance| |
| | | |Element Model | | Model | |
| +-------------+ +---------------+ +----------------+ |
|---------------------------------------------------------------------- |
| << Component Models>> |
|+---------++---------++---------++----------++---------++---------+ |
|| || || ||Common || || OAM: | |
|| Routing ||Transport|| Policy ||(interface||Multicast|| | |
||(e.g.,BGP||(e.g., ||(e.g, ACL||multicast || (IGMP ||FM,PM, | |
|| OSPF) || MPLS) || QoS) || IP, ... )|| MLD,...)||Alarm | ...|
|+---------++---------++---------++----------++---------++---------+ |
+-----------------------------------------------------------------------+
Figure 1: An overview of IETF YANG Modules o Network Operator
2.1. Network Service and Resource Models o Customer
Service and Network Resource modules define what the o Service
"service"/"resource" is. These modules can be classified into two
categories:
1. Network Service Models (Section 2.1.1) o Data Model
2. Network Resource Models (Section 2.1.2) o Service Model
o Customer Service Model
o Service Delivery Model
o Network Service Module
o Network Element Module
The following terms are defined in this document as follows:
Network Resource Module: The Network Resource Module is used by a
network operator to allocate the resource(e.g., tunnel resource,
topology resource) for the service or schedule the resource to
meet the service requirements define in the Service Model.
2. Layered YANG Modules: An Overview
Figure 1 provides an overview of various macro-functional blocks at
different levels that articulate the various YANG data modules. In
this figure, we use IETF defined YANG data model as an example
Models.
<<Network Service Models>>
+-------------------------------------------------------------------------+
| << Network Service Models>> |
| +----------------+ +----------------+ |
| | L3SM | | L2SM | |
| | Service Model | | Service Model | ............. |
| +----------------+ +----------------+ |
+------------------------------------------------------------------------ +
<<Network Resource Models>>
+------------------------------------------------------------------------ +
| << Network Resource Models >> |
| +------------+ +-------+ +----------------+ +------------+ |
| |Network Topo| | Tunnel| |Path Computation| |FM/PM/Alarm | |
| | Models | | Models| | API Models | | OAM Models|... |
| +------------+ +-------+ +----------------+ +------------+ |
+-------------------------------------------------------------------------+
--------------------------------------------------------------------------
<Network Element Models>>
+-------------------------------------------------------------------------+
| <<Composition Models>> |
| +-------------+ +---------------+ +----------------+ |
| |Device Model | |Logical Network| |Network Instance| |
| | | |Element Model | | Model | ... |
| +-------------+ +---------------+ +----------------+ |
|-------------------------------------------------------------------------|
| << Function Models>> |
|+---------++---------++---------++----------++---------++---------+ |
|| || || ||Common || || OAM: | |
|| Routing ||Transport|| Policy ||(interface||Multicast|| | |
||(e.g.,BGP||(e.g., ||(e.g, ACL||multicast || (IGMP ||FM,PM, | |
|| OSPF) || MPLS) || QoS) || IP, ... )|| MLD,...)||Alarm | ... |
|+---------++---------++---------++----------++---------++---------+ |
+-------------------------------------------------------------------------+
Figure 1: An overview of Layered YANG Modules
2.1. Network Service and Resource Models
2.1.1. Network Service Models: Definition and Samples 2.1.1. Network Service Models: Definition and Samples
As described in [RFC8309], the service is some form of connectivity As described in [RFC8309], the service is "some form of connectivity
between customer sites and the Internet and/or between customer sites between customer sites and the Internet and/or between customer sites
across the network operator's network and across the Internet. More across the network operator's network and across the Internet". More
concretely, an IP connectivity service can be defined as the IP concretely, an IP connectivity service can be defined as the IP
transfer capability characterized by a (Source Nets, Destination transfer capability characterized by a (Source Nets, Destination
Nets, Guarantees, Scope) tuple where "Source Nets" is a group of Nets, Guarantees, Scope) tuple where "Source Nets" is a group of
unicast IP addresses, "Destination Nets" is a group of IP unicast unicast IP addresses, "Destination Nets" is a group of IP unicast
and/or multicast addresses, and "Guarantees" reflects the guarantees and/or multicast addresses, and "Guarantees" reflects the guarantees
(expressed in terms of Quality Of Service (QoS), performance, and (expressed in terms of Quality Of Service (QoS), performance, and
availability, for example) to properly forward traffic to the said availability, for example) to properly forward traffic to the said
"Destination" [RFC7297]. "Destination" [RFC7297].
For example, For example:
o L3SM model [RFC8299] defines the L3VPN service ordered by a o L3SM model [RFC8299] defines the L3VPN service ordered by a
customer from a network operator. customer from a network operator.
o L2SM model [RFC8466] defines the L2VPN service ordered by a o L2SM model [RFC8466] defines the L2VPN service ordered by a
customer from a network operator. customer from a network operator.
o L1CSM model [I-D.ietf-ccamp-l1csm-yang] defines a YANG module for o VN model [I-D.ietf-teas-actn-vn-yang]provides a YANG data model
Layer 1 Connectivity Service Model (L1CSM). generally applicable to any mode of Virtual Network (VN)
operation.
o TEAS VN model [I-D.ietf-teas-actn-vn-yang] defines a YANG module
for the Abstraction and Control of Traffic Engineered (TE)
networks (ACTN) Virtual Network Service (VNS) operation. Unlike
L3SM model, ACTN model can also be used as operator-facing model,
e.g., establish interconnections between L3VPN sites across
multiple ASes.
o [I-D.ietf-teas-te-service-mapping-yang] defines a YANG module to
map service model (e.g., L3SM) and Traffic Engineering model
(e.g., TE Tunnel or the ACTN model). This model is applicable to
the operation's need for a control and management of VPN services
with TE tunnel support and principally used to allow monitoring
and diagnostic of the management systems to assess how the service
requests are mapped onto underlying network resources and TE
models.
o Composed VPN model [I-D.evenwu-opsawg-yang-composed-vpn] defines a
YANG module that can be used by a network operator to configure a
VPN service in multiple administrative domain environment
consisting of L2VPN or L3VPN or a mixture of the two. This model
provides an abstracted view of VPN service configuration
components at different layer.
2.1.2. Network Resource Models 2.1.2. Network Resource Models: Definitions and Samples
Figure 2 depicts a set of Network resource YANG modules such as Figure 2 depicts a set of Network resource YANG modules such as
topology models or tunnel models: topology models or tunnel models:
| | | |
Topo YANG modules | Tunnel YANG modules |Resource NM Tool Topo YANG modules | Tunnel YANG modules |Resource NM Tool
------------------------------------------------|-- ------------ ------------------------------------------------|-- ------------
+------------+ | | +------------+ | |
|Network Top | | +------+ +-----------+ | +-------+ |Network Top | | +------+ +-----------+ | +-------+
| Model | | |Other | | TE Tunnel | | | LIME | | Model | | |Other | | TE Tunnel | | | LIME |
skipping to change at page 7, line 27 skipping to change at page 8, line 22
| +--------+ | +------+ | | |/PM/FM | | +--------+ | +------+ | | |/PM/FM |
|---+Svc Topo| | +--------+-+--------+ |Model | |---+Svc Topo| | +--------+-+--------+ |Model |
| +--------+ | +----+---+ +---+----+ +-+-----+ +-------+ | +--------+ | +----+---+ +---+----+ +-+-----+ +-------+
| +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | +--------+ | +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | +--------+
|---+L2 Topo | | | Tunnel | | Tunnel | |Tunnel | | Alarm | |---+L2 Topo | | | Tunnel | | Tunnel | |Tunnel | | Alarm |
| +--------+ | +--------+ +--------+ +-------+ | Model | | +--------+ | +--------+ +--------+ +-------+ | Model |
| +--------+ | +--------+ | +--------+ | +--------+
|---+TE Topo | | +-----------+ |---+TE Topo | | +-----------+
| +--------+ | |Path | | +--------+ | |Path |
| +--------+ | |Computation| | +--------+ | |Computation|
+---+L3 Topo | |API Model | +---+L3 Topo | | |API Model |
+----|---+ +-----------+ +--------+ | +-----------+
+---------+---------+
| | |
+---|---+ +--|---+ +---|-+
|SR Topo| |SR TE | |L3 TE|
| Model | | Topo | |Topo |
+-------+ +------+ +-----+
Figure 2: Sample Resource Facing Network Models Figure 2: Sample Resource Facing Network Models
Topology YANG modules: Topology YANG module Examples:
o Network Topology Models: [RFC8345] defines a base model for o Network Topology Models: [RFC8345] defines a base model for
network topology and inventories. Network topology data include network topology and inventories. Network topology data include
link resource, node resource, and terminate-point resources. link resource, node resource, and terminate-point resources.
o TE Topology Models: [I.D-ietf-teas-yang-te-topo] defines a data o TE Topology Models: [I.D-ietf-teas-yang-te-topo] defines a data
model for representing and manipulating TE topologies. model for representing and manipulating TE topologies.
This module is extended from network topology model defined in This module is extended from network topology model defined in
[RFC8345] with TE topologies specifics. This model contains [RFC8345] with TE topologies specifics. This model contains
technology agnostic TE Topology building blocks that can be technology-agnostic TE Topology building blocks that can be
augmented and used by other technology-specific TE Topology augmented and used by other technology-specific TE Topology
models. models.
o L3 Topology Models o L3 Topology Models
[RFC8346] defines a data model for representing and manipulating [RFC8346] defines a data model for representing and manipulating
L3 Topologies. This model is extended from the network topology L3 Topologies. This model is extended from the network topology
model defined in [RFC8345] with L3 topologies specifics. model defined in [RFC8345] with L3 topologies specifics.
o L2 Topology Models o L2 Topology Models
[I.D-ietf-i2rs-yang-l2-topology] defines a data model for [I.D-ietf-i2rs-yang-l2-topology] defines a data model for
representing and manipulating L2 Topologies. This model is representing and manipulating L2 Topologies. This model is
extended from the network topology model defined in [RFC8345] with extended from the network topology model defined in [RFC8345] with
L2 topologies specifics. L2 topologies specifics.
o L3 TE Topology Models Tunnel YANG module Examples:
When traffic engineering is enabled on a layer 3 network topology,
there will be a corresponding TE topology. [I.D-ietf-teas-yang-
l3-te-topo] defines data models for layer 3 traffic engineering
topologies. Two data models are defined, one is layer 3 TE
topology model, the other is packet switching TE topology model.
Layer 3 TE topology model is extended from Layer 3 topology model.
Packet switching TE topology model is extended from TE topology
model.
o SR TE Topology Models
[I-D.ietf-teas-yang-sr-te-topo] defines a YANG module for Segment
Routing (SR) topology and Segment Routing (SR) traffic engineering
(TE) topology. Two models are defined, one is SR topology model,
the other is SR TE topology model, SR topology model is extended
from L3 Topology model. SR TE topology model is extended from
both SR Topology model and L3 TE topology model.
o SF Aware TE Topology YANG module
[I-D. ietf-teas-sf-aware-topo-model] defines a YANG module for TE
network topologies that are network service and function aware.
o Optical Transport Topology Models:
* OTN Transport Topology Model: [I-D.ietf-ccamp-otn-topo-yang]
defines a YANG module to describe the topologies of an Optical
Transport Network (OTN).
* WSON Transport Topology Model: [I-D.ietf-ccamp-wson-yang]
defines a YANG module for the routing and wavelength assignment
(RWA) Traffic Engineering (TE) topology in wavelength switched
optical networks (WSONs).
* Flex-Grid Transport Topology Model: [I-D.ietf-ccamp-flexigrid-
yang] defines a YANG module for flexi-grid objects in the
dynamic optical network, including the nodes, transponders and
links between them, as well as how such links interconnect
nodes and transponders.
Tunnel YANG modules:
o Tunnel identities [I-D.ietf-softwire-iftunnel] to ease o Tunnel identities [I-D.ietf-softwire-iftunnel] to ease
manipulating extensions to specific tunnels. manipulating extensions to specific tunnels.
o TE Tunnel Model o TE Tunnel Model
[I.D-ietf-teas-yang-te] defines a YANG module for the [I.D-ietf-teas-yang-te] defines a YANG module for the
configuration and management of TE interfaces, tunnels and LSPs. configuration and management of TE interfaces, tunnels and LSPs.
o SR TE Tunnel Model o SR TE Tunnel Model
skipping to change at page 9, line 39 skipping to change at page 9, line 35
[I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE
model(s) and defines a YANG module for MPLS TE configurations, model(s) and defines a YANG module for MPLS TE configurations,
state, RPC and notifications. state, RPC and notifications.
o RSVP-TE MPLS Model o RSVP-TE MPLS Model
[I.D-ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module [I.D-ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module
with parameters to configure and manage signaling of MPLS RSVP-TE with parameters to configure and manage signaling of MPLS RSVP-TE
LSPs. LSPs.
o Optical Transport Tunnel Models:
* Flexigrid Media Channel Tunnel Models: [I-D.ccamp-flexigrid-
media-channel-yang] defines a YANG module for the flexi-grid
media-channel. This YANG module defines the whole path from a
source transponder or node to the destination through a number
of intermediate nodes in the flexi-grid network.
* WSON Tunnel Model: [I-D.ccamp-wson-tunnel-model] defines a YANG
module for WSON tunnel model.
* OTN Tunnel Model: [I-D. ietf-ccamp-otn-tunnel-model]defines a
YANG module for OTN tunnel Model.
Resource NM Tool Models: Resource NM Tool Models:
o Path Computation API Model o Path Computation API Model
[I.D-ietf-teas-path-computation] YANG module for a stateless RPC [I.D-ietf-teas-path-computation] YANG module for a stateless RPC
which complements the stateful solution defined in [I.D-ietf-teas- which complements the stateful solution defined in [I.D-ietf-teas-
yang-te]. yang-te].
o OAM Models (including Fault Management (FM) and Performance o OAM Models (including Fault Management (FM) and Performance
Monitoring) Monitoring)
skipping to change at page 10, line 33 skipping to change at page 10, line 16
Alarm monitoring is a fundamental part of monitoring the network. Alarm monitoring is a fundamental part of monitoring the network.
Raw alarms from devices do not always tell the status of the Raw alarms from devices do not always tell the status of the
network services or necessarily point to the root cause. [I.D- network services or necessarily point to the root cause. [I.D-
ietf-ccamp-alarm-module]defines a YANG module for alarm ietf-ccamp-alarm-module]defines a YANG module for alarm
management. management.
o Generic Policy Model o Generic Policy Model
The Simplified Use of Policy Abstractions (SUPA) policy-based The Simplified Use of Policy Abstractions (SUPA) policy-based
management framework [RFC8328] defines base YANG modules to encode management framework [RFC8328] defines base YANG modules
policy. These models point to device-, technology-, and service- [I-D.ietf-supa-generic-policy-data-model]to encode policy. These
specific YANG modules developed elsewhere. Policy rules within an models point to device-, technology-, and service-specific YANG
operator's environment can be used to express high-level, possibly modules developed elsewhere. Policy rules within an operator's
network-wide, policies to a network management function (within a environment can be used to express high-level, possibly network-
wide, policies to a network management function (within a
controller, an orchestrator, or a network element). The network controller, an orchestrator, or a network element). The network
management function can then control the configuration and/or management function can then control the configuration and/or
monitoring of network elements and services. This document monitoring of network elements and services. This document
describes the SUPA basic framework, its elements, and interfaces. describes the SUPA basic framework, its elements, and interfaces.
2.2. Network Element Models 2.2. Network Element Models: Definitions and Samples
Network Element models (Figure 3) are used to describe how a service Network Element models (Figure 3) are used to describe how a service
can be implemented by activating and tweaking a set of functions can be implemented by activating and tweaking a set of functions
(enabled in one or multiple devices) that are involved in the service (enabled in one or multiple devices, or hosted in cloud
delivery. infrastructures) that are involved in the service delivery. The
following figure uses IETF defined models as an example.
+----------------+ +----------------+
--|Device Model | --|Device Model |
| +----------------+ | +----------------+
| +------------------+ | +------------------+
+---------------+ | |Logical Network | +---------------+ | |Logical Network |
| | --| Element Mode | | | --| Element Mode |
| Architecture | | +------------------+ | Architecture | | +------------------+
| | | +----------------------+ | | | +----------------------+
+-------+-------+ --|Network Instance Mode | +-------+-------+ --|Network Instance Mode |
skipping to change at page 11, line 44 skipping to change at page 11, line 44
| +-------+ | +-------+
--|VRRP | --|VRRP |
| +-------+ | +-------+
--|SR/SRv6| --|SR/SRv6|
| +-------+ | +-------+
--|ISIS-SR| --|ISIS-SR|
| +-------+ | +-------+
--|OSPF-SR| --|OSPF-SR|
+-------+ +-------+
Figure 3: Network Element Modules Figure 3: Network Element Modules Overview
2.2.1. Model Composition 2.2.1. Model Composition
o Device Model o Device Model
[I.D-ietf-rtgwg-device-model] presents an approach for organizing [I.D-ietf-rtgwg-device-model] presents an approach for organizing
YANG modules in a comprehensive logical structure that may be used YANG modules in a comprehensive logical structure that may be used
to configure and operate network devices. The structure is itself to configure and operate network devices. The structure is itself
represented as an example YANG module, with all of the related represented as an example YANG module, with all of the related
component models logically organized in a way that is component models logically organized in a way that is
skipping to change at page 12, line 38 skipping to change at page 12, line 38
of the YANG data modeling language. As a result, the same YANG of the YANG data modeling language. As a result, the same YANG
module can be combined with various sets of other modules and thus module can be combined with various sets of other modules and thus
form a data model that is tailored to meet the requirements of a form a data model that is tailored to meet the requirements of a
specific use case. [RFC8528] defines a mechanism, denoted schema specific use case. [RFC8528] defines a mechanism, denoted schema
mount, that allows for mounting one data model consisting of any mount, that allows for mounting one data model consisting of any
number of YANG modules at a specified location of another (parent) number of YANG modules at a specified location of another (parent)
schema. schema.
That capability does not cover design time. That capability does not cover design time.
2.2.2. Protocol/Function Configuration Models 2.2.2. Protocol/Function Configuration Models: Definitions and Samples
BGP: [I-D.ietf-idr-bgp-yang-model] defines a YANG module for BGP: [I-D.ietf-idr-bgp-yang-model] defines a YANG module for
configuring and managing BGP, including protocol, policy, configuring and managing BGP, including protocol, policy,
and operational aspects based on data center, carrier and and operational aspects based on data center, carrier and
content provider operational requirements. content provider operational requirements.
MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS
which serves as a base framework for configuring and which serves as a base framework for configuring and
managing an MPLS switching subsystem. It is expected that managing an MPLS switching subsystem. It is expected that
other MPLS technology YANG modules (e.g. MPLS LSP Static, other MPLS technology YANG modules (e.g. MPLS LSP Static,
skipping to change at page 15, line 16 skipping to change at page 15, line 16
Platforms (LMAPs). Platforms (LMAPs).
3. Architectural Concepts 3. Architectural Concepts
3.1. Data Models: Layering and Representation 3.1. Data Models: Layering and Representation
As described in [RFC8199], layering of modules allows for better As described in [RFC8199], layering of modules allows for better
reusability of lower-layer modules by higher-level modules while reusability of lower-layer modules by higher-level modules while
limiting duplication of features across layers. limiting duplication of features across layers.
The IETF has developed a number of service level, network level and The data modules developed by IETF can be classified into service
device level modules. Different service level modules may rely on level, network level and device level modules. Different service
the same set of network level or device level modules. Service level level modules may rely on the same set of network level or device
modules usually follow top down approach and are mostly customer- level modules. Service level modules usually follow top down
facing models providing a common model construct for higher level approach and are mostly customer-facing modules providing a common
network services, which can be further mapped to network technology- model construct for higher level network services, which can be
specific models at lower layer. further mapped to network technology-specific modules at lower layer.
Network level modules mostly follow bottom up approach and are mainly Network level modules mostly follow a bottom-up approach and are
network resource-facing model and describe various aspects of a mainly network resource-facing modules and describe various aspects
network infrastructure, including devices and their subsystems, and of a network infrastructure, including devices and their subsystems,
relevant protocols operating at the link and network layers across and relevant protocols operating at the link and network layers
multiple devices (e.g., Network topology and TE Tunnel modules). across multiple devices (e.g., Network topology and TE Tunnel
modules).
Device level modules usually follow bottom up approach and are mostly Device level modules usually follow a bottom-up approach and are
technology-specific modules used to realize a service. mostly technology-specific modules used to realize a service.
3.2. Service Activation, Provision, and Invocation Automation 3.2. Automation of service delivery procedures
To provide more adaptive (a.k.a., agile) service offerings, Service To dynamically provide service offerings, Service level modules can
level modules can be used by an operator to structure how it be used by an operator. One or more monolithic Service modules can
communicates with the customer. One or more monolithic Service be used in the context of a composite service activation request
modules can be used in teh context of a composite service activation (e.g., delivery of a caching infrastructure over a VPN). Such
requets (e.g., deliver of a caching infrastructure over a VPN). Such modules are used to feed a decision-making intelligence to adequately
modules are used to feed a decision-making intelligence to rapidly accommodate customer's needs.
accommodate customer' needs.
Also, such modules may be used jointly with services that require Also, such modules may be used jointly with services that require
dynamic service invocation. A typical example is the service modules dynamic invocation. An example is provided by the service modules
defined by the DOTS WG to dynamically trigger requests to handle DDoS defined by the DOTS WG to dynamically trigger requests to handle DDoS
attacks [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel]. attacks [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel].
Network level module can be translated from service level module and Network level modules can be derived from service level modules and
used to provision, monitor, instantiate the service and provide life used to provision, monitor, instantiate the service and provide
cycle management of network resource,e.g., expose network resource to lifecycle management of network resources, e.g., expose network
the customer or operators to provide service assurance on network resources to customers or operators to provide service fulfillment
service and allow customer or operator to re-optimize the network and assurance and allow customers or operators to dynamically adjust
based on service requirements described in the service level model. the network resources based on service requirements as described in
service level modules and the current network performance information
described in the Northbound telemetry modules.
3.3. Service Enforcement Automation 3.3. Service Fullfillment Automation
To provide network management automation, Device level modules To operate the service, Device level modules derived from Service
translated from Service level modules or Network level modules can be level modules or Network level modules can be used to provision each
used to provision each involved network function/device and operate involved network function/device with the proper configuration
the network based on service requirements described in the Service information, and operate the network based on service requirements as
level module(s). described in the Service level module(s).
In addition, the operational state including configuration that is in In addition, the operational state including configuration that is in
effect and status together with statistics should be exposed to upper effect together with statistics should be exposed to upper layers to
layers to provide better network visibility (and assess to what provide better network visibility (and assess to what extent the
extent the translated low level modules are honoring the upper level derived low level modules are consistent with the upper level
inputs). Note that it is important is to stitch telemetry data with inputs). Note that it is important to relate telemetry data with
configuration data to provide closed loop life cycle management on configuration data to used closed loops at the different stages of
the network as a system (including device-centric views). service delivery, from resource allocation to service operation, in
particular.
3.4. Modules Decomposition and Composition 3.4. Module Decomposition and Composition
To support top-down service delivery, the service parameters captured To support top-down service delivery, the service parameters captured
in service level module(s) need to be decomposed into a set of in service level module(s) need to be decomposed into a set of
configuration parameters specific to one or more technologies; these configuration parameters that may be specific to one or more
technology-specific parameters will be grouped together per technologies; these technology-specific parameters will be grouped
technology to define technology-specific device level model or together per technique to define technology-specific device level
network level model. modules or network level modules.
In addition, these technology-specific device level models can be In addition, these technology-specific device level models can be
further assembled together to provision each involved network further assembled together to provision each involved network
function/device or each involved administrative domain to improve function/device or each involved administrative domain to improve
provision efficiency. provision efficiency.
For example, IETF rtgwg and netmod working groups have already been For example, IETF rtgwg and netmod working groups have already been
tasked to define model composition mechanism (i.e., Schema Mount tasked to define a model composition mechanism (i.e., Schema Mount
mechanism) and relevant grouping base models such as network instance mechanism) and relevant grouping base models such as network instance
model, logical network element model. The model composition model, logical network element model . The model composition
mechanism can be used to assembler different model together while mechanism can be used to assembler different model together while
grouping based models can be used to setup and administrate both grouping based models can be used to setup and administrate both
virtualized system and physical system. virtualized system and physical systems .
IETF also developed YANG catalog tool to manage metadata around IETF- IETF also developed a YANG catalog tool to manage metadata around
defined modules; it allows both YANG developers and operators to IETF- defined modules; it allows both YANG developers and operators
discover appropriate YANG modules that may be used to automate to discover appropriate YANG modules that may be used to automate
services operations. This YANG catalog tools can be used to select services operations. This YANG tool catalog tools can be used to
appropriate models for grouping purposes or even to identify gaps. select appropriate models for grouping purposes or even to identify
gaps.
4. Architecture Overview 4. Architecture Overview
The architectural considerations and conclusions described in the The architectural considerations described in the previous section
previous section lead to the architecture described in this section lead to the architecture described in this section and illustrated in
and illustrated in Figure 4. Figure 4.
The interfaces and interactions shown in the figure and labeled (a) The interfaces and interactions shown in the figure and labeled (a)
through (j) are further described in Section 4.1. through (j) are further described in Section 4.1.
+-----------------+ ---------------- +-----------------+ ----------------
|Service Requester| Service Level| |Service Requester| Service Level|
+-----------------+ | +-----------------+ |
+-------------|--------------------------------------------------+ | +-------------|--------------------------------------------------+ |
| +--------V---------+ +------------+ | | | | +----------------------+ | |
| | Service Exposure |----------------- IP Service | | | | | | | | |
| +-------(b)--------+ | Mapping | | | | +--------V---------+ | +------------+ +---+--+| |
| | +--(c)-|-----+ | | | | Service Exposure |-------------V--- IP Service | |Alarm/|| |
| | | ---------------- | +-------(b)--------+ | Mapping | | PM || |
| |---------->|<----------------+ | Network Level| | | +--(c)-|-----+ +-(g) -+| |
| | | | |
| +---------->|<----------------+ +------------+ |
| | | | | -------------+--
| | | | | Network Level|
| | +--------V---------+ | | | | | | +--------V---------+ | | | |
| | | IP Service to TE | +------->|<-----------+ | | | | | IP Service to TE | +------->|<-----------+ | |
| | | Mapping | | | | | | | | | | Mapping | | | | | | |
| | +-------(f)--------+ | | +------|-----+ | | | | | +-------(f)--------+ | | +------|-----+ | | |
| | | +-----|-----+| | IP Service | +---+--+| | | | | +-----|-----+| | IP Service | +---+--+| |
| | +--------V---------+ |TE Resource|| | Composition| |Alarm/|| | | | +--------V---------+ |TE Resource|| | Composition| |Alarm/|| |
| | | TE Path | | Exposure || +--(d)-|-----+ | PM || | | | | TE Path | | Exposure || +--(d)-|-----+ | PM || |
| | | Management +----(h)----+| | +-(g) -+| | | | | Management +----(h)----+| | +-(g) -+| |
| | +-------(e)--------+ | | +------|------+ | | | | +-------(e)--------+ | | +------|------+ | |
| | | | | | IP Service | | | | | | | | | | IP Service | | | |
| | +-----------------+ | | Provision +-----| | | | | +-----------------+ | | Provision +-----| | |
| | | +-(e)--|------+ | | | | | +-(e)--|------+ | |
| | +-----------++ | | | | +-----------++ | |
| | | Resource | | | | | | Resource | | |
| | | Collection | | | | | | Collection | | |
| |------------------------+&Abstraction| | | | |------------------------+&Abstraction| | |
| +----(a)-----+ ---------------- | +----(a)-----+ ----------------
+----------------------------------------------------------------+ +----------------------------------------------------------------+
Figure 4: Service and Network Management Automation with YANG Figure 4: Service and Network Management Automation with YANG
4.1. End-to-End Service Delivery and Service Assurance Procedure 4.1. End-to-End Service Delivery and Service Assurance Procedure
4.1.1. Resource Collection and Abstraction (a) 4.1.1. Resource Collection and Abstraction (a)
Network Resource such as links, nodes, or terminate-point resources Network Resources such as links, nodes, or terminate-point resources
can be collected from the network and aggregated or abstracted to the can be collected from the network and aggregated or abstracted to the
management system. Periodic fetching of data is not an adequate management system. Periodic fetching of data is not an adequate
solution for applications requiring frequent or prompt updates of solution for applications requiring frequent or prompt updates of
network resource. Applying polling-based solutions to retrieve network resources. Applying polling-based solutions to retrieve
network resource also imposes a load on networks, devices, and network resource information impacts networks, devices, and
applications. These limitations can be addressed by including applications' loads. These limitations can be addressed by including
generic object subscription mechanisms within network elements. generic object subscription mechanisms within network elements.
These resources can be modelled using network topology model, L3 These resources can be modelled using network topology models, L3
topology model, L2 topology model, TE topology model, L3 TE topology topology model, L2 topology model, TE topology model, L3 TE topology
model, SR TE topology models at different layers. model, SR TE topology models at different layers.
In some cases, there may have multiple overlay topologies built on In some cases, there may be multiple overlay topologies built on top
top of the same underlay topology, and the underlay topology can be of the same underlay topology, and the underlay topology can also be
also built from one or more lower layer underlay topology. built from one or more lower layer underlay topologies. The network
resources and management objects in these multi-layer topologies are
In some cases, there may have multiple overlay topologies built on not recommended to be exposed to customers, but rather exposed to the
top of the same underlay topology, and the underlay topology can be management system for IP service mapping and Path Management.
also built from one or more lower layer underlay topology. The
network resources and management objects in these multi-layer
topologies are not recommended to be exposed to customers who (will)
order the service from the management system, instead it will be
exposed to the management system for IP service mapping and TE path
Management.
The abstract view is likely to be technology-agnostic.
4.1.2. Service Exposure & Abstraction (b) 4.1.2. Service Exposure & Abstraction (b)
Service exposure & abstraction is used to capture services offered to Service exposure & abstraction is used to capture services offered to
customers. customers.
Service abstraction can be used by a customer to request a service Service abstraction can be used by a customer to request a service
(ordering and order handling). One typical example is that a (ordering and order handling). One typical example is that a
customer can use L3SM service model to request L3VPN service by customer can use a L3SM service model to request L3VPN service by
providing the abstract technical characterization of the intended providing the abstract technical characterization of the intended
service. Such L3VPN service describes various aspects of network service.
infrastructure, including devices and their subsystems, and relevant
protocols operating at the link and network layers across multiple
device. The L3SM service model can be used to interact with the
network infrastructure, e.g., configure sites, decide QoS parameters
to be applied to end to end connectivity between VPN sites, select
PEs, CEs, etc.
Service catalogs can be created to expose the various services and Service catalogs can be created to expose the various services and
the information needed to invoke/order a given service. the information needed to invoke/order a given service.
YANG modules can be grouped into various service bundles; each YANG modules can be grouped into various service bundles; each
service bundle is corresponding to a set of YANG modules that have service bundle corresponds to a set of YANG modules that have been
been released or published. Then, a mapping can be established released or published. Then, a mapping can be established between
between service abstraction at higher layer and service bundle or a service abstraction at higher layer and service bundle or a set of
set of YANG modules at lower layer. YANG modules at lower layer.
4.1.3. IP Service Mapping (c) 4.1.3. IP Service Mapping (c)
Service abstraction starts with high-level abstractions exposing the Service abstraction starts with high-level abstractions exposing the
business capabilities or capturing customer requirements. Then, it business capabilities or capturing customer requirements. Then, it
needs to maps them to resource abstraction and specific network needs to map them to resource abstraction and specific network
technologies. technologies.
Therefore, the interaction between service abstraction in the overlay Therefore, the interaction between service abstraction in the overlay
and network resource abstraction in the underlay is required. For and network resource abstraction in the underlay is required. For
example, in the L3SM service model, we describe VPN service topology example, in the L3SM service model, a VPN service topology is
including sites relationship, e.g., hub and spoke and any to any, described as e.g., hub and spoke and any-to-any, single-homed, dual-
single homed, dual-homed, multi-homed relation between PEs and CEs, homed, multi-homed relation between PEs and CEs, but we don't know
but we don't know how this service topology can be mapped into how this service topology can be mapped into the underlying network
underlying network topology. For detailed interaction, please refer topology Section 4.1.8
to Section 4.1.8
In addition, there is a need to decide on a mapping between service In addition, there is a need to decide on a mapping between service
abstraction and underlying specific network technologies. Take L3SM abstraction and the underlying specific network technologies. Take
service model as an example, to realize L3VPN service, we need to map L3SM service model as an example, to deliver a L3VPN service, we need
L3SM service view defined in Service model into detailed to map L3SM service view defined in Service model into detailed
configuration view defined by specific configuration models for configuration view defined by specific configuration models for
network elements, these configuration models include: network elements, configuartion information includes:
o VRF definition, including VPN Policy expression o VRF definition, including VPN Policy expression
o Physical Interface o Physical Interface
o IP layer (IPv4, IPv6). o IP layer (IPv4, IPv6).
o QoS features such as classification, profiles, etc. o QoS features such as classification, profiles, etc.
o Routing protocols: support of configuration of all protocols o Routing protocols: support of configuration of all protocols
skipping to change at page 20, line 7 skipping to change at page 19, line 47
with those protocols. with those protocols.
o Multicast Support o Multicast Support
o NAT or address sharing o NAT or address sharing
o Security functions o Security functions
4.1.4. IP Service Composition (d) 4.1.4. IP Service Composition (d)
These detailed configuration models are further assembled together These configuration models are further grouped together into service
into service bundle described inFigure 3 using, e.g., device model, bundles, as described in Figure 3using, e.g., device models, logical
logical network element model or network instance model defined in network element models or network instance models defined in [I.D-
[I.D-ietf-rtgwg-device-model] [RFC8530] [RFC8529] and provide the ietf-rtgwg-device-model] [RFC8530] [RFC8529] and provide the
association between an interface and its associated LNE and NI and association between an interface and its associated LNE and NI and
populate them into appropriate devices(e.g., PE and CE). populate them into appropriate devices(e.g., PE and CE).
4.1.5. IP Service Provision (e) 4.1.5. IP Service Provision (e)
IP Service Provision is used to provision network infrastructure IP Service Provision is used to provide IP network devices with a set
using various configuration models, e.g., use network element models of configuration information, e.g., network element models such as
such as BGP, ACL, QoS, Interface model, Network instance models to BGP, ACL, QoS, Interface model, Network instance models to configure
configure PE and CE device within the site. BGP Policy model is used PE and CE devices within the site, etc. A BGP policy model is used
to establish VPN membership between sites and VPN Service Topology. to establish VPN membership between sites and VPN Service Topology.
Traditionally, "push" service element configuration model one by one Experience shows that "pushing" configuration information to each
to the network device and provide association between an interface device one after the other is not efficient.
and each service element configuration model is not efficient.
To automate configuration of the service elements, we first assemble To automate the configuration of service elements, we first assemble
all related network elements models into logical network element all the related network elements models into logical network element
model defined in [RFC8530] and then establish association with an model as defined in [RFC8530] and then establish an association with
interface and a set of network element configurations. an interface and a set of network element configurations.
In addition, IP Service Provision can be used to setup tunnels In addition, not all the parameters of the service level model or
between sites and setup tunnels between PE and CE within the site network level model(e.g., mapped from service level model) needs to
when tunnels related configuration parameters can be generated from be specified, in many cases, some default values, or even some values
service abstraction. However when tunnels related configuration depending of some contextual information (e.g., the particular
parameters can not be generated from service abstraction, IP Service service / network element / location / etc) should be taken to
to TE Mapping procedure is required. automate the configuration process.
4.1.6. Performance Measurement and Alarm Telemetry (f) Seconldy, IP Service Provision can be used to setup tunnels between
sites and setup tunnels between PEs and CEs based upon tunnel-related
configuration information that can be derived from service
abstraction. However, when tunnel-related configuration parameters
cannot be generated from service abstraction, other service Mapping
procedure is required,e.g.,IP Service to TE mapping procdure
described in Section 4.1.7.
Once the tunnel is setup, PM and Warning information per tunnel or 4.1.6. Performance Measurement and Alarm Telemetry (g)
per link based on network topology can be collected and report to the
management system. This information can be used to optimize the
network or provide troubleshooting support.
4.1.7. IP Service to TE Mapping (g) Once the tunnel or VPN is setup, PM and Alarm information per tunnel
or per link based on network topology can be collected and report to
the management system. This information can be further aggregated
and abstracted from layered network topology to monitor and manage
network Performance on the topology at different layer or the overlay
topology between VPN sites. These network performance information or
VPN performance information (e.g., latency or bandwidth utilization
between two VPN sites) can be put into NBI telemetry model or NBI
performance monitoring model at either service level or network level
to further optimize the network or provide troubleshooting support.
4.1.7. IP Service to TE Mapping (f)
Take L3VPN service model as an example, the management system will Take L3VPN service model as an example, the management system will
use L3SM service model to determine where to connect each site- use L3SM service model to determine where to connect each site-
network-access of a particular site to the provider network (e.g., network-access of a particular site to the provider network (e.g.,
PE, aggregation switch). L3SM Service model proposes parameters and PE, aggregation switch). The L3SM Service model includes parameters
constraints that can influence the meshing of the site-network- that can help design the VPN, according to customer's requirements,
access. for example.
Nodes used to connect a site may be captured in relevant clauses of a Nodes used to connect a site may be captured in relevant clauses of a
service exposure model (e.g., Customer Nodes Map [RFC7297]). service exposure model (e.g., Customer Nodes Map [RFC7297]).
When Site location is determined, PE and CE device location will be When Site location is determined, PE and CE device location will be
selected. Then we can replace parameters and constraints that can selected. Then we can replace parameters and constraints that can
influence the meshing of the site-network-access with specified PE influence the meshing of the site-network-access with specified PE
and CE device information associated with site-network-access and and CE device information associated with site-network-access and
generate resource facing VN Overlay Resource model. One example of generate resource facing VN Overlay Resource model. One example of
resource facing VN Overlay Resource model is TEAS VN Service Model resource facing VN Overlay Resource model is TEAS VN Service Model
[I-D.ietf-teas-actn-vn-yang]. [I-D.ietf-teas-actn-vn-yang].
This VN Overlay Resource model can be used to calculate node and link This VN model can be used to calculate node and link resource to meet
resource to Meet service requirements based on Network Topology service requirements based on Network Topology models collected at
models collected at step (a). step (a).
4.1.8. Path Management (h) 4.1.8. Path Management (h)
Path Management includes Path computation and Path setup. For Path Management includes Path computation and Path setup. For
example, we can translate L3SM service model into resource facing VN example, we can derive an instantiated L3SM service model into a
Model, with selected PE and CE in each site, we can calculate point resource facing VN Model, with selected PE and CE in each site, we
to point or multipoint end to end path between sites based on VN can calculate point- to-point or multipoint end-to-end paths between
Overlay Resource Model. sites based on the VPN Overlay Resource Model.
After identifying node and link resources required to meet service After identifying node and link resources required to meet service
requirements, the mapping between overlay topology and underlay requirements, the mapping between overlay topology and underlay
topology can be established, e.g., establish an association between topology can be established, e.g., establish an association between
VPN service topology defined in customer facing model and underlying VPN service topology defined in customer-facing model and underlying
network topology defined in the TE topology model (e.g., one overlay network topology defined in the TE topology model (e.g., one overlay
node is supported by multiple underlay nodes, one overlay link is node is supported by multiple underlay nodes, one overlay link is
supported by multiple underlay nodes) and generate end to end VN supported by multiple underlay nodes) and generate end-to-end VPN
topology. topology.
4.1.9. TE Resource Exposure (i) 4.1.9. TE Resource Exposure (i)
When tunnels related configuration parameters can not be generated When tunnel-related configuration parameters cannot be derived from
from service abstraction, IP Service to TE Mapping procedure can be service abstraction, IP Service-to-TE Mapping procedure can be used
used to generate TE Resource Exposure view, this TE resource Exposure to generate TE Resource Exposure view, this TE resource Exposure view
view can be modeled as resource facing VN model which is translated can be modeled as a resource-facing VPN model which is translated and
and instantiated from L3SM model and manage TE resource based on path instantiated from a L3SM model and manage TE resources based on path
management information and PM and alarm telemetry information. management information and PM and alarm telemetry information.
Operators may use this dedicated TE resource Exposure view to Operators may use this dedicated TE resource Exposure view to
dynamically capture the overall network status and topology to: dynamically capture the overall network status and topology to:
o Perform all the requested recovery operations upon detecting o Perform all the requested recovery operations upon detecting
network failures affecting the network service. network failures affecting the network service.
o Adjust resource distribution and update to end to end Service o Adjust resource distribution and update to end to end Service
topology models topology models
skipping to change at page 22, line 22 skipping to change at page 22, line 25
5.1. L3VPN Service Delivery via Coordinated YANG Modules 5.1. L3VPN Service Delivery via Coordinated YANG Modules
Take L3VPN service as an example, IETF has already developed L3VPN Take L3VPN service as an example, IETF has already developed L3VPN
service model [RFC8299] which can be used to describe L3VPN service. service model [RFC8299] which can be used to describe L3VPN service.
To enforce L3VPN service and program the network, a set of network To enforce L3VPN service and program the network, a set of network
element models are needed, e.g., BGP model, Network Instance model, element models are needed, e.g., BGP model, Network Instance model,
ACL model, Multicast Model, QoS model, or NAT model. ACL model, Multicast Model, QoS model, or NAT model.
These network element models can be grouped into different release These network element models can be grouped into different release
bundles or feature bundle using Schema Mount technology to meet bundles or feature bundles using Schema Mount technology to meet
different tailored requirements and realize L3VPN service. different tailored requirements and deliver the L3VPN service.
To support the creation of logical network elements on a network To support the creation of logical network elements on a network
device and enable automation of virtualized network, Logical Network device and deliver a virtualized network, Logical Network Element
Element (LNE) model can be used to manage its own set of modules such (LNE) models can be used to manage its own set of modules such as
as ACL, QoS, or Network Instance modules. ACL, QoS, or Network Instance modules.
5.2. 5G Transport Service Delivery via Coordinated YANG Modules 5.2. 5G Transport Service Delivery via Coordinated YANG Modules
The overview of network slice structure as defined in the 3GPP 5GS is The overview of network slice structure as defined in the 3GPP 5GS is
shown in Figure 5. The terms are described in specific 3GPP shown in Figure 5. The terms are described in specific 3GPP
documents (e.g., [TS.23.501-3GPP] and [TS.28.530-3GPP]). documents (e.g., [TS.23.501-3GPP] and [TS.28.530-3GPP]).
<================== E2E-NSI =======================> <================== E2E-NSI =======================>
: : : : : : : : : :
: : : : : : : : : :
skipping to change at page 24, line 5 skipping to change at page 24, line 5
network NFs. network NFs.
VN in TEAS VN model and support point-to-point or multipoint-to- VN in TEAS VN model and support point-to-point or multipoint-to-
multipoint connectivity service and can be seen as one example of multipoint connectivity service and can be seen as one example of
network slice. network slice.
TE Service mapping model can be used to map L3VPN service requests TE Service mapping model can be used to map L3VPN service requests
onto underlying network resource and TE models to get TE network onto underlying network resource and TE models to get TE network
setup. setup.
For IP VPN service provision, L3VPN service model is translated into For IP VPN service provision, L3VPN service model is used to derive a
a set of network element configuration parameters, these set of configuration parameterswhich will be bound to different
configuration parameters will be bound to different network element network element models and group them together to form feature or
models and group them together to form feature bundle or service service bundles to deliver the VPN service.
bundle to get L3VPN network setup.
6. Modules Usage in Automated Virtualized Network Environment: Sample 6. Modules Usage in Automated Virtualized Network Environment: Sample
Examples Examples
6.1. Network-initiated Resource Creation 6.1. Network-initiated Resource Creation
|(2) |(2)
| |
V V
+-------------------+ +-------------------+
| Management System | (3)(4)(5) | Management System | (3)(4)(5)
+-------------------+ +-------------------+
+--------------------------------------------------------+ +--------------------------------------------------------+
/ _[CE2] _[CE3] / / _[CE2] _[CE3] /
/ _/ : \_ _/ : \_ / / _/ : \_ _/ : \_ /
skipping to change at page 25, line 46 skipping to change at page 25, line 8
/ : / __/ \__ / : / / : / __/ \__ / : /
/ : / ___/ \__ / : / / : / ___/ \__ / : /
/ : / ___/ \ / : / / : / ___/ \ / : /
/ [X4]__________________[X3]..: / / [X4]__________________[X3]..: /
+------------------------------------------+ +------------------------------------------+
L3 Topology L3 Topology
The following steps are performed to deliver the service within the The following steps are performed to deliver the service within the
network management automation architecture proposed in this document: network management automation architecture proposed in this document:
o Pre-provision multiple virtualized networks on top of the same 1. Pre-provision multiple virtualized networks on top of the same
basic network infrastructure based on pre-configured service basic network infrastructure based on pre-configured service
requirements and establish resource pool for each virtualized requirements and establish resource pool for each virtualized
network and expose to the customer with several service templates network and expose to the customer with several service templates
through web portal. through web portal.
o Selects and uses one which fulfills most its requirement among the 2. Selects and uses one which best accommodates its requirement
service templates. among the service templates.
o Create resource facing VN Network based on selected service 3. Calculate the node resource, link resource corresponding to
template, and calculate the node resource, link resource connectivity between sites and create resource facing VN Network
corresponding to connectivity between sites. based on selected service template, and
o Setup tunnels between sites and map them into the selected 4. Setup tunnels between sites and map them into the selected
virtualized network topology and establish resource facing VN virtualized network topology and establish resource facing VN
topology based on TEAS VN model [I-D.ietf-teas-actn-vn-yang] and topology based on TEAS VN model [I-D.ietf-teas-actn-vn-yang] and
TE tunnel based on TE Tunnel model. TE tunnel based on TE Tunnel model.
The resource facing VN model and corresponding TE Tunnel model can The resource-facing VN model and corresponding TE Tunnel model
be further used to notify all the parameter changes and event can be further used to notify all the parameter changes and event
related to VN topology or Tunnel. These information can be related to VN topology or Tunnel. This information can be
further used to adjust network resource distributed in the further used to adjust network resource distributed in the
network. network.
The network initiated resource creation is similar to ready made The network initiated resource creation is similar to ready-made
Network Slice creation pattern discussed in Section 5.1 of [I- Network Slice creation pattern discussed in Section 5.1 of [I-
D.homma-slice-provision-models]. D.homma-slice-provision-models].
6.2. Customer-initiated Dynamic Resource Creation 6.2. Customer-initiated Dynamic Resource Creation
|(2) |(2)
| |
V V
+-------------------+ +-------------------+
| Management System | (3)(4)(5) | Management System | (3)(4)(5)
+-------------------+ +-------------------+
skipping to change at page 27, line 40 skipping to change at page 26, line 40
/ : / __/ \__ / / / : / __/ \__ / /
/ : / ___/ \__ / / / : / ___/ \__ / /
/ : / ___/ \ / / / : / ___/ \ / /
/ [X4]__________________[X3]. / / [X4]__________________[X3]. /
+------------------------------------------+ +------------------------------------------+
L3 Topology L3 Topology
The following steps are performed to deliver the service within the The following steps are performed to deliver the service within the
network management automation architecture proposed in this document: network management automation architecture proposed in this document:
o Establish resources pool for the basic common network 1. Establish resource pool for the basic common network
infrastructure. infrastructure.
o Request to create two sites based on L3SM Service model with each 2. Request to create two sites based on L3SM Service model with each
having one network access connectivity: having one network access connectivity:
Site A: Network-Access A, Bandwidth=20M, for class "foo", Site A: Network-Access A, Bandwidth=20M, for class "foo",
guaranteed-bw-percent = 10, One-Way-Delay=70 msec guaranteed-bw-percent = 10, One-Way-Delay=70 msec
Site B: Network-Access B, Bandwidth=30M, for class "foo1", Site B: Network-Access B, Bandwidth=30M, for class "foo1",
guaranteed-bw-percent = 15, One-Way-Delay=60 msec guaranteed-bw-percent = 15, One-Way-Delay=60 msec
o Create a new service topology based on Service Type and service 3. Create a new service topology based on Service Type and service
requirements (e.g., Slice Service Type, Slice location, Number of requirements (e.g., Service Type, Site location, Number of
Slices, QoS requirements corresponding to network connectivity Slices, QoS requirements corresponding to network connectivity
within a Slice) defined in L3SM service model. within a L3VPN) defined in L3SM service model.
o Translate L3SM service model into resource facing TEAS VN Model 4. Translate L3SM service model into resource facing TEAS VN Model
[I-D.ietf-teas-actn-vn-yang], and calculate the node resource, [I-D.ietf-teas-actn-vn-yang] and a set of Network element models
link resource corresponding to connectivity between sites or to enable the protocols on the network device and get the network
connectivity between PE and CE within Site in the service topology setup, and the generated resource facing TEAS VN model can be
based on generated resource facing TEAS VN model. further used to calculate the node resource, link resource
corresponding to connectivity between sites.
o Setup tunnels between sites and tunnel between PE and CE within 5. Setup tunnels between sites and map them with the network
Site and map them into basic network infrastructure and establish infrastructure and establish resource facing VN topology based on
resource facing VN topology based on TEAS VN model and TE tunnel TEAS VN model and TE tunnel based on TE Tunnel model. The
based on TE Tunnel model. The resource facing TEAS VN model and resource facing TEAS VN model and corresponding TE Tunnel model
corresponding TE Tunnel model can be used to notify all the can be used to notify all the parameter changes and event related
parameter changes and event related to VN topology or Tunnel. to VN topology or Tunnel. These information can be further used
These information can be further used to adjust network resource to adjust network resource distributed within the network.
distributed within the network.
The customer initiated resource creation is similar to customer made The customer-initiated resource creation is similar to customer made
Network Slice creation pattern discussed in Section 5.2 of [I- Network Slice creation pattern discussed in Section 5.2 of [I-
D.homma-slice-provision-models]. D.homma-slice-provision-models].
7. Security Considerations 7. Security Considerations
Security considerations specific to each of the technologies and Security considerations specific to each of the technologies and
protocols listed in the document are discussed in the specification protocols listed in the document are discussed in the specification
documents of each of these techniques. documents of each of these techniques.
(Potential) security considerations specific to this document are (Potential) security considerations specific to this document are
skipping to change at page 29, line 14 skipping to change at page 28, line 14
9. Contributors 9. Contributors
Shunsuke Homma Shunsuke Homma
Japan Japan
Email: s.homma0718+ietf@gmail.com Email: s.homma0718+ietf@gmail.com
10. Acknowledgements 10. Acknowledgements
Thanks to Joe Clarck and Greg Mirsky for the review. Thanks to Joe Clark and Greg Mirsky for the review.
11. Informative References 11. Informative References
[I-D.arkko-arch-virtualization] [I-D.arkko-arch-virtualization]
Arkko, J., Tantsura, J., Halpern, J., and B. Varga, Arkko, J., Tantsura, J., Halpern, J., and B. Varga,
"Considerations on Network Virtualization and Slicing", "Considerations on Network Virtualization and Slicing",
draft-arkko-arch-virtualization-01 (work in progress), draft-arkko-arch-virtualization-01 (work in progress),
March 2018. March 2018.
[I-D.asechoud-netmod-diffserv-model] [I-D.asechoud-netmod-diffserv-model]
Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N. Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N.
Strahle, "YANG Model for Diffserv", draft-asechoud-netmod- Strahle, "YANG Model for Diffserv", draft-asechoud-netmod-
diffserv-model-03 (work in progress), June 2015. diffserv-model-03 (work in progress), June 2015.
[I-D.clacla-netmod-model-catalog] [I-D.clacla-netmod-model-catalog]
Clarke, J. and B. Claise, "YANG module for Clarke, J. and B. Claise, "YANG module for
yangcatalog.org", draft-clacla-netmod-model-catalog-03 yangcatalog.org", draft-clacla-netmod-model-catalog-03
(work in progress), April 2018. (work in progress), April 2018.
[I-D.evenwu-opsawg-yang-composed-vpn]
Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model
for Composed VPN Service Delivery", draft-evenwu-opsawg-
yang-composed-vpn-03 (work in progress), March 2019.
[I-D.homma-slice-provision-models] [I-D.homma-slice-provision-models]
Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V.,
Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez-
Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X.
Foy, "Network Slice Provision Models", draft-homma-slice- Foy, "Network Slice Provision Models", draft-homma-slice-
provision-models-00 (work in progress), February 2019. provision-models-00 (work in progress), February 2019.
[I-D.ietf-bess-evpn-yang] [I-D.ietf-bess-evpn-yang]
Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K.,
and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- and J. Rabadan, "Yang Data Model for EVPN", draft-ietf-
bess-evpn-yang-07 (work in progress), March 2019. bess-evpn-yang-07 (work in progress), March 2019.
[I-D.ietf-bess-l2vpn-yang] [I-D.ietf-bess-l2vpn-yang]
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
and K. Tiruveedhula, "YANG Data Model for MPLS-based and K. Tiruveedhula, "YANG Data Model for MPLS-based
L2VPN", draft-ietf-bess-l2vpn-yang-09 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress),
October 2018. July 2019.
[I-D.ietf-bess-l3vpn-yang] [I-D.ietf-bess-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
for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work
in progress), October 2018. in progress), October 2018.
[I-D.ietf-bfd-yang] [I-D.ietf-bfd-yang]
Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and
G. Mirsky, "YANG Data Model for Bidirectional Forwarding G. Mirsky, "YANG Data Model for Bidirectional Forwarding
skipping to change at page 33, line 5 skipping to change at page 32, line 5
[I-D.ietf-softwire-yang] [I-D.ietf-softwire-yang]
Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in-
IPv6 Address plus Port (A+P) Softwires", draft-ietf- IPv6 Address plus Port (A+P) Softwires", draft-ietf-
softwire-yang-16 (work in progress), January 2019. softwire-yang-16 (work in progress), January 2019.
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
Tantsura, "YANG Data Model for Segment Routing", draft- Tantsura, "YANG Data Model for Segment Routing", draft-
ietf-spring-sr-yang-12 (work in progress), February 2019. ietf-spring-sr-yang-12 (work in progress), February 2019.
[I-D.ietf-supa-generic-policy-data-model]
Halpern, J. and J. Strassner, "Generic Policy Data Model
for Simplified Use of Policy Abstractions (SUPA)", draft-
ietf-supa-generic-policy-data-model-04 (work in progress),
June 2017.
[I-D.ietf-teas-actn-vn-yang] [I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
Yoon, "A Yang Data Model for VN Operation", draft-ietf- Yoon, "A Yang Data Model for VN Operation", draft-ietf-
teas-actn-vn-yang-05 (work in progress), June 2019. teas-actn-vn-yang-05 (work in progress), June 2019.
[I-D.ietf-teas-sf-aware-topo-model] [I-D.ietf-teas-sf-aware-topo-model]
Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras,
L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology
YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work
in progress), March 2019. in progress), March 2019.
skipping to change at page 34, line 8 skipping to change at page 33, line 14
[I-D.ietf-teas-yang-te] [I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels and "A YANG Data Model for Traffic Engineering Tunnels and
Interfaces", draft-ietf-teas-yang-te-21 (work in Interfaces", draft-ietf-teas-yang-te-21 (work in
progress), April 2019. progress), April 2019.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE) O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-21 (work in Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), May 2019. progress), June 2019.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, DOI 10.17487/RFC4664, September 2006,
<https://www.rfc-editor.org/info/rfc4664>. <https://www.rfc-editor.org/info/rfc4664>.
skipping to change at page 37, line 29 skipping to change at page 36, line 29
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Christian
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Luis Miguel Contreras Murillo
Telifonica
Email: luismiguel.contrerasmurillo@telefonica.com
Diego R. Lopez
Telefonica I+D
Spain
Email: diego.r.lopez@telefonica.com
Chongfeng Xie
China Telecom
Beijing
China
Email: xiechf.bri@chinatelecom.cn
Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com
Young Lee Young Lee
Futurewei Futurewei
Email: younglee.tx@gmail.com Email: younglee.tx@gmail.com
 End of changes. 113 change blocks. 
446 lines changed or deleted 451 lines changed or added

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