< draft-ietf-teas-sf-aware-topo-model-06.txt   draft-ietf-teas-sf-aware-topo-model-07.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: May 23, 2021 Volta Networks Expires: August 25, 2021 Volta Networks
Y. Lee Y. Lee
Sung Kyun Kwan University Samsung Electronics
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 19, 2020 D. Shytyi
SFR
February 21, 2021
SF Aware TE Topology YANG Model SF Aware TE Topology YANG Model
draft-ietf-teas-sf-aware-topo-model-06 draft-ietf-teas-sf-aware-topo-model-07
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 44
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 May 23, 2021. This Internet-Draft will expire on August 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 2, line 48 skipping to change at page 3, line 4
C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 34 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 34
C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 35 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 35
C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 36 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 36
C.5. Network Clock Synchronization . . . . . . . . . . . . . . 39 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 39
C.6. Client - Provider Network Slicing Interface . . . . . . . 39 C.6. Client - Provider Network Slicing Interface . . . . . . . 39
C.7. Dynamic Assignment of Regenerators for L0 Services . . . 39 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 39
C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 41 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 41
C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 42 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 42
C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 42 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 42
C.11. Application-aware Resource Operations and Management . . 43 C.11. Application-aware Resource Operations and Management . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 C.12. Interconnection between Service Functions/Termination
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Points in uCPE . . . . . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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 [RFC8795] elements, such as ports, link termination points and nodes [RFC8795]
[I-D.ietf-teas-yang-te]. However, the connectivity services, [I-D.ietf-teas-yang-te]. However, the connectivity services,
skipping to change at page 4, line 20 skipping to change at page 4, line 23
14, [RFC2119] [RFC8174] when, and only when, they appear in all 14, [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 Function(s) and/or Network
its functional and behavioural specification. The Network Service Service(s), defined by its functional and behavioural
contributes to the behaviour of the higher layer service, which is specification. The Network Service contributes to the behaviour
characterized by at least performance, dependability, and security of the higher layer service, which is characterized by at least
specifications. The end-to-end network service behaviour is the performance, dependability, and security specifications. The end-
result of the combination of the individual network function to-end network service behaviour is the result of the combination
behaviours as well as the behaviours of the network infrastructure of the individual network function behaviours as well as the
composition mechanism [ETSI-NFV-TERM]. behaviours of the network infrastructure composition mechanism
[ETSI-NFV-TERM].
o Service Function (SF): A function that is responsible for specific o Service Function (SF): A function that is responsible for specific
treatment of received packets. A service function can act at treatment of received packets. A service function can act at
various layers of a protocol stack (e.g., at the network layer or various layers of a protocol stack (e.g., at the network layer or
other OSI layers). As a logical component, a service function can other OSI layers). As a logical component, a service function can
be realized as a virtual element or be embedded in a physical be realized as a virtual element or be embedded in a physical
network element. One or more service functions can be embedded in network element. One or more service functions can be embedded in
the same network element. Multiple occurrences of the service the same network element. Multiple occurrences of the service
function can exist in the same administrative domain. A non- function can exist in the same administrative domain. A non-
exhaustive list of service functions includes: firewalls, WAN and exhaustive list of service functions includes: firewalls, WAN and
skipping to change at page 9, line 7 skipping to change at page 9, line 7
+--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. SF Aware TE Topology YANG Module 4. SF Aware TE Topology YANG Module
<CODE BEGINS> file "ietf-te-topology-sf@2019-11-03.yang" <CODE BEGINS> file "ietf-te-topology-sf@2021-02-15.yang"
module ietf-te-topology-sf { module ietf-te-topology-sf {
yang-version 1.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"; 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"; reference
"RFC 8345: A YANG Data Model for Network Topologies";
} }
import ietf-te-topology { import ietf-te-topology {
prefix "tet"; prefix "tet";
reference reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Engineering (TE) Topologies"; 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.ietf@gmail.com>";
description description
"Network service and function aware aware TE topology model. "Network service and function aware aware TE topology model.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2021 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).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2019-11-03 { revision 2021-02-15 {
description "Initial revision"; description "Initial revision";
reference "RFC XXXX: SF Aware TE Topology YANG Model"; 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" {
skipping to change at page 11, line 4 skipping to change at page 11, line 5
direction."; direction.";
} // connectivity-direction } // connectivity-direction
/* /*
* Groupings * Groupings
*/ */
grouping service-function-node-augmentation { grouping service-function-node-augmentation {
description description
"Augmenting a TE node to be network service and function "Augmenting a TE node to be network service and function
aware."; aware.";
container service-function { container service-function {
description description
"Containing attributes related to network services and "Containing attributes related to network services and
network functions"; network functions";
container connectivity-matrices { container connectivity-matrices {
description description
"Connectivity relations between network services/functions "Connectivity relations between network services/functions
on a TE node, which can be either abstract or physical."; on a TE node, which can be either abstract or physical.";
reference reference
"ETSI GS NFV-MAN 01: Network Functions Virtualisation "ETSI GS NFV-SOL 006: Network Functions Virtualisation
(NFV); Management and Orchestration. (NFV) Release 3; Protocols and Data Models;
NFV descriptors based on YANG specification.
RFC7665: Service Function Chaining (SFC) Architecture."; RFC7665: Service Function Chaining (SFC) Architecture.";
list connectivity-matrix { list connectivity-matrix {
key "id"; key "id";
description description
"Represents the connectivity relations between network "Represents the connectivity relations between network
services/functions on a TE node."; services/functions on a TE node.";
leaf id { leaf id {
type uint32; type uint32;
description "Identifies the connectivity-matrix entry."; description "Identifies the connectivity-matrix entry.";
} }
skipping to change at page 12, line 42 skipping to change at page 12, line 43
} }
} // connectivity-matrix } // connectivity-matrix
} // connectivity-matrices } // connectivity-matrices
container link-terminations { container link-terminations {
description description
"Connectivity relations between network services/functions "Connectivity relations between network services/functions
and link termination points on a TE node, which can be and link termination points on a TE node, which can be
either abstract or physical."; either abstract or physical.";
reference reference
"ETSI GS NFV-MAN 01: Network Functions Virtualisation "ETSI GS NFV-SOL 006: Network Functions Virtualisation
(NFV); Management and Orchestration. (NFV) Release 3; Protocols and Data Models;
NFV descriptors based on YANG specification.
RFC7665: Service Function Chaining (SFC) Architecture."; RFC7665: Service Function Chaining (SFC) Architecture.";
list link-termination { list link-termination {
key "id"; key "id";
description description
"Each entry of the list represents the connectivity "Each entry of the list represents the connectivity
relation between a network service/function and relation between a network service/function and
a link termination point on a TE node."; a link termination point on a TE node.";
leaf id { leaf id {
type uint32; type uint32;
description "Identifies the termination entry."; description "Identifies the termination entry.";
skipping to change at page 14, line 12 skipping to change at page 14, line 15
container service-function { container service-function {
description description
"Containing attributes related to network services and "Containing attributes related to network services and
network functions"; network functions";
container tunnel-terminations { container tunnel-terminations {
description description
"Connectivity relations between network services/functions "Connectivity relations between network services/functions
and tunnel termination points on a TE node, which can be and tunnel termination points on a TE node, which can be
either abstract or physical."; either abstract or physical.";
reference reference
"ETSI GS NFV-MAN 01: Network Functions Virtualisation "ETSI GS NFV-SOL 006: Network Functions Virtualisation
(NFV); Management and Orchestration. (NFV) Release 3; Protocols and Data Models;
NFV descriptors based on YANG specification.
RFC7665: Service Function Chaining (SFC) Architecture."; RFC7665: Service Function Chaining (SFC) Architecture.";
list tunnel-termination { list tunnel-termination {
key "id"; key "id";
description description
"Each entry of the list represents the connectivity "Each entry of the list represents the connectivity
relation between a network service/function and relation between a network service/function and
a tunnel termination point on a TE node."; a tunnel termination point on a TE node.";
leaf id { leaf id {
type uint32; type uint32;
description "Identifies the termination entry."; description "Identifies the termination entry.";
skipping to change at page 20, line 5 skipping to change at page 20, line 9
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Data Model for Network Instances", RFC 8529,
DOI 10.17487/RFC8529, March 2019,
<https://www.rfc-editor.org/info/rfc8529>.
[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Model for Logical Network Elements", RFC 8530,
DOI 10.17487/RFC8530, March 2019,
<https://www.rfc-editor.org/info/rfc8530>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795, Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020, DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>. <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, Label "A YANG Data Model for Traffic Engineering Tunnels, Label
Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
(work in progress), July 2020. (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-10 (work in progress), November 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) Release 3;
and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December Protocols and Data Models; NFV descriptors based on YANG
2014. specification", ETSI GS NFV-SOL 006 V3.3.1, August 2020,
<https://www.etsi.org/deliver/etsi_gs/NFV-
SOL/001_099/006/03.03.01_60/gs_NFV-SOL006v030301p.pdf>.
[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 GR NFV 003 V1.5.1, January
December 2014. 2020, <https://www.etsi.org/deliver/etsi_gr/
NFV/001_099/003/01.05.01_60/gr_NFV003v010501p.pdf>.
[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>.
skipping to change at page 21, line 5 skipping to change at page 21, line 20
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459, "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018, DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/info/rfc8459>. <https://www.rfc-editor.org/info/rfc8459>.
[I-D.defoy-netslices-3gpp-network-slicing]
Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case",
draft-defoy-netslices-3gpp-network-slicing-02 (work in
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>.
7.2. Informative References 7.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,
skipping to change at page 22, line 5 skipping to change at page 21, line 42
[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>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[I-D.defoy-netslices-3gpp-network-slicing]
Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case",
draft-defoy-netslices-3gpp-network-slicing-02 (work in
progress), October 2017.
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
[RFC8342]. In order to allow implementations to use the model even [RFC8342]. In order to allow implementations to use the model even
in cases when NMDA is not supported, the following companion module, in cases when NMDA is not supported, the following companion module,
ietf-te-topology-sf-state, is defined as state model, which mirrors ietf-te-topology-sf-state, is defined as state model, which mirrors
the module ietf-te-topology-sf defined earlier in this document. the module ietf-te-topology-sf defined earlier in this document.
However, all data nodes in the companion module are non-configurable, However, all data nodes in the companion module are non-configurable,
skipping to change at page 22, line 27 skipping to change at page 22, line 27
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@2019-11-03.yang" <CODE BEGINS> file "ietf-te-topology-sf-state@2021-02-15.yang"
module ietf-te-topology-sf-state { module ietf-te-topology-sf-state {
yang-version 1.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"; 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"; 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"; 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 reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Engineering (TE) Topologies"; 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.ietf@gmail.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) 2019 IETF Trust and the persons identified as Copyright (c) 2021 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).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2019-11-03 { revision 2021-02-15 {
description "Initial revision"; description "Initial revision";
reference "RFC XXXX: SF Aware TE Topology YANG Model"; 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" {
skipping to change at page 35, line 18 skipping to change at page 35, 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.
_ The figure is available in the PDF format.
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
skipping to change at page 36, line 11 skipping to change at page 36, 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.
_ The figure is available in the PDF format.
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
skipping to change at page 37, line 12 skipping to change at page 37, 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.
_ The figure is available in the PDF format.
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.
_ The figure is available in the PDF format.
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
_ The figure is available in the PDF format.
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
skipping to change at page 41, line 5 skipping to change at page 41, 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).
_ The figure is available in the PDF format.
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,
skipping to change at page 42, line 5 skipping to change at page 42, 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.
_ The figure is available in the PDF format.
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
skipping to change at page 43, line 23 skipping to change at page 43, 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.
_ The figure is available in the PDF format.
Figure 9: Application aware topology Figure 9: Application aware topology
C.12. Interconnection between Service Functions/Termination Points in
uCPE
Universal Customer Premises Equipment (uCPE) enables Virtual Network
Functions (VNFs) at the client site. uCPE is based on the Network
Function Virtualization Infrastructure (NFVI) - generally Linux
distribution with integrated software that offers:
o Virtual Switch functionality
o Full virtualization/containerization solution
o Data path acceleration tool-kits
o Management layer
The sf-aware-topo-model placed in the controller controls via the
management layer of uCPE the interconnection between:
o virtual ports of VNFs
o virtual ports of Virtual Switch abstraction elements
o physical ports of uCPE
Figure 10 shows an example application aware topology for
interconnection between Logical Network Elements [RFC8530], Network
Instances [RFC8529], uCPE node Termination Points [RFC8345]. In
Figure 10 the following elements are presented:
o 3 Logical Network Elements (vCPEL3_WAN1,vCPEL3_WAN2,vSD-WAN)
o 4 Network Instances (vCPEL2)
o 4 Termination Points (Physical Ports)
There are two types of access provided to the client.
The 1st access "Internet" topology part: 1st uCPE Termination Point
"WAN1_port_internet" -- NI (vCPEL2) -- LNE (vCPEL3_telco_internet) --
NI (vCPEL2) -- vSD-WAN_port_internet.
The 2nd access "MPLS" topology part: 2nd Termination Point
"WAN2_port_mpls" -- NI (vCPEL2) -- LNE (vCPEL3_telco_mpls) -- NI
(vCPEL2) -- vSD-WAN_port_mpls.
Finally SD-WAN balances the traffic via two WAN ports (Termination
Points) of uCPE and shares the connection to LAN ports (Termination
Points).
The figure is available in the PDF format.
Figure 10: uCPE Service Functions topology
An example of an instance data tree in the XML format is presented in
Figure 12, following the uCPE Service Functions topology presented in
Figure 11.
For this example, the interconnection goes as follows: Network-facing
Provider Edge (N-PE) router -- User-facing Provider Edge (U-PE)
router -- uCPE ( Termination Point WAN -- NI (vCPEL2) -- LNE (vCPEL3)
)
In uCPE, Termination Point (WAN) has id 1. On the NNI
(connectionpoint_id == 10) port of NI the trunk mode is configured.
On UNI ports of NI (cp_id == 13) access mode is configured. Port
with cp_id == 13 is connected to LNE cp_id = 1.
The figure is available in the PDF format.
Figure 11: uCPE Service Functions topology (simple)
<config>
<networks xmlns="urn:ietf:params:xml:ns:yang:ietf-network">
<network>
<network-id>network1</network-id>
<network-types>
<te-topology
xmlns="urn:ietf:params:xml:ns:yang:ietf-te-topology">
<sf xmlns=
"urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"/>
</te-topology>
</network-types>
<node>
<node-id>uCPE1</node-id>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>1</tp-id>
<tp-properties
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-ucpe-node-type">
<ethernet>
<duplex>full</duplex>
</ethernet>
<mtu>1500</mtu>
<type>dpdk</type>
</tp-properties>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>2</tp-id>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>3</tp-id>
</termination-point>
<te-node-id
xmlns= "urn:ietf:params:xml:ns:yang:ietf-te-topology"
>0.0.0.0</te-node-id>
<te xmlns="urn:ietf:params:xml:ns:yang:ietf-te-topology">
<te-node-attributes>
<service-function
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-te-topology-sf">
<connectivity-matrices>
<connectivity-matrix>
<id>1</id>
<from>
<service-function-id>CPEL3</service-function-id>
<sf-connection-point-id
>1</sf-connection-point-id>
</from>
<to>
<service-function-id>CPEL2</service-function-id>
<sf-connection-point-id
>13</sf-connection-point-id>
</to>
<enabled>true</enabled>
<virtual-link-id>l10</virtual-link-id>
</connectivity-matrix>
</connectivity-matrices>
<link-terminations>
<link-termination>
<id>2</id>
<from>
<tp-ref>1</tp-ref>
</from>
<to>
<service-function-id>CPEL2</service-function-id>
<sf-connection-point-id
>10</sf-connection-point-id>
</to>
<virtual-link-id
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-ucpe-lt-virtual-link-id"
>l11</virtual-link-id>
</link-termination>
</link-terminations>
</service-function>
</te-node-attributes>
</te>
<node-type
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-ucpe-node-type"
>ucpe</node-type>
</node>
<node>
<node-id>N-PE</node-id>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>1</tp-id>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>2</tp-id>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>3</tp-id>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>4</tp-id>
</termination-point>
</node>
<node>
<node-id>U-PE</node-id>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>1</tp-id>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>2</tp-id>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>3</tp-id>
</termination-point>
<termination-point
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-network-topology">
<tp-id>4</tp-id>
</termination-point>
</node>
<link
xmlns="urn:ietf:params:xml:ns:yang:ietf-network-topology">
<link-id>1</link-id>
<source>
<source-node>N-PE</source-node>
<source-tp>2</source-tp>
</source>
<destination>
<dest-node>U-PE</dest-node>
<dest-tp>1</dest-tp>
</destination>
</link>
<link
xmlns="urn:ietf:params:xml:ns:yang:ietf-network-topology">
<link-id>2</link-id>
<source>
<source-node>U-PE</source-node>
<source-tp>2</source-tp>
</source>
<destination>
<dest-node>uCPE1</dest-node>
<dest-tp>1</dest-tp>
</destination>
</link>
</network>
</networks>
<logical-network-elements
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element">
<logical-network-element>
<name>CPEL3</name>
<logical-network-element-properties
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-ucpe-lne-properties">
<etsi>
<vnfd>CPEL3</vnfd>
<vdu>small</vdu>
</etsi>
<supporting-node>uCPE1</supporting-node>
</logical-network-element-properties>
</logical-network-element>
</logical-network-elements>
<network-instances
xmlns="urn:ietf:params:xml:ns:yang:ietf-network-instance">
<network-instance>
<name>CPEL2</name>
<network-instance-properties
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-ucpe-ni-properties">
<sf-connection-points>
<sf-connection-point-id>10</sf-connection-point-id>
<dot1q-vlan>
<trunk-allowed-vlans>X</trunk-allowed-vlans>
<trunk-allowed-vlans>Y</trunk-allowed-vlans>
<trunk-allowed-vlans>Z</trunk-allowed-vlans>
</dot1q-vlan>
</sf-connection-points>
<sf-connection-points>
<sf-connection-point-id>11</sf-connection-point-id>
<dot1q-vlan>
<access-tag>X</access-tag>
</dot1q-vlan>
</sf-connection-points>
<sf-connection-points>
<sf-connection-point-id>12</sf-connection-point-id>
<dot1q-vlan>
<access-tag>Z</access-tag>
</dot1q-vlan>
</sf-connection-points>
<sf-connection-points>
<sf-connection-point-id>13</sf-connection-point-id>
<dot1q-vlan>
<access-tag>Y</access-tag>
</dot1q-vlan>
</sf-connection-points>
<ni-area>wan</ni-area>
<supporting-node>uCPE1</supporting-node>
</network-instance-properties>
</network-instance>
</network-instances>
</config>
Figure 12: uCPE Service Funcitons topology YIN example
Acknowledgements 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
Xufeng Liu Xufeng Liu
Volta Networks Volta Networks
EMail: xufeng.liu.ietf@gmail.com EMail: xufeng.liu.ietf@gmail.com
Young Lee Young Lee
Sung Kyun Kwan University Samsung Electronics
EMail: younglee.tx@gmail.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
skipping to change at line 1860 skipping to change at page 52, line 4
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
EMail: daniele.ceccarelli@ericsson.com EMail: daniele.ceccarelli@ericsson.com
Jeff Tantsura Jeff Tantsura
Apstra Networks Apstra Networks
EMail: jefftant.ietf@gmail.com EMail: jefftant.ietf@gmail.com
Dmytro Shytyi
SFR
Paris
France
EMail: ietf.dmytro@shytyi.net
 End of changes. 44 change blocks. 
60 lines changed or deleted 375 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/