- Nsi-wg - lists.ogf.org

Updates for FIA demo efforts and tasks for Monday night/Tuesday morning...
by Jerry Sobieski 25 Oct '11

25 Oct '11

Hi all- the demos are struggling... So here is the plan of attack: GEANT, Pionier, AIST are all working with the new WSDL and have hardware control. We are close with OpenNSA/Argia interface for StarLight, and OpenDRAC at Netherlight is using HTTPS which while conformant to the spec seems to be problematic. So, we will continue to address these issues, but we need to pare down the demo field to get the *NSI* demo to work. 1. We need to statically configure vlan 1780 thru NetherLight (from PSNC port to StarLight/IRNC port) (John MacCauley and/or Gerben?) 2. We need to statically configure vlan 1780 thru StarLight (from Netherlight/irnc port13 to the JGNX port24) (Scott Campbell and Henrik Thostrup Jensen) This will provide a direct link from Pionier to AIST over VLAN 1780. 3. We will use AutoBAHN Pionier as the aggregator for a Reservation: geant.ets:ps-80 -> aist.ets:ps-80. The connectionID and/or Global ID will be registered with the Query Agent. (Michal B. and Jeroen vdH) 4. The QA will query AB pionier for the path info, and pass the location info to a) the Automated Earth and b) the AIST display agent. ( Jeroen van der Ham and Takatoshi Ikeda (AE) and Tomohiro Kudoh? (AIST) ) 5. Everyone, Pionier, GEANT, and AIST especially, please post your perfSonar server IP addresses so that I can add them to the diagram. And make sure your perfSonar servers have the subinterfaces for the 1780-83 VLANs configured with the corresponding IP subnet and host address. And its off to the races... Remember all - we are demonstrating _/*NSI*/_ so its ok to pare things back a bit. THis is complex stuff, we'll continue to get things running, but for now we want to have a successful demo showing circuits being set up across the world, across domains. Thanks! Jerry

2 1

FIA demo
by Radek Krzywania 24 Oct '11

24 Oct '11

Hi all, I need your quick help with the FIA demo. It seems that everything is down, and we will not show NSI glory at all. I would like to ask all NSI domains to put their agents up and ready, and use newer version of NSI protocol if possible. I would also like to know all IP addresses of the servers attached to the end of circuits. Currently I have neither control plane nor dataplane ready. Could you please help with sorting this out. The FIA is already in progress and I was hoping to have the demo working by today morning. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

3 4

FIA Topo v1.2.owl
by Jerry Sobieski 24 Oct '11

24 Oct '11

Hi all- Here is version 1.3 of the topo file. Changes: - Converted uppercase urns to all lowercase (note- did not change the rdf:types...ex: NSNetwork types remain) - Added "locatedAt" relation to nsnetwork objects. These point to location objects with URN of: urn:ogf:network:nsnetwork:<NSNetwork>:location ex: urn:ogf:network:nsnetwork:geant.ets:location - Added "location" objects with the lat lon of each network - Changed KDDI Labs from Tokyo to Fujimino (changes the STP names in KDDI and Starlight respectively) Please, everyone validate their portion and let me know of any mistakes... as I did not run it through the SNE editor... Jerry

1 1

New OGF document "Firewall Traversal Protocol" in public comment
by Niederberger, Ralph 24 Oct '11

24 Oct '11

Dear all, The document " Firewall Traversal Protocol (FiTP)" has begun public comment on 2011-10-18. Description: Firewalls control traffic flows between internal and external communication partners. Mostly traffic from inside to outside is allowed, but traffic coming from outside must be explicitly configured. The rules which packets may traverse the firewall and which not are normally configured manually by firewall administrators. To speed up such kind of access list changes, it would be desirable to dynamically signal access requests and automatically change those access lists. Though some protocols are inspectable by firewalls already like FTP, SIP and H.323, a general protocol, which could be used for signaling dynamically required access rules, is not available until now. This paper proposes a standard protocol, which would allow such signaling in a secure manner. Firewalls which have installed a corresponding inspection module could be configured automatically, which would ease the configuration of such systems a lot. Please visit: http://www.ogf.org/gf/docs/comment.php?id=381 and consider reading and providing feedback. A brief affirmation is very useful to demonstrate community input and support. More detailed analysis is also, of course, welcome. All documents in public comment are accessible here: http://www.ogf.org/gf/docs/?public_comment Please also feel free to forward this email to further interested people, so that a maximum of feedback can be gained. Best regards Ralph Niederberger *************************************************** Ralph Niederberger Juelich Supercomputing Centre Institute for Advanced Simulation Phone: +49 2461 61-4772 Fax: +49 2461 61-6656 E-Mail: r.niederberger(a)fz-juelich.de WWW: http://www.fz-juelich.de/jsc/ JSC is the coordinator of the John von Neumann Institute for Computing and member of the Gauss Centre for Supercomputing *************************************************** Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ***************************************************

1 0

Demo at FIA
by Radek Krzywania 24 Oct '11

24 Oct '11

Hi all, I am already at FIA in Poznan, finalising demo stuff. Could someone send me the visualisation interface address for Google Earth? I would like to put it on the main screen. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

1 0

Groups and Labels
by Jeroen van der Ham 20 Oct '11

20 Oct '11

Hello, Yesterday in the call Jerry and I briefly touched on the issue of Groups and Labels in network topologies. After numerous discussions, it seems that Jerry and I still have opposing views, and we do not seem to be getting closer to a solution. This is why I'm raising this as a group issue, so that we can have a broader discussion on this. The issue at stake here is handling network connections with labels. Take for example a circuit from CERN, through USLHCNet, NLR, ending up in San Antonio. One end of the connection uses VLAN 3000, this is not available end-to-end, so it gets converted to VLAN 3067 along the way. My viewpoint is that this label is an essential part in the definition of an end-point of a connection. The end-point is defined both by the place in the network (URN), as well as the label VLAN 3067. Both these elements, point and label, must be indicated, and available to the pathfinder in order to optimally calculate a connection. This does not pose any restrictions on how that calculation and/or negotiation takes place, but at least that information is available. From what I understand, Jerry's viewpoint is that the label is *not* an essential part of the end-point definition. An end-point is in the network, and a Group of STPs is described that derive from that end-point, which implicitly encode the label through the mapping. The value of the label is available to the intra-domain manager, but not inter-domain. Inter-domain path calculation takes place without knowledge of the label, assignment of labels is done by the domains themselves. My problem with the latter approach is that it is virtually impossible to do pathfinding when you mix domains that can and cannot swap labels. In the example above the label is translated by a transit-domain. If the label is not available in the pathfinding process, the domains basically have to guess at which label to use. If it turns out not to work, the requesting agent is groping in the dark for another possibility. Almost all circuits that are being made currently use a label. The OSCARS interface supports the user defining a label in a request. OpenDRAC supports the user defining a label in a request. Other NRMs probably do also, so why would NSI not support this? Jeroen.

1 1

minutes from Wednesday's NSI conf call
by Guy Roberts 20 Oct '11

20 Oct '11

The minutes from yesterday's NSI conf call are available here: http://forge.gridforum.org/sf/go/doc16350?nav=1 Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

FIA demo topo v1.2
by Jerry Sobieski 20 Oct '11

20 Oct '11

Changes: - Removed link from GEANT to Netherlight, and removed associated STPs from topology - changed NSnetwork urns to lowercase nsnetwork - updated diagrams to reflect JGNX and GEANT changes - remove GRnet (not sure if they are able to participate...so made their perfSonar look like the others. - Added US LHCnet link from Netherlight to StarLight - updated some location info in the diagrams (Can someone confirm whether the GEANT should be located in Cambridge or in Paris?) - updated SOAP endpoints for Pionier, KRLight, KDDI, StarLight, GEANT,...

2 1

Issue 47 in ogf-nsi-project: Add WS-Secuirty policy definitions to WSDL for digital signing of NSI SOAP message
by ogf-nsi-project＠googlecode.com 19 Oct '11

19 Oct '11

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.Rio FixedInVersion-2.0 New issue 47 by jmacau...(a)gmail.com: Add WS-Secuirty policy definitions to WSDL for digital signing of NSI SOAP message http://code.google.com/p/ogf-nsi-project/issues/detail?id=47 Description of Issue: Need to validate the integrity of an NSI message as well as validate it is issued from the expected NSA. Discussion of Issue: It was previously agreed that the "transport layer" would digitally sign the NSI message to verify it was not tampered with, and is from the expected sender. This can be accomplished by using WS-Secuirty policy definitions in the WSDL. This mechanism is currently being used by OSCARS and is accepted as a common web service practice. Resolution of Issue: Add WS-Secuirty policy definitions to WSDL for digital signing of NSI SOAP message and NSA implement the solution.

1 0

Re: [Nsi-wg] Issue 1 in ogf-nsi-project: ConnectionStateType.TERMINATEING - maybe TERMINATING looks better
by ogf-nsi-project＠googlecode.com 19 Oct '11

19 Oct '11

Updates: Status: Fixed Comment #8 on issue 1 by jmacau...(a)gmail.com: ConnectionStateType.TERMINATEING - maybe TERMINATING looks better http://code.google.com/p/ogf-nsi-project/issues/detail?id=1 This issue was closed by revision r2.

1 4