Hi Mahesh, (changing the subject as this point is related to a teas WG doc + adding teas mailing list)
A choice would be intuitive here. However, a case it might be useful to have both rather than a choice is to handle migration cases. For example, a slice service was first bound to a very basic dedicated AC, but then the management of that AC is handed to the ACaaS because the AC is shared between several services. But, one would argue that the basic AC can also be created using ACaaS, which is fair as well. I let the authors of draft-ietf-teas-ietf-network-slice-nbi-yang clarify the intended usage. Independent of whether the current design is maintained or a choice is used, some text to explain the design rationale would be helpful in the spec. Thank you. Cheers, Med De : Mahesh Jethanandani <mjethanand...@gmail.com> Envoyé : mardi 2 avril 2024 23:09 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : Gyan Mishra <hayabusa...@gmail.com>; rtg-...@ietf.org; draft-ietf-opsawg-ac-lxsm-lxnm-glue....@ietf.org; opsawg@ietf.org Objet : Re: Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 Hi Med, Just one comment. See inline with [mj] On Apr 1, 2024, at 11:05 PM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Gyan, Thank you for the review. The candidate revisions can be tracked here: * https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff * https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff * https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ntw-attachment-circuit.diff * https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ac-lxsm-lxnm-glue.diff See more context inline. Cheers, Med -----Message d'origine----- De : Gyan Mishra via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Envoyé : vendredi 29 mars 2024 18:05 À : rtg-...@ietf.org<mailto:rtg-...@ietf.org> Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue....@ietf.org<mailto:draft-ietf-opsawg-ac-lxsm-lxnm-glue....@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 Reviewer: Gyan Mishra Review result: Has Issues I have been selected as the Routing Area Directorate Reviewer for the draft below: draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 I reviewed the latest version 6 and the ideas behind the concept of the draft makes sense, however some additional recommendations on clarity of the draft I believe is necessary before publication. This draft was presented at IETF 117 last summer by Mohamed Boucadair and adopted on November 6th 2023. As the draft was adopted fairly recently, my goal is to catch any issues with the draft before publication. The 3 additional drafts below were reviewed together as requested. ! Draft being reviewed draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 ! Additional drafts reviewed draft-ietf-opsawg-ntw-attachment-circuit-05 draft-ietf-opsawg-teas-attachment-circuit-06 draft-ietf-opsawg-teas-common-ac-05 All 4 drafts were adopted on November 6th 2023. I ran IDNITS against all 4 drafts and result was "no issues found here" Routing Area Directorate Review request Main Draft draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 Major Issues: None Minor Issues: The main use case for this draft is for network slicing [Med] Actually, no. This draft focuses on binding LxVPN to ACs. The required functionality to bind a slice service with ACs is built as part of the service slice model itself. FWIW, draft-ietf-teas-ietf-network-slice-nbi-yang includes the following: * "ac-svc-name": Indicates the names of AC services, for association purposes, to refer to the ACs that have been created. When both "ac-svc-name" and the attributes of "attachment-circuits" are defined, the "ac-svc-name" takes precedence. [mj] Is there a reason to have both? Should it not be a choice statement? | +--rw ac-svc-name* string | +--rw attachment-circuits | | +--rw attachment-circuit* [id] | | +--rw id string | | +--rw description? string | | +--rw ac-svc-name? string ____________________________________________________________________________________________________________ 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 https://www.ietf.org/mailman/listinfo/opsawg
