[Nsi-wg] Issues for next NSI call

[Jerry Sobieski]

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 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/20130122/e3a3cec3/attachment-0001.html>