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 ________________________________________________________________________
Radek, At SLC we agreed that it is fine to use the NSI mailing list for the NSI demo discussions. Guy -----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Radek Krzywania Sent: 28 July 2011 14:55 To: nsi-wg@ogf.org; automatedgole-pilot@internet2.edu Subject: [Nsi-wg] Few questions for the demo 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
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
Hello all of you, Jerry Sobieski wrote:
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 )+.
I agree with that. Some eople know this is a hobbyhorse of mine;-): Policy is not an object, it is a property of an object. All the best, Victor -- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
-----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
Hi all, I've got few questions, which applies to all of the demo participants, so I do
1) what is the most suitable mailing list for the demo issues (I did cross
On 7/28/11 9:55 AM, Radek Krzywania wrote: that via email: 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
Hi Radek- I agree...coffee is good:-) Seriously... For the plugfest, we *will* be providing a global topology for each Challenge. Note: Each Challenge may use a different topology. But within any given Challenge, there will be one global topology description that all NSAs involved in the Challenge will be able to import. Since we decided to _not_ use the Automated GOLE infrastructure, the Challenges will be using artificial topologies. Artificial topologies have the benefit of providing a much richer topology than the the real infrastructure currently offers. So the Challenge topologies are designed to enable the particular protocol features under test and to simplify the evaluation of the results. I am finishing up a draft of the NSI Interop Overview and Challenges documentation. I will circulate these docs and the associated topologies in the next couple days for comment. As it stands right now, expect the topologies to be in .OWL files as downloaded from the SNE tool. BR Jerry On 7/29/11 5:01 AM, Radek Krzywania wrote:
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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
-----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
Hi all, I've got few questions, which applies to all of the demo participants, so I do
1) what is the most suitable mailing list for the demo issues (I did cross
On 7/28/11 9:55 AM, Radek Krzywania wrote: that via email: 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
participants (4)
-
Guy Roberts -
Jerry Sobieski -
Radek Krzywania -
Victor Reijs (work)