search

Open-Network-Models-and-Interfaces-ONMI / TAPI

LF ONMI Transport API Repository (TAPI)
https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/wiki
Apache License 2.0
95 stars 80 forks source link

NEP availableCepLayerProtocol plus OAM and Ethernet/OAM enhancements #370

Closed amazzini closed 5 years ago

italobusi commented 5 years ago

I have not found any discussion describing the problem we are trying to solve with this pull request

I am also not participating to MEF discussions

Is it possible to know more background information about these changes?

The need to add a timeStamp to pmHistoryData seems quite straightforward: it seems the proposed change is just fixing a bug

The need to add MD/MA attributes seems reasonable if IEEE 802.1Q naming is intended to be supported. It is not clear from the description (the UML diff is unreadable), what would be the impact of this change to the use of the ITU-T MEG-ID naming scheme

What about generic MEG-ID naming?

The need for the availableCepLayerProtocol is quite unclear. The NEP is a pool of potential CEPs, so I have always assumed (since TAPI 1.0) that the NEP layerProtocol is sufficient to qualify the layerProtocol of its potential CEPs

What is missing?

amazzini commented 5 years ago

I have not found any discussion describing the problem we are trying to solve with this pull request

I am also not participating to MEF discussions

Is it possible to know more background information about these changes?

The need to add a timeStamp to pmHistoryData seems quite straightforward: it seems the proposed change is just fixing a bug

In theory the HD start time can be derived from periodEndTime minus granularityPeriod. In MEF it was required to add dedicated attribute in HD.

The need to add MD/MA attributes seems reasonable if IEEE 802.1Q naming is intended to be supported. It is not clear from the description (the UML diff is unreadable), what would be the impact of this change to the use of the ITU-T MEG-ID naming scheme

I used red font in the diagrams, to identify the changes.

What about generic MEG-ID naming?

MD/MA is additional, for interworking purposes, so you can use either generic megIdentifier or MA name.

The need for the availableCepLayerProtocol is quite unclear. The NEP is a pool of potential CEPs, so I have always assumed (since TAPI 1.0) that the NEP layerProtocol is sufficient to qualify the layerProtocol of its potential CEPs

What is missing?

The number of CEPs per each layer protocol qualifier.

italobusi commented 5 years ago

I have not found any discussion describing the problem we are trying to solve with this pull request

I am also not participating to MEF discussions

Is it possible to know more background information about these changes?

The need to add a timeStamp to pmHistoryData seems quite straightforward: it seems the proposed change is just fixing a bug

In theory the HD start time can be derived from periodEndTime minus granularityPeriod. In MEF it was required to add dedicated attribute in HD.

This means that we are adding yet another error-prone redundant information

Would not be worthwhile documenting the relationship that the TAPI server shall enforce between these three attributes?