On 9/10/12 5:48 AM, Guy Roberts 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.

Guy

Hi Guy- So here is a good point for NSI's technology agnostics. Whether some specific technology may or may not be accessible in a uni-directed or bi-directed fashion should not impose a requirement on NSI. If we elect to have NSI support STPs of one form or the other, or both, we leave it to the NRM to translate the NSI primitive appropriately to construct a service instance across the local intra-domain hardware that is consistent with the NSI service request. NSI should do what we deem best for the global inter-domain service framework - and let specific NRMs translate that abstract service model to specific hardware confiogurations. A very similar situation exists where a network implements what appears to be a VLAN service across say, an MPLS or SDH hardware infrastructure - the hardware configuration is resolved by the NRM not by NSI. Just because the service presents something that looks and feels like a VLAN to the user does not require that the instance is actually realized across ethernet hardware. So, even if some hardware can only support bi-directed configuration, that does not impose a requirement that NSI must support bi-directed STPs. (vice versa is true too - if NSI supports bi-directed connections only does not mean that only hardware that supports bi-directional configuration must be used...) This is why it is important to maintain technology agnostics. And further - even if we allow and support bi-directed STPs in NSI, does not mean that we should not support uni-directed connections across those STPs. A unidirectional request does not impose any requirements upon a reverse path - so a NRM could allocate the reverse path however it chose, or it could not, or ... We simply leave it to the NRM to decide how to put a uni-directed path across their STPs. I recommend that NSI recognize both Bi-directed STPs and Uni-directed STPs. NSI leaves it to the local network to decide whether to advertise their STPs as bi-directional or uni-directional. (Note- this does not require a network to expose any other hardware specifi details, nor does it require a network advertise anything more than we have already discussed.) This just says that *IF* you advertise an STP, you need to declare it bi-directional or uni-directional. I also recommend that NSI Reservation Requests now implement "directionality": uni-directional connection, or bi-directional connection. The path object is always considered to be the forward path only. I also recommend that if we agree that NSI supports bi-directional STPs, then we must also define the following "orientation" attribute for STP references: When an ERO element or the SourceSTP/DestSTP references a bi-directional STP(s), the reference must include an explicit "orientation" type-value pair to indicate how the STP is to be oriented relative to the forward path segment: <orientation="outbound"> indicates that the forward path will transit the STP from the intra-domain region towards the inter-domain region, and <orientation="inbound"> indicates that transit will occur from the inter-domain region towards the intra-domain region. The network identifier, or topology id, of the referenced bi-STP is considered the _/intra-domain/_ network for that STP. Note: if the specified STP is a uni-directional STP, the orientation is pre-defined in the topology - thus the "orientation" T-V pair may be omitted or null. But if orientation is specified in the path object associated with a uni-STP it must agree with the orientation defined in the topology. If it does not, it is an error and the request should be failed. I recommend NSI adopt the following behavior for path resolution: STP | UNI-STP | BI-STP Directionality | | ---------------+----------------------+----------------- UNI-dir: | Forward: use ERO | Forward: use ERO | Reverse: n/a | Reverse: n/a (NRM decides) ---------------+----------------------+----------------- BI-dir: | Forward: use ERO |Forward: use ERO | Reverse: PA selects |Reverse: use ERO To elaborate - a uni-dir connection with uni-STPs is fine, no reverse path. A bi-dir connection with bi-STPs is fine, the reverse path is taken from the bi-directional STPs. If a uni path is requested using bi-STPs, the forward path is built, but the reverse path is unneeded - it is left to the NRM to decide what happens along the "reverse path" (it may provision a reverse path anyway, or it may not...) For a bi-dir connection with uni-STPs, we have an issue - how do we select the reverse path? I suggest we let the PA (the network that defined the uni-STPs and is offering a bi-directional service) decide how to identify an appropriate reverse path....the RA did not specify STPs that had a reverse path, so it has essentially left the reverse path selection to the PA to choose. Thoughts? Jerry

*From:*Jerry Sobieski [mailto:jerry@nordu.net] *Sent:* 07 September 2012 11:16 *To:* Jeroen van der Ham *Cc:* Guy Roberts; nsi-wg@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@nordu.net> <mailto:jerry@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.