Subject: Re: [rrg] RRG to hibernation

From: [email-masked] (Noel Chiappa)
Date: Sun, 11 Nov 2012 20:55:52 -0500 (EST)

> From: William Herrin <[email-masked]>

    > 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

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 11 Nov 2012 18:13:44 -0800

> 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.)

I think that we are giving up too early on the feasibility of updating all
hosts. Indeed, any substantial change in routing and addressing would most
probably end up changing all hosts, or at least most of them. I also think
that a research group should not necessarily shy away from investigations
that affect all hosts. If research comes out with a brilliant shiny star on
the horizon, then engineering might follow. If the best we can do is hack on
the edges of current solutions, then engineering groups can definitely do
that, no need for a research group.

-- Christian Huitema

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Nov 2012 21:48:22 -0500

I can well believe we can, for a reasonable value of all, update all 
host TCP and UDP engines with a small, migratable, change.
We can't change all host applications.
And we can not make a change that does not interoperate with existing hosts.

Yours,
Joel

On 11/11/2012 9:13 PM, Christian Huitema wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: [email-masked]
Date: Mon, 12 Nov 2012 04:23:46 -0500 (EST)

Christian,
you are absolutely right. However,  avoiding any impact on the users has been the number ONE objective of LISP.
And now, by moving even to LISP-DDT,i.e. dumping allegeable worse variants, the consequences will be disasterous.
Heiner

-----Ursprüngliche Mitteilung----- 
Von: Christian Huitema <[email-masked]>
An: 'Noel Chiappa' <[email-masked]>; rrg <[email-masked]>
Verschickt: Mo, 12 Nov 2012 3:13 am
Betreff: Re: [rrg] RRG to hibernation

if you can
the new

-- Christian Huitema