Hi All- I hope you all had a nice well deserved and relaxing weekend. Alas, we must get started on the final stretch this year and prepare for the Supercomputing demos... (there must be some cosmic justice to the fact that "demonstration" begins with "demons"...) The focus for SC will be to consolidate, stabilize, and demonstrate our existing capabilities. So, our target topology will be the topology we used last week for FIA, plus any added GOLEs or Networks that participate. There are two ways to participate: a) as an NSI network running an NSA, or b) as a supporting organization that is willing to lend transport resources between these NSI networks or is willing to help write software tools, etc. I will acknowledge all organizations on the posters/handouts. ---> I want to freeze the topology by November 7th so that applications building off the diagrams don't have to keep fixing their graphics everytime someone realizes they want to participate...So if you want to be part of this, let me know ASAP. (That means yesterday!:-)) The fundamental objective of the SC demo is to set up circuits using NSI-CS across multiple domains and over real hardware. So each network will need to verify their 1) control plane interoperability with the other NSAs, and 2) insure that their data plane is properly configured between your network and your adjacent peer. Attached is the initial topology diagram and the associated .owl file for SC - SC2011-Topo-v1.0 Changes from latest FIA topo: - Added STPs for USLHCnet between NL and SL. For SC, we will again use only four VLANs on each link: 1780 to 1783. In some locations we may need to only use a subset of these depending upon how the NSAs are resolved by next week. Tasks: For the GOLE/network operators: pursue the following tasks: 1) Every network should have at least one end system that can be used to terminate circuits and that can issue and respond to IP layer Pings. This could be a perfSonar host with apropriate access provided to the demo team, or a small Linux or Mac, or possibly the switch processor itself. But we need something we can use to test to, and access to configure and verify the circuit. 2) Control plane: Begin testing immediately from your NSA to your neighbor's NSA to set up simple intra-domain Reservation Requests across your neighbor's network, and then progress to test inter-domain reservations across your network *and* your neighbor. THis is to insure proper and reliable interoperability between NSAs. Coordinate with your neighbor network (you all know the PoCs by now) to test. 3) Data plane: Ping test the connections to your neighbors' networks to insure the VLANs are clear channels between the NSI Networks. The crossconnects within your networks will never work if the static VLANs between networks are not operational first. So _/verify these VLANs/_ by manually placing an end system from each network on each VLAN, configuring the IP subnet, and pinging one another. For the code developers: 1) Make sure your hardware/NRM interfaces are working reliably. 2) Make sure you are able to deal with SOAP/HTTPS messaging. If you need to implement it - now is the time. If there are issues doing so, lets get those exposed so that we can resolve them. Monitor the nsi-wg chat on Skype... 3) Make sure the Query command is working properly. 4) Lets get the Query Agent, the MotherEarth (autoEarth) vizualizer, and the AIST-vizualizer working *RELIABLY*. You all should dive into this as soon as the SC WSDL interop, query interop, and HTTPS is working. This is the capstone task for this year!!! These visualizers will exercise and demonstrate all of the other great work we've accomplished. So let make these look good! Thanks all.... Any additions, corrections, thoughts, or comments, please post or send them to me and we'll integrate them into the task tracking... Two weeks till Showtime! Jerry