IETF Logo Mail Archive

Re: [rrg] RRG to hibernation

Danny McPherson <danny@tcb.net> Sun, 11 November 2012 23:45 UTC

Return-Path: <danny@tcb.net>
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 D419521F8518 for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 15:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 IpoXs9OUVm0f for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 15:45:02 -0800 (PST)
Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4219A21F8502 for <rrg@irtf.org>; Sun, 11 Nov 2012 15:45:02 -0800 (PST)
Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id BC8C320DF for <rrg@irtf.org>; Sun, 11 Nov 2012 23:45:01 +0000 (UTC)
Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 7C33E20DC; Sun, 11 Nov 2012 16:45:00 -0700 (MST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li>
Date: Sun, 11 Nov 2012 18:45:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <878C9E8D-D2B8-43CF-B338-15A341C399B0@tcb.net>
References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> <B80A8335-49BD-4B90-A024-FA82B1E8EE5F@tony.li> <C64A3635-DE95-41F6-A70C-43597EB58CBB@tcb.net> <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li>
To: Tony Li <tony.li@tony.li>
X-Mailer: Apple Mail (2.1283)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Sun Nov 11 16:45:01 2012
X-DSPAM-Confidence: 0.9898
X-DSPAM-Improbability: 1 in 9709 chance of being spam
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 50a0387d199632084684145
X-DSPAM-Factors: 27, Subject*Re+#+#+#+hibernation, 0.01000, Subject*to+hibernation, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*Re+rrg, 0.01000, Subject*Re+#+RRG, 0.01000, Subject*Re+#+#+to, 0.01000, PM+#+#+wrote, 0.01000, Subject*rrg+#+#+hibernation, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*rrg+#+to, 0.01000, Subject*RRG+to, 0.01000, Subject*RRG+#+hibernation, 0.01000, Subject*rrg+RRG, 0.01000, Nov+#+#+at, 0.01000, On+Nov, 0.01000, Nov+#+2012, 0.01000, On+#+#+#+at, 0.01000, On+#+#+2012, 0.01000, an+engineering, 0.40000, the+#+forum, 0.40000, alternative+#+protocols, 0.40000, architectures+#+#+#+encouraged, 0.40000, and+#+#+#+the, 0.40000, out+#+#+#+necessary, 0.40000, As+#+#+benefit, 0.40000, autonomous+#+#+in, 0.40000
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: Sun, 11 Nov 2012 23:45:06 -0000

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

v2.23.0 | Report a Bug | By Email