[Xorp-hackers] is this right?
Atanu Ghosh
atanu@ICSI.Berkeley.EDU
Tue, 09 Aug 2005 10:17:56 -0700
Hi,
I'm not absolutely clear on what you are attempting here.
The assumptions with respect to the RIB-IN are correct the unmodified
route is held here and the delete_route() should contain the original
med. When a peering is taken down all the the routes are withdrawn. If
there is a large number of routes in the RIB-IN (we see around 160K
routes) when a peering goes down we can't atomically delete the routes
in the RIB-IN remove the winning routes from the routing table and
inform all of our peers. We therefore dynamically create a deletion
table with the old trie after the RIB-IN. The old routes can then be
deleted and a new peering can be accepted immediately. Therefore old
routes can continue to flow through the system even though a new peering
is in effect. The routes contain a generation ID that it may be
necessary for you to track.
Atanu.
>>>>> "Ratul" == Ratul Mahajan <ratul@cs.washington.edu> writes:
Ratul> hi -
Ratul> i am experimenting with a new interdomain routing protocol, as part of
Ratul> which i need to do keep track of
Ratul> - the sums of the MEDs received from each ebgp peer.
Ratul> - the sums of the MEDs sent to each ebgp peer.
Ratul> (its actually a custom attribute but pretty much like MEDs)
Ratul> since i am not intimately familiar with xorp code, it'll be great if
Ratul> someone verified what i am doing is correct.
Ratul> i do the following:
Ratul> 1. add member variables sum_in and sum_out to PeerData which are
Ratul> updated through Rib[In,Out]->PeerHandler->Peer->PeerData
Ratul> 2. update sum_in in RibIn
Ratul> 2a. subtract in add_route() and delete_route() the MED of
Ratul> existing route, if any*
Ratul> 2b. add the MED value of the new route in add_route()
Ratul> 3. update sum_out in RibOut
Ratul> 3a. subtract in delete_route(), using the MED attached to rtmsg,
Ratul> the route passed in the argument*
Ratul> 3b. add in add_route() the current MED
Ratul> * 2a and 3a are based on the following assumptions:
Ratul> - 2a: the routes stored in RibIn are never changed or deleted from
Ratul> what is originally received, no matter what the input filters
Ratul> do. (i realize that this might change in the future)
Ratul> - 3a: the rtmsg in delete_route() contains the correct old MED
Ratul> value, since the filtertable re-applies the filters to old route
Ratul> passed through the fanout table
Ratul> are the following assumptions correct?
Ratul> are there cases when the above procedure will break, e.g., peerings
Ratul> up/down or too many routes in the queue?
Ratul> thanks!
Ratul> _______________________________________________
Ratul> Xorp-hackers mailing list
Ratul> Xorp-hackers@icir.org
Ratul> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers