Skip to end of metadata
Go to start of metadata

Each project should have its own page with all of the associated project pages / attachments under it.

For consistency, use the same <project Name> as recoded in the list of Resources and Repositories

Approved Project Proposal

Release Planning

A Release

B Release

C Release


Place for whatever the team needs

Meeting Minutes

ONAP_DCAE_WeeklyMeeting_062217.docx 

ONAP_DCAE_WeeklyMeeting_062917.docx

2017/07/27  Meeting contents: collectd presentation materials by Maryam Tahham:  Platform Service Assurance for NFV Overview - DCAE.pdf

  • No labels

7 Comments

  1. Lusheng Ji  is there a regular project meeting for this project yet?

    I see release 1 planning done - but I don't know where to get started to get involved with this project... 

  2. Maryam - Thanks for your interest.  We have been having DCAE meeting on thursday (9 AMEST) for last couple weeks; it is on the ONAP calendar; this will be a good forum to discuss. The release plan identifies high level EPIC's/US, pls review and let us know if you would like to contribute for R1.

  3. I am trying to understand the scope of this project. If this is being discussed elsewhere, please point me to that location.  Netflow is one popular mechanism to get to know the traffic characteristics on the network. It is also used by security analytics and network trouble shooting.  I am wondering whether there is any plan to integrate Netflow collector functionality within DCAE framework to work with VNF based netflow exporters.

  4. Srinivasa - Currently DCAE R1 includes VES and SNMP Trap collector only. The VES spec is broad and includes several domains - measurement being one of them. The collection suite ofcourse can be expanded to include additional types for future release.  Is there a specific usecase you are looking to integrate netflow collected stats in ONAP?

    1. Hi Vijay, Just a background - Packet processing related PNFs and VNFs tend to use Netflow mechanisms for many analytics - Including trouble shooting, understandt traffic characteristics, traffic volume on per flow/protocol basis and many more... But, Netflow exporters (which are part of PNF and VNFs) use UDP transport with its own messaging format.

      It appears that VES collector expects its own format in HTTPS JSON transport. There are two ways to go about this.

      1. Every PNF/VNF exports the flow information in VES format instead of current format and UDP transport.
      2. Creation of Netflow collection service under DCAE.

      I am just wondering whether any thought has gone into it as Netflow is very popular in networking industry.

      There are Pros and Cons.

      Netflow: It is UDP and very simple and hence many it is easy to transport even by HW entities such as intelligent NICs. But, it is clear (hence possibly insecure) on the wire and hence IPSEC kind of network encryption is needed in some deployments.

      VES (JSON/HTTPS): It is non-standard and being TCP/SSL/HTTPS/TEXT based, it could be heavy on PNF and VNFs from compute power perspective.

      Thanks
      Srini

  5. Will DCAE R1 release support installation on Openstack environment? Is there any installation documentation for this ?