This meeting was chaired by Steve Terrill

Two topics were originally schedulled.  External controllers and the R2 architecture.  
The R2 Architecture presentation was not ready to be presented so a delay is requested.
This opened up time for an addition topic which was about the microservice architecture in support of 3SP.


External Controller (Ramesha Nagarajan)   
-------------------
Presentation Link: https://wiki.onap.org/download/attachments/16001886/ONAP%20External%20Controller%20Integration%20v0.5.pptx?api=v2 

This topic started in the Use Case sub-committe as connecting to external controllers for SD-WAN; however given that ONAP should be a generic platform
the UC committee went in the direction of making it more general.

Some notes from the discussion
- There are many use cases requiring ONAP to connect to external Systems.
- It was felt that the scenarios need to be clarified first.
- It was said that a debrief of the use case would be benificial (recognising that the architecture sub-committee has been working on that,
  however it was considered useful to articulate what they were.
- When connecting to an external system, the discussion evolved that that system can provide a service to ONAP and the proposed
  requirement try to capture that handling.
- The implementation options were proposed.
  1.  Master - Slave. External domain is a slave orchestration system
  	- introduce a Externa Controller Adapter
	- The slave system provides a service to the overall domain
	- It was commented that the internal domain and the B2B can be different.
  2. Subtending SDN Controller (option 2)  [Already in Amsterdamn release]
  3. Set of VNFs (option 3).

  It was noted as an observation that option 2 is already in the amsterdam release. It was also noted that really only option 1 was explored.
- It was commented as an observation that when considering the distintion between the orchestration layer and the controller layer, 
   the nature of a controller changes when it is controlling other controllers.  It no longer manages the state of the underlying resources
- A question was raised about where we should discuss the UCs for multiple levels or orchestration -> USe case sub-committee 
  (however it was different architectural implecation discussions, that is architecture).

Next Steps
- Remash will host adhoc meetings to increase the alignment before comming back to the architecture committee.
	- including summary of the use cases
	- including articularing the scenario(s).
        - discussion on the requirements
- The conclusions to be presented on the architecture sub-committee (Note: sending out first would increase the alignment).
- There was a request for Dan to present https://wiki.onap.org/download/attachments/11928197/ONAP-mc-sdn.pdf?version=1&modificationDate=1506518708000&api=v2 to the archicture sub-committee

----------------
R2 Architecture.
----------------
The presentation was not ready, so this has to be rescheduled

----------------
Microservice improvements - Manoj Nair
----------------
ONAP Micro-service Design Improvements.
- Mainly in S3P context i.e. what is the best way to achieve this.  What is highlighted in the presentation is somethoughts about what the projects can consider, and that this suggests that the projects look at their microservice architecture

Proposals
1. Microservice meta model.  
2. Micro Service Boundaries
3. Support micros service shared concerns with a PaaS layer.

Proposal:
- Setup two child wiki pages
	- Discussion in motion
	- conclusions
or just
 	- microservice Architectural Guidelines.
- Identify area areas to solicite contributions