2026 public meeting minutes
Meetings connection details
available at TransportPCE meetings
https://lf-opendaylight.atlassian.net/wiki/display/ODL/TransportPCE+meetings
2026-04-02
General information
Ti-SR2: a release candidate is underway for approval by TSC.
V-SR1: still in a pending status.
Code Review
Changes merged since last meeting:
“TAPI - OpenROADM TP to TAPI ONEP spectrum mapping”, “Refactor RDM link conversion to use topology”, and “Add OpenROADM link tp resolution support” have been merged
Changes under review on transportpce-models
"Add openROADM 17.1.0 models” has been pushed by Christophe. This allows to use device and common models of OpenROADM R17.1, while still relying on 13.1.1 models for Network and Services. Gilles identified an issue with this dual dependency to 13.1.1 and 17.1 models. We may need to migrate the entire stack of the models.
Changes under review on transportpce
Smartoptics relation-chain:
“Fail fast if TAPI service already exists”, “TAPI - apply OpenROADM topology updates to NEPs” have been reviewed by Orange (Gilles and/or Olivier)
Joakim changed to Private status the other changes of the relation chain. Gilles highlighted that
"Update pre-commit config file”: is an attempt to solve the issue we currently have with Github action. However, this does not solve the issue.
Olivier just updated his relation chain to solve some pylint issue. We however have some issues with the Daexim dependency. Daexim code would need to be integrated into NETCONF so that it is integrated in an upstream dependency. Robert is working on the issue but need a formal approval form Daexim developers to do so, most of them not working anymore on the project
Other:
Andrea made a summary of the demonstration they run during OFC 2026.
2026-03-26
General information
Ti-SR2: Still in a pending status since we see some issues with the integration test results of the BGPCEP project.
V-SR1: still in a pending status.
Code Review
Changes merged since last meeting:
The bottom of SmartOptics relation chain up to “Copy OpenROADM service to TAPI” has been merged.
Changes under review on transportpce
Smartoptics relation-chain:
Gilles started the review of changes on top of “Copy OpenROADM service to TAPI”
it has been complemented with around 30 additional changes.
The huge size of this relation chain leads to some issue, especially when the relation chain is rebased, since this affects other members of the community saturating the CI.
2 Changes from the LFN need to be merged.
“Add E2E functional tests for OC service creation” has been pushed by Christophe but does not pass the gate for still unidentified reasons (Functional tests failing seems unrelated to the changes made).
Olivier published 2 new changes.
The first, “Fix for transversal routing over tapi topos” provides some fixes so that the PCE can route over several TAPI domains (different topology Uuids) interconnected together through interdomain links.
Tapi Functional Test06 allows testing it, uploading a SBI Topology through Daexim features and creating dynamically an OpenROADM topology, brideged to the first through 2 interdomain links. As Robert mentioned that the way Daexim feature is activated will lead to some issues, we will need to find a way to activate this feature in a different way to run this test.
The second “Switch to UNIDIR links in Topo conversion”: Switches from BIDIR to UNIDIR link in TapiLinkImpl createTapiLink keeping BIDIRECTIONNAL Connections (for OTN Link). This is made to Improves stability in Uuid of created links, and better fits with OR link creation rationale.
Several changes from github Gerrit are also under review…
Other:
We plan to remove support for OR 1.2.1 in Cr. We will need to check as AT&T plans to use release 17.1 for devices how we should add 17.1 models including device, but also common, while avoiding potential conflicts with service and network models which also rely on common models. We may need to update also Service and Network models to the same release. No disruption was identified from R13.1 to 17.1 for what concerns Network and service models. However, the structure of the operational mode catalog has been updated and we may need to adjust the code and the catalog we upload at controller initialization.
2026-03-19
General information
Ti-SR2: All projects were released end of last week, and Gilles released tpce this week
V-SR1: All projects were released end of last week, and Gilles released tpce this week. Main features concerns contention-less Management and Tapi Topology bug fixing & developments, OpenROADM Service and Network Models evolution to 13.1.
Today was the official date for Cr release, but this will be delayed.
Christophe has removed OC models 1.9 from models for migration to Cr. We still need to remove the 1.2.1 models and add 17.1 OR models.
On tpce side we will need to remove the code associated with OC 1.9 and OR 1.2.1
Code Review
Changes merged since last meeting:
“Bump Upstream dependencies to V SR2” (error in message, concerns in fact SR1), “Bump Upstream dependencies to Ti SR2” and other associated changes have been merged to handle the migration to these releases.
Changes under review on transportpce
Smartoptics relation-chain:
Olivier reviewed SmartOptics relation chain up to “Copy OpenROADM service to TAPI”. All of the changes have been considered as OK (+1)
Changes on Top of this ones focus on TP and NEP Management starting with “TAPI-OpenROADM TP to TAPI ONEP spectrum mapping”, a huge change.
“add E2E functional tests for OC service creation ”, pushed by Christophe is still not fully complete but tests service creation for OC Release 1.9.
Robert reviewed the change associated with the add of Daexim dependency, highlighting an issue : Daexim is a downstream MSI project on which we can not rely as a dependency : transportPCE can only rely on upstream dependencies. We will ask the question on how to solve this during the TSC.
2026-03-12
General information
Last meeting was canceled following a technical issue on Orange internal Network
Ti-SR2: we are still waiting for NETCONF to be released.
Code Review
Changes merged since last meeting:
Changes associated with OpenConfig R2.0.0 models easing to set up the demonstration for OFC on transportpce-models
A lot of changes were provided by Anil to solve issues with the CI.
The changes updating Maven version pushed by Gilles to solve gate issues : “CI: update maven version used by tox-verify job”
Changes under review on transportpce
“ci: disable Jenkins tox-verify for transportpce master” : Gilles reviewed it and requested to not merge it, since he did not see equivalent feature available on Github Actions (GHA) and until now Jenkins provides the only way to run functional tests of TransportPCE on the gate.
Other:
IPoWDM use case: Bala has published all the code associated with IPoWDM use case, except code associated with specific-operational-mode changes which was pushed on a specific private branch to test IPoWDM ATT implementation.
OFC Demo: The LOG associated with the issue setting temporary services are on a sever shipped to OFC Exhibition. Thus UTD can not send them before they arrive in LA and start this server.
2026-02-19
General information
Ti SR2 : still waiting for NETCONF R 9.0.2 to be able to release transportpce (transportpce/models has been released)
Annual election for several leadership positions at the LFN TAC (Technical Advisory Council). For some of them, need to be a committer of a LFN project, for others not.
Code Review
Changes merged since last meeting:
The bottom of the stack dedicated to TAPI refactoring up to “Improve readability by creating helper methods”.
“Service creation with OC-XPDR and OR ROADM” provided by Fujitsu to support OpenConfig 1.9.
Changes under review on transportpce
Gilles will continue reviewing the changes of the stack dedicated to TAPI refactoring starting from “Improve readability by creating helper methods”.
Olivier’s relation chains:
Topo Uuid usage consolidation: the 3 changes are ready for review. An additional change is forecasted on top of it to allow for setting externally 2 variables: 1 to set the way the OpenROADM Topology is translated in the TAPI Datastore (Full versus Abstracted), and the second to set the behavior for saving services in TAPI datastore (all service saved versus only services created from TAPI NBI). For this Oliviers ask for help. He has locally created a change, but some deeper refactoring of corresponding classes will be required to be able to handle this.
Transversal TAPI topology consolidation: the change “SBI tapi topology Listener” has been completed to improve the management of Inter-domain link. It is still WIP, but changes below could be reviewed.
“NetConf Proxy Tool” change has been provided by Fujitsu and corresponds to the translation of the existing Proxy Tool we had based on Pearl into a Java version, which will be very useful and will ease the maintenance.
“Add support for proprietary operational modes”: an update has been provided, but the change is still WIP as some tests fail.
Gilles made an update on bump for TI SR2, but is still waiting for the update of the NETCONF project
Other:
OFC Demonstration will be based on OC Release 2.0. This implementation shall be provided by Fujitsu in a short time as we merged the end to end service implementation for release 1.9. (which was a pre-requisite from Fujitsu)
Andrea mentions that all equipment will need to be shipped in a 2 weeks’ time-frame, which means OpenLabs needs the code asap, and at the latest, early next week. Christophe will send a reminder and explain the situation to Roshan.
2026-02-12
General information
Ti SR2 : still waiting for NETCONF R 9.0.2 to be able to release transportpce (transportpce/models has been released)
Code Review
Changes merged since last meeting:
Upstreams regarding TiSR2 (TPCE models) : “Bump Upstreams to Ti-SR2” & “Bump project version to 22.2.0 SNAPSHOT”
“CI: Update maven version used by tox verify job”
“Adapt serialize context Test from test-common”
“Fix a bug in functional test script”
“Fixup Javadoc-based violations in OLM”
“Bump project version to 12.1.0-SNAPSHOT"
“TAPI - Refactor populateNepsForRdmNode readability”
“TAPI - Unambiguous available spectrum”
“TAPI converting SRG PP used wavelength”
Changes under review on transportpce
“Support for complete public OpenConfig 2.0.0 models will probably been abandoned in favor of the one that only uses the modules necessary to run TransportPCE and the one that adds an additional revision common to the same release (for future developments to be able to simultaneously support multiple releases of openconfig models).
“Add a set of OpenConfig 2.0.0 models” will be merged on Chromium, whereas pre-rel 1.9 models will still remain on Ti and V.
Note : we plan to abandon OR Device 1.2.1 support in Cr.
“Service creation with OC-XPDR and OR-ROADM” change was pushed by Fujitsu on behalf of NTT. Christophe has reviewed the change. It is based on 1.9 models of OpenConfig. We plan to merge (on master and backport it on stable Vanadium) this change asap, even if we don’t have corresponding functional end to end functional test, since this code is to be used for OFC demo. Fujitsu will then push code associated with OC 2.0 which at the end shall be merged on Cr.
“SBI tapi topology Listener" : provides a TAPI SBI topology listener to reflect changes occurring in TAPI SBI topology in the OpenROADM node that abstracts this topo. TapiProvider was adjusted to register the listener at tapi feature installation as well as a functional test that verifies appropriate TPs are populated in TAPI-SBI-ABS node after a SBI Topology is loaded in the DS.
”Initial transversal Topo func test" : checks PCE behavior across several TAPI topologies of different Uuid.
“Add SBI topo file to sample configs” : a new topology file that mimics the topology retrieved from TAPI South Bound Interface that still needs to be developed, is provided, to be copied to karaf/target/assembly/daexim folder.
“Add Daexim dependencies to odl-tpce Pom” : adds Daexim dependencies in common so that the feature is activated launching karaf.
Smartoptics relation chain: Christophe merged the 3 bottom changes. Gilles made some additional comments on some of the changes. Joakim rebased the relation chain and addressed comments from Gilles, but it seems there is an issue with the gate, which makes them fail.
“Add provision mode for B100G OCH interfaces” which provides Profile based provisioning was abandoned. Akash and Bala are still working on it, and Bala will provide updated changes.
Other:
Aparaadjitha mentions that trying to create Degree NMC interface with Lighty node (for OpenROADM Version 7.1) we get “operation-fail” answer.
2026-02-05
Code Review
Changes merged since last meeting:
“Bump upstreams to Ti-SR2” has been merged on transportpce-models.
“Bump the lightynode version”: this version of lighty (22.1.0.6) uses Ti SR1 upstream dependencies, to be able to use transportpce-models compiled in Ti-SR1. A newer version (22.1.0.7) supporting OC models 2.0 is also available on gitlab.com public repository.
“Bug in functional tests scripts”: when only renderer functional test was selected the tests were not correctly launched.
Changes under review on transportpce
Some changes are associated with the preparation of Ti-SR2:
“Bump upstream dependencies to Ti-SR2”: this change is still based on 9.0.2 SNAPSHOT version of Netconf.
“Fixup javadoc-based violations in OLM”: new one related to the new version of checkstyle
”Adapt serializeContextTest from test-common”: backported from master
“CI: update maven version used by tox-verify job”: backported from master
Smartoptics: relation chain could be merged up to TAPI- Refactor OpenROADM TP datastore reads
“TAPI OpenROADM TP to TAPI ONEP Spectrum Mapping” provides in in package-info relevant information on associated mechanisms
“Rest listener state on all exit paths” has been removed from the relation chain since it was leading to some issues. Some deeper investigation is required to correct the change.
Other changes :
“Modify validation process in PceTapiLink” and “consolidate topoUuid usage step 1 & 2”: Olivier should add the Jira ticket and reviewers
We are waiting for a contribution from Fujitsu to support OpenConfig R2.0. Fujitsu successfully tested LightyNode 22.1.0.7. They made it run with the developments they made. They plan to push some code by the 13th of February. As OC 1.9.0 is no longer needed. We will probably abandon the support of 1.9.0 and keep only 2.0.0 release support in Cr. Fujitsu is currently evaluating how we can support in the proxy-hijacker the modification of hello messages. For Cr targeted for march we will remove support 1.9.0 and will rely on modified version of 2.0 models.
Other:
For Chromium release, targeted for march, we will remove support of OC 1.9.0 and will rely on the stric necessary subset of openconfig models in version 2.0.0. Gilles suggests that we also remove the support for OpenROADM R 1.2.1 in Chromium . Bala mentions that AT&T may provide code to support OR 17.1 in transportpce.
2026-01-29
General information
Vanadium has been approved and is available since the 26 of January.
Ti SR2 is still not available since we are waiting for Netconf 9.0.2 availability.
Code Review
Changes merged since last meeting:
“Bump upstreams to Ti SR2” and “Bump project version to 22.2.0-SNAPSHOT” have been merged on TransportPCE models.
Changes under review on transportpce/models:
“Add a set of OpenConfig 2.0.0 models” and “Update openconfig models” : For OpenConfig we will keep only the required model since we have some limitation with Yangtools for what concerns include statement . So the models pushed have been adjusted and only corresponds to a limited set of modules.
Changes under review on transportpce
“Bump the Lightynode version": Adopts the 22.1.0.6 version of lightynode (aligned with Titanium-SR1)
“Modify validation process in PceTapiLink” and “consolidate topoUuid usage step 1 & 2” : Olivier should add the Jira ticket and reviewers
“Service creation with OC XPDR and OR ROADMs” has been pushed by Fujitsu but is still not reviewed. Christophe will review it beginning of next week.
Smartoptics provided a relation chain to refactor some of the TAPI code to improve reusability and added some new functionalities in the 5 Top level changes. These last allow listening for topology update in OR when a service is created. TAPI owned node edge points are then updated with their spectrum capabilities in the TAPI topology. Creation of connection still needs to be investigated.
“TAPI - apply OpenROADM topology updates to NEPs”
“TAPI - add OpenROADM TP mapping and NEP PACs”
“Copy OpenROADM service to TAPI”
“Send OpenROADM topology update notification”
“Refactor spectrum extraction and remove wrappers”
“TAPI add SpectrumRanges-based spectrum extraction”
“TAPI - Add empty() factory method for Range”
“TAPI - round THz->Hz conversion in TeraHertz”
“TAPI - Normalize SortedRange by merging intervals”
“Cleanup DefaultOpenRoadmSpectrumRangeExtractor”
“TAPI - Extract OpenROADM spectrum range parsing”
“TAPI - extract SpectrumCapabilityPac factory”
“TAPI - Refactor photonic NEP spectrum construction”
“TAPI - Refactor OpenROADM TP datastore reads”
“Simplify CEP-in-topology checks in TapiContext”
“Prevent NPE processing links during OTN creation”
“Reset listener state on all exit paths”
“TAPI - Reduce log detail and log file size”
“Improved readability by creating helper methods”
“TAPI - Refactor finding avail/used freq”
“Deduplicate TTP C-band available freq map logic”
“TAPI - Value object for OpenROADM topology node id”
“TAPI - Refactor populateNepsForRdmNode readability”
“TAPI - Unambiguous available spectrum”
“TAPI converting SRG PP used wave length”
Other:
Dr Fumagalli made an update of OFC 2026 ongoing work to prepare the demos in UTD. From the discussion they have with equipment manufacturers it seems that tpce was not tried with some of the devices that will be provided : in some of the showcases some equipment will host R2.0 of OpenConfig models. Christophe made an update on the way we will manage OpenConfig in TransportPCE
We will keep only a subset of about 15 of 130 models in tpceModels.
The models will be adjusted (Revision fixed to an arbitrary date across all models, some files imported rather than included)
LightyNode will be customized, and we will have specific version for each release to avoid conflict when having different releases cohabiting, which is impossible to manage with both ODL and Lighty.
We will use the proxy-hijacker to remove/adjust capability statements coming from devices.
Jimmy mentions the fact that OpenConfig is using both the revision and oc-ext:openconfig-version, a specific key to handle version.
2026-01-15
General information
Status on Vanadium: TSC is close to deliver the V release. A release candidate is going to be proposed to the TSC for vote..
Code Review
Changes merged since last meeting:
No changes merged this week.
Changes under review on transportpce:
“Bump the lightynode version" adopts the 22.1.0.2 version of lightynode (aligned with Titanium-SR1). This will allow to manage next version of tpce-models, handling several releases of OpenConfig in the same instance of tpce. OpenConfig models R.2.0 will need to be backported in Ti Release.
“Consolidate topoUuid usage step 1 & 2": through both of these changes, we introduce topoUuid as an input parameters of some TAPI dedicated methods, to make sure they can be used whatever is the considered TAPI topology (Multi-Layer, Full Muli-layer, Alien, SBI) and try to remove hard setting of the TopoUuid in the classes where this might not be relevant. The goal is to be able to handle the different topologies that will cohabitate in the dataStore whereas until now we focused on Full Muli-layer topology.
”Modify validation process in PceTapiLink": this change applies the same approach as the one used for Pce Nodes, when we refactored it to address some comments provided by Smartoptics. Olivier will need to complete his commit messages.
“Service creation with OC-XPDR and OR-ROADM”: Portmapping and Renderer have been complemented with additional methods to provide end to end service provisioning with OpenConfig Transponders. Test will need to be complemented (either in OC dedicated tests or through hybrid tests).
“Added available frequencies”: Jimmy implemented both scenarios 1 & 2 as proposed. This change is ready for review and if no specific issues is identified, it could be merged.
Smartoptics big relation chain needs to be rebased on master since it does not pass the gate.
Other:
Bala mentions that they start having equipment in their labs with OpenRodam models in version 17.1. These models (device an common) will need to be included in tpce-models. Some bugs have been identified with some corrections applied on the devices that won’t be backported to a 17.1.1 model. Thus, some models might be corrected and may be slightly different from currently official 17.1 models.
Gilles and Olivier will work on consolidating backlogs, so that if we have time during next meeting, we can launch a new development sprint.
2026-01-08
General information
Status on Vanadium: Vanadium GA has still not been submitted to the TSC vote.
Code Review
Changes merged since last meeting:
“CI: update Maven version used by tox-verify job” makes the CI functional again. Need to rebase current relation chain to make this fix effective.
Changes under review on transportpce:
Smartoptics relation chain: Joakim has associated tickets to his changes. Tapi Listener on OpenROADM topology updated is still in Work in Progress. Changes at the bottom of the relation chain are open for review.
“Added available frequencies” has been removed from the relation chain. Olivier was fine with the 2 proposals made.
“WIP : support for OpenConfig V2.0.0”: this change allows considering the new reduced set of OpenConfig models introduced in transportpce-models. Its works in a local environment and allows having several OpenConfig Releases’ models supported concurrently. It is not passing the gate, since his related change on transportpce-models is not merged yet.
Changes under review on transportpce-models:
“Add a set of OpenConfig 2.0.0 models” proposes to include only absolutely required yang models. Christophe needed to slightly modify the openconfig-platform model, to directly include into it groupings coming from another yang file managed as an “include”. This means this model diverges from the original OpenConfig model. The fact that this model has been modified must be mentioned in the commit message as well as in a specific file under the resource directory. Revision have also been added everywhere.