Hi Some notes from implementing NML, and some input for the topology discussion at Glif. There is no bandwdith/capacity attribute in NML. This means we cannot do capacity matching in pathfinding Is this something we need? (insert usual disclaimer about advertised bandwidth being different from avaible) NML does not have anything to denote available service definitions - per network or port. This again, makes pathfinding rather tricky and full of assumptions. While one can match labels with labels used in a service definition, there might be certain semantics which is not supported. Is this something we need to add? The NML model is quite different from the original network+port model of NSI. The role of a topology corresponds roughly to a network, but this is a restriction/policy that we have made (which I am perfectly fine with, but we just need to be explicit about this). This also means the way NML and NSI reference ports are different. In NSI we use a network id (which maps to a topology in NML) and a local id which maps to a fully qualified port name in NML, like this: <sourceSTP> <networkId>urn:ogf:network:aruba.net</networkId> <localId>urn:ogf:network:aruba.net:ps</localId> </sourceSTP> In NML, one can reference ports directly, like this: <nml:PortGroup id="urn:ogf:network:bonaire.net:bonaire.net:arb-in" /> There is something to be said for both models, but not really about having both at the same. The network id in NSI is really redundant. I talked to to John about this in Madrid, and while he agreed he just couldn't get himself to remove (and I agree with this, the whole thing just feels so goddamn clumsy). Right now we essentially have 1½ topology model. There are some ways Then there are some security aspects. How do I control that no one injects services / topologies / servies into the topology? In OpenNSA, I do the following in the configuration: peers=example.org@http://example.org:9080/NSI/topology/example.org.xml This enables me to check/filter for identifiers in the retrieved topology. A basic way could be to match the hostname of the base identifier (like nordu.net:2013) against a certificate (can the the one of the TLS session or via a signed topology). However AFAICT, there is no way to establish exactly what the base identifier is. Furthermore the certificate is not likely to match the base identifier, e.g. nordu.net:2013 vs nsi.nordu.net. The NML year model also falls somewhat apart here, as someone announcing with a certain year would need to have a valid certificate for that year, however certificates where the current time is not within the valid period are by default invalid (and with good reason). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 30 Sep 2013, at 16:10, Henrik Thostrup Jensen <htj@nordu.net> wrote:
There is no bandwdith/capacity attribute in NML. This means we cannot do capacity matching in pathfinding Is this something we need? (insert usual disclaimer about advertised bandwidth being different from avaible)
That should be a good thing for the NSI Extension to add because there it is used in a much stricter context, i.e. service being announced as available (sometimes).
NML does not have anything to denote available service definitions - per network or port. This again, makes pathfinding rather tricky and full of assumptions. While one can match labels with labels used in a service definition, there might be certain semantics which is not supported. Is this something we need to add?
What exactly do you mean? This is different from the SwitchingService that I described earlier?
The NML model is quite different from the original network+port model of NSI. The role of a topology corresponds roughly to a network, but this is a restriction/policy that we have made (which I am perfectly fine with, but we just need to be explicit about this). This also means the way NML and NSI reference ports are different. In NSI we use a network id (which maps to a topology in NML) and a local id which maps to a fully qualified port name in NML, like this:
<sourceSTP> <networkId>urn:ogf:network:aruba.net</networkId> <localId>urn:ogf:network:aruba.net:ps</localId> </sourceSTP>
In NML, one can reference ports directly, like this:
<nml:PortGroup id="urn:ogf:network:bonaire.net:bonaire.net:arb-in" />
There is something to be said for both models, but not really about having both at the same. The network id in NSI is really redundant. I talked to to John about this in Madrid, and while he agreed he just couldn't get himself to remove (and I agree with this, the whole thing just feels so goddamn clumsy). Right now we essentially have 1½ topology model. There are some ways
yes ? We're still using a somewhat "simple" topology where we have an explicit split between aggregator NSAs and NSAs taking care of a single network. If we ever move to a different kind of model, you need to have both an identifier for the NSA (i.e. network) and the specific Port that you want to get at. And also given that URIs should not be interpreted (according to the RFCs and GFDs), we need to have separate ones.
Then there are some security aspects. How do I control that no one injects services / topologies / servies into the topology? In OpenNSA, I do the following in the configuration:
That makes some sense indeed. We have to look at that more closely if we want to continue this model. Jeroen.
Hi On Mon, 30 Sep 2013, Jeroen van der Ham wrote:
On 30 Sep 2013, at 16:10, Henrik Thostrup Jensen <htj@nordu.net> wrote:
There is no bandwdith/capacity attribute in NML. This means we cannot do capacity matching in pathfinding Is this something we need? (insert usual disclaimer about advertised bandwidth being different from avaible)
That should be a good thing for the NSI Extension to add because there it is used in a much stricter context, i.e. service being announced as available (sometimes).
I agree. And this is the obvious way of doing it. However I found that if I present a ready solution people start debating and arguing because they haven't been heard, so these days I try not to that :-).
NML does not have anything to denote available service definitions - per network or port. This again, makes pathfinding rather tricky and full of assumptions. While one can match labels with labels used in a service definition, there might be certain semantics which is not supported. Is this something we need to add?
What exactly do you mean?
So, how I know a port can can be used in an ETS or EVTS? Sure I can maybe infer this somewhat from a VLAN label to EVTS, but there isn't anything stating that just because it has a VLAN label it can do EVTS. Regular ETS is somewhat more muddy because we currently don't have labels for that (but we could come up with one), so here the problem is more apparent.
This is different from the SwitchingService that I described earlier?
I don't think so.
There is something to be said for both models, but not really about having both at the same. The network id in NSI is really redundant. I talked to to John about this in Madrid, and while he agreed he just couldn't get himself to remove (and I agree with this, the whole thing just feels so goddamn clumsy). Right now we essentially have 1½ topology model. There are some ways
yes ?
Sorry I was on a train when I wrote this, and it was pretty early What I was thinking about was to enforce a certain way of applying NML within NSI, in such a way that NML was shoehorned into the NSI model. Essentially a request would be like this: networkId: nordu.net localId: ps this would then map to the port id: urn:ogf:network:nordu.net:ps This would force the topology id to correspond to the NSI network id. One can probably come up with some similar ways for this.
We're still using a somewhat "simple" topology where we have an explicit split between aggregator NSAs and NSAs taking care of a single network. If we ever move to a different kind of model, you need to have both an identifier for the NSA (i.e. network) and the specific Port that you want to get at.
I think having explicit identifiers for network and NSA is perfectly fine. However NML doesn't really have the concept of a network, only a topology.
And also given that URIs should not be interpreted (according to the RFCs and GFDs), we need to have separate ones.
Yearh that fact has some trouble getting into my head. Especially since a lot of rules for how construct them. What do you call a rule that cannot be enforced in any practical way?
Then there are some security aspects. How do I control that no one injects services / topologies / servies into the topology? In OpenNSA, I do the following in the configuration:
That makes some sense indeed. We have to look at that more closely if we want to continue this model.
If I cannot interpret URNs, then this verification becomes rather impossible. This means that NSAs can (or should) import topologies from NSAs which they completely and uttterly thrust not to pollute anything (accidently or on purpose). That sucks. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (2)
-
Henrik Thostrup Jensen -
Jeroen van der Ham