Hi all- Relative to our brief discussion last week about topology and the NSI... We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion. However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about. So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs. Comments are welcome...Its only a draft for consideration... Jerry While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.