[Nsi-wg] 08-20-topology-discussion-nsi-wg Digest, Vol 36, Issue 23
???(YoungWook Cha)
ywcha at andong.ac.kr
Tue Aug 23 19:45:57 CDT 2011
===================================
http://ngn.andong.ac.kr
NGN Lab. Comp. Engineering Dept.
Andong National University
+82-10-2456-3237, +82-54-820-5714
===================================
----- Original Message -----
From: <nsi-wg-request at ogf.org>
To: <nsi-wg at ogf.org>
Sent: Monday, August 22, 2011 9:15 PM
Subject: nsi-wg Digest, Vol 36, Issue 23
> Send nsi-wg mailing list submissions to
> nsi-wg at ogf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.ogf.org/mailman/listinfo/nsi-wg
> or, via email, send a message with subject or body 'help' to
> nsi-wg-request at ogf.org
>
> You can reach the person managing the list at
> nsi-wg-owner at ogf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nsi-wg digest..."
>
>
> Today's Topics:
>
> 1. Re: NSI specific topology recommendation for plug fest.
> (John MacAuley)
> 2. Re: NSI specific topology recommendation for plug fest.
> (Jeroen van der Ham)
> 3. Re: NSI specific topology recommendation for plug fest.
> (Jerry Sobieski)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 Aug 2011 00:39:54 -0400
> From: John MacAuley <john.macauley at surfnet.nl>
> Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug
> fest.
> To: John MacAuley <john.macauley at surfnet.nl>
> Cc: NSI WG <nsi-wg at ogf.org>
> Message-ID: <7769F884-3DA9-412B-8599-1A3B64730CCA at surfnet.nl>
> Content-Type: text/plain; charset="windows-1252"
>
> Found a small issue in the example owl.
>
>
> On 2011-08-19, at 10:16 PM, John MacAuley wrote:
>
>> Peoples,
>>
>> I think the existing detailed DTOX topology models we have been generating are excellent. I can definitely see how I will be able to incorporate this into future versions of OpenDRAC as a primary topology import mechanism, however, I do not think it is capturing the simplified concepts in NSI that are needed for the demo.
>>
>> I have been playing around with the example topologies trying to massage them into a form where I can learn not only the network and STP topologies, but the managing NSA topologies as well. I found that the existing DTOX topology is very good at the details of nodes, switch matrixes, and ports, but I had a hard time filtering down to the simple aspects. I also believe we will get into some trouble if we try to use the port class to model STP while also modeling physical ports. I am not sure if the DTOX schema can handle this aspect, as I could not find a describing schema.
>>
>> I spent time over the last couple of days discussing this with Jerry while we worked through the plug fest scenarios. He provided good feedback and pulled together the attached slide showing the concepts we are trying to capture. I also mocked up an example OWL file with an NSI topology specific name space, and introduced the NSI concepts of NSnetwork, STP, and NSA. These classes are used to model their simplified namesakes from the NSI CS protocol, and are not meant to replace the DTOX definitions, but augment them with our NSI specific concepts. We can consider the NSI topology elements an overlay on the existing DTOX elements, reusing data properties and including references to DTOX object instances. (I removed the DTOX object instances from the file to simplify the example). I think this will become much clearer when running NSI on out real networks and not this abstract topology for the demo.
>>
>> I have not yet validated the attached OWL so I apologize if it contains errors. The following classes and properties are introduced in the file?
>>
>> NSnetwork: We model a NSI network with the NSnetwork class.
>>
>> Example URN: urn:ogf:network:NSnetwork:Aruba
>>
>> Properties:
>>
>> ? label - display name for the network.
>> ? canSwap - indicates VLAN Id interchange is supported in the network domain.
>> ? managedBy - the Network Services Agent managing this network.
>> ? hasSTP - a set of references to the inter-domain Service Termination Points that are within this network.
>> ? hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network.
>>
>>
>> NSA: We model a Network Services Agent with the NSA class.
>>
>> Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
>>
>> Properties:
>>
>> ? label - display name for the NSA.
>> ? managing - indicates the network being managed by this NSA.
>> ? connectedTo - represents an NSA to which this NSA has a peering relationship.
>> ? dnsName - DNS name of the NSA.
>> ? csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface.
>> ? adminContact - administrative contact information for this NSA.
>>
>> STP: We model a logical Service Termination point with the STP class.
>>
>> Example URN: urn:ogf:network:stp:Aruba:Aiden
>>
>> Properties:
>>
>> ? label - display name for this STP.
>> ? partOf - indicates the member network of this STP.
>> ? connectedTo - a topological link identifying the peer STP to which this STP is connected.
>> ? mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX.
>>
>> We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments?
>>
>> Thank you,
>> John.
>>
>>
>> <nsi-interop-topology-example.owl>
>> <NSI topology model.pptx>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachment-0002.html
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: nsi-interop-topology-example.owl
> Type: application/octet-stream
> Size: 12053 bytes
> Desc: not available
> Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachment-0001.obj
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachment-0003.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 22 Aug 2011 11:10:26 +0200
> From: Jeroen van der Ham <vdham at uva.nl>
> Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug
> fest.
> To: John MacAuley <john.macauley at surfnet.nl>
> Cc: NSI WG <nsi-wg at ogf.org>
> Message-ID: <2EDE9B14-3E07-4C19-9BCC-A2EE695B5484 at uva.nl>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hello,
>
>
> On 20 Aug 2011, at 04:16, John MacAuley wrote:
>> NSnetwork: We model a NSI network with the NSnetwork class.
>>=20
>> Example URN: urn:ogf:network:NSnetwork:Aruba
>>=20
>> Properties:
>>=20
>> =B7 label - display name for the network.
>> =B7 canSwap - indicates VLAN Id interchange is supported in the =
> network domain.
>> =B7 managedBy - the Network Services Agent managing this network.
>> =B7 hasSTP - a set of references to the inter-domain Service =
> Termination Points that are within this network.
>> =B7 hasPart - a set of references to the DTOX Node =
> NamedIndividual representing network elements within this network.
>>=20
>>=20
>> NSA: We model a Network Services Agent with the NSA class.
>>=20
>> Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
>>=20
>> Properties:
>>=20
>> =B7 label - display name for the NSA.
>> =B7 managing - indicates the network being managed by this NSA.
>> =B7 connectedTo - represents an NSA to which this NSA has a =
> peering relationship.
>> =B7 dnsName - DNS name of the NSA.
>> =B7 csProviderEndpoint - the SOAP endpoint for this NSA's CS =
> provider interface.
>> =B7 adminContact - administrative contact information for this =
> NSA.
>>=20
>> STP: We model a logical Service Termination point with the STP class.
>>=20
>> Example URN: urn:ogf:network:stp:Aruba:Aiden
>>=20
>> Properties:
>>=20
>> =B7 label - display name for this STP.
>> =B7 partOf - indicates the member network of this STP.
>> =B7 connectedTo - a topological link identifying the peer STP to =
> which this STP is connected.
>> =B7 mapsTo - the logical STP represented by this object instance =
> maps through to this physical entity (port, vlan, etx.) in DTOX.
>>=20
>> We will need to start up a discussion after the plug fest to address =
> the issue of NSI topology needs. I believe these changes will do until =
> then. Comments?
>>=20
>
> How do you envision labels to be added to the above topology?
>
> The ontology above maps almost directly to the DTOX schema we created =
> before we started considering labels...
>
> The current test-topologies may not have labels in them, but as things =
> look now, they will always be part of the network, and will always be =
> something to consider when you are doing pathfinding.
>
> Jeroen.=
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 22 Aug 2011 08:15:09 -0400
> From: Jerry Sobieski <jerry at nordu.net>
> Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug
> fest.
> To: Jeroen van der Ham <vdham at uva.nl>
> Cc: NSI WG <nsi-wg at ogf.org>
> Message-ID: <7377BC40-AF8C-4FBD-B5D4-AF87DBDDED3D at nordu.net>
> Content-Type: text/plain; charset=utf-8
>
> Hi jeroen
>
> The issue is that currently NSI service termination points do not point to u=
> nder-specified endpoints such as ports with labels. As it stands today an N=
> SI STP would point to a particular label as the termination point for a circ=
> uit. To put something other than the terminating point of the circuit in t=
> he NSI reservation request implies a certain semantic about what specificall=
> y can be found in a request as an Endpoint and how to recognize and process i=
> t. We got into this briefly but decided it involved a lot of topology issu=
> es we were not able to address or answer at that time - so we shelved it unt=
> il we had a chance to discuss a more sophisticated NSI topology model.
>
> For now, for the plugfest, we can treat Ports as the STP. We will define a=
> ll interdomain peering points as untagged ports for the interop plugfest in R=
> io. In the Port object we either define a single label, (e.g. "0") or be=
> tter, no label at all. This must be coordinated with the peer network so th=
> at their corresponding Port object is defined similarly.
>
> IMO, the NSI working group has not worked out a consensus approach to how we=
> expect the protocol to treat "labels"...else it would already be in the sta=
> ndard. Strictly speaking, the NSI CS protocol works just fine as is - it j=
> ust maps STPs to particular labels. (note: the SNE editor offered no Label=
> object.) However, a number of folks are uncomfortable with this and want a=
> different treatment. We need to have this discussion, but there are relate=
> d issues we need to work through if we want all of these features to integra=
> te in a cohesive and fashion. =20
>
> Sent from my iPad3g
>
> On Aug 22, 2011, at 5:10 AM, Jeroen van der Ham <vdham at uva.nl> wrote:
>
>> Hello,
>>=20
>>=20
>> On 20 Aug 2011, at 04:16, John MacAuley wrote:
>>> forNSnetwork: We model a NSI network with the NSnetwork class.
>>>=20
>>> Example URN: urn:ogf:network:NSnetwork:Aruba
>>>=20
>>> Properties:
>>>=20
>>> =C2=B7 label - display name for the network.
>>> =C2=B7 canSwap - indicates VLAN Id interchange is supported in the n=
> etwork domain.
>>> =C2=B7 managedBy - the Network Services Agent managing this network.=
>
>>> =C2=B7 hasSTP - a set of references to the inter-domain Service Term=
> ination Points that are within this network.
>>> =C2=B7 hasPart - a set of references to the DTOX Node NamedIndividua=
> l representing network elements within this network.
>>>=20
>>>=20
>>> NSA: We model a Network Services Agent with the NSA class.
>>>=20
>>> Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
>>>=20
>>> Properties:
>>>=20
>>> =C2=B7 label - display name for the NSA.
>>> =C2=B7 managing - indicates the network being managed by this NSA.
>>> =C2=B7 connectedTo - represents an NSA to which this NSA has a peeri=
> ng relationship.
>>> =C2=B7 dnsName - DNS name of the NSA.
>>> =C2=B7 csProviderEndpoint - the SOAP endpoint for this NSA's CS prov=
> ider interface.
>>> =C2=B7 adminContact - administrative contact information for this NS=
> A.
>>>=20
>>> STP: We model a logical Service Termination point with the STP class.
>>>=20
>>> Example URN: urn:ogf:network:stp:Aruba:Aiden
>>>=20
>>> Properties:
>>>=20
>>> =C2=B7 label - display name for this STP.
>>> =C2=B7 partOf - indicates the member network of this STP.
>>> =C2=B7 connectedTo - a topological link identifying the peer STP to w=
> hich this STP is connected.
>>> =C2=B7 mapsTo - the logical STP represented by this object instance m=
> aps through to this physical entity (port, vlan, etx.) in DTOX.
>>>=20
>>> We will need to start up a discussion after the plug fest to address the i=
> ssue of NSI topology needs. I believe these changes will do until then. Co=
> mments?
>>>=20
>>=20
>> How do you envision labels to be added to the above topology?
>>=20
>> The ontology above maps almost directly to the DTOX schema we created befo=
> re we started considering labels...
>>=20
>> The current test-topologies may not have labels in them, but as things loo=
> k now, they will always be part of the network, and will always be something=
> to consider when you are doing pathfinding.
>>=20
>> Jeroen.
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
> ------------------------------
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> End of nsi-wg Digest, Vol 36, Issue 23
> **************************************
>
>
>
More information about the nsi-wg
mailing list