Meetings are held by WebEx every other Wednesday at 5:00 AM PT, 7:00 AM CT, 8:00 AM ET, 2:00 PM CET

Please contact Denise Provencher for the recurring meeting invitation.

Meeting recordings and (some) notes are below.

04 Nov 2020

ONAP L1 Carrier Interconnect (MDONS) Demo of Transport PCE Integration with ONAP
Wednesday, November 4, 2020
6:59 am \| Central Standard Time (Chicago, GMT-06:00) \| 1 hr 6 min
Recording
Topic	Link	Password
ONAP L1 Carrier Interconnect (MDONS)-20201104 1306-1	View	xJK9Rp8n
Nicolas Pelloquin shared a demo of the work that Orange and AT&T have done to integrate Transport PCE with ONAP in support of the MDONS use case. T-PCE is used as an external domain controller, and the implementation automates service creation at both the WDM and OTN layers (previous MDONS work automated only the OTN layer).

30 Sep 2020

ONAP L1 Carrier Interconnect (MDONS)
Wednesday, September 30, 2020
6:58 am \| Central Daylight Time (Chicago, GMT-05:00) \| 33 min
Recording
Topic	Link	Password
ONAP L1 Carrier Interconnect (MDONS)-20200930 1204-1	View	XheJeVc6
Notes:

02 Sep 2020

ONAP L1 Carrier Interconnect (MDONS)-20200902 1205-1

Wednesday, September 2, 2020 | 7:05 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 36 min 28 sec

Recording password: PpxpV7M9

Play recording

Notes:

05 Aug 2020

ONAP L1 Carrier Interconnect (MDONS)-20200805 1205-1

Wednesday, August 5, 2020 | 7:05 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 43 min 21 sec

Recording password: vCGc2bcW

Play recording

Notes:

22 Jul 2020

ONAP L1 Carrier Interconnect (MDONS)-20200722 1205-1

Wednesday, July 22, 2020 | 7:05 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 55 min 23 sec

Recording password: mHQ4B82P

Play recording

Notes:

08 Jul 2020

No recording

Notes:

24 Jun 2020

ONAP L1 Carrier Interconnect (MDONS)-20200624 1205-1

Wednesday, June 24, 2020 | 7:05 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 51 min 20 sec

Recording password: cDXVpFX4

Play recording

Notes:

Olivier A shared two approaches for inter-domain link failure detection and subsequent recovery action:
1. Scenario 1: Wait for events from both ends of the failed link before declaring the link down.
2. Scenario 2: Act on a single event to declare the link down.
3. Slides may be found here.
Xin Miao (Unlicensed) indicated that we are currently assuming a flow more like scenario 1 to avoid double triggering the policy. He described the flow:
1. Receive alarm
2. DCAE updates A&AI
3. A&AI posts event on DMaaP
4. Microservice will listen for event and trigger action
Yici asked what failure types we plan to cover. Is it hard failures, such as LOS, or also PM indications such as BER, signal degrade? After some discussion we considered including two hard failures: a fiber cut and an equipment failure (e.g. transmitter failure)

17 Jun 2020

ONAP L1 Carrier Interconnect (MDONS)-20200617 1204-1

Wednesday, June 17, 2020 | 7:04 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 43 min 31 sec

Recording password: Dup5JqJM

Play recording

Notes:

Frankfurt was released on June 11th
The MDONS extension for Guilin was presented to the Architecture Subcommittee. The Subcommittee warned that the CLAMP component is dates and may not work. Slides may be found here.
Olivier A explained a similar closed loop analysis that was done by Orange. He suggested a simplification to let SDN-C trigger a closed-loop workflow based on a specific alarm/event. Orange is using this method for device discovery and configuration (ZTP).
The Guilin M1 (requirements complete) date has been pushed to July.
Raghavan Subramanian mentioned that the Linux Foundation Virtual DDF will be held the week of June 22nd.

03 Jun 2020

ONAP L1 Carrier Interconnect (MDONS)-20200603 1207-1

Wednesday, June 3, 2020 | 7:07 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 51 min 53 sec

Recording password: eTfFGbw8

Play recording

Notes:

Raghavan Subramanian shared information about the TIP CANDI project. The next POC includes a multi-domain alien wavelength service. Orange may have a person involved in CANDO and will check with his colleagues.
Xin Miao (Unlicensed) reviewed the MDONS closed loop scenario.
The Guilin Architecture Subcommittee review meeting is next week. MDONS may be on the agenda.
Frankfurt is expected to be released June 4th.

27 May 2020

ONAP L1 Carrier Interconnect-20200527 1203-1

Wednesday, May 27, 2020 | 7:03 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 1 hr 8 min 41 sec

Recording password: sNJNHMc3

Play recording

Notes:

Xin Miao (Unlicensed) shared an update on the Frankfurt status. RC0 and RC1 are complete for MDONS, so we are essentially done. RC2 is a final E2E verification of all bug fixes.
Xin Miao (Unlicensed) shared an update on the MDONS extensions for the Guilin releaese.
1. OOF enhancements for inter-domain optimization are in verification
2. handling of asynchronous responses from the controller is in verification
Xin Miao (Unlicensed) provided an overview of the scenario proposed for assurance/closed loop: the failure of an inter-domain link is detected, affected services are identified and then restored by using an alternate IDL. Xin asked for feedback from the carriers as to whether this scenario is useful. The planned implementation is patterned after CCVPN. Xin's slides may be found here.
1. Dave A suggested another possible scenario: a restoration event within a domain (executed by a domain controller) that changes the latency of affected services.
2. Dave M mentioned that MEF 63 covers latency scenarios in the appendix. Another possibility is that we have 1+1 port protection at the NNI, so the protection switch is transparent to ONAP. We might need to indicate that the IDL is in an unprotected state.

06 May 2020

ONAP L1 Carrier Interconnect-20200506 1214-1

Wednesday, May 6, 2020 | 7:14 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 41 min 52 sec

Recording password: TfmKk5um

Play recording

Notes:

Henry Yu reviewed the Transport Slicing project as well as the scope planned for the Guilin release. A key requirement for the Transport NSSMF is that it be consumer agnostic. Transport Slicing will include fronthaul, midhaul, and backhaul networks. TS is not planning to address the core → application portion of the network (no requirements from the community at this time). All are invited to participate; Huawei expects to do most of the implementation but welcomes input on the design discussions. Slides can be found here. Please contact Henry Yu (henry.yu1@huawei.com) for additional information.

29 Apr 2020

ONAP L1 Carrier Interconnect-20200429 1203-1

Wednesday, April 29, 2020 | 7:03 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 42 min 47 sec

Recording password: ZdCWEv76

Play recording

Notes:

The team reviewed candidate features for the Guilin release and agreed on overall priorities and owners. Updated slides can be found here.
The team will have some working sessions on EXT-API to refresh ideas on workflow and requirements.
Olivier mentioned that TransportPCE is able to export an abstract topology. They are working on mapping the data into A&AI.
There is some community discussion about whether we should add capabilities to the SO and CDS components rather than add complexity in DGs.
Next meeting Henry Yu will share an update on the Transport Slicing project.

22 Apr 2020

ONAP L1 Carrier Interconnect-20200422 1208-1

Wednesday, April 22, 2020 | 7:08 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 44 min 39 sec

Recording password: bHHKxww8

Play recording

Notes:

Xin Miao (Unlicensed) reviewed the status of the Frankfurt release. He mentioned that the team has created a controller simulator to be used for automated integration testing. The Frankfurt release date is May 28.
Raghavan Subramanian presented Fujitsu's suggestions for Guilin work items. Olivier A suggested assigning priorities 1-4 and indicated interest in completing the inter-carrier work. Dave Martin noted that the Legato and Interlude interfaces may be a bit immature for implementation.
Henry Yu asked if Transport Slicing is under consideration for Guilin. Fujitsu is interested in the Transport Slicing project but focused only on the MDONS use case for this meeting. Henry agreed to present the Transport Slicing project at an upcoming meeting since others in the MDONS group may be interested.
Dave M reminded everyone that the MEF 2Q meeting will be held virtually all next week and includes the network slicing letter ballot. More information here.
Slides from today will be distributed and placed on the MDONS Wiki. Everyone should review the suggested Guilin features for further discussion next week.

08 Apr 2020

ONAP L1 Carrier Interconnect-20200408 1203-1

Full demo of MDONS Frankfurt contribution

