HI Victor, My feeling is that the Stitching Framework (SF) developed in GN2 JRA3 is part of a pathfinding function. (I think of it as a kind of Traffic Engineering extension to pathfinding). In theory G.800 (if it is a fully generic schema for describing networks) should support any type of pathfinding and also the SF. I think it is out of the scope of NSI to nominate the pathfinding method used by the Network Service Agents. Guy -----Original Message----- From: Victor Reijs (work) [mailto:victor.reijs@heanet.ie] Sent: 10 August 2009 10:35 To: Guy Roberts Cc: 'NSI WG' Subject: Re: [Nsi-wg] Today's NSI-WG conf call minutes Hello all of you, I think this is a good standard to look into, indeed. As I and others are looking at the Stitching Framework, it will be interesting to see how this standard maps the SF. Luckily the ideas are quite similar (it is a unified approach and there is a close 1 to 1 mapping of some the relevant definitions, but there will be some difference of course and we need see how to map these). It would be nice to know if we indeed want to go this way of G.80x in NSI. Ideas? By the way the Stitching Framework is in G.800 speak: about finding out what LI (Layer Information) makes sure that the Layer processor function can function at an interdomain level ('interdomain' is not defined in G.800 I think, so it is perhaps a specific abstracted 'layer relationship'). All the best, Victor Guy Roberts wrote:

Hello All,

The minutes from today's conf call are now available on gridforge:

http://forge.gridforum.org/sf/go/doc15739?nav=1

Guy

------------------------------------------------------------------------------------------------------------------

Guy Roberts, Ph.D

Network Engineering & Planning

DANTE - www.dante.net <http://www.dante.net/>

Tel: +44 (0)1223 371 316

City House, 126-130 Hills Road

Cambridge, CB2 1PQ, UK

------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

-- The HEAnet National Networking Conference 2009 - 12&13 November Registration is now open: http://www.heanet.ie/conferences/2009/ Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/

Victor Reijs wrote to the NSI list:

I think [G.800] is a good standard to look into, indeed. As I and others are looking at the Stitching Framework, it will be interesting to see how this standard maps the SF [Stitching Framework]. Luckily the ideas are quite similar (it is a unified approach and there is a close 1 to 1 mapping of some the relevant definitions, but there will be some difference of course and we need see how to map these). [...] By the way the Stitching Framework is in G.800 speak: about finding out what LI (Layer Information) makes sure that the Layer processor function can function at an interdomain level ('interdomain' is not defined in G.800 I think, so it is perhaps a specific abstracted 'layer relationship').

Victor, When looking at explicit multi-layer network descriptions, I have the impression that most approaches start with G.800 as the base model (or a very similar model) and then extend it in one of these two ways: - Extend the base model by adding addition properties to the model to cope with technology constraints. This is the approach taken by NDL, and Stitching Framework. - Extend the base model by making subclasses for each technology (WDM, TDM, Ethernet, IP). This is the approach taken by cNIS, GMPLS, and UNIS. The advantage of the first approach is that is is truly technology independent, which makes it very suitable for inter-domain path finding (as the algorithm does not need addition for technology specific, which is a problem if new technologies are introduced). The disadvantage of the first approach is that it is hard to model characteristics which are only suitable for a single technology. (Think about signal degradation, memory buffers, packet size, which are hard to model in a technology independent enough that it applies equally well to -let's say- wireless, TDM and Ethernet.) The advantage of the second approach is that these technology quirks can be modeled in a better way using technology-specific extensions. This makes this approach very suitable for monitoring or intra-domain path finding. The decision which approach to use will be on the agenda in the upcoming time for NML. I personally hope that it is possible to create some hybrid form, which takes the best of both approaches by describing all extensions, no matter how hard, in a generic way. I guess the stitching framework is a set in that direction, but personally I am not convinced that this really works for ALL extensions. I would be thrilled to be proven otherwise. Regards, Freek