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

[Jerry Sobieski]

Hi Jeroen and all-

Sorry this is a bit long - but I propose we do two things: 1) The ERO 
path be defined as a single [forward] path consisting of one STP 
reference per hop.   2) each network indicates in their topology 
description the duplex STP pairings to be used for reverse path 
construction for bi-directional services.

Detail/discussion below.
please read and comment.

Thanks!
Jerry

On 9/7/12 7:37 AM, Jeroen van der Ham wrote:
> Hi,
>
> On 7 Sep 2012, at 12:16, Jerry Sobieski <jerry at nordu.net> wrote:
>
>> 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./_
> I'm not trying impose geographical restrictions, I'm trying to add logical restrictions. STPs with the same Topology ID should go to the same NSA. This makes the whole behavior a lot more predictable.
Yup - by definition: STPs with the same topology ID belong to the same 
NSA.  This is always the case in NSI.  But in specifying a path, we do 
not always want the forward and reverse components to transit the same 
path elements.     We could, for instance, request that the forward path 
transit one network, but the reverse path transit a different network.   
This is perfectly legal and useful. But it can't be done if you cannot 
specify a different topology Id for the forward and reverse STPs.  I.e. 
/there is no inherent reason the forward and reverse hops must transit a 
single particular network or even traverse the same number of explicit 
hops./

Thus, the proposed triple  (topology, source port, sink port ) 
constrains the source and sink to be in the same network - This does not 
solve any problem, thus is places arbitrary and unnecessary restrictions 
on path specification.   We don't put unnecessary or arbitrary 
constraints into the standard.

The more important question is: _/Do we actually need to specify a 
reverse path at all? /_    I suggest not.

I recommend that we specify the forward path only in the ERO.  Each hop 
would be:  ( topology Id, port Id, tv1, tv2,... ).  i.e. a STP 
Type/value reference.   If a service request is asking for a 
uni-directional connection, then there is no need for reverse path ERO 
elements at all.    If a service request is asking for a 
"bi-directional" circuit, then we let the Provider Agent construct the 
reverse path according to duplex pairing attributes defined in their 
topology.  Thus, again, there is no need for a reverse ERO element.   
(Indeed, we can't actually identify the forward transit STP until the 
forward path segment is confirmed and we can get the "as-built" STP back.)

If a "bi-directional connection request" has to do something special to 
build a bidirectional connection, i.e. not just build two 
uni-directional connections, then we need to _/define explicitly what a 
"reverse" path is meant to be./_ Otherwise, it is just another 
unidirectional connection.  And if so, there is no need to have a 
special primitive that does two uni-directional connections in one 
request - we just perform two requests and simplify the protocol.

If, however, a user wants a connection that has both a forward channel 
and a back channel, and the back channel transits ports that are 
"tightly coupled" in some specific manner with the transit ports in the 
forward path, then we really need a "bi-directional connection service" 
- it is not just two uni-directional connections.     For example:  If 
you want the reverse path to transit a particular receive port because 
it is associated with a particular transmit port on the forward path,  
then you need to specify what that "association" is - specifically.   
Its not implicit or self evident in anything we have adopted to date.

The WG has not been able to provide a rigorous and concise definition of 
what a "bi-directional" Connection  instance means. We all know it when 
we see it :-)...but we have nothing specific that can be adopted as 
either part of the NSI CS standard, nor even as part of a best practice 
or service definition.   Thus, we are all over the place on how the ERO 
should look.    From experience, we know such connections are generally 
made up of two adjacent - but separate - uni-directional data flows 
going in opposite directions - but this is not a formal specification 
and often not actually the case in the WAN or even the metro space.   We 
have a notion of a "forward" and "reverse" data path - but what 
*_/SPECIFIC/_* characteristics do they exhibit relative to one another? 
   What do we need defined within the topology database to enable a path 
finder to identify the topological objects that constitute a "reverse 
path" relative to some "forward path"   ???

Here is my off-the-cuff definition of a "bi-directional" connection 
instance:
  -- It has a "forward path" defined by an ordered set of 2 or more STPs 
as specified in the path object (or ERO).  The data flows along this 
forward path from the first STP ( ERO[0] ) to the last STP ( ERO[n] ).
  -- It has a "reverse path" defined by a set of STPs identified as 
"duplex" with the STPs in the forward path.
  -- The reverse path flows data in the opposite direction of the 
forward path (assuming the reverse path STPs are ordered in the same 
order as their corresponding forward path STPs.)
  -- Duplex STPs are indicated in the topology.  (This relation may be 
any relation that provides the same semantic meaning.)
  -- The forward and reverse paths have equal capacity (This is not 
strictly necessary, but simplifies things.)
  -- The forward and reverse paths are linked.  I.e. there is a formal 
service-specific relationship between the forward and reverse 
connections.  together, they are/can-be treated as a single service 
instance.

The advantage of these "bi-directional" characteristics is that the 
forward and reverse paths could be constructed by a RA independently.   
I.e. an RA could reserve a unidirectional connection, query its path, 
find the duplex STPs in the topology, reverse their order, and request a 
2nd uni-directional connection. These two connections taken together 
would be technically equivalent to a single bidirectional connection - 
except that the two uni-directional connections would be seen as two 
separate service instances rather than one.

If we adopt this definition for v2.0, then our ERO elements can be 
single STPs defining the forward path - very simple.  A network service 
provider will define their network topology to be uni-directional STPs 
(NML Port objects, and will indicate the Port's duplex twin in the 
database.

Note: perhaps the NML folks can concur with this, or pose an alternative 
relation defining the duplex pairs?)   For example:

Aruba a nml:Topology ;

nml:version "2011112901" ;

nml:hasOutboundPort Aruba:ams-ge1out ;

nml:hasInboundPort Aruba:ams-ge1in .
Aruba:ams-ge1out a nml:PortGroup ;

nmleth:vlans "1780-1783" ;

nsi:isDuplexWith ams-ge1in ;     <---------------- duplexity
nml:alias NetherLight:cph-a .

Aruba:ams-ge1in a nml:PortGroup ;

nmleth:vlans "1780-1783" ;

nsi:isDuplexWith ams-ge1out ; <---------------- duplexity
nml:alias NetherLight:cph-b .



My proposal is to have the local network provide the appropriate 
forward/reverse pair mapping in their topology description. 
Bi-directional connection requests would then use that mapping for path 
construction.   How we specify the mapping syntactically in the NML 
topology can be flexible...but it must be simple and consistent.

Thoughts?
Jerry

> Jeroen.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120907/ee6058d5/attachment.html>