From vdham at uva.nl  Thu Feb  2 08:45:51 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 2 Feb 2012 14:45:51 +0100
Subject: [Nml-wg] Teleconference Feb 9th
Message-ID: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>

Hello,

Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam

I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?

Jeroen.

From vdham at uva.nl  Wed Feb  8 11:42:47 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Wed, 8 Feb 2012 17:42:47 +0100
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
Message-ID: <B10804AF-8B3F-4BFB-9959-A56319DE8BDC@uva.nl>


Reminder!


On 2 feb. 2012, at 14:45, Jeroen van der Ham <vdham at uva.nl> wrote:

> Hello,
> 
> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
> 
> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
> 
> Jeroen.
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

From chin at es.net  Wed Feb  8 12:33:42 2012
From: chin at es.net (Chin Guok)
Date: Wed, 08 Feb 2012 09:33:42 -0800
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <B10804AF-8B3F-4BFB-9959-A56319DE8BDC@uva.nl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
	<B10804AF-8B3F-4BFB-9959-A56319DE8BDC@uva.nl>
Message-ID: <4F32B1F6.2070507@es.net>

Unfortunately I won't be able to attend this call.  I'm in a Ciena 
training course all week and it goes from 8:30am - 4:30pm PT all days :(

- Chin

On 2/8/12 8:42 AM, Jeroen van der Ham wrote:
> Reminder!
>
>
> On 2 feb. 2012, at 14:45, Jeroen van der Ham<vdham at uva.nl>  wrote:
>
>> Hello,
>>
>> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
>> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
>>
>> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
>>
>> Jeroen.
>> _______________________________________________
>> 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

From zurawski at internet2.edu  Wed Feb  8 12:33:52 2012
From: zurawski at internet2.edu (Jason Zurawski)
Date: Wed, 08 Feb 2012 09:33:52 -0800
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <B10804AF-8B3F-4BFB-9959-A56319DE8BDC@uva.nl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
	<B10804AF-8B3F-4BFB-9959-A56319DE8BDC@uva.nl>
Message-ID: <4F32B200.1090201@internet2.edu>

Hi Jeroen;

I will be unable to make it tomorrow.

-jason

On 2/8/12 8:42 AM, thus spake Jeroen van der Ham:
>
> Reminder!
>
>
> On 2 feb. 2012, at 14:45, Jeroen van der Ham<vdham at uva.nl>  wrote:
>
>> Hello,
>>
>> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
>> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
>>
>> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
>>
>> Jeroen.
>> _______________________________________________
>> 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

From vdham at uva.nl  Thu Feb  9 10:59:13 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 9 Feb 2012 16:59:13 +0100
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
Message-ID: <8B41CBAF-1D5B-4646-94FB-67B9F118CD76@uva.nl>

For those who will join, here's the details again of the bridge:

Call: +1-734-615-7474 (Please use if you do not pay for Long Distance)
or +1-866-411-0013 (toll free US/Canada Only)
Enter access code: 0186145

Jeroen.

On 2 Feb 2012, at 14:45, Jeroen van der Ham wrote:

> Hello,
> 
> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
> 
> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
> 
> Jeroen.
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120209/73719631/attachment.pgp>

From vdham at uva.nl  Thu Feb  9 11:42:03 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 9 Feb 2012 17:42:03 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
Message-ID: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>

Hi,

Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI.

It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain.

Some terms used in the topology:
NSA: Network Service Agent, program that does the provisioning
NSNetwork: The Network that the NSA manages.
STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator.

Connectivity is only defined between networks, internally full connectivity is assumed.

Jeroen.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25.owl
Type: application/octet-stream
Size: 94178 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120209/d06487b6/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120209/d06487b6/attachment-0001.pgp>

From vdham at uva.nl  Thu Feb  9 11:49:50 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 9 Feb 2012 17:49:50 +0100
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
Message-ID: <7C8059A9-1AF6-4BA7-A6D7-43E3E627AA71@uva.nl>

Hello all,

My apologies, we started a bit early. For next time I'll make sure that I announce and join at the right time.

We had present on the call: Freek, Aaron and Roman. (Jerry joined at the later time)

We discussed progress in NSI, GLIF and Automated GOLE. We see an increasing need for an NML schema.
NSI has agreed on an STP format, which includes typed name-value pairs, which allow you to describe labels, technologies and all kinds of other things.
GLIF has stated that it will use NML soon. 

Jeroen suspects that there is not much requirement right now, because the GLIF questionnaire shows that most networks use some handcrafted topology format right now. Hopefully once we release something, we'll get usage, and from that feedback.

To speed things up, we have agreed to do weekly calls now.

Action points:
- Jeroen sends the Automated GOLE topology to the list as example (done)
- Jeroen sends the results of the GLIF questionnaire to the list.
- Freek will propose a notation for VLANs
- Jeroen will go through the current NML schema doc and gives an update on the status.

Next call is on Thursday February 16th.

Jeroen.


On 2 Feb 2012, at 14:45, Jeroen van der Ham wrote:

> Hello,
> 
> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
> 
> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
> 
> Jeroen.
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120209/a31566e6/attachment.pgp>

From vdham at uva.nl  Thu Feb  9 11:51:56 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 9 Feb 2012 17:51:56 +0100
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <7C8059A9-1AF6-4BA7-A6D7-43E3E627AA71@uva.nl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>
	<7C8059A9-1AF6-4BA7-A6D7-43E3E627AA71@uva.nl>
Message-ID: <303969E0-6BC1-41B3-A5A1-0791AD632B14@uva.nl>

Hi,
To add to that, the time of the next call will be:

UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam

Jeroen.

On 9 Feb 2012, at 17:49, Jeroen van der Ham wrote:

> Hello all,
> 
> My apologies, we started a bit early. For next time I'll make sure that I announce and join at the right time.
> 
> We had present on the call: Freek, Aaron and Roman. (Jerry joined at the later time)
> 
> We discussed progress in NSI, GLIF and Automated GOLE. We see an increasing need for an NML schema.
> NSI has agreed on an STP format, which includes typed name-value pairs, which allow you to describe labels, technologies and all kinds of other things.
> GLIF has stated that it will use NML soon. 
> 
> Jeroen suspects that there is not much requirement right now, because the GLIF questionnaire shows that most networks use some handcrafted topology format right now. Hopefully once we release something, we'll get usage, and from that feedback.
> 
> To speed things up, we have agreed to do weekly calls now.
> 
> Action points:
> - Jeroen sends the Automated GOLE topology to the list as example (done)
> - Jeroen sends the results of the GLIF questionnaire to the list.
> - Freek will propose a notation for VLANs
> - Jeroen will go through the current NML schema doc and gives an update on the status.
> 
> Next call is on Thursday February 16th.
> 
> Jeroen.
> 
> 
> On 2 Feb 2012, at 14:45, Jeroen van der Ham wrote:
> 
>> Hello,
>> 
>> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
>> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
>> 
>> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
>> 
>> Jeroen.
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120209/1954e005/attachment.pgp>

From vdham at uva.nl  Thu Feb  9 11:53:58 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 9 Feb 2012 17:53:58 +0100
Subject: [Nml-wg] Presentation on the GLIF questionnaire results
Message-ID: <E78C05E8-411A-4DCD-84D5-C70B5FA56668@uva.nl>

Hi,

As promised here are the results from the GLIF questionnaire.

Jeroen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DTOX-Questionnaire.pdf
Type: application/pdf
Size: 1054517 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120209/5d56fc13/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120209/5d56fc13/attachment-0001.pgp>

From romradz at man.poznan.pl  Mon Feb 13 10:32:32 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Mon, 13 Feb 2012 16:32:32 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
Message-ID: <4F392D10.8000509@man.poznan.pl>

W dniu 2012-02-09 17:42, Jeroen van der Ham pisze:
> Hi,

Hi Jeroen

if I'm not wrong the NSI group uses some tool to generate diagrams from 
such topology files. Is it possible to get a diagram based on the 
example file you sent?

Cheers,
Roman

> Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI.
>
> It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain.
>
> Some terms used in the topology:
> NSA: Network Service Agent, program that does the provisioning
> NSNetwork: The Network that the NSA manages.
> STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator.
>
> Connectivity is only defined between networks, internally full connectivity is assumed.
>
> Jeroen.
>
>
>
>
> _______________________________________________
> 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/20120213/fd264b25/attachment.html>

From vdham at uva.nl  Mon Feb 13 12:21:32 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Mon, 13 Feb 2012 18:21:32 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F392D10.8000509@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F392D10.8000509@man.poznan.pl>
Message-ID: <01295127-FD09-4762-B810-9CB2495EFD39@uva.nl>

Hi,

On 13 Feb 2012, at 16:32, Roman ?apacz wrote:
> if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent?


The Automated GOLE demo uses a similar editor available for the NML editor.
The Automated GOLE editor is available at: http://auto-gole.appspot.com

(The NML editor is available at http://nml-editor.appspot.com)

Jeroen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120213/4c387672/attachment.pgp>

From romradz at man.poznan.pl  Tue Feb 14 08:30:48 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Tue, 14 Feb 2012 14:30:48 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
Message-ID: <4F3A6208.6070807@man.poznan.pl>


Hi,

I'm sending you my first try of mapping owl topology desc into nml. 
Please, treat this as a start point for further discussion in order to 
get the final proposal for the NSI team.

Few comments:
- I've created a new namespace nml-nsi which groups NSI elements. This 
allows to avoid using type attribute to indicate that, for example, the 
network element represents the NS network.
- I had a problem with the STP element because in general I didn't want 
to introduce new names if it's not really needed. Finally, I found out 
(correct me if I'm wrong) that we can treat it as a port, but specific 
one and belonging to NSI namespace. This may be new to the NSI team but 
I hope it's only a matter of terminology and does not violate some basic 
functionality definitions.

An example I'm sending contains only the topology description of PIONIER 
(I didn't want to waste too much time for mapping all domains included 
in the owl file). I propose to focus on examples and later prepare the 
schema file (xsd or rnc; or both). This approach may speed up our work.

Cheers,
Roman


W dniu 2012-02-09 17:42, Jeroen van der Ham pisze:
> Hi,
>
> Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI.
>
> It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain.
>
> Some terms used in the topology:
> NSA: Network Service Agent, program that does the provisioning
> NSNetwork: The Network that the NSA manages.
> STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator.
>
> Connectivity is only defined between networks, internally full connectivity is assumed.
>
> Jeroen.
>
>
>
>
> _______________________________________________
> 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/20120214/c11d9b65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25-NML_example_v1.xml
Type: text/xml
Size: 5790 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120214/c11d9b65/attachment.xml>

From jerry at nordu.net  Tue Feb 14 08:35:38 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Tue, 14 Feb 2012 08:35:38 -0500
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <01295127-FD09-4762-B810-9CB2495EFD39@uva.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F392D10.8000509@man.poznan.pl>
	<01295127-FD09-4762-B810-9CB2495EFD39@uva.nl>
Message-ID: <4F3A632A.7020409@nordu.net>

Hi Roman  and everyone-

The topology that Jeroen distributed was the topo used last fall for our 
NSI demos.   And we did use the UvA SNE editor to initially create that 
topology.   And that version of the topo should still be compatible with 
SNE.

But the graphical representation created by SNE is not automatic - it is 
manually created by the individual building the topology...   Attached 
is the diagram we used for public consumption last fall.   A more useful 
approach (IMO) to learn NSI or to understand the AutoGOLE fabric than 
the SNE graphical display of this topology would be to look at any one 
NSI Network - say Netherlight.ets - in the diagram, and study its 
components in the OWL topology file to learn those relations to NSAs, 
STPs, location info, etc.   Once you understand the set of topological 
relations to one particular network, the other networks in the overall 
topology are simply repeated themes.   This high level top down approach 
to understanding the topology is much more effective than the SNE 
graphics IMO.  Indeed, I had to manually edit the SNE graphical layout 
(manually computing the coordinates of each object) in order to get a 
meaningful graphical display from the topology.  The SNE editor is a 
very basic tool.   And certain necessary topological relations cause 
graphical diagrams to get complex and busy very quickly.    So, the 
prospect of graphically editing any but the simplest topologies requires 
a rather inteligent editing tool that understands and uses the network 
semantics - not just RDF relations - to develop the graphical 
representation and manipulation interactions.

As the topology continues to get more complex it has become unwieldy to 
use the SNE editor in its current form to work on it.  So the topo 
releases we are moving to this spring are not built using SNE.   The 
rest of the OWL topology representation is the same, and I am pretty 
sure SNE can still be used to process it, but these other 
semantic/graphical issues make the SNE tool less useful than it might be 
for building more complex network topologies.  NOTE:  SNE is the only 
tool I know that understand the OWL data format and so I believe it 
might be more useful for representing RDF semantic relations rather than 
building network topologies per se...so don't take this critique of SNE 
as a swipe at it...we just need a tool more aimed at network service 
architectures than semantic web applications.   I always think of 
CASE/CAE tools, or an object oriented approach, as a potentially more 
effective GUI model.

We *do* need some sort of graphical editor for managing large scale 
topological information, but we need some editing features that are not 
currently available in SNE (or any other similar topology tool AFAIK).  
These would include graphical sumarization and layering (not just 
hardware, but service layering, control plane layers, etc.), 
auto-routing/placement that "makes sense" within the semantic context of 
the objects and that minimizes visual clutter, color coding would be 
useful, groupings and graphical object editing ala Powerpoint or the 
like, etc.   These are largely human-interface/presentation issues, some 
graphical bugs resolved, etc., but nevertheless these features are why 
we want graphical editors for this task, and these would make graphical 
management of topologies much more intuitive and efficient - and thus used.

I would suggest that if you are starting out to create a basic topology 
from scratch, the SNE editor is very good place to begin.  It works fine 
for a basic not-too-complex topology and generates an OWL file with all 
the headers required for this data representation form.  You can learn a 
fair bit about NSI by building some simple topologies using SNE.   And 
then you can study the resulting OWL output and extend the topology 
using SNE or other conventional editing tools or auto-generating scripts 
to generate larger more complex OWL based topologies.   And I think you 
can still feed those auto-generated topologies into SNE for a rough 
validation.   (There may be other ways to validate an OWL topology file 
I am not aware of...Jeroen?  Any thoughts on this?)

Just some observations...
Jerry

On 2/13/12 12:21 PM, Jeroen van der Ham wrote:
> Hi,
>
> On 13 Feb 2012, at 16:32, Roman ?apacz wrote:
>> if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent?
>
> The Automated GOLE demo uses a similar editor available for the NML editor.
> The Automated GOLE editor is available at: http://auto-gole.appspot.com
>
> (The NML editor is available at http://nml-editor.appspot.com)
>
> Jeroen.
>
>
> _______________________________________________
> 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/20120214/9a8a9de0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SC2011 Demo Diag v5d captioned.pptx.pdf
Type: application/pdf
Size: 955556 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120214/9a8a9de0/attachment-0001.pdf>

From romradz at man.poznan.pl  Tue Feb 14 09:00:00 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Tue, 14 Feb 2012 15:00:00 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3A632A.7020409@nordu.net>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F392D10.8000509@man.poznan.pl>
	<01295127-FD09-4762-B810-9CB2495EFD39@uva.nl>
	<4F3A632A.7020409@nordu.net>
Message-ID: <4F3A68E0.8000708@man.poznan.pl>


Thanks Jerry. When I took a look at the example Jeroen sent I thought 
that it would be difficult to analyse it. Too much information, 
especially for me who was not involved in the NSI discussion. That is 
why I asked for a tool to see the whole picture in a simple way. But 
today I analysed the PIONIER part in that file and I think I understand 
(other sections only repeat constructions with content relevant to other 
domains).

Cheers,
Roman

W dniu 2012-02-14 14:35, Jerry Sobieski pisze:
> Hi Roman  and everyone-
>
> The topology that Jeroen distributed was the topo used last fall for 
> our NSI demos.   And we did use the UvA SNE editor to initially create 
> that topology.   And that version of the topo should still be 
> compatible with SNE.
>
> But the graphical representation created by SNE is not automatic - it 
> is manually created by the individual building the topology...   
> Attached is the diagram we used for public consumption last fall.   A 
> more useful approach (IMO) to learn NSI or to understand the AutoGOLE 
> fabric than the SNE graphical display of this topology would be to 
> look at any one NSI Network - say Netherlight.ets - in the diagram, 
> and study its components in the OWL topology file to learn those 
> relations to NSAs, STPs, location info, etc.   Once you understand the 
> set of topological relations to one particular network, the other 
> networks in the overall topology are simply repeated themes.   This 
> high level top down approach to understanding the topology is much 
> more effective than the SNE graphics IMO.  Indeed, I had to manually 
> edit the SNE graphical layout (manually computing the coordinates of 
> each object) in order to get a meaningful graphical display from the 
> topology.  The SNE editor is a very basic tool.   And certain 
> necessary topological relations cause graphical diagrams to get 
> complex and busy very quickly.    So, the prospect of graphically 
> editing any but the simplest topologies requires a rather inteligent 
> editing tool that understands and uses the network semantics - not 
> just RDF relations - to develop the graphical representation and 
> manipulation interactions.
>
> As the topology continues to get more complex it has become unwieldy 
> to use the SNE editor in its current form to work on it.  So the topo 
> releases we are moving to this spring are not built using SNE.   The 
> rest of the OWL topology representation is the same, and I am pretty 
> sure SNE can still be used to process it, but these other 
> semantic/graphical issues make the SNE tool less useful than it might 
> be for building more complex network topologies.  NOTE:  SNE is the 
> only tool I know that understand the OWL data format and so I believe 
> it might be more useful for representing RDF semantic relations rather 
> than building network topologies per se...so don't take this critique 
> of SNE as a swipe at it...we just need a tool more aimed at network 
> service architectures than semantic web applications.   I always think 
> of CASE/CAE tools, or an object oriented approach, as a potentially 
> more effective GUI model.
>
> We *do* need some sort of graphical editor for managing large scale 
> topological information, but we need some editing features that are 
> not currently available in SNE (or any other similar topology tool 
> AFAIK).  These would include graphical sumarization and layering (not 
> just hardware, but service layering, control plane layers, etc.), 
> auto-routing/placement that "makes sense" within the semantic context 
> of the objects and that minimizes visual clutter, color coding would 
> be useful, groupings and graphical object editing ala Powerpoint or 
> the like, etc.   These are largely human-interface/presentation 
> issues, some graphical bugs resolved, etc., but nevertheless these 
> features are why we want graphical editors for this task, and these 
> would make graphical management of topologies much more intuitive and 
> efficient - and thus used.
>
> I would suggest that if you are starting out to create a basic 
> topology from scratch, the SNE editor is very good place to begin.  It 
> works fine for a basic not-too-complex topology and generates an OWL 
> file with all the headers required for this data representation form.  
> You can learn a fair bit about NSI by building some simple topologies 
> using SNE.   And then you can study the resulting OWL output and 
> extend the topology using SNE or other conventional editing tools or 
> auto-generating scripts to generate larger more complex OWL based 
> topologies.   And I think you can still feed those auto-generated 
> topologies into SNE for a rough validation.   (There may be other ways 
> to validate an OWL topology file I am not aware of...Jeroen?  Any 
> thoughts on this?)
>
> Just some observations...
> Jerry
>
> On 2/13/12 12:21 PM, Jeroen van der Ham wrote:
>> Hi,
>>
>> On 13 Feb 2012, at 16:32, Roman ?apacz wrote:
>>> if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent?
>> The Automated GOLE demo uses a similar editor available for the NML editor.
>> The Automated GOLE editor is available at:http://auto-gole.appspot.com
>>
>> (The NML editor is available athttp://nml-editor.appspot.com)
>>
>> Jeroen.
>>
>>
>> _______________________________________________
>> 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/20120214/3cf24f40/attachment.html>

From romradz at man.poznan.pl  Tue Feb 14 09:11:04 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Tue, 14 Feb 2012 15:11:04 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3A6208.6070807@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
Message-ID: <4F3A6B78.3010204@man.poznan.pl>


forgive me my mistakes with </nml-nsi: ....> . It should be of course 
<nml-nsi: .... />

Roman

W dniu 2012-02-14 14:30, Roman ?apacz pisze:
>
> Hi,
>
> I'm sending you my first try of mapping owl topology desc into nml. 
> Please, treat this as a start point for further discussion in order to 
> get the final proposal for the NSI team.
>
> Few comments:
> - I've created a new namespace nml-nsi which groups NSI elements. This 
> allows to avoid using type attribute to indicate that, for example, 
> the network element represents the NS network.
> - I had a problem with the STP element because in general I didn't 
> want to introduce new names if it's not really needed. Finally, I 
> found out (correct me if I'm wrong) that we can treat it as a port, 
> but specific one and belonging to NSI namespace. This may be new to 
> the NSI team but I hope it's only a matter of terminology and does not 
> violate some basic functionality definitions.
>
> An example I'm sending contains only the topology description of 
> PIONIER (I didn't want to waste too much time for mapping all domains 
> included in the owl file). I propose to focus on examples and later 
> prepare the schema file (xsd or rnc; or both). This approach may speed 
> up our work.
>
> Cheers,
> Roman
>
>
> W dniu 2012-02-09 17:42, Jeroen van der Ham pisze:
>> Hi,
>>
>> Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI.
>>
>> It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain.
>>
>> Some terms used in the topology:
>> NSA: Network Service Agent, program that does the provisioning
>> NSNetwork: The Network that the NSA manages.
>> STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator.
>>
>> Connectivity is only defined between networks, internally full connectivity is assumed.
>>
>> Jeroen.
>>
>>
>>
>>
>> _______________________________________________
>> 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/20120214/040f9e31/attachment.html>

From vdham at uva.nl  Wed Feb 15 05:47:06 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Wed, 15 Feb 2012 11:47:06 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3A6208.6070807@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
Message-ID: <9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>

Hi,

On 14 Feb 2012, at 14:30, Roman ?apacz wrote:

> - I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network.

Seems sensible to me.

> - I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions.

I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.

> An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work.

I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.

On to the comments for your description:

- You're using <nml:relation type="next"> to describe connections, this should be <nml:relation type="connectedTo">.
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.

Jeroen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120215/37c69bd4/attachment.pgp>

From romradz at man.poznan.pl  Wed Feb 15 06:31:38 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Wed, 15 Feb 2012 12:31:38 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
Message-ID: <4F3B979A.1090806@man.poznan.pl>

W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
> Hi,
>
> On 14 Feb 2012, at 14:30, Roman ?apacz wrote:
>
>> - I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network.
> Seems sensible to me.
>
>> - I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions.
> I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
>
>> An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work.
> I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.
>
> On to the comments for your description:
>
> - You're using<nml:relation type="next">  to describe connections, this should be<nml:relation type="connectedTo">.

I proposed "next" because it was already used in the framework for 
circuit monitoring. I'm hesitating to introduce an other name which 
means the same (1. as I wrote I try to limit new names; 2. use of new 
name would be incompatible or inconsistent with that solution for 
circuit monitoring).  On the other hand, "connectedTo" is already used 
by NSI so I understand that some continuation is welcome. If you think 
that it's really important to keep "connectedTo" then I'm fine.

> - We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.

I'll try to find something. Any suggestions are welcome.

Roman

> Jeroen.


From vdham at uva.nl  Wed Feb 15 07:20:37 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Wed, 15 Feb 2012 13:20:37 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3B979A.1090806@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl>
Message-ID: <C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>

On 15 Feb 2012, at 12:31, Roman ?apacz wrote:
>> On to the comments for your description:
>> 
>> - You're using<nml:relation type="next">  to describe connections, this should be<nml:relation type="connectedTo">.
> 
> I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring).  On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.

We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.

>> - We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
> 
> I'll try to find something. Any suggestions are welcome.

There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think.
There's also the vCard standard, for which there is (I think) both an RDF and XML notation.

Jeroen.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120215/ad2e0548/attachment.pgp>

From romradz at man.poznan.pl  Wed Feb 15 07:41:37 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Wed, 15 Feb 2012 13:41:37 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl>
	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>
Message-ID: <4F3BA801.8010407@man.poznan.pl>

W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
> On 15 Feb 2012, at 12:31, Roman ?apacz wrote:
>>> On to the comments for your description:
>>>
>>> - You're using<nml:relation type="next">   to describe connections, this should be<nml:relation type="connectedTo">.
>> I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring).  On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
> We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.

Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the 
nml-nsi namespace would be STP).  "connectedTo" would work, no doubt, 
but the question is: should we use this if we already used "next" in 
circuit monitoring (and both mean the same).

>>> - We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
>> I'll try to find something. Any suggestions are welcome.
> There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think.
> There's also the vCard standard, for which there is (I think) both an RDF and XML notation.

yes, vCard was my first candidate as well
http://tools.ietf.org/html/rfc6351

Roman

> Jeroen.
>


From jerry at nordu.net  Wed Feb 15 08:08:59 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 15 Feb 2012 08:08:59 -0500
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3B979A.1090806@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl>
Message-ID: <4F3BAE6B.6030706@nordu.net>

Could we have a Skype call to dscuss this...I am not following the whole 
proposal here - proabably because I am not clear on the NML 
constructs...  We need some examples.

I am available this afternoon (EST) after the NSI call.

Thanks
Jerry

On 2/15/12 6:31 AM, Roman ?apacz wrote:
> W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
>> Hi,
>>
>> On 14 Feb 2012, at 14:30, Roman ?apacz wrote:
>>
>>> - I've created a new namespace nml-nsi which groups NSI elements. 
>>> This allows to avoid using type attribute to indicate that, for 
>>> example, the network element represents the NS network.
>> Seems sensible to me.
>>
>>> - I had a problem with the STP element because in general I didn't 
>>> want to introduce new names if it's not really needed. Finally, I 
>>> found out (correct me if I'm wrong) that we can treat it as a port, 
>>> but specific one and belonging to NSI namespace. This may be new to 
>>> the NSI team but I hope it's only a matter of terminology and does 
>>> not violate some basic functionality definitions.
>> I think that that is correct. An STP is a specialized form of a Port, 
>> one that is used to define the boundary between an intra-domain 
>> network service and some other service. This can be an inter-domain 
>> network service, or something like a PerfSonar server.
>>
>>> An example I'm sending contains only the topology description of 
>>> PIONIER (I didn't want to waste too much time for mapping all 
>>> domains included in the owl file). I propose to focus on examples 
>>> and later prepare the schema file (xsd or rnc; or both). This 
>>> approach may speed up our work.
>> I agree. Most domains are roughly equal in setup, and certainly equal 
>> in constructs. Doing this for one domain is fine.
>>
>> On to the comments for your description:
>>
>> - You're using<nml:relation type="next">  to describe connections, 
>> this should be<nml:relation type="connectedTo">.
>
> I proposed "next" because it was already used in the framework for 
> circuit monitoring. I'm hesitating to introduce an other name which 
> means the same (1. as I wrote I try to limit new names; 2. use of new 
> name would be incompatible or inconsistent with that solution for 
> circuit monitoring).  On the other hand, "connectedTo" is already used 
> by NSI so I understand that some continuation is welcome. If you think 
> that it's really important to keep "connectedTo" then I'm fine.
>
>> - We don't have an nml:contact object at the moment, but it seems 
>> that we may indeed need one. However, defining the contact methods 
>> should perhaps be done using some other appropriate (standard) schema.
>
> I'll try to find something. Any suggestions are welcome.
>
> Roman
>
>> Jeroen.
>
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

From jerry at nordu.net  Wed Feb 15 08:12:47 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 15 Feb 2012 08:12:47 -0500
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BA801.8010407@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl>
	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>
	<4F3BA801.8010407@man.poznan.pl>
Message-ID: <4F3BAF4F.8040303@nordu.net>

I am very nervous about this - we deliberatly did *NOT* use "port" in 
NSI because of the overloaded connotation. The Service Termination Point 
in NSI is *not* a port. ...not in the physical sense.   So we need to 
understand what a NML "port" represents.

Was there an example for this?

Thanks!
Jerry

On 2/15/12 7:41 AM, Roman ?apacz wrote:
> W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
>> On 15 Feb 2012, at 12:31, Roman ?apacz wrote:
>>>> On to the comments for your description:
>>>>
>>>> - You're using<nml:relation type="next">   to describe connections, 
>>>> this should be<nml:relation type="connectedTo">.
>>> I proposed "next" because it was already used in the framework for 
>>> circuit monitoring. I'm hesitating to introduce an other name which 
>>> means the same (1. as I wrote I try to limit new names; 2. use of 
>>> new name would be incompatible or inconsistent with that solution 
>>> for circuit monitoring).  On the other hand, "connectedTo" is 
>>> already used by NSI so I understand that some continuation is 
>>> welcome. If you think that it's really important to keep 
>>> "connectedTo" then I'm fine.
>> We're already saying that an nml-nsi:STP is equivalent to an nml:Port 
>> with some added behavior. I don't really see any reason why 
>> connectedTo would not work in this case.
>
> Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the 
> nml-nsi namespace would be STP).  "connectedTo" would work, no doubt, 
> but the question is: should we use this if we already used "next" in 
> circuit monitoring (and both mean the same).
>
>>>> - We don't have an nml:contact object at the moment, but it seems 
>>>> that we may indeed need one. However, defining the contact methods 
>>>> should perhaps be done using some other appropriate (standard) schema.
>>> I'll try to find something. Any suggestions are welcome.
>> There's a FOAF namespace in RDF which describes similar things about 
>> a person. However, it's not really a standard I think.
>> There's also the vCard standard, for which there is (I think) both an 
>> RDF and XML notation.
>
> yes, vCard was my first candidate as well
> http://tools.ietf.org/html/rfc6351
>
> Roman
>
>> Jeroen.
>>
>
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

From romradz at man.poznan.pl  Wed Feb 15 08:18:10 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Wed, 15 Feb 2012 14:18:10 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BAE6B.6030706@nordu.net>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl> <4F3BAE6B.6030706@nordu.net>
Message-ID: <4F3BB092.7050200@man.poznan.pl>

Hi,

tomorrow we've got the NML conf call. Can we discuss it then?

Roman

W dniu 2012-02-15 14:08, Jerry Sobieski pisze:
> Could we have a Skype call to dscuss this...I am not following the 
> whole proposal here - proabably because I am not clear on the NML 
> constructs...  We need some examples.
>
> I am available this afternoon (EST) after the NSI call.
>
> Thanks
> Jerry
>
> On 2/15/12 6:31 AM, Roman ?apacz wrote:
>> W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
>>> Hi,
>>>
>>> On 14 Feb 2012, at 14:30, Roman ?apacz wrote:
>>>
>>>> - I've created a new namespace nml-nsi which groups NSI elements. 
>>>> This allows to avoid using type attribute to indicate that, for 
>>>> example, the network element represents the NS network.
>>> Seems sensible to me.
>>>
>>>> - I had a problem with the STP element because in general I didn't 
>>>> want to introduce new names if it's not really needed. Finally, I 
>>>> found out (correct me if I'm wrong) that we can treat it as a port, 
>>>> but specific one and belonging to NSI namespace. This may be new to 
>>>> the NSI team but I hope it's only a matter of terminology and does 
>>>> not violate some basic functionality definitions.
>>> I think that that is correct. An STP is a specialized form of a 
>>> Port, one that is used to define the boundary between an 
>>> intra-domain network service and some other service. This can be an 
>>> inter-domain network service, or something like a PerfSonar server.
>>>
>>>> An example I'm sending contains only the topology description of 
>>>> PIONIER (I didn't want to waste too much time for mapping all 
>>>> domains included in the owl file). I propose to focus on examples 
>>>> and later prepare the schema file (xsd or rnc; or both). This 
>>>> approach may speed up our work.
>>> I agree. Most domains are roughly equal in setup, and certainly 
>>> equal in constructs. Doing this for one domain is fine.
>>>
>>> On to the comments for your description:
>>>
>>> - You're using<nml:relation type="next">  to describe connections, 
>>> this should be<nml:relation type="connectedTo">.
>>
>> I proposed "next" because it was already used in the framework for 
>> circuit monitoring. I'm hesitating to introduce an other name which 
>> means the same (1. as I wrote I try to limit new names; 2. use of new 
>> name would be incompatible or inconsistent with that solution for 
>> circuit monitoring).  On the other hand, "connectedTo" is already 
>> used by NSI so I understand that some continuation is welcome. If you 
>> think that it's really important to keep "connectedTo" then I'm fine.
>>
>>> - We don't have an nml:contact object at the moment, but it seems 
>>> that we may indeed need one. However, defining the contact methods 
>>> should perhaps be done using some other appropriate (standard) schema.
>>
>> I'll try to find something. Any suggestions are welcome.
>>
>> Roman
>>
>>> Jeroen.
>>
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg


From vdham at uva.nl  Wed Feb 15 08:22:18 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Wed, 15 Feb 2012 14:22:18 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BAE6B.6030706@nordu.net>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl> <4F3BAE6B.6030706@nordu.net>
Message-ID: <F0897137-3C88-45E2-B5B7-7F591F38EBBD@uva.nl>

We can certainly put this on the agenda for the NML call tomorrow.

In the meantime: the current NML schema is still available at https://forge.ogf.org/sf/go/doc15481?nav=1


Jeroen.

On 15 Feb 2012, at 14:08, Jerry Sobieski wrote:

> Could we have a Skype call to dscuss this...I am not following the whole proposal here - proabably because I am not clear on the NML constructs...  We need some examples.
> 
> I am available this afternoon (EST) after the NSI call.
> 
> Thanks
> Jerry
> 
> On 2/15/12 6:31 AM, Roman ?apacz wrote:
>> W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
>>> Hi,
>>> 
>>> On 14 Feb 2012, at 14:30, Roman ?apacz wrote:
>>> 
>>>> - I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network.
>>> Seems sensible to me.
>>> 
>>>> - I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions.
>>> I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
>>> 
>>>> An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work.
>>> I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.
>>> 
>>> On to the comments for your description:
>>> 
>>> - You're using<nml:relation type="next">  to describe connections, this should be<nml:relation type="connectedTo">.
>> 
>> I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring).  On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
>> 
>>> - We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
>> 
>> I'll try to find something. Any suggestions are welcome.
>> 
>> Roman
>> 
>>> Jeroen.
>> 
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120215/2217cf8f/attachment.pgp>

From romradz at man.poznan.pl  Wed Feb 15 08:24:44 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Wed, 15 Feb 2012 14:24:44 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BAF4F.8040303@nordu.net>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl>
	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>
	<4F3BA801.8010407@man.poznan.pl> <4F3BAF4F.8040303@nordu.net>
Message-ID: <4F3BB21C.7090804@man.poznan.pl>

W dniu 2012-02-15 14:12, Jerry Sobieski pisze:
> I am very nervous about this - we deliberatly did *NOT* use "port" in 
> NSI because of the overloaded connotation. The Service Termination 
> Point in NSI is *not* a port. ...not in the physical sense.   So we 
> need to understand what a NML "port" represents.

port in the nml-nsi namespace is not physical. This is an abstraction 
and represents STP. We could introduce new element nml-nsi:stp but is it 
really necessary?

Roman

>
> Was there an example for this?
>
> Thanks!
> Jerry
>
> On 2/15/12 7:41 AM, Roman ?apacz wrote:
>> W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
>>> On 15 Feb 2012, at 12:31, Roman ?apacz wrote:
>>>>> On to the comments for your description:
>>>>>
>>>>> - You're using<nml:relation type="next">   to describe 
>>>>> connections, this should be<nml:relation type="connectedTo">.
>>>> I proposed "next" because it was already used in the framework for 
>>>> circuit monitoring. I'm hesitating to introduce an other name which 
>>>> means the same (1. as I wrote I try to limit new names; 2. use of 
>>>> new name would be incompatible or inconsistent with that solution 
>>>> for circuit monitoring).  On the other hand, "connectedTo" is 
>>>> already used by NSI so I understand that some continuation is 
>>>> welcome. If you think that it's really important to keep 
>>>> "connectedTo" then I'm fine.
>>> We're already saying that an nml-nsi:STP is equivalent to an 
>>> nml:Port with some added behavior. I don't really see any reason why 
>>> connectedTo would not work in this case.
>>
>> Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the 
>> nml-nsi namespace would be STP).  "connectedTo" would work, no doubt, 
>> but the question is: should we use this if we already used "next" in 
>> circuit monitoring (and both mean the same).
>>
>>>>> - We don't have an nml:contact object at the moment, but it seems 
>>>>> that we may indeed need one. However, defining the contact methods 
>>>>> should perhaps be done using some other appropriate (standard) 
>>>>> schema.
>>>> I'll try to find something. Any suggestions are welcome.
>>> There's a FOAF namespace in RDF which describes similar things about 
>>> a person. However, it's not really a standard I think.
>>> There's also the vCard standard, for which there is (I think) both 
>>> an RDF and XML notation.
>>
>> yes, vCard was my first candidate as well
>> http://tools.ietf.org/html/rfc6351
>>
>> Roman
>>
>>> Jeroen.
>>>
>>
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg


From jerry at nordu.net  Wed Feb 15 08:39:08 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 15 Feb 2012 08:39:08 -0500
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BB092.7050200@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl> <4F3BAE6B.6030706@nordu.net>
	<4F3BB092.7050200@man.poznan.pl>
Message-ID: <4F3BB57C.8010403@nordu.net>

Sure - thats a good idea:-)   (Duh!)

Thanks Roman!
J

On 2/15/12 8:18 AM, Roman ?apacz wrote:
> Hi,
>
> tomorrow we've got the NML conf call. Can we discuss it then?
>
> Roman
>
> W dniu 2012-02-15 14:08, Jerry Sobieski pisze:
>> Could we have a Skype call to dscuss this...I am not following the 
>> whole proposal here - proabably because I am not clear on the NML 
>> constructs...  We need some examples.
>>
>> I am available this afternoon (EST) after the NSI call.
>>
>> Thanks
>> Jerry
>>
>> On 2/15/12 6:31 AM, Roman ?apacz wrote:
>>> W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
>>>> Hi,
>>>>
>>>> On 14 Feb 2012, at 14:30, Roman ?apacz wrote:
>>>>
>>>>> - I've created a new namespace nml-nsi which groups NSI elements. 
>>>>> This allows to avoid using type attribute to indicate that, for 
>>>>> example, the network element represents the NS network.
>>>> Seems sensible to me.
>>>>
>>>>> - I had a problem with the STP element because in general I didn't 
>>>>> want to introduce new names if it's not really needed. Finally, I 
>>>>> found out (correct me if I'm wrong) that we can treat it as a 
>>>>> port, but specific one and belonging to NSI namespace. This may be 
>>>>> new to the NSI team but I hope it's only a matter of terminology 
>>>>> and does not violate some basic functionality definitions.
>>>> I think that that is correct. An STP is a specialized form of a 
>>>> Port, one that is used to define the boundary between an 
>>>> intra-domain network service and some other service. This can be an 
>>>> inter-domain network service, or something like a PerfSonar server.
>>>>
>>>>> An example I'm sending contains only the topology description of 
>>>>> PIONIER (I didn't want to waste too much time for mapping all 
>>>>> domains included in the owl file). I propose to focus on examples 
>>>>> and later prepare the schema file (xsd or rnc; or both). This 
>>>>> approach may speed up our work.
>>>> I agree. Most domains are roughly equal in setup, and certainly 
>>>> equal in constructs. Doing this for one domain is fine.
>>>>
>>>> On to the comments for your description:
>>>>
>>>> - You're using<nml:relation type="next">  to describe connections, 
>>>> this should be<nml:relation type="connectedTo">.
>>>
>>> I proposed "next" because it was already used in the framework for 
>>> circuit monitoring. I'm hesitating to introduce an other name which 
>>> means the same (1. as I wrote I try to limit new names; 2. use of 
>>> new name would be incompatible or inconsistent with that solution 
>>> for circuit monitoring).  On the other hand, "connectedTo" is 
>>> already used by NSI so I understand that some continuation is 
>>> welcome. If you think that it's really important to keep 
>>> "connectedTo" then I'm fine.
>>>
>>>> - We don't have an nml:contact object at the moment, but it seems 
>>>> that we may indeed need one. However, defining the contact methods 
>>>> should perhaps be done using some other appropriate (standard) schema.
>>>
>>> I'll try to find something. Any suggestions are welcome.
>>>
>>> Roman
>>>
>>>> Jeroen.
>>>
>>> _______________________________________________
>>> nml-wg mailing list
>>> nml-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nml-wg
>

From Freek.Dijkstra at sara.nl  Wed Feb 15 09:25:37 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 15 Feb 2012 15:25:37 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BAF4F.8040303@nordu.net>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>	<4F3A6208.6070807@man.poznan.pl>	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>	<4F3B979A.1090806@man.poznan.pl>	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>	<4F3BA801.8010407@man.poznan.pl>
	<4F3BAF4F.8040303@nordu.net>
Message-ID: <4F3BC061.80407@sara.nl>

Jerry Sobieski wrote:

> I am very nervous about this - we deliberatly did *NOT* use "port" in 
> NSI because of the overloaded connotation. The Service Termination Point 
> in NSI is *not* a port. ...not in the physical sense.   So we need to 
> understand what a NML "port" represents.

Indeed the term "Port" is overloaded, but so are (unfortunately) other
terms. We had multiple (very long) discussion on the exact term to use,
and we closed the discussion by reaching working group consensus onn "Port".

An NML "port" is equivalent to a G.800 "Forwarding Point" (or G.805
"Connection Point").

I usually refer to it as a "logical interface", to clearly distinguish
it from a "physical interface". G.805 defines it as 'A "reference point"
that consists of a pair of co-located "unidirectional connection points"
and therefore represents the binding of two paired bidirectional
"connections".'

You will note from this definition that in G.800, two "Ports" connected
together form a "Point", I think this is similar to a NSI STP and SDP.
>From discussion we had with people involved in the ITU, most people
nowadays consider this distinction unnecessary, since there is only
rarely the need to differentiate between the G.800 "Port" and G.800
"Point" when it comes to topology descriptions (in fact I do not know of
any use case where the distinction is required -- I would love to hear
about one).

Regards,
Freek

From Freek.Dijkstra at sara.nl  Wed Feb 15 09:31:35 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 15 Feb 2012 15:31:35 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BC061.80407@sara.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>	<4F3A6208.6070807@man.poznan.pl>	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>	<4F3B979A.1090806@man.poznan.pl>	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>	<4F3BA801.8010407@man.poznan.pl>	<4F3BAF4F.8040303@nordu.net>
	<4F3BC061.80407@sara.nl>
Message-ID: <4F3BC1C7.4080700@sara.nl>

Freek Dijkstra wrote:

> An NML "port" is equivalent to a G.800 "Forwarding Point" (or G.805
> "Connection Point").
> 
> I usually refer to it as a "logical interface", to clearly distinguish
> it from a "physical interface".

FYI, NML has no term or concept for a "physical interface" or "physical
port" other than to define it as a (logical) port on the Fiber layer.

However, that concept would not include the full complexity of a
physical port (e.g. adaptations to link connections on higher layers
whose data pass through the physical interface, or the exact position in
a device where the XFP is plugged in).

If it is useful to add this concept of "physical port" next to the
current "Port" (which is a logical connection point), I'm happy to hear
about a use-case or a proposal.

Freek

From jerry at nordu.net  Wed Feb 15 09:56:56 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 15 Feb 2012 09:56:56 -0500
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BB21C.7090804@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl>
	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>
	<4F3BA801.8010407@man.poznan.pl> <4F3BAF4F.8040303@nordu.net>
	<4F3BB21C.7090804@man.poznan.pl>
Message-ID: <4F3BC7B8.2080607@nordu.net>


On 2/15/12 8:24 AM, Roman ?apacz wrote:
> W dniu 2012-02-15 14:12, Jerry Sobieski pisze:
>> I am very nervous about this - we deliberatly did *NOT* use "port" in 
>> NSI because of the overloaded connotation. The Service Termination 
>> Point in NSI is *not* a port. ...not in the physical sense.   So we 
>> need to understand what a NML "port" represents.
>
> port in the nml-nsi namespace is not physical. This is an abstraction 
> and represents STP. We could introduce new element nml-nsi:stp but is 
> it really necessary?
>
Ah, ok...the abstraction is good.  (Thanks both Roman and Freek in 
explaining this.)   This was much of my concern.    But lets discuss 
tomorrow in more detail as there are still some other aspects of NML 
"ports" we need to understand/reconcile.

Some further background on NSI notions:

In NSI, the STP is indeed an interface at the edge of a network service 
domain - it identifies uniquely where user data enters or exits a 
service domain.   The STPs associated with a network service define the 
boundary of that NSI service domain.    STPs "mapTo" an internally 
defined tuple that represents the internal specifics associated with 
that Service Termination Point.   For instance, an STP 
"NorthernLight:ams-80" would mapTo <switch, mx80-CPH>, <blade, 0>, 
<port, 2>, <vlan, 1780>.   This entire tuple is the internal topological 
information represented by that STP.   (Note- the internal tuple 
specification is a local network internal issue relevant to the specific 
infrastructure or software being used.)

Inter-domain peering between two networks is expressed via a Service 
Demarcation Point "SDP".   An SDP pairs two corresponding STPs - one in 
each network.   SDPs indicate adjacencies between NSI network services, 
and differentiate the paths that exist between two networks (or that 
originate or terminate at a network.)   SDPs are *not* physical links 
(circuits, fibers, etc) between networks - SDPs are /relations/ that 
identify a common topological interface between two domains - i.e. the 
two STPs that are part of an SDP represent the *same* topological 
location - albeit from different name spaces and with different internal 
mapsTo info.  For example, an SDP might look like this: < 
NorthernLight:ams-80, NetherLight:cph-80 >   In the OWL topology, this 
SDP would be expressed as NorthernLight:ams-80 "connectsTo" 
NetherLight:cph-80.   Thus it is found in an NorthernLight:ams-80 STP 
object.  A similar SDP would be defined in the NetherLight domain.   
These STP names are just strings, but they "mapTo" the internal physical 
details of the terminus, and they "connectTo" the corresponding STP in 
another network.   (Note:  NSI is developing an "enumeration" construct 
that will allow a compact SDP representation of large groups of peering 
STPs...e.g. where two networks terminate a physical link that carries 
large number of VLAN IDs. perhaps we can discuss this too at the NML 
call thursday.?)

If an STP does not have a corresponding STP in another NSI network - for 
example where the remote side is an end host that does not participate 
in NSI - there is just no "connectsTo" relation, i.e no SDP.   In our 
AutoGOLE topology, these are how we represent the perfSonar nodes.

Note that these STPs and SDPs are expressly technology agnostic.  The 
physical details are held internally to each network NSA in the "mapsTo" 
relation and the internal topology DB.    I think what we nee to now do 
with NML and NSI is that we want to express these NSI topological 
constructs and the NML constructs using a common form (the NML 
representation is what we currently believe to be the right approach), 
without breaking the semantics that NSI requires to remain secure and 
autonomous.  At the same time, we want to enable a network announce much 
more topology if they wish - We'd like both of these aspects to be a 
well integrated common representational model that syntactically 
functions smoothly together.  Thus a NSA would announce the NSI service 
domain (presumably using an NML representation), and if they wish, they 
can include more details of internal structure using further - perhaps 
more technology specific -  NML constructs.   Ideally, all of this 
announcement would be a common structure syntactically, and hopefully 
semantically as well.   This would simplify implementations - 
partcularly in furture virtual worlds...   But we *must* maintain the 
NSI topological model of STPs and SDPs and Networks and NSAs etc (though 
we might elect to rename them within the NML context)  So I think our 
task is to figure out how to dovetail these NSI semantics and the NML 
semantics so that processes can traverse between the two smoothly and 
hopefully imperceptibly.

I look forward to the discussion tomorrow!
Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120215/06cfd664/attachment-0001.html>

From romradz at man.poznan.pl  Thu Feb 16 07:00:31 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 13:00:31 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BA801.8010407@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>	<4F3A6208.6070807@man.poznan.pl>	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>	<4F3B979A.1090806@man.poznan.pl>	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>
	<4F3BA801.8010407@man.poznan.pl>
Message-ID: <4F3CEFDF.7010409@man.poznan.pl>

Hi,

an update is attached. Two changes:
- use of xCard for the contact element (rfc6351)
- I was thinking a bit about "next" vs "connectedTo" (I wouldn't like to 
have the situation when we there are different attribute values which 
mean the same; let's keep the set of xml/nml elements and their 
attribute values as small as possible). There is a solution which avoid 
the conflict of existing these two values in the NML world. I propose to 
use a namespae for type attribute in the relation element. In  the case 
of  topology for NSI we could have nml-nsi:type which ensures that the 
value "connectedTo" is known and accepted by application parsers.

Cheers,
Roman

W dniu 2012-02-15 13:41, Roman ?apacz pisze:
> W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
>> On 15 Feb 2012, at 12:31, Roman ?apacz wrote:
>>>> On to the comments for your description:
>>>>
>>>> - You're using<nml:relation type="next">   to describe connections, 
>>>> this should be<nml:relation type="connectedTo">.
>>> I proposed "next" because it was already used in the framework for 
>>> circuit monitoring. I'm hesitating to introduce an other name which 
>>> means the same (1. as I wrote I try to limit new names; 2. use of 
>>> new name would be incompatible or inconsistent with that solution 
>>> for circuit monitoring).  On the other hand, "connectedTo" is 
>>> already used by NSI so I understand that some continuation is 
>>> welcome. If you think that it's really important to keep 
>>> "connectedTo" then I'm fine.
>> We're already saying that an nml-nsi:STP is equivalent to an nml:Port 
>> with some added behavior. I don't really see any reason why 
>> connectedTo would not work in this case.
>
> Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the 
> nml-nsi namespace would be STP).  "connectedTo" would work, no doubt, 
> but the question is: should we use this if we already used "next" in 
> circuit monitoring (and both mean the same).
>
>>>> - We don't have an nml:contact object at the moment, but it seems 
>>>> that we may indeed need one. However, defining the contact methods 
>>>> should perhaps be done using some other appropriate (standard) schema.
>>> I'll try to find something. Any suggestions are welcome.
>> There's a FOAF namespace in RDF which describes similar things about 
>> a person. However, it's not really a standard I think.
>> There's also the vCard standard, for which there is (I think) both an 
>> RDF and XML notation.
>
> yes, vCard was my first candidate as well
> http://tools.ietf.org/html/rfc6351
>
> Roman
>
>> Jeroen.
>>
>
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25-NML_example_v2.xml
Type: text/xml
Size: 7932 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120216/b218f27a/attachment.xml>

From romradz at man.poznan.pl  Thu Feb 16 07:12:57 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 13:12:57 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3CEFDF.7010409@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>	<4F3A6208.6070807@man.poznan.pl>	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>	<4F3B979A.1090806@man.poznan.pl>	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>	<4F3BA801.8010407@man.poznan.pl>
	<4F3CEFDF.7010409@man.poznan.pl>
Message-ID: <4F3CF2C9.7060302@man.poznan.pl>


I forgot to remove previous contact structure. Fixed.

Roman

W dniu 2012-02-16 13:00, Roman ?apacz pisze:
> Hi,
>
> an update is attached. Two changes:
> - use of xCard for the contact element (rfc6351)
> - I was thinking a bit about "next" vs "connectedTo" (I wouldn't like 
> to have the situation when we there are different attribute values 
> which mean the same; let's keep the set of xml/nml elements and their 
> attribute values as small as possible). There is a solution which 
> avoid the conflict of existing these two values in the NML world. I 
> propose to use a namespae for type attribute in the relation element. 
> In  the case of  topology for NSI we could have nml-nsi:type which 
> ensures that the value "connectedTo" is known and accepted by 
> application parsers.
>
> Cheers,
> Roman
>
> W dniu 2012-02-15 13:41, Roman ?apacz pisze:
>> W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
>>> On 15 Feb 2012, at 12:31, Roman ?apacz wrote:
>>>>> On to the comments for your description:
>>>>>
>>>>> - You're using<nml:relation type="next">   to describe 
>>>>> connections, this should be<nml:relation type="connectedTo">.
>>>> I proposed "next" because it was already used in the framework for 
>>>> circuit monitoring. I'm hesitating to introduce an other name which 
>>>> means the same (1. as I wrote I try to limit new names; 2. use of 
>>>> new name would be incompatible or inconsistent with that solution 
>>>> for circuit monitoring).  On the other hand, "connectedTo" is 
>>>> already used by NSI so I understand that some continuation is 
>>>> welcome. If you think that it's really important to keep 
>>>> "connectedTo" then I'm fine.
>>> We're already saying that an nml-nsi:STP is equivalent to an 
>>> nml:Port with some added behavior. I don't really see any reason why 
>>> connectedTo would not work in this case.
>>
>> Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the 
>> nml-nsi namespace would be STP).  "connectedTo" would work, no doubt, 
>> but the question is: should we use this if we already used "next" in 
>> circuit monitoring (and both mean the same).
>>
>>>>> - We don't have an nml:contact object at the moment, but it seems 
>>>>> that we may indeed need one. However, defining the contact methods 
>>>>> should perhaps be done using some other appropriate (standard) 
>>>>> schema.
>>>> I'll try to find something. Any suggestions are welcome.
>>> There's a FOAF namespace in RDF which describes similar things about 
>>> a person. However, it's not really a standard I think.
>>> There's also the vCard standard, for which there is (I think) both 
>>> an RDF and XML notation.
>>
>> yes, vCard was my first candidate as well
>> http://tools.ietf.org/html/rfc6351
>>
>> Roman
>>
>>> Jeroen.
>>>
>>
>> _______________________________________________
>> 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/20120216/14d33310/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25-NML_example_v2.xml
Type: text/xml
Size: 7232 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120216/14d33310/attachment-0001.xml>

From Freek.Dijkstra at sara.nl  Thu Feb 16 07:16:14 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 16 Feb 2012 13:16:14 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3A6208.6070807@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
Message-ID: <4F3CF38E.7060307@sara.nl>

Roman ?apacz wrote:

> I'm sending you my first try of mapping owl topology desc into nml.
> Please, treat this as a start point for further discussion in order to
> get the final proposal for the NSI team.

Hi Roman,

I have three main comments for now.

1. You use the nml "next" relation to signify a network connections. The
"next" relation is already in use to describe something else: the order
in XML lists (as such it is merely a syntactic construct, instead of an
actual connection/relation between network elements). This was proposed
in Salt Lake City last year, and agreed upon by a small margin.

2. You seem to define network ports and create relations between them to
define a network topology. The NML method is instead to define the
links, and create relations between them to define a network topology.
You can either connect two links using a port, or connect them directly
together (which is slightly shorter to describe circuits through a network).

3. As Jeroen mentioned, I would refer to vCard for defining contacts,
and XML (or OWL) schemas are great in combining multiple schemas in one
document.

Freek

From romradz at man.poznan.pl  Thu Feb 16 07:39:29 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 13:39:29 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3CF38E.7060307@sara.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
Message-ID: <4F3CF901.2020500@man.poznan.pl>

