Subject: Re: [rrg] RRG recommendation

From: [email-masked] (Noel Chiappa)
Date: Tue, 10 Nov 2009 10:26:15 -0500 (EST)

> From: [email-masked]

    > Yes, but do hierarchies right.
    > ...
    > I have my doubts that the routing folks have a proper understanding wrt
    > hierarchies.

This is probably true, because we just haven't had that much experience with
them; the _very_ limited amount of hierarchy in use in the current system is
just not enough to fully educate us about them.

(I'd like to make an analogy to congestion control - back in the '77-'79 time
period, not only did we not know much, we didn't know how much we didn't
know... Well, a few people probably had a clue, but the rest of us did not
really... :-)

But I do think this particular topic is something that the RRG _should_ be
thinking about, since it's closer to what I think a 'routing research' group
should be thinking of.

(The location/identity separation stuff is not, to me, really routing - it's
more basic architecture, but since the I* doesn't seem to have a forum for
basic architecture discussion, it seems to have wound up here...)

    > What it takes is a "sliding hierarchy" as provided by TARA so that each
    > router is fairly in the middle of the hierarchy and never at the very
    > rim.

Sorry, I don't know enough about TARA to respond to this. Your Istanbul
analogy didn't really help me much. Can you say more?

    > Hierarchy is by no means a reason to enforce a path which is longer
    > than the shortest one!

True, but.... it seems to me fairly fundamental that the basic idea behind
hierarchy and routing is that it allows one to discard _some_ information, to
make the amount of data one has to process in the path-selection computation
more reasonable. That being the case, it seems inevitable that _some_ stretch
(over the theoretical minimum) should result.

To return to your real-world map analogy, nobody planning a trip from Madrid
to Gdansk goes out and obtains a map that shows _every_ road in Europe, and
does their path-selection based on that. Any realistic approach would use
'high-level maps' from which many of the minor roads have been omitted.
However, ignoring those minor roads may result in a path which is longer
than the theoretical minimum.

(And yes, I know, a theoretical-minimum length path would probably be slower
than a path which took the larger limited-access highways... most people want
to optimize time, and the road system itself has been designed to optimize
that goal, e.g. with the constuction of those larger limited-access highways,
so in the real-world there's an interesting interaction between the
map-abstraction process and the infrastructure planning process - maybe the
network world needs to do something similar?)

	Noel

---

From: [email-masked]
Date: Tue, 10 Nov 2009 16:32:32 EST

> I have my  doubts that the routing folks have a proper understanding wrt

This is probably true, because we just haven't had  that much experience 
with
them; the _very_ limited amount of hierarchy in  use in the current system 
is
just not enough to fully educate us about  them.

(I'd like to make an analogy to congestion control - back in the  '77-'79 
time
period, not only did we not know much, we didn't know how much  we didn't
know... Well, a few people probably had a clue, but the rest of  us did not
really... :-)

But I do think this particular topic is  something that the RRG _should_ be
thinking about, since it's closer to  what I think a 'routing research' 
group
should be thinking  of.

Fine. I can promise: It is not just about reducing some ugly aggregation  
material. 
It is also about enabling Moore's law. And even better: Given that you can  
index the best next hop information by ONE offset info as taken from the  
packet header (similar to MPLS), you can also do temporary reroute by the 
same  speed: by just storing the temporary alternate next hop info at that 
place where  as a default the very best next hop info would be placed. (plus a 
long list of  more advantages).

(The  location/identity separation stuff is not, to me, really routing -  
it's
more basic architecture, but since the I* doesn't seem to have a forum  for
basic architecture discussion, it seems to have wound up  here...)

I fully agree.   

Well, being a godfather of PNNI you ought to understand the  
Istanbul-analogy :-)

True, but.... it seems to me fairly fundamental that the basic  idea behind
hierarchy and routing is that it allows one to discard _some_  information, 
to
make the amount of data one has to process in the  path-selection 
computation
more reasonable. That being the case, it seems  inevitable that _some_ 
stretch
(over the theoretical minimum) should  result.
While being in the USA you should really discard the info about  streets 
inside European villages (better: you should not even get them). At  the same 
time you should definitely NOT discard any physical link which directly  
interconnects some place in America and another place in Europe. In the end, it 
 is better to speak of a hierarchically sparsed flat topology !
So I use the term hierarchy only because  this term is better  understood 
by the readers (imho)

Noel wrote:
To return to your real-world map analogy, nobody planning a trip from  
Madrid
 
This depends on your concept. If you want to go from Istanbul-West to  
Istanbul-East and your hierarchically upper map recommends you to go to Ankara  
(or even Teheran) first before being able to appreach  Istanbul-East then 
you will have this ugly stretch factor.

Noel wrote: (And yes, I know, a theoretical-minimum length path would  
probably be slower
than a path which took the larger limited-access  highways... most people 
want
to optimize time, and the road system itself has  been designed to optimize
that goal, e.g. with the constuction of those  larger limited-access 
highways,
so in the real-world there's an interesting  interaction between the
map-abstraction process and the infrastructure  planning process - maybe the
network world needs to do something  similar?)
 
Well this is state of the art. To play with the weight values of the  edges.

Heiner

---

From: [email-masked]
Date: Tue, 10 Nov 2009 16:48:16 EST

Lixia,
 
Excuse my minimal knowledge about  transport layer and DNS (I  only think 
to know a lot about routing).
So I cannot say anything wrt to pages 7 & 8. Maybe GROBJ enables  some 
progress ?
 
Heiner
 
In einer eMail vom 10.11.2009 15:44:38 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Nov  10, 2009, at 1:32 AM, [email-masked] wrote:

> In einer eMail  vom 10.11.2009 08:04:50 Westeuropäische Normalzeit  
> schreibt  [email-masked]:
>
>> the presentation slides are  at:
>>  
http://www.nanog.org/meetings/nanog44/presentations/Wednesday/Zhang_Wed_N44.pdf
>>
>
>  Quote from these slides:
> The problem: routing too flat
>  solution: add more hierarchies in addressing & routing
>
>  Yes, but do hierarchies right. There have been multiple hierarchical   
> proposals which did the hierarchical aggregation in the wrong  way.  
> What it takes is a "sliding hierarchy" as provided by TARA  so that  
> each router is fairly in the middle of the hierarchy  and never at  
> the very rim.
> Analogy: Imagine a city map  for Istanbul, Turkey, with a Western  
> part containing each  single street and an Eastern part being a  
> highly aggregated  road map for entire Asia.
>
> Or take Compact Routing studies  which mentioned stretch factor  
> 17 !!! Hierarchy is by no means  a reason to enforce a  path which is  
> longer than the  shortest one! Neither when being in the middle or at  
> the rim  ("Istanbul").
>
> How many hierarchical levels is the right  number? Who says "the less  
> the better" is  wrong.
>
> I have my doubts that the routing folks have a proper  understanding  
> wrt hierarchies.
>
> Heiner

Hi  Heiner, a couple comments here.

1/ one needs to read this with the  understanding of its context--the  
quote you picked reflected  understanding 15 years back.
the world has changes in significant ways  since then
We understand much better now too.

2/ most importantly, I  was calling attention to Postel's comments on  
slides 7 & 8:  these quotes were taken from the meeting minutes then:

- “Transport  layer ID is not an issue that we
need be concerned with for  now. Once we
decide what to do for IP addresses,  then
transport people can easily figure out how
they may use the address.”

- “We must avoid circular  dependencies;

- “we must define a substrate of the
system that can operate without DNS. ...

- “we must not depend on DNS  to
bootstrap the core operation of the
system”

Personally I believe these design guidelines still hold true  today.

Lixia

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 11 Nov 2009 21:10:39 -0500 (EST)

> From: Scott Brim <[email-masked]>

    > NAT won't be everywhere, and .. it will go away eventually

One more time:

No, it won't, not unless the deployed architecture provides _all_ the
capabilities NAT now gives us (e.g. provider independence). As long as we
don't have separate location and identity namespaces, we by definition
can't have provider independence.

    >> NAT66 stands as a potential solution, with its pros and cons,
    >> independent of such a prediction.

    > If NAT66 is everywhere then the RRG doesn't need to do much.

Only if the existing routing architecture (ERA - i.e. distributed
computation by passing destination vector tables around, with limited
built-in naming abstraction tools) does all we need.

I.e. i) only if the ERA can continue to handle the network as it gets
bigger (since it will, even if separation of location and identity
namespace allows us to do some gargage collection on the routing tables),
and ii) we don't need/want any additional capabilities out of the routing
(e.g. multiple metrics, or some user influence over paths, or whatever).

	Noel

---

From: [email-masked]
Date: Thu, 19 Nov 2009 03:52:27 EST

In einer eMail vom 19.11.2009 09:36:31 Westeuropäische Normalzeit schreibt  
[email-masked]:

Locators  are necessarily about network attachments (per stack).  If a 
host has  multiple points of attachment, then it should have multiple  
locators.  And only one  identifier.

Regards,
Tony

Yes. Easy as pie:-)
Heiner