[Nsi-wg] Service decoupling proposal

[Henrik Thostrup Jensen]

Hi

On Fri, 28 Jun 2013, John MacAuley wrote:

> Please find attached the service decoupling proposal discussed a couple 
> weeks ago via e-mail.  The document describes the current XSD structure 
> and associated issues, as well as the proposed minor changes to fix the 
> problem.  I have also included the modified schema files and an example 
> of a new reserve message.  Behaviours remain the same.

First. Are you aiming for NSI2 with this or a future revision? I think 
this is almost the most important thing in the discussion about this.


So there are actually multiple proposals in here:

1. The use of Any element in serviceAttributs.

This doesn't really change anything fundenmental in the protocol. I don't 
really see any problems with it, except that we already have the 
NSI2 document in for editor review.


2. A generic path element, for allowing all sorts of path setsup, e.g., 
point-to-point, multi-point, whatever.

At a workshop (I think it was Charlottesville) someone (could have been 
Takahiro), suggested an alternative way of constructing multi-setup, where 
aggregation points (with some configurable behaviour I assume). This 
aggregation point would then have a number of STPs, which would reside in 
the network, and could be connected to the STPs demarcating other networks 
- via the CS protocol. This approach with virtuals STPs (whatever that 
means) also has some validity, and I think the construction of STPs on the 
fly has some validity to it. For instance, one could construct an MPLS 
tunnel and have the ends be new STPs, which one could use to build other 
circuits (in fact, LHCONE wants to something similar to this AFAIK).

Anyway, what approach we want to take towards building multi-point 
circuits needs be discussed better IMHO.

Notes:

p2p is used to abbreviate peer-to-peer practically everywhere. Another 
name would be good.

symmetricPath relates to the path taken, i.e., if the data is allowed be 
transported via different routes. It is perfectly useable and valid in its 
current form, and it not related to bandwidth. I cannot guarantie such a 
thing on the NORDUnet infrastructure, but some networks probably can.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet