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