Wednesday, April 8, 2020 | 7:03 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 56 min 48 sec

Recording password: NxqeNB2r

Play recording

Notes: MDONS demo conducted by THIRILOSHINI KRISHNAKUMAR and Xin Miao (Unlicensed) of Fujitsu

18 Mar 2020

ONAP L1 Carrier Interconnect-20200318 1209-1

Wednesday, March 18, 2020 | 7:09 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 36 min 56 sec

Recording password: bP6FHM9Z

Play recording

Notes:

11 Mar 2020

ONAP L1 Carrier Interconnect-20200311 1203-1

Wednesday, March 11, 2020 | 7:03 am | Central Daylight Time (Chicago, GMT-05:00)

Duration: 27 min 22 sec

Recording password: 7PxPybkh

Play recording

Notes:

26 Feb 2020

ONAP L1 Carrier Interconnect-20200226 1305-1

Wednesday, February 26, 2020 | 7:05 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 34 min 30 sec

Recording password: eKZdxMR3

Play recording

Notes:

Former user (Deleted) reviewed a summary of the team's accomplishments (slides). Suggestions for additions to the slides were:
1. Add a slide for next steps
2. Add a slide to show the specific contributions to each ONAP component (code, template, DG...)
In order to complete (a) above, we need to agree on next steps. Raghavan Subramanianhas captured potential next steps on the wiki (here). Team members are encouraged to review and comment/contribute as well as to vote. You will need to login to Confluence in order to vote. If you do not have a login, you may send email to Raghavan Subramanian with your input. We will plan to discuss next week.

05 Feb 2020

ONAP L1 Carrier Interconnect-20200205 1302-1

Wednesday, February 5, 2020 | 7:02 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 15 min 20 sec

Recording password: mQxy3V9W

Play recording

Notes:

Xin Miao (Unlicensed) reviewed the MDONS integration test cases found here. We welcome comments on the test cases; please comment directly on the page.
Brief discussion of test configuration options (use public ONAP instance, host local ONAP instance).
The M4 milestone (start of integration test) is March 5.

29 Jan 2020

ONAP L1 Carrier Interconnect-20200129 1326-1

Wednesday, January 29, 2020 | 7:26 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 41 min 44 sec

Recording password: mVWbcgQ2

Play recording

Notes:

Xin Miao (Unlicensed) shared a recorded demo of the OTN service create/delete operations using the Open ROADM service model APIs from SDN-C to the domain controller. During the demo, the asynchronous operation complete notification from the controller was simulated due to some complexities in the existing controller workflow. CCVPN requires a similar notification mechanism but uses a push mechanism rather than a called API. This portion of the WebEx session was not recorded, but a recording of the demo is included here: Create-Delete-Demo.mp4.
Henry Yu shared updates to his presentation on ENNI modeling, comparing the MEF and IETF/ACTN models with the goal of having a unified model in A&AI. IETF/ACTN uses a multi-domain super controller (MDSC) to orchestrate among domains within an operator. TE links between domains contain an inter-domain-plug-id to match compatible interfaces between domains. Olivier A and Dave A commented that we don't need to include everything from all possible models in A&AI, rather, we need one model that can be mediated to support various controller models.
1. Action: Henry asked that the team review his slides and let him know if anything is missing. Also, if anyone would like to be added to the email thread on this topic, please let Henry Yu or Dave Allabaugh know.

22 Jan 2020

ONAP L1 Carrier Interconnect-20200122 1306-1

Wednesday, January 22, 2020 | 7:06 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 49 min 35 sec

Recording password: 8rUvYR8J

Play recording

Notes:

Frankfurt M2/M3 milestone completed - API documentation and functionality freeze. Next milestone is M4 on Mar 5 (coding complete). Thanks to Xin Miao (Unlicensed) and team!
Readout of Linux Foundation Developer & Testing Forum in Prague last week. Henry Yu presented a proposal for a new CCVPN project on transport slicing. All slides from the Prague meetings can be found on the LF Wiki. (CCVPN proposal is on Tuesday at 9:45 AM)
Discussion on shift from ONAP use case focus to requirements focus. More attention to ONAP as a platform for Service Provider use case implementations.
Reviewed potential MDONS enhancements for the Guilin release. Raghavan Subramanianwill create a wiki page for review/comment/voting.
Dave M reminded everyone that the MEF operator services specification is out for letter ballot; final voting needed by Friday Jan 24.
Andrea M plans to propose a new MEF project on operator L1 service constructs for Presto. Will be proposed at the Saigon meeting the week of Feb 10.
Next meeting we will get back to reviewing Henry Yu's ENNI modeling analysis.

