Roman Łapacz wrote:
1. The resulting topology file has three layers: - NML topology - dtox NSNetwork - dtox NSA I really like the clear distinction between the data plane (NML) and control plane (dtox/NSI). However, I wonder if we should move this to two layers, perhaps merging dtox:NSNetwork and nml:topology.
I'm not sure of this distinction if nml:bidirectionalport is STP (I have a problem with this: dtox:hasSTP in dtox:NSNetwork points at nml:bidirectionalport; moving from dtox to nml domain does not look right to me in this case).
I agree that this looks strange, and should be fixed. But before we can fix it, we should decide if the above three concepts are truly distinct and should remain as-is, or perhaps should be merged somehow. My hope is that we can merge NML:topology with dtox:NSNetwork, but for that to decide, at least I need a better understanding what a NSNetwork represents. If I'm correct, a NSNetwork represents the abstracted transport capability of some data plane (typically under control by a given NSA). I think that NML:Topology is able to represent that. However, it should be said that a NML:Topology can also represent a non-abstracted data plane. In my mind, that's not an issue, but I like to hear input from others.
All elements in the example belong to NSI abstraction (links are SDPs, ports STPs; except VCard part). To me distinction is between NSI topology (represented by STP, SDP, NSNetwork, NSA) and internal domain topology which is hidden under mapTo relation.
What do you mean with a mapTo relation? A mapping from an abstracted to an actual topology? One of the discussions we should have tomorrow is if NML is capable of describing abstracted topologies or not. I personally think it can; I also think it should: NML about exchanging topology data, and there are substantial benefits in only exchanging abstracted topologies over exchanging the actual topology implementation. Regards, Freek