Hi Bo, Thank you for addressing my comments. I agree with the modifications.
Best regards, Ines On Tue, Jan 21, 2025 at 2:59 PM Wubo (lana) <lana.w...@huawei.com> wrote: > 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 <nore...@ietf.org> > Sent: Saturday, January 11, 2025 4:06 AM > To: gen-art@ietf.org > Cc: draft-ietf-teas-ietf-network-slice-nbi-yang....@ietf.org; > last-c...@ietf.org; t...@ietf.org > 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 > > >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