08 Jan 2020

ONAP L1 Carrier Interconnect-20200108 1307-1

Wednesday, January 8, 2020 | 7:07 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 21 min 18 sec

Recording password: xGg88sgm

Play recording

18 Dec 2019

ONAP L1 Carrier Interconnect-20191218 1305-1

Wednesday, December 18, 2019 | 7:05 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 1 hr 5 min 28 sec

Recording password: Kva5pnyJ

Play recording

11 Dec 2019

ONAP L1 Carrier Interconnect-20191211 1311-1

Wednesday, December 11, 2019 | 7:11 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 46 min 50 sec

Recording password: Xfpe7gc3

Play recording

20 Nov 2019

ONAP L1 Carrier Interconnect-20191120 1331-1

Wednesday, November 20, 2019 | 7:31 am | Central Standard Time (Chicago, GMT-06:00)

Duration: 26 min 1 sec

Recording password: tMMb52Ms

Play recording

28 Aug 2019

21 Aug 2019

14 Aug 2019

No meeting.

07 Aug 2019

No meeting.

31 Jul 2019

24 Jul 2019

Attendees:

AT&T: Martin Birk, FREEMAN, BRIAN D

Orange: Olivier Augizeau

Fujitsu: Raghavan Subramanian, David Allabaugh, Xin Miao (Unlicensed)

Notes:

Continued discussion of how best to align with the CCVPN project. Brian agreed to reply to Lin's email and suggest that L1 operate as an autonomous use case that can also be used by CCVPN due to the need to support standalone L1 interconnect services.
Olivier A shared slides describing Orange's proposal for ONAP contributions as part of this use case. Aside from enhancements to TransportPCE to support this use case, Orange expects to update SDN-C, SO, and A&AI (e.g. create DG, WF, models) to support our initial implementation.
1. Brian suggested that Fujitsu create a similar slide explaining our proposed contributions.

17 Jul 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Olivier Renais, Olivier Augizeau

Altran - AMMAR ALBETAR

Fujitsu - David Allabaugh Raghavan Subramanian , Former user (Deleted)

Notes:

Team discussed the invitation from CCVPN to join their project rather than creating a new project. Agreement that there advantages and disadvantages to joining CCVPN. We agreed to talk informally with others who are familiar with or participating in CCVPN. Will continue discussion next week.
Olivier A provided an update on Orange's analysis of work required. They would like to be ready to get started in September. Olivier clarified that they plan to run a separate instance of ODL initially and operate as an external controller. Orange plans to use Open ROADM 2.2.1; will check on T-API version.
1. Have identified some extensions to the Open ROADM service model
2. Need to develop an OTN simulator
3. Integrate TransportPCE ODL enhancement
4. SO workflows
5. SDN-C DG

10 Jul 2019

No meeting

03 Jul 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Olivier Renais

Altran - AMMAR ALBETAR

Fujitsu - Raghavan Subramanian , THIRILOSHINI KRISHNAKUMAR, Former user (Deleted)

Notes:

FREEMAN, BRIAN D shared results of the 2 July 2019 EUAG meeting. General agreement that the functionality we are proposing is useful. There is some concern about LFN API specifications diverging from SDOs. We need to ensure that our modeling is consistent with MEF & TMF. Brian also suggested that we get a zoom bridge and post on our wiki so others can join more easily. EUAG meeting minutes can be found here.
Thiriloshini presented the work that Fujitsu has done in the Dublin release. She and her team have on boarded an optical domain controller and created DGs in SDN-C to retrieve topology inventory for A&AI. This code will be contributed when the optical service creation use case is complete.

Some discussion about the level of abstraction required in A&AI. Consensus that inventory details should be kept in the controller. Olivier suggested that PNFs may simply be modeled as end points.
Thiriloshini's slides and a video of the demo have been posted on the Dublin demo page.

The team discussed the scope of our first implementation phase. We agreed to begin with optical service creation within a singe carrier and single optical domain. This is the smallest service creation building block required for inter-carrier connections.

