Hi Ines, Many thanks for your detailed review and valuable comments. The new version rev-18 has been submitted to address your comments. Please refer to the diff for updates: https://author-tools.ietf.org/iddiff?url2=draft-ietf-teas-ietf-network-slice-nbi-yang-18 And please see inline for the detailed response. Regards, Bo -----Original Message----- From: Ines Robles via Datatracker <noreply@xxxxxxxx> Sent: Saturday, January 11, 2025 4:06 AM To: gen-art@xxxxxxxx Cc: draft-ietf-teas-ietf-network-slice-nbi-yang.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx Subject: Genart last call review of draft-ietf-teas-ietf-network-slice-nbi-yang-17 Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-teas-ietf-network-slice-nbi-yang-17 Reviewer: Ines Robles Review Date: 2025-01-10 IETF LC End Date: 2025-01-10 IESG Telechat date: Not scheduled for a telechat Summary: The document defines a YANG data model for the RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider offering RFC 9543 Network Slice Services. The document is comprehensive and includes good examples, particularly in the appendices. I have the following questions/comments: 1- Section 4: The document mentions dynamic Network Slice management for 5G but does not specify what "dynamic" entails in this context. It would be helpful to clarify what dynamic management means, perhaps by providing examples of dynamic changes, such as modifying service objectives. [Bo Wu] Thank you for pointing out this issue. To avoid ambiguity, I will remove "dynamic". This model is similar to other existing VPN service models and is used for service management, without any specific ‘dynamic’ functionality. 2- Section 5.2.3: The draft defines precedence rules for SLO/SLE policies. It would be helpful to explain what happens if policies conflict or are ambiguous. [Bo Wu] Thank you for the suggestions. The model defines two types of precedence rules: one is the "scope-based precedence ", which is used for simple SLO/SLE policies, such as bandwidth and latency, where conflicts are resolved by ; the other is the "explicit precedence", which is used for partial or complete overwriting rules in cases of more complex SLO/SLE policies, thereby reducing the need for configuration changes. To provide clearer explanation, Section 5.2.3 has been revised. Please let us know if it is clear. https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-18#section-5.2.3 3 -Section 5.2.6: In "compute-only" mode, the document mentions feasibility checks. It would be helpful to describe what happens if the checks fail. [Bo Wu] Thank you again for the suggestions. To provide a clearer explanation of the check fail process, “compute-status” for feasibility check results and “error-info” for error details have been added. Please let us know if this is clear. https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-18#section-5.2.6 4- Does the YANG model support compute-only mode in multi-domain setups, and if so, are there any constraints or limitations that need to be addressed? [Bo Wu] Thank you for reminding us to include the multi-domain consideration in the description. The model assumes that the NSC supports the distribution and verification of cross-domain NS computation. Here is the considerations: When an IETF Network Slice spans multiple administrative domains, the 'compute-only' mode relies on the NSC to aggregate and validate information across these domains. This could include: a. Validating end-to-end Network Slice requests to ensure they can be realized across all domains. b. Checking resource availability and constraints within each domain to confirm feasibility. c. Identifying potential conflicts or bottlenecks between domains that may impact the Network Slice's performance or realization. Hope this helps to clarify. 5- How does the model scale with an increasing number of slices or handle frequent modifications to existing slices? It would be helpful to include a sentence addressing this. [Bo Wu] Thanks again for the suggestion. The model was designed with scalability in mind, including SLOs/SLEs policy templates, as well as SDP and connectivity-construct definitions. These definition serve for the purpose: enabling reuse and minimizing redundant configurations. How about we add as a sentence in section 5: To ensure scalability of the Network Slice Service as the number of slices increases, "slo-sle-templates" can be utilized to reuse existing SLO/SLE policies. And the SDPs and connection constructs can be incrementally updated to minimize the overhead associated with frequent modifications. https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-18#section-5 Regards, Bo Thank you for this document, Ines -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
