[Nsi-wg] Some NSI topics...

Jerry Sobieski jerry at nordu.net
Tue Apr 19 07:31:34 CDT 2011


Hi Inder and all-

I've been thinking hard on these topics below.   I am still unsure as to 
the correctness of some of our decisions here, but I will concede 
several of these in order to move v1.0 forward.

- underspec'd endpoints
     IMO:  This is workable concept and very promising and I like it - 
but requires a considerable discussion regarding topology and endpoint 
semantics that we have not had yet and that will take a while to work 
out.  I think the breadth (and power) of this concept will surprise us, 
so I want to do it well.   So my recommendation is that we do not do 
something now that prevents this, but we should not try to work this out 
in V1.0  - this is a new feature.   For v1.0, leave the endpoint to be 
an endpoint.   I think a lot of this issue will be worked out relatively 
easily in conjunction with NSI topology.   The CS protocol does not 
*need* this to be fully functional and entirely workable. ( The concerns 
that have been voiced are actually topology and pathfinding issues - and 
I think we can resolve these better and more completely in the ensuing 
topology discussion.)

- NSA and NSI Network name equivalence
     I will concede this issue.   I still am not certain this is the 
correct course to take, but since we *do* use the NSA and Network 
interchangeably so often, perhaps we will not run afoul of their 
differences.    I would ask that we keep this issue in mind and if we 
find a compelling aspect that dictates these be separated, that we 
reconsider the issue.   But lets assume for v1.0 that the "NSI Network 
name" and the "NSA_ID" are the same object.
- NSA indirection
I think we agree that the NSA_ID==Network Name.  But the contact 
information for the NSA/Network is not encoded in the name itself.   The 
NSA contact info is *associated* with the network name but requires one 
level of indirection (a look up) to go from <name> to <contact info>.

- Network name: Opaque string or URN?
IMO: Opaque string. For now.   I am certain that we will have more 
specific requirements when we get to NSI topology and/or pathfinding 
discussions.  If those discussions benefit from or require a specific 
format, I will go willingly:-)   But for now, /NSI-CS/ only requires the 
Network name to be unique so that endpoints are uniquely mapped to one 
and only one NSA.  The NSI-CS requirement is only uniqueness, so lets 
not impose more - particularly when we have other undefined protocols 
that may have some requirements as well.    Since we do not know of 
other uses of the Network name, we should leave it as unspecified as 
possible.    It is sufficient for NSI-CS to say "The Network name is 
assumed to be a string that uniquely identifies a single particular NSI 
network."
Thats all we need.  (This allows URNs, DNS names, ISBN numbers, ... as 
long as it uniquely identifies a single NSI network.)
If the group does insist on specific format(s) e.g. URN, I will accept 
it.  But then we must also specify the registry.  And we should also 
specify how NSI verifies the name is conformant to the required 
format(s) since it is explicitly necessary that Network Names have those 
formats.

- NSA/Network ID authentication
We have not addressed this, but this may be necessary to insure no two 
NSAs claim the same [unique] network name.
This goes to some of my reservations about URNs and network names - a 
unique name does not prevent two agents from using it.   How do we 
insure a network name is unique - and in what context (topology 
representation? trust extablishment? etc.)   I think this is a topology 
discussion.   But that we will need to define a mechanism that allows an 
NSA to authenticate a remote NSA as the authoritative NSA for the 
associated network.   Which implies a linkage beween the Network name 
and the authorization credentials.   Has anyone explicitly considered 
this as part of the trust establishment?   Does this go far enough?

- simple user NSAs
We do not have resolution on how a simple user RA should identify 
itself.   Since this simple user RA has no network, what network name 
should it use as its NSA_ID in its messaging?   Since the user NSA has 
no network, it has then no endpoints, and the endpoints in the request 
are therefore not in its "network"...therefore, no uniqueness is 
required unless some far remote NSA needs to contact it...Since the 
simple User RA has no trust with any other NSA, this seems unlikely to 
happen.   So can we use a non-unique network name?   Can we ask the PA 
to assign a "local Network name" to be used for this connection?   
Without resolving this issue, all simple user NSAs will need to acquire 
a globally unique network name in order to particiapte in NSI.   If we 
could allow simple users without networks to avaod registering a unique 
network name, it would make it far simpler for adoption...and I don't 
think it would be difficult to do this or break/change the rest of the 
protocol.
Thoughts?

I hope this helps.
Jerry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110419/f8e6d726/attachment.html 


More information about the nsi-wg mailing list