Hi, We need to take a decision regarding the identifiers used for STPs and other elements. The NML-WG has taken upon itself to register the urn:ogf:network subnamespace, and to make it available for the identification of network resources. The group is currently writing a document describing how that should be used. The current accepted proposal is the following form: urn:ogf:network:example.com:2012:opaque:part So after the urn:ogf:network part comes the DNS name of the organisation defining the identifier, followed by the four digit year in which the identifier was created, followed by a local part. The current Automated GOLE uses identifiers of the form below, which is not compatible: urn:ogf:network:stp:example.ets:opaque:part We have a couple of options going forward: - use identifiers following NML-WG standard a) allow domain owners free form in the opaque part b) define that opaque part should begin with "stp:" - try to register a different urng:ogf subnamespace Note that the last option is not that simple. We have to propose a scheme that will ensure indefinite uniqueness, which would probably be something very closely resembling the NML-WG scheme. Jeroen.
Jeroen van der Ham wrote:
We have a couple of options going forward:
- use identifiers following NML-WG standard a) allow domain owners free form in the opaque part b) define that opaque part should begin with "stp:" - try to register a different urng:ogf subnamespace
My personal ideal [*] would be (a), thus NSI saying "here is a list of STP" and just giving a list of identifiers, without many syntax restrictions. (And I would be thrilled if that identifier could be a NML Port, thus that a NSI STP is a NML Port, but that is a different discussion.) That said, I haven't implemented an NSI interface, so feel free to ignore me :) Freek [*] Well, I have some more ideals, but that's probably out of scope for NSI :)
I concur with Freek. Cheers, Aaron On Jun 12, 2012, at 10:16 AM, Freek Dijkstra wrote:
Jeroen van der Ham wrote:
We have a couple of options going forward:
- use identifiers following NML-WG standard a) allow domain owners free form in the opaque part b) define that opaque part should begin with "stp:" - try to register a different urng:ogf subnamespace
My personal ideal [*] would be (a), thus NSI saying "here is a list of STP" and just giving a list of identifiers, without many syntax restrictions.
(And I would be thrilled if that identifier could be a NML Port, thus that a NSI STP is a NML Port, but that is a different discussion.)
That said, I haven't implemented an NSI interface, so feel free to ignore me :)
Freek
[*] Well, I have some more ideals, but that's probably out of scope for NSI :) _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
If the NSI two-tuple <networkid>:<localid> STP name is preserved in the NML naming convention, then I think it is possible to use the NML convention with maybe some minor mods... However, I have some concerns about the NML convention in this respect: Q1.) Is the proposed NML naming convention "urn:ogf:network:<DNSname>:<year>:<opaque part>" used for all topological objects? Or is it *only* for naming STPs? Q1.b) Is "urn:ogf:network:" now to be used solely for NML topology? or will that namesapce be available for naming other objects or subspaces related to other aspects of grid networking in general? Q2.) Is it *required* that the NML naming element that follows "network" be specifically a DNS domain name? I.e. Why does NML require a DNS name? In essence, the *DNS requirement* makes the the domain naming registry the authority that guarantees uniqueness for OGF URNs. right? Further, requiring DNS names makes it difficult for end users to name their own network(s) as not every STP resides where a DNS name is clear or appropriate or valid. Q2.b) Since NSI Networks are "service domains" rather than comprehensive hardware infrastructure, they may not map directly or uniquely to specific DNS domains. For instance, there is nothing preventing a number of collaborating organizations from pooling their resources into a single NSI Network service domain. How would the DNS mapping be applied in this scenario? Q3.) What does the DNS name level represent in terms of NML? I.e. why have it at all ? What are the NML requirements for object names that requires DNS names in them (or the year value that follows the DNS element..) Q4.) There is a <year> following the DNS element in the NML convention. Why? In particular, what authority is responsible for naming topological objects under a "ogf:network:<DNS name>:" name space? Is this truly necessary? This feels rather convoluted and questionable... - we certainly do not need it for the NSI naming... Comments? Jerry On 6/12/12 9:05 AM, Jeroen van der Ham wrote:
Hi,
We need to take a decision regarding the identifiers used for STPs and other elements.
The NML-WG has taken upon itself to register the urn:ogf:network subnamespace, and to make it available for the identification of network resources. The group is currently writing a document describing how that should be used. The current accepted proposal is the following form:
urn:ogf:network:example.com:2012:opaque:part
So after the urn:ogf:network part comes the DNS name of the organisation defining the identifier, followed by the four digit year in which the identifier was created, followed by a local part.
The current Automated GOLE uses identifiers of the form below, which is not compatible:
urn:ogf:network:stp:example.ets:opaque:part
We have a couple of options going forward:
- use identifiers following NML-WG standard a) allow domain owners free form in the opaque part b) define that opaque part should begin with "stp:" - try to register a different urng:ogf subnamespace
Note that the last option is not that simple. We have to propose a scheme that will ensure indefinite uniqueness, which would probably be something very closely resembling the NML-WG scheme.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, Let me quickly answer your questions: On 13 Jun 2012, at 14:54, Jerry Sobieski wrote:
If the NSI two-tuple <networkid>:<localid> STP name is preserved in the NML naming convention, then I think it is possible to use the NML convention with maybe some minor mods...
However, I have some concerns about the NML convention in this respect:
Q1.) Is the proposed NML naming convention "urn:ogf:network:<DNSname>:<year>:<opaque part>" used for all topological objects? Or is it *only* for naming STPs?
This is meant for all topological objects.
Q1.b) Is "urn:ogf:network:" now to be used solely for NML topology? or will that namesapce be available for naming other objects or subspaces related to other aspects of grid networking in general?
It is not restricted to NML topologies, it is meant for all kinds of things you want to identify in networking objects. The NML group is just taking the initiative in registering this subnamespace.
Q2.) Is it *required* that the NML naming element that follows "network" be specifically a DNS domain name? I.e. Why does NML require a DNS name? In essence, the *DNS requirement* makes the the domain naming registry the authority that guarantees uniqueness for OGF URNs. right? Further, requiring DNS names makes it difficult for end users to name their own network(s) as not every STP resides where a DNS name is clear or appropriate or valid.
Yes, this is defined in the syntactic structure required by this namespace. The definition of this structure is require when you register a urn (sub)namespace. It is the method that we defined as the way to guarantee uniqueness. We do not foresee problems with end-users who own a large enough network to use this, yet not having a DNS name.
Q2.b) Since NSI Networks are "service domains" rather than comprehensive hardware infrastructure, they may not map directly or uniquely to specific DNS domains. For instance, there is nothing preventing a number of collaborating organizations from pooling their resources into a single NSI Network service domain. How would the DNS mapping be applied in this scenario?
That would be up to those organisations to figure out. They have been able to somehow align their policies, part of that will probably also be to figure out a DNS name for it. In practice you almost always see that such an organisation would have a DNS name of its own (e.g., GLIF, Geant).
Q3.) What does the DNS name level represent in terms of NML? I.e. why have it at all ? What are the NML requirements for object names that requires DNS names in them (or the year value that follows the DNS element..) Q4.) There is a <year> following the DNS element in the NML convention. Why? In particular, what authority is responsible for naming topological objects under a "ogf:network:<DNS name>:" name space? Is this truly necessary? This feels rather convoluted and questionable... - we certainly do not need it for the NSI naming...
It is a very simple method for guaranteeing uniqueness, without requiring the creation of a new central registry. The year is in there because it is possible that DNS names change hands. This ensures that an organisation that acquires the DNS name does not end up with a polluted namespace. DNS changeover processes for these kinds of organisations take usually many months, or years even, so we did not think it was necessary to add further timestamp information. Jeroen.
THanks Jeroen! I figured the DNS thing was for uniqueness. What happened to using the funky web service convention for generating unique strings? :-) As for yearly timestamps - this seems completely out in left field. That should be the purvue of the current owner to decide their structure unless it is critical to the NML topology descriptions to know what year an object name was created. I think this pollutes an otehrwise usable naming convention. It could be *suggested* ...but it complicates things unnecessarilly and is out of scope for NML (IMHO). Besides there is no way to enforce it. I would suggest NML should decide what the :network: hierarchy formally represents. Not the specific names, but the hierarchical structure. This should dictate the format of the structure ... does the structure represent an annual hierarchy?? :-) I still think the year component is extraneous and should be removed. Thanks again! Jerry On 6/13/12 9:13 AM, Jeroen van der Ham wrote:
Hi,
Let me quickly answer your questions:
On 13 Jun 2012, at 14:54, Jerry Sobieski wrote:
If the NSI two-tuple<networkid>:<localid> STP name is preserved in the NML naming convention, then I think it is possible to use the NML convention with maybe some minor mods...
However, I have some concerns about the NML convention in this respect:
Q1.) Is the proposed NML naming convention "urn:ogf:network:<DNSname>:<year>:<opaque part>" used for all topological objects? Or is it *only* for naming STPs? This is meant for all topological objects.
Q1.b) Is "urn:ogf:network:" now to be used solely for NML topology? or will that namesapce be available for naming other objects or subspaces related to other aspects of grid networking in general? It is not restricted to NML topologies, it is meant for all kinds of things you want to identify in networking objects. The NML group is just taking the initiative in registering this subnamespace.
Q2.) Is it *required* that the NML naming element that follows "network" be specifically a DNS domain name? I.e. Why does NML require a DNS name? In essence, the *DNS requirement* makes the the domain naming registry the authority that guarantees uniqueness for OGF URNs. right? Further, requiring DNS names makes it difficult for end users to name their own network(s) as not every STP resides where a DNS name is clear or appropriate or valid. Yes, this is defined in the syntactic structure required by this namespace. The definition of this structure is require when you register a urn (sub)namespace. It is the method that we defined as the way to guarantee uniqueness. We do not foresee problems with end-users who own a large enough network to use this, yet not having a DNS name.
Q2.b) Since NSI Networks are "service domains" rather than comprehensive hardware infrastructure, they may not map directly or uniquely to specific DNS domains. For instance, there is nothing preventing a number of collaborating organizations from pooling their resources into a single NSI Network service domain. How would the DNS mapping be applied in this scenario? That would be up to those organisations to figure out. They have been able to somehow align their policies, part of that will probably also be to figure out a DNS name for it. In practice you almost always see that such an organisation would have a DNS name of its own (e.g., GLIF, Geant).
Q3.) What does the DNS name level represent in terms of NML? I.e. why have it at all ? What are the NML requirements for object names that requires DNS names in them (or the year value that follows the DNS element..) Q4.) There is a<year> following the DNS element in the NML convention. Why? In particular, what authority is responsible for naming topological objects under a "ogf:network:<DNS name>:" name space? Is this truly necessary? This feels rather convoluted and questionable... - we certainly do not need it for the NSI naming... It is a very simple method for guaranteeing uniqueness, without requiring the creation of a new central registry. The year is in there because it is possible that DNS names change hands. This ensures that an organisation that acquires the DNS name does not end up with a polluted namespace. DNS changeover processes for these kinds of organisations take usually many months, or years even, so we did not think it was necessary to add further timestamp information.
Jeroen.
Jerry Sobieski wrote:
Q1.) Is the proposed NML naming convention "urn:ogf:network:<DNSname>:<year>:<opaque part>" used for all topological objects? Or is it *only* for naming STPs?
It will be used for all topological objects.
Q1.b) Is "urn:ogf:network:" now to be used solely for NML topology? or will that namespace be available for naming other objects or subspaces related to other aspects of grid networking in general?
Other objects may use the "urn:ogf:network" namespace. The urn:ogf:network specification formally only defines a procedure to generate a persistent, globally unique identifiers, with minimal risk of name collisions, and without creating a new registry. It is recommended that these identifiers are used for identifying network objects, but if someone likes to give a urn:ogf:network identifier to his newborn child, I will not sue :)
Q2.) Is it *required* that the NML naming element that follows "network" be specifically a DNS domain name? I.e. Why does NML require a DNS name? In essence, the *DNS requirement* makes the the domain naming registry the authority that guarantees uniqueness for OGF URNs. right? Further, requiring DNS names makes it difficult for end users to name their own network(s) as not every STP resides where a DNS name is clear or appropriate or valid.
The *combination of DNS and date* (typically a year, but it was suggested that year+month or year+month+day should be allowed too) is a easy way to create a persistent globally unique prefix to denote a registry ("namespace organisation" according to GFD.191). So the DNS name + year combination identifies an organisation, not a network element. We think that this is an easy requirement for an organisation, and less hassle than setting up a formal registry where users (including end users) can register a namespace.
Q2.b) Since NSI Networks are "service domains" rather than comprehensive hardware infrastructure, they may not map directly or uniquely to specific DNS domains. For instance, there is nothing preventing a number of collaborating organizations from pooling their resources into a single NSI Network service domain. How would the DNS mapping be applied in this scenario?
See above. Again, all that the DNS + year combination does is create a globally unique, persistent prefix. It has no other meaning. The only implication of "urn:ogf:network:chucknorriskicksass.com:2008:18348975" is that whoever assigned it was administrative owner of the domain name in 2008. It does not imply that it still owned by the same person, or that the resource in question has anything to do with said domain.
Q3.) What does the DNS name level represent in terms of NML? I.e. why have it at all ? What are the NML requirements for object names that requires DNS names in them (or the year value that follows the DNS element..)
NML only requires that if an object is given an identifier, that identifier is globally unique (thus not used before) and persisten (thus will not be used again for something else). This identifier MAY (SHOULD?) be a urn:ogf:network namespace, but it is likely not a MUST. The urn:ogf:network thing is only there to make it easy to create such globally unique, persistent identifier. So once an object has been given an identifier, that identifier sticks. The identifier will always point to that resource, even if it's properties change, is decommissioned or whoever assigned that identifier runs out of business.
Q4.) There is a <year> following the DNS element in the NML convention. Why? In particular, what authority is responsible for naming topological objects under a "ogf:network:<DNS name>:" name space? Is this truly necessary? This feels rather convoluted and questionable... - we certainly do not need it for the NSI naming...
The year (actually: date) is intrinsic part of the combination of DNS + Year that uniquely identifies the organisation that assign identifiers. It is added the the DNS name to prevent the situation where an organisation runs out of business and the DNS registration if handed out to another organisation who subsequently also likes to assign URNs. Regards, Freek
Hi Jeroen et al- First a minor nit: the current NSI form is "urn:ogf:network:stp:<networkname>:<local part>" . I.e. there is no "opaque" multilevel subspace under the <networkname> component in STPs. More importantly, Our desire is to develop a naming convention that is compatible with both NML *and* NSI - so it may be that we need to modify the NML naming convention instead (or also)... we need to look at both. so keep an open mind how this is best reconciled. Step 1.) It seems to me the preliminary issue to be resolved is the actual object mappings. We have had some preliminary discussion on this that I think poses a good starting point... Step 2) Then we need to develop some NML topology examples that replicate the current NSI topologies. This will provide concrete examples of how the existing [working] topology constructs will be represented in NML. Step 3) Then we need to analyze how NSI would work processing these new NML examples, and where it breaks. And we resolve those issues by changing the NML construct, or by changing the NSI functionality - or a combination of both. A basic question occurs to me: Why do names need to be consistent within NSI and NML? What breaks if NSI maintains its current naming scheme? The NSI protocol needs to be able to map an STP to its home NSI network. The current NSI CS 1.1 specification describes the two-tuple <networkid>:<localid> STP name implemented as a URN. It stipulates that the home network is identified by the network name portion found in the STP reference. Due to the current dtox topology that is informaly being used by the NSI implementations, the network associated with an STP can also be found by looking up the STP in the topology DB and linking to the NSI Network object. THis works fine, but to be clear - it is an artifact of the dtox topology, not NSI standard. Thus the lookup mechanism may not be used or even work in all NSI implementations. Thus we need to maintain the two-tuple NSI STP. ...but this could be encoded in a URN an other ways... My concern with the lookup mechanism is that it requires STPs be present in the topology db in order to determine which network they belong to. Implicitly, this requires all STPs to be advertised in the global topology. Indeed, this means *_/all/_* STPs- including simple end system STPs that are not members of any SDP. However, NSI CS does not require any topological knowledge of simple STPs - NSI only needs to know in which network an STP resides and any adjacencies to that network to choose the egress point. This is sufficient to segment the request and to perform path finding. Thus there is no current requirement for ALL STPs to be announced - only those that are part of an SDP (the adjacencies.) One can imagine that the simple end system STPs will out number SDPs in most networks - probably by orders of magnitude (consider how a campus/data center might fanout one or two WAN links to hundreds or thousands of possible end systems.) Given the number of virtual endpoints we will have globally - even with a compact syntactic enumeration of STPs - this amounts to a significant(!) amount of topology data that is not strictly necessary and will only rarely be referenced. A more efficient system would simply announce NSI Networks and their adjacencies (SDPs). All STP references would implicitly resolve to the network contained in their name. Thus a user could specify a STP that he knows is available locally, but which had not been announced to the world, and the NSAs will successfully segment and reserve the connection. I believe the NSI hierarchical two-tuple <networkid>:<localid> must be maintained as we reconcile the NML form to NSI. I think this will prove high useful in both path finding and topology distribution. It seems to me the <DNS> requirement for the NML name could be relaxed slightly to be a bit more flexible for NSI network name requirements without undue harm to NML. I suggest that there is no need to name STPs with a year component - this should be removed. (Why is it even required for NML?) I actually think I like the possbly multi-level <opaque part> in the NML spec if we make some stipulations about its construction for STP names. I pose for discussion the prospect of a subspace - either ...:ogf:network:nsi: , or a sibling ...:ogf:nsi: that we could use to identify specific NSI names. Could these maybe be used to reference NML objects directly or indirectly? THus allowing NSI to maintain its current naming structure under a different subspace....? As a related issue, we also need to decide what that distribution process ought to be. Thoughts? Jerry On 6/12/12 9:05 AM, Jeroen van der Ham wrote:
Hi,
We need to take a decision regarding the identifiers used for STPs and other elements.
The NML-WG has taken upon itself to register the urn:ogf:network subnamespace, and to make it available for the identification of network resources. The group is currently writing a document describing how that should be used. The current accepted proposal is the following form:
urn:ogf:network:example.com:2012:opaque:part
So after the urn:ogf:network part comes the DNS name of the organisation defining the identifier, followed by the four digit year in which the identifier was created, followed by a local part.
The current Automated GOLE uses identifiers of the form below, which is not compatible:
urn:ogf:network:stp:example.ets:opaque:part
We have a couple of options going forward:
- use identifiers following NML-WG standard a) allow domain owners free form in the opaque part b) define that opaque part should begin with "stp:" - try to register a different urng:ogf subnamespace
Note that the last option is not that simple. We have to propose a scheme that will ensure indefinite uniqueness, which would probably be something very closely resembling the NML-WG scheme.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, That's a very long reply which I'll take as support for option 2, define a new subnamespace for NSI. I will respond to your questions in another thread. Jeroen. On 13 Jun 2012, at 15:38, Jerry Sobieski wrote:
Hi Jeroen et al-
First a minor nit: the current NSI form is "urn:ogf:network:stp:<networkname>:<local part>" . I.e. there is no "opaque" multilevel subspace under the <networkname> component in STPs.
More importantly, Our desire is to develop a naming convention that is compatible with both NML *and* NSI - so it may be that we need to modify the NML naming convention instead (or also)... we need to look at both. so keep an open mind how this is best reconciled.
Step 1.) It seems to me the preliminary issue to be resolved is the actual object mappings. We have had some preliminary discussion on this that I think poses a good starting point...
Step 2) Then we need to develop some NML topology examples that replicate the current NSI topologies. This will provide concrete examples of how the existing [working] topology constructs will be represented in NML.
Step 3) Then we need to analyze how NSI would work processing these new NML examples, and where it breaks. And we resolve those issues by changing the NML construct, or by changing the NSI functionality - or a combination of both.
A basic question occurs to me: Why do names need to be consistent within NSI and NML? What breaks if NSI maintains its current naming scheme?
The NSI protocol needs to be able to map an STP to its home NSI network. The current NSI CS 1.1 specification describes the two-tuple <networkid>:<localid> STP name implemented as a URN. It stipulates that the home network is identified by the network name portion found in the STP reference.
Due to the current dtox topology that is informaly being used by the NSI implementations, the network associated with an STP can also be found by looking up the STP in the topology DB and linking to the NSI Network object. THis works fine, but to be clear - it is an artifact of the dtox topology, not NSI standard. Thus the lookup mechanism may not be used or even work in all NSI implementations. Thus we need to maintain the two-tuple NSI STP. ...but this could be encoded in a URN an other ways...
My concern with the lookup mechanism is that it requires STPs be present in the topology db in order to determine which network they belong to. Implicitly, this requires all STPs to be advertised in the global topology. Indeed, this means *_/all/_* STPs- including simple end system STPs that are not members of any SDP. However, NSI CS does not require any topological knowledge of simple STPs - NSI only needs to know in which network an STP resides and any adjacencies to that network to choose the egress point. This is sufficient to segment the request and to perform path finding. Thus there is no current requirement for ALL STPs to be announced - only those that are part of an SDP (the adjacencies.)
One can imagine that the simple end system STPs will out number SDPs in most networks - probably by orders of magnitude (consider how a campus/data center might fanout one or two WAN links to hundreds or thousands of possible end systems.) Given the number of virtual endpoints we will have globally - even with a compact syntactic enumeration of STPs - this amounts to a significant(!) amount of topology data that is not strictly necessary and will only rarely be referenced.
A more efficient system would simply announce NSI Networks and their adjacencies (SDPs). All STP references would implicitly resolve to the network contained in their name. Thus a user could specify a STP that he knows is available locally, but which had not been announced to the world, and the NSAs will successfully segment and reserve the connection.
I believe the NSI hierarchical two-tuple <networkid>:<localid> must be maintained as we reconcile the NML form to NSI. I think this will prove high useful in both path finding and topology distribution.
It seems to me the <DNS> requirement for the NML name could be relaxed slightly to be a bit more flexible for NSI network name requirements without undue harm to NML.
I suggest that there is no need to name STPs with a year component - this should be removed. (Why is it even required for NML?)
I actually think I like the possbly multi-level <opaque part> in the NML spec if we make some stipulations about its construction for STP names.
I pose for discussion the prospect of a subspace - either ...:ogf:network:nsi: , or a sibling ...:ogf:nsi: that we could use to identify specific NSI names. Could these maybe be used to reference NML objects directly or indirectly? THus allowing NSI to maintain its current naming structure under a different subspace....?
As a related issue, we also need to decide what that distribution process ought to be.
Thoughts? Jerry
On 6/12/12 9:05 AM, Jeroen van der Ham wrote:
Hi,
We need to take a decision regarding the identifiers used for STPs and other elements.
The NML-WG has taken upon itself to register the urn:ogf:network subnamespace, and to make it available for the identification of network resources. The group is currently writing a document describing how that should be used. The current accepted proposal is the following form:
urn:ogf:network:example.com:2012:opaque:part
So after the urn:ogf:network part comes the DNS name of the organisation defining the identifier, followed by the four digit year in which the identifier was created, followed by a local part.
The current Automated GOLE uses identifiers of the form below, which is not compatible:
urn:ogf:network:stp:example.ets:opaque:part
We have a couple of options going forward:
- use identifiers following NML-WG standard a) allow domain owners free form in the opaque part b) define that opaque part should begin with "stp:" - try to register a different urng:ogf subnamespace
Note that the last option is not that simple. We have to propose a scheme that will ensure indefinite uniqueness, which would probably be something very closely resembling the NML-WG scheme.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (4)
-
Aaron Brown -
Freek Dijkstra -
Jeroen van der Ham -
Jerry Sobieski