Dae, On Nov 12, 2012, at 5:12 PM, Dae Young KIM <[email protected]> wrote: > Hi, Joel, > > Perhaps a more direct question might serve here: > > o How has ILNP solved the problem of the DFZ routing table explosion?
First, let me remind you that there *are* FIB aggregation techniques that may work to squelch some of the most egregious deaggregation that occurs out there. IMHO, the following are the most promising, but there are others: http://tools.ietf.org/html/draft-uzmi-smalta-01 More work needs to be done, specifically trials in _production_networks_ to qualify how good (or, bad) it really works. I've asked several vendors to develop a prototype implementation of the above to test in my network, but have yet to see any takers, unfortunately. (Someone please prove me wrong :-). Also, more importantly, let me add that "DFZ routing table explosion" is not the only concern that operators solely care about. Yes, it's an important factor, but it's not the _sole_ factor. As I alluded to in a previous e-mail just recently to this list, there are additional things to care about: - inter-domain routing protocol robustness, i.e.: one malformed UPDATE will not cause BGP session to reset - ensuring "routing security" is a first-class design principle - allowing for _additional_ routing metrics to be learned *and* used in terms of path selection. Note, this is likely not a panacea, but most likely (in the end) *may* provide "hints" to end-hosts as to "path quality" so that they don't waste time hunting/exploring bad paths. - and, yes, scalability of the RIB/FIB So, let's not solely focus on one aspect of the problem-space, to the detriment of other useful areas that need to get solved. -shane > > On Tue, Nov 13, 2012 at 9:08 AM, Joel M. Halpern <[email protected]> wrote: > I do not see the difficulty. We already have the IPv6 mechanisms to > advertise the prefixes. And we have the IPv6 mechanisms for hosts to combne > the prefixes with teir IDs. > We also have the dynamic DNS mechanisms (with security) needed to advertise > the results. > > With ILP, these combinations can be changed during sessions, and traffic can > change paths during sessions without impact. > With the current architecture, sessions can not change paths, and changes to > the connectivity are hard to discover or utilize. > > Thee are other multi-homing problems that are not solved. Working out how to > manage prefix assignments in an enterprise when external assignments change > is one example of such issues (LISP takes a different tack, and thus the > costs and benefits are different.) > > Yours, > Joel > > -- > DY > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
