Re: [GLIF tech] Why do we need topology exchange?

[John Vollbrecht <jrv@xxxxxxxxx>]

On Oct 14, 2010, at 11:35 AM, Freek Dijkstra wrote:

> In his presentation today, Jeroen expressed that while there has been
> apparent need for topology descriptions (e.g. for path finding,
> monitoring and provisioning), no real adaption has been done by GOLEs
> and NRENs.
> 
> So let me ask all of you, why do we need topology exchange?
> 
> Currently, no GOLEs really distribute topology information (even though
> the usual suspects -ESnet, Nordunet, and SURFnet- have expressed their
> intention.)
> 
> Is there no need for topology exchange after all?
Can you define what you mean by topology exchange a bit more?  Is this to describe statically configured hardware so that the infrastructure at multiple levels can be understood or is it to describe topology of controllable Links, possibly both, and possibly something different.

From the automated connection point of view it is necessary to have tolopogy that can be used to create connections.  This sort of topology is used in providing accessibility information to network users, and interconnections between networks to network providers.  This kind of topology has been available for networks such as Internet2's ION and is incorporated in the automated GOLE pilot (though the representation might be changed if a std becomes available).  I think this is necessary for the software to make connections, and so is available because it must be.

The rest of topology I am not sure about.  I would think it a good thing, but I also think it would take a lot of work and be hard to maintain.  Is this what you mean?

> 
> Right now, all GOLEs use email, pictures, wikis and a lot of smart
> people for the operation of their production network. In the last five
> years, we as GLIF comminutiy have show that we are successful in
> providing network connection accross te globe.
> 
> We even show very fancy proof of concepts like yesterday's Dynamic GOLE
> demo, but also projects like G-Lambda, and Phosporous in earlier years,
> and production application like the e-VLBI network.
> 
> However, we may blind ourselves by telling that we now have dynamic
> GOLEs. We have not. I don't want to discredit the applications, but the
> GOLEs are still manually configured. What is done is that we create an
> overlay network for each group (either a project, demo or user
> application) on top of the GLIF network. Such overlay network contains
> and links and sometimes also dedicated switches or interfaces, which may
> be dynamic. However, that does not make the underlying GLIF network dynamic.
Seems that if is switched "dynamically" is is dynamic by definition?
> 
> So who would need automated topology exchange? The GOLEs? No, since that
> is still provisioned by hand (and given that the biggest issue is
> dealing with policies and politics that come with scarce resources
> typically during demos, this may not change as long our resource remain
> scarce). So do the overlay networks need automated topology exchange? We
> surely have seen so in demos! Well, arguably they don't need it either.
> In most cases, the projects are relatively small, and so is the network
> -- typically 5 to 10 nodes only. You can easily just make a nice picture
> or hard-code it in software, no need for more dynamics.
I am confused by this - is the question about topology exchange or about description.  I would think exchange by email for static network would be a good first step if that is what is wanted.
> 
> Of course, our NREN networks are larger, and do need automated topology
> descriptions, but as Jerry pointed out, the issue there is about
> automated topology discovery, not topology description or topology exchange.
> 
> So, last option -- do we need topology exchange between the overlay
> network and the underlying GLIF network? Well, if the mapping is static,
> perhaps not. Perhaps it would be useful for monitoring to have a shared
> resource description, but that is distinct from topology exchange. (This
> has more to do with identifiers, than with topology descriptions)
> 
> I think that if we want to move this work forward, we first need to make
> clear what the problem is, before we find a solution.
I  agree - this is a good start at trying to define the problem -  thanks 

> 
> So I'm again asking you: Why do we need topology exchange?
> 
> Awaiting your answers,
> Freek
> 
>