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 protected]:
On Tue, Dec 23, 2008 at 3:35 AM, <[email protected]> wrote: > In einer eMail vom 23.12.2008 00:16:53 Westeuropäische Normalzeit schreibt > [email protected]: > > On Mon, Dec 22, 2008 at 5:55 PM, <[email protected]> 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 -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
