Hi Mahesh, Thanks for the AD review.
A new version that takes into account your review is published: draft-ietf-opsawg-ac-lxsm-lxnm-glue-10. This version also includes some other edits to enhance the readability and fix some few nits. Some of the changes will be reflected in other I-Ds of the AC document sets. Please see inline for more context, fwiw. Cheers, Med De : Mahesh Jethanandani <mjethanand...@gmail.com> Envoyé : samedi 8 juin 2024 23:45 À : draft-ietf-opsawg-ac-lxsm-lxnm-g...@ietf.org Cc : opsawg-chairs <opsawg-cha...@ietf.org>; opsawg@ietf.org Objet : AD review of draft-ietf-opsawg-ac-lxsm-lxnm-glue Dear Authors, Thanks for working on this document. The document is short and easy to read. Thanks for adding examples to explain the use case. Please find some COMMENTS and NITS. I hope the authors find the comments helpful to improve the document further. ------------------------------------------------------------------------------- COMMENT ------------------------------------------------------------------------------- Section 3, paragraph 2 > Figure 1 depicts the relationship between the various AC data models: Most drafts specify which module is being imported with which prefix and refer to the document where the modules is being imported from. [Med] OK to add such table for the reader's convenience. As an example, what is the prefix for ietf-ac-common module that is used by the YANG model in this draft? [Med] This one is not imported here, but I understand that you were simply providing an example to illustrate your comment. Section 4.1, paragraph 5 > * A single CE may terminate multiple ACs, which can be associated > with the same bearer or distinct bearers. Is there a CE in the diagram that you can point to for this? [Med] Updated the figure so that we can cite CE4 for this case. Updated the figure to also mention the bearers where this is not implicit. Section 4.1, paragraph 5 > * Customers may request protection schemes in which the ACs > associated with their endpoints are terminated by the same PE > (e.g., CE#3), distinct PEs (e.g., CE#34), etc. The network > provider uses this request to decide where to terminate the AC in > the network provider network and also whether to enable specific > capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)). But there is no CE#34. Did you mean CE#3 and CE#4? [Med] Fixed to CE4. Thanks for catching this. Also, how is CE#4 connected to distinct PEs is not clear from the diagram. All folks see is two AC, just the same as CE#3. Can the diagram be enhanced to show the difference? [Med] We initially avoided to draw PEs because the customer is not aware about which PE is being used. We understand that this may be confusing so added them to the figure but without numbering them. While you are at it, can you explain what is "network provider network". [Med] We meant "service provider network". Fixed. Section 4.2, paragraph 2 > Figure 3 shows the positioning of the AC models in the overall > service delivery process. This diagram is not clear to me. Which AC models are you referring to? There are ietf-ac-svc, ietf-ac-glue, and ietf-ac-ntw models, but none without the ietf- prefix. If you are referring to their prefixes, then say so, and highlight that in Conventions and Definitions. The prefixes there do not match the prefixes here. [Med] Updated the figure with the full module names. Also, updated the description to cite the modules. Section 6, paragraph 1 > This module uses references defined in > [I-D.ietf-opsawg-teas-attachment-circuit] and > [I-D.ietf-opsawg-ntw-attachment-circuit]. Is that it? I see it imports module from RFC 8299, 8466, 9182, to just name a few. Please reference each of them. [Med] These other imports are for augment purposes. Added them. Section 6, paragraph 14 > description > "Augments VPN site network access with AC provisioning > details."; These descriptions are not helpful. And if they are the same, why do we need so many different augments? The description should say more than which two endpoints are being "glued" together. It should highlight which augment should be used in which case, and maybe use the diagrams above to help explain use cases. [Med] Updated the description accordingly. Section 7, paragraph 8 Since the draft does not define any RPCs, please add a statement here to that effect. [Med] We don't usually add such statement per the security template (https://wiki.ietf.org/group/ops/yang-security-guidelines). We prefer to keep the content consistent with the template. Thanks. This document does not use RFC2119 keywords, but contains the RFC8174 boilerplate. [Med] Fixed. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 0 > The document specifies a YANG module ("ietf-ac-glue", Section 6) that > updates existing service and network Virtual Private Network (VPN) > modules with the required information to bind specific services to > Attachment Circuits (ACs) that are created using the AC service model > [I-D.ietf-opsawg-teas-attachment-circuit], specifically the following > modules are augmented: s/, specifically/. Specifically,/ [Med] OK Section 3, paragraph 8 > "ietf-ac-common" is imported by "ietf-bearer-svc", "ietf-ac-svc", and > "ietf-ac-ntw". Bearers managed using "ietf-bearer-svc" may be > referenced in the service ACs managed using "ietf-ac-svc". > Similarly, a bearer managed using "ietf-bearer-svc" may list the set > of ACs that use that bearer. In order to ease correlation between an > AC service requests and the actual AC provisioned in the network, > "ietf-ac-ntw" uses the AC references exposed by "ietf-ac-svc". To > bind Layer 2 VPN or Layer 3 VPN services with ACs, "ietf-ac-glue" > augments the LxSM and LxNM with AC service references exposed by > "ietf-ac-svc" and AC network references exposed bt "ietf-ac-ntw". s/bt/by/ [Med] Fixed. Document references draft-ietf-opsawg-teas-attachment-circuit-09, but -13 is the latest available revision. Document references draft-ietf-opsawg-ntw-attachment-circuit-07, but -11 is the latest available revision. Document references draft-ietf-netmod-rfc8407bis-09, but -11 is the latest available revision. Document references draft-ietf-opsawg-teas-common-ac-08, but -11 is the latest available revision. Document references draft-ietf-teas-ietf-network-slice-nbi-yang-10, but -13 is the latest available revision. Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
