Child pages
  • 2019-06-27 OIMT Meeting notes
Skip to end of metadata
Go to start of metadata




  • Andrea Mazzini
  • Martin Skorupski


  • Admin
    • September F2F meeting
    • Feedback on Action item wiki page and work item wiki page
  • Profile & template model 
  • WT Equipment model 
  • Co-routing constraint in the Core model broader context 
  • Feedback on TR-512.3

Discussion items

  • Face-to-Face Meetings
    • 2019 September 9-13 ONF OIMT & OTCC Silicon Valley Meeting
        • Day: Monday - Friday (in parallel with ONF CONNECT, which is on Tuesday through Friday) 
        • Meeting venue: (Not co-located with ONF CONNECT)
        • Host:
        • Options of meeting formats
          • Private meeting (i.e., ONF member only):
            • Unless we get a firm statement from ONF, we cannot have an ONF meeting that excludes a particular ONF member. Otherwise there may be legal consequence.
          • Open meeting (i.e., open to the public)
            • If the meeting is open, then we need to make the Core model public. The Core model currently is still private (i.e., available within ONF only). Otherwise we have another legal problem.
                • AI: Nigel Davis  To propose an approach to make the Core model public. Core mode was made public just prior to the face to face meeting in September.
            • Even as the meeting is open to the public, the host may have problem with particular member attending the meeting in its facility.
              • A possibility is to hold the meeting at the ONF office
          • Virtual meeting: this should only be the last resort
        • Need to decide by mid-July on which option to take

Profile & Template model
  • Profile & template model
    • AI: Nigel Davis To provide the WT profile mechanism for discussion with Chris next week.
    • Conditional augmentation using constraint with simple xPath statement
    • A general profile class and a set of pacs of attributes associated to the profile
    • The application of the pacs are governed by the constraints. There is example in the UML-YANG guideline section 5.6.2.
    • A more general approach would be: Soft class with hard attributes (e.g., profile role that drives the augment).
    • WT driving use case: Lp profile
    • Two type of profiles: constraint profile (e.g., with range), instance profile (e.g., with specific concrete values)
  • Much discussion occurred on datatypes
    • Karthik: In TAPI, LayerProtocolName and LayerProtocolQualifier are defined in the TapiCommon module.
      • The LayerProtocolName is a Enum
      • The LayerProtocolQualifier is an extensible Enum, but it is intentionally empty in the common module and is expected to be augmented with layer-specific values in the respective technology-specific modules. Note that some example qualifiers of some LP names are provided in the description (Applied comments) of LayerProtocolQualifier.
        • Nigel comment: they should be in one place.
        • Karthik response: there are (will be) lot of unnecessary stuff in the Common datatype;
        • Nigel: no problem to remove those unnecessary stuff and even rename to such as ONF Common datatype.
    • AI: Nigel DavisKarthik Sethuraman (TAPI call) Discuss off line for a proposal on which datatypes should go into Common vs technology-specific modules. Datatypes to be considered will include Layer protocol (go to common), qualifier, and other things, such as operational state, alarm, performance monitoring, etc.

WT Equipment model
  • WT Equipment model
    • Nigel is working on aligning the TAPI equipment and the WT equipment models
    • Discussion on the use of class vs datatype.
      • Nigel reported that
        • Currently what the WT folks has been done with the Core model differ from the TAPI that they use classes rather than datatypes
        • Nigel and Martin think that the output YANG from the Core model form and output YANG from the datatypes from the tooling are essentially the same.
        • Nigel is trying to transform the core to datatype base and in parallel Martin will generate YANG from the core class to see what will come out from that. And see whether to align the core with TAPI.
      • Karthik noted that we should revisit the datatype mapping. He thinks the current way of dataype mapping is wrong, it should be a type, cannot be a grouping.
      • Nigel: What will the implication then?
        • Nigel: In core, use datatype for structural content
        • Karthik: If as class, then one has to provide an API for operations
      • Nigel: So the output YANG of class and datatype are the same is wrong. The output YANG of class and datatype should not be the same.
      • Datatype does/should not have object ID.
      • Nigel: What does the tool do with class without an ID defined?
        • Karthik: The tool map it to grouping. In YANG, one can have a list of things as typedef without a key. For class without and ID defined, you need to put a key in there so that looks like a class. Need a key if it is configurable.
        • Nigel: If it is not configurable, it is read-only, you don't need to address it. No key is fine.
        • Nigel: We can augment a list to add a member to the list.
      • Need further study on this issue.

Co-routing constraint

Defer to next week due to lack of time

Feedback on TR-512.3

Action items