[TRNSPRTPCE-460] PCE picks wrong aendPceNode, zendPceNode and termination-tp Created: 14/May/21  Updated: 23/Feb/22  Resolved: 11/Feb/22

Status: Verified
Project: transportpce
Component/s: None
Affects Version/s: None
Fix Version/s: Phosphorus

Type: Bug Priority: High
Reporter: Shweta Vachhani Assignee: Shweta Vachhani
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 weeks
Original Estimate: Not Specified

Attachments: File ethernet service input payload.json     XML File port-mapping.xml     Text File reproduce the client pick error on muxponder ethernet pce log.txt     Text File wrong client port pick log.txt    

 Description   

Current PCE code is picking up very first XPDR node as aendPceNode and zendPceNode. For example if a XPONDER-OUTPUT link exists only between TPDR1-XPDR3-NETWORK1-RDM1-SRG1-PP1, but PCE always assigns TPDR1-XPDR1 as aendPceNode.

During the testing with equipments we found even though we create Xponder links for certain TPs, PCE returns TP which doesn't have physical connections. We suggest updating following:

if (ServiceFormat.OTU.equals(this.serviceFormat) && nttp1 == null)

{ LOG.info("Tail attribute is null. Please continue"); continue; }

There is client TP for OTU service format. In that case, once network TP is found and service format is confirmed method should return. This is the correct code.

} else if (ServiceFormat.OTU.equals(this.serviceFormat))

{ LOG.info("Infrastructure OTU4 connection"); this.valid = true; return; }

PceLink only has just client attribute, as a result the path returns same client TP even through they are different. For example one end has CLIENT2 and other-side has CLIENT5. It would be a good idea to have them separated by having srcClient and destClient

 Comments   
Comment by Gilles Thouenon [ 26/Jan/22 ]

Actually, this part of PCE code would need rather important refactor to be sure that when "port-device-name" and "port-name" are specified in the service-create rpc, they are correctly transmitted to the path-computation-request input, and above all, correctly handled by PCE.

The 25th of January 22, Bala reported same issue, with a wrong client termination-point affected by the PCE to the service termination.
It appears that the client-termination-point specified in the service-create input of ServiceHanlder is not transmitted to the PCE path-computation-request. So, PCE picks the first client-termination-point compatible with the kind of service to affect the client-port of the otn-muxponder to the associated network-port.

PCE must be modified to take into acount input coming from service-create rpc when available, and picks the defaut value only when not specified as input parameters.

Comment by Jonas Mårtensson [ 28/Jan/22 ]

See also https://jira.opendaylight.org/browse/TRNSPRTPCE-176.

Comment by Tianliang Zhang [ 12/Feb/22 ]

Hello,

I still got wrong client port pick problem when testing on UTD testbed.

aToz direction: both a and z are picking z's client port in the input json.

zToa direction: both z and a are picking a's client port in the input json.

Here is the log I have.

Similar problem when I swap a and z node in the input json.(divided by dash line)

wrong client port pick log.txt

Comment by Tianliang Zhang [ 15/Feb/22 ]

I just reproduce the similar problem on another set up.

I attached the log, portmapping, and my input payload here.

Generated at Wed Feb 07 20:43:09 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.