BRIDGE: https://zoom.us/j/661303200?pwd=TFdRd0c2MTJUem8xa252UGJHTE1Mdz09

Passcode: 209247

We will start our meetings by mentioning the project's Antitrust Policy, which you can find linked from the LF and project websites. The policy is important where multiple companies, including potential industry competitors, are participating in meetings. Please review and if you have any questions, please contact your company legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.

...

...

05:54:36 From  Sai Seshu  to  Everyone:
    #info Seshu, huawei
05:57:13 From  Alla Goldner  to  Everyone:
    #info Alla Goldner, Amdocs
05:58:39 From  Magnus Buhrgard  to  Everyone:
    #info Magnus Buhrgard, Ericsson
05:58:52 From  N.K. Shankaranarayanan  to  Everyone:
    #info N.K.Shankar, STL
06:00:12 From  Ranny HAIBY (Samsung)  to  Everyone:
    #info Ranny Haiby, Samsung
06:00:16 From  bin.yang@windriver.com  to  Everyone:
    #info Bin Yang, Wind River
06:00:25 From  Yuanhong Deng (China Mobile)  to  Everyone:
    #info Yuanhong Deng, China Mobile
06:00:35 From  Bruno Sakoto  to  Everyone:
    #info Bruno Sakoto, Bell Canada
06:00:55 From  Fred Oliveira  to  Everyone:
    #info Fred Oliveira, Self
06:01:09 From  Dong Wang (China Telecom)  to  Everyone:
    #info Dong Wang, China Telecom
06:01:10 From  Timo Perala (Nokia)  to  Everyone:
    #info Timo Perala, Nokia
06:01:12 From  Andreas GEISSLER (DT)  to  Everyone:
    #info Andreas Geissler, DT
06:04:52 From  Eric Debeau  to  Everyone:
    #info Eric Debeau, Orange
06:05:03 From  Catherine Lefevre  to  Everyone:
    #info Catherine L, ATT
06:05:15 From  Kenny PAUL (LFN)  to  Everyone:
    @eric, @catherine - thanks
06:31:18 From  Kenny PAUL (LFN)  to  Everyone:
    https://wikilf-onap.onapatlassian.orgnet/wiki/x/RqYEBwm7r7
06:57:05 From  N.K. Shankaranarayanan (STL)  to  Everyone:
    Comment re. EMCO_ONAP Alignment Proposal: Slides 1,2,3 mentions Non-RT RIC (SMO). The SMO is an entity defined by O-RAN and it has the O2 interface to the O-Cloud. The alignment of EMCO and O-RAN should be addressed. This comment is related to the O2 question on Slide 7.
07:15:43 From  Zu Qiang (Ericsson)  to  Everyone:
    rh
07:16:02 From  Marian Darula  to  Everyone:
    rh
07:16:06 From  Thinh NGUYENPHU  to  Everyone:
    RH
07:16:13 From  Magnus Buhrgard  to  Everyone:
    rh
07:16:20 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    Rh :)
07:16:46 From  Catherine Lefevre  to  Everyone:
    Dear all - i suggest that we start the questions after Xu finished his presentation
07:16:53 From  Catherine Lefevre  to  Everyone:
    Thank you
07:18:20 From  Kevin Sandi (LFN)  to  Everyone:
    I’m sorry I have to leave the call to take care of an urgent personal matter
07:20:10 From  Timo Perala (Nokia)  to  Everyone:
    +1 Shankar. Fully agree with you.     That's why I have advertised the event since mid Feb to the community meeting on Wednesdays,, the meeting "ONAP/O-RAN-SC Alignment for SMO/NONRTRIC/OAM/SIM"
07:20:19 From  Fred Oliveira  to  Everyone:
    I support this approach to map the ONAP IM to support ASD.
07:22:59 From  Andy MAYER (AT&T)  to  Everyone:
    Mapping is a great approach for the parent class. We need to make sure that any new classes introduced by ASD are reflected in the Information Model as well.
07:23:49 From  Thinh NGUYENPHU  to  Everyone:
    I have prepared a slide set to clarify ASD concept rationales and highlight some of the IFA011 ETSI MANO differences
07:24:10 From  Andy MAYER (AT&T)  to  Everyone:
    The ASD Data Model (implementation) can map only the pieces of the information model that are part of the implementation.
07:24:58 From  Andy MAYER (AT&T)  to  Everyone:
    The important part is to capture the Data Model mapping. Plus augment the Information Model where there are gaps.
07:25:14 From  Xu YANG  to  Everyone:
    Yes, Andy is right. And actually the Mandatory here is not mandatory for the onboarding model, but to the orchestrators.
07:26:03 From  Andy MAYER (AT&T)  to  Everyone:
    RH