Suggestion to include simulators with our solution so that others can easily try it out and/or test modifications.
Martin and FREEMAN, BRIAN D will discuss the possibility of contributing the SDN-C Open ROADM adapter.

Schedule

We should plan to have a PoC as part of the Frankfurt release. Our development should be non-blocking - no disruption to other teams.
We will need to propose any changes required to other components.
Need to have representation at the Monday Use Case Subcommittee meetings, and the Thursday TSC meetings. Currently Raghavan Subramanian is attending.

26 Jun 2019

No meeting

19 Jun 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Olivier Augizeau, Olivier Renais

Altran - AMMAR ALBETAR

Fujitsu - David Allabaugh, Raghavan Subramanian, THIRILOSHINI KRISHNAKUMAR, Joe Peters, Former user (Deleted)

Notes:

EUAG meeting - presentation was deferred due to lack of carrier participation in the meeting; rescheduled for July 2nd (FREEMAN, BRIAN D will present since Olivier Augizeau will be on vacation)
Continued reviewing Dave's optical modeling slides
1. MEF has created a TOSCA model for L2 service (55.0.2); can be applied to L1 services based on MEF63
2. Brian suggested adding a slide to show a layer 2 service on top of the optical service; Dave commented that the adaptation from L2 to L1 is currently missing from MEF
3. MEF has resource models based on T-API
4. Brian suggested identifying key fields in the L2 service definition that L0/1 controllers may need to be aware of (e.g. high packet loss triggersre-route or addition of L0 bandwith)
Team agreed that MEF approach seems reasonable
1. Need to begin looking at Legato for L1 - service attributes, resource model
2. SPOC operator will need a view of the entire service, perhaps as an abstracted list of containers
  1. Dave will contact the MEF team informally for more information
3. Olivier A commented that the service order definition is most urgent; service OAM can be handled later
Raghavan submitted an abstract for ONS Europe based on our project; if selected, Olivier A will participate in presentation
Next meeting
1. discuss scope of first release (first baby step)

12 Jun 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Olivier Augizeau, Olivier Renais

Altran - AMMAR ALBETAR

Fujitsu - David Allabaugh, Raghavan Subramanian, THIRILOSHINI KRISHNAKUMAR, Joe Peters, Former user (Deleted)

Notes:

The team reviewed Olivier A's update of the EUAG material. Agreed to change our proposal to be a stand-alone use case that is linked to and can be leveraged by CCVPN. Orange will be using the Open ROADM service model but will expose the more abstract T-API network model for A&AI. Other minor edits agreed to for consistency. Olivier re-issued the proposal after the meeting.
Raghavan asked if any team members are planning to attend ONS Europe in September. If so, would anyone like to join him in presenting our ONAP work? Orange expressed interest. Raghavan will draft an abstract for review (network automation track).
Dave shared his slides on MEF APIs and how they might be applied to our project. Slides may be found here.
1. T-API is the foundation model for MEF APIs
2. MEF 63 includes L1 subscriber services; to day the L1 ENNI is always OTN, mapped or muxed
Next meeting
1. feedback from EUAG presentation
2. Continue review of MEF slides

05 Jun 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Eric Debeau , Olivier Augizeau , Olivier Renais

Fujitsu - Dwayne Reeves, Former user (Deleted) David Allabaugh , Raghavan Subramanian

Notes:

Oliver R recapped the Orange proposal that he shared last week:
1. “Option 2” with macro routing at the BSS layer
2. Use of CDS may not makes sense for TransportPCE
3. Use of T-API connector northbound of controller
Oliver R reviewed the Orange Service Instantiation slide
1. Suggest not using OOF in the initial phase (reduce complexity)
2. Dave pointed out that we may lose the ability to optimize across SP domains by requiring the BSS to provide interconnect points; inter-SP optimization assumed to be an aspirational goal, not in first phase
3. SO polls for service status update – discussion about how long to wait and whether we should use DMaaP to send a notification.
4. OPEN ITEM – determine best way to handle notifications (1) from domain controller to SDN-C, and (2) from domain controller to SO
5. We may want to simplify the OTN requirement, e.g. use a muxponder rather than an OTN switch/switchponder
Oliver A compared proposed Option 2 to the MEF model
1. Reference: MEF 3.0, LSO reference architecture
2. Customer Single Point of Contact (SPOC) is at the BSS level in the MEF model
3. Service decomposition is done by the MEF Business Applications (BSS). A service between Paris and Dallas will be decomposed into requests (via Legato) for connections Paris <> NYC and NYC <> Dallas. Orchestrator is not aware of E2E service?
4. Interlude may be used between ONAP instances to make service modifications that do not affect billing
  1. Could be used to negotiate interconnect details such as trib assignments; perhaps could be used for optimization in the future
