[Nsi-wg] NSI CS XSD comments

[Jerry Sobieski]

On 4/13/11 11:22 AM, Jeff W. Boote wrote:
> I would go one step further here and say that there is no benefit in having multiple ways to specify most things in schema, and it makes interoperability and software development more cumbersome.  (i.e. For bandwidth, just specify an explicit unit. Do not have another parameter to define units. There is no benefit to having multiple ways to specify it and it just adds to complexity of software.)
>
Hi Jeff-  Yes. I concur.

I think a lot of folks dropped off the cal before we covered a few 
aspects of the Service Definition....

My thinking is to make a very simple SD.   A Service Name, and a list of 
Service Attributes.

Each Service Attribute will take one of only a very few forms so that 
the NSA validation module can compare Service Request Attributes with 
Service Definition Attributes.   For instance, a Service Attribute could 
take the form of a "range" (min, max), a "interval" (floor, ceiling, 
step), a "choice" ( "a", "b", "c",...), and probably a "dateTime" 
(yyyy-mm-ddThh:mm:ss).   Optional Service Attributes will have a default 
value, and lacking a default, the Attribute is required to be specified 
in the SR by the RA.  And Units would be explicit in the annotation of 
each Attribute.

THis allows the NSA to insure a complete and explicitly specified 
service request is communicated between RA and PA.  However, this is not 
[currently] sufficient to generalize the entire service allocation 
process...  But it will prune the search space considerably and allow a 
straight forward high level candidate path to be selected fairly easily. 
   So it is very useful.

The workings of Service Definitions will be increasingly obvious and 
important as new service capabilities in our networks are identified and 
engineered.   This SD process is one of the truly novel aspects of NSI 
that I think will be very useful in coming years.

At the moment, we need to define the minimum SD capability necessary get 
V1.0 out the door.   To this end, I have chucked the idea of a 
generalized XSD for service definitions - its difficult to do what I 
think we need done. And the bells and whistles I had in mind are not 
really necessary now (maybe we revisit later...).  For now, I propose to 
simply describe essential what I just said above, and provide an example 
XML based Service Definition, and a corresponding Service Request.   A 
set of several SDs can be then easily defined and verified, and all NSA 
should produce the same expected result.

I need to look thru several other comments yet regarding the SD I 
profered several days back... So I have'nt settled yet on a final form.  
I need to see what concerns and suggestions were made...  I think we are 
close though.

Regards all
Jerry

Jerry

> jeff
>
> On Apr 13, 2011, at 7:39 AM, Atsuko Takefusa wrote:
>
>> Hi all,
>>
>> I prefer John's structured schema.
>> Because it can specify optional or mandatory parameters and data types
>> of each parameter, explicitly.
>> In order for interoperability, we should define a standard schema as
>> explicitly as possible.
>> Thank you,
>>
>> Atsuko
>> G-lambda, AIST
>>
>>
>> 2011/4/12 John MacAuley<john.macauley at surfnet.nl>:
>>> Peoples,
>>> I think there is one major area we need to close on before I feel
>>> comfortable starting to write the associated document.  It is specifically
>>> around the service parameters and how they are specified:
>>>    <!-- Parameters relating to the requested service. -->
>>>     <xsd:complexType name="ServiceParametersType">
>>>        <xsd:sequence>
>>>           <!-- Time parameters relating to the reservation. -->
>>>           <xsd:element name="schedule" type="tns:ScheduleType"/>
>>>           <xsd:element name="bandwidth" type="tns:BandwidthType"/>
>>>           <xsd:element name="directionality" type="tns:DirectionalityType"/>
>>>           <xsd:element name="pathObject" type="tns:PathObjectType"/>
>>>           <xsd:element name="guaranteed" type="tns:AttributeSequenceType"
>>> minOccurs="0"/>
>>>           <xsd:element name="preferred" type="tns:AttributeSequenceType"
>>> minOccurs="0"/>
>>>        </xsd:sequence>
>>>     </xsd:complexType>
>>> The main question I have is do we change this structure to be completely
>>> generic and list all service parameters through type/value pairs, or do we
>>> break out hose key ones as I have here and put the remaining in the
>>> type/value pairs?
>>> Also, for bandwidth do we document the values as Mb/s or do I add an element
>>> to explicitly identify the unit as suggested in one provided comment.
>>> Thank you,
>>> John.
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>
>>>
>>
>>
>> -- 
>> Atsuko Takefusa
>> Information Technology Research Institute, AIST
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg