I've just created a new artifact, https://forge.ogf.org/sf/go/artf6507 Here is the full proposal. Adaptation is between Ports, and requires the following objects: * 2 Link instances * 4 Port instances * 2 Adaptation instances * 8 relations between these instances (see https://forge.ogf.org/sf/go/artf6514 for details) While the above is great to describe a topology in detail, it is sometimes useful to describe less detail. I propose a shortcut to define adaptation between Links: Link --(providesLink)--> Link This would only require the following objects: * 2 Link instances * 1 relation between these instances This is similar how isSerialCompoundLink also relates Link objects, bypassing the more tedious Link <--(isSink)-- Port --(isSource)--> Link relations. Of course this is less detailed (e.g. it is not possible to describe the type or adaptation, or the name of the Ports). It's intended use is a situations where a full topology description (with all ports) is not required or not desirable. NML: Link --(providesLink)--> Link The subject (Link on the left) is on the server layer. The link of the right (the object) is one the client layer, and source and sinks of both Links MUST be related with an equal adaptation stack. In other words, both Links MUST span the same distance. For example, in the following ASCII-art, the following statements are True: l0 --(providesLink)--> l1 - True l0 --(providesLink)--> l2-2 - True l1 --(providesLink)--> l2-2 - True While the following statements are all False: l0 --(providesLink)--> l3 - False l1 --(providesLink)--> l3 - False l2-2 --(providesLink)--> l3 - False l3 O -----------------------------------------------> O | | _ _ V V | l2-1 l2-2 l2-3 | O -------------> O -------------> O -------------> O | | _ _ V V | l1 | O -------------> O | | _ _ V V | l0 | O -------------> O
From these requirements follows that the subject is always a terminated network connection (thus not a segment of a larger link connections), while the object is never a serial compound link.
XML example: <nml:Link id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm"> <nml:name>1530nm wave between NOR and AMS</nml:name> <nml:Relation type="providesLink"> <nml:Port idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" /> </nml:Relation> </nml:Service> RDF example: @prefix nml: <http://example.ogf.org/schemas/nml/>; . @prefix nmlrel: <http://example.ogf.org/schemas/nml-relation/>; . @prefix ex: <urn:ogf:network:example.net:2012> . ex:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm a nml:Link ; nml:name "1530nm wave between NOR and AMS" ; nmlrel:providesLink ex:link:eth:NOR-AMS-0001 .
Hi Freek; I could see the shortcut notation being made available through an extension (e.g. nml-lazy), but too many options will confuse things. If there was the ability to capture the 16 object interaction in 3 objects, why would you ever waste time encoding it as such? Thanks; -jason On 5/10/12 7:41 AM, thus spake Freek Dijkstra:
I've just created a new artifact, https://forge.ogf.org/sf/go/artf6507
Here is the full proposal.
Adaptation is between Ports, and requires the following objects: * 2 Link instances * 4 Port instances * 2 Adaptation instances * 8 relations between these instances (see https://forge.ogf.org/sf/go/artf6514 for details)
While the above is great to describe a topology in detail, it is sometimes useful to describe less detail.
I propose a shortcut to define adaptation between Links: Link --(providesLink)--> Link
This would only require the following objects: * 2 Link instances * 1 relation between these instances
This is similar how isSerialCompoundLink also relates Link objects, bypassing the more tedious Link<--(isSink)-- Port --(isSource)--> Link relations.
Of course this is less detailed (e.g. it is not possible to describe the type or adaptation, or the name of the Ports). It's intended use is a situations where a full topology description (with all ports) is not required or not desirable.
NML:
Link --(providesLink)--> Link
The subject (Link on the left) is on the server layer. The link of the right (the object) is one the client layer, and source and sinks of both Links MUST be related with an equal adaptation stack. In other words, both Links MUST span the same distance.
For example, in the following ASCII-art, the following statements are True: l0 --(providesLink)--> l1 - True l0 --(providesLink)--> l2-2 - True l1 --(providesLink)--> l2-2 - True While the following statements are all False: l0 --(providesLink)--> l3 - False l1 --(providesLink)--> l3 - False l2-2 --(providesLink)--> l3 - False
l3 O -----------------------------------------------> O | | _ _ V V | l2-1 l2-2 l2-3 | O -------------> O -------------> O -------------> O | | _ _ V V | l1 | O -------------> O | | _ _ V V | l0 | O -------------> O
From these requirements follows that the subject is always a terminated network connection (thus not a segment of a larger link connections), while the object is never a serial compound link.
XML example:
<nml:Link id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm"> <nml:name>1530nm wave between NOR and AMS</nml:name> <nml:Relation type="providesLink"> <nml:Port idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" /> </nml:Relation> </nml:Service>
RDF example:
@prefix nml:<http://example.ogf.org/schemas/nml/>; . @prefix nmlrel:<http://example.ogf.org/schemas/nml-relation/>; . @prefix ex:<urn:ogf:network:example.net:2012> .
ex:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm a nml:Link ; nml:name "1530nm wave between NOR and AMS" ; nmlrel:providesLink ex:link:eth:NOR-AMS-0001 . _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jason Zurawski wrote:
I could see the shortcut notation being made available through an extension (e.g. nml-lazy), but too many options will confuse things.
I would prefer this in the main document, but have no objections in putting this in another document and/or specifying that it does not need to be supported by a "base" NML implementation. We can't put it this in a different (e.g. nml-lazy) namespace though. The simple reason is that this is a relation, and relation types have no namespace. How to deal with extensions, such as this one, is exactly the question that I brought up earlier today (http://www.ogf.org/pipermail/nml-wg/2012-May/000955.html). In particular -- do we want to limit the number of relation types for NML 1? Or can we extend that without changing the NML schema itself? Also, do we want to add a namespace to relation types after all so we can differentiate between "base" NML extension and e.g. "nml-lazy" extensions?
If there was the ability to capture the 16 object interaction in 3 objects, why would you ever waste time encoding it as such?
Because there is different needs what is to be described. The 8 objects + 8 relations allow naming of Ports, and specification of the type of adaptation used. The 2 objects + 1 relation does not allow that. Note that we have a similar situation for isSerialCompoundLink. It is perfectly possible to reason that a serial compound link exists by following all isSource and isSink relations. The isSerialCompoundLink is just shorter, because it does not list ports. (Admittedly, isSerialCompoundLink also allows one to name an end-to-end link. This providesLink proposal does not have such advantage. It's only shorter, no other advantages.) Freek
Thanks;
-jason
On 5/10/12 7:41 AM, thus spake Freek Dijkstra:
I've just created a new artifact, https://forge.ogf.org/sf/go/artf6507
Here is the full proposal.
Adaptation is between Ports, and requires the following objects: * 2 Link instances * 4 Port instances * 2 Adaptation instances * 8 relations between these instances (see https://forge.ogf.org/sf/go/artf6514 for details)
While the above is great to describe a topology in detail, it is sometimes useful to describe less detail.
I propose a shortcut to define adaptation between Links: Link --(providesLink)--> Link
This would only require the following objects: * 2 Link instances * 1 relation between these instances
This is similar how isSerialCompoundLink also relates Link objects, bypassing the more tedious Link<--(isSink)-- Port --(isSource)--> Link relations.
Of course this is less detailed (e.g. it is not possible to describe the type or adaptation, or the name of the Ports). It's intended use is a situations where a full topology description (with all ports) is not required or not desirable.
NML:
Link --(providesLink)--> Link
The subject (Link on the left) is on the server layer. The link of the right (the object) is one the client layer, and source and sinks of both Links MUST be related with an equal adaptation stack. In other words, both Links MUST span the same distance.
For example, in the following ASCII-art, the following statements are True: l0 --(providesLink)--> l1 - True l0 --(providesLink)--> l2-2 - True l1 --(providesLink)--> l2-2 - True While the following statements are all False: l0 --(providesLink)--> l3 - False l1 --(providesLink)--> l3 - False l2-2 --(providesLink)--> l3 - False
l3 O -----------------------------------------------> O | | _ _ V V | l2-1 l2-2 l2-3 | O -------------> O -------------> O -------------> O | | _ _ V V | l1 | O -------------> O | | _ _ V V | l0 | O -------------> O
From these requirements follows that the subject is always a terminated network connection (thus not a segment of a larger link connections), while the object is never a serial compound link.
XML example:
<nml:Link id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm">
<nml:name>1530nm wave between NOR and AMS</nml:name> <nml:Relation type="providesLink"> <nml:Port idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" /> </nml:Relation> </nml:Service>
RDF example:
@prefix nml:<http://example.ogf.org/schemas/nml/>; . @prefix nmlrel:<http://example.ogf.org/schemas/nml-relation/>; . @prefix ex:<urn:ogf:network:example.net:2012> .
ex:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm a nml:Link ; nml:name "1530nm wave between NOR and AMS" ; nmlrel:providesLink ex:link:eth:NOR-AMS-0001 .
On May 10, 2012, at 7:41 AM, Freek Dijkstra wrote:
I've just created a new artifact, https://forge.ogf.org/sf/go/artf6507
Here is the full proposal.
Adaptation is between Ports, and requires the following objects: * 2 Link instances * 4 Port instances * 2 Adaptation instances * 8 relations between these instances (see https://forge.ogf.org/sf/go/artf6514 for details)
While the above is great to describe a topology in detail, it is sometimes useful to describe less detail.
I propose a shortcut to define adaptation between Links: Link --(providesLink)--> Link
This would only require the following objects: * 2 Link instances * 1 relation between these instances
This is similar how isSerialCompoundLink also relates Link objects, bypassing the more tedious Link <--(isSink)-- Port --(isSource)--> Link relations.
Of course this is less detailed (e.g. it is not possible to describe the type or adaptation, or the name of the Ports). It's intended use is a situations where a full topology description (with all ports) is not required or not desirable.
NML:
Link --(providesLink)--> Link
The subject (Link on the left) is on the server layer. The link of the right (the object) is one the client layer, and source and sinks of both Links MUST be related with an equal adaptation stack. In other words, both Links MUST span the same distance.
For example, in the following ASCII-art, the following statements are True: l0 --(providesLink)--> l1 - True l0 --(providesLink)--> l2-2 - True l1 --(providesLink)--> l2-2 - True While the following statements are all False: l0 --(providesLink)--> l3 - False l1 --(providesLink)--> l3 - False l2-2 --(providesLink)--> l3 - False
l3 O -----------------------------------------------> O | | _ _ V V | l2-1 l2-2 l2-3 | O -------------> O -------------> O -------------> O | | _ _ V V | l1 | O -------------> O | | _ _ V V | l0 | O -------------> O
From these requirements follows that the subject is always a terminated network connection (thus not a segment of a larger link connections), while the object is never a serial compound link.
XML example:
<nml:Link id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm"> <nml:name>1530nm wave between NOR and AMS</nml:name> <nml:Relation type="providesLink"> <nml:Port idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" />
Should this be <nml:Link> and not <nml:Port> ? If not, I'm apparently missing something obvious. If so, I'm fine with the proposal. Cheers, Aaron
</nml:Relation> </nml:Service>
RDF example:
@prefix nml: <http://example.ogf.org/schemas/nml/>; . @prefix nmlrel: <http://example.ogf.org/schemas/nml-relation/>; . @prefix ex: <urn:ogf:network:example.net:2012> .
ex:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm a nml:Link ; nml:name "1530nm wave between NOR and AMS" ; nmlrel:providesLink ex:link:eth:NOR-AMS-0001 . _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
Aaron Brown wrote:
XML example:
<nml:Link id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm"> <nml:name>1530nm wave between NOR and AMS</nml:name> <nml:Relation type="providesLink"> <nml:Port idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" />
Should this be <nml:Link> and not <nml:Port> ? If not, I'm apparently missing something obvious. If so, I'm fine with the proposal.
Good catch. You are -as usual- correct that this should be nml:Link. Freek
W dniu 2012-05-10 14:53, Aaron Brown pisze:
On May 10, 2012, at 7:41 AM, Freek Dijkstra wrote:
I've just created a new artifact, https://forge.ogf.org/sf/go/artf6507
Here is the full proposal.
Adaptation is between Ports, and requires the following objects: * 2 Link instances * 4 Port instances * 2 Adaptation instances * 8 relations between these instances (see https://forge.ogf.org/sf/go/artf6514 for details)
While the above is great to describe a topology in detail, it is sometimes useful to describe less detail.
I propose a shortcut to define adaptation between Links: Link --(providesLink)--> Link
This would only require the following objects: * 2 Link instances * 1 relation between these instances
This is similar how isSerialCompoundLink also relates Link objects, bypassing the more tedious Link <--(isSink)-- Port --(isSource)--> Link relations.
Of course this is less detailed (e.g. it is not possible to describe the type or adaptation, or the name of the Ports). It's intended use is a situations where a full topology description (with all ports) is not required or not desirable.
NML:
Link --(providesLink)--> Link
The subject (Link on the left) is on the server layer. The link of the right (the object) is one the client layer, and source and sinks of both Links MUST be related with an equal adaptation stack. In other words, both Links MUST span the same distance.
For example, in the following ASCII-art, the following statements are True: l0 --(providesLink)--> l1 - True l0 --(providesLink)--> l2-2 - True l1 --(providesLink)--> l2-2 - True While the following statements are all False: l0 --(providesLink)--> l3 - False l1 --(providesLink)--> l3 - False l2-2 --(providesLink)--> l3 - False
l3 O -----------------------------------------------> O | | _ _ V V | l2-1 l2-2 l2-3 | O -------------> O -------------> O -------------> O | | _ _ V V | l1 | O -------------> O | | _ _ V V | l0 | O -------------> O
From these requirements follows that the subject is always a terminated network connection (thus not a segment of a larger link connections), while the object is never a serial compound link.
XML example:
<nml:Link id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm"> <nml:name>1530nm wave between NOR and AMS</nml:name> <nml:Relation type="providesLink"> <nml:Port idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" />
Should this be <nml:Link> and not <nml:Port> ?
If not, I'm apparently missing something obvious. If so, I'm fine with the proposal.
providesLink may not be obvious for people who will want to use NML that it is adaptation. Of course a detailed documentation of it may solve the problem but on the other hand such things should be intuitive. Maybe still using nml:Service element, only with type attribute and no additional info, would be better? Roman
Cheers, Aaron
</nml:Relation> </nml:Service>
RDF example:
@prefix nml: <http://example.ogf.org/schemas/nml/>; . @prefix nmlrel: <http://example.ogf.org/schemas/nml-relation/>; . @prefix ex: <urn:ogf:network:example.net:2012> .
ex:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm a nml:Link ; nml:name "1530nm wave between NOR and AMS" ; nmlrel:providesLink ex:link:eth:NOR-AMS-0001 . _______________________________________________ nml-wg mailing list nml-wg@ogf.org <mailto:nml-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
participants (4)
-
Aaron Brown -
Freek Dijkstra -
Jason Zurawski -
Roman Łapacz