draft-ietf-ccamp-l1csm-yang-08.txt   draft-ietf-ccamp-l1csm-yang-09.txt 
CCAMP Working Group G. Fioccola (Ed.) CCAMP Working Group G. Fioccola (Ed.)
Telecom Italia Telecom Italia
Internet Draft K. Lee Internet Draft K. Lee
Intended Status: Standard Track Korea Telecom Intended Status: Standard Track Korea Telecom
Expires: March 12, 2019 Y. Lee (Ed.) Expires: September 6, 2019 Y. Lee (Ed.)
D. Dhody D. Dhody
Huawei Huawei
O. Gonzalez de-Dios O. Gonzalez de-Dios
Telefonica Telefonica
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
September 12, 2018 March 6, 2019
A YANG Data Model for L1 Connectivity Service Model (L1CSM) A YANG Data Model for L1 Connectivity Service Model (L1CSM)
draft-ietf-ccamp-l1csm-yang-08 draft-ietf-ccamp-l1csm-yang-09
Abstract Abstract
This document provides a YANG data model for Layer 1 Connectivity This document provides a YANG data model for Layer 1 Connectivity
Service Model (L1CSM). The intent of this document is to provide a Service Model (L1CSM). The intent of this document is to provide a
transport service model exploiting YANG data model, which can be transport service model exploiting YANG data model, which can be
utilized by a client network controller to initiate a service utilized by a client network controller to initiate a service
request connectivity request as well as retrieving service states request connectivity request as well as retrieving service states
toward a transport network controller communicating with the client toward a transport network controller communicating with the client
controller. This YANG model is NMDA-compliant. controller. This YANG model is NMDA-compliant.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 12 2019. This Internet-Draft will expire on September 6, 2019.
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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1. Deployment Scenarios......................................4 1.1. Deployment Scenarios......................................3
1.2. Terminology...............................................6 1.2. Terminology...............................................6
1.3. Tree diagram..............................................7 1.3. Tree diagram..............................................6
1.4. Prefixes in Data Node Names...............................7 1.4. Prefixes in Data Node Names...............................6
2. Definitions....................................................7 2. Definitions....................................................7
3. L1SM YANG Model (Tree Structure)...............................8 3. L1SM YANG Model (Tree Structure)...............................7
4. L1SM YANG Code.................................................8 4. L1SM YANG Code.................................................8
5. JSON Example..................................................21 5. JSON Example..................................................21
6. Security Considerations.......................................22 6. Security Considerations.......................................22
7. IANA Considerations...........................................23 7. IANA Considerations...........................................23
8. Acknowledgments...............................................24 8. Acknowledgments...............................................24
9. References....................................................25 9. References....................................................25
9.1. Normative References.....................................25 9.1. Normative References.....................................25
9.2. Informative References...................................25 9.2. Informative References...................................25
10. Contributors.................................................26 10. Contributors.................................................26
Authors' Addresses...............................................26 Authors' Addresses...............................................26
skipping to change at page 3, line 42 skipping to change at page 3, line 42
parameters of the part of the provider's network dedicated to the parameters of the part of the provider's network dedicated to the
customer. customer.
The primary focus of this document is to describe L1CS YANG model The primary focus of this document is to describe L1CS YANG model
required for the instantiation of point-to-point L1VPN service. A required for the instantiation of point-to-point L1VPN service. A
L1VPN is a service offered by a core layer 1 network to provide L1VPN is a service offered by a core layer 1 network to provide
layer 1 connectivity between two or more customer sites where the layer 1 connectivity between two or more customer sites where the
customer has some control over the establishment and type of the customer has some control over the establishment and type of the
connectivity. connectivity.
The data model presented in Section 3 is in consistent with [MEF- The data model presented in Section 3 is in consistent with [MEF63].
L1CS]. The data model includes configuration and state data The data model includes configuration and state data according to
according to the new Network Management Datastore Architecture the new Network Management Datastore Architecture [RFC8342].
[RFC8342].
1.1. Deployment Scenarios 1.1. Deployment Scenarios
Figure 1 depicts a deployment scenario of the L1VPN SDN control- Figure 1 depicts a deployment scenario of the L1VPN SDN control-
based service model for an external customer instantiating L1 point- based service model for an external customer instantiating L1 point-
to-point connectivity to the provider. to-point connectivity to the provider.
+------------+ +------------+
| Customer | | Customer |
| Service | | Service |
|Orchestrator| |Orchestrator|
+------------+ +------------+
| |
.. .. .. .. .. .|.. .. .. .. .. .. .. .. .. .. ..|.. .. .. .. .. .. .
: | : : | :
: +--------------------+ : : +--------------------+ :
: | | : : | | :
: | +----------+ | : : | +----------+ | :
: | | Network | | : : | | Network | | :
: | | SDN | | : : | | SDN | | :
: | |Controller| | : : | |Controller| | :
: | |/NMS/EMS | | : : | |/NMS/EMS | | :
: | +----------+ | : : | +----------+ | :
: | | : : | | :
: | | : : | | :
skipping to change at page 4, line 41 skipping to change at page 4, line 35
+----+ : +----+ +----+ +----+ : +----+ +----+ : +----+ +----+ +----+ : +----+
: | | : : | | :
: | | : : | | :
: +--------------------+ : : +--------------------+ :
: | | : : | | :
: |<-Provider network->| : : |<-Provider network->| :
Customer Customer Customer Customer
Interface Interface Interface Interface
Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: External Customer Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model:
External Customer
With this scenario, the customer service orchestrator interfaces With this scenario, the customer service orchestrator interfaces
with the network SDN controller of the provider using Customer with the network SDN controller of the provider using Customer
Service Model as defined in [RFC8309]. Service Model as defined in [RFC8309].
Figure 2 depicts another deployment scenario for internal customer Figure 2 depicts another deployment scenario for internal customer
(e.g., higher-layer service management department(s)) interfacing (e.g., higher-layer service management department(s)) interfacing
the layer 1 transport network department. With this scenario, a the layer 1 transport network department. With this scenario, a
multi-service backbone is characterized such that each service multi-service backbone is characterized such that each service
department of a provider (e.g., L2/3 services) that receives the department of a provider (e.g., L2/3 services) that receives the
same provider's L1VPN service provides a different kind of higher- same provider's L1VPN service provides a different kind of higher-
skipping to change at page 6, line 29 skipping to change at page 5, line 47
| | | | | | | |
| | | | | | | |
| +--------------------+ | | +--------------------+ |
| | | | | | | |
| |<------------------>| | | |<------------------>| |
| Provider Network | | Provider Network |
| For Layer 1 | | For Layer 1 |
|<------------------------------------------>| |<------------------------------------------>|
Provider Network for L2/3 Provider Network for L2/3
Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: Internal Customer Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model:
Internal Customer
The benefit is that the same layer 1 transport network resources are The benefit is that the same layer 1 transport network resources are
shared by multiple services. A large capacity backbone network shared by multiple services. A large capacity backbone network
(data plane) can be built economically by having the resources (data plane) can be built economically by having the resources
shared by multiple services usually with flexibility to modify shared by multiple services usually with flexibility to modify
topologies, while separating the control functions for each service topologies, while separating the control functions for each service
department. Thus, each customer can select a specific set of department. Thus, each customer can select a specific set of
features that are needed to provide their own service [RFC4847]. features that are needed to provide their own service [RFC4847].
1.2. Terminology 1.2. Terminology
skipping to change at page 11, line 32 skipping to change at page 11, line 4
grouping subscriber-l1vc-endpoint-attributes { grouping subscriber-l1vc-endpoint-attributes {
description description
"subscriber layer 1 connection endpoint attributes"; "subscriber layer 1 connection endpoint attributes";
reference "MEF 63"; reference "MEF 63";
container endpoint-1 { container endpoint-1 {
description "One end of UNI id's - string and id"; description "One end of UNI id's - string and id";
leaf id { leaf id {
type string; type string;
mandatory true; mandatory true;
description "subscriber end point ID of one end"; description "subscriber end point ID of one end";
} }
leaf uni { leaf uni {
type leafref { type leafref {
path "/l1-connectivity/access/unis/uni/id"; path "/l1-connectivity/access/unis/uni/id";
} }
mandatory true; mandatory true;
description "this is one end of subscriber L1VC end point description "this is one end of subscriber L1VC end point
ID value = UNI-1"; ID value = UNI-1";
} }
} }
container endpoint-2 { container endpoint-2 {
description "One end of UNI id's - string and id"; description "One end of UNI id's - string and id";
leaf id { leaf id {
type string; type string;
mandatory true; mandatory true;
description "subscriber end point ID of the other end"; description "subscriber end point ID of the other end";
} }
leaf uni { leaf uni {
type leafref { type leafref {
path "/l1-connectivity/access/unis/uni/id"; path "/l1-connectivity/access/unis/uni/id";
} }
mandatory true; mandatory true;
description "this is one other end of subscriber L1VC end point description
ID value = UNI-2"; "this is one other end of subscriber L1VC end point
ID value = UNI-2";
} }
} }
} }
container l1-connectivity { container l1-connectivity {
description description
"serves as a top-level container for a list of layer 1 "serves as a top-level container for a list of layer 1
connection services (l1cs)"; connection services (l1cs)";
container access { container access {
skipping to change at page 12, line 32 skipping to change at page 12, line 4
container unis { container unis {
description "the list of UNI's to be configured"; description "the list of UNI's to be configured";
list uni { list uni {
key "id"; key "id";
description "UNI identifier"; description "UNI identifier";
leaf id { leaf id {
type string; type string;
description "the UNI id of UNI Service Attributes"; description "the UNI id of UNI Service Attributes";
} }
uses protocol-coding-optical-interface; uses protocol-coding-optical-interface;
} }
} }
} }
container services { container services {
description "L1VC services"; description "L1VC services";
list service { list service {
key "service-id"; key "service-id";
description description
"an unique identifier of a subscriber L1VC service"; "an unique identifier of a subscriber L1VC service";
leaf service-id { leaf service-id {
type string; type string;
mandatory true; mandatory true;
description "a unique service identifier for description "a unique service identifier for
subscriber L1VC."; subscriber L1VC.";
} }
uses subscriber-l1vc-endpoint-attributes;
uses subscriber-l1vc-sls-service-attribute;
}//end of service list uses subscriber-l1vc-endpoint-attributes;
} //end of services container uses subscriber-l1vc-sls-service-attribute;
}//end of l1 connectivity top container
}//end of service list
} //end of service container
}//service top container
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-l1-service-types@2018-09-12.yang" <CODE BEGINS> file "ietf-l1-service-types@2018-09-12.yang"
module ietf-l1-service-types { module ietf-l1-service-types {
namespace "urn:ietf:params:xml:ns:yang:ietf-l1-service-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-l1-service-types";
prefix "l1-st"; prefix "l1-st";
skipping to change at page 14, line 4 skipping to change at page 13, line 24
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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions 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 This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2018-09-12" { revision "2018-09-12" {
description "Initial revision."; description "Initial revision.";
reference "RFC XXXX: A Yang Data Model for L1 Connectivity reference "RFC XXXX: A Yang Data Model for L1 Connectivity
Service Model (L1CSM)"; Service Model (L1CSM)";
// Note: The RFC Editor will replace XXXX with the number // Note: The RFC Editor will replace XXXX with the number
// assigned to the RFC once this draft becomes an RFC. // assigned to the RFC once this draft becomes an RFC.
} }
identity protocol-type { identity protocol-type {
description description
"base identity from which client protocol type is derived."; "base identity from which client protocol type is derived.";
} }
identity ETH-1GbE { identity ETH-1GbE {
base "protocol-type"; base "protocol-type";
description description
"Gigabit Ethernet protocol type"; "Gigabit Ethernet protocol type";
reference "MEF63 & G.709"; reference "MEF63 & G.709";
} }
skipping to change at page 17, line 40 skipping to change at page 17, line 13
} }
identity coding-func { identity coding-func {
description description
"base identity from which coding func is derived."; "base identity from which coding func is derived.";
} }
identity ETH-1000X-PCS-36 { identity ETH-1000X-PCS-36 {
base "coding-func"; base "coding-func";
description description
"PCS clause 36 coding function that corresponds to 1000BASE-X"; "PCS clause 36 coding function that corresponds to
reference "MEF63 & IEEE802.3"; 1000BASE-X";
reference "MEF63 & IEEE802.3";
} }
identity ETH-10GW-PCS-49-WIS-50 { identity ETH-10GW-PCS-49-WIS-50 {
base "coding-func"; base "coding-func";
description description
"PCS clause 49 and WIS clause 50 coding func that corresponds "PCS clause 49 and WIS clause 50 coding func that
to 10GBASE-W (WAN PHY)"; corresponds to 10GBASE-W (WAN PHY)";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
identity ETH-10GR-PCS-49 { identity ETH-10GR-PCS-49 {
base "coding-func"; base "coding-func";
description description
"PCS clause 49 coding function that corresponds to 10GBASE-R "PCS clause 49 coding function that corresponds to
(LAN PHY)"; 10GBASE-R (LAN PHY)";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
identity ETH-40GR-PCS-82 { identity ETH-40GR-PCS-82 {
base "coding-func"; base "coding-func";
description description
"PCS clause 82 coding function that corresponds to 40GBASE-R"; "PCS clause 82 coding function that corresponds to
40GBASE-R";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
identity ETH-100GR-PCS-82 { identity ETH-100GR-PCS-82 {
base "coding-func"; base "coding-func";
description description
"PCS clause 82 coding function that corresponds to 100GBASE-R"; "PCS clause 82 coding function that corresponds to
100GBASE-R";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
/* coding func needs to expand for Fiber Channel, SONET, SDH */ /* coding func needs to expand for Fiber Channel, SONET, SDH */
identity optical-interface-func { identity optical-interface-func {
description description
"base identity from which optical-interface-function is derived."; "base identity from which optical-interface-function is
} derived.";
}
identity SX-PMD-clause-38 { identity SX-PMD-clause-38 {
base "optical-interface-func"; base "optical-interface-func";
description description
"SX-PMD-clause-38 Optical Interface function for "SX-PMD-clause-38 Optical Interface function for
1000BASE-X PCS-36"; 1000BASE-X PCS-36";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
identity LX-PMD-clause-38 { identity LX-PMD-clause-38 {
skipping to change at page 20, line 44 skipping to change at page 20, line 18
} }
identity ER4-PMD-clause-88 { identity ER4-PMD-clause-88 {
base "optical-interface-func"; base "optical-interface-func";
description description
"ER4-PMD-clause-88 Optical Interface function for "ER4-PMD-clause-88 Optical Interface function for
100GBASE-R PCS-82"; 100GBASE-R PCS-82";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
/* optical interface func needs to expand for Fiber Channel, SONET and SDH */ /* optical interface func needs to expand for Fiber Channel,
SONET and SDH */
identity performance-metric { identity performance-metric {
description "list of performance metric"; description "list of performance metric";
} }
identity One-way-Delay { identity One-way-Delay {
base "performance-metric"; base "performance-metric";
description "one-way-delay"; description "one-way-delay";
} }
identity One-way-Errored-Second { identity One-way-Errored-Second {
base "performance-metric"; base "performance-metric";
description "one-way-errored-second"; description "one-way-errored-second";
} }
skipping to change at page 23, line 22 skipping to change at page 22, line 40
subset of all available NETCONF protocol operations and content. subset of all available NETCONF protocol operations and content.
A number of configuration data nodes defined in this document are A number of configuration data nodes defined in this document are
writable/deletable (i.e., "config true") These data nodes may be writable/deletable (i.e., "config true") These data nodes may be
considered sensitive or vulnerable in some network environments. considered sensitive or vulnerable in some network environments.
These are the subtrees and data nodes and their These are the subtrees and data nodes and their
sensitivity/vulnerability: sensitivity/vulnerability:
unis: unis:
- id - id
Service: Service:
- service-id - service-id
- endpoint-1 - endpoint-1
- endpoint-2 - endpoint-2
- start-time - start-time
- time-interval - time-interval
- performance-metric - performance-metric
7. IANA Considerations 7. IANA Considerations
skipping to change at page 25, line 40 skipping to change at page 25, line 40
RFC 7950, August 2016. RFC 7950, August 2016.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017. Protocol", RFC 8040, January 2017.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", RFC 8341, March 2018. Access Control Model", RFC 8341, March 2018.
9.2. Informative References 9.2. Informative References
[RFC3688] M. Mealling, "The IETF XML Registry", RFC 3688, January
2004.
[RFC4847] T. Takeda (Editor), "Framework and Requirements for Layer [RFC4847] T. Takeda (Editor), "Framework and Requirements for Layer
1 Virtual Private Networks", RFC 4847, April 2007. 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC5253] T. Takeda, "Applicability Statement for Layer 1 Virtual [RFC5253] T. Takeda, "Applicability Statement for Layer 1 Virtual
Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. Private Network (L1VPN) Basic Mode", RFC 5253, July 2008.
[RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module
Classification", RFC 8199, July 2017. Classification", RFC 8199, July 2017.
[RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained",
RFC 8309, January 2018. RFC 8309, January 2018.
[RFC8340] M. Bjorklund and L. Berger, Ed., "YANG Tree Diagrams", RFC
8340, March 2018.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, March 2018, (NMDA)", RFC 8342, March 2018,
[G.709] ITU-T Recommendation G.709/Y.1331, Interfaces for the [G.709] ITU-T Recommendation G.709/Y.1331, Interfaces for the
optical transport network, Corrigendum 1, August 2017. optical transport network, Corrigendum 1, August 2017.
[IEEE802.3] IEEE Std 802.3, IEEE Standard for Ethernet, 2015. [IEEE802.3] IEEE Std 802.3, IEEE Standard for Ethernet, 2015.
10. Contributors 10. Contributors
 End of changes. 37 change blocks. 
61 lines changed or deleted 81 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/