[Nsi-wg] Few questions for the demo

Jerry Sobieski jerry at nordu.net
Thu Jul 28 10:18:40 CDT 2011


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 at man.poznan.pl                   Networking Center
> +48 61 850 25 26                             http://www.man.poznan.pl
> ________________________________________________________________________
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg


More information about the nsi-wg mailing list