[Nsi-wg] STP lists and path ordering

[Henrik Thostrup Jensen]

Hi

On Wed, 16 May 2012, John MacAuley wrote:

> There are two approaches we could try to solve this problem.  One is to 
> identify the ingress and egress STP for each domain in the path, and the 
> other is to specify the ingress and egress STP that makes up and SDP.

I agree. (I call this link vs. SDP).

> This was what I was thinking of on the call for a modification to the 
> existing structure to address the first approach.  Ingress means it 
> enters a domain associated with the STP, and egress means it leaves the 
> domain associated with the STP.  This gives us directionality of the 
> path.
>
>    <xsd:complexType name="OrderedServiceTerminationPointType">
>        <xsd:annotation>
>            <xsd:documentation xml:lang="en">
>                A Service Termination Point (STP) which can be ordered in a list for
>                use in PathObject definition.
>
>                Attributes:
>
>                order - Order attribute is provided only when the STP is part of an
>                orderedStpList.
>
>                Elements:
>
>                ingressStpId - the unique identifier for the STP identifying the ingress point of a network.
>                egressStpId - the unique identifier for the STP identifying the engress point of a network.
>         </xsd:documentation>
>        </xsd:annotation>
>        <xsd:sequence>
>            <xsd:element name="ingressStpId" type="tns:StpIdType" minOccurs="0" />
>            <xsd:element name="egressStpId" type="tns:StpIdType" minOccurs="0" />
>        </xsd:sequence>
>        <xsd:attribute   name="order" type="xsd:int" />
>    </xsd:complexType>
>
>
> If you look at the attached diagram we are using in the other 
> discussion, I can model the outlined path as follows (order, IngressSTP, 
> egressSTP):
> 	(1, A.User, A.B), (2, B.A, B.D), (3, D.B, D.E), (4, E.D, E.User);
>
> We could even model the User A end of the connection by leaving out the ingressSTP and only providing the egressSTP:
> 	(1, null, User.A), (2, A.User, A.B), (3, B.A, B.D), (4, D.B, D.E), (5, E.D, E.User);

Erhh.. I can't get this to make sense (there is just another link in 
there, which is redundant).

> Interestingly enough, if we specify the links instead of the entry and exit points of the domain, we can use the same structure but we get:
> 	(1, User.A, A.User), (2, A.B, B.A), (3, B.C, C.B), (4, D.E, E.D), (5, E.User, null);

Should 1 be (1, null, A.User) here?

I think we should be carefull about making promoting an ERO structure as 
the primary thing, so I'd prefer an SDP oriented thing.

All the above have redundancy in them, i.e., one could do:

source: A.User
dest: E.user
inw-path: B.A, C.B, D.C, E.D

inw-path = Inward path STP (inward relative to source). This only 
specifies one STP per SDP. There is less repitition, but I'm not sure it 
is a good idea as it still requires invocation of the topology module to 
figure out the SDPs. On the other hand, I'd probably verify an ERO if I 
got one (they don't trust my pathfinder - why should I trust theirs).

Side note:

It seems there are a lot of different mindset about on how to specify a 
conection in a request. Here are some:

A: Connect these two STPs, One STP being in your domain.
    (Chaining, Thrust the NSA to do the right thing)

B: Connect these two endpoints in your domain.
    (Tree or chain end, the NSA is a stupid resource)

C: Connect these two STPs in the way I say soo. One STP in your domain.
    (ERO Chaining, thrust the NSA to setup the connection, but not its
     pathfinder)

D: Connect these two endpoints, both are outside your domain.
    (I have no sensible use case for this).

>From a design point of view I find the trust + distrust in model C rather 
fascinating.


> Was this close to what you were thinking?

Quite, but not exactly.

On the SDP vs. Link: Originally I used the SDP abstraction internally in 
OpenNSA, but it turned out to be complete crap. Using a link abstraction 
was - from a code point of view - much nicer. However I'm not sure this 
applies on protocol level.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet