Some notes on call below. We will have a "optional" next week and a regular call in two weeks. At the end of the meeting, after a number of people had already had to leave, there was some discussion of what is planned for the next meeting at OGF in Oct. The feeling among those present was that it would be good to have a first pass at an architecture document. This will be a topic for discussion in two weeks, and also for initial discussion next week. Some questions are the form of the document, the selection of topics and their current state, and what areas to focus on over the next couple months. Tentative agendas -- next week - Radek's pathfinding charts- combining with Guy's messaging and John's Path-handling diagram - initial discussion of document for next OGF two weeks - discuss document and plans for how to create it - other discussion to be determined Notes from today 1. Radek described his diagrams showing how path computation could be done in different ways. There was a lot of very good discussion to clarify. The intent of the diagrams is to show how initial paths are created. These are then used to request resources. Some questions - why does a network need to know internal paths of other networks? I think the answer was that it doesn't "have" to know, but it is allowed for this to be shared. - is this path computation part of request of separate? I believe that the intent is that it is separate, although I am still a little confused by how this works in some diagrams. - how does the ability to get "next hop" and "detailed path" play with topology sharing and path computation. Lots of discussion. I think this still needs to be worked out. Radek proposed that he modify the diagrams based on discussion to make a distinction between finding local data plane paths and general control plane paths. There was a question about how global data plane paths are found that he will consider. Radek had to leave after this discussion. 2. We had a lot of discussion about how topology is shared, and what must be shared for something to work. - Some discussion about how one finds out if a location is available. We discussed that the edgepoints would be described as URIs and that the URI would include information about the network/domain to which the edgepoint belongs. In addition a lookup service has been proposed that will allow a dns-like name to be mapped to its URI. This name might be used in the request and then NSA would use the lookup service to convert it to URI. - talked more about distinction between dataplane paths and control plane paths. They do not need to map to each other, and when finding a global route one may find a set of NSAs that can provide an interconnected dataplane path. The NSAs would then figure out the details of the route. - talked briefly about the distinction between route and topology. We referenced Radek's abstracted topology as example of topology and route being a sequence of edge points and hints about how the edgepoints are interconnected. Guy will try to fill out this distinction as part of the messaging he is working on. 3. There was some discussion about topology sharing and what is required and what is optional. Seems to be agreed that one must share edgepoints it wants others to know about. edgepoints that connect other networks are needed in topology, edgepoints that connect to end- devices are needed for reachability. It is not required that a NSA share everything with everybody. 4. At the tail end of the call we talked about the use cases I sent out. One question was whether these were intended to be controlled by NSA. The answer was that they are meant to be input to NML group in discussing adaptations, and don't have to be controlled. They do raise some interesting questions (as Jerry points out in his email earlier) that we may discuss later. There was some agreement and no disagreement that I heard for sending these to NML group for their discussion. I will send these. --- Please correct or comment on these. I am not sure I caught all the discussion. John