Service decoupling proposal
All, 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. John
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
participants (2)
-
Henrik Thostrup Jensen
-
John MacAuley