NSI Topology extensions document
Hi, The NSI Topology extensions document is in a separate Redmine project: https://redmine.ogf.org/projects/nsi-wg-topology Join that project, and then you can use this page to check out/explore the git repository: https://redmine.ogf.org/projects/nsi-wg-topology/repository Jeroen.
If that does not work for you, you can also get a copy from: https://github.com/jeroenh/NSI-Topology.git Jeroen. On 18 Dec 2013, at 16:43, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
The NSI Topology extensions document is in a separate Redmine project:
https://redmine.ogf.org/projects/nsi-wg-topology
Join that project, and then you can use this page to check out/explore the git repository: https://redmine.ogf.org/projects/nsi-wg-topology/repository
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi Had a look at the updates. On Wed, 18 Dec 2013, Jeroen van der Ham wrote:
The NSI Topology extensions document is in a separate Redmine project:
https://redmine.ogf.org/projects/nsi-wg-topology
Join that project, and then you can use this page to check out/explore the git repository: https://redmine.ogf.org/projects/nsi-wg-topology/repository
nsi:Service -> nsi:Interface rename. I cannot recall dicussing this on the call. It doesn't really matter, but it is difficult to see why this had to be renamed. Both terms are overloaded anyway, but usually I associate interface with something slightly more abstract. The schemas/test2.xml is (very) outdated. I suggest removing it. I would - very much - like to have xs:any under the nsi:NSA (I was actually under the impression that it was there already). It is also a bit weird of us to complain about NML not having them, and not adding them ourselves. Here is a patch: --- a/schemas/nsi-ext.xsd +++ b/schemas/nsi-ext.xsd @@ -47,6 +47,9 @@ <xs:element ref="nsi:Interface" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nsi:Relation" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nml:Topology" minOccurs="0" maxOccurs="unbounded"/> + <!-- the local one is needed for xmllint to not complain about determinism --> + <xs:any namespace="##local" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> + <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> There is a bug in libxml2 that will complain about the model not being deterministic when not having the local there. It is actually, but since a lot of people use libxml2, I've added the local element. Since we added the labelType in the SwitchingService, I think it should be in the example. Will the namespaces by updated? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 19 Dec 2013, at 12:26, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Had a look at the updates.
Thanks.
On Wed, 18 Dec 2013, Jeroen van der Ham wrote:
nsi:Service -> nsi:Interface rename. I cannot recall dicussing this on the call. It doesn't really matter, but it is difficult to see why this had to be renamed. Both terms are overloaded anyway, but usually I associate interface with something slightly more abstract.
This is something that John changed, I just copied it in because I did not follow all NSI calls lately.
The schemas/test2.xml is (very) outdated. I suggest removing it.
Done.
I would - very much - like to have xs:any under the nsi:NSA (I was actually under the impression that it was there already). It is also a bit weird of us to complain about NML not having them, and not adding them ourselves. Here is a patch:
--- a/schemas/nsi-ext.xsd +++ b/schemas/nsi-ext.xsd @@ -47,6 +47,9 @@ <xs:element ref="nsi:Interface" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nsi:Relation" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nml:Topology" minOccurs="0" maxOccurs="unbounded"/> + <!-- the local one is needed for xmllint to not complain about determinism --> + <xs:any namespace="##local" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> + <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent>
Doesn’t the inheritance from NetworkObject already include the xs:any ? Or does that get lost in the change?
There is a bug in libxml2 that will complain about the model not being deterministic when not having the local there. It is actually, but since a lot of people use libxml2, I've added the local element.
Sounds good to me.
Since we added the labelType in the SwitchingService, I think it should be in the example.
Good point, do you have an example?
Will the namespaces by updated?
Yes, the namespace will be updated to the date of publication of the document (as happened with NML). I have not updated them yet, because I have no idea when this would happen.
One more thing. I think we discussed - and perhaps decided - to an NSI extension for capacity on the ports. AFAICT that isn't it currently; I think we should consider adding it.
Iirc that depended on adding an attribute to a Port, which I’m not sure how to do in an extension schema. Jeroen.
Hi On Fri, 20 Dec 2013, Jeroen van der Ham wrote:
The schemas/test2.xml is (very) outdated. I suggest removing it.
Done.
Did you forgot to push this?
I would - very much - like to have xs:any under the nsi:NSA (I was actually under the impression that it was there already). It is also a bit weird of us to complain about NML not having them, and not adding them ourselves. Here is a patch:
--- a/schemas/nsi-ext.xsd +++ b/schemas/nsi-ext.xsd @@ -47,6 +47,9 @@ <xs:element ref="nsi:Interface" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nsi:Relation" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nml:Topology" minOccurs="0" maxOccurs="unbounded"/> + <!-- the local one is needed for xmllint to not complain about determinism --> + <xs:any namespace="##local" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> + <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent>
Doesn’t the inheritance from NetworkObject already include the xs:any ?
One should think so. It is certainly possible that it is just libxml2/xmllint which is buggy here, but it didn't validate for me. My xsd-foo is too weak to really give a proper answer to this.
There is a bug in libxml2 that will complain about the model not being deterministic when not having the local there. It is actually, but since a lot of people use libxml2, I've added the local element.
Sounds good to me.
Since we added the labelType in the SwitchingService, I think it should be in the example.
Good point, do you have an example?
Possibly: <nml:Topology id="urn:ogf:network:...."> ... <nml:SwitchingService id="urn:ogf:network:example.net:2012:nodeA:switchingService" labelSwapping="true" labelType="http://schemas.ogf.org/nml/2012/10/ethernet#vlan"> ... I hope this is right.
Will the namespaces by updated?
Yes, the namespace will be updated to the date of publication of the document (as happened with NML). I have not updated them yet, because I have no idea when this would happen.
Ok.
One more thing. I think we discussed - and perhaps decided - to an NSI extension for capacity on the ports. AFAICT that isn't it currently; I think we should consider adding it.
Iirc that depended on adding an attribute to a Port, which I’m not sure how to do in an extension schema.
Well, you cannot really define a new type, as the would make something is not longer an NML port. I think the way is to define an attribute in nsi-ext.xsd , like this: + + <!-- capacity of a port, attribute for Port and PortGroup --> + <xs:attribute name="capacity" /> + Doing this: <nml:PortGroup id="urn:ogf:network:aruba.net:ps-out" nsi:capacity="1000"> Is okay with xmllint at least. But I don't really know if this is the correct way of doing things. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 8 Jan 2014, at 11:19, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Since we added the labelType in the SwitchingService, I think it should be in the example.
Good point, do you have an example?
Possibly:
<nml:Topology id="urn:ogf:network:...."> ... <nml:SwitchingService id="urn:ogf:network:example.net:2012:nodeA:switchingService" labelSwapping="true" labelType="http://schemas.ogf.org/nml/2012/10/ethernet#vlan"> ...
I hope this is right.
It is, I’ve included it in the XML example. I have also updated the OWL example so that it matches the document again.
One more thing. I think we discussed - and perhaps decided - to an NSI extension for capacity on the ports. AFAICT that isn't it currently; I think we should consider adding it.
Iirc that depended on adding an attribute to a Port, which I’m not sure how to do in an extension schema.
Well, you cannot really define a new type, as the would make something is not longer an NML port. I think the way is to define an attribute in nsi-ext.xsd , like this:
+ + <!-- capacity of a port, attribute for Port and PortGroup --> + <xs:attribute name="capacity" /> +
I’m leaving the XML schema things open until I get confirmation from another XML expert that this does what is intended :) Jeroen.
I will have a look at the changes tomorrow. Packed full today :-) On 2014-01-08, at 9:15 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
On 8 Jan 2014, at 11:19, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Since we added the labelType in the SwitchingService, I think it should be in the example.
Good point, do you have an example?
Possibly:
<nml:Topology id="urn:ogf:network:...."> ... <nml:SwitchingService id="urn:ogf:network:example.net:2012:nodeA:switchingService" labelSwapping="true" labelType="http://schemas.ogf.org/nml/2012/10/ethernet#vlan"> ...
I hope this is right.
It is, I’ve included it in the XML example. I have also updated the OWL example so that it matches the document again.
One more thing. I think we discussed - and perhaps decided - to an NSI extension for capacity on the ports. AFAICT that isn't it currently; I think we should consider adding it.
Iirc that depended on adding an attribute to a Port, which I’m not sure how to do in an extension schema.
Well, you cannot really define a new type, as the would make something is not longer an NML port. I think the way is to define an attribute in nsi-ext.xsd , like this:
+ + <!-- capacity of a port, attribute for Port and PortGroup --> + <xs:attribute name="capacity" /> +
I’m leaving the XML schema things open until I get confirmation from another XML expert that this does what is intended :)
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Sorry, power failure for three hours yesterday and I forgot to press sent on this after it came back on. I renamed Service to Interface because the concept of Service was already used in NML and I wanted to avoid additional confusion by adding something else called Service in the NSI extensions that was not the same use of the term Service. John On 2013-12-19, at 6:26 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
Had a look at the updates.
On Wed, 18 Dec 2013, Jeroen van der Ham wrote:
The NSI Topology extensions document is in a separate Redmine project:
https://redmine.ogf.org/projects/nsi-wg-topology
Join that project, and then you can use this page to check out/explore the git repository: https://redmine.ogf.org/projects/nsi-wg-topology/repository
nsi:Service -> nsi:Interface rename. I cannot recall dicussing this on the call. It doesn't really matter, but it is difficult to see why this had to be renamed. Both terms are overloaded anyway, but usually I associate interface with something slightly more abstract.
The schemas/test2.xml is (very) outdated. I suggest removing it.
I would - very much - like to have xs:any under the nsi:NSA (I was actually under the impression that it was there already). It is also a bit weird of us to complain about NML not having them, and not adding them ourselves. Here is a patch:
--- a/schemas/nsi-ext.xsd +++ b/schemas/nsi-ext.xsd @@ -47,6 +47,9 @@ <xs:element ref="nsi:Interface" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nsi:Relation" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nml:Topology" minOccurs="0" maxOccurs="unbounded"/> + <!-- the local one is needed for xmllint to not complain about determinism --> + <xs:any namespace="##local" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> + <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent>
There is a bug in libxml2 that will complain about the model not being deterministic when not having the local there. It is actually, but since a lot of people use libxml2, I've added the local element.
Since we added the labelType in the SwitchingService, I think it should be in the example.
Will the namespaces by updated?
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Fri, 20 Dec 2013, John MacAuley wrote:
I renamed Service to Interface because the concept of Service was already used in NML and I wanted to avoid additional confusion by adding something else called Service in the NSI extensions that was not the same use of the term Service.
Yes, but that is why we have prefixes, so we can have elements with sortof similar names. We have been calling this a service for some time in the NSI group (and I think our use of Service is closer to what most people think of when they hear the term service, but that is beside the point). It doesn't change any functionality, but just moves away from terminology already established in the NSI group. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi again One more thing. I think we discussed - and perhaps decided - to an NSI extension for capacity on the ports. AFAICT that isn't it currently; I think we should consider adding it. Have a nice Christmas and new-years everyone. /Henrik On Wed, 18 Dec 2013, Jeroen van der Ham wrote:
Hi,
The NSI Topology extensions document is in a separate Redmine project:
https://redmine.ogf.org/projects/nsi-wg-topology
Join that project, and then you can use this page to check out/explore the git repository: https://redmine.ogf.org/projects/nsi-wg-topology/repository
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
We need a formalized Ethernet extensions document, or at the very least, an NSI Ethernet extensions for NML. We need to capture the final VLAN namespace, mtu, capacity, and perhaps cost metrics we want supported. John On 2013-12-20, at 9:28 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi again
One more thing. I think we discussed - and perhaps decided - to an NSI extension for capacity on the ports. AFAICT that isn't it currently; I think we should consider adding it.
Have a nice Christmas and new-years everyone.
/Henrik
On Wed, 18 Dec 2013, Jeroen van der Ham wrote:
Hi,
The NSI Topology extensions document is in a separate Redmine project:
https://redmine.ogf.org/projects/nsi-wg-topology
Join that project, and then you can use this page to check out/explore the git repository: https://redmine.ogf.org/projects/nsi-wg-topology/repository
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Henrik Thostrup Jensen
-
Jeroen van der Ham
-
John MacAuley