Internet-Draft | NRP YANG | July 2023 |
Wu, et al. | Expires 25 January 2024 | [Page] |
- Workgroup:
- Network Working Group
- Internet-Draft:
- draft-wdbsp-teas-nrp-yang-01
- Published:
- Intended Status:
- Standards Track
- Expires:
A YANG Data Model for Network Resource Partitions (NRPs)
Abstract
This document defines a YANG data model for Network Resource Partitions (NRPs). The model can be used, in particular, for the realization of the IETF Network Slice Services.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 January 2024.¶
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Introduction
[I-D.ietf-teas-ietf-network-slices] defines a framework for IETF Network Slice Services, which provide connectivity coupled with network resources commitment between a number of Service Demarcation Points (SDPs) over a shared network infrastructure. The IETF Network Slice service is expressed in terms of one or more connectivity constructs, which can be of a connection type (point-to-point (P2P), point-to-multipoint (P2MP), or any-to-any (A2A)) and any combination of these types.¶
This draft defines a YANG module of NRPs for mapping one or more connection constructs of one or more IETF network slices, for ensuring SLO and SLE and network scalability. An IETF Network Slice Controller (NSC) can use it to manage NRP instances in order to implement Network Slice Services.¶
An NRP Policy [I-D.ietf-teas-ns-ip-mpls] is a policy construct that enables instantiation of mechanisms in support of service specific control and data plane behaviors on select topological elements associated with the NRP.Section 3.1 describes the detailed definition of NRP policy in NRP instantiation.¶
According to the YANG model classification of [RFC8309], the NRP model is a network configuration model.¶
2. Terminology
The following terms are defined in [RFC6241] and are used in this specification:¶
The following terms are defined in [RFC7950] and are used in this specification:¶
The terminology for describing YANG data models is found in [RFC7950].¶
The tree diagram used in this document follows the notation defined in [RFC8340].¶
3. NRP Data Model
There are multiple modes of NRP operations to be supported as follows:¶
- NRP instantiation: Depending on the slice service types and also network status, there can be two types of approaches. One method is to create an NRP instance before the network controller processes the IETF Network Slice service request. Another one is that the network controller may start creating an NRP instance while configuring the IETF Network Slice service request.¶
- NRP modification: When the capacity of an existing NPR link is close to capacity, the bandwidth of the link could be increased. And when the NRP link or node resources are insufficient, new NRP links and nodes could be added.¶
- NRP Deletion: If the NSC determines that no slice service is using an NRP, the NSC can delete the NRP instance.¶
- NRP Monitoring: The NSC can use the NRP model to track and monitor NRP resource status and usage.¶
3.1. NRP Instantiation
An NRP policy specifies the rules for determining the topology associated with the NRP and dictates how an NRP can be realized in IP/MPLS networks using one of three partition modes. The NRP policy dictates if the partitioning of the shared network resources can be achieved in (a) just the data plane or in (b) just the control plane or in (c) both the control and data planes.¶
The NRP policy modes (a) and (c) require the forwarding engine on each NRP capable node to identify the traffic belonging to a specific NRP and to apply the corresponding Per-Hop Behavior (PHB) or forwarding mechanism that determines the forwarding treatment of the packets belonging to the NRP. When catering to IETF Network Slices, this NRP identification is referred to as the NRP selector and may comprises of traffic streams from one or more connectivity constructs (belonging to one or more IETF network slices) mapped to a specific NRP. The NRP policy modes (b) and (c) require the distributed/centralized resource reservation management.¶
'nrp-policy' is defined to enable NRP Stateful Traffic Engineering (NRP-TE) [I-D.ietf-teas-ns-ip-mpls] and/or NRP IGP forwarding in IP/MPLS networks.¶
The tree diagram used in this document follows the notation defined in [RFC8340].¶
The high-level model structure of NRP policy defined by this document is as shown in Figure 1:¶
The 'networks' container from the 'ietf-network' module [RFC8345] provides a placeholder for an inventory of nodes in the network. This container is augmented to carry a set of NRP policies.¶
The 'nrp-policies' container carries a list of NRP policies. Each 'nrp-policy' entry is identified by a name and holds the set of attributes needed to instantiate the NRP. Each entry also carries an 'nrp-id' leaf which uniquely identifies the NRP created by the enforcement of this policy. The¶
The description of the 'nrp-policies' data nodes are as follows, and the other key elements of each nrp-policy entry are discussed in the following sub-sections.¶
- 'nrp-id': Is an identifier that is used to uniquely identify an NRP instance within the NSC network scope.¶
- 'mode': Refers to control plane resource partition, data plane resource partition, or a combination of both types.¶
3.1.1. Resource Reservation
The 'resource-reservation' container specifies the bandwidth resource allocated to an NRP instance, or can be overridden by the configuration of the link specific 'resource-reservation' nodes of 'nrp-topology'.¶
3.1.2. NRP Selector
NRP selector defines the data plane encapsulation types and values that are used to identify NRP-specific network resources. The data plane mechanism could be based on IP, MPLS, or SRv6 forwarding.¶
3.1.3. NRP Topology
'nrp-topology' defines a dedicated NRP topology.¶
When an NRP support IGP forwarding, the topology of the NRP must be congruent with an IGP instance.The topology used for IGP route computation and forwarding can be derived using Multi-Topology Routing (MTR) or Flex-algo. Multi-Topology Routing (MTR) is defined in [RFC4915], [RFC5120], and [I-D.ietf-lsr-isis-sr-vtn-mt] or Flex-algo is defined in [RFC9350].¶
The 'selection' container consists of a list of select subset of links of an underlay topology or a pre-built topology.¶
The 'filter' container consists of a list of filters where each entry references a topology filter [I-D.bestbar-teas-yang-topology-filter]. The topological elements that satisfy the membership criteria can optionally override the default resource-reservation and nrp-selector specific leafs.¶
3.2. NRP monitoring
The NRP model can be used to track and monitor operational status and resource usage of NRPs.¶
3.3. NRP Device Model Description
The device-specific NRP model is defined in module 'ietf-nrp-device' as shown in Figure 8, which augments NRP YANG data model in Figure 7 and adds interface attributes, including resource reservation, NRP selector, and PHB profile, that are specific to an NRP device.¶
Figure below shows the tree diagram of the device NRP YANG model defined in modules 'ietf-nrp-device.yang'.¶
4. NRP Yang Module
The 'ietf-nrp' module uses types defined in [RFC8345].¶
5. NRP Device YANG module
The device NRP YANG module ('ietf-nrp-device') models augments the NRP YANG module ('ietf-nrp') and adds the attributes of NRP interfaces that are local to an NRP device.¶
The device NRP YANG module imports the following module(s): ietf-interfaces defined in [RFC8343], ietf-network defined in [RFC8345], and NRP grouping defined in this document.¶
6. Security Considerations
The YANG model defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in this YANG model that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations.¶
nrp-link: A malicious client could attempt to remove a link from a topology, add a new link. In each case, the structure of the topology would be sabotaged, and this scenario could, for example, result in an NRP topology that is less than optimal.¶
The entries in the nodes above include the whole network configurations corresponding with the NRP, and indirectly create or modify the PE or P device configurations. Unexpected changes to these entries could lead to service disruption and/or network misbehavior.¶
7. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made:¶
URI: urn:ietf:params:xml:ns:yang:ietf-nrp Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-nrp-device Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
This document requests to register a YANG module in the YANG Module Names registry [RFC7950].¶
Name: ietf-nrp Namespace: urn:ietf:params:xml:ns:yang:ietf-nrp Maintained by IANA: N Prefix: nrp Reference: RFC XXXX Name: ietf-nrp-device Namespace: urn:ietf:params:xml:ns:yang:ietf-nrp-device Maintained by IANA: N Prefix: nrp-dev Reference: RFC XXXX¶
8. Acknowledgments
The authors would like to thank Krzysztof Szarkowicz, Jie Dong, Qin Wu, Yao Zhao, Zhenbing Li, Ying Cheng, Liyan Gong, and many others for their helpful comments and suggestions.¶
9. Contributor
The following individuals, authors of [I-D.bestbar-teas-yang-nrp-policy] and [I-D.wd-teas-nrp-yang], contributed to this consolidated document:¶
Xufeng Liu IBM Corporation Email: xufeng.liu.ietf@gmail.com Mohamed Boucadair Orange Email: mohamed.boucadair@orange.com Daniele Ceccarelli Bin Wen Comcast Email: Bin_Wen@cable.comcast.com Ran Chen ZTE Corporation Email: chen.ran@zte.com.cn Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Ying Cheng China Unicom Email: chengying10@chinaunicom.cn Liyan Gong China Mobile Email: gongliyan@chinamobile.com¶
10. References
10.1. Normative References
- [RFC3688]
- Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
- [RFC4915]
- Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, , <https://www.rfc-editor.org/info/rfc4915>.
- [RFC5120]
- Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, , <https://www.rfc-editor.org/info/rfc5120>.
- [RFC6241]
- Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
- [RFC6242]
- Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, , <https://www.rfc-editor.org/info/rfc6242>.
- [RFC7950]
- Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
- [RFC7951]
- Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/info/rfc7951>.
- [RFC8040]
- Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
- [RFC8340]
- Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
- [RFC8341]
- Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/info/rfc8341>.
- [RFC8343]
- Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, , <https://www.rfc-editor.org/info/rfc8343>.
- [RFC8345]
- Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, , <https://www.rfc-editor.org/info/rfc8345>.
- [RFC8446]
- Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References
- [I-D.bestbar-teas-yang-nrp-policy]
- Beeram, V. P., Saad, T., Wen, B., Ceccarelli, D., Peng, S., Chen, R., Contreras, L. M., and X. Liu, "YANG Data Model for Network Resource Partition Policy", Work in Progress, Internet-Draft, draft-bestbar-teas-yang-nrp-policy-03, , <https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-nrp-policy-03>.
- [I-D.bestbar-teas-yang-topology-filter]
- Beeram, V. P., Saad, T., Gandhi, R., and X. Liu, "YANG Data Model for Topology Filter", Work in Progress, Internet-Draft, draft-bestbar-teas-yang-topology-filter-04, , <https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-04>.
- [I-D.ietf-lsr-isis-sr-vtn-mt]
- Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-sr-vtn-mt-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-sr-vtn-mt-05>.
- [I-D.ietf-teas-ietf-network-slices]
- Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "A Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-21>.
- [I-D.ietf-teas-ns-ip-mpls]
- Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli, D., Halpern, J. M., Peng, S., Chen, R., Liu, X., Contreras, L. M., Rokui, R., and L. Jalil, "Realizing Network Slices in IP/MPLS Networks", Work in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-ip-mpls-02>.
- [I-D.wd-teas-nrp-yang]
- Wu, B., Dhody, D., Boucadair, M., Cheng, Y., and L. Gong, "A YANG Data Model for Network Resource Partitions (NRPs)", Work in Progress, Internet-Draft, draft-wd-teas-nrp-yang-02, , <https://datatracker.ietf.org/doc/html/draft-wd-teas-nrp-yang-02>.
- [RFC8309]
- Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, , <https://www.rfc-editor.org/info/rfc8309>.
- [RFC9350]
- Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, , <https://www.rfc-editor.org/info/rfc9350>.
Appendix A. An Example
This section contains an example of an instance data tree in JSON encoding [RFC7951]. The example below instantiates an NRP for the topology that is depicted in the following diagram. There are three nodes, D1, D2, and D3. D1 has three termination points, 1-0-1, 1-2-1, and 1-3-1. D2 has three termination points as well, 2-1-1, 2-0-1, and 2-3-1. D3 has two termination points, 3-1-1 and 3-2-1. In addition there are six links, two between each pair of nodes with one going in each direction.¶
An corresponding IGP congruent NRP instance data tree is depicted below:¶
In addition, an exampe of an NRP that supports the control plane partition mode is shown in the following figure.¶
{ "ietf-network:networks": { "nrp-policies": { "nrp-policy": [ { "name": "NRP2", "nrp-id": "foo:nrp-example2", "mode": "nrp-control-plane-partition", "resource-reservation": { "bw-value": "10000" }, "topology": { "filters": { "filter": [ { "filter-ref": "te-topology-filter1" } ] } } } ] } } }¶
Appendix B. NRP YANG Module Tree
module: ietf-nrp augment /nw:networks: +--rw nrp-policies +--rw nrp-policy* [name] +--rw name string +--rw nrp-id? uint32 +--rw mode? identityref +--rw resource-reservation | +--rw (max-bw-type)? | +--:(bw-value) | | +--rw maximum-bandwidth? uint64 | +--:(bw-percentage) | +--rw maximum-bandwidth-percent? | rt-types:percentage +--rw selector | +--rw ipv4 | | +--rw destination-prefix* inet:ipv4-prefix | +--rw ipv6 | | +--rw (selector-type)? | | +--:(dedicated) | | | +--rw ipv6-hbh-eh? uint32 | | +--:(srv6-sid-derived) | | | +--rw srv6-sid* | | | inet:ipv6-prefix | | +--:(ipv6-destination-derived) | | +--rw destination-prefix* | | inet:ipv6-prefix | +--rw mpls | | +--rw (selector-type)? | | +--:(dedicated) | | | +--rw label? | | | | rt-types:mpls-label | | | +--rw label-position? identityref | | | +--rw label-position-offset? uint8 | | +--:(derived) | | +--rw forwarding-label? empty | +--rw acl-ref* nrp-acl-ref +--rw phb-profile? string +--rw topology +--rw igp-congruent! | +--rw multi-topology-id? uint32 | +--rw algo-id? uint32 | +--rw sharing? boolean +--rw (topology-type)? +--:(selection) | +--rw select | +--rw topology-group* [group-id] | +--rw group-id string | +--rw base-topology-ref | | +--rw network-ref? leafref | +--rw links* [link-ref] | | +--rw link-ref leafref | +--rw resource-reservation | | +--rw (max-bw-type)? | | +--:(bw-value) | | | +--rw maximum-bandwidth? | | | uint64 | | +--:(bw-percentage) | | +--rw maximum-bandwidth-percent? | | rt-types:percentage | +--rw link-partition-type? | | identityref | +--rw phb-profile? string +--:(filter) +--rw filters +--rw filter* [filter-ref] +--rw filter-ref | nrp-topo-filter-ref +--rw resource-reservation | +--rw (max-bw-type)? | +--:(bw-value) | | +--rw maximum-bandwidth? | | uint64 | +--:(bw-percentage) | +--rw maximum-bandwidth-percent? | rt-types:percentage +--rw selector | +--rw ipv4 | | +--rw destination-prefix* | | inet:ipv4-prefix | +--rw ipv6 | | +--rw (selector-type)? | | +--:(dedicated) | | | +--rw ipv6-hbh-eh? | | | uint32 | | +--:(srv6-sid-derived) | | | +--rw srv6-sid* | | | inet:ipv6-prefix | | +--:(ipv6-destination-derived) | | +--rw destination-prefix* | | inet:ipv6-prefix | +--rw mpls | | +--rw (selector-type)? | | +--:(dedicated) | | | +--rw label? | | | | rt-types:mpls-label | | | +--rw label-position? | | | | identityref | | | +--rw label-position-offset? | | | uint8 | | +--:(derived) | | +--rw forwarding-label? | | empty | +--rw acl-ref* nrp-acl-ref +--rw phb-profile? string augment /nw:networks/nw:network/nw:network-types: +--rw nrp! augment /nw:networks/nw:network/nw:node: +--ro nrp +--ro selector +--ro srv6? srv6-types:srv6-sid +--ro sr-mpls? rt-types:mpls-label augment /nw:networks/nw:network/nt:link: +--ro nrp +--ro link-partition-type? identityref +--ro bandwidth-value? uint64 +--ro selector | +--ro srv6? srv6-types:srv6-sid | +--ro sr-mpls? rt-types:mpls-label +--ro statistics +--ro admin-status? | te-types:te-admin-status +--ro oper-status? | te-types:te-oper-status +--ro one-way-available-bandwidth? | rt-types:bandwidth-ieee-float32 +--ro one-way-utilized-bandwidth? | rt-types:bandwidth-ieee-float32 +--ro one-way-min-delay? uint32 +--ro one-way-max-delay? uint32 +--ro one-way-delay-variation? uint32 +--ro one-way-packet-loss? decimal64 augment /nw:networks/nw:network/nw:node: +--ro nrps* [nrp-id] +--ro nrp-id uint32 +--ro nrp +--ro selector +--ro srv6? srv6-types:srv6-sid +--ro sr-mpls? rt-types:mpls-label augment /nw:networks/nw:network/nt:link: +--ro nrps* [nrp-id] +--ro nrp-id uint32 +--ro link-partition-type? identityref +--ro bandwidth-value? uint64 +--ro selector +--ro srv6? srv6-types:srv6-sid +--ro sr-mpls? rt-types:mpls-label <CODE ENDS>¶
Appendix C. NRP Device YANG Module Tree
module: ietf-nrp-device augment /nw:networks/nrp:nrp-policies/nrp:nrp-policy: +--rw interfaces +--rw interface* [interface] +--rw interface if:interface-ref +--rw resource-reservation | +--rw (max-bw-type)? | +--:(bw-value) | | +--rw maximum-bandwidth? uint64 | +--:(bw-percentage) | +--rw maximum-bandwidth-percent? rt-types:percentage +--rw selector | +--rw ipv4 | | +--rw destination-prefix* inet:ipv4-prefix | +--rw ipv6 | | +--rw (selector-type)? | | +--:(dedicated) | | | +--rw ipv6-hbh-eh? uint32 | | +--:(srv6-sid-derived) | | | +--rw srv6-sid* inet:ipv6-prefix | | +--:(ipv6-destination-derived) | | +--rw destination-prefix* inet:ipv6-prefix | +--rw mpls | | +--rw (selector-type)? | | +--:(dedicated) | | | +--rw label? rt-types:mpls-label | | | +--rw label-position? identityref | | | +--rw label-position-offset? uint8 | | +--:(derived) | | +--rw forwarding-label? empty | +--rw acl-ref* nrp-acl-ref +--rw phb-profile? string¶