[Nsi-wg] NSI-CS initial SD for Ethernet transport
Jerry Sobieski
jerry at nordu.net
Mon Apr 11 22:20:17 CDT 2011
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
More information about the nsi-wg
mailing list