[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