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

[Jerry Sobieski]

You are right, John.   All I was doing in the SD was trying to make sure 
it conforms to whatever the spec required.
There may be some specifics here to be changed, but the Orig and Dest 
STP names are really NSI Endpoints ...so whatever Enspoints require.

J

On 4/12/11 7:47 AM, John MacAuley wrote:
> 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: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/20110412/d1b6be3d/attachment-0001.html