Hi, On 10 Sep 2012, at 11:48, Guy Roberts <Guy.Roberts@dante.net> wrote:
Jeroen,
"IMO, what we need to do is provide a single forward path ERO. And if the request is for a bi-directional service instance, then that service provider identifies the appropriate reverse path for the "bi-directional connection". If the requester specifies the forward and reverese path, then it is just two uni-directional service requests. And if so, then we should just do two requests so that the user has the ability to define the two paths independently."
This is a simple and quite elegant solution, but I have a strong concern with this approach as it forces providers to describe their topology using a network modelling method where all STPs map to unidirectional STPs (exclusive use of bi-directional STPs would not be allowed) . This is quite a severe constraint for transmission equipment as ITU-T MIB models do not include uni-directional ports as part of their model.
I like that simple solution indeed. It provides for simple semantics of the reservation command, yet does not limit users in what they can reserve. I don't see the constraint for the bi/uni-directional STPs. In practice the names of STPs are not those of the original ports, and a mapping is defined to go from an STP name to the management-plane name of that port. The uni-directional names of those ports would work in a similar fashion. Jeroen.