[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