2025 public meeting minutes
Meetings connection details
available at TransportPCE meetings
https://lf-opendaylight.atlassian.net/wiki/display/ODL/TransportPCE+meetings
2025-12-18
General information
Status on Vanadium: we are close to release the Vanadium GA distribution. Still some issues in the CI to integrate some of the projects such as BGPCEP.
TSC chair election: process is still in progress.
Code Review
Changes merged during the week:
The relation chain of TAPI-PCE (Initial code + refactoring + some changes addressing reviews) has been merged (this includes 29 changes).
Changes under review on transportpce:
Smartoptics relation chain addressing the update of tps including spectral characteristics has been reviewed by Olivier and Gilles. Gilles did not formalize at that time his reviews through comment.
“Remove dead code from inventory module” & “Remove deprecated DataObjectModification methods”: Gilles experienced since this refactoring the issue we already observed with the uninstallation of the tapi feature. He will try to check with Robert why this issue comes again.
Changes under review on transportpce-models:
Add a set of OpenConfig 2.0.0 models”: Christophe proposes this change that introduces a reduced set of models for OpenConfig R2.0, so that we can support several concurrent versions of the same models in the same instance of tpce. He has tested it and succeeded in making cohabiting pre-release1 and Release 2 OC models.
2025-12-04
General information
Status on Vanadium: we are close to release the Vanadium GA distribution. The artifacts of all projects are there.
TSC chair election: process is still in progress. Nobody applied for this function so far.
Code Review
Changes merged during the week:
No merged change this week.
Changes under review on transportpce:
TAPI PCE Relation Chain: it has been reviewed to check whether the different changes can be merged and what still need to be addressed. All the relation chain will need to be rebased on master branch, now aligned on Vanadium.
“Refactor PceLink Interface » is a new change which gives an idea of the spirit of the refactoring we will perform not only on PceLink interfaces but also PceNodeInterface. Start the PceLink interface refactoring in order to simplify and rationalize implementation of OR and TAPI Links, avoiding to use different kind/types of parameter across both implementations. First focus is on nodeId, tpIds and linkIds.
"Address comments of change 115942": should change the commit message and add a generic Jira ticket number
“Refactor TON&PTON to address Change 113567 review”: should add a Jira Ticket and change the title of the commit message.
“CleanUp LOGs in TAPI PCE & ConnectivityUtils”: should add Jira Ticket.
“Address comments on BW units & fiber type”: should add Jira Ticket.
“Clean up and refactor TapiOpticalNode”: simplify for loop that iterates only on map values, put some NPE checks with Objects.requireNonNull, use nonnull-xx methods when available, replace the calculateDirection method by the getTpQualifier that return a record instead of a Map composed of a single element, add a JUnit test to check this new getTpQualifier method.
“Remove enum DirectionType from TapiOpticalNode”: This enum augment the tapi Direction enum with a unidirectional value that is never used. Use the enum coming from TAPI model.
“Add ODU4 service type in SERVICE_TYPE_RATE map”
“Slight refactoring of TapiOpticalNode”: remove non-stricly necessary arguments from the constructor (portmapping, slotWidthGranularity, centralFreqGranularity, serviceFormat), refactor the qualifyNode() method, rewrite the qualifyNode JUnit test
“Refactor and enable PostAlgoPathValidatorTest”: restore the test providing adjustment to make it pass the gate
“Refactor path check in ConnectivityUtils”: resolves two issues (1. The if-statement always evaluated to true, 2. It relied on a hardcoded string "ROADM") : no specific comment/ things to be done
“Add unit test for path check”: no specific comment/ things to be done
“Remove ROADM string check in ConnectivityUtils“: Replaced hardcoded "ROADM" string lookups with topology-based logic in some methods. No specific comment/ things to be done
“Add unit tests for Phtnc methods”: no specific comment/ things to be done
“Remove ROADM string check in SIP methods”: no specific comment/ things to be done
“Add unit tests for SIP methods”: no specific comment/ things to be done
“Remove hardcoded strings in TP handling”: Removes logic that depended on patterns like "CLIENT", "NETWORK", "TTP", "ROADM" etc relying on OR topology. ”: no specific comment/ things to be done
“Add unit tests for TP handling” also Refactors createConnectionsFromService(...) in ConnectivityUtils. No specific comment/ things to be done
“Consolidation of TAPI PCE & func tests”
“Rationalize use of PceNode/Links easing migration”
“Disable PostAlgoPathValidatorTest”
“Initial PCE algo for TAPI “: Jonas is OK with provided answer
“Introduce PCELink interface”: main identified issue is the call of external classes methods in the constructor. Joakim proposed to address his comment in a later refactor but to generate a specific dedicated ticket. Joakim will build the ticket after reading the answers to the comments.
“CleanUp Abstracted Tapi Pce Link and Node Classes” : comments addressed
“Consolidate Implementation of PceTapiLink”: comments addressed
“Add Junit tests of Tapi Node and PCE node classes”: comments addressed
“Initial T-API 2.4 PCE OTN Node Class”: some comments have been addressed. Propose to solve some of the comments in a later refactoring. Still a bit of refactoring to be done before merging it (addressing notably last comment)
“Consolidate implem of Tapi Link & Node classes”: Answer provided. Remaining comments can be addressed in a later refactor.
“Add Tapi Topo File for test”: OK
"Initial T-API 2.4 PCE link & Nodes Classes “ : Joakim’s concern is about potential NPE raised by TapiMapUtils.getUsedBandwidth. For others they could be closed
The Relation of Joakim (“Reset listener state on all exit paths”, “TAPI listener on OpenROADM topology updated”, “Send OpenROADM topology update notification”, “Copy OpenROADM service to TAPI”, “Add FrequencyRange adapter for used/available”, “Dedup TTP C-band available freq map logic” , “TAPI - Unambiguous available spectrum”, “TAPI converting SRG PP used wave length”) is still in progress.
2025-11-27
General information
Status on Vanadium: a new version of tpce artifacts was published last week and has been integrated by Robert Varga
TSC election process: Gilles has been reelected. TSC Chair will be elected soon.
Code Review
Changes merged during the week:
Change related to the new Vanadium release
Changes under review on transportpce:
“TAPI-unambiguous available spectrum” solves a bug creating available spectrum. This bug appears when tapi feature is installed, not at the initialization, but after services have been created.
Relation chain on Tapi PCE:
Joakim rebased is relation chain (id-dependency) on TAPI-PCE relation chain.
Gilles provided some changes starting refactoring the classes created for TAPI-PCE : “Clean up and refactor TapiOpticalNode”, “Remove enum DirectionType from TapiOpticalNode”, “Add ODU4 service type in SERVICE_TYPE_RATE map”, “Slight refactoring of TapiOpticalNode"
Olivier started to address comments of Smartoptics review of TAPI-PCE relation chain, providing some changes, on top of the relation chain (to avoid relaunching on the gate tests for the whole relation chain) : “Address comments of change 115942”, “Refactor TON&PTON to address Change 113567 review”, “CleanUp LOGs in TAPI PCE & ConnectivityUtils”, “Address comments on BW units & fiber type”
Gilles ask for potential review during next week, as it becomes urgent to merge this huge relation chain (30 Changes), considering that some further reviews may be done asking for some adjustment even after the change have been merged.
All the relation chain will need to be rebased on master branch, now aligned on Vanadium.
2025-11-20
General information
Status on Vanadium
A first version of tpce artifacts was published last week. But a regression has been identified on controller upstream project. Since a new NETCONF version is available, Gilles will publish a new version of tpce artifacts very soon.
TSC election process is underway. Tomorrow is last day to apply. Gilles renewed his application. You must be either a committer or an ACM (active community member, it means at least 20 contributions during the previous 12 month period)
Code Review
Changes merged during the week:
Changes related to the new stable/vanadium branch and the release publication
About 10 changes to fix various minor inconsistencies detected in the code.
Changes under review on transportpce:
Relation chain on Tapi PCE:
the change on the top now passes the gate. It includes the test of Tapi PCE functionality and provide a reference on which we can rely to make some refactoring and test that this refactoring does not affect the TAPI PCE behavior.
Relation chain on Connectivityutils refactoring:
the main goal is to avoid dependance on Node and Tp naming convention that could evolve so that we depend on some fixed static parameter populated in the topology to determine node and tp types.
Gilles suggest that SmartOptics rebase its relation change on top of the TAPI-PCE relation chain, to make sure that the refactoring does not affect the Tapi PCE behavior. This will probably be simpler since the opposite way of handling it could lead to complex merge conflict.
Add provision mode for B100 OChInterface:
Bala isolated the change in the renderer yang module. But it seems that the modification from Akash making operational mode type as a union of a string and a Uint8 has not been propagated.
Other
Gilles proposes that we close current sprint next week after the Vanadium release, and that we start chrome iteration development with a new sprint starting from a cleaned version.
2025-11-06
General information
Vanadium GA shall be released soon.
At the last TSC meeting, members voted for opening the new gNMi project proposed by Pantheon.
Our issue to integrate in Karaf the same OpenConfig models with different versions (as it is done with OpenROADM models) has also been evoked.
Code Review
Changes merged during the week:
No change was merged during the week
Changes under review on transportpce:
Relation chain from Akash to handle Operational modes: proposes to handle Operational modes as a String or an Integer through an union type in the yang model. The merge conflict is probably concerning the previous associated change. Abandoning it would probably solve the conflict. The revision of associated yang file should be updated. This change is still WIP since some consolidation is needed.
Relation chain of Joakim concerning Tapi Topology update: Joakim is still working on it.
Relation chain of Joakim related to the refactoring of ConnectivityUtils: Joakim has removed all string dependencies in his relation chain. Gilles did not identify any conflict with the PCE relation up to the antepenultimate change.
Joakim succeeded in updating the PostAlgoPathValidator test. He has been working on removing the XStream dependency in his change, but this is still work in progress. Gilles also works on the same topics, so that we could have 2 solutions to solve this.
TAPI-PCE relation chain of Olivier
Joakim started his review on the TAPI PCE relation chain.
Gilles also started working on the relation chain. He provided some changes to simplify the code and reduce the number of attributes in the constructors. He suggested that we address some of the comments made in the change going from the older to the later ones, through changes on top of the last change(“Consolidation of TAPI PCE & func tests”), because only this change provides all the tests that allow checking that modifications introduced addressing reviews have an impact on the global implementation. For comments that imply a deep refactoring he suggested that we handle them through JIRA Ticket to keep trace of needed developments.
Other
Andrea mentions they are using the lighty nodes in UTD and may need help to implement their use cases. Christophe mentions that we will need to refactor some of the code of the Lighty Nodes to address PM management.
2025-10-30
General information
Will probably get news from Release manager about Vanadium availability during today’s TSC meeting.
Code Review
Changes merged during the week:
“Avoid NPE for OC node in PceCalculation”, “Introduce aend & zend OpMode in tpce-common-types”, & “Change OM handling in device-renderer.yang” have been merged addressing TRNSPRTPCE-884 & 885.
“Increase delay in DeviceTransactionManagerTest” solves an issue with the CI when Gerrit is overloaded.
“Adapt serializeContextTest from test-common” solves an issue identified during the migration to Vanadium associated with Junit test in test-common.
“Used connections in TAPI are not deleted”
“Prevent NPE while deleting connections in TAPI”
“Prevent exception during PCE spectrum allocation”
Relation chain provided by SmartOptics for Contentionless feature
Changes under review on transportpce master branch:
The TAPI PCE relation chain has been rebased. We have been forced to disable the PostAlgoPathValidatorTest, because the deserializer does not succeed in instantiating PceLink (in Edge class) since PceLink has been changed from a class to an interface from which PceORLink and PceTapiLink provide implementation.
“Copy OpenROADM service to TAPI”: Joakim started addressing the comment made on this change by Jonas and Olivier, but still remains some work to be done
“Remove superfluous condition in ConnectivityUtils” : it seems that rather than removing the useless statement, it might be better to adjust the if statement so that it works in the expected way (create a TOP connection between 2 OTSi NEP, when the 2 end Nodes of the Path are Xponders : when end points are ROADMs it means we are creating tunnels, that are not associated with OTSi TOP-connections, but MC connections handled in another way and another place of the code) .
“Refactor ConnectivityUtils add unit tests for TP” is the first change of a deep refactoring concerning the use of specific characters-chains. This refactoring brings a lot of value but may collide with the work done on TAPI-PCE. Before merging the relation-chain we will need to check that when it is rebased on the change on the TOP of TAPI-PCE relation chain, it does not affect the associated functional tests.
Other
Akash has some issues pushing some code because his e-mail- address does not match with his Gerrit Profile, which he can’t edit. Gilles suggest to submit the case on Zulip (LFN support).
2025-10-23
General information
We are preparing Vanadium. Artifacts have been released for transportpce/models. Master branch of transportpce has already migrated to V.
We are close to the deadline (2 November) for submit a session to the next LF event: "Cloud Native Telco Day 2026", that will be held in Amsterdam (The Netherlands) in March 2026. Cloud Native Telco Day | LF Events
Robert Varga sent a mail to enquire on how ODL users are willing to deploy it. Do not hesitate to answer.
New project under preparation in ODL community: gNMI project - OpenDaylight - Confluence
Code Review
Changes merged during the week:
Changes related to the V release (transportpce-models): new stable/vanadium branch
Change of the project structure
Issue in pom.xml files introduced in the new project structure
One bug raised by Joakim: “Modernize a switch-case structure”, “Prevent NPE in TopologyUtils.createOtnTopology”
the Relation chain on Contentionless SRGs has also been merged
and also:
“fixup few Javadoc violations”
“Fix @NonNull annotations use”
Changes under review on transportpce master branch:
Gilles abandonned several changes: most of them were very old, because they were obsolete.
“Increase delay in DeviceTransactionManagerTest”: Gilles propose this change that should solve a JUnit test failure appearing regularly on the CI.
“Prevent NPE while deleting connections in TAPI” and “used connections in TAPI not deleted” are fixing NPE issues and are ready to be merged.
Relation chain on Operational mode is currently under review.
Joakim is working on the comments provided by Olivier on its Relation chain associated with TAPI.
“Remove string dependency in TAPI Connectivity Utils”: connectivityMap is used several times for methods, connectivityObject, as a local variable which makes it very difficult to follow. The proposed modifications in connectivityUtils may interfere and create some conflict when we will need to merge the TAPI PCE. The commit message shall probably be refactored so that we better understand the goal of the change.
2025-10-16
General information
A new project is under preparation in ODL community to develop a gNMI southbound connector: gNMI project - OpenDaylight - Confluence
this is to adapt to ODL context an existing code that Pantheon developped in lighty.io.
Very interesting…
Code Review
Changes merged during the week:
Nothing merged since last TPCE code review meeting.
Changes under review on transportpce/models master branch:
“Change the project structure”: the purpose of this change is to adopt the same structure as the ietf liaison project to ease the integration of these models into the transportpce project. Uses a parent pom.xml file, replaces md-sal dependencies by a yangtools equivalent one and adds a test-distribution directory to ease the integration of models features in karaf. This last also allows identifying issues integrating new models at an early time.
Changes under review on transportpce master branch:
“Bump upstream dependencies to Vanadium”: Gilles started the master branch migration to Vanadium which is very close to Ti-SR1. So functional tests are OK, and compilation on the gate is also OK.
TAPI-PCE Relation chain was rebased on the change that updates dependencies to Vanadium, and the final change providing functional tests has been completed. We still need to develop one additional set of tests for regular transponders.
Relation chain on operational mode: Fujitsu tested it. They identifed 2 issues:
Operational mode is not present in XpdrNetworkAttributes for OpenConfig transponders. We will need to investigate why this is the case.
Both a and z tx/rx operational mode have been added to yang model where there was already on top an operational-mode that correspond to both a and z end. This will need to be consolidated to avoid redundancy.
Olivier provided some guidelines for the adaptation of the “Copy OpenROADM service to TAPI” change for which we had some concerns. In order to avoid potential merge conflicts when we will merge the code for the TAPI Pce, in TapiPceNotificationHandler he suggested that we keep in onServicePathRpcResult, the call of onPathComputationResult. onPathComputationResult needs to be kept as it is, as well as updateConnectionContextWithConn. Both setInput and setServiceUuid shall be kept. However, both updateTopologyWithCep and update TopologyWithNep can be removed. For what concerns TAPI connectivity service database update, listening to ANY openRoadm service successful creation; he suggested to make the update of TAPI connectivity services conditional to the value of a variable such as "ServiceStoragePolicy"; so that, later-on, by just adding the code to be able to modify the setting of the variable externally (by an option at the tapi-feature installation), users can trigger 2 potential behaviors that fit their expectations. This would also fit with what we currently plan to do for the OR topology that we convert in the Tapi DataStore (ABSTRACTED vs FULL).
2025-10-09
General information
Gilles released TransportPCE artifacts for SC-SR3 and Ti-SR1. Release notes still need to be built for these 2 releases.
ODL community is talking about changing the way releases are managed. They want to adopt the "Tip & Tail model of Library Development" as Java and other connex opensource community (scala, Jerssey, Junit, guava, netty, karaf)
Grosso modo, we could have a LTS every 2 years,
LTS should have at least 6/12 months overlap
Each project could choose to integrate LTS release only…
Code Review
Changes merged during the week:
Only changes related to migrations to Ti-SR1 and Sc-SR3 and very few backports.
For Ti SR1, the latest changes merged on master have been backported.
This is not the case of stable/scandium branch for which the branch has been diverging. For this last Gilles just push the minimum change need to follow the release train
Gilles also started the migration to Vanadium, which was due for the 18th of October starting with transportpce Models.
The migration to Vanadium was also initiated for transportpce. V refers to odlparent and yangtool of the same version as for Ti. However for mdsal and Netconf the dependencies are not the same. As per now we can consider that migration is more or less done.
Changes under review on transportpce master branch:
“Used connections in TAPI are not deleted” solves a bug where connections could be deleted even if they are still active and supporting others.
“Prevent NPE while deleting connections in TAPI” could be merged but JIRA ticket needs to be associated to the change.
Olivier’s relation chain on operational mode: Fujitsu will test it and agreed to add a test in functional tests associated with OpenConfig. Orange will need on his side to develop a Junit test in PceSendingRpcTest.
2025-10-02
General information
No specific information
Code Review
Changes merged during the week:
“Correct bug in Get-topology-list”
“SpanLoss bug fixes”
Changes under review on transportpce master branch:
New relation chain from Olivier to solve the bug 884 raised by Fujitsu.
“Avoid NPE for OC node in PceCalculation” solves the bug
“Add operational-mode to PathDescription”: adds operational-mode to the PathDescription yang model and updates the revisions in the different classes that import this model.
“Process OM from PostAlgoValidator to PathDesc”: adds to the pathdescription the operational mode retrieved and selected in PostAlgoValidator,
“OM type from uint16 to String in tpce-device-renderer.yang”: changes the type of operational-mode from Uint16 to String in device-renderer yang model so that it can be used not only for OC but also for OR devices. Updates the revisions in the different classes that import this model.
“propagate OM from PathDescription to ServicePathInput”: Sets operational mode in ServicePathInput according to the OM now present in PathDescription.
Relation chain dedicated to contention-less ROADMS: Olivier has no objection for this relation chain to be merged.
relation chain from SmartOptics:
“TAPI converting SRG PP used wavelength” : Joakim made the modification on getP11UsedWavelength to getPP11UsedFrequencies. So, the change could be merge.
“Copy OpenROADM service to TAPI” is passing the gate. Joakim and Jonas replied to the comment, Olivier has reviewed it. Several issues were identified
onPathComputationResult must be kept, because we need to build a path description after a path computation occurred in the TAPI-PCE.
UpdateTopologywithNep and updateTopologyWithCEP : these functions or their equivalent shall be, at the end, somewhere else (probably in TapiPceNotificationHandler). It does not only concerns ROADMS but also transponders.
UpdateConnectionContextWithConn : this function was removed and is not called anymore. It needs to be restore as onPathComputationResult method is restored.
In CreateConnectivityServiceImpl , tapiContext.updateConnectivityContext is no more called. But we need to update connections after a service has been correctly rendered as they will be used as the supporting connections (equivalent to supporting OTN links) for services to come on top of them.
It is very complicated right now to give some clear recommendations on the best way to handle that change since both SmartOptics and Orange are working simultaneously on the same code. Keeping the code as it was in TapiPceNotificationHandler, if it does not create interactions that would prevent the provided code to operate efficiently, would probably be the best option, to limit potential conflicts when merging the code of the PCE. Olivier still need to solve some issues he has with the generation of new services and connections in the tapi-context. Thus, he will need to modify the code in TapiPceNotificationHandler. The recommendation is put the change in standby mode, so that we have a better view on how to proceed.
2025-09-25
General information
No specific information
Code Review
Changes merged during the week:
Nothing merged since last TPCE code review meeting.
Changes under review on transportpce master branch:
“Correct bug in Get-topology-list” has been merged during the meeting.
“SpanLoss bugfixes”: Correct spelling from “OCS” to “OSC” when accessing power-output and power-input. Src and dest link nodes also now always use the same type of measurements (either only OTS or OMS)
“Used connections in TAPI are not deleted”: This update resolves a bug where connections are deleted even though they are in use.
“Prevent NPE while deleting connections in TAPI”: Gilles suggests to avoid using naming including 1 end for variables since this is devoted to augmentation. Joakim should add a Jira ticket to refer to.
Relation chain dedicated to contention-less ROADMS: Olivier will need to check of these changes since they could lead to potential conflict in the PCE he is currently working on.
“Deleting openRoadm node after controller restart”: Jonas has fixed the issue he had with the first version of this change. ROADM to ROADM links are no more deleted.
relation chain of SmartOptics:
“TAPI converting SRG PP used wavelength”: Joakim made the modification on getP11UsedWavelength to getPP11UsedFrequencies. So, the change could be merge.
“Copy OpenROADM service to TAPI” is passing the gate. Joakim replied to the comment, Olivier to review it.
“Send OpenROADM topology update notification” has been reviewed and looks good to Olivier. It is passing the gate.
“TAPI listener on OpenROADM topology updated” has been reviewed by Olivier. Olivier to review the answer to his comment .
“Added available frequencies”: Joakim has tried to decorrelate this change from the relation chain it was associated with, but did not completely succeed. So, this is still in progress.
“Added Plant uml documentation”: Gilles will provide feedback during next meeting on the best way to handle it in his opinion.
Other
Support of same OpenConfig models in different verions in the same instance of tpce: Christophe is working to clearly fix the revision of all models and append to the yang file name the corresponding revision date. He experienced an issue with the include statement for some models, as the revision can not be added to the include statement. He also created two different features to support the concurrent releases.
2025-09-11
General information
No specific information
Code Review
Changes merged during the week:
Nothing merged since last TPCE code review meeting.
Changes under review on transportpce master branch:
Relation chain of SmartOptics:
“TAPI converting SRG PP used wavelength”: Joakim made the modification on getP11UsedWavelength to getPP11UsedFrequencies. So, the change could be merge.
“Copy OpenROADM service to TAPI” is passing the gate. Still one comment needs to be addressed concerning multithread aspects.
“Send OpenROADM topology update notification” has been reviewed and looks good to Olivier. It is passing the gate.
“TAPI listener on OpenROADM topology updated” has been reviewed by Olivier. Olivier needs his comment to be addressed since this change propose to do things that are already done in a different way.
“Added available frequencies”: Joakim has tried to decorrelate this change from the relation chain it was associated with, but did not completely succeed. So, this is still in progress.
2nd relation of SmartOptics chain is associated with the contentionless feature implementation. Gilles started to review it and did not identify any blocking points.
“Added Plant uml documentation”: Gilles would prefer that we keep rules applied in other projects rather than changing the way we address documentation. He will review it and provide feedback during next meeting.
“Support for complete public OpenConfig 2.0.0 “: Christophe has completed the change provided by Roshan to be in line with what is provided on their public Repo. Gilles notes that support in transportpce of models from concurrent releases is not supported with OC models since they do not specify the revisions in the imports. We may need to rename at a later step the models considering adding to them a revision that is homogeneous through the all the suite of models.
“Revert Add OpenROADM device 13.1.1 models” is no more needed and could be abandoned since we have pushed all models for OR R13.1.1.
“Add renderer to support profile mode”: Akash is still working on this change which should be ready next week
Other
Moojan briefly introduced the issues she has experienced in building the demonstration with OpenConfig devices.
2025-09-04
General information
No specific information from the TSC.
Code Review
Changes merged during the week on transportpce/models:
“Upgrade openroadm from 13.1.0 models to 13.1.1” : updates the change proposed by Bala, including network and service models
Changes merged since this meeting on transportpce:
“Use 13.1.1 network and service openroadm models” : Upgrade revision of openroadm models for network and service layers from 13.1.0 to 13.1.1 to prepare future developments to manage 13.1.1 devices.
“Update revision of some transportpce yang model” : update their revision and, as a consequence, import revision in java code of the transportpce yang models that were updated in the previous change. Additionally, sorts few dict of list comparisons in functional tests”
Changes under review on transportpce/models:
“Support for complete public OpenConfig 2.0.0” : Update change 116532 with OpenConfig models 2.0.0 incorporating all models from the public GitHub OpenConfig repository. Note that openconfig-ap-interfaces@2021-08-02.yang has been renamed to prevent it from being included in the model compilation, as it appears to be corrupted.
Changes under review on transportpce:
“Added plant Uml documentation” : discussion has been delayed to next meeting as Gilles had some comments about it.
First relation chain of SmartOptics :
“TAPI converting SRG PP used wavelength” : Joakim made the modification on getP11UsedWavelength to getPP11UsedFrequencies. So, the change could be merge.
“Copy OpenROADM service to TAPI” was passing but is now in merge conflict. Still some comments have not been updated
“Send OpenROADM topology update notification” has been reviewed and looks good to Olivier but is failing.
“TAPI listener on OpenROADM topology updated” has been reviewed by Olivier just before the meeting.
“Added available frequencies”: Joakim has tried to decorrelate this change from the relation chain it was associated with, but did not completely succeed. So, this is still in progress.
Other
Andrea made a short update of what they have been doing in the OpenLabs for OFC 2025! OpenConfig devices to be managed were an ANRITSU monitoring device, a NEC Galileo Muxponder and 8K Router.
2025-08-28
General information
Titanium release is done, but the TPCE release note should need to be updated.
Code Review
Changes merged during the week:
nothing
Changes under review on transportpce master branch:
First relation chain from SmartOptics:
“TAPI converting SRG PP used wave length”: Joakim made the modification on getP11UsedWavelength to getPP11UsedFrequencies. So the change could be merged. For other changes, it might be easier to have a discussion during a regular meeting to understand what is proposed and what was done since last proposals.
Management of contentionless SRG: Gilles will have a look at the relation chain.
Status of the relation chain of AT&T: Bala still has some issue to compile the models project due to an issue in OpenConfig models. He will share his ERROR LOG. The idea is to replace the 13.1.0 models by 13.1.1 models. After that Service and Network models shall be imported and the tpce code adjusted to fit with these new models. After this is successful, models 13.1.0 can be removed.
On tpce/models : “Support for complete public OpenConfig V2.0.0 models ” still need to be rebased on master branch
“Adjust management of used/available Spectrum in Tapi Factory” is a change proposed by Olivier to modify and limit the impact of the proposal of Joakim in its first relation-chain. Waiting for Joakim’s review.
Other
Andrea proposed that UTD makes an update of what they are currently doing with TransportPCE during one of the next regular meeting. The proposal was enthusiastically accepted!
2025-08-21
General information
Titanium has been released on the 12th of August, stable/Ti branch in on Ti-SR1 ready for developments.
Master branch is now aligned with Vanadium developments.
The proposal for an IETF liaison project has been adopted.
Code Review
Changes merged since our last meeting on transportpce/models:
“Bump Project version to 22.1.0/23.0.0 SNAPSHOT”. Corresponds to the new project version for respectivley Ti/master
“Add OpenROADM device 13.1.1 models” : Equipment supporting 13.1.1 Release of OpenROADM start to appear. Balla merged this change, but after he received some comments from Gilles and started reworking it. Christophe suggests to add to these models both the service and the network model to have the full set of 13.1.1 models. This will allow avoiding some conflicts in the future that we could have if we support both R13.0 and 13.1 in different modules.
Changes merged since our last meeting on transportpce:
“Optimize functional tests execution”. It distributes functional tests across multiple Karaf instances to speed up overall functional tests execution. This change has also been reported to titanium branch (117220)
“Update .gitreview to stable/titanium”. Upgrade .gitreview on titanium branch.
“fix checkbashism issue”. Add a shebang in reflectwarn.sh script to avoid compilation errors.
“Update docs/conf.yaml to Titanium”. Update doc conf file for titanium branch
“Bump project version to 12.0.0-SNAPSHOT”. Update project version for Vanadium on master branch
“Bump project version to 11.1.0-SNAPSHOT”. Update project version for titanium SR1 on Ti branch
“fix few compilation warnings”. It fix compilation issues ont master and Titanium branches
“fix bug in tapi-topology to create a RDM node”. Add the mandatory missing CostCharacteristic element to items of a NodeRuleGroup. When mounting the OpenROADM ROADM-A in version 2.2.1, an exception is thrown because the cost-characteristics child element is missing from some node-rule-group elements.
“Clean up few warnings”. In CatalogDataStoreOperationsImplTest, mock exact arguement rather than any Class to remove the unchecked SuppressWarnings annotatio. In JsonDataConverter and XmlDataConverter, change the class declaration to remove the raw type compilation warnings.
Changes under review on transportpce master branch:
“Test Tapi Feature unsinstallation” still does not completely solve the issue
“Correct Bug in Get-topology-details” has been tested with postman and solve the issue experienced by Jimmy
The following relationchain is associated with the introduction of contentionless feature :
“Use contentionless SRG PP used wavelength”.
“Save SRG information during device mount”.
“Package for contentionless SRG information”.
“Add wavelength duplication to tpce portmapping”. : to save wavelength duplication during device mount
The following relation chain needs to be to be rediscussed since a lot of things changed and some decisions were made on some changes that can also impact others….
“TapiListener on OpenROADM topology updated”.
“SendOpenROADM topology update notification”.
“copy OpenROADM service to TAPI”. Still need to be rediscussed since a lot of things changed in the meanwhile.
“Added available frequencies” : Still need to be rediscussed since a lot of things changed in the meanwhile.
“Tapi converting SRG PP used wavelength”. LGT Olivier as far as it passed the gate (Test 190 does not fail anymore)
Other items:
Bala asked when we plan to remove support for 1.2.1 Release of OpenROADM. We will wait for a confirmation by Gilles but if we introduce 13.1.1 and remove 1.2.1 at the same time, Vanadium is a good candidate since API rupture shall be done at the introduction of new major release.
2025-07-24
General information
Titanium migration is still under progress for TransportPCE project. Everything is ready, but the new stable/titanium branch is locked, so last changes to be merged are still in a pending state…
artifacts are released for transportpce-models.
Code Review
Changes merged during the week:
“Catch GNPy exception when not available“: Gilles fixed the exception we had when the GNPy server is not available during the PCE path computation. This makes the controller execution cleaner.
“Refactor oduSwPool creation in OR Otn Topology“: Gilles reworked this change to integrate it into Ti. There was a strong bug that was, until now, hiden…
“Prevent NEP available total size from being null“ and “Parallellizing node calls spanloss calculation“ from Smartoptics are part of Ti.
the relation on Ti migration (bump of upstream + peko)
“Rename class name of functional tests“ and “Store karaf.log in tox after functional test exec“: Gilles refined scripts to be able to have karaf.log tracks on the CI. Should help to understand why our functional tests are sometimes failing on the gate.
“CI: update maven version used by tox-verify job “: update the binaries of maven used on the CI