-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Ruichuan, I am really happy that we can see new concepts that address the iBGP anomaly problem. A few years ago, we also worked at that problem. In that context, we could already develop and publish a concept that inherently solves the iBGP anomaly problem. A paper presenting the concept was published at the LCN 2009 [1]. Focussing the demands of ISPs, we developed the so called "iBGP Route Server Architecture". For the architecture, we *formally* proved that the concept inherently avoids suboptimal routing decisions, inconsistent routing decisions, and robustness problems (oscillation, non-determinism). In the following document, you find all details on the concept: https://net.cs.uni-bonn.de/fileadmin/user_upload/ub/slides/bornhauser-phd-20... Against the background of that experience, let me give you some feedback on your approach: (1) As far as I understood your abstract and the paper itself, your approach realizes an information exchange that is comparable to full-mesh iBGP (even if the information exchange is slightly different). In principle, this leads to correctness properties comparable to full-mesh iBGP. However, the conclusion that this means that your concept implements an anomaly-free iBGP is not correct. To be precise, it means: - - I agree that your concepts avoids robustness problems (especially oscillation). - - Your concept still allows consistency problems. - - I disagree to your assertion that path inefficiencies are avoided in arbitrary configurations. You find all the details and exemplary configurations on that in [2]. The point here is that even if iBGP is clearly more robust than RR or AS confederations due to the lower degree of information reduction, operationally unwanted behavior (anomalies) may still appear. (2) To really guarantee an anomaly-free iBGP, your concept can be developed in two different ways: Either the decision process has to be modified (unwanted in general) or also clients (to be precise speakers that keep eBGP sessions) have to provide more information to your central component(s) than common iBGP specifies. You find the details in the document I linked above. (3) Even if dividing the amount of information processed by a central routing device by address space (and not by topological closeness) is a helpful concept to avoid scalability problems, this should not be necessary in most cases. You also find a detailed scalability analysis for a large AS and the generalizing conclusions substantiating my opinion in the document I linked above, too. (4) Assuming that putting no constraints on RR placements may also mean that your abandon RRs at all (what you also propose in my understanding by replacing TBRRs by ABRRs), your concept is not the first solution ;-). Generally, if you modify your concepts to address these issues, you will probably come to an architecture that is a mixture between the iBGP Route Server Architecture and Iuniana's oBGP concept. Thoughts that may help to improve your concept may be found in [4]. I would be really happy if we discuss some further details on your concept. Best Regards Uli [1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5355200 [2] http://net.cs.uni-bonn.de/fileadmin/user_upload/ub/papers/UB-KIVS-2011.pdf [3] http://iuniana.ro/publications/networking_11.pdf [4] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5735762 Am 13.01.2012 um 19:48 schrieb Ruichuan Chen:
Dear all,
The document below may be of interest:
"Address-based Route Reflection" at http://bgp.mpi-sws.org/papers/abrr-CoNEXT11.pdf
by Ruichuan Chen (MPI-SWS), Aman Shaikh (AT&T Labs Research), Jia Wang (AT&T Labs Research), Paul Francis (MPI-SWS)
==== Abstract ====
This work presents Address-Based Route Reflection (ABRR): the first iBGP solution that completely solves all oscillation and looping problems, has no path inefficiencies, and puts no constraints on RR placement. ABRR does this by emulating the semantics of full-mesh iBGP, and thereby adopting the correctness and path efficiency properties of full-mesh iBGP. Both traditional Topology-Based Route Reflection (TBRR) and ABRR take a divide-and-conquer approach. While TBRR scales by making each RR responsible for all prefixes from some fraction of routers, ABRR scales by making each RR responsible for some fraction of prefixes from all routers.
Best regards, --Ruichuan _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- -- https://net.cs.uni-bonn.de/ub -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iF4EAREIAAYFAk8cT6kACgkQHjTkVxyUO5wRpQEAsB3x1kyG5L5hlQX4dXvHNCaW vqkR677GE0ZfzHOQ1gwBAIpeY6/OBZTYLbuc4pChHXycYsje6js1aKLPeEmjFIJC =5bYk -----END PGP SIGNATURE-----