Re: [rrg] RRG to hibernation (Noel Chiappa) Mon, 12 November 2012 01:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AA0221F84DF for <>; Sun, 11 Nov 2012 17:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.483
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B6lnBeKlV6-n for <>; Sun, 11 Nov 2012 17:55:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 018E521F84D8 for <>; Sun, 11 Nov 2012 17:55:55 -0800 (PST)
Received: by (Postfix, from userid 11178) id DC3BA18C0C7; Sun, 11 Nov 2012 20:55:52 -0500 (EST)
Message-Id: <>
Date: Sun, 11 Nov 2012 20:55:52 -0500 (EST)
From: (Noel Chiappa)
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 01:55:56 -0000

    > From: William Herrin <>

    > 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

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.