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

From: [email-masked]
Date: Tue, 12 Dec 2006 13:21:29 EST

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 (obviously it can only be hierarchical; compare:  100 +100+100 
+100= 400 while 100 x100x100x100 =100 ,000,000.
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.
 
-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).
 
-do routing such that   fear of loops doesn't have to  be at  all.
 
-do routing such that real-time traffic balancing is enabled  
 
-do clean cuts: 
a)at the edges: the used technology there (LAN,WLAN,...) is outside the  
scope.
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 ot routing.
Compare: Neither OSPF- nor IDR-WG will ever be shut down. They may sleep  
eventually while waiting for some  new topic, as to get their shares  just like 
the MIB-folks would get.
This however is due to the lack of a clean cut. I don't like the idea of a  
building which is never completed.
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.

Heiner

 
In einer eMail vom 12.12.2006 17:52:37 Westeuropäische Normalzeit schreibt  
[email-masked]:

Bound,  Jim <[email-masked]> wrote:
> 
> I believe we must  separate transport end-to-end as one problem space and
> routing as  another problem space completely...

I agree with Jim, and  I'd like to try for a first pass at consensus  on
architecture.

Statement:

We want  to work towards an architecture with separate "layers" for
"routing" and  "transport", where "routing" is responsible for
- delivering packets to  destinations on the same network;
- forwarding the other packets to another  network "closer" to their
destination;
- dropping the other  packets if no "closer" network is available;
- building forwarding tables  believed to be loop-free;
- detecting loops in forwarding paths actually  used;
- dropping packets which would cause excessive congestion;
and  "transport" is responsible for
- detecting and adjusting for packet  loss;
- detecting and adjusting for packet corruption;
- reducing packet  injection rate when a path is congested;
- choosing among multiple paths  (if available).

Question Areas:

- is there a better name than  "layers" for these problem spaces?

- is there a better name than  "routing" for the lower "layer"?

- is there a better name than  "transport" for the upper "layer"?

- are any of the responsibilities  clearly assigned to the wrong "layer"?

- are we ready to agree to  define separate namespaces for these "layers"?

(I know  there are other responsibilities which _must_ be assigned
before we can  have a working system: I'd _really_ prefer not to argue
where they belong  yet...)

--
John Leslie  <[email-masked]>

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

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

---

From: John Leslie <[email-masked]>
Date: Tue, 12 Dec 2006 14:18:43 -0500

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

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