draft-ietf-teas-sf-aware-topo-model-00.txt   draft-ietf-teas-sf-aware-topo-model-01.txt 
Network Working Group I. Bryskin Network Working Group I. Bryskin
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational X. Liu Intended status: Informational X. Liu
Expires: December 6, 2018 Jabil Expires: December 30, 2018 Volta Networks
June 4, 2018 Y. Lee
Huawei Technologies
June 28, 2018
SF Aware TE Topology YANG Model SF Aware TE Topology YANG Model
draft-ietf-teas-sf-aware-topo-model-00 draft-ietf-teas-sf-aware-topo-model-01
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 32 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 6, 2018. This Internet-Draft will expire on December 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 11 skipping to change at page 2, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3
2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 3 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 4
3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4 3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 5
4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 6 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Companion YANG Model for Non-NMDA Compliant Appendix A. Companion YANG Model for Non-NMDA Compliant
Implementations . . . . . . . . . . . . . . . . . . 16 Implementations . . . . . . . . . . . . . . . . . . 24
A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 16 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 24
Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 18 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 26
B.1. A Topology with Multiple Connected Network Functions . . 18 B.1. A Topology with Multiple Connected Network Functions . . 26
B.2. A Topology with an Encapsulated Network Service . . . . . 23 B.2. A Topology with an Encapsulated Network Service . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
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 allocated for and assigned to a client. As described in
[I-D.bryskin-teas-use-cases-sf-aware-topo-model], there are some [I-D.ietf-teas-use-cases-sf-aware-topo-model], there are some
important use cases, in which the network needs to represent to the important use cases, in which the network needs to represent to the
client SFs at the client's disposal as topological elements in client SFs at the client's disposal as topological elements in
relation to other elements of a topology (i.e. nodes, links, link and relation to other elements of a topology (i.e. nodes, links, link and
tunnel termination points) used by the network to describe itself to tunnel termination points) used by the network to describe itself to
the client. Not only would such information allow for the client to the client. Not only would such information allow for the client to
auto-discover the network's SFs available for the services auto-discover the network's SFs available for the services
provisioned for the client, it would also allow for the client provisioned for the client, it would also allow for the client
selecting the SFs, duel-optimizing the selection on the SF location selecting the SFs, duel-optimizing the selection on the SF location
on the network and connectivity means (e.g. TE tunnels) to inter- on the network and connectivity means (e.g. TE tunnels) to inter-
connect the SFs. Consequently thus would give to both the network connect the SFs. Consequently thus would give to both the network
skipping to change at page 4, line 44 skipping to change at page 4, line 51
and hence to SFs residing on other TE nodes on the topology that and hence to SFs residing on other TE nodes on the topology that
could be inter-connected with the TE node in question via TE could be inter-connected with the TE node in question via TE
tunnels terminated by the corresponding TTPs. 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
for SF-aware Topology. Section 5 and 6 provide the YANG model
structure and the YANG module for Data Center Compute Node resource
abstraction. This provides an example of SF2LTP CM where DC compute
nodes are connected to LTPs at the remote ends of the corresponding
TE links. This use-case is described in Section 12 of
[I-D.ietf-teas-use-cases-sf-aware-topo-model].
3. Model Structure 3. 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]
skipping to change at page 13, line 28 skipping to change at page 13, line 42
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. IANA Considerations 5. Model Structure
module: ietf-cso-dc
+--rw cso
+--rw dc* [id]
| +--rw hypervisor* [id]
| | +--rw ram
| | | +--rw total? uint32
| | | +--rw used? uint32
| | | +--rw free? uint32
| | +--rw disk
| | | +--rw total? uint32
| | | +--rw used? uint32
| | | +--rw free? uint32
| | +--rw vcpu
| | | +--rw total? uint16
| | | +--rw used? uint16
| | | +--rw free? uint16
| | +--rw instance* -> /cso/dc/instance/id
| | +--rw id string
| | +--rw name? string
| +--rw instance* [id]
| | +--rw flavor
| | | +--rw disk? uint32
| | | +--rw ram? uint32
| | | +--rw vcpus? uint16
| | | +--rw id? string
| | | +--rw name? string
| | +--rw image
| | | +--rw checksum string
| | | +--rw size uint32
| | | +--rw format
| | | | +--rw container? enumeration
| | | | +--rw disk? enumeration
| | | +--rw id? string
| | | +--rw name? string
| | +--rw hypervisor? -> /cso/dc/hypervisor/id
| | +--rw port* -> /cso/dc/network/subnetwork/port
/id
| | +--rw project? string
| | +--rw status? enumeration
| | +--rw id string
| | +--rw name? string
| +--rw image* [id]
| | +--rw checksum string
| | +--rw size uint32
| | +--rw format
| | | +--rw container? enumeration
| | | +--rw disk? enumeration
| | +--rw id string
| | +--rw name? string
| +--rw flavor* [id]
| | +--rw disk? uint32
| | +--rw ram? uint32
| | +--rw vcpus? uint16
| | +--rw id string
| | +--rw name? string
| +--rw dc-monitoring-param* [name]
| | +--rw name string
| | +--rw value-string? string
| +--rw network* [id]
| | +--rw subnetwork* [id]
| | | +--rw port* [id]
| | | | +--rw ip-address? inet:ip-address
| | | | +--rw instance? -> /cso/dc/instance/id
| | | | +--rw project? string
| | | | +--rw status? enumeration
| | | | +--rw id string
| | | | +--rw name? string
| | | +--rw project? string
| | | +--rw status? enumeration
| | | +--rw id string
| | | +--rw name? string
| | +--rw dhcp-agent* [id]
| | | +--rw enabled? boolean
| | | +--rw pools* [ip-address]
| | | | +--rw ip-address inet:ip-address
| | | +--rw project? string
| | | +--rw status? enumeration
| | | +--rw id string
| | | +--rw name? string
| | +--rw project? string
| | +--rw status? enumeration
| | +--rw id string
| | +--rw name? string
| | +--rw cso-ref? -> /cso/cso-id
| +--rw ap* -> /actn-vn:actn/ap
/access-point-list/access-point-id
| +--rw cso-ref? -> /cso/cso-id
| +--rw id string
| +--rw name? string
+--rw cso-id? string
6. YANG Modules
<CODE BEGINS> file "ietf-cso-dc@2017-01-16.yang"
module ietf-cso-dc
{
namespace "urn:ietf:params:xml:ns:yang:ietf-cso-dc";
prefix "dc";
import ietf-inet-types {
prefix "inet";
}
import ietf-actn-vn {
prefix "actn-vn";
}
revision 2017-01-16 {
description
"Initial revision. This YANG file defines
the reusable base types for CSO DC description.";
reference
"Derived from earlier versions of base YANG files";
}
// Abstract models
grouping resource-element {
leaf id { type string; }
leaf name { type string; }
}
grouping resource-instance {
leaf project{ type string; }
leaf status {
type enumeration {
enum active;
enum inactive;
enum pending;
}
}
uses resource-element;
}
// Compute models
grouping format {
leaf container {
type enumeration {
enum ami;
enum ari;
enum aki;
enum bare;
enum ovf;
}
default bare;
}
leaf disk {
type enumeration {
enum ami;
enum ari;
enum aki;
enum vhd;
enum vmdk;
enum raw;
enum qcow2;
enum vdi;
enum iso;
}
default qcow2;
}
}
grouping image {
leaf checksum { type string; mandatory true; }
leaf size { type uint32; units 'Bytes'; mandatory true; }
container format {
uses format;
}
uses resource-element;
}
grouping flavor {
leaf disk { type uint32; units 'GB'; default 0; }
leaf ram { type uint32; units 'MB'; default 0; }
leaf vcpus { type uint16; default 0; }
uses resource-element;
}
grouping ram {
leaf total { type uint32; units 'MB'; }
leaf used { type uint32; units 'MB'; }
leaf free { type uint32; units 'MB'; }
}
grouping disk {
leaf total { type uint32; units 'GB'; }
leaf used { type uint32; units 'GB'; }
leaf free { type uint32; units 'GB'; }
}
grouping vcpu {
leaf total { type uint16; }
leaf used { type uint16; }
leaf free { type uint16; }
}
grouping hypervisor {
container ram {
uses ram;
}
container disk {
uses disk;
}
container vcpu {
uses vcpu;
}
leaf-list instance {
type leafref { path '/cso/dc/instance/id'; } }
uses resource-element;
}
grouping instance {
container flavor { uses flavor; }
container image { uses image; }
leaf hypervisor {
type leafref { path '/cso/dc/hypervisor/id'; } }
leaf-list port { type leafref {
path '/cso/dc/network/subnetwork/port/id'; } }
uses resource-instance;
}
grouping dc-monitoring-param {
leaf name {
description "dc-monitoring-param identifier"; type string; }
leaf value-string {
description
"Current value for a string parameter";
type string;
}
}
grouping dc {
list hypervisor {
key id;
uses hypervisor;
}
list instance {
key id;
uses instance;
}
list image {
key id;
uses image;
}
list flavor {
key id;
uses flavor;
}
list dc-monitoring-param {
key "name";
uses dc-monitoring-param;
}
list network {
key id;
uses network;
}
leaf-list ap { type leafref {
path
'/actn-vn:actn/actn-vn:ap/actn-vn:access-point-list/'
+ 'actn-vn:access-point-id';
}
}
leaf cso-ref { type leafref { path "/cso/cso-id"; } }
uses resource-element;
}
container cso {
list dc {
key id;
uses dc;
}
leaf cso-id { type string; }
}
// Network models
grouping ip-address {
leaf ip-address { type inet:ip-address; }
}
grouping dhcp-agent {
leaf enabled { type boolean; }
list pools {
key ip-address;
uses ip-address;
}
uses resource-instance;
}
grouping network {
list subnetwork {
key id;
uses subnetwork;
}
list dhcp-agent {
key id;
uses dhcp-agent;
}
uses resource-instance;
leaf cso-ref { type leafref { path "/cso/cso-id"; } }
}
grouping subnetwork {
list port {
key id;
uses port;
}
uses resource-instance;
}
grouping port {
leaf ip-address { type inet:ip-address; }
leaf instance { type leafref { path '/cso/dc/instance/id'; } }
uses resource-instance;
}
}
<CODE ENDS>
7. IANA Considerations
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number (and remove this note). 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.
skipping to change at page 14, line 19 skipping to change at page 21, line 37
reference: RFC XXXX reference: RFC XXXX
-------------------------------------------------------------------- --------------------------------------------------------------------
-------------------------------------------------------------------- --------------------------------------------------------------------
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 8. Security Considerations
The configuration, state, action and notification data defined in The configuration, state, action and notification data defined in
this document are designed to be accessed via the NETCONF protocol this document are designed to be accessed via the NETCONF protocol
[RFC6241]. The data-model by itself does not create any security [RFC6241]. The data-model by itself does not create any security
implications. The security considerations for the NETCONF protocol implications. The security considerations for the NETCONF protocol
are applicable. The NETCONF protocol used for sending the data are applicable. The NETCONF protocol used for sending the data
supports authentication and encryption. supports authentication and encryption.
7. References 9. References
7.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>.
[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>.
skipping to change at page 15, line 10 skipping to change at page 22, line 28
[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] [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.
[I-D.bryskin-teas-use-cases-sf-aware-topo-model] [I-D.ietf-teas-use-cases-sf-aware-topo-model]
Bryskin, I., Liu, X., Guichard, J., Lee, Y., Contreras, Bryskin, I., Liu, X., Guichard, J., Lee, Y., Contreras,
L., Ceccarelli, D., and J. Tantsura, "Use Cases for SF L., Ceccarelli, D., and J. Tantsura, "Use Cases for SF
Aware Topology Models", draft-bryskin-teas-use-cases-sf- Aware Topology Models", draft-ietf-teas-use-cases-sf-
aware-topo-model-03 (work in progress), March 2018. aware-topo-model-00 (work in progress), June 2018.
[I-D.ietf-i2rs-yang-network-topo] [I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N., Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A Data Model for Network Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in
progress), December 2017. progress), December 2017.
[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-15 (work in Topologies", draft-ietf-teas-yang-te-topo-16 (work in
progress), February 2018. progress), June 2018.
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-10 Architecture", draft-ietf-netmod-revised-datastores-10
(work in progress), January 2018. (work in progress), January 2018.
7.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>.
skipping to change at page 27, line 17 skipping to change at page 35, line 17
} }
Authors' Addresses Authors' Addresses
Igor Bryskin Igor Bryskin
Huawei Technologies Huawei Technologies
EMail: Igor.Bryskin@huawei.com EMail: Igor.Bryskin@huawei.com
Xufeng Liu Xufeng Liu
Jabil Volta Networks
EMail: Xufeng_Liu@jabil.com EMail: xufeng.liu.ietf@gmail.com
Young Lee
Huawei Technologies
EMail: leeyoung@huawei.com
 End of changes. 18 change blocks. 
29 lines changed or deleted 373 lines changed or added

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