[Nml-wg] NMLify of AutoGOLE topology
Jerry Sobieski
jerry at nordu.net
Wed Feb 22 15:00:43 EST 2012
Hi Roman e al-
In general, I think the NMLification of the NSI topology is quite
good. I do not mind the unidirectional aspects myself as I believe
these are necessary for NSI (ultimately) anyway. And as presented in
Freek's example seem to be perfectly consistent with the current NSI
model. (FYI- I have asked that unidirectional connections be a topic
for NSI V2.0.
The vcard issue is not on the critical path for NSI, so I am not too
worried about that. Freek's suggestions seem fine to me.
There is some concern about using the "port" term itself as it is just
so overloaded that it creates confusion. But that said, I think the
logical nature of the NML "port" construct as it represents STPs is
consistent with NSI semantics.
I think the bidirectional nature of NSI STPs will relax soon as well to
be unidirectional STPs. STPs identify specific locations where a
connection can be terminated (or originated). And really, a
unidirectional flow of data is the atomic element of a "connection" and
is in fact how actual switching fabrics are actually constructed, so
this fits best (IMO). Binding arbitrary switch fabric input and output
interfaces into a single "transmit/receive Port" on a box is purely an
engineering practice (indeed - many optical equipment explicitly
separate the transmit and receive paths to be configured independently
by the transport engineers..)
Bi-directional Connections are [should be IMO] a compositional service
feature. (see comments further down.) There is no innate requirement
that a "NSI Connection" be bi-directional. Nor is it required that the
forward and reverse components be congruent or symmetric. Thus, I
believe the basic coin of the realm should be a unidirectional
topological construct as well.
I understand why Freek translated STPs to be the bidirectional ports -
this is how the current NSI topology uses them.
But I would concur that what we really want is a unidirectional concept
of a domain edge interface (STP or port) that identifies uniquely the
termini for service instances with an "orientation" - in or out relative
to the domain.
some other comments below...
On 2/22/12 9:19 AM, Roman Łapacz wrote:
> W dniu 2012-02-22 10:52, Freek Dijkstra pisze:
>> Hi all,
>>
>> I've tried to NML-ify the AutoGOLE topology. I did in RDF/XML because
>> that is probably readable by both OWL and XML folks.
>>
>> Below are the steps I took in detail, along with intermediate results
>> (which may help in understanding the differences).
>>
>> The main changes are:
>> - made ports and link unidirectional, per NML specs.
>> - use explicit link object to describe the SDP
>> (NML has no connectedTo concept)
>> - change the urn:ogf:network identifiers to a valid syntax,
>> the ones currently in AutoGOLE use are not valid according
>> to proposed standard nor previous use in either GLIF or
>> perfSONAR community.
>>
>> The file AutoGOLE-Topo-2012-02-22.rdf gives the result so far.
>>
>> Notes:
>>
>> 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). 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.
Yes. But first things first. This was/is a good exercise as we see
that the NSI topology can indeed be represented semantically in the NML
format. This is a great first step.
Now, as you suggest, there is this issue of "resolution" - the ability
to define internal topology in finer resolution - still as NSI concepts
or as NRM technology specific constructs. IMO, we should be able to
recursively define more internal detailed NSI constructs until the
domain is ready to map the NSI constructs to the tuple that the internal
NRM will recognize. It is not strictly required that the "mapsTo"
relation point to physical or technology specific information. The
mapsTo could map to a more detailed NSI topology internal to a domain
(think of a "federation" NSI domains). I do believe at some level the
mapsTo should reference a topological object or tuple that is physical
or a string that the local NRM can interpret to indicate where the NSI
Connection should be terminated.
Topo X1. Perhaps a next exercise would be to stipulate a simple
exemplar network with a single physical switch. Lets take
NetherLight domain as example. The expressed NSI/NML Topology should
be such that we can ascribe a simple any-to-any switching function to
NetherLight...from any ingress STP to any egress STP.
Topo X2a & X2b. The next topology would be to enhance TopoX1 with the
specification of an ethernet switch as Netherlight switching core. For
X2a, assume the switch can do VLAN re-write and so the any-to-any
switching capability is maintained. For X2b, assume the ethernet
switch is a crufty old conventional switch that cannot swap VLAN IDs and
so the any-to-any switching function is reduced to ingress port/STP(i)
can switch to output port/STP(j) iff i=j.
TopoX3. In this topo, provide an example we switch to NorthernLight.
Show how NorthernLight could present a single NSI domain but has NSI
"sub-domains" in NYC and CPH. (This is likely a real scenario...)
Assume the switching functions are any-to-any for all ports/STPs.
Consider the naming scope carefully.
>
> btw. I'm still thinking that we don't need nml:bidirectionalport in
> NML :) We could use port with "bidirectional" relation.
I agree. What is a "bidirectional port"? It is really two ports
bound together for purposes of ... what? Indeed - Freek bound NSI STPs
together as bidirectional ports...you didn't have any information that
said these ports were even on the same switch or of the same
technology! (:-) Be careful about what your assumptions are. NSI
STPs deliberately hide technology specifics - don't be fooled by the STP
names:-) There were no MapsTo relations that pointed to physical
descriptions, so you all made some assumptions that were not necessarily
valid.
A true "bidirectional port" would be a port on which data is sent in
both directions simultaneously...which is in fact possible in the
photonic realm. So perhaps the "bidirectional port" grouping needs
some further consideration?
Also... simply calling an in and out port a "bidirectional port" does
not prevent those unidirectional components from linking to completely
different far ends...
Jerry
> Roman
>
>> 2. The dtox:hasSTP relation now points to a nml:bidirectionalport. NML
>> defines a similar "hasPort" relation between a nml:Topology and
>> nml:Port. (and there is some discussion to differentiate between
>> hasOutboundPort and hasInboundPort). If dtox:NSNetwork and nml:topology
>> are merged, I recommend to use these relations.
>> 3. Yet unclear how exactly to tie Ethernet specifics to the examples, it
>> seems prudent to use labels and the subnetwork concept as discussed in
>> the NML-WG in Lyon (see subversion:
>> https://forge.ogf.org/svn/repos/nml-examples/20110922/other_examples/configured_vlan.xml;
>> you need a gridforge login. Drop me a line if you can't access it.)
>>
>>
>> Regards,
>> Freek Dijkstra
>>
>>
>> List of steps I took:
>>
>> Source: AutoGOLE-Topo-2012-01-25.owl
>>
>> Removed owl:NamedIndividual
>> Removed schema definitions (owl:Ontology, owl:AnnotationProperty, etc.)
>> Removed Position comments (used by auto-gole.appspot.com)
>> Removed unnecessary comments
>>
>> Result: AutoGOLE-Topo-2012-01-25.rdf
>>
>> Changed dtox:lat, dtox:long and dtox:Location to geo84:lat, geo84:long
>> and geo84:SpatialThing
>> Corrected label of Netherlight location from Copenhagen to Amsterdam
>> (geo84 was OK)
>>
>> Changed dtox:STP to nml:bidirectionalport
>> Grouped ports of a single network in a nml:topology
>> Commented dtox:connectedTo, since this is not valid NML
>> Added rdfs:label to all NSA and all locations
>> Changed admin contact from string to vCard
>>
>> Result: AutoGOLE-Topo-2012-02-20.rdf
>>
>> Change urn:ogf:network identifiers to valid syntax
>> (urn:ogf:network:<FQDN>:<date>:<opaque>)
>> Make all bidirectional ports unidirectional
>> Explicitly defined NML links, with sources and sinks
>>
>> Result: AutoGOLE-Topo-2012-02-22.rdf
>>
>> Possible future direction:
>>
>> Merge NML:topology with dtox:NSNetwork
>> Remove the dtox:managedBy property, as there is already an inverse
>> relation dtox:managing to find the correct dtox:NSA
>> Added switch matrix to each NML topology
>> Define switching capabilities for each topology.
>> use nml:hasPort instead of dtox:hasSTP
>>
>> Result: (the-AutoGOLE-future-is-yet-to-be-written.rdf)
>>
>>
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
>
>
>
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/c013c082/attachment.html>
More information about the nml-wg
mailing list