[Nsi-wg] A slightly different take on topology

[John MacAuley]

Shall we do something else in parallel? ;-)

On 2012-01-18, at 9:13 AM, Henrik Thostrup Jensen wrote:

> Hi (sorry for being a bit close to the meeting with this mail)
> 
> I am probably not the only one who would like to have an NSI meeting that
> didn't revolve around Jeroen and Jerry debating topology description, in a not
> very productive fashion. Guy did a good effort trying to control this last
> week, but it sure is hard keeping those two under wraps :-).
> 
> So far I've tried to keep (mostly) out of it, but I'll try to give my views on
> the topology issue. The first thing we need to figure out is what we want to
> do. Are we trying to solve just the VLAN problem or coming up with a solution
> for multilayer path finding / creation and what scope of problems are we
> working with.
> 
> Solving the VLAN problem is quite easy IMHO. Multilayer is significantly more
> tricky.
> 
> I've read some of the papers Jeroen has linked to. In particular the "Path
> selection in multi-layer networks" illustrates what it is Jeroen is aiming for
> (I think). The paper is quite clever and displays a couple of nice tricks that
> can be done to solve some seemingly impossible tasks if one has (very) detailed
> information (I especially liked the graph conversions).
> 
> However it is very much a research paper, and I do not believe the approach will work - for several reasons. First is complexity, the proposed pathfinding algorithms is rather complex, but it could probably be implemented. Second reason is that I do not see it feasible to collect so detailed topology information, let alone load/availability information. Third reason is that the approach completely ignores any policies that may be in place in a network. E.g., NORDUnet has a policy for how to do VLAN rewriting (always on ingress), and we have no plans of letting other organizations decide how it should be done. Furthermore NORDUnet and SUNET (Swedish Reseach Network, which is operated by NORDUnet) shares some resources, and wether or not one is allowed to use these resource is highly dependant on who you are.
> 
> One of the really nice things about the current NSI model is that is promotes
> encapsulation. This allows us to define the network we want or need without
> regard to the underlying physical infrastructure. Going with this direction
> means will be cases where there is a potential path, but we do not have the
> means to create it for some reason or other (policy or technical). I am okay
> with this, as long as it doesn't become the norm.
> 
> On the other hand Jerry haven't really managed to give a coherent view of what
> it is he wants. I do think that Jerry has some good ideas, mostly because he
> realises the need for abstraction and encapsulation in the system, providing a
> means to actually comprehend and understand what is going on in the system (and
> hence build and debug it). Some of the ideas with recursive domains and
> hiarchial STPs are quite good, but they haven't really been fully formed yet
> IMHO.
> 
> What is clear, is that we will probably not find our final topology model at todays meeting, especially not for multilayer. However we are very much standing still and need to move forward. Could we, as a _temporary_ solution use Tomohiros STP enumeration in the reserve request in order to specify a set of potential STPs to connect with in the reservation request. This would solve our most pressing problem (VLANs) and give us some more time to work out the multilayer pathfinding/creation (which we will need). This would not require any protocol or topology changes, but an implementation change for parsing the STPs, and it is backwards compatible.
> 
> Hopefully some progress will be made in Baton Rouge (I'm not betting on it though), but we simply need to get topology out of the NSI meetings as there are also other issues we need to focus on (security comes to mind).
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> NORDUnet
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg