Open orenais opened 1 year ago
amazzini
commented
1 year ago I would think that the opposite link information applies only in the case of unidirectional Links linking the same pair of bidirectional NEPs. If so, it seems true that is not possible to distinguish AZ Link from ZA Link. This issue is solved in the Core IM thanks to the Link Ports. Further discussion is necessary.
rcasellas
commented
1 year ago Hi
Just two thoughts
If these are unidirectional links with bidirectional NEPs, I fail to see the issue, I am probably missing something. Link A->B and Link B->A will have reverse NEPs uuids, right?
I guess the original issue is if we want to associate a “pair” of unidirectional NEPs “only in the topology aspect”, similar to what in other contexts people call “port pair”
Can you elaborate?
Thanks
Ramon
From: amazzini @.> Sent: domingo, 9 de julio de 2023 17:28 To: OpenNetworkingFoundation/TAPI @.> Cc: Subscribed @.***> Subject: Re: [OpenNetworkingFoundation/TAPI] Opposite Link (Issue #542)
I would think that the opposite link information applies only in the case of unidirectional Links linking the same pair of bidirectional NEPs. If so, it seems true that is not possible to distinguish AZ Link from ZA Link. This issue is solved in the Core IM thanks to the Link Ports. Further discussion is necessary.
— Reply to this email directly, view it on GitHub https://github.com/OpenNetworkingFoundation/TAPI/issues/542#issuecomment-1627748121 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQOMXJSGY5FKAQNM5RN5F3XPLEZBANCNFSM6AAAAAA2BOCMLA . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ACQOMXMYSLXRCLX5LJLJBDDXPLEZBA5CNFSM6AAAAAA2BOCMLCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTBAV3RS.gif Message ID: @. @.> >
amazzini
commented
1 year ago Another consideration is to sistematically model bidirectional links even when ended by two couples of unidirectional NEPs. Doing so, you join the NEPs according to the topology intent pursued at installation/cabling time. Additionally the Access Port may join the couple of logically unidirectional NEPs. In other words, when a link is modeled as unidirectional, it is intended for an unidirectional use, hence the "opposite" link is not applicable. Nigel & Andrea
orenais
commented
1 year ago Thanks to all of you for considering my point. Answering to the conversation thread starting from first to latest answer. I had in mind both the case of bidirectional and unidirectional NEPs. For bidirectional NEP, there is a way to retrieve the opposite link, but this imply to scan the list of links until we find one that has the same NEPs at its ends. So the problem is more obvious in the case mentioned by Ramon when we consider on both sides a pair of unidirectional NEP terminating 2 unidirectional links. In this case we don't really have a way to make sure both unidirectionnal links are associated and use the same cable. It would be painfull to scan the risk charaterictics to compare them. Additionally we have no garanty that this information has been correctly filled in the data base. Some SRLG might miss from a list. Systematically model bidirectional links is an acceptable solution, but IMHO probably not so optimal in terms of backward compatibility. Additionaly it constrains the implementation. Some OEMS may have already developped their controller considering unidirectional links. As the amplifier information is not associated with the links but at the oms-CEP level some of them may have done complex implementation that they are not really willing to change. Moreover it is risky since it implies to add an implementation guideline which would be in a RIA and could be easily missed. My feeling is that adding an opposite-link attribute to the link (To check : making it mandatory for unidirectional links with a when statement to avoid potential wrong implementation) does not imply to modify implementations made by early implementers. They will just need to populate an additional attributes which limits the required developments. For the ones that want to work on a T-API topology retrieved from a NMS/controllers it will greatly simplify the code and limit the number of operations required to build this information.
rcasellas
commented
1 year ago From: Olivier RENAIS @.***>
My feeling is that adding an opposite-link attribute to the link does not imply to modify implementations made by early implementers. They will just need to populate an additional attributes which limits the required developments. For the ones that want to work on a T-API topology retrieved from a NMS/controllers it will gretaly simplify the code and limit the number of operation required to build this information.
Just to note that, in the meantime, one can use the “name” array to encode such information (the uuid of the reverse link) as a temporary workaround. I am aware this does not address your concern fully and it is not ideal
— Reply to this email directly, view it on GitHub https://github.com/OpenNetworkingFoundation/TAPI/issues/542#issuecomment-1642378078 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQOMXPAMRFIJ5LV3FYDGL3XRABTFANCNFSM6AAAAAA2BOCMLA . You are receiving this because you commented.Message ID: @.***>
orenais
commented
1 year ago Sure, the name array is really convenient to handle many workaround.
We have started working on a T-API 2.4.x compliant PCE in transportPCE : https://git.opendaylight.org/gerrit/c/transportpce/+/106775 At that time we built the classes that allow abstracting Nodes and Links from the topology to Graph objects. There is still a method for which we are investigating on how to make it the best way : this is the method that allows retrieving from a link its corresponding opposite link when unidirectional links are used between ROADMs. In our network we have some links that have the same endpoints but do not use the same path/cables, so that we need this attribute to make sure that when we have calculated a path from A to Z, the path we calculate from Z to A uses the right path and that impairments are correctly evaluated. We did not identify at that time some link attribute in the yang model that provides a reference to the opposite link. If we did not miss anything, would it be possible to add this attribute to the link in 2.4.x models? Thanks!