Hi John, Concerning your first point. I'm thinking of also adding a nml:name element to the nml:BidirectionalPort element as we have additional information in our administration already. It might not be used by tools right now, but it would also help topology administrators and users to find specific ports in the xml output. HansT. On 10/10/13 9:07 PM, John MacAuley wrote:
Peoples,
Given the painful experiences last week with respect to the demo topology, I thought I might capture some additional questions that popped into my head over the last couple of weeks. These are in addition to the issues raised during the NSI operationalization group update.
1. Useful topology identifiers and name elements - An NSA can manage more than one topology, and given how we will need to break up STP topologies based on the defined model, we will definitively have multiple topologies associated with an NSA in the short term. This means we need to have a more useful topology identifier than "urn:ogf:network:acme.org:2013:topology" or the more exciting "urn:ogf:network:acme.org:2013". Some people are encoding context into their URI so they type of URI is evident from the name "urn:ogf:network:acme.org:2013:topology:a-gole-testbed", whereas some are just using a unique name such as "urn:ogf:network:acme.org:2013:a-gole". In addition, it really helps to have the "name" element populated with a label you would like associated with your network when being displayed. Some of the visualization tools were using it as the primary display attribute. Something descriptive a relatively unique would help like "ACME A-GOLE Testbed".
2. There was still some mixup between the topology identifier and the NSA identifier. Remember the Topology identifier goes in the networkId field of the STP and it should be different from the NSA identifier.
3. Topology linkages - This is not the isAlias disaster relating to OpenNSA's new port identifier generation scheme, but instead, how we will relate and navigate through multiple topologies per NSA. I am hoping this will stabilize so we will not have additional churn.
John _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg