> From [EMAIL PROTECTED] Sun Jul 13 09:45:46 2008 > From: [EMAIL PROTECTED] > Date: Sun, 13 Jul 2008 10:38:19 EDT > Subject: Re: [RRG] Geographic aggregation-based routing > To: [EMAIL PROTECTED] > CC: [email protected] > > > > 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 [EMAIL PROTECTED] 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
