Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Streaming model (Nigel)
  • Equipment model questions (Arturo)
  • Revision date issue in TAPI v2.1.2 yang models (Arturo)
  • Routing Constraints (Andrea)
  • ODU OAM (Andrea)
  • Photonic Model

Discussion items

10 minsAdministrative

Next TAPI Call: 

  • Nigel DavisTAPI Roadmap:
    • Updated including a new version 2.3 which purpose is to anticipate a selection of 3.0 features. Selection is made on less impacting features, specially considering backward compatibility.
    • Proposed the introduction of an additional 2.4 version specially dedicated to documentation. Furthermore some simple 3.0 features (backward compatible, e.g. ODU L1) can be moved to this new 2.4 version.
    • We need a plan for documentation - see related discussion below.
  • Andrea Mazzini, Karthik Sethuraman to provide more details on Ethernet (L2) feature.
  • 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!
30 minsTAPI Documentation
  • There is an urgent need to produce TAPI documentation / tutorials. The following items were considered:
  1. Provide an organized index of available presentations
  2. Select some key slides from available presentations
  3. Add explanatory text for more opaque subjects
  4. Plan the review of Arturo Mayoral's TR-5XX.1-TAPI v2.1.2 Reference Implementation_v0.1.docx
  5. Expand descriptions in UML diagrams
  6. Update Functional Requirements for Transport API (TR-527) - June 2016
20 minsStreaming Model
  • Nigel Davis presents the UML diagram of draft TAPI Streaming Model
    • An updated version of the presentation can be found at otcc2020.ND.001_TapiStreaming.zip. The .zip file also includes the UML model, data dictionary (generated using gendoc) and Yang (generated using Eagle tooling). 
    • It is intended that the model be reviewed in more detail on the TAPI call next week.
    • There had been a suggestion that the streaming model could be constructed by adapting the notification model. This has been explored, but it appears that the two approaches are sufficiently different to cause significant additional complexity. This will be further explored.
    • In the slide pack some areas of additional work on streaming are highlighted.
60 minsEquipment Model: slot and sub slot casesArturo Mayoral

Arturo Mayoralpresents the "TAPI Equipment model doubt" email exchange with <n>Nigel Davis</n>:

1) How a pluggable equipment (Small-Form-Factor equipment category according the model) can be related to an “Access-port”, which is to the best of our knowledge the entity related to the logical tapi models (tapi-topology:node-edge-point). <n> You are correct that AccessPort is the bridge between the logical model (NEPs etc.) and the PhysicalModel. There is more explanation of this in the ONF Core model document TR-512.6_OnfCoreIm-Physical (I suspect you have this already, but if not, then get https://www.opennetworking.org/wp-content/uploads/2018/12/TR-512_v1.4_OnfCoreIm-info.zip and locate it in there). </n>

This is the block diagram we are trying to construct but we miss the red relationship.


<n> I will use the UML (which should have direct equivalence in the Yang). The relationship is carried by the connectorPin property of AccessPort.

This is of type ConnectirPinAddress:

The property provides you with the UUID of the Equipment, which will let you locate the SFF Equipment. It also provide pin/connector details for more complex cases (for the SFF Equipment, it is probably not that relevant).

Note that the relationship is one way. It is assumed that the client is using the TAPI interface to populate a data base and can set up the reverse navigation itself upon receipt of the AccessPorts. </n>


2) Secondly, if you see the drawing we have depicted two possible equipment configurations.

i.  The first possibility is that a “Circuit-Pack” equipment (i.e., a Shelf’s board) does just contain holders equipped with “pluggables” (Small-Form-Factor equipment category according the model). In this case the model is pretty clear.<n> This is the expectation (see also TR-512.6 mentioned earlier). </n>

ii.  The second case, a bit more complicated, is that there are multiple sub-slots within a “Shelf” (Sub-Rack equipment category according the model) slot. <n> The expectation is that an equipment has holders and a holder may be occupied by an equipment.

</n>

 In this case, a possible representation according to the data model is to introduce a “virtual Circuit-Pack” equipment (which does not contain “Actual-equipment” nor “Expected-equipment“) <n> You mean an Equipment with null expectedEquipment and null actualEquipment? This was not an intended state, but we did not put a rule in to prevent it, so the model does seem to allow it. </n> that contains a list of “equipment-holder” which represents the “Sub-Slots”. These “Sub-Slots” do potentially pointer to the actual “Circuit-Packs” which are represented by an “Equipment” object which may contain “Actual-equipment” or “Expected-equipment“ sub-tree attributes depending on the case. <n> We ought to put a rule in TAPI to “prevent” this unless you can see a very good case for it where the model as intended does not work. If you have got such a case, I would be very keen to discuss it. I suggest not using this mechanism, but to instead use what you described in point (1) and have actual or expected equipment in between each level of holders. The model is intended to represent solid things that have spaces for other solid things where, in the telecoms environment, each space is restricted to have only one thing in it (a thing can occupy more than one space). We intentionally did not deal with rooms and floor layout where this rule does not apply. If you are aiming to use the model for more freeform cases, then we should discuss in detail in TAPI. </n>


After some discussions on "horizontal vs. vertical" holder models, where a circuit-pack may occupy more slots (horizontal) or a fraction of a slot (vertical), together with the case a same slot may be occupied by a single pack or by two packs, this is the temporary conclusion:

  • three different scenarios are considered:
    1. "Division": The equipment slot (and sub-slot) structure is fixed: there is only one level of Holder objects, which may represent both "full slot" space or "sub slot" space cases. In other words, the Holder always represents the smallest granularity occupance model (as per current definition).
    2. "Hierarchy": The equipment slot structure can evolve: an additional level of "SubHolder" objects is introduced. The SubHolder class inherits from Holder and is introduced only to avoid Holder recursion, which is difficult to manage in YANG. This SubHolder object is used when an existing Holder object instance, representing a full slot space, needs to be decomposed into more "sub slot" spaces.
    3. "Specific Hw": Same as case 2. above, but (management information about) specific hardware is necessary to implement "sub-slotting". In this case, the existing Holder object will host an Equipment object (either reusing category SUBRACK or adding a new enum, e.g. SUBSLOT) which in turn "HasHolders" (the sub-slots).

Nigel Davis there can be cases where the slot configuration may follow complex composition rules similar e.g. to the SDH payload structure rules. For further study. The idea here is that all holder schemes within a particular Equipment are declared in a flat structure (as equals) and then any dependencies are stated as rules between holders and groups of holders. So a Slot that could alternatively be considered as two halfslots would have three holders declared where anything present in one of the halfslots would block the full slot. This scheme appears to be least disruptive to an existing equipmet where an unexpected opportunity for use of halfslots becomes available.. The scheme also allows form more flexibility than the simple hierarchies discussed above. Clearly there can be default rules for simple cases and shorthand for expressing the rules for common complex cases.





Action items

  •