Comments inline...

On 3/29/11 6:18 AM, Guy Roberts wrote:

My understanding is that you are currently planning to implement AutoBAHN internally in GÉANT and an NSI interface facing other dynamic services.  In this case, GÉANT will be treated by an NSI request as a leaf network, for this reason any connection request will be a single-Network request (i.e not a multi-domain request).  This means that the Origin and Destination STPs will also be the service end-points.

This is correct.

  So in this case you are able to look at the Access Framing type to find out if the STP reflects a tagged or untagged Ethernet port.

The STP *represents* a topological location where the service does or 
could terminate.  i.e. It *links* to the TopoDB.   It is *not* the 
topoDB.  So using the STP name, the NSA indexes into the topologyDB to 
find the corresponding topological object (a port, or VLAN, or...)  
Specifics about the termination point is then found in the topology DB - 
not in the STP name itself.

Access Framing types (and VLANs?) are described in the service definition associated with the connection request:

OrigSTP    := NSISTP(OrigSTP)==True;    /* STP */
DestSTP    := NSISTP(DestSTP)==True;   /* STP */
Bandwidth  := 1..1000 Mbps, default=10 Mbps;
AccessFraming:= 	802.1,  /* payloads in untagged frames */
		 	802.1q, /* payloads in tagged frames */
		 	802.1ah,/* tagged frames are the payload */
		 	default=802.1q; /* only tagged payloads */

Note that this would change if you were to implement NSI between AutoBAHN IDMs.  Since the access framing only refers to the service access points, intermediate 'stitching points' between networks are represented by STPs which are technology agnostic labels only, so to find the technology detail it would be necessary to dig down (i.e perform some lookup of the full NML representation).

Yes, NSI endpoint names (STPs) are technology agnostic.  They represent 
points where the *service* can terminate (whatever the service may be.)  
The "stitching" points are simply STPs in two adjacent networks that are 
indicated to correlate to the same *topological location* i.e. if you 
plug a fiber into a port, the end of the fiber, and the port interface 
now correlate to the same topological location.  Therefore they exhibit 
the same topological characteristics.   Likewise at the service level, 
if your ethernet service connects to my ethernet service at a particular 
endpoint on your service and a similar endpoint on my service, then 
those two endpoints now correlate to the same topological location, and 
exhibit the same characteristics, and they constitute the inter-domain 
connection of our two networks, or the stitching point.

Guy

-----Original Message-----
From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Radek Krzywania
Sent: 29 March 2011 10:26
To: nsi-wg@ogf.org
Subject: [Nsi-wg] comments to WSDL files

Hi,
Michal has get through the WSDL file, the comments are below:
- WSDL seems to be fine, and not very difficult to adopt in various software (i.e. AutoBAHN)
- 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...)

We should re-iterate this:  Since the specifics of physical resources 
are managed by the NRM  there is no need for the NSAs to know about or 
to specify anything more specific than the network and localname of the 
endpoint.   It is the NRM's job to convert the global NSI address to the 
local hardware specifics.

With regard to WSDLs, the WS implementation of the NSI CS primitives 
does not redefine any of the NSI semantics.    The NSI primitive XML 
descriptions (the message formats) look the same regardless of whether 
they are processed by a WS or by a lower layer protocol.

I hope this helps explain why we do not include hardware specifics in 
the provisioning semantics.  Why do you say hardware specific end point 
information would be useful at the interdomain level.??

BR
Jerry

Best regards
Radek

________________________________________________________________________
Radoslaw Krzywania                      Network Research and Development
                                            Poznan Supercomputing and
radek.krzywania@man.poznan.pl                   Networking Center
+48 61 850 25 26                             http://www.man.poznan.pl
________________________________________________________________________

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg