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