Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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).
Sep 30, 2020
ONAP L1 Carrier Interconnect (MDONS)
Wednesday, September 30, 2020
6:58 am | Central Daylight Time (Chicago, GMT-05:00) | 33 min
@Xin Miao indicated that we are currently assuming a flow more like scenario 1 to avoid double triggering the policy. He described the flow:
Receive alarm
DCAE updates A&AI
A&AI posts event on DMaaP
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)
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.
@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 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.
May 27, 2020
ONAP L1 Carrier Interconnect-20200527 1203-1
Wednesday, May 27, 2020 | 7:03 am | Central Daylight Time (Chicago, GMT-05:00)
@Xin Miao 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 shared an update on the MDONS extensions for the Guilin releaese.
OOF enhancements for inter-domain optimization are in verification
handling of asynchronous responses from the controller is in verification
@Xin Miao 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.
Dave A suggested another possible scenario: a restoration event within a domain (executed by a domain controller) that changes the latency of affected services.
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.
May 6, 2020
ONAP L1 Carrier Interconnect-20200506 1214-1
Wednesday, May 6, 2020 | 7:14 am | Central Daylight Time (Chicago, GMT-05:00)
@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.
Apr 29, 2020
ONAP L1 Carrier Interconnect-20200429 1203-1
Wednesday, April 29, 2020 | 7:03 am | Central Daylight Time (Chicago, GMT-05:00)
@Xin Miao 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.
Apr 8, 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)
@Former user (Deleted) reviewed a summary of the team's accomplishments (slides). Suggestions for additions to the slides were:
Add a slide for next steps
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.
Feb 5, 2020
ONAP L1 Carrier Interconnect-20200205 1302-1
Wednesday, February 5, 2020 | 7:02 am | Central Standard Time (Chicago, GMT-06:00)
@Xin Miao 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: .
@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.
Action: Henry asked that the team review 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.
Jan 22, 2020
ONAP L1 Carrier Interconnect-20200122 1306-1
Wednesday, January 22, 2020 | 7:06 am | Central Standard Time (Chicago, GMT-06:00)
Frankfurt M2/M3 milestone completed - API documentation and functionality freeze. Next milestone is M4 on Mar 5 (coding complete). Thanks to @Xin Miao 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.
Jan 8, 2020
ONAP L1 Carrier Interconnect-20200108 1307-1
Wednesday, January 8, 2020 | 7:07 am | Central Standard Time (Chicago, GMT-06:00)
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.
Brian suggested that Fujitsu create a similar slide explaining our proposed contributions.
Jul 17, 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)