[Nsi-wg] NSI WSDL - The Maastricht Updates

[John MacAuley]

The SURFnet subnetwork protection mechanism is definitely domain specific based on the service offered to their customers.  That is why specifying a service attribute within the SURFnet namespace is the way to go as it isolates the feature to their network.  We have had this capability in the protocol since version 1.0, but I just want to clean up the XSD definition to simplify and formalize.

I am not saying we remove the bandwidth and path objects, I am just saying we move them into the serviceAttributes where they really should belong since they are service specific.  Decoupling these two attributes will give us much needed flexibility, and hopefully, reduce the need for another protocol change for something as simple as adding an asymmetric service definition.

I have no issue waiting and submitting this as a public comment to correct the current protocol deficiency.

John.

On 2013-06-20, at 9:45 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> On Wed, 19 Jun 2013, John MacAuley wrote:
> 
>> Notice the service attributes provided.  This is an example of the two ways we can specify the same
>> thing, and in this case, it is the SURFnet subnetwork protection attribute.  I would like to flatten
>> the serviceAttributes structure to a simple ANY to give us the following:
>>         <serviceAttributes>
>>          
>>   <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP>
>>         </serviceAttributes>
> 
> I like this construction.
> 
>> Now onto the key point I was trying to get across.  Bandwidth and path are specific to a symmetric
>> point-to-point service.  I would like to make a simple change to move bandwidth and path into
>> serviceAttributes with their own specific p2pservice namespace.  This will let us have a more generic
>> reserve message.  Here is an example:
> [snip]
>> This will allow us to use the existing XSD for new service definitions without needing to modify the
>> schema.  New attributes can be imported for other namespaces when defined.  It really is a simple
>> change and it should provide good value.
> 
> This certainly makes the CS protocol way more flexible in specifying circuits, and to some extent I like it. The problem is timing as we are close to sending the document to the editors, and complete lack of discussion in the group about the base of this.
> 
> Previously we have discussed the option of having aggregation points, where to point-to-point connections could be connected (the underlying NRM can choose whatever to make this happen), but this takes a completely other approach (though non fundementally incompatible).
> 
> There is also the whole multi-domain aspect to consider. How we do multicast and protected paths across those in a proper way. Anything single-domain with NSI is point-less IMHO.
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> Software Developer, NORDUnet_______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg