Ran, Fred, sorry for taking so long time to come back to this topic, day work "interference" and I needed to update my I-D to make it clearer on this topic ...
Comments in-line On Wed, Jun 9, 2010 at 4:09 PM, RJ Atkinson <[email protected]> wrote: > > On 08 Jun 2010, at 14:38 , Patrick Frejborg wrote: >> The outcome is that there are a bunch of exit points, >> there could be easily four to ten peering points >> and the internal routing becomes complex. > > Interior routing doesn't have to be so complex, > even with that many exterior peering points. > > I certainly know of sites that have been handling > that range of exterior peers for more than 20 years, > without having unusual complexity within their > interior routing. > > There must be some other reasons that the site you > describe has chosen to have complex interior routing. Yes, these scenarios are usually due to mergers or acquisitions - then the networks are loosely integrated just for some common applications. Also since the countries are quite small over here, a patriotic factor arrives - moving functionality to some other place and it is overtaken by "foreigners". Now not every network is like a describe but I see some challenging solutions from time to time. > >> So if you could have concurrent multiple paths >> from the hosts towards the customers via specific exits ... > > > The issue of concurrent multiple paths to exist > an end site is not new. > > Using ILNP does not make that issue any worse than today. > So this really is not an ILNP-unique issue. Instead, > it is a separate issue, which is why I've moved this > discussion into its own thread. Hmm.. if you could improve current situation you might have a business case to start a migration, wouldn't you? > > The "Border Router Discovery Protocol" that Teco Boot > is already working to standardise within the IETF is > an interesting technology that appears able to help > with these issues (for existing deployed IP networks, > and for ILNP). Whilst BRDP's origins are in the MANET world, > its applicability/utility seem to be very much broader -- > including totally fixed non-mobile/non-MANET environments. > BRDP enables the interior of a site to have better information > about the currently available set of upstream links/ > site border routers. > I had a look on that, if I understood that right you need two NICs on the host to be able to use both border routers? It also seems that VET do not integrate multipath transport protocols in the architecture? Instead of rewriting locator values on the border router you take the edge and core address spaces out to the hosts, add multipath transport protocol - then you get an interesting solution, multi-homing becomes multi-pathing with only one NIC at the host. I have tried to explain that in appendix B, see http://tools.ietf.org/html/draft-frejborg-hipv4-07#appendix-B With this approach it will bring some use cases that might be interesting for the CIO of an enterprise - it should bring down costs and at the same time improve availability and performance, also make mergers easier to handle - maybe enough incentives for the CIO? http://tools.ietf.org/html/draft-frejborg-hipv4-07#section-7 -- patte To make it easier to understand, ALOC=core locator space that is installed in DFZ, similar as RLOC space in LISP. ELOC= edge locator space, similar as EID in LISP. _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