W dniu 2012-02-16 13:16, Freek Dijkstra pisze:
> Roman ?apacz wrote:
>
>> I'm sending you my first try of mapping owl topology desc into nml.
>> Please, treat this as a start point for further discussion in order to
>> get the final proposal for the NSI team.
> Hi Roman,

Hi Freek,

> I have three main comments for now.
>
> 1. You use the nml "next" relation to signify a network connections. The
> "next" relation is already in use to describe something else: the order
> in XML lists (as such it is merely a syntactic construct, instead of an
> actual connection/relation between network elements). This was proposed
> in Salt Lake City last year, and agreed upon by a small margin.

I replaced  that with nml-nsi:type="connectedTo" (suggested by Jeroen). 
See my last update.
But even if we wanted to use "next" I wouldn't see the problem in using 
it for network connections and lists (in fact, network connections are 
the lists of ports or links).

> 2. You seem to define network ports and create relations between them to
> define a network topology. The NML method is instead to define the
> links, and create relations between them to define a network topology.
> You can either connect two links using a port, or connect them directly
> together (which is slightly shorter to describe circuits through a network).

I wanted to be as close as possible to the example that Jeroen sent. I 
believe that NML should be flexible and allow creating relations between 
ports or links. I see (this is my vision) NML as a set of components 
that you can use to build various complex topology structures according 
to the needs raised by users (in this case NSI).

> 3. As Jeroen mentioned, I would refer to vCard for defining contacts,
> and XML (or OWL) schemas are great in combining multiple schemas in one
> document.

Done. See my last update.

Roman

> Freek


From Freek.Dijkstra at sara.nl  Thu Feb 16 08:27:49 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 16 Feb 2012 14:27:49 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3CF901.2020500@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl>
Message-ID: <4F3D0455.1070506@sara.nl>

Hi Roman,

Sorry, I saw your new file after I send my email (insert rant about
gray-listing here).

It seems that NSI uses a different topology concept than NML, using the
(NDL-based?) connectedTo. This is different from what we have in the
examples (relating either links with port using "source" and "sink", or
as I proposed, directly connecting two links with "serialcompound"
relation). Perhaps it is good to discuss this in today's call.

Nevertheless, it seems that the concepts are sufficiently equivalent to
merge the NSI and NML topology concept.

Freek

From romradz at man.poznan.pl  Thu Feb 16 08:41:28 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 14:41:28 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3D0455.1070506@sara.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl> <4F3D0455.1070506@sara.nl>
Message-ID: <4F3D0788.6060801@man.poznan.pl>

W dniu 2012-02-16 14:27, Freek Dijkstra pisze:
> Hi Roman,
>
> Sorry, I saw your new file after I send my email (insert rant about
> gray-listing here).
>
> It seems that NSI uses a different topology concept than NML, using the
> (NDL-based?) connectedTo. This is different from what we have in the
> examples (relating either links with port using "source" and "sink", or
> as I proposed, directly connecting two links with "serialcompound"
> relation). Perhaps it is good to discuss this in today's call.
>
> Nevertheless, it seems that the concepts are sufficiently equivalent to
> merge the NSI and NML topology concept.

My thinking is that NML would be more interesting and useful for users 
(in this case NSI) if we don't impose too many resrtictions. As I wrote 
NML could offer a set of elements, basic relations and minimal set of 
rules how to use them (we may have suggestion and examples of usage). It 
would be up to users and their use cases which elements and combination 
of them are used. Of course there's a risk of going too far with such 
open approach but ... what the hell, users are always right :)

Roman

> Freek


From Freek.Dijkstra at sara.nl  Thu Feb 16 09:03:08 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 16 Feb 2012 15:03:08 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3D0788.6060801@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl> <4F3D0455.1070506@sara.nl>
	<4F3D0788.6060801@man.poznan.pl>
Message-ID: <4F3D0C9C.4090909@sara.nl>

Roman ?apacz wrote:
> W dniu 2012-02-16 14:27, Freek Dijkstra pisze:
>> Hi Roman,
>>
>> Sorry, I saw your new file after I send my email (insert rant about
>> gray-listing here).
>>
>> It seems that NSI uses a different topology concept than NML, using the
>> (NDL-based?) connectedTo. This is different from what we have in the
>> examples (relating either links with port using "source" and "sink", or
>> as I proposed, directly connecting two links with "serialcompound"
>> relation). Perhaps it is good to discuss this in today's call.
>>
>> Nevertheless, it seems that the concepts are sufficiently equivalent to
>> merge the NSI and NML topology concept.
> 
> My thinking is that NML would be more interesting and useful for users 
> (in this case NSI) if we don't impose too many restrictions.

I agree if you are saying "don't impose too many restrictions on the
network topology that users can describe".

I disagree if you are saying "don't impose too many restrictions on the
number of ways that users can describe the same topology".

In both cases the core building blocks are (logical) ports and links
between these logical ports, and I do not see any restrictions there
(which I think is good), but I do see two different methods how this
same topology is described (which I think is bad).

Regards,
Freek

From Freek.Dijkstra at sara.nl  Thu Feb 16 10:03:29 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 16 Feb 2012 16:03:29 +0100
Subject: [Nml-wg] Document update
Message-ID: <4F3D1AC1.7000602@sara.nl>

FYI,

I just updated the nml-base document:

------------------------------------------------------------------------
r24 | macfreek | 2012-02-16 16:01:06 +0100 (Thu, 16 Feb 2012) | 1 line

Reformatted document to adhere to GFD.152 guideline
------------------------------------------------------------------------
r23 | macfreek | 2012-02-16 14:22:26 +0100 (Thu, 16 Feb 2012) | 1 line

Add section on identifiers
------------------------------------------------------------------------

If you have not checked it out,
% svn co https://forge.ogf.org/svn/repos/nml-base

You probably need your Gridforge username and password.

Regards,
Freek

From boote at internet2.edu  Thu Feb 16 10:18:54 2012
From: boote at internet2.edu (Jeff W. Boote)
Date: Thu, 16 Feb 2012 08:18:54 -0700
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3D0C9C.4090909@sara.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl> <4F3D0455.1070506@sara.nl>
	<4F3D0788.6060801@man.poznan.pl> <4F3D0C9C.4090909@sara.nl>
Message-ID: <A592C4FB-C89B-4AA2-A0D8-996BF0EEB2C5@internet2.edu>


On Feb 16, 2012, at 7:03 AM, Freek Dijkstra wrote:
>> 
>> My thinking is that NML would be more interesting and useful for users 
>> (in this case NSI) if we don't impose too many restrictions.
> 
> I agree if you are saying "don't impose too many restrictions on the
> network topology that users can describe".
> 
> I disagree if you are saying "don't impose too many restrictions on the
> number of ways that users can describe the same topology".
> 

Freek++

We can't forget the primary purpose of the schema. It is to communicate the topology among software/hardware implementations. It is not to describe it to humans. And, we want that software to be as simple to write and keep up to date as possible. (So - lets not have multiple ways to describe the same topology please.)

Computers don't care if this is 'Next' or 'ConnectedTo'. It could be called 'RelationType3' and it would be just fine as long as it is consistent. The only reason to name it something in particular is to make sure it is understandable to the programmers writing the software. 

Lets just pick something, document it well, and move on. ;)

Jeff


> In both cases the core building blocks are (logical) ports and links
> between these logical ports, and I do not see any restrictions there
> (which I think is good), but I do see two different methods how this
> same topology is described (which I think is bad).
> 
> Regards,
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg


From Freek.Dijkstra at sara.nl  Thu Feb 16 10:33:48 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 16 Feb 2012 16:33:48 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <A592C4FB-C89B-4AA2-A0D8-996BF0EEB2C5@internet2.edu>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl> <4F3D0455.1070506@sara.nl>
	<4F3D0788.6060801@man.poznan.pl> <4F3D0C9C.4090909@sara.nl>
	<A592C4FB-C89B-4AA2-A0D8-996BF0EEB2C5@internet2.edu>
Message-ID: <4F3D21DC.9020106@sara.nl>

Jeff W. Boote wrote:

> Computers don't care if this is 'Next' or 'ConnectedTo'.

I think the issue ad hand is unfortunately a bit more complex.

The question at hand is basically how to describe the following (with
apologies with my poor ASCII art skills)

port A    link X    port B    link Y    port C
  O------------------>O------------------>O

Roman described this as:

 Port A
    relation=next/connectTo
        port B
 Port B
    relation=next/connectTo
        port C

In the NML schema it is currently defined as:

 link X
    relation=source
        port A
    relation=sink
        port B
 link Y
    relation=source
        port B
    relation=sink
        port C

Previous year I noticed some reluctance in describing both Ports and
Links in examples, and asked if there was need to simplify as follows:

 link X
    relation=serialcompound
        link Y

(After which the discussion ended in "that's a might ugly word
`serialcompound' there, that's how G.800 defined it and I wasn't
creative enough to come up with something better".)

At this moment, neither "serialcompound" nor "connectTo" are valid NML
constructs.

What I'm saying is that I would regret seeing all three options as "valid".

The current source/sink think is most flexible, but I'm happy to
consider alternatives. Please discuss.

Regards,
Freek

From romradz at man.poznan.pl  Thu Feb 16 10:35:30 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 16:35:30 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3BC7B8.2080607@nordu.net>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl>
	<9F0401BB-0B1B-4BA8-9925-E94E942A7CF6@uva.nl>
	<4F3B979A.1090806@man.poznan.pl>
	<C3D5B531-F793-4032-A795-55B95E166F97@uva.nl>
	<4F3BA801.8010407@man.poznan.pl> <4F3BAF4F.8040303@nordu.net>
	<4F3BB21C.7090804@man.poznan.pl> <4F3BC7B8.2080607@nordu.net>
Message-ID: <4F3D2242.3060502@man.poznan.pl>

W dniu 2012-02-15 15:56, Jerry Sobieski pisze:
>
> On 2/15/12 8:24 AM, Roman ?apacz wrote:
>> W dniu 2012-02-15 14:12, Jerry Sobieski pisze:
>>> I am very nervous about this - we deliberatly did *NOT* use "port" 
>>> in NSI because of the overloaded connotation. The Service 
>>> Termination Point in NSI is *not* a port. ...not in the physical 
>>> sense.   So we need to understand what a NML "port" represents.
>>
>> port in the nml-nsi namespace is not physical. This is an abstraction 
>> and represents STP. We could introduce new element nml-nsi:stp but is 
>> it really necessary?
>>
> Ah, ok...the abstraction is good.  (Thanks both Roman and Freek in 
> explaining this.)   This was much of my concern.    But lets discuss 
> tomorrow in more detail as there are still some other aspects of NML 
> "ports" we need to understand/reconcile.
>
> Some further background on NSI notions:
>
> In NSI, the STP is indeed an interface at the edge of a network 
> service domain - it identifies uniquely where user data enters or 
> exits a service domain.   The STPs associated with a network service 
> define the boundary of that NSI service domain.    STPs "mapTo" an 
> internally defined tuple that represents the internal specifics 
> associated with that Service Termination Point.   For instance, an STP 
> "NorthernLight:ams-80" would mapTo <switch, mx80-CPH>, <blade, 0>, 
> <port, 2>, <vlan, 1780>.   This entire tuple is the internal 
> topological information represented by that STP.   (Note- the internal 
> tuple specification is a local network internal issue relevant to the 
> specific infrastructure or software being used.)
>
> Inter-domain peering between two networks is expressed via a Service 
> Demarcation Point "SDP".   An SDP pairs two corresponding STPs - one 
> in each network.   SDPs indicate adjacencies between NSI network 
> services, and differentiate the paths that exist between two networks 
> (or that originate or terminate at a network.)   SDPs are *not* 
> physical links (circuits, fibers, etc) between networks - SDPs are 
> /relations/ that identify a common topological interface between two 
> domains - i.e. the two STPs that are part of an SDP represent the 
> *same* topological location - albeit from different name spaces and 
> with different internal mapsTo info.  For example, an SDP might look 
> like this: < NorthernLight:ams-80, NetherLight:cph-80 >   In the OWL 
> topology, this SDP would be expressed as NorthernLight:ams-80 
> "connectsTo" NetherLight:cph-80.   Thus it is found in an 
> NorthernLight:ams-80 STP object.  A similar SDP would be defined in 
> the NetherLight domain.   These STP names are just strings, but they 
> "mapTo" the internal physical details of the terminus, and they 
> "connectTo" the corresponding STP in another network.   (Note:  NSI is 
> developing an "enumeration" construct that will allow a compact SDP 
> representation of large groups of peering STPs...e.g. where two 
> networks terminate a physical link that carries large number of VLAN 
> IDs. perhaps we can discuss this too at the NML call thursday.?)

I was thinking about this grouping. To better understand the problem 
I've created an example presenting simple solution. I wasn't involved in 
the NSI discussion on this so that piece of xml may be far away from 
that what you want. But your comments let me see your ideas of solving this.

Cheers,
Roman


>
> If an STP does not have a corresponding STP in another NSI network - 
> for example where the remote side is an end host that does not 
> participate in NSI - there is just no "connectsTo" relation, i.e no 
> SDP.   In our AutoGOLE topology, these are how we represent the 
> perfSonar nodes.
>
> Note that these STPs and SDPs are expressly technology agnostic.  The 
> physical details are held internally to each network NSA in the 
> "mapsTo" relation and the internal topology DB.    I think what we nee 
> to now do with NML and NSI is that we want to express these NSI 
> topological constructs and the NML constructs using a common form (the 
> NML representation is what we currently believe to be the right 
> approach), without breaking the semantics that NSI requires to remain 
> secure and autonomous.  At the same time, we want to enable a network 
> announce much more topology if they wish - We'd like both of these 
> aspects to be a well integrated common representational model that 
> syntactically functions smoothly together.  Thus a NSA would announce 
> the NSI service domain (presumably using an NML representation), and 
> if they wish, they can include more details of internal structure 
> using further - perhaps more technology specific -  NML constructs.   
> Ideally, all of this announcement would be a common structure 
> syntactically, and hopefully semantically as well.   This would 
> simplify implementations - partcularly in furture virtual worlds...   
> But we *must* maintain the NSI topological model of STPs and SDPs and 
> Networks and NSAs etc (though we might elect to rename them within the 
> NML context)  So I think our task is to figure out how to dovetail 
> these NSI semantics and the NML semantics so that processes can 
> traverse between the two smoothly and hopefully imperceptibly.
>
> I look forward to the discussion tomorrow!
> Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120216/617a2a98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vlans_in_one_stp_example_v1.xml
Type: text/xml
Size: 2647 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120216/617a2a98/attachment-0001.xml>

From romradz at man.poznan.pl  Thu Feb 16 10:48:37 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 16:48:37 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3D21DC.9020106@sara.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl> <4F3D0455.1070506@sara.nl>
	<4F3D0788.6060801@man.poznan.pl> <4F3D0C9C.4090909@sara.nl>
	<A592C4FB-C89B-4AA2-A0D8-996BF0EEB2C5@internet2.edu>
	<4F3D21DC.9020106@sara.nl>
Message-ID: <4F3D2555.3060504@man.poznan.pl>


W dniu 2012-02-16 16:33, Freek Dijkstra pisze:
> Jeff W. Boote wrote:
>
>> Computers don't care if this is 'Next' or 'ConnectedTo'.
> I think the issue ad hand is unfortunately a bit more complex.
>
> The question at hand is basically how to describe the following (with
> apologies with my poor ASCII art skills)
>
> port A    link X    port B    link Y    port C
>    O------------------>O------------------>O
>
> Roman described this as:
>
>   Port A
>      relation=next/connectTo
>          port B
>   Port B
>      relation=next/connectTo
>          port C
>
> In the NML schema it is currently defined as:
>
>   link X
>      relation=source
>          port A
>      relation=sink
>          port B
>   link Y
>      relation=source
>          port B
>      relation=sink
>          port C
>
> Previous year I noticed some reluctance in describing both Ports and
> Links in examples, and asked if there was need to simplify as follows:
>
>   link X
>      relation=serialcompound
>          link Y
>
> (After which the discussion ended in "that's a might ugly word
> `serialcompound' there, that's how G.800 defined it and I wasn't
> creative enough to come up with something better".)
>
> At this moment, neither "serialcompound" nor "connectTo" are valid NML
> constructs.
>
> What I'm saying is that I would regret seeing all three options as "valid".

But if NSI wants to use paths/links as connected ports because of some 
reasons then I woul be open to let them do it this way. Other 
users/applications may prefer using links because of some other reasons. 
By setting the limits should we prevent various users/applications from 
utilizing NML? Do we want to be so strict? Extensions (namespaces) and 
minimal set of rules would be an answer.

Roman

> The current source/sink think is most flexible, but I'm happy to
> consider alternatives. Please discuss.
>
> Regards,
> Freek


From romradz at man.poznan.pl  Thu Feb 16 10:55:18 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 16:55:18 +0100
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <303969E0-6BC1-41B3-A5A1-0791AD632B14@uva.nl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>	<7C8059A9-1AF6-4BA7-A6D7-43E3E627AA71@uva.nl>
	<303969E0-6BC1-41B3-A5A1-0791AD632B14@uva.nl>
Message-ID: <4F3D26E6.6010605@man.poznan.pl>

W dniu 2012-02-09 17:51, Jeroen van der Ham pisze:
> Hi,
> To add to that, the time of the next call will be:
>
> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam

The NMC call is cancelled so can we have the NML call earlier?

Roman


> Jeroen.
>
> On 9 Feb 2012, at 17:49, Jeroen van der Ham wrote:
>
>> Hello all,
>>
>> My apologies, we started a bit early. For next time I'll make sure that I announce and join at the right time.
>>
>> We had present on the call: Freek, Aaron and Roman. (Jerry joined at the later time)
>>
>> We discussed progress in NSI, GLIF and Automated GOLE. We see an increasing need for an NML schema.
>> NSI has agreed on an STP format, which includes typed name-value pairs, which allow you to describe labels, technologies and all kinds of other things.
>> GLIF has stated that it will use NML soon.
>>
>> Jeroen suspects that there is not much requirement right now, because the GLIF questionnaire shows that most networks use some handcrafted topology format right now. Hopefully once we release something, we'll get usage, and from that feedback.
>>
>> To speed things up, we have agreed to do weekly calls now.
>>
>> Action points:
>> - Jeroen sends the Automated GOLE topology to the list as example (done)
>> - Jeroen sends the results of the GLIF questionnaire to the list.
>> - Freek will propose a notation for VLANs
>> - Jeroen will go through the current NML schema doc and gives an update on the status.
>>
>> Next call is on Thursday February 16th.
>>
>> Jeroen.
>>
>>
>> On 2 Feb 2012, at 14:45, Jeroen van der Ham wrote:
>>
>>> Hello,
>>>
>>> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
>>> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
>>>
>>> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
>>>
>>> Jeroen.
>>> _______________________________________________
>>> 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/20120216/8efbdbbe/attachment.html>

From Freek.Dijkstra at sara.nl  Thu Feb 16 10:57:44 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 16 Feb 2012 16:57:44 +0100
Subject: [Nml-wg] source/sink versus ingress/egress (was: Example topology
 of Automated GOLE)
Message-ID: <4F3D2778.30801@sara.nl>

A somewhat related issue on source/sink. I don't think this was ever
written down.

Freek Dijkstra wrote:

> The question at hand is basically how to describe the following (with
> apologies with my poor ASCII art skills)
> 
> port A    link X    port B    link Y    port C
>   O------------------>O------------------>O
> 
[...]
> In the NML schema it is currently defined as:
> 
>  link X
>     relation=source
>         port A
>     relation=sink
>         port B
>  link Y
>     relation=source
>         port B
>     relation=sink
>         port C

For the record, an alternative way to describe this is making the ports
leading instead of the links:

 port A
     relation=egress
         link X
 port B
     relation=ingress
         link X
     relation=egress
         link Y
 port C
     relation=ingress
         link Y

Technically I think these are equivalent: the provide a directed
relation between links and ports. Which one is syntactically better
depends what is more common, a one-to-many or a many-to-one relation
between ports and links.

For the circuits, this is often a one-to-one relation.
Since we implemented cross-connects as links, VLANs are likely also
described as some kind of "link", but one with multiple sources and
sinks. Hence, there is a one to many relation from link to port.
This means that the source and sink relation we have now is more easy to
convey in XML than the alternative ingress and egress relation.

I personally think the source/sink stuff is still the best alternative
we have.

Regards,
Freek

From vdham at uva.nl  Thu Feb 16 11:02:59 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 16 Feb 2012 17:02:59 +0100
Subject: [Nml-wg] Teleconference Feb 9th
In-Reply-To: <4F3D26E6.6010605@man.poznan.pl>
References: <77C29D3D-0142-481B-988C-1ACE452051B0@uva.nl>	<7C8059A9-1AF6-4BA7-A6D7-43E3E627AA71@uva.nl>
	<303969E0-6BC1-41B3-A5A1-0791AD632B14@uva.nl>
	<4F3D26E6.6010605@man.poznan.pl>
Message-ID: <C97625DF-0285-4883-9D4E-13CCBDBD98A7@uva.nl>

Hi,

Sorry, if we'd have known that earlier, yes, but now I don't want to move the call. We have some others who may also attend and will not see this in time.

Jeroen.

On 16 Feb 2012, at 16:55, Roman ?apacz wrote:

> W dniu 2012-02-09 17:51, Jeroen van der Ham pisze:
>> Hi,
>> To add to that, the time of the next call will be:
>> 
>> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
> 
> The NMC call is cancelled so can we have the NML call earlier?
> 
> Roman
> 
> 
>> Jeroen.
>> 
>> On 9 Feb 2012, at 17:49, Jeroen van der Ham wrote:
>> 
>>> Hello all,
>>> 
>>> My apologies, we started a bit early. For next time I'll make sure that I announce and join at the right time.
>>> 
>>> We had present on the call: Freek, Aaron and Roman. (Jerry joined at the later time)
>>> 
>>> We discussed progress in NSI, GLIF and Automated GOLE. We see an increasing need for an NML schema.
>>> NSI has agreed on an STP format, which includes typed name-value pairs, which allow you to describe labels, technologies and all kinds of other things.
>>> GLIF has stated that it will use NML soon.
>>> 
>>> Jeroen suspects that there is not much requirement right now, because the GLIF questionnaire shows that most networks use some handcrafted topology format right now. Hopefully once we release something, we'll get usage, and from that feedback.
>>> 
>>> To speed things up, we have agreed to do weekly calls now.
>>> 
>>> Action points:
>>> - Jeroen sends the Automated GOLE topology to the list as example (done)
>>> - Jeroen sends the results of the GLIF questionnaire to the list.
>>> - Freek will propose a notation for VLANs
>>> - Jeroen will go through the current NML schema doc and gives an update on the status.
>>> 
>>> Next call is on Thursday February 16th.
>>> 
>>> Jeroen.
>>> 
>>> 
>>> On 2 Feb 2012, at 14:45, Jeroen van der Ham wrote:
>>> 
>>>> Hello,
>>>> 
>>>> Due to the cancelling of Jan 26th and Joint-Techs last week, I forgot to set a new date for the NML teleconference. I propose that we hold a meeting on Feb 9th at the usual time.
>>>> UTC 16:30 = 8:30 Pacific = 11:30 Eastern = 17:30 Amsterdam
>>>> 
>>>> I see an increasing outside demand to this group to provide a first draft. Also given the travel limitations of many contributors, I propose that we start doing teleconferences on a weekly basis now, until we finalize the first draft. Any objections?
>>>> 
>>>> Jeroen.
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120216/d7c00aee/attachment.pgp>

From Freek.Dijkstra at sara.nl  Thu Feb 16 11:09:28 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 16 Feb 2012 17:09:28 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3D2555.3060504@man.poznan.pl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl> <4F3D0455.1070506@sara.nl>
	<4F3D0788.6060801@man.poznan.pl> <4F3D0C9C.4090909@sara.nl>
	<A592C4FB-C89B-4AA2-A0D8-996BF0EEB2C5@internet2.edu>
	<4F3D21DC.9020106@sara.nl> <4F3D2555.3060504@man.poznan.pl>
Message-ID: <4F3D2A38.7010904@sara.nl>

Roman ?apacz wrote:

>> The question at hand is basically how to describe the following (with
>> apologies with my poor ASCII art skills)
>>
>> port A    link X    port B    link Y    port C
>>    O------------------>O------------------>O
>>
>> Roman described this as:
>>
>>   Port A
>>      relation=next/connectTo
>>          port B
>>   Port B
>>      relation=next/connectTo
>>          port C
>>
>> In the NML schema it is currently defined as:
>>
>>   link X
>>      relation=source
>>          port A
>>      relation=sink
>>          port B
>>   link Y
>>      relation=source
>>          port B
>>      relation=sink
>>          port C
>>
>> Previous year I noticed some reluctance in describing both Ports and
>> Links in examples, and asked if there was need to simplify as follows:
>>
>>   link X
>>      relation=serialcompound
>>          link Y
>>
[...]
>> What I'm saying is that I would regret seeing all three options as "valid".
> 
> But if NSI wants to use paths/links as connected ports because of some 
> reasons then I would be open to let them do it this way. Other
> users/applications may prefer using links because of some other reasons. 
> By setting the limits should we prevent various users/applications from 
> utilizing NML? Do we want to be so strict? Extensions (namespaces) and
> minimal set of rules would be an answer.

I do not see how the current source/sink syntax "prevent various
users/applications from utilizing NML".

I agree it is not the most compact syntax out there. But I think it
makes it possible to describe the network topology that NSI uses.

Again, that should be the restriction: can it describe the desired
topology. Not: does it match the syntactical constructs we currently have.

Freek

From romradz at man.poznan.pl  Thu Feb 16 11:21:09 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 16 Feb 2012 17:21:09 +0100
Subject: [Nml-wg] Example topology of Automated GOLE
In-Reply-To: <4F3D2A38.7010904@sara.nl>
References: <3D133411-608A-4403-B286-B15CE1846147@uva.nl>
	<4F3A6208.6070807@man.poznan.pl> <4F3CF38E.7060307@sara.nl>
	<4F3CF901.2020500@man.poznan.pl> <4F3D0455.1070506@sara.nl>
	<4F3D0788.6060801@man.poznan.pl> <4F3D0C9C.4090909@sara.nl>
	<A592C4FB-C89B-4AA2-A0D8-996BF0EEB2C5@internet2.edu>
	<4F3D21DC.9020106@sara.nl> <4F3D2555.3060504@man.poznan.pl>
	<4F3D2A38.7010904@sara.nl>
Message-ID: <4F3D2CF5.1010500@man.poznan.pl>

W dniu 2012-02-16 17:09, Freek Dijkstra pisze:
> Roman ?apacz wrote:
>
>>> The question at hand is basically how to describe the following (with
>>> apologies with my poor ASCII art skills)
>>>
>>> port A    link X    port B    link Y    port C
>>>     O------------------>O------------------>O
>>>
>>> Roman described this as:
>>>
>>>    Port A
>>>       relation=next/connectTo
>>>           port B
>>>    Port B
>>>       relation=next/connectTo
>>>           port C
>>>
>>> In the NML schema it is currently defined as:
>>>
>>>    link X
>>>       relation=source
>>>           port A
>>>       relation=sink
>>>           port B
>>>    link Y
>>>       relation=source
>>>           port B
>>>       relation=sink
>>>           port C
>>>
>>> Previous year I noticed some reluctance in describing both Ports and
>>> Links in examples, and asked if there was need to simplify as follows:
>>>
>>>    link X
>>>       relation=serialcompound
>>>           link Y
>>>
> [...]
>>> What I'm saying is that I would regret seeing all three options as "valid".
>> But if NSI wants to use paths/links as connected ports because of some
>> reasons then I would be open to let them do it this way. Other
>> users/applications may prefer using links because of some other reasons.
>> By setting the limits should we prevent various users/applications from
>> utilizing NML? Do we want to be so strict? Extensions (namespaces) and
>> minimal set of rules would be an answer.
> I do not see how the current source/sink syntax "prevent various
> users/applications from utilizing NML".
>
> I agree it is not the most compact syntax out there. But I think it
> makes it possible to describe the network topology that NSI uses.
>
> Again, that should be the restriction: can it describe the desired
> topology. Not: does it match the syntactical constructs we currently have.

I see you point and am not against. I'm only asking the questions which 
may appear on the user side. The best way is to answer someone from NSI.

Roman

> Freek


From vdham at uva.nl  Thu Feb 16 12:27:06 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Thu, 16 Feb 2012 18:27:06 +0100
Subject: [Nml-wg] Notes for teleconference Feb 16
Message-ID: <3692E6D2-0230-4A62-9375-D2FA80621A0A@uva.nl>

Hi,

Below are the notes of the call we had today.

Attendance: Jason Zurawski (I2), Aaron Brown (I2), Freek Dijkstra (SARA), Yufeng Xin (Renci), Ilia Baldine (Renci), Roman ?apacz (PSNC), Jeff Boote (I2), Chin Guok (ESnet)

We go quickly through the NML schema document. Freek has updated it to the required syntax and added a short section on Identifiers.
Jeroen mentions that updates to the Introduction, Identifiers, and Example section are required, furthermore the definitions have to be checked against the latest schema diagram.

We will move the diagram first, Jeroen will write actionpoints for what has to be fixed.
Security section  will be copied from the NM document and considered in light of current requirements.

Roman has worked on the Automated GOLE example and created an NML-ized version. The last few days we have had a discussion on this and he has further improved on the translation, adding the xCard description.

Jeroen notes that the NSI topology assumes bi-directional topology, while NML uses uni-directional topology. In time NSI will also support uni-directioanl requests, but this is not high on the list at the moment.
We decide to continue with both models and try to define a mapping between them.

next vs connectedTo: next is used for ordering in lists and should not be used outside of that context. We conclude that connectedTo is fine to be used, and does not clash with anything in the NML standard. This means that namespaced attributes don't seem to be necessary after all.

Freek mentions that it would be good to have a discussion between NSI and NML regarding topology approaches. He will set this up.

We discuss the concepts of STP and SDP.
STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints.
SDP: is a pair of connected STPs which are in different domains.

The current NSI does not actively use the SDP, although in the future they may be used to define extra intermediate points of network connections.


Freek proposes to make a real NML version of the Automated GOLE example together with Roman and then compare the two approaches and see if we can map them.

Action points:
Jeroen to go through document and set up action points
Jeroen to check the Security considerations of NM
Freek to contact NSI to set up topology discussion
Freek and Roman to create an NML version of the topology

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120216/d7b76325/attachment.pgp>

From Freek.Dijkstra at sara.nl  Fri Feb 17 07:00:19 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Fri, 17 Feb 2012 13:00:19 +0100
Subject: [Nml-wg] NSI topology
Message-ID: <4F3E4153.2010705@sara.nl>

Hello Guy, Inder, Tomohiro,
cc: NML and NSI groups

Last week Roman ?apacz (PSNC) took Jeroen's AutoGOLE network description
and turned it into an XML format. (Thanks Roman!)

In that process, we discovered a few differences how AutoGOLE and NML
describe a network model. The main differences are:

* NML links and ports are unidirectional, AutoGOLE links are
  bidirectional
* NML uses links and ports to describe network connections (a
  proposal to describe only links, not the ports was not followed
  up), AutoGOLE only describes the ports (the links are described
  as connectedTo between the ports, but have no identifier of their
  own)


Of course there are some commonalities:
* Both implementations focus on logical connections, not physical
  connections.
* Both implementations have provisionings to ensure a layer of
  abstraction in case attributes of a link or port change (in NML:
  the identifiers are opaque strings and have no inherent attributes;
  in AutoGOLE and NSI: the distinction between SDP and STP)

In yesterday's NML conference [1], we briefly discusses these
differences and commonalities.


Now, I do not know to what aspect the NSI working group is building on
the AutoGOLE work, and what the current issues are. I don't want to
interrupt the considerable progress the NSI group is making, and
certainly don't want to get in the way of more great demos such as
previous year's AutoGOLE demos by interrupting their implementation
timelines.

I think it would be good for the NML group to:
- educate the NSI working group participants on these differences.
- listen to the NSI group if there are any problems with the topology
  as we specified.

I realise that the above may take some valuable resources of the NML
working group, but I am dedicated to make sure our groups are aligned.


My question to you (as NSI co-chairs) is if you think the above is
useful, and if so, when we can best discuss this.  Would it be useful to
discuss this with the whole NSI group, or a subset?  I propose that we
dedicate a timeslot for this work, and am happy to use the NML break-out
slot for this purpose (if you like it earlier, we can see if we can ask
Joel to re-arrange some slots). We can also use a NSI or NML telephone
call to discuss this.

Part of that work means for NML-WG to provide example topology
descriptions (which can be done within a few days). But also means
making code contributions, which I don't think the NML-WG has the
resources for on short term notice.

What is your recommended way forward?

Regards,
Freek Dijkstra

[1] http://www.ogf.org/pipermail/nml-wg/2012-February/000815.html

From Freek.Dijkstra at sara.nl  Fri Feb 17 10:05:41 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Fri, 17 Feb 2012 16:05:41 +0100
Subject: [Nml-wg] NML-NSI integration
Message-ID: <4F3E6CC5.2000704@sara.nl>

Roman,

Can I forward the following to the list?

Freek


All,

Roman created an update to the AutoGOLE topology. This lead to an
off-list discussion regarding the namespaces.

Since this may be relevant to the group, I would like to take this
discussion on-list.

Freek

-------- Original Message --------
Subject: Re: [Nml-wg] Notes for teleconference Feb 16
Date: Fri, 17 Feb 2012 15:53:09 +0100
From: Roman ?apacz <romradz at man.poznan.pl>
To: Freek Dijkstra <Freek.Dijkstra at sara.nl>
CC: Jeroen van der Ham <vdham at uva.nl>,
    Jason Zurawski <zurawski at internet2.edu>

Freek suggested:

>>>>> * Use NML namespace over NML-NSI namespace where possible

Roman:

>>>> nml-nsi:port indicates that the port element represents NSI's STP
>>>> nml-nsi:link indicates that the link element represents NSI's SDP
>>>> nm-nsi:network indicates that the network element represents NSI's nsnetwork
>>>> All three things are specific to NSI so I would keep their nsi
>>>> namespaces to stress that.

Freek:

>>> I understand your point, and agree that is may be beneficial to denote
>>> somehow that these are SDP or STP to NSI.
>>>
>>> However, would using a different namespace not defeat the purpose of NML
>>> of having a single schema that everyone uses?
>>>
>>> (Also, I'm not sure if that should be in the topology; I'm actually
>>> hoping that we can keep the topology clean from control plane
>>> information, and have the the control plane simply refer to the topology.)

Roman:

>> I see your point. Just one basic NML namespace would be an ideal
>> situation. But still think that extensions/namespaces should be allowed
>> to assign more and specific information to the basic NML elements. The
>> NSI application(s) may want such extension to easily identify NSI
>> abstract connections or points.

Freek:

> I was perhaps a bit quick in saying "let's use NML (base) namespace
> everywhere". I don't know what the best option is. I try to make up my
> mind as we discuss this.
>
> It is certainly possible to overload (subclass? I'm not sure about the
> correct term here) a namespace to let's say include NSI-specific
> attributes next to the regular NML-attributes.
>
> However, I see a big risk there: in the past we have been discussing the
> option to overload (subclass?) a namespace for the purpose of
> differentiating between different technologies (Ethernet, WDM, ...).
> I don't see a clean way to put something in both a nml-nsi AND a
> nml-ethernet namespace. Unless we are creating nml-base, nml-nsi,
> nml-ethernet, and also nml-nsi-ethernet namespaces. I have a feeling
> that that solution does not scale. What if tomorrow some policy working
> group comes along, and we have to create a nml-nsi-ethernet-public and
> nml-nsi-ethernet-restricted namespace (or whatever someone may come up
> with).
>
> In programming patterns, I think we need to use has-a instead of is-a (a
> Port has-a STP-attribute, rather than a Port is-a STP).
>
>
> Here is my current thinking.
>
> I understand there is a need for NSI (and perhaps others) to tag a given
> port as being a "STP", and perhaps it should go in the topology. It
> actually is a matter how to refer to it. The option above tags certain
> ports as "an STP" by being in a different namespace. My thought (hope)
> was that the NSI protocol could add a tag somewhere like this:

If we allow adding new tags as extensions in any place in the structure
then we don't have too much control over the structure. Generic parsers
will not know how to interpret such unexpected (not included in the base
NML schema) changes. On the contrary, namespaces as extensions allow
parsers to, at least, understand their standard properties, others would
be ignored. The structures defined in the base NML schema are still
followed. (Of course it is possible to define a schema in such way that
any element could be inserted in any place but I don't think it's the
right direction).

Roman

> <nml:topology id="1234">
>    ....
>    <!-- regular NML topology info -->
>    ...
>      <nsi:stp-list>
>        <nml:port idref="...."/>
>        <nml:port idref="...."/>
>        <nml:port idref="...."/>
>      </nsi:stp-list>
> </nml:topology>
> <nsi:domain>
>    <contact>
>      <vCard>
>    </contact>
>    <controller>
>      <url>http://example.net/webservices/NSI-controller</url>
>      <topology idref="1234"/>
>    <controller>
> </nsi-domain>



From Freek.Dijkstra at sara.nl  Fri Feb 17 10:26:48 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Fri, 17 Feb 2012 16:26:48 +0100
Subject: [Nml-wg] NML-NSI integration
In-Reply-To: <4F3E6CC5.2000704@sara.nl>
References: <4F3E6CC5.2000704@sara.nl>
Message-ID: <4F3E71B8.3080108@sara.nl>

Freek Dijkstra wrote _to the list_:

> Can I forward the following to the list?

/me FAIL.

Sorry folks, it's Friday afternoon here.
(thanks for nevertheless giving the permission, Roman)

Freek -d?h!- Dijkstra

From Freek.Dijkstra at sara.nl  Fri Feb 17 10:28:13 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Fri, 17 Feb 2012 16:28:13 +0100
Subject: [Nml-wg] NML-NSI integration
In-Reply-To: <4F3E6CC5.2000704@sara.nl>
References: <4F3E6CC5.2000704@sara.nl>
Message-ID: <4F3E720D.4010001@sara.nl>

Hi all,

A port can have many properties. It can be abstract, Ethernet, (NSI)
domain boundary port, have restricted access, be part of a link bundle.

What I want to avoid is having to deal with namespaces and objects such
as <nml-nsi-ethernet-restricted-lacp:port>

> If we allow adding new tags as extensions in any place in the structure
> then we don't have too much control over the structure. Generic parsers
> will not know how to interpret such unexpected (not included in the base
> NML schema) changes. On the contrary, namespaces as extensions allow
> parsers to, at least, understand their standard properties, others would
> be ignored. The structures defined in the base NML schema are still
> followed. (Of course it is possible to define a schema in such way that
> any element could be inserted in any place but I don't think it's the
> right direction).

The RNC schema you created last year DID allow arbitrary elements inside
NML elements.

I think I misunderstand you. In particular, I do not understand the
sentence "namespaces as extensions allow parsers to, at least,
understand their standard properties."

Are you talking about chameleon namespaces?

I assume that:

* NML elements can contain arbitrary child elements, from the NML or
other namespace
* if a parser encounters an unknown element from a known namespace, it
should stop and return an error
* if a parser encounters an element from a unknown namespace, it should
ignore it (or -if we define chameleon namespaces- interpret as if it was
part of the base namespace)
(Note that in this case, I'm unclear how a parser should distinguish
between a chameleon namespace and a proprietary namespace which can
safely be ignored.)

Could you perhaps give an example of a message containing NML and NSI
information, and explain how a parser which only understands NML sees
it, and how a parsers understands both NML and NSI sees it, and if
either should ignore unknown elements or stop and return an error?

Freek

From romradz at man.poznan.pl  Fri Feb 17 10:45:28 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Fri, 17 Feb 2012 16:45:28 +0100
Subject: [Nml-wg] NML-NSI integration
In-Reply-To: <4F3E720D.4010001@sara.nl>
References: <4F3E6CC5.2000704@sara.nl> <4F3E720D.4010001@sara.nl>
Message-ID: <4F3E7618.4040908@man.poznan.pl>

W dniu 2012-02-17 16:28, Freek Dijkstra pisze:
> Hi all,
>
> A port can have many properties. It can be abstract, Ethernet, (NSI)
> domain boundary port, have restricted access, be part of a link bundle.
>
> What I want to avoid is having to deal with namespaces and objects such
> as<nml-nsi-ethernet-restricted-lacp:port>
>
>> If we allow adding new tags as extensions in any place in the structure
>> then we don't have too much control over the structure. Generic parsers
>> will not know how to interpret such unexpected (not included in the base
>> NML schema) changes. On the contrary, namespaces as extensions allow
>> parsers to, at least, understand their standard properties, others would
>> be ignored. The structures defined in the base NML schema are still
>> followed. (Of course it is possible to define a schema in such way that
>> any element could be inserted in any place but I don't think it's the
>> right direction).
> The RNC schema you created last year DID allow arbitrary elements inside
> NML elements.
>
> I think I misunderstand you. In particular, I do not understand the
> sentence "namespaces as extensions allow parsers to, at least,
> understand their standard properties."
>

a very simple example

<nml-ext:x>
<nml:y></nml:y>
<nml-ext:z></nml-ext:z>
</nml-ext:x>

A parser which does not understand the nml-ext extension/namespace would 
treat x as nml:x (of course if nml:x exsits) and ignore nml-ext:z.


Roman


> Are you talking about chameleon namespaces?
>
> I assume that:
>
> * NML elements can contain arbitrary child elements, from the NML or
> other namespace
> * if a parser encounters an unknown element from a known namespace, it
> should stop and return an error
> * if a parser encounters an element from a unknown namespace, it should
> ignore it (or -if we define chameleon namespaces- interpret as if it was
> part of the base namespace)
> (Note that in this case, I'm unclear how a parser should distinguish
> between a chameleon namespace and a proprietary namespace which can
> safely be ignored.)
>
> Could you perhaps give an example of a message containing NML and NSI
> information, and explain how a parser which only understands NML sees
> it, and how a parsers understands both NML and NSI sees it, and if
> either should ignore unknown elements or stop and return an error?
>
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg


From jerry at nordu.net  Fri Feb 17 10:53:11 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Fri, 17 Feb 2012 10:53:11 -0500
Subject: [Nml-wg] NML-NSI integration
In-Reply-To: <4F3E7618.4040908@man.poznan.pl>
References: <4F3E6CC5.2000704@sara.nl> <4F3E720D.4010001@sara.nl>
	<4F3E7618.4040908@man.poznan.pl>
Message-ID: <4F3E77E7.3080305@nordu.net>

Guys-

If you are considering which parsers will process the constructs then 
you are already way past where you need to be.

I would implore you to make the specification so simple that the 
standard is not based on nor is concerned about parser implementations.

Jerry



On 2/17/12 10:45 AM, Roman ?apacz wrote:
> W dniu 2012-02-17 16:28, Freek Dijkstra pisze:
>> Hi all,
>>
>> A port can have many properties. It can be abstract, Ethernet, (NSI)
>> domain boundary port, have restricted access, be part of a link bundle.
>>
>> What I want to avoid is having to deal with namespaces and objects such
>> as<nml-nsi-ethernet-restricted-lacp:port>
>>
>>> If we allow adding new tags as extensions in any place in the structure
>>> then we don't have too much control over the structure. Generic parsers
>>> will not know how to interpret such unexpected (not included in the 
>>> base
>>> NML schema) changes. On the contrary, namespaces as extensions allow
>>> parsers to, at least, understand their standard properties, others 
>>> would
>>> be ignored. The structures defined in the base NML schema are still
>>> followed. (Of course it is possible to define a schema in such way that
>>> any element could be inserted in any place but I don't think it's the
>>> right direction).
>> The RNC schema you created last year DID allow arbitrary elements inside
>> NML elements.
>>
>> I think I misunderstand you. In particular, I do not understand the
>> sentence "namespaces as extensions allow parsers to, at least,
>> understand their standard properties."
>>
>
> a very simple example
>
> <nml-ext:x>
> <nml:y></nml:y>
> <nml-ext:z></nml-ext:z>
> </nml-ext:x>
>
> A parser which does not understand the nml-ext extension/namespace 
> would treat x as nml:x (of course if nml:x exsits) and ignore nml-ext:z.
>
>
> Roman
>
>
>> Are you talking about chameleon namespaces?
>>
>> I assume that:
>>
>> * NML elements can contain arbitrary child elements, from the NML or
>> other namespace
>> * if a parser encounters an unknown element from a known namespace, it
>> should stop and return an error
>> * if a parser encounters an element from a unknown namespace, it should
>> ignore it (or -if we define chameleon namespaces- interpret as if it was
>> part of the base namespace)
>> (Note that in this case, I'm unclear how a parser should distinguish
>> between a chameleon namespace and a proprietary namespace which can
>> safely be ignored.)
>>
>> Could you perhaps give an example of a message containing NML and NSI
>> information, and explain how a parser which only understands NML sees
>> it, and how a parsers understands both NML and NSI sees it, and if
>> either should ignore unknown elements or stop and return an error?
>>
>> Freek
>> _______________________________________________
>> 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

From romradz at man.poznan.pl  Fri Feb 17 11:00:51 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Fri, 17 Feb 2012 17:00:51 +0100
Subject: [Nml-wg] NML-NSI integration
In-Reply-To: <4F3E77E7.3080305@nordu.net>
References: <4F3E6CC5.2000704@sara.nl> <4F3E720D.4010001@sara.nl>
	<4F3E7618.4040908@man.poznan.pl> <4F3E77E7.3080305@nordu.net>
Message-ID: <4F3E79B3.7030601@man.poznan.pl>

W dniu 2012-02-17 16:53, Jerry Sobieski pisze:
> Guys-
>
> If you are considering which parsers will process the constructs then 
> you are already way past where you need to be.

No, no, we are not talking about parser implementations but how nml 
elements could be interpreted.

Roman

>
> I would implore you to make the specification so simple that the 
> standard is not based on nor is concerned about parser implementations.
>
> Jerry
>
>
>
> On 2/17/12 10:45 AM, Roman ?apacz wrote:
>> W dniu 2012-02-17 16:28, Freek Dijkstra pisze:
>>> Hi all,
>>>
>>> A port can have many properties. It can be abstract, Ethernet, (NSI)
>>> domain boundary port, have restricted access, be part of a link bundle.
>>>
>>> What I want to avoid is having to deal with namespaces and objects such
>>> as<nml-nsi-ethernet-restricted-lacp:port>
>>>
>>>> If we allow adding new tags as extensions in any place in the 
>>>> structure
>>>> then we don't have too much control over the structure. Generic 
>>>> parsers
>>>> will not know how to interpret such unexpected (not included in the 
>>>> base
>>>> NML schema) changes. On the contrary, namespaces as extensions allow
>>>> parsers to, at least, understand their standard properties, others 
>>>> would
>>>> be ignored. The structures defined in the base NML schema are still
>>>> followed. (Of course it is possible to define a schema in such way 
>>>> that
>>>> any element could be inserted in any place but I don't think it's the
>>>> right direction).
>>> The RNC schema you created last year DID allow arbitrary elements 
>>> inside
>>> NML elements.
>>>
>>> I think I misunderstand you. In particular, I do not understand the
>>> sentence "namespaces as extensions allow parsers to, at least,
>>> understand their standard properties."
>>>
>>
>> a very simple example
>>
>> <nml-ext:x>
>> <nml:y></nml:y>
>> <nml-ext:z></nml-ext:z>
>> </nml-ext:x>
>>
>> A parser which does not understand the nml-ext extension/namespace 
>> would treat x as nml:x (of course if nml:x exsits) and ignore nml-ext:z.
>>
>>
>> Roman
>>
>>
>>> Are you talking about chameleon namespaces?
>>>
>>> I assume that:
>>>
>>> * NML elements can contain arbitrary child elements, from the NML or
>>> other namespace
>>> * if a parser encounters an unknown element from a known namespace, it
>>> should stop and return an error
>>> * if a parser encounters an element from a unknown namespace, it should
>>> ignore it (or -if we define chameleon namespaces- interpret as if it 
>>> was
>>> part of the base namespace)
>>> (Note that in this case, I'm unclear how a parser should distinguish
>>> between a chameleon namespace and a proprietary namespace which can
>>> safely be ignored.)
>>>
>>> Could you perhaps give an example of a message containing NML and NSI
>>> information, and explain how a parser which only understands NML sees
>>> it, and how a parsers understands both NML and NSI sees it, and if
>>> either should ignore unknown elements or stop and return an error?
>>>
>>> Freek
>>> _______________________________________________
>>> 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


From jerry at nordu.net  Fri Feb 17 11:18:27 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Fri, 17 Feb 2012 11:18:27 -0500
Subject: [Nml-wg] source/sink versus ingress/egress (was: Example
 topology of Automated GOLE)
In-Reply-To: <4F3D2778.30801@sara.nl>
References: <4F3D2778.30801@sara.nl>
Message-ID: <4F3E7DD3.3060006@nordu.net>

Hi Freek-

Regarding the "connectedTo" or "mapsTo" terms in the NSI topology, those 
could be different strings if NML is already using them in a different 
sense.   We could in NSI use the term "sharesInterfaceWith" or 
"internallyTranslatesTo" for each of those respectively.   THis ould be 
a minor change for us.

More important to NSI is that there be the /semantics/ that those 
relations represent.

On a slightly different issue -
I saw a comment somewhere (maybe the minutes of THursday's call?) that 
said NSI was not using the SDP relations...  This is wrong.   NSI very 
much uses SDPs in the current topology.

SDPs are represented within an STP object with a "connectedTo" relation 
referencing another STP object.   Here is a OWL snippet:
<owl:NamedIndividual 
rdf:about="urn:ogf:network:stp:northernlight.ets:poz-1">
<rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/>
<connectedTo rdf:resource="urn:ogf:network:stp:pionier.ets:cphb"/>
</owl:NamedIndividual>
In this snippet, NorthernLight STP "poz-1" is in an SDP relationship 
with the Pionier STP "cphb".   The Snippet is the STP object defined for 
NothernLight.    A mirror image STP is defined in Pionier.   Thus a path 
finder traversing the networks in either direction will easily see the 
SDP relation.

There may be better ways to represent the SDP, this was what we did for 
the fall...We can discuss others...

The NSI topological _/representation/_ (i.e. the OWL/RDF form) could 
take other forms that we currently have as long as the semantics of the 
three key NSI objects are preserved: NSI Networks (service domains), 
STPs (edge ports/points), and SDPs (adjacencies).   These are I think 
represented in NML, though there is probably a different notion of 
"link" vs "SDP" that we need to reconcile...and maybe some of the 
mechanics of the "port" vs "STP" ...  These notions are very close.

Jerry

On 2/16/12 10:57 AM, Freek Dijkstra wrote:
> A somewhat related issue on source/sink. I don't think this was ever
> written down.
>
> Freek Dijkstra wrote:
>
>> The question at hand is basically how to describe the following (with
>> apologies with my poor ASCII art skills)
>>
>> port A    link X    port B    link Y    port C
>>    O------------------>O------------------>O
>>
> [...]
>> In the NML schema it is currently defined as:
>>
>>   link X
>>      relation=source
>>          port A
>>      relation=sink
>>          port B
>>   link Y
>>      relation=source
>>          port B
>>      relation=sink
>>          port C
> For the record, an alternative way to describe this is making the ports
> leading instead of the links:
>
>   port A
>       relation=egress
>           link X
>   port B
>       relation=ingress
>           link X
>       relation=egress
>           link Y
>   port C
>       relation=ingress
>           link Y
>
> Technically I think these are equivalent: the provide a directed
> relation between links and ports. Which one is syntactically better
> depends what is more common, a one-to-many or a many-to-one relation
> between ports and links.
>
> For the circuits, this is often a one-to-one relation.
> Since we implemented cross-connects as links, VLANs are likely also
> described as some kind of "link", but one with multiple sources and
> sinks. Hence, there is a one to many relation from link to port.
> This means that the source and sink relation we have now is more easy to
> convey in XML than the alternative ingress and egress relation.
>
> I personally think the source/sink stuff is still the best alternative
> we have.
>
> Regards,
> Freek
> _______________________________________________
> 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/20120217/0cf2efd7/attachment.html>

From jerry at nordu.net  Fri Feb 17 11:52:01 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Fri, 17 Feb 2012 11:52:01 -0500
Subject: [Nml-wg] NSI -> NML integration
Message-ID: <4F3E85B1.2030101@nordu.net>

Hi all -

With the discussion around NSI integration into NML, I have constructed 
a few slides to present the NSI topological notions to the NML folks.   
These are general, and so we should discuss in a joint call... but the 
basics of the two efforts are fairly close...

I am much more comfortable now that we have a notion that many of these 
NML topology constructs are logical notions rather than physical 
analogues...  we just need to identify where there are semantic 
differences and where there is just terminology differences... the 
latter are easily reconciled.   The former may be a bit more effort - 
but I am very optimistic these will fall over reasonably easy as well.

Please offer any questions of comments...

Jerry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Abstract NSI Topology Model.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 133311 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120217/7395eb5f/attachment-0001.pptx>

From romradz at man.poznan.pl  Tue Feb 21 06:39:43 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Tue, 21 Feb 2012 12:39:43 +0100
Subject: [Nml-wg] Conf call Feb 23
Message-ID: <4F43827F.2000007@man.poznan.pl>


Hi Jeroen,

would it be possible to start the call at 5pm CET in case of NMC call 
cancellation?

Jason, are we going to have the NMC call on Thu?

Cheers,
Roman

From zurawski at internet2.edu  Tue Feb 21 07:38:14 2012
From: zurawski at internet2.edu (Jason Zurawski)
Date: Tue, 21 Feb 2012 07:38:14 -0500
Subject: [Nml-wg] Conf call Feb 23
In-Reply-To: <4F43827F.2000007@man.poznan.pl>
References: <4F43827F.2000007@man.poznan.pl>
Message-ID: <4F439036.7050903@internet2.edu>

Hi Roman/All;

NMC operates every other week, we do not have a call scheduled for 2/23.

Thanks;

-jason

On 2/21/12 6:39 AM, thus spake Roman ?apacz:
>
> Hi Jeroen,
>
> would it be possible to start the call at 5pm CET in case of NMC call
> cancellation?
>
> Jason, are we going to have the NMC call on Thu?
>
> Cheers,
> Roman

From vdham at uva.nl  Tue Feb 21 08:00:39 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Tue, 21 Feb 2012 14:00:39 +0100
Subject: [Nml-wg] Conf call Feb 23
In-Reply-To: <4F439036.7050903@internet2.edu>
References: <4F43827F.2000007@man.poznan.pl> <4F439036.7050903@internet2.edu>
Message-ID: <0D01084B-AEB8-4538-AA8E-9E15F8CA3CA8@uva.nl>

Hi,

I'll leave the decision to Freek, I'm not available this week.

Jeroen.

On 21 Feb 2012, at 13:38, Jason Zurawski wrote:

> Hi Roman/All;
> 
> NMC operates every other week, we do not have a call scheduled for 2/23.
> 
> Thanks;
> 
> -jason
> 
> On 2/21/12 6:39 AM, thus spake Roman ?apacz:
>> 
>> Hi Jeroen,
>> 
>> would it be possible to start the call at 5pm CET in case of NMC call
>> cancellation?
>> 
>> Jason, are we going to have the NMC call on Thu?
>> 
>> Cheers,
>> Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120221/7b430447/attachment.pgp>

From Freek.Dijkstra at sara.nl  Tue Feb 21 08:31:12 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Tue, 21 Feb 2012 14:31:12 +0100
Subject: [Nml-wg] Conf call Feb 23
In-Reply-To: <0D01084B-AEB8-4538-AA8E-9E15F8CA3CA8@uva.nl>
References: <4F43827F.2000007@man.poznan.pl> <4F439036.7050903@internet2.edu>
	<0D01084B-AEB8-4538-AA8E-9E15F8CA3CA8@uva.nl>
Message-ID: <4F439CA0.6090900@sara.nl>

Roman ?apacz wrote:

>> would it be possible to start the call at 5pm CET in case of NMC call
>> cancellation?

I'm fine rescheduling half an hour earlier to 16:00 UCT (17:00 CET, 8:00
Pacific, 11:00 Eastern).

If anybody has an objection before Wednesday 16.00 UCT we'll stick to
the old time, otherwise we'll use the new time.


Freek

From Freek.Dijkstra at sara.nl  Wed Feb 22 04:52:01 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 10:52:01 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
Message-ID: <4F44BAC1.70500@sara.nl>

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.
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25.owl
Type: text/xml
Size: 94178 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/7d6a594a/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-01-25.rdf
Type: application/rdf+xml
Size: 52002 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/7d6a594a/attachment-0003.rdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-02-20.rdf
Type: application/rdf+xml
Size: 80231 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/7d6a594a/attachment-0004.rdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoGOLE-Topo-2012-02-22.rdf
Type: application/rdf+xml
Size: 153902 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/7d6a594a/attachment-0005.rdf>

From Freek.Dijkstra at sara.nl  Wed Feb 22 07:21:49 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 13:21:49 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F44BAC1.70500@sara.nl>
References: <4F44BAC1.70500@sara.nl>
Message-ID: <4F44DDDD.5060602@sara.nl>

A quick follow-up with technical bug fixes.

The RDF file credited Roman ?apacz and Jeroen van der Ham for their
contributions. Many bright ideas came from them. The errors, on the
other hand, are mostly mine.

I've corrected two errors:
* Change geo84:SpatialThing to nml:Locations (I actually forgot that we
defined that in nml. I was overzealous when correcting the
dtox:long/dtox:lat to geo84:long/geo84:lat.)
* <nml:relation type="source"> is valid XML, but not valid RDF; change
to <nml-rel:source> for RDF.

There are still a few more errors in the RDF: nml:port is a direct child
element of nml:bidirectionalport, and nml:bidirectionalport and nml:link
are direct child elements of nml:topology. That is fine in XML, but RDF
needs an explicit predicate. I don't think we've defined that yet. For
now I like to focus on the main issues, but welcome corrections!

Freek

From romradz at man.poznan.pl  Wed Feb 22 09:19:05 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Wed, 22 Feb 2012 15:19:05 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F44BAC1.70500@sara.nl>
References: <4F44BAC1.70500@sara.nl>
Message-ID: <4F44F959.80909@man.poznan.pl>

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.

btw. I'm still thinking that we don't need nml:bidirectionalport in NML 
:) We could use port with "bidirectional" relation.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/9f6fa33f/attachment.html>

From Freek.Dijkstra at sara.nl  Wed Feb 22 14:11:31 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 20:11:31 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F44F959.80909@man.poznan.pl>
References: <4F44BAC1.70500@sara.nl> <4F44F959.80909@man.poznan.pl>
Message-ID: <4F453DE3.7060109@sara.nl>

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

From jerry at nordu.net  Wed Feb 22 15:00:43 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 22 Feb 2012 15:00:43 -0500
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F44F959.80909@man.poznan.pl>
References: <4F44BAC1.70500@sara.nl> <4F44F959.80909@man.poznan.pl>
Message-ID: <4F45496B.1070309@nordu.net>

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>

From Freek.Dijkstra at sara.nl  Wed Feb 22 15:15:31 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 21:15:31 +0100
Subject: [Nml-wg] bidirectionality (was: NMLify of AutoGOLE topology)
Message-ID: <4F454CE3.7090106@sara.nl>

Roman ?apacz wrote:

> btw. I'm still thinking that we don't need nml:bidirectionalport in NML
> :) We could use port with "bidirectional" relation.

The distinction between <nml:port type="bidirectional"> and
<nml:bidirectionalport> is only syntactic, so I presume you are
referring to not only change the syntax, but also the semantic. Meaning
that all the rules and relations that apply to nml:ports can be applied
to nml:bidirectional ports as well.

