< draft-ietf-teas-sf-aware-topo-model-03.txt   draft-ietf-teas-sf-aware-topo-model-04.txt >
Network Working Group I. Bryskin Network Working Group I. Bryskin
Internet-Draft Huawei Technologies Internet-Draft Individual
Intended status: Informational X. Liu Intended status: Informational X. Liu
Expires: September 12, 2019 Volta Networks Expires: May 7, 2020 Volta Networks
Y. Lee Y. Lee
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
November 4, 2019
March 11, 2019
SF Aware TE Topology YANG Model SF Aware TE Topology YANG Model
draft-ietf-teas-sf-aware-topo-model-03 draft-ietf-teas-sf-aware-topo-model-04
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 41 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 2019. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6
2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6
3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 7 3. SF Aware TE Topology Model Structure . . . . . . . . . . . . 7
4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 8 4. SF Aware TE Topology YANG Module . . . . . . . . . . . . . . 9
5. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 15 5. CSO Data Center Model Structure . . . . . . . . . . . . . . . 16
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 6. CSO Data Center YANG Module . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Companion YANG Model for Non-NMDA Compliant Appendix A. Companion YANG Model for Non-NMDA Compliant
Implementations . . . . . . . . . . . . . . . . . . 26 Implementations . . . . . . . . . . . . . . . . . . 27
A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 26 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 27
Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 28 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 30
B.1. A Topology with Multiple Connected Network Functions . . 28 B.1. A Topology with Multiple Connected Network Functions . . 30
B.2. A Topology with an Encapsulated Network Service . . . . . 33 B.2. A Topology with an Encapsulated Network Service . . . . . 34
Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 37 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 38
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 . . . . . . . . . . . . . . . . . 37 Network SDN Controllers . . . . . . . . . . . . . . . . . 38
C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 38 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 39
C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 39 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 40
C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 40 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 41
C.5. Network Clock Synchronization . . . . . . . . . . . . . . 43 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 44
C.6. Client - Provider Network Slicing Interface . . . . . . . 43 C.6. Client - Provider Network Slicing Interface . . . . . . . 44
C.7. Dynamic Assignment of Regenerators for L0 Services . . . 43 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 44
C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 45 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 46
C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 46 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 47
C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 46 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 47
C.11. Application-aware Resource Operations and Management . . 47 C.11. Application-aware Resource Operations and Management . . 48
C.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 48 C.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 49
C.13. Security Considerations . . . . . . . . . . . . . . . . . 48 C.13. Security Considerations . . . . . . . . . . . . . . . . . 49
C.14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 48 C.14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
RFC Ed.: In this document, please replace all occurrences of 'XXXX'
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
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the [I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the
connectivity services, strictly speaking, interconnect not the connectivity services, strictly speaking, interconnect not the
network topology elements per-se, rather, located on/associated with network topology elements per-se, rather, located on/associated with
the various network and service functions [RFC7498] [RFC7665]. In the various network and service functions [RFC7498] [RFC7665]. In
many scenarios it is beneficial to decouple the service/network many scenarios it is beneficial to decouple the service/network
functions from the network topology elements hosting them, describe functions from the network topology elements hosting them, describe
them in some unambiguous and identifiable way (so that it would be them in some unambiguous and identifiable way (so that it would be
skipping to change at page 3, line 44 skipping to change at page 3, line 49
available for the services provisioned for the client, it would also available for the services provisioned for the client, it would also
allow for the client selecting the SFs, duel-optimizing the selection allow for the client selecting the SFs, duel-optimizing the selection
on the SF location on the network and connectivity means (e.g. TE on the SF location on the network and connectivity means (e.g. TE
tunnels) to inter-connect the SFs. Consequently thus would give to tunnels) to inter-connect the SFs. Consequently thus would give to
both the network and the client powerful means for the service both the network and the client powerful means for the service
function chain (SFC [RFC7498] [RFC7665]) negotiation to achieve most function chain (SFC [RFC7498] [RFC7665]) negotiation to achieve most
efficient and cost effective (from the network point of view) and efficient and cost effective (from the network point of view) and
most optimal yet satisfying all necessary constraints of SFCs (from most optimal yet satisfying all necessary constraints of SFCs (from
the client's point of view). the client's point of view).
This document defines a YANG data model that allows service functions This document defines a YANG [RFC7950] data model that allows service
to be represented along with TE topology elements. functions to be represented along with TE topology elements.
The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) [RFC8342].
1.1. Terminology 1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
o Network Function (NF): A functional block within a network o Network Function (NF): A functional block within a network
infrastructure that has well-defined external interfaces and well- infrastructure that has well-defined external interfaces and well-
defined functional behaviour [ETSI-NFV-TERM]. Such functions defined functional behaviour [ETSI-NFV-TERM]. Such functions
include message router, CDN, session border controller, WAN include message router, CDN, session border controller, WAN
cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and
radio/fixed access network nodes. radio/fixed access network nodes.
o Network Service: Composition of Network Functions and defined by o Network Service: Composition of Network Functions and defined by
its functional and behavioural specification. The Network Service its functional and behavioural specification. The Network Service
skipping to change at page 5, line 19 skipping to change at page 5, line 28
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 [I-D.ietf-teas-yang-te-topo].
o Topology and Orchestration Specification for Cloud Applications
(TOSCA): A language standard specified by OASIS, to describe
service components and their relationships using a service
topology, and management procedures using orchestration processes.
OASIS is a nonprofit consortium that drives the development,
convergence and adoption of open standards for the global
information society.
The following terms are defined in [RFC7950] and are not redefined The following terms are defined in [RFC7950] and are not redefined
here: here:
o augment o augment
o data model o data model
o data node o data node
1.2. Tree Diagrams 1.2. Tree Diagrams
A simplified graphical representation of the data model is presented A simplified graphical representation of the data model is presented
in this document, by using the tree format defined in in this document, by using the tree format defined in [RFC8340].
[I-D.ietf-netmod-yang-tree-diagrams].
1.3. Prefixes in Data Node Names 1.3. Prefixes in Data Node Names
In this document, names of data nodes, actions, and other data model In this document, names of data nodes, actions, and other data model
objects are often used without a prefix, as long as it is clear from objects are often used without a prefix, as long as it is clear from
the context in which YANG module each name is defined. Otherwise, the context in which YANG module each name is defined. Otherwise,
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 | [I-D.ietf-i2rs-yang-network-topo] | | nw | ietf-network | [RFC8345] |
| nt | ietf-network- | [I-D.ietf-i2rs-yang-network-topo] | | nt | ietf-network- | [RFC8345] |
| | topology | | | | topology | |
| tet | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] | | tet | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] |
+--------+------------------+-----------------------------------+ | 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 [I-D.ietf-teas-yang-te-topo]. SFs are
modeled as child elements of a TE node similarly to how Link modeled as child elements of a TE node similarly to how Link
Termination Points (LTPs) and Tunnel Termination Points (TTPs) are Termination Points (LTPs) and Tunnel Termination Points (TTPs) are
modeled in the TE Topology model. The SFs are defined as opaque modeled in the TE Topology model. The SFs are defined as opaque
skipping to change at page 6, line 28 skipping to change at page 6, line 49
TOSCA or YANG data store(s) defined by [ETSI-NFV-MAN] to retrieve the TOSCA or YANG data store(s) defined by [ETSI-NFV-MAN] to retrieve the
details of the SFs, for example, to understand the SF's mutual details of the SFs, for 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. This CM describes which pairs of SFs could be locally 1. SF2SF CM (SF to SF Connectivity Matrix). This CM describes which
inter-connected, and, if yes, in which direction, via which CPs pairs of SFs could be locally inter-connected, and, if yes, in
and at what costs. In other words, the SF2SF CM describes how which direction, via which CPs and at what costs. In other
SFs residing on the same TE node could be inter-connected into words, the SF2SF CM describes how SFs residing on the same TE
local from the TE node's perspective SFCs; node could be inter-connected into local from the TE node's
perspective SFCs;
2. SF2LTP CM. This CM describes how, in which direction and at what 2. SF2LTP CM (SF to LTP Connectivity Matrix). This CM describes
costs the TE node's SFs could be connected to the TE node's LTPs how, in which direction and at what costs the TE node's SFs could
and hence to SFs residing on neighboring TE nodes that are be connected to the TE node's LTPs and hence to SFs residing on
connected to LTPs at the remote ends of corresponding TE links; neighboring TE nodes that are connected to LTPs at the remote
ends of corresponding TE links;
3. SF2TTP CM. This CM describes how, in which direction and at what 3. SF2TTP CM (SF to TTP Connectivity Matrix). This CM describes
costs the TE node's SFs could be connected to the TE node's TTPs how, in which direction and at what costs the TE node's SFs could
and hence to SFs residing on other TE nodes on the topology that be connected to the TE node's TTPs and hence to SFs residing on
could be inter-connected with the TE node in question via TE other TE nodes on the topology that could be inter-connected with
tunnels terminated by the corresponding TTPs. the TE node in question via TE tunnels terminated by the
corresponding TTPs.
In addition to SF2SF CM, the local SF chaining could be described In addition to SF2SF CM, the local SF chaining could be described
with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN]. with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN].
This option is especially useful when the costs of the local chaining This option is especially useful when the costs of the local chaining
are negligible as compared to ones of the end-to-end SFCs said local are negligible as compared to ones of the end-to-end SFCs said local
SFCs are part of. SFCs are part of.
Section 3 and 4 provide the YANG model structure and the YANG module Section 3 and 4 provide the YANG model structure and the YANG module
for SF-aware Topology. Section 5 and 6 provide the YANG model for SF-aware Topology. Section 5 and 6 provide the YANG model
structure and the YANG module for Data Center Compute Node resource structure and the YANG module for Data Center Compute Node resource
abstraction. This provides an example of SF2LTP CM where DC compute abstraction. This provides an example of SF2LTP CM where DC compute
nodes are connected to LTPs at the remote ends of the corresponding nodes are connected to LTPs at the remote ends of the corresponding
TE links. This use-case is described in Section 10 of Appendix C. TE links. This use-case is described in Section 10 of Appendix C.
3. Model Structure 3. SF Aware TE Topology Model Structure
module: ietf-te-topology-sf module: ietf-te-topology-sf
augment /nw:networks/nw:network/nw:network-types/tet:te-topology: augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
+--rw sf! +--rw sf!
augment /nw:networks/nw:network/nw:node/tet:te augment /nw:networks/nw:network/nw:node/tet:te
/tet:te-node-attributes: /tet:te-node-attributes:
+--rw service-function +--rw service-function
+--rw connectivity-matrices +--rw connectivity-matrices
| +--rw connectivity-matrix* [id] | +--rw connectivity-matrix* [id]
| +--rw id uint32 | +--rw id uint32
skipping to change at page 8, line 27 skipping to change at page 9, line 5
/tet:tunnel-termination-point: /tet:tunnel-termination-point:
+--rw service-function +--rw service-function
+--rw tunnel-terminations +--rw tunnel-terminations
+--rw tunnel-termination* [id] +--rw tunnel-termination* [id]
+--rw id uint32 +--rw id uint32
+--rw service-function-id? string +--rw service-function-id? string
+--rw sf-connection-point-id? string +--rw sf-connection-point-id? string
+--rw enabled? boolean +--rw enabled? boolean
+--rw direction? connectivity-direction +--rw direction? connectivity-direction
4. YANG Modules 4. SF Aware TE Topology YANG Module
<CODE BEGINS> file "ietf-te-topology-sf@2018-02-27.yang" <CODE BEGINS> file "ietf-te-topology-sf@2019-11-03.yang"
module ietf-te-topology-sf { module ietf-te-topology-sf {
yang-version 1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf";
prefix "tet-sf"; prefix "tet-sf";
import ietf-network { import ietf-network {
prefix "nw"; prefix "nw";
reference "RFC 8345: A YANG Data Model for Network Topologies";
} }
import ietf-network-topology { import ietf-network-topology {
prefix "nt"; prefix "nt";
reference "RFC 8345: A YANG Data Model for Network Topologies";
} }
import ietf-te-topology { import ietf-te-topology {
prefix "tet"; prefix "tet";
reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies";
} }
organization organization
"Traffic Engineering Architecture and Signaling (TEAS) "Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/teas/> "WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org> WG List: <mailto:teas@ietf.org>
Editors: Igor Bryskin Editors: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com> <mailto:Igor.Bryskin@huawei.com>
Xufeng Liu Xufeng Liu
<mailto:Xufeng_Liu@jabil.com>"; <mailto:Xufeng_Liu@jabil.com>";
description description
"Network service and function aware aware TE topology model. "Network service and function aware aware TE topology model.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info)."; (http://trustee.ietf.org/license-info).
revision 2018-02-27 { This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
revision 2019-11-03 {
description "Initial revision"; description "Initial revision";
reference "TBD"; reference "RFC XXXX: SF Aware TE Topology YANG Model";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef connectivity-direction { typedef connectivity-direction {
type enumeration { type enumeration {
enum "to" { enum "to" {
description description
"The direction is uni-directional, towards the 'to' "The direction is uni-directional, towards the 'to'
skipping to change at page 15, line 18 skipping to change at page 16, line 4
uses service-function-node-augmentation; uses service-function-node-augmentation;
} }
/* Augmentations to tunnel-termination-point */ /* Augmentations to tunnel-termination-point */
augment "/nw:networks/nw:network/nw:node/tet:te/" augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:tunnel-termination-point" { + "tet:tunnel-termination-point" {
description description
"Parameters for SF aware TE topology."; "Parameters for SF aware TE topology.";
uses service-function-ttp-augmentation; uses service-function-ttp-augmentation;
} }
/* Augmentations to connectivity-matrix */ /* Augmentations to connectivity-matrix */
augment "/nw:networks/nw:network/nw:node/tet:te/" augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/tet-sf:service-function/" + "tet:te-node-attributes/tet-sf:service-function/"
+ "tet-sf:link-terminations/tet-sf:link-termination/" + "tet-sf:link-terminations/tet-sf:link-termination/"
+ "tet-sf:from" { + "tet-sf:from" {
description description
"Add reference to the link termination point. "Add reference to the link termination point.
This portion cannot be shared with the state module."; This portion cannot be shared with the state module.";
leaf tp-ref { leaf tp-ref {
type leafref { type leafref {
path "../../../../../../../nt:termination-point/" path "../../../../../../../nt:termination-point/"
+ "nt:tp-id"; + "nt:tp-id";
} }
description description
"Reference to the link termination point."; "Reference to the link termination point.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. Model Structure 5. CSO Data Center Model Structure
module: ietf-cso-dc module: ietf-cso-dc
+--rw cso +--rw cso
+--rw dc* [id] +--rw dc* [id]
| +--rw hypervisor* [id] | +--rw hypervisor* [id]
| | +--rw ram | | +--rw ram
| | | +--rw total? uint32 | | | +--rw total? uint32
| | | +--rw used? uint32 | | | +--rw used? uint32
| | | +--rw free? uint32 | | | +--rw free? uint32
| | +--rw disk | | +--rw disk
skipping to change at page 17, line 38 skipping to change at page 18, line 23
| | +--rw id string | | +--rw id string
| | +--rw name? string | | +--rw name? string
| | +--rw cso-ref? -> /cso/cso-id | | +--rw cso-ref? -> /cso/cso-id
| +--rw ap* -> /actn-vn:actn/ap | +--rw ap* -> /actn-vn:actn/ap
/access-point-list/access-point-id /access-point-list/access-point-id
| +--rw cso-ref? -> /cso/cso-id | +--rw cso-ref? -> /cso/cso-id
| +--rw id string | +--rw id string
| +--rw name? string | +--rw name? string
+--rw cso-id? string +--rw cso-id? string
6. YANG Modules 6. CSO Data Center YANG Module
<CODE BEGINS> file "ietf-cso-dc@2017-01-16.yang" <CODE BEGINS> file "ietf-cso-dc@2017-01-16.yang"
module ietf-cso-dc module ietf-cso-dc
{ {
namespace "urn:ietf:params:xml:ns:yang:ietf-cso-dc"; namespace "urn:ietf:params:xml:ns:yang:ietf-cso-dc";
prefix "dc"; prefix "dc";
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
skipping to change at page 22, line 43 skipping to change at page 23, line 29
leaf ip-address { type inet:ip-address; } leaf ip-address { type inet:ip-address; }
leaf instance { type leafref { path '/cso/dc/instance/id'; } } leaf instance { type leafref { path '/cso/dc/instance/id'; } }
uses resource-instance; uses resource-instance;
} }
} }
<CODE ENDS> <CODE ENDS>
7. IANA Considerations 7. IANA Considerations
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number (and remove this note).
This document registers the following namespace URIs in the IETF XML This document registers the following namespace URIs in the IETF XML
registry [RFC3688]: registry [RFC3688]:
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
This document registers the following YANG modules in the YANG Module This document registers the following YANG modules in the YANG Module
Names registry [RFC7950]: Names registry [RFC6020]:
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-te-topology-sf name: ietf-te-topology-sf
namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet
prefix: tet-sf prefix: tet-sf
reference: RFC XXXX reference: RFC XXXX
-------------------------------------------------------------------- --------------------------------------------------------------------
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-te-topology-sf-state name: ietf-te-topology-sf-state
skipping to change at page 24, line 5 skipping to change at page 24, line 37
9. References 9. References
9.1. Normative References 9.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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<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>.
[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>.
[ETSI-NFV-MAN] [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
ETSI, "Network Functions Virtualisation (NFV); Management 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December May 2017, <https://www.rfc-editor.org/info/rfc8174>.
2014.
[I-D.ietf-i2rs-yang-network-topo] [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
Clemm, A., Medved, J., Varga, R., Bahadur, N., and R. Wilton, "Network Management Datastore Architecture
Ananthakrishnan, H., and X. Liu, "A Data Model for Network (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in <https://www.rfc-editor.org/info/rfc8342>.
progress), December 2017.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[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-18 (work in Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2018. progress), June 2019.
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-teas-yang-te]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
and R. Wilton, "Network Management Datastore "A YANG Data Model for Traffic Engineering Tunnels and
Architecture", draft-ietf-netmod-revised-datastores-10 Interfaces", draft-ietf-teas-yang-te-22 (work in
(work in progress), January 2018. progress), November 2019.
[I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
Yoon, "A Yang Data Model for VN Operation", draft-ietf-
teas-actn-vn-yang-07 (work in progress), October 2019.
[ETSI-NFV-MAN]
ETSI, "Network Functions Virtualisation (NFV); Management
and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December
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.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and
I. Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work
in progress), July 2018.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>. <https://www.rfc-editor.org/info/rfc3022>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[I-D.ietf-sfc-hierarchical] [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Dolson, D., Homma, S., Lopez, D., and M. Boucadair, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
"Hierarchical Service Function Chaining (hSFC)", draft- DOI 10.17487/RFC8453, August 2018,
ietf-sfc-hierarchical-11 (work in progress), June 2018. <https://www.rfc-editor.org/info/rfc8453>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/info/rfc8459>.
[I-D.defoy-netslices-3gpp-network-slicing] [I-D.defoy-netslices-3gpp-network-slicing]
Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case",
draft-defoy-netslices-3gpp-network-slicing-02 (work in draft-defoy-netslices-3gpp-network-slicing-02 (work in
progress), October 2017. progress), October 2017.
[_3GPP.28.801] [_3GPP.28.801]
3GPP, "Study on management and orchestration of network 3GPP, "Study on management and orchestration of network
slicing for next generation network", 3GPP TR 28.801 slicing for next generation network", 3GPP TR 28.801
V2.0.0, September 2017, V2.0.0, September 2017,
<http://www.3gpp.org/ftp/Specs/html-info/28801.htm>. <http://www.3gpp.org/ftp/Specs/html-info/28801.htm>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
9.2. Informative References 9.2. Informative References
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665> <https://www.rfc-editor.org/info/rfc7665>.
[I-D.ietf-netmod-yang-tree-diagrams] [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
ietf-netmod-yang-tree-diagrams-06 (work in progress), <https://www.rfc-editor.org/info/rfc8340>.
February 2018.
Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations
The YANG module ietf-te-topology-sf defined in this document is The YANG module ietf-te-topology-sf defined in this document is
designed to be used in conjunction with implementations that support designed to be used in conjunction with implementations that support
the Network Management Datastore Architecture (NMDA) defined in the Network Management Datastore Architecture (NMDA) defined in
[I-D.ietf-netmod-revised-datastores]. In order to allow [RFC8342]. In order to allow implementations to use the model even
implementations to use the model even in cases when NMDA is not in cases when NMDA is not supported, the following companion module,
supported, the following companion module, ietf-te-topology-sf-state, ietf-te-topology-sf-state, is defined as state model, which mirrors
is defined as state model, which mirrors the module ietf-te-topology- the module ietf-te-topology-sf defined earlier in this document.
sf defined earlier in this document. However, all data nodes in the However, all data nodes in the companion module are non-configurable,
companion module are non-configurable, to represent the applied to represent the applied configuration or the derived operational
configuration or the derived operational states. states.
The companion module, ietf-te-topology-sf-state, is redundant and The companion module, ietf-te-topology-sf-state, is redundant and
SHOULD NOT be supported by implementations that support NMDA. SHOULD NOT be supported by implementations that support NMDA.
As the structure of the companion module mirrors that of the As the structure of the companion module mirrors that of the
coorespinding NMDA model, the YANG tree of the companion module is coorespinding NMDA model, the YANG tree of the companion module is
not depicted separately. not depicted separately.
A.1. SF Aware TE Topology State Module A.1. SF Aware TE Topology State Module
<CODE BEGINS> file "ietf-te-topology-sf-state@2018-02-27.yang" <CODE BEGINS> file "ietf-te-topology-sf-state@2019-11-03.yang"
module ietf-te-topology-sf-state { module ietf-te-topology-sf-state {
yang-version 1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state";
prefix "tet-sf-s"; prefix "tet-sf-s";
import ietf-te-topology-sf { import ietf-te-topology-sf {
prefix "tet-sf"; prefix "tet-sf";
reference "RFC XXXX: SF Aware TE Topology YANG Model";
} }
import ietf-network-state { import ietf-network-state {
prefix "nw-s"; prefix "nw-s";
reference "RFC 8345: A YANG Data Model for Network Topologies";
} }
import ietf-network-topology-state { import ietf-network-topology-state {
prefix "nt-s"; prefix "nt-s";
reference "RFC 8345: A YANG Data Model for Network Topologies";
} }
import ietf-te-topology-state { import ietf-te-topology-state {
prefix "tet-s"; prefix "tet-s";
reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies";
} }
organization organization
"Traffic Engineering Architecture and Signaling (TEAS) "Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/teas/> "WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org> WG List: <mailto:teas@ietf.org>
Editors: Igor Bryskin Editors: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com> <mailto:Igor.Bryskin@huawei.com>
Xufeng Liu Xufeng Liu
<mailto:Xufeng_Liu@jabil.com>"; <mailto:Xufeng_Liu@jabil.com>";
description description
"Network service and function aware aware TE topology operational "Network service and function aware aware TE topology operational
state model for non-NMDA compliant implementations. state model for non-NMDA compliant implementations.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info)."; (http://trustee.ietf.org/license-info).
revision 2018-02-27 { This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
revision 2019-11-03 {
description "Initial revision"; description "Initial revision";
reference "TBD"; reference "RFC XXXX: SF Aware TE Topology YANG Model";
} }
/* /*
* Augmentations * Augmentations
*/ */
/* Augmentations to network-types/te-topology */ /* Augmentations to network-types/te-topology */
augment "/nw-s:networks/nw-s:network/nw-s:network-types/" augment "/nw-s:networks/nw-s:network/nw-s:network-types/"
+ "tet-s:te-topology" { + "tet-s:te-topology" {
description description
"Defines the SF aware TE topology type."; "Defines the SF aware TE topology type.";
skipping to change at page 38, line 5 skipping to change at page 39, line 5
defining a model, in which formally described/recognizable SF/NF defining a model, in which formally described/recognizable SF/NF
instances are presented as topological elements, for example, hosted instances are presented as topological elements, for example, hosted
by TE, L3 or L2 topology nodes (see Figure 1). The model could by TE, L3 or L2 topology nodes (see Figure 1). The model could
describe whether, how and at what costs the SFs/NFs hosted by a given describe whether, how and at what costs the SFs/NFs hosted by a given
node could be chained together, how these intra-node SFCs could be node could be chained together, how these intra-node SFCs could be
connected to the node's Service Function Forwarders (SFFs, entities connected to the node's Service Function Forwarders (SFFs, entities
dealing with SFC NSHs and metadata), and how the SFFs could be dealing with SFC NSHs and metadata), and how the SFFs could be
connected to the node's Tunnel and Link Termination Points (TTPs and connected to the node's Tunnel and Link Termination Points (TTPs and
LTPs) to chain the intra-node SFCs across the network topology. LTPs) to chain the intra-node SFCs across the network topology.
The figure is available in the PDF format.
Figure 1: SF/NF aware TE topology Figure 1: SF/NF aware TE topology
C.2. Flat End-to-end SFCs Managed on Multi-domain Networks C.2. Flat End-to-end SFCs Managed on Multi-domain Networks
SFCs may span multiple administrative domains, each of which SFCs may span multiple administrative domains, each of which
controlled by a separate SFC controller. The usual solution for such controlled by a separate SFC controller. The usual solution for such
a scenario is the Hierarchical SFCs (H-SFCs), in which the higher a scenario is the Hierarchical SFCs (H-SFCs) [RFC8459], in which the
level orchestrator controls only SFs located on domain border nodes. higher level orchestrator controls only SFs located on domain border
Said higher level SFs are chained together into higher level SFCs via nodes. Said higher level SFs are chained together into higher level
lower level (intra-domain) SFCs provisioned and controlled SFCs via lower level (intra-domain) SFCs provisioned and controlled
independently by respective domain controllers. The decision as to independently by respective domain controllers. The decision as to
which higher level SFCs are connected to which lower level SFCs is which higher level SFCs are connected to which lower level SFCs is
driven by packet re-classification every time the packet enters a driven by packet re-classification every time the packet enters a
given domain. Said packet re-classification is a very time-consuming given domain. Said packet re-classification is a very time-consuming
operation. Furthermore, the independent nature of higher and lower operation. Furthermore, the independent nature of higher and lower
level SFC control is prone to configuration errors, which may lead to level SFC control is prone to configuration errors, which may lead to
long lasting loops and congestions. It is highly desirable to be long lasting loops and congestions. It is highly desirable to be
able to set up and manage SFCs spanning multiple domains in a flat able to set up and manage SFCs spanning multiple domains in a flat
way as far as the data plane is concerned (i.e. with a single packet way as far as the data plane is concerned (i.e. with a single packet
classification at the ingress into the multi-domain network but classification at the ingress into the multi-domain network but
skipping to change at page 39, line 18 skipping to change at page 40, line 18
Some SFCs require per SFC link/element and end-to-end TE constrains Some SFCs require per SFC link/element and end-to-end TE constrains
(bandwidth, delay/jitter, fate sharing/diversity. etc.). Said (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said
constraints could be ensured via carrying SFPs inside overlays that constraints could be ensured via carrying SFPs inside overlays that
are traffic engineered with the constrains in mind. A good analogy are traffic engineered with the constrains in mind. A good analogy
would be orchestrating delay constrained L3 VPNs. One way to support would be orchestrating delay constrained L3 VPNs. One way to support
such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs
inside delay constrained TE tunnels interconnecting the PEs hosting inside delay constrained TE tunnels interconnecting the PEs hosting
the VRFs. the VRFs.
_
Figure 2: L3 VPN with delay constraints Figure 2: L3 VPN with delay constraints
Planning, computing and provisioning of TE overlays to constrain Planning, computing and provisioning of TE overlays to constrain
arbitrary SFCs, especially those that span multiple administrative arbitrary SFCs, especially those that span multiple administrative
domains with each domain controlled by a separate controller, is a domains with each domain controlled by a separate controller, is a
very difficult challenge. Currently it is addressed by pre- very difficult challenge. Currently it is addressed by pre-
provisioning on the network of multiple TE tunnels with various TE provisioning on the network of multiple TE tunnels with various TE
characteristics, and "nailing down" SFs/NFs to "strategic" locations characteristics, and "nailing down" SFs/NFs to "strategic" locations
(e.g. nodes terminating many of such tunnels) in a hope that an (e.g. nodes terminating many of such tunnels) in a hope that an
adequate set of tunnels could be found to carry the SFP of a given adequate set of tunnels could be found to carry the SFP of a given
skipping to change at page 40, line 11 skipping to change at page 41, line 11
will allow for the network orchestrator (or a client controller) to will allow for the network orchestrator (or a client controller) to
compute, set up and manipulate the TE overlays in the form of TE compute, set up and manipulate the TE overlays in the form of TE
tunnel chains (see Figure 3). tunnel chains (see Figure 3).
Said chains could be duel-optimized compromising on optimal SF/NF Said chains could be duel-optimized compromising on optimal SF/NF
locations with optimal TE tunnels interconnecting them. The TE locations with optimal TE tunnels interconnecting them. The TE
tunnel chains (carrying multiple similarly constrained SFPs) could be tunnel chains (carrying multiple similarly constrained SFPs) could be
adequately constrained both at individual TE tunnel level and at the adequately constrained both at individual TE tunnel level and at the
chain end-to-end level. chain end-to-end level.
_
Figure 3: SFC with TE constraints Figure 3: SFC with TE constraints
C.4. SFC Protection and Load Balancing C.4. SFC Protection and Load Balancing
Currently the combination of TE topology & tunnel models offers to a Currently the combination of TE topology & tunnel models offers to a
network controller various capabilities to recover an individual TE network controller various capabilities to recover an individual TE
tunnel from network failures occurred on one or more network links or tunnel from network failures occurred on one or more network links or
transit nodes on the TE paths taken by the TE tunnel's connection(s). transit nodes on the TE paths taken by the TE tunnel's connection(s).
However, there is no simple way to recover a TE tunnel from a failure However, there is no simple way to recover a TE tunnel from a failure
affecting its source or destination node. SF/NF-aware TE topology affecting its source or destination node. SF/NF-aware TE topology
skipping to change at page 41, line 12 skipping to change at page 42, line 12
functionally the same SFs/NFs as ones hosted by the failed node (see functionally the same SFs/NFs as ones hosted by the failed node (see
Figures 6). Figures 6).
This is in line with the ACTN edge migration and function mobility This is in line with the ACTN edge migration and function mobility
concepts [RFC8453]. It is important to note that the described concepts [RFC8453]. It is important to note that the described
strategy works much better for the stateless SFs/NFs. This is strategy works much better for the stateless SFs/NFs. This is
because getting the alternative stateful SFs/NFs into the same because getting the alternative stateful SFs/NFs into the same
respective states as the current (i.e. active, affected by failure) respective states as the current (i.e. active, affected by failure)
are is a very difficult challenge. are is a very difficult challenge.
_
Figure 4: SFC recovery: SF2 on node NE1 fails Figure 4: SFC recovery: SF2 on node NE1 fails
At the SFC level the SF/NF-aware TE topology model can offer SFC At the SFC level the SF/NF-aware TE topology model can offer SFC
dynamic restoration capabilities against failed/malfunctioning SFs/ dynamic restoration capabilities against failed/malfunctioning SFs/
NFs by identifying and provisioning detours to a TE tunnel chain, so NFs by identifying and provisioning detours to a TE tunnel chain, so
that it starts carrying the SFC's SFPs towards healthy SFs/NFs that that it starts carrying the SFC's SFPs towards healthy SFs/NFs that
are functionally the same as the failed ones. Furthermore, multiple are functionally the same as the failed ones. Furthermore, multiple
parallel TE tunnel chains could be pre-provisioned for the purpose of parallel TE tunnel chains could be pre-provisioned for the purpose of
SFC load balancing and end-to-end protection. In the latter case SFC load balancing and end-to-end protection. In the latter case
said parallel TE tunnel chains could be placed to be sufficiently said parallel TE tunnel chains could be placed to be sufficiently
disjoint from each other. disjoint from each other.
_
Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on
node N1 has failed node N1 has failed
_
Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1
has failed has failed
C.5. Network Clock Synchronization C.5. Network Clock Synchronization
Many current and future network applications (including 5g and IoT Many current and future network applications (including 5g and IoT
applications) require very accurate time services (PTP level, ns applications) require very accurate time services (PTP level, ns
resolution). One way to implement the adequate network clock resolution). One way to implement the adequate network clock
synchronization for such services is via describing network clocks as synchronization for such services is via describing network clocks as
NFs on an NF-aware TE topology optimized to have best possible delay NFs on an NF-aware TE topology optimized to have best possible delay
skipping to change at page 45, line 5 skipping to change at page 46, line 5
o Ensure recovery of such chains from any failures that could happen o Ensure recovery of such chains from any failures that could happen
on links, nodes or regenerators along the chain path. on links, nodes or regenerators along the chain path.
NF-aware TE topology model (in this case L1 NF-aware L0 topology NF-aware TE topology model (in this case L1 NF-aware L0 topology
model) is just the model that could provide a network controller (or model) is just the model that could provide a network controller (or
even a client controller operating on abstract NF-aware topologies even a client controller operating on abstract NF-aware topologies
provided by the network) to realize described above computations and provided by the network) to realize described above computations and
orchestrate the service provisioning and network failure recovery orchestrate the service provisioning and network failure recovery
operations (see Figure 7). operations (see Figure 7).
_
Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators.
Red trail (not regenerated) is not optically reachable, but blue Red trail (not regenerated) is not optically reachable, but blue
trail (twice regenerated) is trail (twice regenerated) is
C.8. Dynamic Assignment of OAM Functions for L1 Services C.8. Dynamic Assignment of OAM Functions for L1 Services
OAM functionality is normally managed by configuring and manipulating OAM functionality is normally managed by configuring and manipulating
TCM/MEP functions on network ports terminating connections or their TCM/MEP functions on network ports terminating connections or their
segments over which OAM operations, such as performance monitoring, segments over which OAM operations, such as performance monitoring,
are required to be performed. In some layer networks (e.g. are required to be performed. In some layer networks (e.g.
skipping to change at page 46, line 5 skipping to change at page 47, line 5
(but not all network ports) due to the fact that the OAM (but not all network ports) due to the fact that the OAM
functionality (i.e. recognizing and processing of OAM messages, functionality (i.e. recognizing and processing of OAM messages,
supporting OAM protocols and FSMs) requires in these layer networks supporting OAM protocols and FSMs) requires in these layer networks
certain support in the data plane, which is not available on all certain support in the data plane, which is not available on all
network nodes. This makes TCMs/MEPs good candidates to be modeled as network nodes. This makes TCMs/MEPs good candidates to be modeled as
NFs. This also makes TCM/MEP aware topology model a good basis for NFs. This also makes TCM/MEP aware topology model a good basis for
placing dynamically an ODUk connection to pass through optimal OAM placing dynamically an ODUk connection to pass through optimal OAM
locations without mandating the client to specify said locations locations without mandating the client to specify said locations
explicitly. explicitly.
_
Figure 8: Compute/storage resource aware topology Figure 8: Compute/storage resource aware topology
C.9. SFC Abstraction and Scaling C.9. SFC Abstraction and Scaling
SF/NF-aware topology may contain information on native SFs/NFs (i.e. SF/NF-aware topology may contain information on native SFs/NFs (i.e.
SFs/NFs as known to the provider itself) and/or abstract SFs/NFs SFs/NFs as known to the provider itself) and/or abstract SFs/NFs
(i.e. logical/macro SFs/NFs representing one or more SFCs each made (i.e. logical/macro SFs/NFs representing one or more SFCs each made
of native and/or lower level abstract SFs/NFs). As in the case of of native and/or lower level abstract SFs/NFs). As in the case of
abstracting topology nodes, abstracting SFs/NFs is hierarchical in abstracting topology nodes, abstracting SFs/NFs is hierarchical in
nature - the higher level of SF/NF-aware topology, the "larger" nature - the higher level of SF/NF-aware topology, the "larger"
skipping to change at page 47, line 23 skipping to change at page 48, line 23
resources include: caches, mirrors, application specific servers, resources include: caches, mirrors, application specific servers,
content, large data sets, and computing power. Application service content, large data sets, and computing power. Application service
is a networked application offered to a variety of clients (e.g., is a networked application offered to a variety of clients (e.g.,
server backup, VM migration, video cache, virtual network on-demand, server backup, VM migration, video cache, virtual network on-demand,
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 C.12. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
C.13. Security Considerations C.13. Security Considerations
This document does not define networking protocols and data, hence is This document does not define networking protocols and data, hence is
not directly responsible for security risks. not directly responsible for security risks.
C.14. Acknowledgements 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
Huawei Technologies Individual
EMail: Igor.Bryskin@huawei.com EMail: i_bryskin@yahoo.com
Xufeng Liu Xufeng Liu
Volta Networks Volta Networks
EMail: xufeng.liu.ietf@gmail.com EMail: xufeng.liu.ietf@gmail.com
Young Lee Young Lee
Huawei Technologies Sung Kyun Kwan University
EMail: leeyoung@huawei.com EMail: younglee.tx@gmail.com
Jim Guichard Jim Guichard
Huawei Technologies Huawei Technologies
EMail: james.n.guichard@huawei.com EMail: james.n.guichard@huawei.com
Luis Miguel Contreras Murillo Luis Miguel Contreras Murillo
Telefonica Telefonica
EMail: luismiguel.contrerasmurillo@telefonica.com EMail: luismiguel.contrerasmurillo@telefonica.com
 End of changes. 74 change blocks. 
141 lines changed or deleted 206 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/