Hi Henrik-

Here are my recommendation about the issues to which you refer:

Jerry
On 1/18/13 3:06 AM, Henrik Thostrup Jensen wrote:

* NML format decision

We need to decide on a format for topology exchange (note that the model for
all these are NML, is is just about the specific format).

Options are: XML, OWL, N3 (unless we want to invent something).

OWL and N3 are RDF based, where as the XML is a direct NML representation in
XML. See the NML spec for XML and OWL examples. OWL and N3 examples can be seen
in the autogole-topology repository at:
https://github.com/jeroenh/AutoGOLE-Topologies/tree/nsiv2/goles

All of the formats need to be augmented slightly for describing NSAs, but that
is more or less trivial in all of them (and roughly the same procedure).

Personally I like the XML representation is it the one most close to the actual
mode, and seems easy to generate and parse.

Do we have some XML examples to compare to the N3 and others?   For instance, a XML, N3, and OWL representation of one or two autoGOLE domains...

My recommendation is to use the form that is a) most likely to exist in five years, and b) easy for network engineers to understand and maintain.



* Do we allow one NSA (by URL) to act for multiple networks

This isn't clear and does affect some things in the protocol design.

Personally I think this is way more trouble than it is worth, and it is easy to
create different URLs for each NSA even if they are hosted within the same daemon.

I agree that breaking the one-to-one relationship of NSA to Network service domain is a non-trivial issue.

I suggest that we maintain the one-to-one NSI architectural/protocol model of one NSA to each Network service domain, and vice versa of one Network to each NSA.   One to one.  For v2.  Revisit in V3.

However (!)   - even with current one-to-one architectural model, one implementation can still be written so that it can be exhibit things like redundancy and multi-network management from a single process.   But these are implementation issues - not NSI framework or protocol issues.

Discussion:
For example:  In the current topology descriptions, an "NSA object" contains a reference to the csProviderEndpoint for that NSA.    The same csProviderEndpoint could be used by many NSA objects in the topology description.   All these NSAs share the same web service endpoint as the place to send messages.  The NSI protocol layer however still sees only one NSA per network service domain, i.e. a unique NSA ID for each network domain.   

NSI protocol messages - regardless of purpose or protocol - are sent between *NSA*s, and contain the destination NSA ID in the message header (and the sender NSA ID as well.)    At the destination, in the code that implements the [shared] csProviderEndpoint, the message is queued for the MDL.  The MDL code looks at the destination NSA ID in the message and processes the message as if it were that NSA.   Simple.    The NSI protocol still only sees one-to-one relations between NSAs and Networks, but one server process could thus be configured at run time to act as multiple NSAs.   

The Message Transport Layer (not to be confused with the Message Delivery Layer) takes care of mapping NSA IDs to tcp/ssl sessions (ws endpoints) and processing the message queues.

This approach does several things:  a) it continues our thrust to separate the NSI framework issues from underlying implementation issues, b) it continue our thrust of separating the NSI protocol issues from underlying message transport issues, and c) it allows us to still indicate in the topology description network policies associated with specific network service domains rather than by NSA.

