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(a)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(a)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.
>
>