Actually, the problem is not so much with bidirectional ports, but with
bidirectional links.

I personally hope you are right. We identified some issues related to
identifying the direction (ingress or egress) for physical interfaces
that did both de-adaptation AND adaptation for ingress traffic (this is
uncommon, I only know of one practical example). For that reason, we
decided at the time to do everything unidirectional (so that identifying
directionality is trivial) and see if we can later come up with either
syntactic of semantic simplifications for bidirectional links.

I just took another look at the problem we had back than, and I start to
wonder if the problem is solved because we now use explicit links, and
we have some basic understanding how to handle multicast and broadcast
(as links with multiple end-points).

Let me describe the problem we had a few years ago. If you have time to
propose a solution, and it works with the following three examples,
that's a good indication for me that we can make it work, and I would
back up your proposal.

If you make a proposal, make sure to do it in the UML schema, since that
is leading.

1. A link between one network that described all links unidirectional
and another network that describes all links bidirectional.

2. A link with more than two end-points, such as a Ethernet LAN or VLAN
(this one is probably easy).

3. How to describe a physical interfaces that did both de-adaptation AND
adaptation for ingress traffic. The only example I know is an Ethernet
interface in a SONET switch. Here, the Ethernet traffic is first
de-adapted from the fiber layer (e.g. using 1000base-LR decoding), and
than, //at the same interface// adapted to the VC-4 layer (e.g. using
GFP-F encoding or the older LEX encoding). The questions are:
a) how to make the distinction between the link on the ingress and
egress side of an such an interface, and
b) the distinction between the adaptation stack on the ingress and
egress side of such an interface.

Use case 3 is rather complex, so I made a picture, see attached (it's
still complex, so I'm happy to explain in more detail if required). As
you can see, on the Ethernet layer, there is a direct link between port
C1 and D2 (thus NOT between C2 and D1 as is the case on the fiber
layer). Data coming in at C1 from either A1 or B1 is really different
from data coming in from D2. For use case 3a, how do the links and ports
look like when described on the Ethernet layer (without describing the
underlying fiber infrastructure). Would be possible to distinction to
describe the connections A1, B1 and C2? For use case 3b, how to describe
the links, ports and adaptation if only the fiber layer and adaptations
are described, but the Ethernet layer is not explicitly defined (but
should be inferred from the underlying infrastructure on the lower layer).

Regards,
Freek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inverse-multiplexing.png
Type: image/png
Size: 52058 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/78eda78e/attachment-0001.png>

From jerry at nordu.net  Wed Feb 22 15:19:13 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 22 Feb 2012 15:19:13 -0500
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F453DE3.7060109@sara.nl>
References: <4F44BAC1.70500@sara.nl> <4F44F959.80909@man.poznan.pl>
	<4F453DE3.7060109@sara.nl>
Message-ID: <4F454DC1.3060705@nordu.net>



On 2/22/12 2:11 PM, Freek Dijkstra wrote:
> 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.
Exactly.  I view a topology as [initially] an abstract domain that 
comprises a comprehensive but finite switching function between points 
at its boundary.   We can map those points to co-registered points in 
another topology that expresses some other aspects - perhaps 
geolocation, or internal connectivity, or policy-based capabilities, or 
a combination thereof.  A perfect example would be a simple abstract 
topology announced publicly that mapsTo a much more detailed internal 
physical topology that the local network wishes to manage itself.   The 
NSA is the agent that speaks to other NSAs inter-domain (at whatever 
domain level we are at) and translates as necessary to local agents that 
do the dirty work internally.
It is important IMO that NML be recursive and abstract in this manner as 
well as able to capture physical hdw engineering trappings.    It looks 
like it is very close to being able to do this.

I am not so concerned about whether these are NML constructs or NSI 
constructs or DTOX...  Its the overall ontology I think that must be 
well considered and well integrated.   THis recursion I mention above 
does not necessarilly hide detail, it organizes it.  It can be exposed 
or hidden as the parties deem appropriate.   But the representation 
allows and enables the networks to describe and share the topology as 
they see fit.
>
>> 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.
Agreed.  Well said.
>
> Regards,
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

From jerry at nordu.net  Wed Feb 22 16:12:26 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Wed, 22 Feb 2012 16:12:26 -0500
Subject: [Nml-wg] bidirectionality (was: NMLify of AutoGOLE topology)
In-Reply-To: <4F454CE3.7090106@sara.nl>
References: <4F454CE3.7090106@sara.nl>
Message-ID: <4F455A3A.7070507@nordu.net>



On 2/22/12 3:15 PM, Freek Dijkstra wrote:
> Roman ?apacz wrote:
>
>> btw. I'm still thinking that we don't need nml:bidirectionalport in NML
>> :) We could use port with "bidirectional" relation.
> The distinction between<nml:port type="bidirectional">  and
> <nml:bidirectionalport>  is only syntactic, so I presume you are
> referring to not only change the syntax, but also the semantic. Meaning
> that all the rules and relations that apply to nml:ports can be applied
> to nml:bidirectional ports as well.
>
> Actually, the problem is not so much with bidirectional ports, but with
> bidirectional links.
>
> I personally hope you are right. We identified some issues related to
> identifying the direction (ingress or egress) for physical interfaces
> that did both de-adaptation AND adaptation for ingress traffic (this is
> uncommon, I only know of one practical example). For that reason, we
> decided at the time to do everything unidirectional (so that identifying
> directionality is trivial) and see if we can later come up with either
> syntactic of semantic simplifications for bidirectional links.
>
> I just took another look at the problem we had back than, and I start to
> wonder if the problem is solved because we now use explicit links, and
> we have some basic understanding how to handle multicast and broadcast
> (as links with multiple end-points).
>
> Let me describe the problem we had a few years ago. If you have time to
> propose a solution, and it works with the following three examples,
> that's a good indication for me that we can make it work, and I would
> back up your proposal.
>
> If you make a proposal, make sure to do it in the UML schema, since that
> is leading.
>
> 1. A link between one network that described all links unidirectional
> and another network that describes all links bidirectional.
>
> 2. A link with more than two end-points, such as a Ethernet LAN or VLAN
> (this one is probably easy).
>
> 3. How to describe a physical interfaces that did both de-adaptation AND
> adaptation for ingress traffic. The only example I know is an Ethernet
> interface in a SONET switch. Here, the Ethernet traffic is first
> de-adapted from the fiber layer (e.g. using 1000base-LR decoding), and
> than, //at the same interface// adapted to the VC-4 layer (e.g. using
> GFP-F encoding or the older LEX encoding). The questions are:
> a) how to make the distinction between the link on the ingress and
> egress side of an such an interface, and
> b) the distinction between the adaptation stack on the ingress and
> egress side of such an interface.
This is where abstraction comes in.  Those de-adaptations and 
adaptations are all functional network elements.  They can be engineered 
topologically just like other devices and preserve your notions of port 
orientation etc.  Granted, some are virtual elements but the point 
remains - they can easily be represented topologically.  Right?

