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