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

From: Scott Brim <[email-masked]>
Date: Fri, 12 Dec 2008 14:10:45 -0500

Tony Li allegedly wrote, On 11/24/08 5:05 PM:
>  
> 
> |> Interesting.  So you're saying that it's perfectly ok for 
> |the operational
> |> folks to set aside the stated routing architecture and do 
> |something else?
> |
> |Not exactly, but I think we do have to try to make future technology
> |intersect with reality.
> 
> 
> Or make reality intersect with future technology...

We need to make it clear if something isn't possible or if it will
really hurt the Internet.  But we need to acknowledge where the network
operators want to go.  "provider-independent" addressing isn't a threat
in itself unless we demonstrate that there is no good way to support it.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Mon, 22 Dec 2008 02:49:19 EST

Bill,
you missed my point:
I am accusing the dependency on user reachability information dissemination  
and wanted to hi-light its absurdity by this example.
 
The determination of various policy/QoS- specific routes is another topic  
and can well be served, if the topolgy is well known. On the one hand side, I am 
 confronted with non-understanding, on the other hand side I should explain  
policy/QoS routing prior shortest routing. Believe me, I have algorithms ipfrr 
 doesn't get close to them. And distance vector based BGP doesn't even 
provide  half of the possible routes. Where is time-of-day based inter-domain 
routing ?  Where is the right and natural approach to combine the end-hosts' and the 
ISPs'  interests in routing ? There would be a substantial improvement due to 
TARA, a)  by better than Dijkstra routing algorithms,  b) because it became  
affordable (no churn, no binary or hash search, no table size problem) and c)  
because it became feasible ( roughly: two thirds of the paths aren't even  
offered for selection).

Heiner

In einer eMail vom 21.12.2008 23:57:37 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Sun,  Dec 21, 2008 at 11:17 AM,  <[email-masked]> wrote:
> My  saying since 45. I have referred to two other networks which both are
>  1000 times larger:
> the road network, and the postal service network.  None of them has this
> crazy problem because none of them does user  reachability information
> dissemination. Let me point to a 3rd network:  the railroad network.
> There a single link (=railway between two  distant cities) may take 10 years
> building  it.

Heiner,

How do you select which train or flight you will  take?

When I select a train or flight, I have multiple  considerations:

1. From the potentially viable destination stations,  how convenient is
the street-level route I've precomputed after acquiring a  local map?
If I take a cab, how much will the cab fare cost? Would it be  cheaper
to rent a car?

2. From the potentially viable source  stations, how convenient is the
street-level route from my current  location? If I take a cab, how much
will the cab fare cost? Would it be  cheaper to pay for parking at the
station?

3. Which trains or  flights go to the stations in question during the
period I want to  travel?

4. Which train or flight is offered at a price I'm willing to  pay?

You'll notice that in order to take a single long trip, I've  acquired
a substantial subset of the routing data and applied a very  complex
set of heuristics in order to precompute my door-to-door  route.

And did I mention that the trains and aitlines are regularly  bankrupt?
It seems they have a helluva time managing their  costs.

Geographic routing for human travel may seem simple and  efficient, but
it only seems that way.

Regards,
Bill  Herrin

-- 
William D. Herrin ................  [email-masked]  [email-masked]
3005 Crane Dr.  ...................... Web: <http://bill.herrin.us/>
Falls Church, VA  22042-3004

---

From: [email-masked]
Date: Tue, 23 Dec 2008 12:20:57 EST

Bill,
I can give you two different answers. The first one is like backing up, the  
second one is not afraid of your "punch".
 
1) should politics follow suit ! And they certainly will. Example: When the  
telco's became private companies
Least Cost Routing was the big topic. Multiple distance zones were defined  
as to affect billing. But soon companies realized that they were unable to  
implement such policy and that they might get in big trouble if the per  call 
detailed bill weren't correct. So all of a sudden, the flat rate was  born and 
telco's who eventually were capable of doing distance-zone-conform  charging ( I 
doubt that there were some) concurred i.e. adopted the flat rate  too. Will 
say: policy will adopt to what is feasible. 
 
2) I would run 99 times my going-beyond-Dijkstra algorithms (anyway) as to  
validate all 300 links and each of them wrt to both directions how well they 
can  be used. Some A or some B who want's to discriminate using the link A<-->  
B as to deny servicing 10.0.0.0/8 should advertise this policy, however  well 
scoped. When a packet arrives it will have to be screened for  10.0.0.0/8. 
When I said only 3 table offset lookups are needed then to retrieve  the complete 
ranking info regarding all adjacent links wrt to the particular  destination 
location from best next hop to imposible because it entered a dead  end. This 
ranking info may eventually include such discriminating data. (but  others as 
well: the actual ranking order may reflect the current time as to do  
time-of-day sensitive routing for instance !
 
Try yourself time-of-day sensitive routing !
 
Heiner

In einer eMail vom 23.12.2008 15:25:38 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Tue,  Dec 23, 2008 at 3:35 AM,  <[email-masked]> wrote:
> In  einer eMail vom 23.12.2008 00:16:53 Westeuropäische Normalzeit  schreibt
> [email-masked]:
>
> On Mon, Dec 22, 2008 at 5:55  PM,  <[email-masked]> wrote:
>> I think there are  enough folks around who are both experts in BGP and
>>  OSPF.
>> (1):
>> My question is, what sort of  policy/QoS/etc. routing can only be enabled
>> by a distance vector  protocol

> Address and direction sensitive link state. That is, for  some
> combinations of source, destination and direction of transit the  link
> is up, but for other combinations of combinations of  source,
> destination and direction of transit the link is  down.
>
> And so can link.state protocols, right ? !
> They  just do it in a different way. Also, you may color the nodes and links
>  such that you can even get Multiple Topologies (see OSPF-MT).

Go try  it.

Build yourself a random network of 100 nodes with a total of 200  to
300 links between those nodes. For each direction on each link,  assign
10 or so ranges of source+destination address for which the link  is
considered "up." Let me give an example of what I mean by  that:

Network:   A-B

Link direction AB is UP for  source 10.0.0.0/8, destination any
Link direction BA is UP for source any,  destination 10.0.0.0/8
Links AB and BA are DOWN for all other combinations  of source and destination

Once you've built your 100-node network "on  paper," do the following:

1. Calculate the size of your link-state  RIB.

2. Formulate an algorithm, presumably using Dijkstra, that  processes
that RIB into a next-hop FIB at a given node.

3. Calculate  the size of the resulting next-hop FIB.

What you'll find when you  do this is that the addition of direction
and source address to the RIB may  square its size versus a comparable
distance-vector RIB. Worse, your  Dijkstra calculation won't be able to
process out the impact of the source  address on the FIB calculation so
you'll have to carry the source address  into the FIB as well. This may
square the size of the FIB you need to carry  versus a distance vector
protocol.

With DV, the source address  factor is subtractive. It's handled by
reducing the database entries  propagated over particular links,
removing the ones that aren't acceptable  for that link. With
link-state it's multiplicative, vastly increasing the  database size.

Regards,
Bill Herrin