Hi Freek- you are essentially correct. But there is some added comments inline. On 6/27/12 6:00 PM, Freek Dijkstra wrote:
During today's call, Jerry brought up the following issue: (Jerry, please correct me if I'm wrong, and sorry if I mixed up the NSI with the NML terminology).
A path computation engine needs to know in which domain a STP lies. Bingo. At least for the inter-domain environment in which NSI operates.
There are solutions to this: 1. The domain can be inferred by parsing the URN identifier of the STP. 2. Each domain announces a full list of it's STPs, and the path computation engine keeps a table of all STP-Domain relations 3. Each connection request must not only list the URN of the STP, but the URN of the domain as well.
The current solution is (1), but that conflicts with the choice in NML that a URN may not contain the domain identifier and should not be interpreted/parsed. Solution (2) or (3) do not have this drawback. Solution (2) seems less scalable compared to solution (3). #1 was adopted by NSI WG in SLC last summer as an interim approach for v1 topology. A lot of issues were still unclear, so we took the interim step to use the simple DToX model (and we even needed to modify it a bit too.) Part of this decision included munging the 2-tuple STP name into a single URN string (this was not a unanimous approach - but it got us off the mark.) This #1 approach does require that NSA aggregators need to parse the STP URN to determine the home network - I am not strictly opposed to parsing an *NSI* STP name to decompose it into some structural components, but I do agree that parsing a *URN* specifically is counter to the purpose of a URN. And mapping any content or structure onto a URN besides administrative scoping is almost always a bad idea. (I think some v1.x implementations cheated with this approach and used the RDF topology as a directory to look up STP URNs to get name-domain mappings...while this avoided parsing the URN, it is not strictly conformant to the NSI framework and breaks if the STPs are not all defined in the topology. The NSI framework will work as long as the STP 2-tuples are used for STP references. )
#2 is essentially a directory service - whether your distribute STPs as part of the topology or as a separate phonebook, you have the same problem: All STPs must be defined and announced in this global directory before they can be used in a Reservation Request. This phonebook/directory service is computationally tractable, but it nonetheless has scalability issues for a global inter-domain service like NSI. It is centralized (bad), or it is distributed (requiring complex protocol to keep it coherent and convergent.) And frankly, for simple end system STPs it is unnecessary as long as the STP reference includes the network id innately - which it currently does. Unless we want a flat name space without hierarchical structure, then our 2-tuple model provides a basic hierarchical interdomain mapping that precludes the need for a global STP directory service. I would phrase #3 a bit differently: The STP name is already and *by definition* a 2-tuple consisting of the network (domain) identifier and a local identifier. These two elements together comprise the STP name. I would suggest that an STP reference might be a compound object ala: <stp_ref> <net_id>nordu.net</net_id> <loc_id>svr1-1-204</loc_id> </stp_ref> This #3 is (IMO) the best solution. It explicitly delineates the <networkid> component from the <localid> component - which means parsing a single string or URN is not required, and the name-domain mapping is explicit in the reference precluding the need for a directory. With the compound reference, as long as the network can be found in the topology, the NSI PF does not need to know specifically how to route to the local end point. the local NSA will resolve that internally. I would surmise that this compound STP object could still be given a URN, which would make it useable within the current RDF/OWL topology. But this then would re-introduce the need for directories. The aspect that I like about #3 using the compound reference is that it allows us to separate the naming of objects internal to the NSI code implementations from the names that users and engineers may wish to use to identify their networks and end points more generally and which users will wish to use when specifiying their requests. The URNs for user interfacing are horrid. One last observation: By referencing STPs as compound objects we obviate the need for global directories. We also do not need to define STPs globaly if/when they only have local significance. (An STP is "only locally significant" if it does not share an SDP with another network.) Thus we don't need to advertise these local only end point names in topology as the path finders get what they need from the STP reference itself. However, this *does not* preclude the need to advertise STPs that *are* part of an NSI SDP adjacency(!!). These adjacencies must still be advertised as part of the topology - indeed, these SDPs define the topology, the inter-connectivity among networks. Hope this helps! Have a nice weekend! Jerry
Regards, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg