< draft-ietf-teas-sf-aware-topo-model-05.txt   draft-ietf-teas-sf-aware-topo-model-06.txt >
Network Working Group I. Bryskin Network Working Group I. Bryskin
Internet-Draft Individual Internet-Draft Individual
Intended status: Informational X. Liu Intended status: Informational X. Liu
Expires: September 10, 2020 Volta Networks Expires: May 23, 2021 Volta Networks
Y. Lee Y. Lee
Sung Kyun Kwan University Sung Kyun Kwan University
J. Guichard J. Guichard
Huawei Technologies Huawei Technologies
L. Contreras L. Contreras
Telefonica Telefonica
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
J. Tantsura J. Tantsura
Apstra Networks Apstra Networks
March 9, 2020 November 19, 2020
SF Aware TE Topology YANG Model SF Aware TE Topology YANG Model
draft-ietf-teas-sf-aware-topo-model-05 draft-ietf-teas-sf-aware-topo-model-06
Abstract Abstract
This document describes a YANG data model for TE network topologies This document describes a YANG data model for TE network topologies
that are network service and function aware. that are network service and function aware.
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.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 10, 2020. This Internet-Draft will expire on May 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6
2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6
3. SF Aware TE Topology Model Structure . . . . . . . . . . . . 7 3. SF Aware TE Topology Model Structure . . . . . . . . . . . . 7
4. SF Aware TE Topology YANG Module . . . . . . . . . . . . . . 9 4. SF Aware TE Topology YANG Module . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Companion YANG Model for Non-NMDA Compliant Appendix A. Companion YANG Model for Non-NMDA Compliant
Implementations . . . . . . . . . . . . . . . . . . 20 Implementations . . . . . . . . . . . . . . . . . . 22
A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 20 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 22
Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 23 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 25
B.1. A Topology with Multiple Connected Network Functions . . 23 B.1. A Topology with Multiple Connected Network Functions . . 25
B.2. A Topology with an Encapsulated Network Service . . . . . 27 B.2. A Topology with an Encapsulated Network Service . . . . . 29
Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 31 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 33
C.1. Exporting SF/NF Information to Network Clients and Other C.1. Exporting SF/NF Information to Network Clients and Other
Network SDN Controllers . . . . . . . . . . . . . . . . . 31 Network SDN Controllers . . . . . . . . . . . . . . . . . 33
C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 32 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 34
C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 33 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 35
C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 34 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 36
C.5. Network Clock Synchronization . . . . . . . . . . . . . . 37 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 39
C.6. Client - Provider Network Slicing Interface . . . . . . . 37 C.6. Client - Provider Network Slicing Interface . . . . . . . 39
C.7. Dynamic Assignment of Regenerators for L0 Services . . . 37 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 39
C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 39 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 41
C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 40 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 42
C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 40 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 42
C.11. Application-aware Resource Operations and Management . . 41 C.11. Application-aware Resource Operations and Management . . 43
C.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 42 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44
C.13. Security Considerations . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
C.14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
RFC Ed.: In this document, please replace all occurrences of 'XXXX' RFC Ed.: In this document, please replace all occurrences of 'XXXX'
with the actual RFC number (and remove this note). with the actual RFC number (and remove this note).
Normally network connectivity services are discussed as a means to Normally network connectivity services are discussed as a means to
inter-connect various abstract or physical network topological inter-connect various abstract or physical network topological
elements, such as ports, link termination points and nodes elements, such as ports, link termination points and nodes [RFC8795]
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the [I-D.ietf-teas-yang-te]. However, the connectivity services,
connectivity services, strictly speaking, interconnect not the strictly speaking, interconnect not the network topology elements
network topology elements per-se, rather, located on/associated with per-se, rather, located on/associated with the various network and
the various network and service functions [RFC7498] [RFC7665]. In service functions [RFC7498] [RFC7665]. In many scenarios it is
many scenarios it is beneficial to decouple the service/network beneficial to decouple the service/network functions from the network
functions from the network topology elements hosting them, describe topology elements hosting them, describe them in some unambiguous and
them in some unambiguous and identifiable way (so that it would be identifiable way (so that it would be possible, for example, to auto-
possible, for example, to auto-discover on the network topology discover on the network topology service/network functions with
service/network functions with identical or similar functionality and identical or similar functionality and characteristics) and engineer
characteristics) and engineer the connectivity between the service/ the connectivity between the service/network functions, rather than
network functions, rather than between their current topological between their current topological locations.
locations.
Today a network offers to its clients far more services than just Today a network offers to its clients far more services than just
connectivity across the network. Large variety of physical, logical connectivity across the network. Large variety of physical, logical
and/or virtual service functions, network functions and transport and/or virtual service functions, network functions and transport
functions (collectively named in this document as SFs) could be functions (collectively named in this document as SFs) could be
allocated for and assigned to a client. As described in the appendix allocated for and assigned to a client. As described in the appendix
of this document, there are some important use cases, in which the of this document, there are some important use cases, in which the
network needs to represent to the client SFs at the client's disposal network needs to represent to the client SFs at the client's disposal
as topological elements in relation to other elements of a topology as topological elements in relation to other elements of a topology
(i.e. nodes, links, link and tunnel termination points) used by the (i.e. nodes, links, link and tunnel termination points) used by the
skipping to change at page 5, line 15 skipping to change at page 5, line 15
shorthand for "service function chain" [RFC7498]. shorthand for "service function chain" [RFC7498].
o Connectivity Service: Any service between layer 0 and layer 3 o Connectivity Service: Any service between layer 0 and layer 3
aiming at delivering traffic among two or more end customer edge aiming at delivering traffic among two or more end customer edge
nodes connected to provider edge nodes. Examples include L3VPN, nodes connected to provider edge nodes. Examples include L3VPN,
L2VPN etc. L2VPN etc.
o Link Termination Point (LTP): A conceptual point of connection of o Link Termination Point (LTP): A conceptual point of connection of
a TE node to one of the TE links, terminated by the TE node. a TE node to one of the TE links, terminated by the TE node.
Cardinality between an LTP and the associated TE link is 1:0..1 Cardinality between an LTP and the associated TE link is 1:0..1
[I-D.ietf-teas-yang-te-topo]. [RFC8795].
o Tunnel Termination Point (TTP): An element of TE topology o Tunnel Termination Point (TTP): An element of TE topology
representing one or several of potential transport service representing one or several of potential transport service
termination points (i.e. service client adaptation points such as termination points (i.e. service client adaptation points such as
WDM/OCh transponder). TTP is associated with (hosted by) exactly WDM/OCh transponder). TTP is associated with (hosted by) exactly
one TE node. TTP is assigned with the TE node scope unique ID. one TE node. TTP is assigned with the TE node scope unique ID.
Depending on the TE node's internal constraints, a given TTP Depending on the TE node's internal constraints, a given TTP
hosted by the TE node could be accessed via one, several or all TE hosted by the TE node could be accessed via one, several or all TE
links terminated by the TE node [I-D.ietf-teas-yang-te-topo]. links terminated by the TE node [RFC8795].
o Topology and Orchestration Specification for Cloud Applications o Topology and Orchestration Specification for Cloud Applications
(TOSCA): A language standard specified by OASIS, to describe (TOSCA): A language standard specified by OASIS, to describe
service components and their relationships using a service service components and their relationships using a service
topology, and management procedures using orchestration processes. topology, and management procedures using orchestration processes.
OASIS is a nonprofit consortium that drives the development, OASIS is a nonprofit consortium that drives the development,
convergence and adoption of open standards for the global convergence and adoption of open standards for the global
information society. information society.
The following terms are defined in [RFC7950] and are not redefined The following terms are defined in [RFC7950] and are not redefined
skipping to change at page 6, line 20 skipping to change at page 6, line 20
names are prefixed using the standard prefix associated with the names are prefixed using the standard prefix associated with the
corresponding YANG module, as shown in Table 1. corresponding YANG module, as shown in Table 1.
+---------+------------------+------------------------------+ +---------+------------------+------------------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+---------+------------------+------------------------------+ +---------+------------------+------------------------------+
| inet | ietf-inet-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] |
| nw | ietf-network | [RFC8345] | | nw | ietf-network | [RFC8345] |
| nt | ietf-network- | [RFC8345] | | nt | ietf-network- | [RFC8345] |
| | topology | | | | topology | |
| tet | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] | | tet | ietf-te-topology | [RFC8795] |
| actn-vn | ietf-actn-vn | [I-D.ietf-teas-actn-vn-yang] | | actn-vn | ietf-actn-vn | [I-D.ietf-teas-actn-vn-yang] |
+---------+------------------+------------------------------+ +---------+------------------+------------------------------+
Table 1: Prefixes and Corresponding YANG Modules Table 1: Prefixes and Corresponding YANG Modules
2. Modeling Considerations 2. Modeling Considerations
The model introduced in this document is an augmentation of the TE The model introduced in this document is an augmentation of the TE
Topology model defined in [I-D.ietf-teas-yang-te-topo]. SFs are Topology model defined in [RFC8795]. SFs are modeled as child
modeled as child elements of a TE node similarly to how Link elements of a TE node similarly to how Link Termination Points (LTPs)
Termination Points (LTPs) and Tunnel Termination Points (TTPs) are and Tunnel Termination Points (TTPs) are modeled in the TE Topology
modeled in the TE Topology model. The SFs are defined as opaque model. The SFs are defined as opaque objects identified via topology
objects identified via topology unique service-function-id's. Each unique service-function-id's. Each SF has one or more Connection
SF has one or more Connection Points (CPs) identified via SF-unique Points (CPs) identified via SF-unique sf-connection-point-id's, over
sf-connection-point-id's, over which the SF could be connected to which the SF could be connected to other SFs resided on the same TE
other SFs resided on the same TE node, as well as to other elements node, as well as to other elements of the TE node, in particular, to
of the TE node, in particular, to the node's LTPs and/or TTPs. An the node's LTPs and/or TTPs. An interested client may use service-
interested client may use service-function-id's to look up the SFs in function-id's to look up the SFs in TOSCA or YANG data store(s)
TOSCA or YANG data store(s) defined by [ETSI-NFV-MAN] to retrieve the defined by [ETSI-NFV-MAN] to retrieve the details of the SFs, for
details of the SFs, for example, to understand the SF's mutual example, to understand the SF's mutual substitutability.
substitutability.
The TE Topology model introduces a concept of Connectivity Matrix The TE Topology model introduces a concept of Connectivity Matrix
(CM), and uses the CM to describe which and at what costs a TE node's (CM), and uses the CM to describe which and at what costs a TE node's
LTPs could be inter-connected internally across the TE node. The LTPs could be inter-connected internally across the TE node. The
model defined in this document heavily uses the same concept to model defined in this document heavily uses the same concept to
describe the SF connectivity via introducing 3 additional CMs: describe the SF connectivity via introducing 3 additional CMs:
1. SF2SF CM (SF to SF Connectivity Matrix). This CM describes which 1. SF2SF CM (SF to SF Connectivity Matrix). This CM describes which
pairs of SFs could be locally inter-connected, and, if yes, in pairs of SFs could be locally inter-connected, and, if yes, in
which direction, via which CPs and at what costs. In other which direction, via which CPs and at what costs. In other
skipping to change at page 17, line 13 skipping to change at page 17, line 13
-------------------------------------------------------------------- --------------------------------------------------------------------
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-te-topology-sf-state name: ietf-te-topology-sf-state
namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state
prefix: tet-sf-s prefix: tet-sf-s
reference: RFC XXXX reference: RFC XXXX
-------------------------------------------------------------------- --------------------------------------------------------------------
6. Security Considerations 6. Security Considerations
The configuration, state, action and notification data defined in The YANG module specified in this document defines a schema for data
this document are designed to be accessed via the NETCONF protocol that is designed to be accessed via network management protocols such
[RFC6241]. The data-model by itself does not create any security as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
implications. The security considerations for the NETCONF protocol is the secure transport layer, and the mandatory-to-implement secure
are applicable. The NETCONF protocol used for sending the data transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
supports authentication and encryption. is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
/nw:networks/nw:network/nw:network-types/tet:te-topology/sf
This subtree specifies the topology type. Modifying the
configurations can make topology type invalid and cause
interruption to the specified SF Aware TE topology and the related
SF Aware TE topologies.
/nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/
service-function
This subtree specifies the configurations of service functions in
SF Aware TE nodes. Modifying the configurations in this subtree
can change the configurations of service functions in the
specified node, causing these service functions disabled or
misbehaving in the specified node.
/nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/
service-function
This subtree specifies the configurations of service functions on
a tunnel-termination-point in SF Aware TE nodes. Modifying the
configurations in this subtree can change the configurations of
service functions on the spcified tunnel-termination-point in the
specified node, causing these service functions disabled or
misbehaving.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
/nw:networks/nw:network/nw:network-types/tet:te-topology/sf
Unauthorized access to this subtree can disclose the SF Aware TE
topology type.
/nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/
service-function
Unauthorized access to this subtree can disclose the operational
state information of the service functions in the specified SF
Aware TE node.
/nw:networks/nw:network/nw:node/tet:te/tet:information-source-entry/
service-function
Unauthorized access to this subtree can disclose the operational
state information of the service functions in the specified SF
Aware TE node.
/nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/
service-function
Unauthorized access to this subtree can disclose the operational
state information of the service functions on the specified
tunnel-termination-point in the specified SF Aware TE node.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 17, line 43 skipping to change at page 19, line 15
[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, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-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>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[I-D.ietf-teas-yang-te-topo] [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
O. Dios, "YANG Data Model for Traffic Engineering (TE) <https://www.rfc-editor.org/info/rfc8446>.
Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019. [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[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, Label
Interfaces", draft-ietf-teas-yang-te-22 (work in Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
progress), November 2019. (work in progress), July 2020.
[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-08 (work in progress), March 2020. teas-actn-vn-yang-10 (work in progress), November 2020.
[ETSI-NFV-MAN] [ETSI-NFV-MAN]
ETSI, "Network Functions Virtualisation (NFV); Management ETSI, "Network Functions Virtualisation (NFV); Management
and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December
2014. 2014.
[ETSI-NFV-TERM] [ETSI-NFV-TERM]
ETSI, "Network Functions Virtualisation (NFV); Terminology ETSI, "Network Functions Virtualisation (NFV); Terminology
for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1, for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1,
December 2014. December 2014.
skipping to change at page 42, line 5 skipping to change at page 44, line 5
5G network slicing, etc.). The application servers that host these 5G network slicing, etc.). The application servers that host these
application resources can be modeled as an abstract node. There may application resources can be modeled as an abstract node. There may
be a variety of server types depending on the resources they host. be a variety of server types depending on the resources they host.
Figure 9 shows one example application aware topology for video cache Figure 9 shows one example application aware topology for video cache
server distribution. server distribution.
_ _
Figure 9: Application aware topology Figure 9: Application aware topology
C.12. IANA Considerations Acknowledgements
This document has no actions for IANA.
C.13. Security Considerations
This document does not define networking protocols and data, hence is
not directly responsible for security risks.
C.14. Acknowledgements
The authors would like to thank Maarten Vissers, Joel Halpern, and The authors would like to thank Maarten Vissers, Joel Halpern, and
Greg Mirsky for their helpful comments and valuable contributions. Greg Mirsky for their helpful comments and valuable contributions.
Authors' Addresses Authors' Addresses
Igor Bryskin Igor Bryskin
Individual Individual
EMail: i_bryskin@yahoo.com EMail: i_bryskin@yahoo.com
 End of changes. 20 change blocks. 
83 lines changed or deleted 152 lines changed or added

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