Hi Gigi-restr

I believe a GOLE has two properties that are interesting, but which I do not believe distinguish it architecturally from a conventional network or domain:
1) It has an "open" policy.
2) it encourages the interconnection of GOLEs in order to allow "express" paths across geographic space to other domains

Allow me to elaborate...

As for the "open" policy of a GOLE, the fact that the sponsors of the GOLE associate a null policy administrative policy to a switch does not  architecturally change the "network" model it conforms to.    Even if you express the open nature of a GOLE by attaching no particular policy to the resource, this only means the PathFnder has less work to do - it does not (IMO) change the technical architecture of the domain containing the GOLE as a switching point that must still be coordinated via a control plane of some sort.   It does not change the pathfinding process - it just reduces some of the constraints.   If the GOLE - or a interconnected group of GOLEs - exhibit some "better" path characteristic than conventional networks, it will be expressed in the topology advertised and will result in GOLE based paths emerging from the PathFinding process.   But this would be true for *any* network.

If we relate this to our NSI model, a GOLE is represented no differnetly than any other "network" - it has a set of STPs and offers some transfer function as defined by its advertised topology.     A local NSA would still be required to be associated with the GOLE and it would still require an NRM to actually interact with the switching device.   

So, and this is a Good Thing, a GOLE is no differnet from other networks except by merit of the fact that the internal authorization policy is highly permissive.   The corrolary is that any network that had a similar open policy would constitute a GOLE.  Right?  

WRT the second point above, I think one of the practical advantages of our notion of a GOLE is to create an open (policywise) "express lane" across the global geographic reach of the R&E infrastrucutre.  I.e. by transitting GOLEs - or open exchange points - with big pipes interconencting these exchange point domains, we are able to bypass a significant amount of intervening networks, switching hardware, restrictive (and often antiquated) policy, and complexity.   THis too is a Good Thing.   But again, from a PathFinder's point of view doing a constraint based search of available paths, this express lane will (should) only emerge by walking the topology and pruning more expensive paths.  If a GOLE based path is emergent as the "best" available path, it will be used.   If you wish to force a request to use a GOLE, you can do so by specifying a GOLE transit STP within the request, but then one would question the value of the GOLE if -after looking at all paths - the PathFinder must be forced to use it - i.e. why does PathFinding prefer another path?   IMO, a GOLE (or any exchange point path) should exhibit sufficient advantage via the path computation to justify its selection as the prefered path.   And so, it exhibits no special architectural characteristics from other network domains.

So, while I support the notion of AUP free exchange points and Big Pipes in bewteen as a Best Common Practice, I do not see any compelling reason to consider GOLEs as somehow unique within the more general inter-domain service architecture.

Hope this made some sense:-)
Jerry


Victor Reijs wrote: 
Hello Gigi,

Gigi Karmous-Edwards wrote:
  
True, it is a domain. However, if a GOLE has the property of being "open 
policy"  and its main service is to interconnect paths between GOLEs and 
domains, then from a "strictly" path computation perspective, and if 
given a choice between a transient link across a domain w/ policy or 
through an open policy GOLE, then it seems that the path computation 
entity will find it simpler to  choose the  the path through the GOLE 
rather than the domain. What are your thoughts on this particular 
scenario...
    

Perhaps I have no full solution to the problem, but IMHO it would be 
great if we can define the properties of a GOLE to any Domain.
So the main question is: are 'GOLE' and 'Domain' different objects, or 
are they the same object (different instances) with different attribute 
values.
I would prefer the last one as it provide a larger flexibility (e.g. a 
'Domain' can be a 'GOLE'  in context or when time changes)

  
I can see a situation  where an end user may choose to go through a 
particular  domain  if  they are members of a domain and have certain  
privileges.
    

This is not only related to policy, might also be QoS, etc.

All the best,


Victor