-----Original Message-----
From: Jerry Sobieski [mailto:jerry@nordu.net]
Sent: Thursday, July 28, 2011 5:19 PM
To: radek.krzywania@man.poznan.pl
Cc: nsi-wg@ogf.org; automatedgole-pilot@internet2.edu
Subject: Re: [Nsi-wg] Few questions for the demo
Hi Radek, some of this you know already, but others may be interested too:
1. At OGF, I think we decide that we'd post NSI plugfest issues to the
NSI-WG list. If its a broader topology description issue, (ala the
SNE/RDF, etc) we should probably distribute to both NSI and
AutoGOLE...as both are using these tools.
2.Gerben or Hans suggested that the Hierarchy should be:
Gole->Node->Switchmatrix->Port. The editor is confusing in that the
Gole->Node relationship actually is displayed graphically as Node->Gole
and has some other options (e.g. Node->Port) that seem unnecessary if we
follow the suggested hierarchy. For purposes of NSI plugfest, we
decided that SNE Node would map to NSI Network, and SNE Port would map
to NSI Endpoint. Jvdh endorsed this as well.
3. Frankly, I think the "GOLE" object is misleading. This should
really be called the "Network" object or "Domain" object or some such.
A "GOLE" is a particular subset of network architecture that infers a
particular policy...Not all networks that use NSI are GOLEs. And the
SNE GOLE object asserts a single location for the GOLE...which many
operators would argue is inadequate as well. I would rather see a more
generalized domain object ala: Network:= ( Node | Network )+.
4. We should not need a global registry for edge/peering points. We
only need bi-lateral coordination so that two adjacent (connected)
networks can specify their local-remote port pairing. The common
global name requirement for every port and every other SNE object is an
RDF description artifact - not a topological requirement. However, if
we use a naming convention that prepends the [globally unique] network
name to all object names, we can easily generate globally unique object
names on an autonomous distributed basis. Gerben will offer a detailed
proposal for using a URN convention for this naming. Then, topology
configuration can proceed on a bi-lateral basis without a central global
topology coordinator or global registry of object/peering point names
(this is all contained in the topology description.) When each
network has constructed their topology (including their ENNI link
names), the RDF topology files should be very easy to merge into a
single global topology description file. Each NSA will learn the
peering points and their names from this global topology description
file. For the near term, we will offer all NSAs the same single
unified global topology description. This will simplify the plugfest
and probably the SC demo as well. However, the NSAs should never assume
that they have a converged or full view of the global topology - maybe
they do, but probably they don't...as long as they work from a local
topodb, how it is populated and updated becomes a secondary issue. For
now - with the single global topology file - all NSAs will have a
comprehensive and static topology view, but the protocol does not assume
that. We can then focus on protocol interop rather than topology
distribution, accuracy, and/or convergence. In the long term, a more
distributed topology management process is required.
I hope this helps everyone understand what we are doing and why we need
to get topologies captured.
Jerry
On 7/28/11 9:55 AM, Radek Krzywania wrote:
Hi all,
I've got few questions, which applies to all of the demo participants, so I do
that via email:
1) what is the most suitable mailing list for the demo issues (I did cross
posting here :( )
2) What is the relation between switchmatrix, node, and ports? Is that node
has ports, and then switch is additional object that defines which ports can be
switched (node-port-swtichmatrix) or node requires switchmatrix to be
attached to ports (node-switchmatrix-port)?
3) as far as I understand, a GOLE is an administrative object defining
organisation, while Node are collapsed network entities (switches, routers,
whatever) into abstract node. Is that correct?
4) there is no global registry of edge/peering ports (we will know them as
topologies will appear from partners), and their URI's. Having a single registry
in one place IMHO would be useful.
Best regards
Radek
________________________________________________________________
________
Radoslaw Krzywania Network Research and Development
Poznan Supercomputing and
radek.krzywania@man.poznan.pl Networking Center
+48 61 850 25 26 http://www.man.poznan.pl
________________________________________________________________
________
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg