Subject: Re: [rrg] Next topic?

From: [email-masked] (Noel Chiappa)
Date: Mon, 9 May 2011 14:57:11 -0400 (EDT)

> From: Tony Li <[email-masked]>

    > I'd like to open the floor for the discussion of topics. Any
    > _research_ topic within the broad area of routing and addressing is
    > appropriate.
    > ...
    > Any proposals of research topics?
    > The floor is open...

Noting the silence, I do have one topic to suggest.

In prior conversations with you, you have suggested that the broad
architectural approach I prefer for path selection - i.e. topology
distribution, with unified path computation (although perhaps 'monolithic'
is a better term than 'unified', since the latter term was used elsewhere
in routing) - is problematic. I don't recall your reasoning exactly (not
that I ever got it in detail, I don't think), IIRC it was something to do
with a combination of:

i) ISPs didn't want to hand out topology information
ii) ISPs like the kind of policies about traffic flow they can impose
	with destination vector architectures
iii) the overhead of path computation needs to be distributed

So perhaps a discussion about what you see as the shortcomings of that
approach, and discussion about whether those issues are or are not
handlable, would be a good thing to do here?

	Noel

---

From: Sampo Syreeni <[email-masked]>
Date: Tue, 10 May 2011 04:20:31 +0300 (EEST)

On 2011-05-09, Noel Chiappa wrote:

> distribution, with unified path computation [...]

I'm sensing NIMROD, here. It'd be nice to see it rehashed why precisely 
OSPF-like full topology distribution and/or a purely source routing 
framework could or couldn't be done within a wider, multilevel context. 
Also the relative pros and cons of going that way, or not. A couple of 
decades or so more experience certainly couldn't hurt.

I also wonder whether there is some unifying factor under the 
Interplanetary Internet work, the recent, more practical routing work 
on-list wrt IRON/LISP/whatnot, and the long (thin or thick) network 
stuff. All three pictures rely heavily on information stored at the edge 
of the network, which will or should influence routing decisions. 
Evidently the data should stay at the edge, if at all possible, but all 
that caching, prediction and compression seems somehow unifiable to me.

Is there some overa(r)ching principle lying around here, perhaps having 
to do with (nondeterministic?) source routing, unconventional prediction 
by the source, and (soft state?) edge to core (? to edge? one-way?) 
signaling? With the grand aim of countering otherwise-expected latency 
and other routing-relevant problems, in an e2e-compatible way?

As a much more well-defined problem, a recent I-D-in-queue points out 
many problems in how IPv6's flow label is defined and constrained. One 
of the main solutions to the hassle that it proposes is to hide any 
manipulations of the semantics to within some fixed realm and/or AS 
and/or something, so that the manipulations aren't visible from the 
outside. Much of the LISP/IRON/MPLS/whatnot work tries to achieve the 
precise same thing -- transparent routing from the viewpoint of the edge 
device, while the core is doing something else entirely. So do we even 
now have a good description of what the edge device should see, once and 
for all? If not, nailing that down to pure logic would seem like a 
worthwhile exercise, and a rather well-defined one at that. As such it 
would be an academically motivated one, but in practice it might help in 
unexpected ways wrt the protocols we actually use, right now, including 
but not limited to IP and ICMP in their two main versions.

Van Jacobson et al's content centric networking, of course. Especially 
if we could somehow make it lighter-weight than it is now. (The inherent 
copying aspect is just as relevant or irrelevant as it was with TCP, I 
think, from the purely technical viewpoint. I'm also pretty sure there 
are efficient ways to compress those long URI-style addresses downto 
something routable in even current silicon. If not e2e, then at least 
MPLS-style hop-to-hop FEC-like. I'm thinking about some derivation of 
0-complete trees or something to that effect. But that's still research 
stuff, not real, clear-cut engineering, the precise way HIP used to be.)

An evaluation of any and all ways to aggregate and/or cheaply refine 
existing congestion pricing work done by the IETF at the core routing 
level would be neat as well. I.e. how might the ConEx work interface 
with the core routing fabric. Again, there might be a multitude of 
fundamental interface questions lurking around here, well-suited for 
IRTF and not so much for IETF.

Even a facts-based unification of fundamental internet protocol 
compressions is very much lacking. It probably could be done at least to 
a degree, and it would be very useful especially with IPv6, with its fat 
headers and the current deeply nested protocol stack. But nobody's ever 
tried to tackle the problem in full, at a fundamental level, at least to 
my knowledge.

These are all newbie ideas, but perhaps one or two of them could also 
break the silence Noel mentioned.
-- 
Sampo Syreeni, aka decoy - [email-masked], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

---

From: Tony Li <[email-masked]>
Date: Mon, 9 May 2011 18:33:48 -0700

Hi Noel,

> i) ISPs didn't want to hand out topology information

And perhaps more importantly, they are unwilling to disclose their policy information.  Peering policies are a very touchy subject.  Being nice to competitor A and not nice to competitor B is the type of diplomatic fodder that starts corporate battles.

> 	with destination vector architectures

Specifically, the ability to do hot-potato and cold-potato routing, as well as destination originated traffic engineering.

> iii) the overhead of path computation needs to be distributed

This is the least of the issues.  Yes, this needs to be distributed for scalability.  But then I come from a church where _everything_ needs to be distributed for scalability.

> handlable, would be a good thing to do here?

So I'm more than happy to have that conversation, but I would very much like it to proceed into a concrete topic proposal if we're doing it on RRG.  If we're having just a fun architectural discussion, then routing-discussion might be more appropriate, so that this list could be reserved for those developing topics.

Warmest regards,
Tony