[Nsi-wg] STP lists and path ordering

[John MacAuley]

Henrik,

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.

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);

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);

Was this close to what you were thinking?

John


On 2012-05-16, at 6:49 AM, Henrik Thostrup Jensen wrote:

> Hi
> 
> On Wed, 2 May 2012, Jeroen van der Ham wrote:
> 
>> The main problem with the current STP List is I think that it is very hard to relate it to a path.
> 
> Agreed. NSI topology and STPs are fairly abstract concept, while a path is something fairly concrete that must map to actual hardware in a precise manner (IMHO). There is definitely some shoehorning going on.
> 
>> The current query return format also is not a self-contained answer, in that you need to have the NSI topology to interpret the result.
> 
> Good point.
> 
>> I think we should reconsider the information that NSI should be able to convey in a query result.
>> 
>> So to translate your issues below to requirements and list some additional ones that I ran into:
> 
>> 1. Should the source and destination be part of the stp List? (not having them in there is a bit annoying)
> 
> I really don't think we should have any repeated information in the request.
> 
> However Johns proposed stpList constructing in itself is already partly redundant.
> 
> The list of A2, B1, B2, C1 could be reduced to two elements (A2/B2 + B2/C1).
> 
> But maybe the whole source, dest and stpList thing could be represented in one structure.
> 
>> 2. How should the STP List represent routing within domains?
> 
> Isn't this always encapsulated in NSI?
> 
>> 3. How do we represent SDPs in the STP List?
> 
> Not really sure. (see the second part in my reply to 1. as well).
> 
>> 4. How do we represent Domains / NSAs in the STP list? (in order to make a query result self-contained)
> 
> What exactly is you want to have self-contained? The entire topology information to the path?
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> Software Developer, NORDUnet
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120516/707abf21/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: STP Discussion.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 152905 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120516/707abf21/attachment-0001.pptx>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120516/707abf21/attachment-0003.html>