Skip to main content

Early Review of draft-ietf-teas-ietf-network-slice-nbi-yang-12

Request Review of draft-ietf-teas-ietf-network-slice-nbi-yang-10
Requested revision 10 (document currently at 13)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2024-05-07
Requested 2024-04-16
Requested by Vishnu Pavan Beeram
Authors Bo Wu , Dhruv Dhody , Reza Rokui , Tarek Saad , John Mullooly
I-D last updated 2024-05-06
Completed reviews Rtgdir Early review of -12 by Alvaro Retana (diff)
Yangdoctors Early review of -03 by Ladislav Lhotka (diff)
Please note that the document (rev 10) is currently going through the WGLC process (See thread -
Assignment Reviewer Alvaro Retana
State Completed
Request Early review on draft-ietf-teas-ietf-network-slice-nbi-yang by Routing Area Directorate Assigned
Posted at
Reviewed revision 12 (document currently at 13)
Result Ready
Completed 2024-05-06
To: teas-chairs /


Subject: RtgDir Early review: draft-ietf-teas-ietf-network-slice-nbi-yang-12


I have been selected to do a routing directorate “early” review of this draft.

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


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



[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

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;
      "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;
      "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";
          "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

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.