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

[Jerry Sobieski]

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> 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/20120907/cd638067/attachment.html>