[Nsi-wg] NSI-CS initial SD for Ethernet transport

[Jerry Sobieski]

Hi John-

On 4/11/11 9:58 PM, John MacAuley wrote:
> Jerry,
>
> Had a look at the XSD and have a few comments.
>
> 1. Run a spell checker over the comments.  There are a few spelling 
> mistakes.
>
No doubt.   How do I get Oxygen to create a .docx file for inclusion in 
word?  It spits out HTML or PDF or DOCBOOK format - none of which are 
sutible for the word processor we use.  Ugh.

> 2. "serviceNameType" why restrict the length 4-32 of the name?
Why make it longer than it needs to be?

This is just a service name.  Its as trng used for matching.  It 
differntiates two services.   If you allow a name to be any length, it 
becomes unwieldy and difficult to match on.  The 4 character min was 
just arbitrary - I hesitate to allow a service name to be "0"... It 
should be at least a little bit descriptive.
As for maxlength=32, again arbitrary.  But I do believe it should be 
finite and only as long as neccesry to perform the function it is meant 
to perform: identifying the service parameters associated with the service.

Just because we can make it any length does not mean we should or that 
doing so improves it.
>
> 3. "Orig" STP is restricted to value="[a-zA-Z0-9$]+:[a-zA-Z0-9$]+". It 
> seems an arbitrary restriction, and restricts implementations from 
> having a proper URN for the endpoint name as specified in NML and the 
> GLIF.  Can we please reduce the restriction?
The value of the NSI Endpoint names is whatever the NSI specifies.  And 
I thought we had tentatively agreed that for NSI endpoint names, the 
GLIF tuple was adequate.  I put these characters in from memory for what 
the GLIF global naming recommendation allowed.   So there may be some 
other characters missing, but colons are definitely not allowed as they 
were explicitly used to separate the global portion form the local portion.

Remember John:  The syntax of Network names and Endpoint names are not 
part significant in the NSI-CS application.  The tuple is significant.   
A name that is unecessarily complex will impede adoption.  These are 
names users apply to their interfaces, and what they will use in their 
service requests.   Why do these need to be URNs?  WhatURN would you 
specify they use?  If you need this user specified string to be part of 
a name space, can't you do that in your code?  What does the user get 
out of it? The user will provide a name in the service request that 
represents his cluster or server.  How do they know what the URN 
designator will be or ought to be?    Why do you expect some biomedical 
researcher to name their video system with a GLIF URN?

The naming works as it is.    Why do you think it needs to be URNs?

> 4. Same for the "Dest" STP.
>
> 5. For "Bandwidth" there is an upper limit of 
> <xsd:maxInclusivevalue="1000"/>Mb/s or 1 Gb/s.  With 10GE in the 
> network should we not consider a higher limit?
>
Oops.  My mistake.  Indeed, perhaps we should bump this to 100 Gbps?

Just to argue :-) Actually, the service definition as stated is fine.  
If some network has a 10 Gbps offering, or a 100 Gbps offering, they can 
change this upper limit.  They would still have a conforming Service 
Definition.  It would offer higher speeds, but it would be the same 
essential service offering.  (This is the beauty of SDs...networks can 
adjust the parameters somewhat and still interoperate.  For instance, if 
we put the bandwith upper limit at 100Gbps, and no one had 100 Gbps, 
they would just independently drop this to 10 Gbps or 1 Gbps and would 
also still conform.
> 6. We have a "ScheduleStart" and a "ScheduleEnd" but we have not 
> specified a maximum duration.
I tried to figure out how to validate the schedule parameters using the 
xsd.   This is not easy since different cases are presented by the 
relative time to the time when the request is received.  E.g. a Start 
time before "now" is not possible...so does it mean "asap"?   Is a start 
date of 0000/00/00 allowed?

So I put a very simple parameterization in for now.  A valid dateTime is 
required, but we leave it to the NSA to resolve what time it is now, and 
same with the end time/duration...   We could allow a duration, but what 
does validating do for us?   (I think duration is useful, let me hit it 
again...)

Another useful feature of the SD:  Since the Service itself is not part 
of the standard it can be modified indepednetly of the standard.   A 
group of us could take this XSD and hammer a more sophisticated service 
into it.   One that has a maximum Duration  attribute.   This does not 
prevent this basic SD from working.  Right?   Sure, it may not be 
perfect, but the Service Definition can be changed.   Thats why in the 
name I included a Version x.x string at the end - this can indicate 
which version of the service is being processed or is desired.

> Thank you,
You too!
J
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110411/9ffb87ec/attachment-0001.html