Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »



2019.02.12

Agenda

  1. Modeling:
    1. New BBS modeling proposal
    2. Feedback from modeling team on PNF attachment point


2019.02.11

Agenda

  1. M2 requirements for BBS, what needs to be done by M2 (Feb 21)? 
    1. Review https://wiki.onap.org/display/DW/BBS+Planning
  2. Modeling:
    1. review attributes table (Model parameter lifecycle): https://wiki.onap.org/display/DW/BBS+Modeling#BBSModeling-ModelParameterLife-cycle
    2. PNF attachment point in AAI for detecting nomadic ONT (l-interface vs string attribute)
  3. Decide on topology discovery. Possible impact on SDN-C 

Discussion

  1. M2 requirements for BBS
    1. Current proposal is to have modeling draft agreed by M2 for releases beyond Dublin
  2. Topology discovery
    1. Not need for discovery and inventory of OLTs and PON UNIs/OLT NNIs in Dublin timeframe. Added value is minimal, maybe only for validating the attachment point info in PNF registration event. Decision is to not implement topology discovery in Dublin
    2. Review of CP and AccessConnectivity modeling is needed, e.g. C/S-VLAN as property of the AccessConnectivity or CP?
  3. Modeling
    1. PNF attachment point to be stored in AAI as a new string attribute of the PNF resource model. 'logical-interface' should not be used to capture the remote port identifier or attachment point.

Action items

  • David Perez Caparros to propose again to the modeling team to add the 'attachmentPoint' field to the current PNF resource model
  • Stavros Kanarakisvictor gao to review current BBS modeling proposal after deciding that topology discovery will not be used in Dublin


2019.02.07

Agenda

  1. M2 requirements for BBS, what needs to be done by M2 (Feb 21)? [not discussed]
    1. Review https://wiki.onap.org/display/DW/BBS+Planning
  2. Modeling: [not discussed]
    1. review attributes table (Model parameter lifecycle): https://wiki.onap.org/display/DW/BBS+Modeling#BBSModeling-ModelParameterLife-cycle
    2. PNF attachment point in AAI for detecting nomadic ONT (l-interface vs string attribute)
  3. “SO microservice” discussion: microservice implementing SO’s service modification workflow as temporary solution for Dublin. The expectation is that we can replace this microservice with SO’s ServiceModify BPMN in R5+
  4. Decide on topology discovery. Possible impact on SDN-C 
  5. Distribute VPN key passwords to access Swisscom Lab

Discussion

  1. Reviewed flow diagrams in order to accommodate the new "SO microservice" concept
  2. VPN key passwords were distributed to contributors that asked for it
  3. External API Adrian OSullivan. Original mail here: 
    1. Service state transitions based on the Casablanca Orchestration State model from the SO team: External API Framework Files
      1. Seshu Kumar MudigantiKeong Lim : Can someone from AAI/SO team correct/update these slides with what we should actually see in Dublin? 
      2. Added Notes on ONAP Service Instance State Model to TMF 638 Mapping
    2. Submitted the code for  EXTAPI-194 - Getting issue details... STATUS . BSS Portal can now query the Service Instance State using just the serviceInstanceID key


2019.01.21

Agenda

  1. Review and finalize BBS model
    1. BBS Modeling
  2. Review PNF reregistration flow proposed by BBS Meeting Minutes during DDF
    1. 5G - PNF Plug and Play#5G-PNFPlugandPlay-PNPREREGISTRATIONUSECASE
  3. SDN-C northbound discussion
  4. Impacts/Project Commitment (updates?)


2019.01.17

Agenda

  1. Review and finalize BBS model
    1. BBS Modeling
  2. Review PNF reregistration flow proposed by Benjamin Cheung during DDF [not covered]
    1. 5G - PNF Plug and Play#5G-PNFPlugandPlay-PNPREREGISTRATIONUSECASE
  3. SDN-C northbound discussion [not covered]
  4. Impacts/Project Commitment (any updates?)

Discussion

  • Impacts/Project Commitment
    • EXTAPI-98 committed by ExtAPI project. Related AAI-1996 epic is not required anymore for BBS
    • Policy: Identified potential requirements for CLAMP in the context of BBS
    • Commitment from Nokia team for DCAE epics (PRH and RG activation items)
  • BBS model
    • Need to clarify topology of CFS HSIA (service instantiated via ExternalAPI) and how per-customer RFS (Access, Internet) and Infrastructure RFS (shared by all customers) map to it. Check VoLTE use case (RFS as VF, substitution mapping)
    • Add Internet Profile to a new RFS, different from Access RFS, as Internet Profile can be linked to both Access and Edge
    • AccessConnection (PON UNI to OLT NNI connection in OLT) modeled as VFC instead of PNF
    • SDN-C topology discovery returns list of PON UNIs and OLT NNIs to be stored it in AAI
    • ONT renamed to CPE. CPE properties updated following industry best practices in this area. 'id' property for future usage
  • Next week, additional 1h BBS meetings (Mo-Tue-Wed) in order to progress towards M1
  • We will submit a proposal for presenting BBS use case at ONS. Target is to showcase a demo also during ONS.

Action items


2019.01.08 - 2019.01.11

ONAP DDF


2019.01.03

Agenda

  1. Preparation for ONAP DDF
  2. BBS modeling
  3. Impacts/Project Commitment (updates?)
  4. Update on Edge SDN M&C + BNG/AAA/DHCP implementation

2018.12.13

Agenda

  1. Discussion on Nomadic ONT flows / 5G PnP
    1. PNF Registration and Re-registration Notification
  2. BBS modeling proposal
    1. BBS Modeling
  3. Impacts/Project Commitment (any update?) [not covered]
  4. Update on Edge SDN M&C + BNG/AAA/DHCP implementation [not covered]
  5. Update on development environment setup

Discussion

  • BBS modeling proposal
    1. Stavros Kanarakis presented the BBS CFS&RFS Modeling proposal together with a high level work flow for HSIA service activation (BBS Modeling, see first comment).
    2. victor gao also added in the comments section a proposal for the BBS modeling to be discussed in the next BBS meeting (and offline)
  • Discussion on Nomadic ONT flows / 5G PnP
    1. How can we support DOA (Dead on Arrival) cases, which are frequent with ONTs, without having to update the correlation ID? 
      1. One option is to use an alias that maps to ONT vendor + s/n. If ONT s/n changes (replacement ONT sent to the customer), we only need to change the mapping. Disadvantage is that the operator needs to configure such alias in the ONT before sending to the customer.
      2. Current practice (defined by BBF) is to use vendor+s/n to uniquely identify the ONT device
      3. As the correlation ID (pnfName field) is customizable, the decision is to continue with ONT vendor + s/n as correlation ID, meaning pnfName=ONT vendor + s/n in AAI and sourceName=ONT vendor + s/n in VES registration message.
      4. ONT vendor + s/n is communicated to ONAP as part of the service order request coming from BSS to the External API 
        1. In case of ONT DOA, we could use service 'modify' action in ExtAPI to change ONT s/n or delete and issue a new service order request
    2. Current 5G PnP implements a 2 weeks timeout for SO while waiting for the PNF READY event (PNF registration).
      1. In principle, 2 weeks is also fine for ONT registration, but we should check whether this period can be configured and how
    3. Current 5G PnP associates a PNF AAI entry to a service instance only after the PNF READY (after PNF registration) event is consumed by SO
      1. In Dublin, working towards enabling the association of the PNF entry to a service instance ID before the PNF is registered  SO-1274 - Getting issue details... STATUS
    4. How to detect ONT re-registration case (nomadic ONT)?
      1. Option 1: check whether ONT's PON UNI info contained in the VES registration message changes with respect to the one previously stored in AAI
      2. Option 2: check whether ONT is already associated to a service instance and that service instance is in 'active' state. Note: Service instance becomes active only after PNF is registered and SO finishes with the service instantiation flow, so for PNF re-registration the service should be already active 
    5. For further study: What about faulty ONTs continuously sending VES registration events?
      1. This should be detected by Access SDN M&C and send to ONAP an alarm to trigger an ONT reset
  • Update on development environment setup
    1. Private repo for BBS in gitlab, as ONAP does not provide repo for use cases for development. Of course, working code will be upstreamed to respective ONAP projects.
  • Next meeting on Jan 3rd, 2019

Action items

2018.12.06

Agenda

  1. Report on use case subcommittee meeting (Dec 5)
  2. Impacts/Project Commitment
  3. BBS CFS modeling discussion
  4. Update on Edge SDN M&C + BNG/AAA/DHCP implementation [not covered]
  5. Update on development environment setup [not covered]


Discussion

  • Report on use case subcommittee meeting (Dec 5)
    1. BBS wiki page adapted to follow the template recommended by the use case subcommittee. Wiki page split into sub-pages to improve readability
    2. 5-10 minute slot for BBS during next week's VF2F to present use case status and Project Commitment table
  • Impacts/Project Commitment
    1. BBS priority for Dublin is to implement phase 1 and 2 (CFS creation and activation and nomadic ONT)
    2. BBS team will try to reuse existing ONAP functionalities as much as possible and minimize requirements for other projects
    3. Potential requirement for External API to support service state change notification towards BSS (TMF 638), e.g. when ONT moves, to be discussed with External API PTL
    4. Potential requirement for AAI to notify listeners when AAI entry changes: AAI-BBS Proposals for Dublin Release
    5. Potential requirement for DCAE to be discussed with DCAE PTL:
      1. Enhancements for RESTCONF collector & VES mapper
      2. Enhance current PRH to detect ONT move or BBS team to develop a new microservice for this
  • BBS CFS modeling discussion
    1. ONT PNF model uses ONT serial number as unique ID
    2. ONT is associated to a PON UNI during discovery process
    3. New BBS modeling proposal for discussion to be added in BBS wiki
  • Nomadic ONT flow discussion
    • Assumption is that we may have different Access SDN M&C instances. ONT may move to an OLT managed by a second Access SDN M&C, so ONT move detection should be done in ONAP. Access SDN M&C sends ONT registration event to ONAP when new ONT is detected by an OLT.
    • ONT registration event contains ONT serial number + OLT UNI info
      • ONT serial number is used by PRH (or BBS custom microservice) to detect whether ONT is already registered and associated to an existing CFS service instance
      • OLT UNI info is used by PRH (or BBS custom microservice) to detect whether ONT changed location

Action items

  • No labels