General Information:

Agenda:

  • Status overview - Plan for model freeze
  • PNF model
  • Lifecycle of the model - rule for changing the state
  • VES model change

Material:

Minutes:

  • Status overview
    • question: what people would like to include in R3 model, allow updates after model freeze?
    • Thinh: scaling, placement rule (affinity/anti-affinity), instantiation level, R2+ model aligment with latest IFA spec
    • Xiang Li: PNFD
    • Xu: preference is to include what have discussed (and likely to reach consensus) in previous calls
    • About clean page, shall we use R2 clean page as the basis? or use the papyrus document?
  • PNF model
    • change class name to PNFD, using camel case for attribute/type/...
    • Alex: who manage the PNF
      • opinion 1: EMS, which is managed by a service provider; PNFD only describes the connectivity of the PNF
      • opinion 2: ONAP will do homing, configuration, etc. for the PNF; EMS could help in discovery progress; PNFD describes a type of PNF; PNF instance has a correlation ID (e.g., MAC address, serial number, etc.); work order will carry the correlation ID (to the SO)
    • Question:
      • PNFD describes a PNF instance or a class/type of PNF?
      • geographic location / correlation ID should be part of the PNFD or PNF instance? Gil: geo location be part of the PNFD, but no value.
      • 5G use case or simple PNF management?
    • please look at Nokia's proposal on PNF registration (DCAE) 

      https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play

  • Lifecycle of the model - rule for changing the state
    • proposing rule "use "experimental" as the starting state, move to "preliminary" if no changes are made after 1 release (move back to "experimental" if there are), and move to "mature" if no changes are made after another release"
    • no objections on the starting state (mostly are "preliminary")
    • Thinh ask for more time for discussion
  • VES model change
    • please see the material

Video and Audio:

video

audio

  • No labels

1 Comment

  1. Gil Bullard

    The "PNF Plug N Play" work that Nokia is leading in Casablanca describes a PNF onboarding and registration approach that is intended to work for all PNF types, including "simple" PNF types (e.g., CPEs, RGs, Consumer IOT devices, etc.) and "complex" PNF types (e.g., Infrastructure PNFs such as 5G DU, PE Routers, etc.).  Fundamental to driving the runtime behavior of ONAP is the assumption that a when Service Instantiation request arrives into ONAP which decompose into Resources which include PNF Resources, that Service Instantiation request will have 2 attribute values for each PNF instance required by that Service instance:  "geographical_location_info" (which defines where the PNF is physically located) and "correlation_id" (which uniquely identifies the PNF instance, such as a serial number or MAC Address).  How should this fact affect the Info Model for the PNF Resource?  Of course there would be no "geographical_location_info" or "correlation_id" in the PNF Descriptor onboarded into ONAP with a PNF.  However, somewhere in the info model there should be something that indicates that PNFs have some attributes that VNFs do not: specifically "geographical_location_info" or "correlation_id" specifically "geographical_location_info" *and* "correlation_id"