[Nsi-wg] Topology virtualisation

[Jerry Sobieski]

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
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100624/180f68b8/attachment-0001.html