Subject: Re: [rrg] Summary of architectural solution space

From: [email-masked]
Date: Thu, 11 Dec 2008 17:50:31 EST

In einer eMail vom 11.12.2008 23:11:52 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Thu,  Dec 11, 2008 at 3:42 PM,  <[email-masked]> wrote:
>  Some comment and proposals to improve the strategy C text which  currently
> is:

This references  http://bill.herrin.us/network/rrgarchitectures.html

The current text  is:

> Suppress distant routes by aggregating them into sets expected  to be
> available in a given direction. Because LOC reachability info is  not
> flooded, the routing tables each router must deal with are  relatively 
small.
You should say, because user reachability information is not  flooded,..

>  --------------------------proposed text:
>  Extend BGP such that routers can acquire the view of a well-sparsed  
internet
> topology
> with strict links in the near surrounding  and - in general - with loose and
> looser links the
> more remote  they are (strict links to very remote nodes may still be part 
of
> this  topology). Determine the next best hop  based on that viewed
>  destination node which is either the true destination node or a node  which
> is closest to  the true but not yet visible   destination node. Arrange the
> results such that a best next hop can be  retrieved either by 1 or by  3
> table lookups.

As I  mentioned in our email exchange, I don't understand what this
means. What  is a "well-sparsed" Internet? 
A topology which doesn't show the details of the remote  network  parts. 
Similar to routing from NY, Broadway to Sausolito, Main Street without  seeing the 
Main-Street prior entering Sausilito itself.

What is  a loose or strict
link? 
This is IETF terminology.

How do  you determine that a node is "closest to" a node that
isn't visible? 
By the distance (in miles or km) which is adequate in location base routing  
- IMO.

What is  the significance of 1 or 3 table lookups?
Much faster forwarding. Eliminating the need for caching.

> Of course, incremental deployment has to be  supported.The goal is to shrink
> the routing table continuously so that  it becomes empty as soon as  all DFZ
> routers will  comply.

This is a goal, not a strategy.
I skipped the previous explanatory sentence because I thought it is too  hard 
to understand :-(
 
I have one further comment with respect to the mentioned economic model of  
IP. It is just the opposite:
Strategy C avoids everything which looks like administrative hierarchy.  
Rather ask ILNP or HAIR or Joel's presentation. There is no single hint for any  
political/administrative influence in all of what I presented.
Another point: I have always argued against the generalization that  
hierarchical routing is doomed to cause stretch=3 because it is not true wrt  TARA. 
However I can well understand that this reproach is appropriate to ALL the  
currently arising hierarchical ideas.  
 
Heiner

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "William Herrin" <[email-masked]>
Date: Thu, 11 Dec 2008 19:44:21 -0500

On Thu, Dec 11, 2008 at 5:50 PM,  <[email-masked]> wrote:
> Similar to routing from NY, Broadway to Sausolito, Main Street without
> seeing the Main-Street prior entering Sausilito itself.

Hi Heiner,

I think I'm going to stick with "aggregated." You've aggregated
Broadway into New York and you've aggregated Main Street into
Sausolito. Unless there is some subtlety to the notion of "well
sparsed" that you haven't communicated?

"Well sparsed" has no meaning in network engineering that I'm aware
of. The only time I recall encountering the word "sparse" in network
engineering was in describing an address assignment strategy where new
assignments try to split the largest available free space so that they
have the the best probability of being later growable by only changing
the netmask.

> > What is a loose or strict link?
>

I haven't heard it before and I still don't know what you're talking about.

Did you mean to say loose-source-route like what Anja presented in the
HAIR documents? I could see that as a variant C2:

C2. Replace the endpoint's IP address with a loose source route and
update protocols accordingly. The loose source route consists of a
sequence of waypoint addresses, the first of which is expected to be
known to all routers on the Internet and the last of which is the
destination machine. Each waypoint router is required to know a route
to at least one of the later waypoints or the final destination.

Reminds me of my old UUCP email address...

One interesting consequence of C2 is that you get an effectively
variable-length address while each router that isn't a waypoint only
needs to consider a fixed length address. No more worries about
running out of addresses; you just place non-unique addresses behind
another waypoint.

Something similar to C2 would probably also be legitimate for strategy
B, where a link failure causes you to replace one of your waypoints
but leaves the rest alone instead of completely changing your locator.

> By the distance (in miles or km) which is adequate in location base routing - IMO.

How do you know the distance if information about the node isn't
visible? Is it encoded in the network address? How?

> Much faster forwarding. Eliminating the need for caching.

Let me try again: You've made a leap in logic from loose and strict
links to 1 or 3 table lookups. Please fill in the middle.

> Rather ask ILNP or HAIR or Joel's presentation. There is no single hint for
> any political/administrative influence in all of what I presented.

That's the criticism, that administrative routing policy is a
mission-critical feature of any routing protocol and strategy C fails
to support it. Authors of strategy C systems should expect to be asked
how their approach avoids the theft-of-service problem. If they wish
to be taken seriously, those authors should prepare a thorough and
well-considered answer.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg