Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Routing Constraints (Andrea)
  • ODU OAM (Andrea)
  • Photonic Model

Discussion items

50 minsAdministrative

Next TAPI Call: 

  • Agenda 
  • Agreed to set up a "long call" for detailed review of TR-5XX.1-TAPI v2.1.2 Reference Implementation on Tuesday February 4, from 12 to 6pm CET.
  • Next F2F Meeting Plan - not discussed. Current plan is: 
    • Week of 
      • Should we schedule it earlier? In April time-frame?
    • Location: Telefonica, Madrid
  • All, TAPI Roadmap:
    • Introduced versions 2.4 and 2.5
    • Isolated in "edge" version the more advanced and not backward compatible features.
    • For each feature in roadmap add the reference to the related contribution(s).
      • When preparing a new contribution, consider the possible mapping to a specific (set of) feature(s).
    • We need a plan for documentation - see related discussion at 2020-01-07 TAPI Meeting notes.
  • Andrea Mazzini, Karthik Sethuraman to provide more details on Ethernet (L2) feature.
    • Done: "Ethernet model, verify alignment/consistency with "ITU-T G.8052.1 UML & YANG and the IEEE 802.1Qcx CFM YANG" outcomes".
  • Nigel Davis to provide more details on ETSI NFV feature, as it seems more related to Core IM than TAPI.
  • Action to ALL, please check the roadmap and enhance feature descriptions!
  • With reference to Streaming model, clarified how to create a TAPI Release Candidate (RC):
    1. Perform the pull request
    2. Review the model during the calls
    3. Iterate 1, 2 to build the RC, in this case with all 2.3 agreed features
    4. Rule is to leave two weeks for people to review the whole RC
      • For the end of March delivery, the review period shall start mid of February
20 minsStreaming Model

  • Central class is "Stream".
  • To be investigated the relationship between LogRecord and OAM PM (history) data.
  • Conditions for augmentation, the tool does not support the feature. Descriptions should be specified in IISOMI guidelines, Draft_TR-531_UML-YANG_Mapping_Gdls_v1.1.02.docx, 5.6.2 Mapping of Dependencies.
  • All readable items must be part of the YANG tree - which in UML translates in composition from root contexts. As far as LogRecord is not readable, it does not need to be a composition of any context, i.e. it can remain "isolated". This is different from Notification signal, which is composition of NotificationContext, because it is assumed that Notifications can also be read.
30 mins

Revision date issue in TAPI v2.1.2 yang models

Arturo Mayoralshows the recent email on the subject:

I will try to summarize the status of the discussion and the possible alternatives to move forward.

The minor release 2.1.2 was launched with missing/wrong release data. In particular, the following data remained unchanged from the v2.1.1:

  •  Model filenames (.tree, .yang).
  •  Revision yang statement (only in .yang files)
  •  Release final commit, e.g.: Renamed YANG, TREE & OAS files with 2.1.2 revision date @2019-07-11 

In order to fix this and make the release 2.1.2 consistent with the rest of releases of TAPI, there are various alternatives:

  1. Make a new commit only over the tag v2.1.2 model files which were modified in the latest update i.e.: tapi-notifications,  tapi-photonic-media, tapi-path-computation (and maybe tapi-connectivity which .tree file has changed but the .yang not). This commit should change the revision date where appropriate, to the date of this new commit (e.g., @2020-01-14).
  2. Make a new commit only over the tag v2.1.2 model files which were modified in the latest update i.e.: tapi-notifications,  tapi-photonic-media, tapi-path-computation (and maybe tapi-connectivity which .tree file has changed but the .yang not). This commit should change the revision date where appropriate, to the date of the latest modification done in the model (e.g., @2019-07-11).
  3. Make a new commit over all the tag v2.1.2 model files. This commit should change the revision date where appropriate, to the date of this new commit (e.g., @2020-01-14).
  4. Make a new commit over all the tag v2.1.2 model files. This commit should change the revision date where appropriate, to the date of the latest modification done in the models (e.g., @2019-07-11).

Agreements:

  1. Option 2. is the preferred one, but with the "end revision period" date, rather than the date of latest modification.
  2. Files with ".tree" extension keep same date of ".yang" files.
  3. It is recommended to fill the "revision" part of YANG modules, e.g.

revision 2019-03-31 {
    description "ONF Transport API version 2.2-RC1.
        Changes included in this TAPI release (v2.2) are listed in
    
    <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.2.md>";
    reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
        <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.2.0/UML>";
}
revision 2018-12-10 {
    description "ONF Transport API version 2.1.1.
        Changes included in this TAPI release (v2.1.1) are listed in
       <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.1.1.md>";
    reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
        <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/UML>";
}

  • Karthik Sethuraman will update the files of branch "v2.1-bug-fixes" and the "revision" parts in YANG modules.

Karthik Sethuraman suggests to reference a proper project in the commits:


15 mins

Review plan of TR-5XX.1-TAPI v2.1.2 Reference Implementation_v0.1.docx

and is adding his replies.

  • Arturo agrees to deliver the currently available version to allow team to start review.
  • Agreed to set up a "long call" for detailed review on Tuesday February 4, from 12 to 6pm CET.

Action items

  •