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

[Jerry Sobieski]

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