5. Demo suggestion: MEF BA becomes a python script that calls the Legato API; use Interlude between ONAP instances for meet me point details
Action items
1. Review EUAG slides that Denise distributed
2. Gather more detail on Legato and Interlude
Next meeting June 12^th to review EUAG slides (some folks will be at ONAP F2F)

29 May 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Eric Debeau , Olivier Augizeau , Olivier Renais

Fujitsu - ravi.rao , Former user (Deleted) David Allabaugh , Raghavan Subramanian

Notes:

Briefly discussed new EUAG template for proposals. We may be the first to use it; OK to add supplementary information. Denise to draft first version of project slide for the team to review.
Olivier R reviewed Orange's view of the use case from a TransportPCE perspective. Slides have been distributed to the team.
1. "Macro routing" is typically handled at the BSS level and requires access to global topology. Proposal is to have macro routing done at the BSS level and assume that service provider interconnect points are passed from the BSS to ONAP (slide 2, option 2).
2. BSS could query ONAP for topology - check to see if already supported by Legato. Ludovic Robertmay know
3. We should see if we can resuce anything from the MEF 2017 demo
4. Not convinced that CDS is required for TransportPCE - complexity not worth the benefit
5. T-API view of topology (abstracted) sufficient for A&AI. No need to expose Open ROADM network model
6. Discussion of notification mechanisms: controller publishes event to DMaap? use CDS hooks for notifications? REST?
Next meeting - continue to review Orange proposal; discuss best mechanism for notifications

22 May 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Oliver Renais

Fujitsu - David Allabaugh, ravi.rao, Raghavan Subramanian, Former user (Deleted), Dwayne Reeves, Joe Peters

Notes:

Discussed feedback from use case subcommittee that L1 interconnects should be a sub-use case of CCVPN, citing 5G as an example. Team agreed that L1 should be a stand-alone use case and should be suitable as an underlay for other services. The existing CCVPN model does nor fully represent an L0/L1 service interconnect. Brian will discuss with Alla.
Need a small number of slides for EUAG: what is the problem, what is the proposed solution, what are the use cases. Olivier A will present. Denise will send a few applicable slides to be used as raw material (subsequently, Olivier A shared a new template for EUAG proposals).
Briefly discussed timeline for Frankfurt and work that we can begin now. Ravi mentioned a new process for developing blueprints. We should start this sooner rather than later. Olivier R mentioned that Orange is not convinced that CDS is required in the solution. Orange will share their thinking on the next call. Fujitsu will share the results of their whiteboard session.
Development environment discussion. Fujitsu will develop a proposal for a lab configuration.
1. Need equipment emulators in order to test higher level functions and APIS
2. May need enhancements to TransportPCE and ODL to support OTN. Guillame is the PTL for TransportPCE.
3. Brian suggested that we can use the ONAP instance in AT&T's lab

16 May 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Oliver Renais

Fujitsu - David Allabaugh, ravi.rao, Raghavan Subramanian, Former user (Deleted), Deepak Patel

Notes:

Olivier R raised a question about whether or not we have the capability to show a 100G/OTU4 ENNI in the lab. If not, we will use a 10G/OTU2 ENNI and a 1GE service (similar to MEF demo). It was also noted that we can use simulators for most of the development.
The team reviewed the draft business requirements draft and agreed upon some edits. The updated slides have been posted to the wiki; changes are in red. Ravi will bring them to the use case subcommittee.
Brian pointed out that we also need to identify the impact to other components & understand where we need help.
Briefly discussed the June EUAG. We have some time to prepare material. Agreement that we want the L0/L1 use case to stand alone (services offered at those layers) but also support other use cases/services - CCVPN, 5G network slicing...
Team reviewed latest use case slides from Ravi. He has discussed this material with the CDS team. They are working on an alternative to the DG plug-in.
- slide 3 - do we need DMaaP to get topology notifications? Perhaps a DMaaP > REST notification to ensure reliable delivery.
- slide 7 - break into 3 slides: design time; partner on-boarding; and run time (customer order)
- simplest case is to have one controller domain in each service provider; we might want to start with that.

