Re: [rrg] RRG to hibernation

Shane Amante <> Tue, 13 November 2012 01:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E207E21F8804 for <>; Mon, 12 Nov 2012 17:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.436
X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r+QJG7bUTeYh for <>; Mon, 12 Nov 2012 17:54:25 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 2D27121F86EB for <>; Mon, 12 Nov 2012 17:54:25 -0800 (PST)
Received: from dspam (unknown []) by (Postfix) with SMTP id 1B76A20DD for <>; Tue, 13 Nov 2012 01:54:24 +0000 (UTC)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9B2BD20C7; Mon, 12 Nov 2012 18:54:18 -0700 (MST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D401B5DB-DD81-445A-8E99-E63B6FA6B03D"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Shane Amante <>
In-Reply-To: <>
Date: Mon, 12 Nov 2012 18:54:16 -0700
Message-Id: <>
References: <> <> <> <>
To: Dae Young KIM <>
X-Mailer: Apple Mail (2.1499)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Mon Nov 12 18:54:24 2012
X-DSPAM-Confidence: 0.9899
X-DSPAM-Improbability: 1 in 9809 chance of being spam
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 50a1a850199637872915013
X-DSPAM-Factors: 27, Subject*Re+#+#+#+hibernation, 0.01000, Subject*to+hibernation, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000, Subject*Re+rrg, 0.01000, Subject*Re+#+RRG, 0.01000, Subject*Re+#+#+to, 0.01000, Subject*rrg+#+#+hibernation, 0.01000, 2012+#+#+#+PM, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*rrg+#+to, 0.01000, Cc*, 0.01000, Subject*RRG+to, 0.01000, Subject*RRG+#+hibernation, 0.01000, Subject*rrg+RRG, 0.01000, Nov+#+#+at, 0.01000, Nov+#+#+at, 0.01000, On+Nov, 0.01000, On+Nov, 0.01000, the+#+and, 0.01000, the+#+and, 0.01000, Nov+#+2012, 0.01000, Nov+#+2012, 0.01000, On+#+#+#+at, 0.01000, On+#+#+#+at, 0.01000
Subject: Re: [rrg] RRG to hibernation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Nov 2012 01:54:26 -0000


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


> On Tue, Nov 13, 2012 at 9:08 AM, Joel M. Halpern <> 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