Re: [rrg] RRG to hibernation
jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 12 November 2012 01:55 UTC
Return-Path: <jnc@mercury.lcs.mit.edu>
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 9AA0221F84DF for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 17:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.483
X-Spam-Level:
X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 B6lnBeKlV6-n for <rrg@ietfa.amsl.com>; Sun, 11 Nov 2012 17:55:56 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 018E521F84D8 for <rrg@irtf.org>; Sun, 11 Nov 2012 17:55:55 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DC3BA18C0C7; Sun, 11 Nov 2012 20:55:52 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20121112015552.DC3BA18C0C7@mercury.lcs.mit.edu>
Date: Sun, 11 Nov 2012 20:55:52 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
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: Mon, 12 Nov 2012 01:55:56 -0000
> From: William Herrin <bill@herrin.us> > I have a notion for a "routing" protocol I'm glad you put the 'routing' in quotations, because to me, 'routing' is i) the _selection of paths_, and ii) the distribution of the information needed to select paths. I'm not sure what definition other people are using, but it might be useful to come up with a standard one to prevent confusion. > which manages link changes through dynamic re-addressing and multiply > addressing hosts. By and large the addresses change so that the > trivially aggregable routes don't have to. Not just at the host level > but all the way downstream from the link change. If I understand you properly, this is a way of dealing with topology changes by re-numbering things? (To use the definition of 'routing' above, you wouldn't need to propogate new information, because the old data would still be valid - it's just that the things the old information would apply to have changed?) I need to go away and think about this for a while before I can have some really solid reaction, but off the top of my head I wonder if the work involved in keeping up with the changing addresses isn't as much (or possibly more) work than the usual approach. TANSTAAFL, after all... > Even bumps automatic resizing requirements upstream so that over time > any given router offers exactly one route outward which automatically > aggregates with the route its upstream already holds. Err, routing (in the sense given at the top) is trivial when there's only one path ("its upstream"). It's finding/selecting paths in arbitrary graphs with lots of alternate paths (i.e. ones with lots of 'cycles', to use the graph-theory term) which is the hard case. > It does require a new suite of transport protocols > ... > the odds of ever reaching deployment on an approach which requires us > to abandon TCP and UDP are not good? That's infeasible; you can't require changing all hosts. You need to see if you can come up with some approach that avoids that. (E.g. if we have location-identity separatation deployed, you could hide the new locators from the hosts.) > Are you game to flesh it out and see how far we can run with it Right at the moment, I personally don't have any spare time/energy. But you should think about it (and try and write something); even if it's not usable directly, there might be some aspects that could be useful to other designs. Noel
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation Scott Brim
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation William Herrin
- Re: [rrg] RRG to hibernation Danny McPherson
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Danny McPherson
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Shane Amante
- Re: [rrg] RRG to hibernation Eliot Lear
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation heinerhummel
- Re: [rrg] RRG to hibernation Danny McPherson
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation Christian Huitema
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation Joel M. Halpern
- Re: [rrg] RRG to hibernation Patrick Frejborg
- Re: [rrg] RRG to hibernation heinerhummel
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Mark Townsley
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Noel Chiappa
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Joel M. Halpern
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Jakob Heitz
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Shane Amante
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Christian Huitema
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Patrick Frejborg
- Re: [rrg] RRG to hibernation Scott Brim
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Fleischman, Eric
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Joel M. Halpern
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation George, Wes
- Re: [rrg] RRG to hibernation William Herrin
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation heinerhummel
- [rrg] RRG to hibernation (resent) heinerhummel
- Re: [rrg] RRG to hibernation William Herrin
- Re: [rrg] RRG to hibernation heinerhummel
- Re: [rrg] RRG to hibernation Scott Brim
- Re: [rrg] RRG to hibernation Scott Brim
- Re: [rrg] RRG to hibernation Dae Young KIM
- Re: [rrg] RRG to hibernation Christian Huitema
- Re: [rrg] RRG to hibernation Tony Li
- Re: [rrg] RRG to hibernation Eliot Lear
- [rrg] Where IRON fits in Templin, Fred L
- Re: [rrg] Where IRON fits in heinerhummel
- Re: [rrg] RRG to hibernation Christian Huitema
- Re: [rrg] RRG to hibernation Scott Brim
- Re: [rrg] RRG to hibernation Scott Brim