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

[John MacAuley]

Actually, after sleeping on it I think I need to ask the question why we are specifying the format of the STP identifier in the service description?  Should this not be in the protocol spec?  Will this change based on service offered?

On 2011-04-11, at 11:20 PM, Jerry Sobieski wrote:

> 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:maxInclusive value="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/20110412/40db9f9d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110412/40db9f9d/attachment.bin