https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/TRNSPRTPCE-546 transportpce <p>We currently set the rate of a tp in the otn-topology, based on one of the supported rates on the logical connection-point (retrieved from the capabilities announced for a port).<br/> However this is not the expected behaviour. The rate on a tp that does not support any service shall not be set, so that the PCE can identify whether a tp can be used or not to provision a service. Thus the rate shall be set only after a service has been provisionned, according to the interface type that has been set on the port.</p> TRNSPRTPCE-546

OTN tp rate handling in otn-topology

Story High Open Unresolved Unassigned Olivier Renais Fri, 8 Oct 2021 11:49:10 +0000 Wed, 20 Sep 2023 16:21:17 +0000 0 3 1 week, 1 day 1 week, 1 day <p>I'm ok with this behavior that suits well for a configuration blank node.<br/> If we modify PCE to select a TP node which has no rate configured yet, it can be dangerous. <br/> What about if we mount a node whose some ports already support services? I don't see any place in the device model where the rate already configured on a port could be set. Without this information in the device, when we mount the node, it will have no rate information on its Termination Points, and the PCE could select it again...</p> <p>We need to discuss this point before starting any rather important modifications in the code...</p> <p>This raises a lot of questions.... <br/> I guess rate (it could be not simply rate but otsi-rate....) is an interface attribute. So if a service is configured, there should be some associated interfaces on the corresponding ports in the device. <br/> This being said, my understanding is that in the case of a NMS, if an element is disconnected and reconnected, the element is supposed to have all information, that shall be the line to follow to rebuild the information in the NMS. In the case of a SDN controller, the controller is supposed to be the source of truth (I know we are not 100% in line on this topics). This means if an element is disconnected, the controller shall keep a trace of the configuration. After the equipment reconnects, it shall check that the equipment configuration is in line with the configuration it saved. I know we are from this....</p> <p>I agree with Gilles' comment. Today it works well in the ideal case where it is TransportPCE which builds and deletes the services without any disconnection of the controller to the equipment. The problem arises when you have a device that already has ports provisioned that are not known by the controller. There are two possible approaches, either trusting the configuration in the devices or relying on the controller. My personal point of view would be to rely on the equipment...<br/>  <br/>  </p> <p>Olivier, you are right recalling the fact that the port may contain the name of any interface already provisionned on it. <br/> By taking a closer look at the interface in question (in the list of interface), we can just have the interface type (from model org-openroadm-interfaces) which specifies this may be for example an ip or optical channel or otn-odu or..., but without any information related to the rate...<br/> So, that not helps us so much...</p> <p>I could also agree on your way to see things regarding to the fact that the SDN controller finally contains all relevant information. It's possibly OK for anything it configured on the device itself. But what about interfaces already present and configured on the device previously to its control by the SDN controller?</p> <p>If we accept that the SDN controller is the only source of truth, this also means it is the only source of configuration. So, IMHO, the assumption that something else than the controller has been configuring something on a NE is wrong. This is a discussion we had 2 weeks ago in OpenROADM about routers and SDN controller. The presentation was made by Juniper, and I think we had a global consent through all operators and OEMs present at that time on this : nobody claimed this was not correct. <br/> Then about the interface, I am not aware of the existence of interfaces where the rate is not provided in a way or another. yes it might not be simply "rate", but "otsi/och/odu/otu/oducn/... -rate", but it shall be there. And as it is rw, even if this is optional, this is the role of the controller to configure it. Please see in the attachement an extract of the device tree concerning interfaces and related items. <span class="nobr"><a href="https://jira.opendaylight.org/secure/attachment/17600/17600_tree-view-device-interface-rate.txt" title="tree-view-device-interface-rate.txt attached to TRNSPRTPCE-546">tree-view-device-interface-rate.txt^{<img class="rendericon" src="https://jira.opendaylight.org/images/icons/link_attachment_7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> </p> Development Epic Link TRNSPRTPCE-536 Rank 0|i046hi:zi Sprint Sprint 24 Sprint 25 Sprint 26 Sprint 27 Sprint 28 Sprint 32 Story Points 6.0