I recommend we retain the one-to-one NSA relation, but we make sure that we recognize the need for flexibility in the implementations to serve as multiple NSAs  ( i.e. we don't need separate csProviderEndpoints for every NSA as the ws endpoints are not NSI protocol issues.)

* Do we allow multiple NSAs for a single network

Could potentially be used for redundancy.

In case we allow them, should the NSAs have different identity or the same?
This is another message transport layer issue IMO (like above).  

Discussion:
If we have multiple agents representing a single network.. are they all equivalent and interchangeable?  can we send primitives to any of them?   For example: if NSAs A, B and C all represent the same network, can we send a Reservation to A, a Provision to B and a Cancel to C for the same connection?   And likewise, if we send a Reservation to A can we expect a Confirmation from B or C?  How does a Notify() percolate up?  And since our CS state machine imposes a sequence to the life cycle, one would need to synchronize all primitive messages among the equivalent NSAs so that they are not processed out of order by the state machine... I am not sure this is actually viable since the NSAs could have dramatic latency or processing deltas.  To avaoid this, you need to map each connection to one NSA, which voids the reundancy prospect. 

If we were to assert that these NSAs provide redundancy to one another, then the NSAs would in fact be interchangeable.   If one NSA died, in order for the others to continue to function, they would have had to exchanged state for all active reservations before the one died.   So, in fact, they all must maintain a coherent state database.   This is possible, but it poses other problems to the state transitions from potential re-ordering of primitives arriving for one connection at different NSAs.   And since they are interchangable, they act - to the nSI layer - as one NSA...why not treat them as a single NSA?

If we want reliability that is transparent to the NSI layer, we can write software (i.e. implementations) that are redundant.   For instance, an NSA implementation could be configured to have two or more csProviderEndpoints...any one of which is useable for establishing the external NSA-to-NSA transport session.   The redundant NSA software would still look like a single NSA to the protocol layer with a single unique NSA ID, but would advertise several csProviderEndpoints.   The Message Transport Layer could try these endpoints in sequence (or randomly) until a session answers.   Since the two conversing NSAs use a single TCP session, there is no reordering issue.   And the redundant web services implementation is responsible for intra-domain coherency.    This maintains the one-to-one NSA-to-network ratio, while allowing redundancy, load balancing, and multi-network representation to be offered as implementation features.   This keeps the NSI layer very simple - one-to-one - which is a very good thing.

Further, NSI currently allows for NSAs to be genned up arbitrarily that act as aggregators or gateways to other networks/NSAs.  This provides a multi-path control plane capability and is expressible in the topology.  So for topological control plane redundancy, we already have means of expressing this within the current NSI architecture.

I recommend that the NSI layer maintain a one-to-one architectural model of NSA to network service domain.  

I recommend that we have an addendum that describes how redundancy or multi-path issues may be adressed at the software or network design and/or implementation.  

I will also develop a proposal for a "Message Transport Layer".  This will describe how a MTL could simplify several of these issues.   I will schedule this with the chairs for presentation and discussion in the WG.

We should also address the issue that some NSAs to not have *any* network.  Such as a user/uRA.   If "normal" NSAs take their unique ID from their unique network name, then what does a uRA do to get a unique NSA ID?   Does it *really* need a globally unique NSA ID?   or would a locally unique NSA ID that is unique to the PA sufficient?   I would suggest that the NSA ID only needs to be globally unique if global operations are anticiapted (such as for the NSA of a large network) but that a locally unique NSAID is sufficient in most uRA cases. 


* WSDL clean up

Remove superflourous NetworkIdType and saml import ogf_nsi_connection_types_v2_0.xsd

I don't expect any objections here.


* Decide on SOAP 1.1 or SOAP 1.2 for NSI2

This affects requests (slightly), processing and SOAP Faults.

It appears that most are on SOAP 1.1 (at least from the faults I have seen).


* ServiceExceptionType variables

ServiceExceptionType has the following variables decleration:

<xsd:element name="variables"           type="tns:VariablesType" />

Could we get minOccurs="0" on this, as not all exceptions are necessarely
related to a variable.


* Orientation

In the WSDL we allow STPs to be specified without an orientation.

What is the semantics for an STP without orientation?

ugh.   Bidirectional STPs cause so much ambiguity....

I think for Bi-directional STPs in a Reservation request, the orientation must be observed by the PA if the orientation it is specified by the RA.    If the RA does not specify an orientation, both orientations should be considered as candidate end points.  Thus the PA will compute a path to/from each, and choose the one that works, or if both are valid, then the PA may choose either arbitrarilly.

For unidirectional STPs, the orientation, if specified in the service request, must match that found in the topology.   (I.e. topology takes precedence.)   Else, an error "orientation conflict" should be returned, and the request rejected.

My recomendation is that the Source STP, Destination STPs and any ERO STPs should be of like type for v2.  Mixed modes will cause more headaches.

 
* Connection Identifier

We currently have no good way of making an identifier for a connection (it is
scoped within the requester identity). This means that there is no way for one
entity to pass a connection reference to another.
The easiest way to get this it allow NSAs to scope connection ids independently
of requester identity, which means that a connection id at an NSA is always the
same. This should allow us to create a URN for it at least.
Not so.  Its easy to pass a CID...its just not clear that it will be meaningful to the target agent.:-)

Which begs the *real* question:  Why do you need to pass a ConnectionID to another agent? ...presumably an agent that does not know that ConnectionID already..?    What are you trying to do?   

The easiest thing to do is to let the requester choose their own connection ID.  Period.   It is only [locally] unique to the requester.    The PA gets a request from an RA, and creates its own locally unique Connection ID.   The PA binds the PA-CID to the RA's RA-CID in the PA's Connection Table.   And when speaking to RAs, uses the RAs' Connection ID.   And when doing things internally, it has its own local ID it uses, which it can also use for its children.