07:30:26 From  Fred Oliveira  to  Everyone:
    I agree with Andy and Xu. IMHO ONAP IM should only need minor  changes to support the ASD needs.
07:31:46 From  Fred Oliveira  to  Everyone:
    The ONAP IM references the IFA011 but is maintained independently and doesn’t require ETSI input/agreement
07:37:18 From  Xu YANG  to  Everyone:
    What Zu and Thinh shows are still from the perspective of implementation/DM, we shouldn't mix them with the discussion of the IM.
07:40:52 From  Marian Darula  to  Everyone:
    DM model reflects the architecture of IM. If we adopt ETSI MANO in ASD, than we need to implement concepts of ETSI MANO architecture in ASD. This is exactly what we wanted to avoid, and reason why ASD was invented.
07:41:46 From  Xu YANG  to  Everyone:
    No, merging the IM doesn't mean you need to use the ETSI MANO in implementation.
07:42:13 From  Xu YANG  to  Everyone:
    It doesn't mean you need to modify SOL001 as a DM.
07:45:07 From  Bruno Sakoto  to  Everyone:
    Sorry, I have to drop
07:46:01 From  N.K. Shankaranarayanan (STL)  to  Everyone:
    Important discussion. I will catch up with the recording. I have another critical call to join. Thanks.
07:46:25 From  Xu YANG  to  Everyone:
    rh
07:46:52 From  Lingli  to  Everyone:
    RH
07:48:53 From  Bruno Sakoto  to  Everyone:
    Back
07:49:23 From  Thinh NGUYENPHU  to  Everyone:
    The problem is that current ETSI IFA011 IM model is tightly couple with their own architecture (NFVO and VNFM).
07:49:46 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    Xu, now Andy understood why the separate ASD IM makes sense
07:49:55 From  Zu Qiang (Ericsson)  to  Everyone:
    Xu said: "mandatary does not mean you need to support it" why it is mandatary?
07:49:57 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    You are talking about his previous comments
07:50:29 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    ONAP IM mandatory and optional changes do not reflect to ETSI NFV specification automatically
07:50:36 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    Actually ETSI NFV did not approve it
07:50:40 From  Thinh NGUYENPHU  to  Everyone:
    removing mandatory, which mean no VNFM and NFVO. right?
07:51:18 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    As long as ONAP IM refers to IFA011 which links ETSI MANO, it won’t work for ASD
07:51:53 From  philiprobb  to  Everyone:
    From what I’m hearing the underlying architectural drivers between the existing ESTI based IM/DM and the ASD IM/DM are significantly different… one tied to ETSI and one driven by contemporary container/CNF tooling.  Given the different architectural drivers, it warrants different IM/DM Modeling implementations
07:53:16 From  Fred Oliveira  to  Everyone:
    @Phil. I actually think there are very few architectural differences.
07:54:14 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    @fred, I disagree, considering impacts on SOL003, SOL005, VNFM and NFVO. We are bypassing those ETSI MANO components
07:54:40 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    IFA011 refers ETSI MANO (e.g., VNFM)
07:55:00 From  Fred Oliveira  to  Everyone:
    @Byung Those are implementation aspects not conceptual/architectural.
07:55:19 From  Byung-Woo Jun (Ericsson)  to  Everyone:
    It is architectural
07:55:57 From  Xu YANG  to  Everyone:
    @Zu, the "mandatory" means the orchestrator needs to support processing of such information, not means the onboarding NFs need to support or use them.
07:56:03 From  Fred Oliveira  to  Everyone:
    Seems to me that the VNFM functionality has just been incorporated into the NFVO.
07:57:21 From  Zu Qiang (Ericsson)  to  Everyone:
    @xu your statement is misleading
07:57:41 From  Eric Debeau  to  Everyone:
    Sorry, I have to drop. 
07:57:57 From  Thinh NGUYENPHU  to  Everyone:
    rh
07:57:59 From  Xu YANG  to  Everyone:
    I think weeks ago, people are arguing we should not wait for SDOs, and not bind to certain standards, and now we are arguing that we need to wait for ETSI's decision...
07:58:59 From  Xu YANG  to  Everyone:
    @Zu, that's the intention of the mandatory property, and what you want to refer to is the Cardinality 
08:00:38 From  philiprobb  to  Everyone:
    @Fred, I think that the VNFM/NFVO difference is one instance, but aligning more closely with the tools/features available from the K8s/container ecosystem allows for different evolution paths *into the future* between the two architectural underpinnings.
08:01:37 From  Bruno Sakoto  to  Everyone:
    I have to drop for another call
08:01:45 From  Kenny PAUL (LFN)  to  Everyone:
    https://wiki.lfnetworking.org/x/hJEZB
08:02:45 From  Fred Oliveira  to  Everyone:
    @Phil The ETSI approach uses the same “native” tooling, including Helm Charts for K8S support.

...