Hi Freek comments inline W dniu 2012-07-09 17:15, Freek Dijkstra pisze:

On 09-07-2012 16:17, Roman Łapacz wrote:

...

please, take a look at the attachment. Waiting for comments. Hi Roman,

Are there any specifics you like us to comment on?

- is that simple topology ok as an example to present a subset of nml structures (any other simple topology proposals are welcome) - are the structures I have used fine with all agreements we've had (thanks for you comments below)

I had a quick look, and these are things I would probably describe differently.

version -------

Version is a serial number, akin to a serial number in DNS SOA records, I wouldn't make this a number (so it is easy to compare date), not a URN. Also, I probably would simply describe it as an XML attribute instead of child element, but that is admittedly a matter of preference.

Agree. URN format was the first try as I wasn't sure if URN is forced to be used wherever it's possible.

...

<nml:Topology id="urn:ogf:network:domainx.net:2012:org">

<nml:name>Domain X</nml:name> <nml:version>urn:ogf:network:domainx.net:2012:20120709<nml:version> Suggested change:

...

<nml:Topology id="urn:ogf:network:domainx.net:2012:org" version="20120709">

<nml:name>Domain X</nml:name> Implicit relations

---

...

<nml:Topology xmlns:nml="http://schemas.ogf.org/nml/2012/07/base/" id="urn:ogf:network:gn3.net:2012:org"> [...]

<nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/hasTopology"> <nml:Topology idRef="urn:ogf:network:domainx.net:2012:org"/> <nml:Topology idRef="urn:ogf:network:domainy.net:2012:org"/> </nml:Relation>

[...] <nml:Topology id="urn:ogf:network:domainx.net:2012:org">

<nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/hasNode"> <nml:node idRef="urn:ogf:network:domainx.net:2012:nodeA"/> </nml:Relation>

[...] </nml:Topology> </nml:Topology> Some relations, including "hasTopology" and "hasNode" SHOULD be written implicitly.

This was discussed in https://forge.ogf.org/sf/go/artf6537 and I very much value your feedback there. (I see that we never reached consensus on the exact wording there.)

I prefer implicit approach but yesterday I saw in the current NML-relations.pdf file that the relations for mentioned cases are still used. I tried to be consistent with that file but now I'm fine to change that (the pdf file will have to be updated as well).

Suggested change:

...

<nml:Topology xmlns:nml="http://schemas.ogf.org/nml/2012/07/base/" id="urn:ogf:network:gn3.net:2012:org"> [...]

<nml:Topology idRef="urn:ogf:network:domainx.net:2012:org"/> <nml:Topology idRef="urn:ogf:network:domainy.net:2012:org"/>

[...] <nml:Topology id="urn:ogf:network:domainx.net:2012:org">

<nml:Node idRef="urn:ogf:network:domainx.net:2012:nodeA"/>

[...] </nml:Topology> </nml:Topology> or even:

...

<nml:Topology xmlns:nml="http://schemas.ogf.org/nml/2012/07/base/" id="urn:ogf:network:gn3.net:2012:org">

[...] <nml:Topology id="urn:ogf:network:domainx.net:2012:org">

<nml:Node idRef="urn:ogf:network:domainx.net:2012:nodeA"/>

[...] </nml:Topology> </nml:Topology> Case

---

See https://forge.ogf.org/sf/go/artf6534

You have written a few times:

...

nml:node nml:location nml:port Suggested change:

you're right

...

nml:Node nml:Location nml:Port locatedAt

---

You wrote:

...

<nml:node id="urn:ogf:network:domainx.net:2012:nodeA"> <nml:location idRef="urn:ogf:network:nordu.net:2011:redcity"/> [...] </nml:node> I probably would have written:

...

<nml:Node id="urn:ogf:network:domainx.net:2012:nodeA"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/locatedAt"> <nml:Location idRef="urn:ogf:network:nordu.net:2011:redcity"/> </nml:Relation> [...] </nml:node> But I like your implicit relation better, so I propose to make locatedAt an implicit relation (if this was not already the case; I can't seem to find that.)

OK

Slashes -------

...

<nml:port idRef="urn:ogf:network:domainx.net:2012:A_port_ge-0/2/9-out"/> Unfortunately, slashes are a reserved character, and not allowed in URNs. You will have to think of another identifier. I usually make up something like this:

...

<nml:port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-out"/>

Right. These are just identifiers and I overlooked that while focusing on structures.

hasPort -------

...

<nml:port id="urn:ogf:network:domainx.net:2012:A_port_ge-0/2/9-out"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/hasPort"> <nml:PortGroup idRef="urn:ogf:network:domainx.net:2012:domainx-domainy"/> </nml:Relation> </port>

