[Nsi-wg] comments to WSDL files

[Jerry Sobieski]

Oops - one thing I should make clear below...

O
>> - In ServiceTerminationPointType, it would be useful to have information whether port is tagged or not (VLANs information is not stored also). I know that we would like to keep the messages as technology agnostic as possible, but we need to have a balance between functionality and simplicity/universality here. In case of AutoBAHN we can probably do some workarounds to evade the issue, however this is not plug-and-play ;)
> Hej Radak-
>
> The STP is just an NSI name.<network>:<localname>     NSI does not
> encode any physical topology information into the name.  It is just a
> name.  I expect the NSA would use the name to index into a table of
> local names to link to the local topologyDB. (Alternatively, the NSA may
> simply search the local TopoDB for a topology object with this NSI name.
> ...but this is all an implementaion detail)   The topoDB would indicate
> whether that STP maps to a port or VLAN or something else.  Since NSI
> does not define any technology specific topology information, things
> like VLANs and ports etc are only of significance to the local NRM
> (AutoBahn in this case).   And it becomes the responsibility of the NRM
> (AutoBahn in this case) to provide a translation from the NSI local
> endpoint name to any NRM specific denotion.  (Also, since each NRM is
> different, it would be impractical for the NSA to know each dialect of
> every NRM it might encounter...)
The *service* specifics - things like bandwidth or MTU or other service 
related specifics of a particular connection service are defined in the 
Service Definition.  The ReservationRequest contains such service 
attributes, and they are qualified against the Service Definitions of 
the transit networks, but they are not specifically part of the NSI-CS 
protocol.

We have tried to separate the service specifics from the protocol(s) 
that communicate them.   The NSI-CS protocol recognizes an abstract 
model of a "connection", but hardware specifics of a particular 
connection service offering or a particular service instance are not 
hard wired into the NSI-CS protocol.  This will allow a great deal of 
flexibility to map multi-layer and heterogenous connection services and 
their dialects to the same generic and global protocol framework.

Hope this helps a bit more..
J