[Nml-wg] Simple example #1

[Freek Dijkstra]

On 10-07-2012 13:41, Roman Łapacz wrote:

>> 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.

In that case, I would probably make
"urn:ogf:network:domainx.net:2012:A_port_ge-0/2/9-in" a PortGroup:

>      <nml:PortGroup id="urn:ogf:network:domainx.net:2012:A_port_ge-0/2/9-in">
>         <nml:name> ....
>         <nml:label> ....
>      </nml:PortGroup>

It is possible to describe both the single Port that carries all VLANs
and to describe the PortGroup that contains all VLANs. Note the subtle
difference here: the second describes each individual VLAN. In here, the
VLAN ID is part of the header of the frame. The first Port describes the
underlying "sublayer" where all VLAN ID are part of the body of the
frames. So these are two things on a different (sub)layer.

In my view, it is easiest to just describe the PortGroup -- which is the
set of all VLANs, and not to describe the underlying ("physical") Port.
If you want, you can describe them all and related them with and
adaptation. To be specific: in https://forge.ogf.org/sf/go/artf6514
there is consensus to describe it as an Adaptation Service for the
egress interface and as a De-adaptation Service for the ingress interface.


>> 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
* 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