How can State Attributes be manipulated during the creation or updating of a connectivity service?

[jahveen]

Hello,

I am testing our implementation of the Presto API. We have used the swagger specification in the Presto SDK (aretha tag), which is derived from the YANG files. My problem is that there is no way to manipulate the state attributes during the creation or updating of a connectivity service.

In MEF 60, the connectivity service operations are described. With specific reference to sections "14.2.5 createConnectivityService", "14.2.6 updateConnectivityService", and "14.2.7 deleteConnectivityService", the instructions are to "leverage the OperationalState and AdministrativeState variables".

I try to follow those instructions, but when creating or updating a connectivity service, the OperationalState and AdministrativeState variables are not available.

I examined the YANG files. The state attributes are defined in tapi-common as the grouping "admin-state-pac", where the grouping consists of named attributes administrative-state, operational-state, and lifecycle-state. This grouping is not shown in "rpc create-connectivity-service", or "rpc update-connectivity-service" within tapi-connectivity.yang, and therefore, are not available in the swagger specification we use.

How then should I leverage the OperationalState and AdministrativeState variables?

Thanks,

Jahveen

[MichalLaczynskiAmartus]

Hello Jahveen,

I have taken this question to people who implemented this. I will get back as soon as possible.

Michał

[amazzini]

Hello Jahveen, I see in both create and update CS the leaf state { type string; description "none"; } Which should be the intended input parameter to drive the CS administrative-state. Note that only admin state is writable, operational state is read-only as it represents the state of the network resource. From L77049_001_MEF W89 - MRM Common - Draft V1.2.3_Mazzini.docx<https://wiki.mef.net/download/attachments/130254615/L77049_001_MEF%20W89%20-%20MRM%20Common%20-%20Draft%20V1.2.3_Mazzini.docx?version=1&modificationDate=1618615189000&api=v2>: * “The operational state gives the information about the real capability of a resource to provide or not provide service", * "The administration of managed objects operates independently of the operability and usage of managed objects and is described by the administrative state attribute. The administrative state is used by the operator to make a resource available for service, or to remove a resource from service." I guess there is a limitation in the uml2yang tool concerning rpc parameters, hence the below enum defined in TapiCommon becomes a simple string in the rpc: typedef administrative-state { type enumeration { enum LOCKED { description "Users are administratively prohibited from making use of the resource."; } enum UNLOCKED { description "Users are allowed to use the resource"; } } description "The possible values of the administrativeState."; } Hope this helps Kind regards Andrea Andrea Mazzini Sr. Systems Engineer Emerging Product Unit - Standards Optical Networks Division Network Infrastructure, Nokia Via Energy Park 14, Vimercate 20871, Italy ***@***.******@***.***> Mobile: +39 348 28 14 030 From: jahveen ***@***.***> Sent: Monday, July 5, 2021 11:30 AM To: MEF-GIT/mef-lso-presto-sdk-community <MEF LSO Presto SDK ***@***.***> Cc: Subscribed ***@***.***> Subject: [MEF-GIT/mef-lso-presto-sdk-community] How can State Attributes be manipulated during the creation or updating of a connectivity service? (#8) Hello, I am testing our implementation of the Presto API. We have used the swagger specification in the Presto SDK (aretha tag), which is derived from the YANG files. My problem is that there is no way to manipulate the state attributes during the creation or updating of a connectivity service. In MEF 60, the connectivity service operations are described. With specific reference to sections "14.2.5 createConnectivityService", "14.2.6 updateConnectivityService", and "14.2.7 deleteConnectivityService", the instructions are to "leverage the OperationalState and AdministrativeState variables". I try to follow those instructions, but when creating or updating a connectivity service, the OperationalState and AdministrativeState variables are not available. I examined the YANG files. The state attributes are defined in tapi-common as the grouping "admin-state-pac", where the grouping consists of named attributes administrative-state, operational-state, and lifecycle-state. This grouping is not shown in "rpc create-connectivity-service", or "rpc update-connectivity-service" within tapi-connectivity.yang, and therefore, are not available in the swagger specification we use. How then should I leverage the OperationalState and AdministrativeState variables? Thanks, Jahveen — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://github.com/orgs/MEF-GIT/teams/mef-lso-presto-sdk-community/discussions/8>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADB35WBSHVUONBEVAS3BEBDTWF3RNANCNFSM472LEF6Q>.

[rgaglian]

Hi Jahveen,

I would recommend you against implementing these RPCs instead of the NETCONF/RESTCONF native APIs.

If you check the TR-547, these RPCs are not part of the reference implementation (or considered optional) from the ONF and the following text is given:
"Currently there are two allowed APIs resources defined in RESTCONF. Although both are compatible and
valid, given the low penetration in the industry of the RPC-based API implementation, it is not currently
included in this specification.
Thus, the current specification takes the support of the RESTCONF ‘data’ API as mandatory; while
the ‘operations’ API, based on the TAPI defined RPCs, is considered optional."

I have participated in several TAPI interop and only native RPCs are required.

Regards,
Roque

Reference:
https://opennetworking.org/wp-content/uploads/2020/08/TR-547-TAPI-v2.1.3-Reference-Implementation-Agreement-1.pdf

[jahveen]

Hello Michał, Andrea, and Roque. Thanks for your prompt responses.

Firstly, Roque - thanks for your recommendation. I will let my colleagues know this, however, the Operations API (the RPC based API) is what is currently being implemented.

Andrea - I have reviewed the MEF W89 draft document. I notice that the MEF LSO Presto SDK (which we rely on) has versions of the TAPI YANG files (and swagger specification file) that are over 2 years old, and as such, the rpc definitions are not in-sync with the document. The current TAPI YANG files (v2.3) in the ONF github repository better describes and constrains the rpc attributes. For example:

        leaf state {
            type tapi-common:administrative-state;
            description "The Administrative State of the ConnectivityService instance to be created";
        }

Also, the attributes "uuid" and "name" are present, which we expected to see in the first place. For us to continue our development, I believe we either need the YANG files in the SDK to be updated, or we should implement a swagger specification using the latest YANG files and the yang2swagger tool.

Let me know your thoughts.

Thanks,

Jahveen