[Nsi-wg] NSI specific topology recommendation for plug fest.

[Jerry Sobieski]

Hi jeroen

The issue is that currently NSI service termination points do not point to under-specified endpoints such as ports with labels.  As it stands today an NSI STP would point to a particular label as the termination point for a circuit.    To put something other than the terminating point of the circuit in the NSI reservation request implies a certain semantic about what specifically can be found in a request as an Endpoint and how to recognize and process it.   We got into this briefly but decided it involved a lot of topology issues we were not able to address or answer at that time - so we shelved it until 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 all interdomain peering points as untagged ports for the interop plugfest in Rio.     In the Port object we either define a single label, (e.g. "0") or better, no label at all.  This must be coordinated with the peer network so that 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 standard.   Strictly speaking, the NSI CS protocol works just fine as is - it just 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 related issues we need to work through if we want all of these features to integrate in a cohesive and fashion.   

Sent from my iPad3g

On Aug 22, 2011, at 5:10 AM, Jeroen van der Ham <vdham at uva.nl> wrote:

> Hello,
> 
> 
> On 20 Aug 2011, at 04:16, John MacAuley wrote:
>> forNSnetwork: 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?
>> 
> 
> 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.
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg