Re: [rrg] RRG to hibernation

Dae,

On Nov 12, 2012, at 5:12 PM, Dae Young KIM <dykim@cnu.kr> 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 <jmh@joelhalpern.com> 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
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg