This one has to do with whether the existing STP list with ordering information is sufficient to understand the path a service should take, or has been computed to take. I have included the basic schema for reference. As an example let us use a connection request through three domains (A, B, and C) with source STP A1 and destination STP C2. Let us assume that the chosen path is A1->A2->B1->B2->C1->C2. With the existing schema definitions we would get something like this: { sourceSTP=A1 destSTP=C2 stpList={ (1,A2), (2,B1), (3,B2), (4,C1) } } If I remember correctly, the issue we have was that this model is: 1. There is an assumption that sourceSTP A1 is the edge of the connection, and routing will proceed inside domain A, not immediately to the domain adjacent to STP A1. 2. Assumes because A1 and A2 are in the same domain the connection is routed internally to that domain. 3. Assumes that when two STP are adjacent in the ordered list, but in different domains, that there must be an SDP between the two. For example, A2 and B1 must be topologically adjacent and share an SDP. So I guess the question is should we be using SDP here instead of STP? John. <xsd:complexType name="PathType"> <xsd:sequence> <xsd:element name="directionality" type="tns:DirectionalityType" default="Bidirectional"/> <xsd:element name="sourceSTP" type="tns:ServiceTerminationPointType" /> <xsd:element name="destSTP" type="tns:ServiceTerminationPointType" /> <xsd:element name="stpList" type="tns:StpListType" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:OrderedServiceTerminationPointType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="OrderedServiceTerminationPointType"> <xsd:sequence> <xsd:element name="stpId" type="tns:StpIdType" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:int" /> </xsd:complexType>
Hi, The main problem with the current STP List is I think that it is very hard to relate it to a path. 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. 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) 2. How should the STP List represent routing within domains? 3. How do we represent SDPs in the STP List? 4. How do we represent Domains / NSAs in the STP list? (in order to make a query result self-contained) Jeroen. On 1 May 2012, at 17:38, John MacAuley wrote:
This one has to do with whether the existing STP list with ordering information is sufficient to understand the path a service should take, or has been computed to take. I have included the basic schema for reference.
As an example let us use a connection request through three domains (A, B, and C) with source STP A1 and destination STP C2. Let us assume that the chosen path is A1->A2->B1->B2->C1->C2. With the existing schema definitions we would get something like this:
{ sourceSTP=A1 destSTP=C2 stpList={ (1,A2), (2,B1), (3,B2), (4,C1) } }
If I remember correctly, the issue we have was that this model is: 1. There is an assumption that sourceSTP A1 is the edge of the connection, and routing will proceed inside domain A, not immediately to the domain adjacent to STP A1. 2. Assumes because A1 and A2 are in the same domain the connection is routed internally to that domain. 3. Assumes that when two STP are adjacent in the ordered list, but in different domains, that there must be an SDP between the two. For example, A2 and B1 must be topologically adjacent and share an SDP.
So I guess the question is should we be using SDP here instead of STP?
John.
<xsd:complexType name="PathType"> <xsd:sequence> <xsd:element name="directionality" type="tns:DirectionalityType" default="Bidirectional"/> <xsd:element name="sourceSTP" type="tns:ServiceTerminationPointType" /> <xsd:element name="destSTP" type="tns:ServiceTerminationPointType" /> <xsd:element name="stpList" type="tns:StpListType" minOccurs="0" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:OrderedServiceTerminationPointType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="OrderedServiceTerminationPointType"> <xsd:sequence> <xsd:element name="stpId" type="tns:StpIdType" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:int" /> </xsd:complexType> _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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
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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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
This one: (1, null, User.A), (2, A.User, A.B), (3, B.A, B.D), (4, D.B, D.E), (5, E.D, E.User); Starts the connection off with an egress endpoint to help meet Chin's requirements to notify the ultimate start and end domains of the connections. In this case the end user A would have their local NSA notified of the connection request. This could cover the case where they themselves did not initiate the connection but need to be informed of it. I like this idea as it lines up more closely with existing standards. This one: (1, A.User, A.B), (2, B.A, B.D), (3, D.B, D.E), (4, E.D, E.User); Does not involve the end system (User.A) with the connection request. Fun stuff. John. On 2012-05-18, at 5:49 AM, Henrik Thostrup Jensen wrote:
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 _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, On 16 May 2012, at 12:49, Henrik Thostrup Jensen wrote:
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?
Self-contained for the user so that he can do monitoring on his own path without having to learn the full world-wide topology. The idea would be to have a way of relating hops in the query result associated with some domain. It may not be what we want though, and it could also be implemented as an extra function of a pathfinder (given this query result, please break it up into domain-chunks and give me the csProviderEndpoints so that I can do queries on it). Jeroen.
participants (3)
-
Henrik Thostrup Jensen -
Jeroen van der Ham -
John MacAuley