The real issue here is that in order to describe these details, you *DO* 
in fact end up reverse engineering all the hardware.  And it gets very 
complex and increasingly difficult to represent in a generalized manner 
all that detail...you could get down to the gate level if you keep 
going.   It becomes increasingly difficult for pathfinders to model this 
much varied detail. (Imagine all the 1000-baseLR adaptations that occur 
on a campus...is this detail truly necessary for a pathfinder to know in 
another country on the otehr side of the world?  There needs to be a way 
of accounting for the function without actually having to model it 
generically externally.

At some level, you simply have to glom all these internal functions 
together into a single opaque object and say "I cannot or will not 
represent these internal details topologically, so here is an active 
agent you can send your requirements to and *it* will magically do it 
for you - or tell you it can't be done."     The rub is that the remote 
pathfinder still needs to know conclusively the input state and output 
state.  Thus you need a means of specifying the ports - but not the 
internals. I.e. you define the interfaces to the service domain rather 
than the internals of the service domain.

This is how NSI functions.
>
> Use case 3 is rather complex, so I made a picture, see attached (it's
> still complex, so I'm happy to explain in more detail if required). As
> you can see, on the Ethernet layer, there is a direct link between port
> C1 and D2 (thus NOT between C2 and D1 as is the case on the fiber
> layer). Data coming in at C1 from either A1 or B1 is really different
> from data coming in from D2. For use case 3a, how do the links and ports
> look like when described on the Ethernet layer (without describing the
> underlying fiber infrastructure). Would be possible to distinction to
> describe the connections A1, B1 and C2? For use case 3b, how to describe
> the links, ports and adaptation if only the fiber layer and adaptations
> are described, but the Ethernet layer is not explicitly defined (but
> should be inferred from the underlying infrastructure on the lower layer).
Is your diagram then a bidirectional diagram?   It seems to me this 
should really be a diagram of unidirectional links to avoid asymetric 
and diverse connectivity issues.
> Regards,
> Freek
>
>
> _______________________________________________
> 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/c1b0feaa/attachment.html>

From Freek.Dijkstra at sara.nl  Wed Feb 22 16:50:58 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 22:50:58 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F454DC1.3060705@nordu.net>
References: <4F44BAC1.70500@sara.nl> <4F44F959.80909@man.poznan.pl>
	<4F453DE3.7060109@sara.nl> <4F454DC1.3060705@nordu.net>
Message-ID: <4F456342.9020803@sara.nl>

Jerry Sobieski wrote:

> Exactly.  I view a topology as [initially] an abstract domain that 
> comprises a comprehensive but finite switching function between points 
> at its boundary.   We can map those points to co-registered points in 
> another topology that expresses some other aspects - perhaps 
> geolocation, or internal connectivity, or policy-based capabilities, or 
> a combination thereof.  A perfect example would be a simple abstract 
> topology announced publicly that mapsTo a much more detailed internal 
> physical topology that the local network wishes to manage itself.   The 
> NSA is the agent that speaks to other NSAs inter-domain (at whatever 
> domain level we are at) and translates as necessary to local agents that 
> do the dirty work internally.

> It is important IMO that NML be recursive and abstract in this manner as 
> well as able to capture physical hdw engineering trappings.    It looks 
> like it is very close to being able to do this.

NML is partly capable of defining recursive topologies.
* It does not dictate till what level a topology should be abstracted,
and is designed to make this irrelevant (I recommend to give figure 7 of
ITU-T G.800 a good stare: "Example of recursive partitioning")

* NML does not yet define how to tie topologies of different abstraction
together, other than that all ports at the edge of a the more abstract
topology will also be ports at the edge of the less abstract topology,
and should (in my view) get the same identifier.
A 'mapTo' relation may be a possibility.

We played with the concept of virtualisation during OGF 23 in Barcelona
(see https://forge.ogf.org/sf/go/doc15482), which does this for nodes
(both partitioning a physical node into smaller logical nodes as well as
grouping nodes into something that we now call a "topology"). The
discussion was resolved by making all concepts: both node and topology
abstract. Thinking about it, if nodes in NML are also abstract, perhaps
both concepts (topology and node) are the same, only on different levels
of abstraction.

I like to hear from nml-wg participants:
- if they think that NML should be capable of defining a topology at
different layers of abstraction
- how these different descriptions should be tied together. Should we
define a relation between them?

For the NSI participants I'm interested in hearing if you think that
only NML should define different levels of abstraction, or if you also
expect NSNetwork to have different levels of abstraction, and if an NSA
have different levels of abstraction. (I presume both have, given that
NSA supports a tree-like request structure, where a top-NSA can delegate
requests for path provisioning to other NSA).

Regards,
Freek

From Freek.Dijkstra at sara.nl  Wed Feb 22 16:53:55 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 22:53:55 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F45496B.1070309@nordu.net>
References: <4F44BAC1.70500@sara.nl> <4F44F959.80909@man.poznan.pl>
	<4F45496B.1070309@nordu.net>
Message-ID: <4F4563F3.2050101@sara.nl>

Jerry Sobieski wrote:

> What is a "bidirectional port"?   It is really two ports
> bound together for purposes of ... what?

A NML bidirectionalport currently only groups two nml:ports.
The sole purpose is that you can stick a name to it. Nothing more.

NML, as is currently stands is pure unidirectional. E.g. it is not yet
possible to say that a nml:bidirectionalport it is attached to
nml:bidirectionallink (which also exists). You need to describe those
relations using the underlying unidirectional ports and links.

We're not overly thrilled with this restriction, but we postponed the
addition of a bidirectional component till we solved other problems
first, like getting more experience with the switching capabilities and
adaptations we defined at OGF 33, or the integration with the NSI
control plane. Adding more headaches because of mixing directionality
("how do I connect my single bidirectional port to your two
unidirectional ports?") have less priority.


> Topo X1. [...]
>
> Topo X2a & X2b.  [...]
>
> TopoX3.  [...]

These are useful, but take time to create.  Even though I like to, I am
currently not able to take this up as volunteer.

Freek

From Freek.Dijkstra at sara.nl  Wed Feb 22 17:06:02 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Wed, 22 Feb 2012 23:06:02 +0100
Subject: [Nml-wg] Conf call Feb 23
Message-ID: <4F4566CA.8050902@sara.nl>

No-one objected to the shift in starting time, so it is set:

NML conference call starts at:
*** 16:00 UCT (17:00 CET, 8:00 Pacific, 11:00 Eastern). ***

Call: +1-734-615-7474 (Please use if you do not pay for Long Distance)
or +1-866-411-0013 (toll free US/Canada Only)
Enter access code: 0186145

Agenda:
1. Action points from previous call:
Jeroen to go through document and set up action points
Jeroen to check the Security considerations of NM
Freek to contact NSI to set up topology discussion
Freek and Roman to create an NML version of the topology

2. Preparation for OGF 34
- Participants
- Presentations
- Work items
- NML-NSI integration

3. Short discussion on:
- unidirectionality of NML
- difference between NML:topology, dtox:NSNetwork, dtox:NSA
- recursion of NML topologies
- ...
(the goal of the discussion is to (1) identify new issues, (2) formulate
work items for these issues and (3) assign volunteers to them)

Note that I plan to use the tracker at
https://forge.ogf.org/sf/tracker/do/listTrackers/projects.nml-wg/tracker
again.

Regards,
Freek


From romradz at man.poznan.pl  Thu Feb 23 09:23:24 2012
From: romradz at man.poznan.pl (=?UTF-8?B?Um9tYW4gxYFhcGFjeg==?=)
Date: Thu, 23 Feb 2012 15:23:24 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F456342.9020803@sara.nl>
References: <4F44BAC1.70500@sara.nl>
	<4F44F959.80909@man.poznan.pl>	<4F453DE3.7060109@sara.nl>
	<4F454DC1.3060705@nordu.net> <4F456342.9020803@sara.nl>
Message-ID: <4F464BDC.1030302@man.poznan.pl>

W dniu 2012-02-22 22:50, Freek Dijkstra pisze:
> Jerry Sobieski wrote:
>
>> Exactly.  I view a topology as [initially] an abstract domain that
>> comprises a comprehensive but finite switching function between points
>> at its boundary.   We can map those points to co-registered points in
>> another topology that expresses some other aspects - perhaps
>> geolocation, or internal connectivity, or policy-based capabilities, or
>> a combination thereof.  A perfect example would be a simple abstract
>> topology announced publicly that mapsTo a much more detailed internal
>> physical topology that the local network wishes to manage itself.   The
>> NSA is the agent that speaks to other NSAs inter-domain (at whatever
>> domain level we are at) and translates as necessary to local agents that
>> do the dirty work internally.
>> It is important IMO that NML be recursive and abstract in this manner as
>> well as able to capture physical hdw engineering trappings.    It looks
>> like it is very close to being able to do this.
> NML is partly capable of defining recursive topologies.
> * It does not dictate till what level a topology should be abstracted,
> and is designed to make this irrelevant (I recommend to give figure 7 of
> ITU-T G.800 a good stare: "Example of recursive partitioning")
>
> * NML does not yet define how to tie topologies of different abstraction
> together, other than that all ports at the edge of a the more abstract
> topology will also be ports at the edge of the less abstract topology,
> and should (in my view) get the same identifier.
> A 'mapTo' relation may be a possibility.
>
> We played with the concept of virtualisation during OGF 23 in Barcelona
> (see https://forge.ogf.org/sf/go/doc15482), which does this for nodes
> (both partitioning a physical node into smaller logical nodes as well as
> grouping nodes into something that we now call a "topology"). The
> discussion was resolved by making all concepts: both node and topology
> abstract. Thinking about it, if nodes in NML are also abstract, perhaps
> both concepts (topology and node) are the same, only on different levels
> of abstraction.
>
> I like to hear from nml-wg participants:
> - if they think that NML should be capable of defining a topology at
> different layers of abstraction

Yes but I would make this more general and say - just different layers. 
They could be abstractions or tech layers (I'm thinking that layers may 
be also a good solution to control publishing information by configuring 
somehow that only some layers can be distributed, others not; a single 
abstraction could be split into more layers because of some reasons; it 
would be up to the implementation)

> - how these different descriptions should be tied together. Should we
> define a relation between them?

I think so. The work on examples will help to progress.

Roman

> For the NSI participants I'm interested in hearing if you think that
> only NML should define different levels of abstraction, or if you also
> expect NSNetwork to have different levels of abstraction, and if an NSA
> have different levels of abstraction. (I presume both have, given that
> NSA supports a tree-like request structure, where a top-NSA can delegate
> requests for path provisioning to other NSA).
>
> Regards,
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg


From Freek.Dijkstra at sara.nl  Thu Feb 23 10:21:35 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 23 Feb 2012 16:21:35 +0100
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F464BDC.1030302@man.poznan.pl>
References: <4F44BAC1.70500@sara.nl>
	<4F44F959.80909@man.poznan.pl>	<4F453DE3.7060109@sara.nl>
	<4F454DC1.3060705@nordu.net> <4F456342.9020803@sara.nl>
	<4F464BDC.1030302@man.poznan.pl>
Message-ID: <4F46597F.4020707@sara.nl>

Roman ?apacz wrote:

>> I like to hear from nml-wg participants:
>> - if they think that NML should be capable of defining a topology at
>> different layers of abstraction
> 
> Yes but I would make this more general and say - just different layers. 
> They could be abstractions or tech layers (I'm thinking that layers may 
> be also a good solution to control publishing information by configuring 
> somehow that only some layers can be distributed, others not; a single 
> abstraction could be split into more layers because of some reasons; it 
> would be up to the implementation)

Network layers indeed abstract the underlying complexity, but I presume
that there is also a need to abstract a single-layer network.
Hence, I propose to treat these two as different tasks for now (if we
can integrate them later in the same concept, that would be great).

I like to spend some time before next OGF to look into VLAN and layer
abstraction; if someone else would like to take up the topology
abstraction (if only single layer abstraction), that would be awesome.

>> - how these different descriptions should be tied together. Should we
>> define a relation between them?
> 
> I think so. The work on examples will help to progress.

Agreed. I will dot this down as a work item. That can be either one of
Jerry's suggested examples, or just some artificial example.

Freek

From jerry at nordu.net  Thu Feb 23 10:56:16 2012
From: jerry at nordu.net (Jerry Sobieski)
Date: Thu, 23 Feb 2012 10:56:16 -0500
Subject: [Nml-wg] NMLify of AutoGOLE topology
In-Reply-To: <4F464BDC.1030302@man.poznan.pl>
References: <4F44BAC1.70500@sara.nl>
	<4F44F959.80909@man.poznan.pl>	<4F453DE3.7060109@sara.nl>
	<4F454DC1.3060705@nordu.net> <4F456342.9020803@sara.nl>
	<4F464BDC.1030302@man.poznan.pl>
Message-ID: <4F4661A0.1020205@nordu.net>



On 2/23/12 9:23 AM, Roman ?apacz wrote:
> W dniu 2012-02-22 22:50, Freek Dijkstra pisze:
>> I like to hear from nml-wg participants:
>> - if they think that NML should be capable of defining a topology at
>> different layers of abstraction
>
> Yes but I would make this more general and say - just different 
> layers. They could be abstractions or tech layers (I'm thinking that 
> layers may be also a good solution to control publishing information 
> by configuring somehow that only some layers can be distributed, 
> others not; a single abstraction could be split into more layers 
> because of some reasons; it would be up to the implementation)
>
Yes.(!) Exactly.
>> - how these different descriptions should be tied together. Should we
>> define a relation between them?
>
> I think so. The work on examples will help to progress.
>
> Roman
>
>> For the NSI participants I'm interested in hearing if you think that
>> only NML should define different levels of abstraction, or if you also
>> expect NSNetwork to have different levels of abstraction, and if an NSA
>> have different levels of abstraction. (I presume both have, given that
>> NSA supports a tree-like request structure, where a top-NSA can delegate
>> requests for path provisioning to other NSA).
The different levels are IMO necessary.    For instance:  NORDUNet could 
present itself to external agents as a single point abstraction-one NSI 
Network with one NSA, hiding all internal structure.    There are valid 
reasons for doing this - some technical, some purely business related.   
Alternatively, NORDUnet could express itself as a federation of 
subdomains - perhaps an NSI network in NYC, another in CPH.   And while 
I might expose these abstracted NSI [sub]Networks  and the links between 
them and the outside world publicly, I would still hide the underlying 
physical infrastructure that provides those capabilities.  And there is 
a *lot* of underlying infrastructure that is not exposed.  This more 
detailed abstracted topology allows me to offer service characteristics 
(geo location, latency, etc) without losing the abiity to re-engineer 
those service capabilites as I deem necessary to meet my service objectives.

These abstractions are fundamentally necessary because not all of our 
service provisioning is purley a matter of links and adaptations...there 
is a lot of policy and "service" added to the infrastructure.
>>
>> Regards,
>> Freek
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
>

From Freek.Dijkstra at sara.nl  Thu Feb 23 12:35:14 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 23 Feb 2012 18:35:14 +0100
Subject: [Nml-wg] Call for presentations during OGF 34
Message-ID: <4F4678D2.6020304@sara.nl>

Hi,

I you consider giving a formal or informal presentation during one of
NML's timeslots at the upcoming OGF 34 conference, please contact me
on-list or off-list, preferably in the next week.

Thanks,
Freek

From Freek.Dijkstra at sara.nl  Thu Feb 23 13:28:25 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 23 Feb 2012 19:28:25 +0100
Subject: [Nml-wg] Notes for Feb 23 conf call
Message-ID: <4F468549.3000303@sara.nl>

Here are some notes from todays call. Some text is shuffled for
readability. If you have any correction or additions, please follow up.
The actions items are at the end of the notes.

Notes for NML call 23 February
==============================

Attendance: Aaron Brown (I2), Jerry Sobieski (Nordunet), Roman ?apacz
(PSNC), Freek Dijkstra (SARA)
Excused: Jason Zurawski, Jeroen van der Ham, Chin Guok

1. Action items from previous call:
----------------------------------

Jeroen was not able to attend today's call; his action items will be
postponed to the next call.

Roman and Freek send NMLified version of the AutoGOLE topology to the
list. Jerry was pleased to see them and thinks they're great starting
points for integrating NML and NSI concepts. Jerry suggested to create a
smaller example. Freek suggests to instead pick one network and compare
them in the original and proposed drafts.

Freek contacted the NSI group about the integration, but got no formal
reply yet. The NSI-WG is currently very busy on other topics. Freek will
contact Guy for the best time slot.

2. Preparation for OGF 34.
-------------------------

Freek, Roman and Jerry will attend OGF 34. Likely no-one from Internet2
will be able to attend.
Freek will sent out a call for presentations.

The topics during OGF 34 will be:
* NML-NSI integration
  - unidirection
  - explicit links
* recursion of topologies (discussion/proposal)
* VLAN description (discussion/proposal)
* General document improvement (WORKING session a.k.a. the
shut-up-and-start-writing-session)

3a. NML-NSI integration
-----------------------

NSI issues:
* Enumeration: Possible large number of end-points. Unclear how to group
them.
* Distribution process: how to update the world view by each nml/nsi
topology consumer and how to deal with inconsistencies.

Nordunet issue:
* NORDUnet has multiple locations (New York and Copenhagen). Not really
one network.
Three solution: (1) one network, with exposing some of the internal
details and constraints, or (2) describe as 2 topologies with 1
controlling NSA.
* In practice multiple topologies are needed: one detailed topology for
internal use; one published to trusted peers; perhaps yet another
published to end-users or other entities.

3b. Unidirectional vs bidirectional
-----------------------------------

Freek gives some background. When the topic came up first, it was
decided that is was probably easier to pick one instead of doing both at
the same time. Since unidirectional is more flexible, that was chosen.
It was acknowledged that a bidirectional concept is useful, but for
simplicity, this was only a grouping of unidirectional links.

Jerry sees use case where not specifying directionality gives ambiguity.

There are examples where bidirectionality is required. Freek recalled an
example given by Richard Hughed-Jones: a single fiber strand, that
carries data in two directions. Upstream at 1310 nm, and downstream at
1550 nm. This is an actual technology used in some FttH networks.

A broadcast network has multiple output ports.

Roman asks Freek and Jerry to write down these use cases.

3c. Difference between NML:topology, dtox:NSNetwork, dtox:NSA
-------------------------------------------------------------

NML topology is set on network object with some internal connectivity

NSI Network is a connection service.

A NML topology should be thought of as a big round circle with ports on
the edges, and a black box in the middle that can provide some data
transport. The document surely has a more formal definition. A NML
network not the same thing. A NML network is a IP subnet; think of it as
a Ethernet VLAN with attached hosts. These terms were decided in Munich
after a rather lengthy discussion where we concluded that the term
"Network" was severely overloaded.

Jerry: propose to put dtox:nsnetwork in nml:topology for now, and
perhaps take it a step further, put all child elements of dtox:nsnetwork
in directly in the nml:topology.

Freek and Jerry will look at the exact definition of NML:Topology and
NSI Network, and see if they can sync their definition. If that is
possible, they are the same thing. If not, we can than think what the
relation between the two is.

3d. Recursion of NML topologies
-------------------------------

Layers have abstraction, but there is also recursion on a single layer.

Freek referred to figure 7 of G.800. The public URL of G.800 is:
http://www.itu.int/rec/T-REC-G.800

(Note: ITU-T just published a new version of G.800 this month; Freek
referred to figure 7 in the 2007 version of the document. Direct link:
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.800-200709-S!!PDF-E&type=items)

Roman: can there be more than one NSI network in a domain?
Jerry: Each NSA controls exactly one NSI Network, and each NSI Network
is controlled by exactly one NSA.
Both NSI Network and NSA can recursive. E.g. a federated NSA can act a
agent for multiple subdomain NSAs.

NML should be able to describe a federated topology, and subtopologies.
We need to define how to describe the relation of these topologies with
each other.

Jerry will write this down as a use case (he has multiple slides on it)
Freek will dig up the URL for the use-case tracker:
https://forge.ogf.org/sf/tracker/do/listArtifacts/projects.nml-wg/tracker.use_cases

NSI has control plane topology and data plane topology.
Jerry hopes that NML topology constructs can be described by NML concepts.


Action items:
=============

* Jeroen to go through document and set up action points
* Jeroen to check the Security considerations of NM
* Freek to write use case on bidirectional and unidirectional links:
single fiber with two wavelengths in different directions.
* Jerry to write use case on bidirectional and unidirectional links
* Jerry to write usecase on NORDUnet being a geographical segregated
network (NY and CPH), with possible restrictions between the two
locations/networks
* Jerry to write this down federated and sub-NSA as a use case.
* Freek and Jerry look at the exact definition of NML:Topology and NSI
Network, and see if they can sync their definition

From Freek.Dijkstra at sara.nl  Thu Feb 23 13:30:06 2012
From: Freek.Dijkstra at sara.nl (Freek Dijkstra)
Date: Thu, 23 Feb 2012 19:30:06 +0100
Subject: [Nml-wg] Conf call March 1
Message-ID: <4F4685AE.6010708@sara.nl>

The next NML conf call will be shifted in time (again).
Jerry and Roman excused themselves for the next call.

NML conference call starts at:
*** 16:30 UCT (17:30 CET, 8:30 Pacific, 11:30 Eastern). ***

Call: +1-734-615-7474 (Please use if you do not pay for Long Distance)
or +1-866-411-0013 (toll free US/Canada Only)
Enter access code: 0186145


From vdham at uva.nl  Wed Feb 29 17:48:14 2012
From: vdham at uva.nl (Jeroen van der Ham)
Date: Wed, 29 Feb 2012 23:48:14 +0100
Subject: [Nml-wg] Conf call March 1
In-Reply-To: <4F4685AE.6010708@sara.nl>
References: <4F4685AE.6010708@sara.nl>
Message-ID: <FA4BEDA7-5670-4E62-8302-91DAFB68A7DF@uva.nl>

Hi,
The NMC call is cancelled this week so we're moving the call to half an hour earlier than the times below. Calculation is left as an exercise to the reader ;)

Jeroen. 



On 23 feb. 2012, at 19:30, Freek Dijkstra <Freek.Dijkstra at sara.nl> wrote:

> The next NML conf call will be shifted in time (again).
> Jerry and Roman excused themselves for the next call.
> 
> NML conference call starts at:
> *** 16:30 UCT (17:30 CET, 8:30 Pacific, 11:30 Eastern). ***
> 
> Call: +1-734-615-7474 (Please use if you do not pay for Long Distance)
> or +1-866-411-0013 (toll free US/Canada Only)
> Enter access code: 0186145
> 
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

From zurawski at internet2.edu  Wed Feb 29 18:56:40 2012
From: zurawski at internet2.edu (Jason Zurawski)
Date: Wed, 29 Feb 2012 18:56:40 -0500
Subject: [Nml-wg] Conf call March 1
In-Reply-To: <FA4BEDA7-5670-4E62-8302-91DAFB68A7DF@uva.nl>
References: <4F4685AE.6010708@sara.nl>
	<FA4BEDA7-5670-4E62-8302-91DAFB68A7DF@uva.nl>
Message-ID: <4F4EBB38.1030101@internet2.edu>

Hi All;

I will be unable to attend tomorrow.

-jason

On 2/29/12 5:48 PM, thus spake Jeroen van der Ham:
> Hi,
> The NMC call is cancelled this week so we're moving the call to half an hour earlier than the times below. Calculation is left as an exercise to the reader ;)
>
> Jeroen.
>
>
>
> On 23 feb. 2012, at 19:30, Freek Dijkstra<Freek.Dijkstra at sara.nl>  wrote:
>
>> The next NML conf call will be shifted in time (again).
>> Jerry and Roman excused themselves for the next call.
>>
>> NML conference call starts at:
>> *** 16:30 UCT (17:30 CET, 8:30 Pacific, 11:30 Eastern). ***
>>
>> Call: +1-734-615-7474 (Please use if you do not pay for Long Distance)
>> or +1-866-411-0013 (toll free US/Canada Only)
>> Enter access code: 0186145