People, I have a behavioural question with respect to the way we have defined the current point2point service. Please correct me if I am wrong and have missed something fundamental... In a bidirectional service request (directionality == Bidirectional) I specify a pair of bidirectional STP I would like connected. Is there an assumption that I can only satisfy this service request by interconnecting bidirectional STP in the topology, or can the aggregating NSA segment this into component unidirectional ports and route using independent unidirectional STP (with any symmetricPath restrictions)? Using bidirectional topology greatly simplifies path finding, however, the symmetricPath parameter only applies to the intra-domain connections done by the uPA. I assume the answer to my question is "it is up to you". John
Hi John On Wed, 25 Sep 2013, John MacAuley wrote:
In a bidirectional service request (directionality == Bidirectional) I specify a pair of bidirectional STP I would like connected. Is there an assumption that I can only satisfy this service request by interconnecting bidirectional STP in the topology, or can the aggregating NSA segment this into component unidirectional ports and route using independent unidirectional STP (with any symmetricPath restrictions)?
I'd say splitting it up into undirectional circuits should be okay (I guess most path finders are not going to bother with this, but I am putting anything on the line).
Using bidirectional topology greatly simplifies path finding, however, the symmetricPath parameter only applies to the intra-domain connections done by the uPA.
AFAIK, symmetric should be for the entire path. However there is currently no way to really expose that two undidirectional paths are symmetric in the topology. Hence, it is impossibly to guarantee a multi-domain path with the symmetric constraint AFAICT. Only in single-domain requests, where the NSA has knowledge about the underlying structure is it possibly to guarantee the symmetric constraint. Interesting... Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (2)
-
Henrik Thostrup Jensen
-
John MacAuley