[Nsi-wg] uml proposal for STPs path object specifications...

[Guy Roberts]

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.

Guy

From: Jerry Sobieski [mailto:jerry at nordu.net]
Sent: 07 September 2012 11:16
To: Jeroen van der Ham
Cc: Guy Roberts; nsi-wg at ogf.org
Subject: Re: [Nsi-wg] uml proposal for STPs path object specifications...


On 9/7/12 2:26 AM, Jeroen van der Ham wrote:



On 6 Sep 2012, at 23:56, Jerry Sobieski <jerry at nordu.net><mailto:jerry at nordu.net> wrote:



I do not believe it is appropriate or useful to distribute the "topology ID" across both the source and sink localids.   This forces both source and sink to be part of the same network topology...why?   What value is this?  This does not force any relation to exist between the source and sink ports besides being part of the same topology file - so what is the use case or value of it?   We should specify each STP 2-tuple independently.



No, the question should be the reverse, why would you ever want to have a reservation request with two different topology IDs in it?
Yes I Agree.   So what we have in the proposed triple form - even with a single topology id - is the ability to specify forward and reverse transit points that are widely geographicaly separated.  There is no significant constraints imposed by a single topology.   So while I agree with you that we do not want any particular hop to have widely geographically diverse forward and reverse paths, a single topology ID does not accomplish this.

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 why I am suggesting we have a single forward path ERO, and the reverse path is not specified in a request.  If the request is a bi-directional connection, the provider will build the reverse path.   So for such EROs there is not need for a triple at all...just the topology id and port id of the forward path.

make sense?
J







Think about what an NSA would do with that message, how would it handle that? It would have to forward half of the request to someone else? Why are the two unidirectional connections in the same request? Is there some reason that the need to be together?



Basically, having the possibility of two different topology IDs in a reservation request for one end of a connection opens up a huge can of worms for unexpected behavior. And it does not add anything we can already do. You can simply divide up your two unidirectional connections and request them separately with the same mechanics that we already have without having to change anything.



Jeroen.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120910/dec463df/attachment.html>