Re: [rrg] RRG to hibernation

Patrick Frejborg <> Mon, 12 November 2012 08:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BCFF21F84BA for <>; Mon, 12 Nov 2012 00:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MZfk364S80Su for <>; Mon, 12 Nov 2012 00:26:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9C44D21F84BB for <>; Mon, 12 Nov 2012 00:26:36 -0800 (PST)
Received: by with SMTP id bi1so4331454pad.13 for <>; Mon, 12 Nov 2012 00:26:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QuCVe8VO06iZXR46jwyykT1LrNbr3pFKYe5jcaaiOYw=; b=lNOR+Y7T5fR9M1PCSvxqxyRl8TYEIs+nu6llay86kuExvNbT4PG08ySlDKZu437EIh 6BbN8HQl7WBMjawZV49/AoowWveWL2kX7ve5K/OHQUoSl17MiMsfahaWrIfrgRa/U8Cx kHQO1HT/Ax6G80SbcgRi0pomNOT2gTdz8tKbxAVjEI7Lo2XeurbkCvpxTxIfDMHtybR4 ek8eJACWRwTXqDfvEX7Yc3t9NGsI2e2rjxd1hWtVZPZI4ENyUC8HH3PwrCPBVnVZo8cf wBL9zLMCd2xJMTaS781rC2q8tvQ4f96sZo1aEI2k+mic6i24OcSHcfhaBWIg6NdK3URq QYUg==
MIME-Version: 1.0
Received: by with SMTP id no6mr49031135pbc.113.1352708796243; Mon, 12 Nov 2012 00:26:36 -0800 (PST)
Received: by with HTTP; Mon, 12 Nov 2012 00:26:36 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 12 Nov 2012 10:26:36 +0200
Message-ID: <>
From: Patrick Frejborg <>
To: Danny McPherson <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Mon, 12 Nov 2012 08:26:40 -0000

On Mon, Nov 12, 2012 at 1:45 AM, Danny McPherson <> wrote:
> On Nov 10, 2012, at 12:54 PM, Tony Li wrote:
>> I agree, but as you correctly point out, SIDR is an engineering solution.  If you dislike that particular solution, you're of course free to propose others. However, the correct forum for engineering solutions is the IETF.
> I was hoping for some research and fresh thinking related to rate+state+autonomous operations &security in inter-domain routing, hence my message here.  I don't have a solution envisaged, I just know what I'm seeing in current work is err.., going to present some challenges.
> I was hoping for "architectural alternatives, research and experimentation in secure routing architectures and algorithms being encouraged, with an aim to understand whether new directions can provide effective solutions, to work out candidate designs as necessary for a complete solution, and to fully understand both the gains and the tradeoffs that the new solutions may bring." (some of that text may sound familiar :-)
> As a side benefit, whether the routed protocol changes or not, using security as the fulcrum may well help foster broader consideration of alternative routed protocols...
> Else -- some work into scalable *static* inter-domain routing techniques and solutions might be a worthwhile endeavor *8^/
> If that's not within RRG scope then I suppose I understand how we arrived where we currently are...
> -danny

Hi Danny,

if some of the RRG proposals (LISP, ILNP, IRON, hIPV4) gets globally
implemented then the endpoint locators (EID, ELOC etc) will not show
up in the DFZ and the global routing table should be more static than
However, none of the RRG proposals have a proper solution for
inter-domain traffic engineering, thus I think your concerns are right
on spot.
It would be interesting to take the IRS approach (as an interface to
the FIB) and design from scratch an inter-domain traffic engineering
architecture, where the ISPs can create explicit paths for certain
traffic flows/bundles between domains without inserting more granular
prefixes in the RIB of DFZ. This new inter-domain architecture would
be designed as an additional control plane in parallel with the
current control plane of the existing BGP based DFZ.
Is this doable, what are the pros&cons?