Subject: Re: [arch-d] Do we have "partial consensus"?

From: [email-masked]
Date: Wed, 13 Dec 2006 04:38:01 EST

Some more notes pro hierarchical routing:
 
PNNI : The PNNI architects are still around: Ross Callon, Joel Halpern,  
George Swallow, Mickey Spiegel.  It was a fine protocol development which  would 
never have been accomplished if the Bell-heads had understood more of it  :-). 
PNNI contains good and less good things. From some distance that can be  
distinguished even better as to learn from both.
 
There is also a nicely written draft from Frank Kastenholz: ISLAY.  But  from 
a single draft you cannot learn  "by experience",  particularly you cannot 
learn from its worse parts. 
 
And: We all do hierarchical routing day by day.When it comes to travelling,  
at least in your mind you do combine the city map where your trip starts as to 
 get to the right exit, the country road map as to get to the nearest 
airport, a  world map with all the flight routes as to get to the destination 
airport. And  while you haven't yet left the ingress city your routing decisions do 
not  consider any road labor blockings nearby  the hotel of your  destination.
 
I can only repeat myself: There is no better solution than HR, and also HR  
is sufficiently precise.
 
Heiner
 
In einer eMail vom 12.12.2006 20:19:49 Westeuropäische Normalzeit schreibt  
[email-masked]:

I dare to assume Heiner didn't intend 
" 
" you're  so far out of it that you need to go away for a week or  two!"

[email-masked] <[email-masked]>  wrote:
>  
> I have a different list of objectives:
>  
> - develop an architecture which fits even for a 100 times  bigger
>   internet while the workload for the individual  router becomes
>   100 times less than is necessary  today

I agree with this objective.

Speaking only for myself: I specifically tried to minimize the
"routing"  "layer" task. My list contains _only_ the things I think
can't be moved to  another layer, and specifically excludes finding
alternate paths if  forwarding isn't possible.

> Will say, by knowing the hierarchical  network topology of 100 nodes+300 
> hierarchical nodes the same can be  accomplished than be learning about
> 100 million  routers.

Again speaking only for myself: In describing  "layer" responsibilities
I did not intend that all must be accomlished in  the same box. I can
easily imagine totally separating the "routing  protocol" boxes from the
"forwarding" boxes.

> - develop a  one-face-only architecture (rather than a collection of   
>   completely orthogonal concepts like BGP versus  OSPF)
> PNNI at least tried to accomplish such a one-face-only  architecture.
> It was later, in response to PNNI, that OSPF came up  with areas
> (simpler,less ambitious, but not as perfect in  design).

This sounds like it deserves its own  thread...

> -do routing such that fear of loops doesn't have to be  at  all.

Hmm...

I don't think  "routing gurus" will get over that fear in my lifetime!

> -do  routing such that real-time traffic balancing is enabled   

Speaking only for myself: I don't think the "routing"  "layer" can do
any more for that than signal what bandwidth is available to  particular
destinations (currently CIDR block) forwarded from each  forwarder's
individual peers. Even that much begins to intrude on Heiner's  first
principle (scaling by a factor of 100).

> - do clean cuts:  
> 
>   a) at the edges: the used technology there  (LAN,WLAN,...) is outside
>      the  scope.

I'd be happy to agree to that. However, the  question seems premature.

>   b) wrt. layering and also  within the routing protocol: flooding is
>      needed  for detecting the topology. As soon as the topology is
>     provided, loopfree propagation/advertisement of whatsoever can  be
>      done better than by flooding. If it is not  routing relevant but
>      rather end-to-end relevant it  should not even be part of routing.

Feel free to start a  new thread on this issue. (I'm not sure I
understand your point well enough  to respond yet.)

>   c) wrt. addressing:
>   PNNI tried to handle at least 3 prefix-summarizable  address
>      families (IPv4 not counted in) of users.  Obviously all of them
>      could not be  used for  identifying PNNI-nodes concurrently.
>      User  addresses must not be mixed up with (hierarchical) nodes'
>     addresses.

I agree it's important for us to  _architecturally_ distinguish them.
I doubt, however, we will be able to  prevent users from confusing them.

--
John Leslie  <[email-masked]>

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Peter Sherbin <[email-masked]>
Date: Wed, 13 Dec 2006 13:35:48 -0800 (PST)

Would the following suffice:

- the globe is covered with a hierarchical backbone terminating at attachement
points(AP) e.g. per every 10 sq miles
- each AP has a unique address, i.e. fixed geo/topo location
- every edge network has a globally unique name
- AP maintains a table of attached names to route packets within its area
- AP combines its address with a name to route packets outside of its area
- the lowest size of the edge networks is one node
- parts of the backbone are supported by various public / private entities
- AP addresses are distributed by RIR
- edge network names are distributed by e.g. local tax authorities

The above allows free moves of edge networks carrying only their names between 
AP.
IETF/IANA regulates two pools of numbers: backbone/AP addresses and edge networks'
names.

Thanks,

Peter

> https://www1.ietf.org/mailman/listinfo/architecture-discuss

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 14 Dec 2006 14:10:59 +1300

Unfortunately, no.

The real network isn't nearly this simple.  Solutions in this class  
have to derive the locators from the observed topology (which will  
change with time).  This is the problem with Heiner's hierarchical  
suggestion too.  Not to say that it can't be done, but we cannot  
posit a topological simplification; the topology is only going to get  
more complicated.

Andrew

On 14/12/2006, at 10:35 AM, Peter Sherbin wrote:

>> airport. And  while you haven't yet left the ingress city your  
>> routing decisions
>> do

---

From: John Day <[email-masked]>
Date: Thu, 14 Dec 2006 17:08:32 -0500

Catching up:

No the topology shouldn't change.  But the graph may.

At 14:10 +1300 2006/12/14, Andrew McGregor wrote:
>Unfortunately, no.
>
>The real network isn't nearly this simple. 
>Solutions in this class have to derive the 
>locators from the observed topology (which will 
>change with time).  This is the problem with 
>Heiner's hierarchical suggestion too.  Not to 
>say that it can't be done, but we cannot posit a 
>topological simplification; the topology is only 
>going to get more complicated.
>
>Andrew
>
>>>airport. And  while you haven't yet left the 
>>>ingress city your routing decisions
>>>do