I strongly suggest that we limit any addition changes now in V2 to only those that correct something that is broken or that clearly does not work as is.     

We could continue to tweek stuff forever and many of these changes should be considered more thoroughly by the group.  There *will* be additional considereations we are going to have to address in v3 (things like protection are a good example of issues that were not discussed in our v2 requirements and need a broader discussion anyway.)   Besides, stuffing something in now will not necessarilly prevent it from being reviewed and possibly changed again in V3 anyway.    Lets try to stop these elective "improvements" and get v2 out the door.

J


We will have a chance to
On 6/20/13 9:45 AM, Henrik Thostrup Jensen 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@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg