[Nsi-wg] UvA/TUD topology exchange proposal

[Henrik Thostrup Jensen]

Hi

Okay, deep breath.

On Tue, 19 Aug 2014, Ralph Koning wrote:

> Attached to this mail is the document describing this topology exchange,
> and a small discussion on how we can apply it to the NSI work. Feel free
> to comment and ask questions.

Section 1:

* 1 optimal path finding on the provided topologies

Could you please define optimal.

(the finer point here is that network is shared infrastructure, which 
makes this a very complicated thing to do).


Section 2:

After finishing the document, I realized I had read it wrong. I thought 
section 2 and 3 where discussions about topology (or as it is commonly 
called "routing") models, but I realized later that this is just an 
alternative way of distributing NML. However you don't actually mention 
NML until section 9 (yay, a detective story), which makes the document 
incredibly difficult to read.

Anyway, what I had hoped to find in section 2 was something like 
link-state vs. distance vectoring, information push vs. pull, discussion 
of transit, peerings, and customer connectivity and link/transit AUPs. 
Further the control and data plane symmetry (or lack of it) would be good 
to have.

It would also have been nice to see some discussion of what is considered 
the only two successfull inter-networking protocols: BGP and SS7. 
Especially why they are successfull.


Section 2.1:

The more time I have spend with NSI topology, the more convinced I am that 
it is just routing, and that most of time stuff we are doing is actually 
30-40 years old.

Anyway, could you please list the number of successfull centralized 
routing protocols? Have you considered why there are none? It is not just 
because networks don't want to rely on a single service, but also because 
you cannot cram the policies of a network into a single service (there are 
technical, economical, political and legal reasons for this)


>> The topology database can also have a dedicated path finder,

No. It really cannot. We will never succeed in cramming in the policies 
and state of networks into a single point of decision. You cannot tell 
NORDUnet how to deliver data into on of their customer networks. This is 
an agreement between NORDUnet and the customer. Similarly, NORDUnet cannot 
tell their customers how to get the data to the university / research 
institution. You only get to hand over the data to NORDUnet at place.

The sooner we kill of the notion of centralized path finders, the sooner 
we can start making something that can actually be used.


Section 2.2:

>> Hence, frequent topology exchanges could be expected between domain 
>> controllers for path finding purposes.

Why?


Section 2.3:

>> However, full disclosure of internal do- main information may pose a 
>> threat to the domain due to possibilities of attack, sabo- tage, or 
>> competitive intelligence between do- mains.

This is rather speculative. Sure commercial networks are like, but most 
NRENs list their topology openly.

>> The advantage of providing a minimized internal do- main view is that 
>> less information needs to be processed during path finding, and for 
>> safety concerns. However, insufficient topology information may lead to 
>> suboptimal path or even failure to compute paths.

Do you know how much information is exchanged via BGP?

Optimal is still not defined.


Section 2.4

If you mean the GNS approach, say the GNS approach.

>> This discloses even less topology information.

Because more is better? (scandinavian culture does not assert this btw.)

>> The routing is done locally, per domain, based on the information of 
>> itself and its direct neighbours leading to a locally optimal route

Like BGP? :-) (ok, BGP has AS paths, but it is also common to override 
MEDs, so we end up with the same thing).

>> It is not possible to provide a different view to the requester domain

WHAT!? Split horizon and reverse poisoning are 40 year old techniques, was 
used in RIP, and covered in all textbooks on routing.

>> malicious domains can easily provide false reachability information and 
>> break global path finding.

BGP has the same problem. It also has a solution.


Section 3:

>> Since we believe sharing topology information provides more flexibility 
>> over sharing reachability information, we propose a hybrid approach to 
>> exchange topologies:

When you dismiss something due flaws also found in BGP it is something 
difficult to take it serious. Also the two models do no exclude eath other 
(BGP does MEDs for IPs, but still do AS-Paths for adjecency).

I fail to see how the TI is more useful than a list of URLs. Sorry. The 
notion of foreign domains is slighly interesting though.

The trust model is not listed in the section, but it looks like 
all-to-all.

Again, I don't want to depend on your central service.

The neighbour list isn't entirely clear on the data vs control plane 
peering issue.


Section 7.6.

Again. You cannot do path computation centrally. Won't fly. Sorry.


Section 8:

How to deal with:

Complex transit policies

AUP for links. E.g., some project have private links (they have a lot of 
traffic). These might be listed, but you can only use them if you have 
certain credentials. Some links have AUPs that are under NDAs.


Section 9:

NML isn't mentioned before this section, but the entire document is based 
on the NML model.

Section 9.1:

>> Key distribution is problematic, since many developments within NSI did 
>> not focus too much on the security aspects giving no facil- ity to 
>> distribute information with end-to-end security.

And forcing all-to-all trust is much better?

--

Sorry for being an ass about this. But I am tired of seeing technology 
first solutions (and NML and its derivatives is certainly so).

Policies are much more important for finding paths than technology. BGP 
and SS7 is successfull because they allow policies to be expressed. For 
BGP, announcing different reachability to different networks, and with 
different priorities for where to deliver traffic, and the ability to 
override the latter locally. SS7 is more complicated (because telco), but 
interestingly enough it is circuit based.

The basic model needs to allow networks to figure out they want to 
connect. Having user or centrally driven path finding is a pipe dream.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet