Re: [RRG] Geographic aggregation-based routing

[Robert Bonomi <bonomi@mail.r-bonomi.com>]

> From owner-rrg@psg.com  Sun Jul 13 09:45:46 2008
> From: HeinerHummel@aol.com
> Date: Sun, 13 Jul 2008 10:38:19 EDT
> Subject: Re: [RRG] Geographic aggregation-based routing
> To: bill@herrin.us
> CC: rrg@psg.com
>
>
>
> The emails of this thread have been about the shortest path  computation in a 
> network where any subset of links are allowed to be used only  in one 
> particular direction.
> I wonder whether the described solution (replacing links by either two or  
> only one arrow,assigning any predecessor only if there is a fitting arrow from  
> there) is or is not common place?
>  
> It has always been useful for QoS/SLA/available bandwidth  sensitive/etc  
> routing inside any OSPF network.
>  
> Can either OSPF-experts or edu-folks comment on my question?

Back in my college days (long! ago :), in civil engineering it was universal
to represent *all* traffic segments as _one-way_ linkages for 'most desirable' 
path determination.

For, among other reasons, the fact that desirability of using certain segments 
was sensitive to instantaneous load levels on that segment; also load levels/
delays in one direction are -not- necessarily indicative of behavior and/or
desirability of the reverse path.


In the real world there _are_  non-trivial numbers of 'corner' cases -- one-
way paths, assymetric paths, etc. -- that one must be prepared to deal with.

The use of unidirectional graphing elements makes it much easier to deal with
those 'corner' cases.

Unidirectional elements -- in a multiple-source, multiple-destination, 
network -- also allow for better handling of assymetric load levels among 
particular station 'pairs' -- i.e., A->B is much higher/lower than B->A,
by whatever metric is employed.

And, of course, when networks have multiple points of inter-connection, the
'preference' of which inter-connect point ot use may well be different, 
depending on "where, on which network" one is starting from.

Many years ago, in metro Chicago,  I had a wonderful real-world example
of this.  Two systems, less than 3 miles apart, on networks without any
direct peering, or regional inter-connect.  'Preferred' path from A to
B was via MAE-EAST, but the preferred path from B to A was via MAE-WEST.
'traceroute' clearly identified where the preference changed -- one could
clearly see the discontinuity in RTT when packets reached the node where
the 'return' preference changed.



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg