Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • TAPI 2.1.3 Patch version (502)
  • Brief review of modifications on Tapi Edge/Develop (503)
    • ODU/OTU
    • Photonic
  • Continue on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC

Agred Items & Priority

  • Below the list of the agreed items and related priority for the next TAPI & RIA versions.
    • An item is blocking when its resolution is necessary precondition for the next delivery.
  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (blocking, 1)
    1. 3R
    2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs.
  2. OTS and OMS model (blocking, 2)
  3. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (blocking, 3)
    1. Lifecycle management of single ConnectivityService, necessary to identify UCs
  4. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 4)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  5. Elementary alarm (e.g. ITU-T cZZZ fault causes), including TCA related notif), current and history (blocking, 5)
  6. Photonic model capability (blocking, 6)
  7. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  8. RESTCONF Response codes for use cases (not blocking)
  9. TAPI OAS, action points to be assigned (not blocking)
  10. Routing Constraints (not blocking)
  11. Physical Route (not blocking)

Discussion items

10 minsAdministrative

TAPI Call: 2 hours

Continue discussion on

  • OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • Check the possible consequences of OTU/OTSiA agreed use cases to MCA/OTSiMCA model
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC
40 mins

TAPI 2.1.3 Patch version (502)

All

Andrea Mazzini presents the minor corrections of 502, plus the proposal to add central-frequency to media-channel-config-pac.

  • Arturo Mayoral clarifies that the RIA referring to TAPI 2.1.3 needs some minor corrections/amendments, but no modifications on the model.
  • Ramon Casellas and Arturo Mayoral highlight that version 2.1.3 is already used in several implementations, hence adding a new leaf (central-frequency) can lead to interoperability issues.
    • Furthermore, to provide a correct alternative to spectrum provisioning, also spectrum bandwidth would be necessary besides central frequency.
    • Another issue concerns the presence of two mutually exclusive provisioning types in the same media-channel-config-pac.
    • The team agrees to postpone this enhancement to the next TAPI major version.
    • Likely the next major version will be the 2.3, with some breaking of backward compatibility.
  • In the scope of 2.1.3 possible corrections, Arturo Mayoral indicates the issue 501, regarding the "presence" statement in context:
container context {
    uses tapi-context;
    presence "Root container for all TAPI interaction";
    description "none";
}
  • This "presence" statement is driven by "RootElement" stereotype. It indicates when a container must be anyway present regardless the existence of children:

7.5.1. Containers with Presence

YANG supports two styles of containers, those that exist only for organizing the hierarchy of data nodes and those whose presence in the data tree has an explicit meaning. In the first style, the container has no meaning of its own, existing only to contain child nodes. In particular, the presence of the container node with no child nodes is semantically equivalent to the absence of the container node. YANG calls this style a "non-presence container". This is the default style.

In the second style, the presence of the container itself carries some meaning, representing a single bit of data. For configuration data, the container acts as both a configuration knob and a means of organizing related configuration nodes. These containers are explicitly created and deleted. YANG calls this style a "presence container", and it is indicated using the "presence" statement, which takes as its argument a text string indicating what the presence of the node means.

  • Team agrees that the "presence" statement is there exactly to indicate that context must always be present, regardless of current existence of children.
  • Agreed to ask for more clarifications regarding the mentioned "important impact on implementations" in issue 501. Done.
100 mins

Brief review of modifications on Tapi Edge/Develop (503)

  • ODU/OTU
  • Photonic

Andrea Mazzini presents the modifications of 503.

  • Agreed the new attributes of MC and OTSiMC CSEP and CEP.
    • OTSi CSEP and CEP attributes need further review, as discussion moved to the following item.
  • Discussion on OTU and OTSi CSEP model. Reached a preliminary agreement on the model to be used for two distinct use cases:
    1. OTU Connectivity Service involving more OTSi SIPs (hence OTSiA with more OTSi, inverse mux case)
    2. OTU Connectivity Service involving one OTSi SIP (OTSiA with single OTSi or OTSiA with more OTSi, inverse mux case but on same SIP)
  • Below the first case:


  • Below the second case, where Arturo Mayoral highlights the assumption that OTSi SIP has multi-layer capability, i.e. including also OTU/ODUCn:


  • Nigel Davis underlines that currently any provisioning capability implies the presence of a SIP. This may not be convenient in a number of detailed provisioning scenarios, involving resources at any point of the managed domain. Agreed that TAPI Service is oriented to "end to end" provisioning: more detailed provisioning may fall in the "constraints" chapter or similar.
  • Mentioned the scenario where OTN is not present and a DSR is directly mapped on OTSi:

  • Malcolm Betts notes that there could be two distinct scenarios, where the DSR at UNI
    1. is mapped into another DSR "container", or
    2. is directly mapped into OTSiA.
  • For further analysis.