[Nsi-wg] Few questions for the demo

[Radek Krzywania]

Hi Jerry,
By having a global registry I meant to improve organisational work on the demo. I agree we don't needed. You also don't need to drink coffee, but why not? ;) Anyway, I hope that there will be a place to see the global topology, with all URI and connections there (I meant that Ports of one GOLE are connected to Ports of other GOLE and you can see all GOLES at the same time). At least for presentation purposes.

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
________________________________________________________________________

> -----Original Message-----
> From: Jerry Sobieski [mailto:jerry at nordu.net]
> Sent: Thursday, July 28, 2011 5:19 PM
> To: radek.krzywania at man.poznan.pl
> Cc: nsi-wg at ogf.org; automatedgole-pilot at 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 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