Re: [rrg] RRG to hibernation

[Dae Young KIM <[e-mail]>]

On Tue, Nov 13, 2012 at 10:54 AM, Shane Amante <[e-mail]>wrote:

> Dae,
>
> On Nov 12, 2012, at 5:12 PM, Dae Young KIM <[e-mail]> 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 :-).
>

Good to know there are other ways to combat the problem.

>
> 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
>

Agreed.

Then why did we indulge in LIS? Was it a consensus that LIS is the way to
solve the 'other problems' that you mention above?

I was trying to echo Noel's comment like 'what routing problems has INLP
solved?'

If the 'other problems' you mention were our major problem space, weren't
there any other approaches than LIS? Any other more generic approach?

If I'm not wrong, LIS was introduced to this community through the
following arguments, out of the 2006 workshop:

 o Symptom: The DFZ routing table is exploding.
 o Primary Diagnosis: Incompetence in multihoming is the cause.
 o Secondary Diagnosis: Semantic overloading of IP address is responsible
for multihoming incompetence.
 o Prescription: Apply LIS.

So, if not for the problem of routing table explosion, why have we indulged
in LIS?

(As long as migration and mobility are degenerate cases of multihoming, the
same arguments and the question apply to them, too.)

Was LIS conceived fat beyond that quality from the beginning? An all-mighty
to solve all routing problems? Then, what routing problems has it solved?

-- 
DY