[RTG-DIR] ac-svc-name/attachment-circuit (was RE: Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06)

[[e-mail]]

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 <[e-mail]>
Envoyé : mardi 2 avril 2024 23:09
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Gyan Mishra <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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, [e-mail]<mailto:[e-mail]> 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 <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 29 mars 2024 18:05
À : [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.