09 May 2019

Attendees:

AT&T - FREEMAN, BRIAN D

Orange - Olivier Augizeau, Ludovic Robert, Matthieu Geerebaert, Oliver Renais

Fujitsu - David Allabaugh, ravi.rao, Raghavan Subramanian, Former user (Deleted), Deepak Patel

Notes:

Agenda
Olivier A reviewed requirements for interconnect services based on discussion with the marketing and inter-carrier groups at Orange
1. Reviewed three cases for cross-domain connections: (1) domain = vendor, and interconnection is required between vendor domains within a carrier; (2) domain = network managed by an operational unit with its own ONAP instance; and (3) domain = telco.
2. Discussed whether #2 and #3 are effectively the same use case. For Orange, they are the same.
3. Subsea cables are often managed by consortiums and access typically requires lengthy negotiation.
4. Requirements include the need to monitor that the original service constraints are still being met (for instance, latency or sovereignty after a failure that causes a re-route)
5. Need to link L0/L1 to the IP layer. Need a strategy for managing across layers, especially in failure cases. Can you dynamically create new L0 links (e.g. between routers) when there is an IP backbone failure, using an automated patch panel?
6. General agreement that this is a complex problem and that we need to identify a small but valuable first step.
Dave shared his understanding of MEF Interlude support for service provider interconnect. Interlude seems to assume that the BSS layer is handling selection of the interconnect point.
Discussion of scope for this project:
1. Part of what we need to do is model L0/L1 services in ONAP
2. MEF interconnect model could be used as the basis of our work
3. Consider swim lanes of effort:
  1. Modelling
  2. KPIs – what is needed, how should they be collected?
  3. Controller(s) for L0/L1 – functions required, APIs, where in the architecture?
Next meeting – 16 May 2019 , same time as May 9 meeting
Action – all to review the business requirements slides for presentation to the use case subcommittee; be prepared to review on the 16th

24 Apr 2019

Attendees:

AT&T - Martin Birk, Brian Freeman

Orange - Eric Debeau Olivier Augizeau , Olivier Renais

Fujitsu - ravi.rao Former user (Deleted) David Allabaugh Raghavan Subramanian , Dwayne Reeves, Deepak Patel

Notes:

Raghavan shared the child page he created for project artifacts. He will add a child page for meeting notes (this page) and list the names of project members.
Ravi shared his updated slides. There is general agreement to split the workflow into phases and separate onboarding from service design and instantiation.
1. Onboarding
  1. “Onboarding” terminology slightly confusing when applied to topology discovery; you are actually onboarding the assets of the controllers.
  2. Agreement to split onboarding step into (1) controller onboarding (configure IP address, API to use, etc.), and (2) asset/topology discovery (infrastructure prep for service order)
  3. At design-time, artifacts required to define an external controller to discover pertinent parts of the domains (end-points, network models etc.)
  4. Current flows not very aligned with what ONAP uses (Orange concern about using CDS everywhere)
  5. Can we leverage anything from CCVPN discovery? CCVPN currently does not support discovery of a domain controller, but may have a useful model.
  6. SDN domain controllers support tens of thousands of assets so should we be treating/modelling it as a PNF? Does model break down sue to assumptions about scale of individual PNFs?
  7. We might want to set up infrastructure manually in the first release
2. Service Design and Instantiation
  1. Service definition of optical using the same definition that ONAP information model
  2. The model defined at design-time is distributed by SDC via DMAP to SO, SDN-C, A&AI, Policy, CLAMP etc., each of which store locally for use in run-time
  3. How is the service request decomposed? Who decides little “a” and little “z” (the ENNI)? OOF?
  4. Should we use SNIRO emulator (running in Docker containers) for managing homing/allocation in service instantiation flows (OOF reference)?
  5. Will there be a serviceability check in an upper layer system, so that we know that big “Z” is outside of SP1’s domain?
  6. Inter-domain path computation SW piece is missing (which inter-connects area available & will we used)
  7. How will the service request from BSS systems look?
    1. will it be the decomposed service request b/w end-points within the one ONAP SP instance (A > a and z > Z for example) [Likely option]
    2. or will BSS send E2E service request & SO will identify & decompose end-points across SP partner domains
  8. We need to incorporate E2E business constraints into the service definitions - global availability, latency, geographical constraints, automatic restoration
  9. Scope of use-case is very simple right now, but more complex scenarios as probable. We can likely start off small.
  10. Need to check Interlude work – they may have addressed this
Preparation for End User Advisory Group meeting in May
1. Brian/Olivier/Eric will facilitate getting a spot on the agenda

12 Apr 2019

Attendees:

AT&T - Martin Birk, FREEMAN, BRIAN D

Orange - Olivier Augizeau , Olivier Renais

Fujitsu - David Allabaugh, ravi.rao, Raghavan Subramanian, Former user (Deleted)

Notes:

Scope of L1 interconnect use case does not include business negotiations (e.g. pricing).These functions should occur at a higher layer. However, we need to ensure that APIs support all business requirements. For example, price/cost may affect path computation.
Reviewed and commented on use case proposal & flow. Discussion regarding use of CDS; Brian noted that there is a learning curve.
Domains within a carrier: AT&T would probably use manual links between domains. Orange would have separate ONAP instances for each country plus international network; could use L1 interconnect between countries.
Agreement that use case supports a business need to automate L1 interconnects. Olivier A volunteered to document business requirements.
Need a place for artifacts. Suggestion to create a child page in wiki.onap.org.
Target Frankfurt release (since El Alto focused on stability). Need to get this on Alla Goldner’s use case list. Suggestion to present use case at User Advisory Group at the end of May.

Action Items:

Update the flows based on 24 Apr 2019 discussion (ravi.rao)
Document high level L1 interconnect business requirements (Olivier Augizeau )
Update wiki to include names of participants
Setup child page with meeting minutes (Raghavan Subramanian)
Check the MEF Interlude work to see whether/what service constraints are supported (David Allabaugh???)
Include Ludovic Robert (from Orange) to the next meeting (Former user (Deleted))
Check on EUAG meeting schedule – Brian to discuss with Olivier/Eric (FREEMAN, BRIAN D)
Review business requirement slides; send comments to Denise (FREEMAN, BRIAN D, Olivier Augizeau, Martin Birk, Olivier Renais, Eric Debeau, Ludovic Robert, Matthieu Geerebaert)
Need to determine where to host development and demo; can we support a 100G/OTU4 ENNI? Xin Miao (Unlicensed)
Bring agreed-upon business requirements to Use Case Subcommitte (ravi.rao)
Identify impact to ONAP components - where we need help (ravi.rao to lead; contributions from FREEMAN, BRIAN D , Olivier Augizeau , Eric Debeau . Raghavan Subramanian)
Develop presentation for EUAG. Denise to create first draft using new EAUG template & send to team. 31 May 2019 Former user (Deleted)
AT&T to discuss L0/L1 as stand-alone use case with Alla and Catherine (versus sub-use case of CCVPN) FREEMAN, BRIAN D
Orange to present their ideas of TransportPCE integration without CDS 29 May 2019 Olivier Augizeau
~~Fujitsu to begin new ONAP process for modelling/blueprints; share results~~ 29 May 2019 Raghavan Subramanian, David Allabaugh, Former user (Deleted)
Fujitsu to draft proposal for lab configuration Former user (Deleted)
Review draft EUAG slides Olivier Augizeau FREEMAN, BRIAN D
Investigate Legato and Interlude in more detail
Get zoom/webex bridge and update wiki page, meeting invitation Former user (Deleted)
All: read through PoC Definition
Fujitsu team to summarize/present contributions to Frankfurt release 29 Jan 2020 Former user (Deleted), Xin Miao (Unlicensed)
Update team accomplishments during Frankfurt release based on feedback Former user (Deleted)Xin Miao (Unlicensed)

Open Items:

Identify the best way to handle notifications (domain controller <> SDN-C, domain controller <> SO) Xin Miao (Unlicensed)
Resolve where interconnect details are specified or negotiated : OSS/BSS or ONAP

Browser not supported