Re: [rrg] RRG to hibernation

Dae Young KIM <dykim@cnu.kr> Tue, 13 November 2012 02:11 UTC

Return-Path: <dykim6@gmail.com>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9515221F87CF for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 18:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ6usRgEEUwX for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 18:11:54 -0800 (PST)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61121F8753 for <rrg@irtf.org>; Mon, 12 Nov 2012 18:11:54 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id k19so3576601qcs.13 for <rrg@irtf.org>; Mon, 12 Nov 2012 18:11:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=opn8uyRAvNbr99TDEImR/guXIt0dADcH6fmbL+XggJM=; b=VGRY6rKyEIEB/AAtchoQZ0IIElWTUrDRyxqo+A4zeMw+PHho8xhvHfYC4UslBq0Z6A bX4w2s0SbEOkkAb7AkGahHGCWVmwFDbQ5vH39+23NQW4/0NmnaHc0CpfBuKK6BZlI86v YEKd7Szog2IRCr7oyn61g2WIeIZirNooky3z7XAP9arig3eC0tPpDLLqgr9bTk9bl+Cl kL/1yHeCCCgBdkYlznKYb/NCJ/pvuhyhyTJh3H/ipQHx6RwCMbAIXrc6dGcRwHvfqZla fHftg99SGoiWBcL6174fPvqrgttz7eQGBMrkitKB5I1llSrI/VkA2HZO8DEiyE9dOJz8 4pBw==
Received: by 10.229.196.195 with SMTP id eh3mr5396671qcb.82.1352772713965; Mon, 12 Nov 2012 18:11:53 -0800 (PST)
MIME-Version: 1.0
Sender: dykim6@gmail.com
Received: by 10.49.12.9 with HTTP; Mon, 12 Nov 2012 18:11:33 -0800 (PST)
In-Reply-To: <61783025-83F3-4D21-96DC-EB12AC899E05@castlepoint.net>
References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <CAFgODJcP1zvwRJukJdnqjSR-78XAMB1nSxL32gjUQB+NqpgESg@mail.gmail.com> <50A18F75.8060001@joelhalpern.com> <CAFgODJcDAzaYPrWFEJhgeCjnN_M9tdd+pdHTiccd=Dz=1mYrLg@mail.gmail.com> <61783025-83F3-4D21-96DC-EB12AC899E05@castlepoint.net>
From: Dae Young KIM <dykim@cnu.kr>
Date: Tue, 13 Nov 2012 11:11:33 +0900
X-Google-Sender-Auth: BVDOOZtUIctSW7gS20Ess4md0CQ
Message-ID: <CAFgODJca-oVm-E4R6B+BfT=zNjSzWu-KP8mx1FUPyLJqD8AYQw@mail.gmail.com>
To: Shane Amante <shane@castlepoint.net>
Content-Type: multipart/alternative; boundary=0016e6d2660813ea0d04ce56f1c7
Cc: rrg@irtf.org
Subject: Re: [rrg] RRG to hibernation
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2012 02:11:55 -0000

On Tue, Nov 13, 2012 at 10:54 AM, Shane Amante <shane@castlepoint.net>wrote;wrote:

> 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 :-).
>

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