My notes from today's call - on call were Joe Mambtetti, Chin Guok, Jerry Sobieski, Tomohiro Kudoh, and Guy Roberts. A number of people were at Terena conference and were unable to attend. 1. We discussed action points in minutes of NSI meetings in Chapel Hill last week. One discussion was about the need for an overall picture of how the groups -- NML, NSI and NMC - are related. Guy suggested a matrix showing which functions are used by which group. One specific function - topology sharing and aggregation - was discussed as being used by both NMC and NSI groups, and probably should be done a different group -- possibly NML. Some of the other functions were pathfinding, authentication, resource reservation. Others probably can be added to this. Chin mentioned as part of this discussion that he is working with others on an architecture document for DOE. Jerry asked if he could share this and Chin said he would like to and would see if there was any objection to sharing it with this group. 2. Another issue discussed was how monitoring and NSI - 2.1 a) Network Service is an abstract or virtual network which needs to be monitored just as a physical network needs monitoring. b) abstract network includes dynamic circuits that may cross several Network Services c) NS may include additional monitoring needs beyond what physical net needs - find complete ete circuit from a segment in a single NS - find problems in reserving creating and tearing down circuits caused by one of NS - NS has trust relations with other agents - these need monitoring 2.2 - a discussion of whether monitoring should be required- decision was that it was highly recommended by not required by NSI. Might be required to interconnect with other NS's - then - should a method be required if monitoring is done - consensus I think was that this was also not an NSI issue but again might be required to interoperate with other NSs 2.3 Question about what relation of Monitoring (NM and NMC) groups and NSI. Is monitoring interface specified by NSI or NM/ NMC? Discussion was that NSI should expose information. Some, at least, of the information as specified by NM and perhaps some unique to NS agent. Given that information is exposed, how is it transported from NS to others -- should it a) use NMC or other protocol or b) use some NSI protocol. I think the sense of the discussion was that it should use NMC (or other non NSI) protocol, but that exposing the info and defining the need to transport it should be defined in NSI. 3. We discussed the topology use cases I sent out. This was a lively discussion - I note a couple points a) A lot of discussion about what was actually carried between users at either end. We ended up defining a term (minted by Chin) "user service payload" to describe what is carried by an ete connection. I will call this USP at least for the next couple sentences. It became clear that the diagrams would be much clearer if they included some indication of what is being encapsulated in order to be carried on a segment. I note that a USP to be carried between edgepoints by a segment. Segments of the same technology may be cross connected. Segments that require different encapsulation require adaptation before cross connect is possible. I will modify these to incorporate USPs - I think also we should add it to the basic architecture section. We discussed sending this to NML group - I will pass revised doc to NSI for review before sending to NML. ---- We agreed to have "general" call every two weeks. - next June 24. We also agreed to have topic specific calls alternate weeks - next week to focus on Tomohiro tree/change diagram and details of how control plane requests interoperate. Please correct or comment -- John