This document is not as comprehensive as I would have liked, but I wanted to put on paper some of the rationale for the discussion that came up last week and has been discussed privately with Jerry over skype. Thanks, Inder -- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3> Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>
Hello, Please allow me to bundle my feedback on the identifier scheme discussion. A short summary of the issue as I see them currently: There needs to be a globally unique identifier for Service Termination Points. This id does not have to be related to a point in a network topology, but the local NSA must be able to map an STP id to a service and/or endpoint in the network. One possible solution: "The identifier can be just a string" I would strongly argue against this line of thought. Strings are not simple objects. There is a very valid reason why the definition of urn identifiers for OGF (and NML) takes up half a dozen pages. The construction and equality of strings is not trivial to define and should not be underestimated. I am very much in favor of urn-style identifiers similar in style to what GLIF is using currently, using urn:<identifier>:<network-name>:<localpart>. The <identifier> is the urn namespace, most easily is to use a subnamespace of the ogf, urn:ogf:nsi: springs to mind. The advantage of this is that it is easy to set up, constraints on content and equality are already provided and reasonably clear to users. The <network-name> can be the DNS namespace that the NSA represents. This also allows you to use a simple out-of-band verification of the NSA using DNS TXT records or something. The <localpart> can then be defined by the local NSA itself, and it has complete freedom to define this within the confines of the urn syntax limits as described for the namespace. The whole system allows for a very simple scheme that makes it immediately obvious what the identifier is for, and easily ensures global uniqueness. Knowing the purpose of the identifier is important because these will probably be used in many different contexts, as they are used as advertisement of the service. The identifiers may become a bit long, but given the fact that the NSI protocol seems to converge on XML as a dataformat, I do not feel that string-lengths is a problem. One last point on VLAN identification: I have seen some examples where the VLAN number is part of the identifier. There is also an argument for STPs to not map to the network topology so as to avoid a problem with 4095 different labels. As far as I know right now NML will not create labels for endpoints for each different VLAN, wavelength, timeslot or whatever. This should become a property of the object the identifier identifies, not part of the identifier itself. Jeroen.
Agree completely. jeff On Apr 14, 2011, at 8:15 AM, Jeroen van der Ham wrote:
Hello,
Please allow me to bundle my feedback on the identifier scheme discussion. A short summary of the issue as I see them currently: There needs to be a globally unique identifier for Service Termination Points. This id does not have to be related to a point in a network topology, but the local NSA must be able to map an STP id to a service and/or endpoint in the network.
One possible solution: "The identifier can be just a string" I would strongly argue against this line of thought. Strings are not simple objects. There is a very valid reason why the definition of urn identifiers for OGF (and NML) takes up half a dozen pages. The construction and equality of strings is not trivial to define and should not be underestimated.
I am very much in favor of urn-style identifiers similar in style to what GLIF is using currently, using urn:<identifier>:<network-name>:<localpart>.
The <identifier> is the urn namespace, most easily is to use a subnamespace of the ogf, urn:ogf:nsi: springs to mind. The advantage of this is that it is easy to set up, constraints on content and equality are already provided and reasonably clear to users.
The <network-name> can be the DNS namespace that the NSA represents. This also allows you to use a simple out-of-band verification of the NSA using DNS TXT records or something.
The <localpart> can then be defined by the local NSA itself, and it has complete freedom to define this within the confines of the urn syntax limits as described for the namespace.
The whole system allows for a very simple scheme that makes it immediately obvious what the identifier is for, and easily ensures global uniqueness. Knowing the purpose of the identifier is important because these will probably be used in many different contexts, as they are used as advertisement of the service.
The identifiers may become a bit long, but given the fact that the NSI protocol seems to converge on XML as a dataformat, I do not feel that string-lengths is a problem.
One last point on VLAN identification: I have seen some examples where the VLAN number is part of the identifier. There is also an argument for STPs to not map to the network topology so as to avoid a problem with 4095 different labels. As far as I know right now NML will not create labels for endpoints for each different VLAN, wavelength, timeslot or whatever. This should become a property of the object the identifier identifies, not part of the identifier itself.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Inder Monga -
Jeff W. Boote -
Jeroen van der Ham