There is a sense also that Connection IDs should be globally unique so that it is easy to locate segments.   But this is bad and doesn't scale:

In fact, there is a *BIG* security hole created when we assert any tag must be "globally unique" and do not provide validation.   We often say this because the assumption of global uniqueness simplifies things...but in reality, if we are to rely on a tag (e.g. a CID) to be globally unique - and it turns out that it is not - it can crash whatever function is relying on that uniqueness (e.g. all NSAs in the service tree.)   Thus we cannot expect production provisioning systems to simply trust that a tag's value and context is unique.    Thus, if we place uniqueness scoping on any tag, we have to also describe the process whereby the software can verify that uniqueness before that software uses it.    In *this* case, locally unique requirements become trivial to verify, whereas global uniqueness requires large scale distributed infrastructure and processes for validation and reliability.   Thus avoiding global uniqueness requirements for all but the most critical aspects is best. 

So, given this situation, globally unique ConnectionIDs are difficult to secure.   But locally unique CIDs are easily validated.   So we use locally unique ConnectionIDs.   We adopted that the RA creates a CID, which as you note has a limited scope, but is presumably unique to the RA.  

In fact, by concatenating the globally unique NSAID to the locally unique Connection ID, you do in fact create a globally unique identifier.   If a third party references a Connection by its <RA NSAID><ConnectionID>, it should be globally unique.  It does not guarantee that the NSA will know anything about it, or will tell you about it if it does, but there will be no confusion about which segment we are referencing.  (Indeed - even this construct does not mean the connection id is meaningful within the context (NSA) it is being used.)

The children of a Connection cannot have the same Connection ID as the parent.  This is necessary to distinguish the individual segments (created by the PA) from the overall requested CID (that was created by the RA).  Thus a single ID for all segments is not useful in processing those segments... But(!)  we do have a "globalID" tag that is optional that can be associated with all children (this has problems too, but it is currently a feature.)

In fact, each PA must scope requested Connections with the RA NSAID anyway.   Two separate RAs could make a request with the same CID...the PA has to be able to distinguish the two requests...it can only do this by a) either including the RA ID as part of the CID, or to create a local PA CID that is bound to the RA-CID.   Some protocols allow each agent to create their own CID - and they communicate both back and forth in the messaging.   This allows each agent to construct practical CIDs that have a local or internally useful significance (e.g. maybe an index into their connection table...)   Note also: Just declaring a Connection ID to be of the form UUID does not make it unique - uniqueness requires that the requesting agent insures that that id is not used elsewhere.  Failure to do so deterministically can cause duplicates to infiltrate the system and will crash it - classic security hole.

So, The bigger question you pose though is this:  What are you trying to do?  

I can think of a scenario where the uRA agent that made the reservation request is not the same agent making a subsequent request...say a Query() request.  Or a Release() request.     If these "third party" requests want to manipulate the entire end-to-end connection, they can only send that request to the first hop PA...and *that* PA will recognize the RA's CID (so no problem.)  

If the third party request is sent to *any* other NSA, the destination NSA will not recognize it.   And even if we had a means to globalize the CID, we do not have a means of communicating service requests *UP* the tree and over to distant cousins.   All we can do currently is progress these requests *DOWN* the tree.  So any mid-tree requests would only manipulate the descendents of that point - not the entire Connection.  THis would be severely problematic - This brings up a requirement for V3 to generalize the message distribution so that such "up and over" primitive distribution is allowed...but thats V3.

So if an agent wants to monitor a circuit, or learn about a circuit, it *must* walk the tree.   This is the only way to insure the integrity of the entire system in this multi-domain environment.   This is not difficult - we can agree to have a super-user authorization that everyone recognizes - but we cannot bypass the walk itself because that would bypass the structured authorization/security process.     And you cannot compel each NSA to pass information along that is not a verifiable part of the service request.

Thus we still need to walk the tree properly to gain authorized access to the information we seek - including the children Connection IDs that an NSA chose.  (I assert that the segmentation/detailed path information or state  that an intermediate NSA chooses based upon its internal policies is not inherently information the requester is entitled to see or manipulate.  The requester must be authorized to learn this information.)


The real solution is to have a URL, but since we don't use a protocol where
URLs are first-grade citizens that would require a major re-design.
Not sure what you mean by this...?   you mean a URN?

    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