<nml:port id="urn:ogf:network:domainx.net:2012:A_port_ge-0/2/9-in"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/hasPort"> <nml:PortGroup idRef="urn:ogf:network:domainx.net:2012:domainx-domainy"/> </nml:Relation> </port>

I'm not entirely sure what you are describing here. hasPort was recently introduced to describe that a given Port is part of a larger PortGroup.

It means that the outbound and inbound ports ge-0/2/9-out(in) (physically it's just one port ge-0/2/9) have available vlans (1780-1783) defined in PortGroup structure. In case of only one vlan 1501, instead of PortGroup the element Port is used.

Did you perhaps meant to write:

...

<nml:PortGroup id="urn:ogf:network:domainx.net:2012:domainx-domainy"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/hasPort"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A_port_ge-0/2/9-out"/> </nml:Relation> </nml:PortGroup>

<nml:PortGroup id="urn:ogf:network:domainx.net:2012:domainx-domainy"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/hasPort"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A_port_ge-0/2/9-in"/> </nml:Relation> </nml:PortGroup>

However, I'm still a bit of at a loss at the exact meaning -- above two PortGroups have the same identifier, but the Ports have a different directions. Did you intend to describe a PortGroup here, or a BidirectionalPort, or yet something else?

Same for

...

<nml:port id="urn:ogf:network:domainy.net:2012:C_port_ge-5/2/7-out"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/hasPort"> <nml:Port idRef="urn:ogf:network:domainy.net:2012:B-to-C"/> </nml:Relation> </port>

Did you mean here that urn:ogf:network:domainy.net:2012:B-to-C is a Link instead? Eg.

...

<nml:Port id="urn:ogf:network:domainy.net:2012:C_port_ge-5/2/7-out"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/isSource"> <nml:Link idRef="urn:ogf:network:domainy.net:2012:C-to-B"/> </nml:Relation> </nml:port>

(note the hasPort -> isSource, nml:Port -> nml:Link and B-to-C -> C-to-B)

Links -----

You never seem to connect any of the urn:ogf:network:domainx.net:2012:* identifiers to any of the urn:ogf:network:domainy.net:2012:* identifiers.

How do you describe that domains X and Y are connected to each other? I may have overlooked it (If I stare too much at XML and I'm bound to miss the obvious).

I didn't want to use links in this first example. Links will be presented in the next one. This example presents a simple topology that focus only on configurations in network devices. Use of ports and port groups are sufficient for some use cases (an example is the NSI topology).. thanks, Roman

Typos -----

This is all perfectly valid NML, but likely typos nevertheless :)

...

<!-- --------------------------------- Doman X --------------------------------- --> <!-- --------------------------------- Doman Y --------------------------------- --> <nml:location idRef="urn:ogf:network:nordu.net:2011:redcity"/> <nml:port ...> ....</port> Regards, Freek

W dniu 2012-07-10 14:17, Freek Dijkstra pisze:
>>> Links
>>> -----
>>>
>>> You never seem to connect any of the urn:ogf:network:domainx.net:2012:*
>>> identifiers to any of the urn:ogf:network:domainy.net:2012:* identifiers.
>>>
>>> How do you describe that domains X and Y are connected to each other? I
>>> may have overlooked it (If I stare too much at XML and I'm bound to miss
>>> the obvious).
>> I didn't want to use links in this first example. Links will be
>> presented in the next one.
>> This example presents a simple topology that focus only on
>> configurations in network devices. Use of ports and port groups are
>> sufficient for some use cases (an example is the NSI topology)..
> I can think of two ways to related domains together:
> * Using Links between the Nodes in a Topology

I tried to relate domains using Links between Ports but that does not 
look good to me (see the attachment). If I have bidirectional ports a 
link between does not have to be bidirectional. But to connect them I 
use sink/source structure that indicates direction (source->sink). Is 
there a solution for that already discussed?


Roman


> * Using aliases to relate an outbound Ports of one Topology with
>    the inbound Port of another Topology.
> NSI preferred (well, Jeroen and I told them they preferred ;) ) the
> second option. In your example you did neither. This is fine, but in
> that case you are describing that domainx is connected to domainy.
>
> Freek

On 11-07-2012 15:16, Roman Łapacz wrote:

<!-- COMMENT !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --> <!-- I propose to use new Relation="representedBy" --> <!--- when an object (in this case a Link can be represented by an other. Definition of them is the same! -->

<nml:BidirectionalLink id="urn:ogf:network:domainy.net:2012:domainx-domainy-domainx"> <nml:Relation type"http://schemas.ogf.org/nml/2012/07/relation/representedBy"> <nml:Link id="urn:ogf:network:domainx.net:2012:domainx-domainy-domainx"> <nml:Relation> </nml:Link>

I'm not (yet) sure what you mean with this definition. Can you elaborate a bit? My first thought was that you meant an identity relation, like 'isAlias', but since these are two different objects, I guess it's something different. To me, a BidirectionalLink is just a grouping of two Links, with the (implicit) "hasLink" relation. Perhaps a short example in words my help me understand. Disclaimer: I haven't found the time yet to go through the 2nd and 3rd update yet. Thanks, Freek

W dniu 2012-07-11 15:33, Freek Dijkstra pisze:

On 11-07-2012 15:26, Freek Dijkstra wrote:

...

On 11-07-2012 15:16, Roman Łapacz wrote:

...

<!-- COMMENT !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --> <!-- I propose to use new Relation="representedBy" --> <!--- when an object (in this case a Link can be represented by an other. Definition of them is the same! -->

<nml:BidirectionalLink id="urn:ogf:network:domainy.net:2012:domainx-domainy-domainx"> <nml:Relation type"http://schemas.ogf.org/nml/2012/07/relation/representedBy"> <nml:Link id="urn:ogf:network:domainx.net:2012:domainx-domainy-domainx"> <nml:Relation> </nml:Link>

Hold on, did you mean to write:

...

<nml:BidirectionalLink id="urn:ogf:network:domainy.net:2012:domainx-domainy-domainx"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/representedBy"> <nml:BidirectionalLink id="urn:ogf:network:domainx.net:2012:domainx-domainy-domainx"> <nml:Relation> </nml:Link>

Yes, but I understand that I can use Link instead of BidirectionalLink while pointing to BidirectionalLink. in fact I should have used IdRef <nml:BidirectionalLink id="urn:ogf:network:domainy.net:2012:domainx-domainy-domainx"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/representedBy"> <nml:Link idRef="urn:ogf:network:domainx.net:2012:domainx-domainy-domainx"> <nml:Relation> Roman

?

That would make more sense to me, and is probably the same as the "isAlias" relation.

Freek

W dniu 2012-07-11 15:57, Freek Dijkstra pisze:

On 11-07-2012 15:50, Roman Łapacz wrote:

...

...

Hold on, did you mean to write:

...

<nml:BidirectionalLink id="urn:ogf:network:domainy.net:2012:domainx-domainy-domainx"> <nml:Relation type="http://schemas.ogf.org/nml/2012/07/relation/representedBy"> <nml:BidirectionalLink id="urn:ogf:network:domainx.net:2012:domainx-domainy-domainx"> <nml:Relation> </nml:Link>

Yes, but I understand that I can use Link instead of BidirectionalLink while pointing to BidirectionalLink. Sorry, I'm afraid I lost you there.

It kind of sounds like "I like to use that chair, so I point to a table".

Bidirectional link is a Link (I see it as inheritance) so for pointing I think I can use Link element (but if it breaks a rule I can use BidirectionalLink for that, no problem) Roman

I guess that's not what you meant. :)

Freek

On 11-07-2012 16:06, Roman Łapacz wrote:

Bidirectional link is a Link (I see it as inheritance) so for pointing I think I can use Link element (but if it breaks a rule I can use BidirectionalLink for that, no problem)

A Bidirectional Link is not a (special case of a) Link, it's a group of two (Unidirectional) Links. In the NML schema [1] there is no direct inheritance between the two, although both subclass a Network Object (but so does a Node). (I would actually like a BidirectionalLink to be a Link, but all attempt I did failed in logic: things like "isSource" and "isSink" would be ambiguous in the direction. So I stopped trying for now.) Freek [1] https://forge.ogf.org/sf/docman/do/downloadDocument/projects.nml-wg/docman.r...

An example updated. Available in the repo (nml-examples/201207-groups-and-labels). Any comments are welcome. (btw. I've done few minor updatesin the RNC schema as well) Roman W dniu 2012-07-11 16:17, Freek Dijkstra pisze:

On 11-07-2012 16:06, Roman Łapacz wrote:

...

Bidirectional link is a Link (I see it as inheritance) so for pointing I think I can use Link element (but if it breaks a rule I can use BidirectionalLink for that, no problem) A Bidirectional Link is not a (special case of a) Link, it's a group of two (Unidirectional) Links. In the NML schema [1] there is no direct inheritance between the two, although both subclass a Network Object (but so does a Node).

(I would actually like a BidirectionalLink to be a Link, but all attempt I did failed in logic: things like "isSource" and "isSink" would be ambiguous in the direction. So I stopped trying for now.)

Freek

[1] https://forge.ogf.org/sf/docman/do/downloadDocument/projects.nml-wg/docman.r...

W dniu 2012-07-20 15:31, Freek Dijkstra pisze:

On 19-07-2012 16:02, Roman Łapacz wrote:

...

An example updated. Available in the repo (nml-examples/201207-groups-and-labels). Any comments are welcome. Seems good, only a few small issues caught my eye:

...

<nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-out"/>

[...]

...

<nml:PortGroup id="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-out">

The all nml:Port for this object should be a nml:PortGroup.

I thought that Port inside Relation and BidirectionalPort can represent referenced PortGroup. I can change that.

At least, I presume you want to model the VLANs over these links, not necessarily the underling Ethernet layer?

Some holds for <nml:Link id="urn:ogf:network:domainx.net:2012:domainy-domainx"> (I think you want to model this as a LinkGroup).

I briefly wondered if the following is allowed, if you make this change, but I don't see why not:

...

<nml:BidirectionalLink id="urn:ogf:network:domainx.net:2012:domainx-domainy-domainx"> <nml:name>Link between domain x and domain y</nml:name> <nml:LinkGroup idRef="urn:ogf:network:domainx.net:2012:domainx-domainy"/> <nml:LinkGroup idRef="urn:ogf:network:domainx.net:2012:domainy-domainx"/> </nml:Link>

Seems reasonable because there's a range on vlans in this case.

Note that in your example, there is no cross connect between a VLAN in port ge-1/0/9 and VLAN 1501 of port ge-1/0/8. Not really suprising, since you have non-matching VLANS, but I wondered if this was on purpose.

Yes. I didn't want to do the cross in this example. But it can be presented in an other one (good candidate; I think the more examples presenting various setups the better). The file updated. Roman

Nice use of isAlias by the way.

...

(btw. I've done few minor updates in the RNC schema as well) Thanks. I still suck at reading RNC, so I'm going to read this in detail after two more iterations of the draft document.

Freek

On 11-07-2012 15:38, Roman Łapacz wrote:

W dniu 2012-07-11 15:26, Freek Dijkstra pisze:

...

On 11-07-2012 15:16, Roman Łapacz wrote:

...

<!-- COMMENT !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --> <!-- I propose to use new Relation="representedBy" --> <!--- when an object (in this case a Link can be represented by an other. Definition of them is the same! -->

<nml:BidirectionalLink id="urn:ogf:network:domainy.net:2012:domainx-domainy-domainx"> <nml:Relation type"http://schemas.ogf.org/nml/2012/07/relation/representedBy"> <nml:Link id="urn:ogf:network:domainx.net:2012:domainx-domainy-domainx"> <nml:Relation> </nml:Link>

I'm not (yet) sure what you mean with this definition. Can you elaborate a bit?

My first thought was that you meant an identity relation, like 'isAlias', but since these are two different objects, I guess it's something different. To me, a BidirectionalLink is just a grouping of two Links, with the (implicit) "hasLink" relation.

Perhaps a short example in words my help me understand.

The question is which domain name should be included in the URN of an inter-domain link. In this case domain x or domain y. One could say that one of those two (that's fine and I remember a discussion about this problem in the OGF meeting). But we could also create two bidirectional links and one of them is just an an alias (the best name but I wasn't sure if I can use it as I'm not 100% sure of the definition of isAlias used in the NSI example).

Ah, sorry I got confused because in the XML your relation was BidirectionalLink --(representedBy)--> Link instead of BidirectionalLink --(representedBy)--> BidirectionalLink It is now clear to me. I indeed think this is the same as an 'isAlias' relation. I don't have a solid definition at hand, but indeed it should be some sort of identity relation, which can be used for two different purposes: * The above: joining two identifiers given out by different organisations if they -for whatever reason- can not agree on a common identifier. * To add a level of indirection so that a more abstract identifier can be used externally while a more concrete identifier is used internally. E.g. the abstract "link-domainx-domainy" isAlias of the concrete "link-domainx-device-Ahc34-intf3.1-to-domainy-device-Bfg5-intf0.28" I'm not sure if we should use the "isAlias" relation for both purposes, but for now I don't see why not. Freek (PS: Sorry that my mail client is also messing up the example with it's wrapping. I recently moved back to Thunderbird, and came to the conclusion that all mail clients still suck. Offlist suggestions are appreciated.)