To: teas-chairs / draft-ietf-teas-ietf-network-slice-nbi-yang.all@ietf.org Cc: rtg-dir@ietf.org; teas@ietf.org Subject: RtgDir Early review: draft-ietf-teas-ietf-network-slice-nbi-yang-12 Hello, I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/12/ The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments. Document: draft-ietf-teas-ietf-network-slice-nbi-yang-12 Reviewer: Alvaro Retana Review Date: May 6, 2024 Intended Status: Standards Track Summary: This document is basically ready for publication, but I have some concerns that I think should be resolved before it is submitted to the IESG. In general, I found the document easy to read. Please see the in-line comments (below) -- I tagged as couple of them as "major", but they should be easy to address. Thanks! Alvaro. [Line numbers from idnits.] ... 97 1. Introduction ... 120 The NSSM is a service model (Section 3.5.1 of 121 [I-D.ietf-netmod-rfc8407bis]). [nit] s/I-D.ietf-netmod-rfc8407bis/RFC8309 RFC8309 is where a service model is explained -- rfc8407bis later borrows from it. ... 504 5.2. Network Slice Services ... 515 * "service-tags": Indicates a management tag (e.g., "customer-name" 516 ) that is used to correlate the operational information of 517 Customer Higher-level Operation System and Network Slices. It 518 might be used by a Network Slice Service provider to provide 519 additional information to an NSC during the operation of the 520 Network Slices. For example, adding tags with "customer-name" 521 when multiple actual customers use a same Network Slice Service. 522 Another use case for "service-tag" might be for a provider to 523 provide additional attributes to an NSC which might be used during 524 the realization of Network Slice Services such as type of services 525 (e.g., use Layer 2 or Layer 3 technology for the realization). 526 These additional attributes can also be used by an NSC for various 527 purposes such as monitoring and assurance of the Network Slice 528 Services where the NSC can issue notifications to the customer 529 system. All these attributes are optional. [minor] It took me a while to figure out that the customer name tag is not called "customer-name" (as above), but simply "customer" (as part of the service-tag-type identity). Please review for consistency as "customer-name" and "customer name" are used in several places, including the description of the "customer" tag: identity customer { base service-tag-type; description "The Network Slice Service customer name tag type, e.g., adding tags with 'customer-name' when multiple actual customers use a same Network Slice Service."; } ... 901 5.2.3. SLO and SLE Policy ... 952 The list "metric-bound" supports the generic performance metric 953 variations and the combinations and each "metric-bound" could specify 954 a particular "metric-type". "metric-type" is defined with YANG 955 identity and supports the following options: 957 "one-way-bandwidth": Indicates the guaranteed minimum bandwidth 958 between any two SDPs. The bandwidth is unidirectional. 960 "two-way-bandwidth": Indicates the guaranteed minimum bandwidth 961 between any two SDPs. The bandwidth is bidirectional. [?] I noticed that there are no "one-way-bandwidth-percentile" or "two-way-bandwidth-percentile" options. Do they not make sense in this environment or is there a reason for not including them? I'm just curious because I can imagine a customer (maybe one new to slicing or experimenting with them) who may want to dedicate 50% of the bandwidth to a specific slice. [major] "shared-bandwidth" is defined in the module but not mentioned here: identity shared-bandwidth { base service-slo-metric-type; description "The shared SLO bandwidth bound. It is the limit on the bandwidth that can be shared amongst a group of connectivity constructs of a Slice Service."; } ... 1008 "mtu": Refers to the service Layer 2 MTU, in bytes. If the customer 1009 sends packets that are longer than the requested service MTU, the 1010 network may discard it (or for IPv4, fragment it). [nit] s/discard it...fragment it/discard them...fragment them [major] Note that the definition above, and the description in the module are not exactly in sync: leaf mtu { type uint32; units "bytes"; description "Specifies the maximum length of layer 2 data packets of the Slice Service. The value needs to be less than or equal to the minimum MTU value of all 'attachment-circuits' in the SDPs."; } The definition doesn't impose a dependency, but the description does. If the MTU value is (significantly) lower than the description constraints, can the network still discard packets that would otherwise "fit" in the ACs? Should any of the statements be Normative? The definition of 'attachment-circuits' (§5.2.1) says that it is an optional attribute and that ""ac-svc-ref" may take precedence". IOW, the description is incomplete because the MTU value should consider attachment-circuits *and* the attributes in ac-svc-ref. Perhaps the easy solution is to s/'attachment-circuits'/ACs ... 1042 5.2.4. Network Slice Service Performance Monitoring ... 1059 [RFC8639] and [RFC8641] define a subscription mechanism and a push 1060 mechanism for YANG datastores. These mechanisms currently allow the 1061 user to subscribe to notifications on a per-client basis and specify 1062 either periodic or on-demand notifications. By specifying subtree 1063 filters or xpath filters to "sdp", "connectivity-construct", or 1064 "connection-group", so that only interested contents will be sent. 1065 The example in Figure 23 shows the way for a customer to subscribe to 1066 the monitoring information for a particular Network Slice Service. . [nit] s/. ./. ... 2791 11.2. Informative References ... 2829 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2830 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 2831 September 1999, . 2833 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2834 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2835 DOI 10.17487/RFC3393, November 2002, 2836 . 2838 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 2839 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 2840 March 2009, . 2842 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 2843 Ed., "A One-Way Delay Metric for IP Performance Metrics 2844 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2845 2016, . 2847 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 2848 Ed., "A One-Way Loss Metric for IP Performance Metrics 2849 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2850 2016, . [major] These 5 references should be Normative as they are is used to define parameters in §5.2.3. [EoR-12]