propose bloom filter to encode routing table. exchange digests
compact size, low b/w cost to share. low false positive rate
false positives can be filtered by hash functions in digests. 0.003% left
Pekka: trading off b/w for processing cost. compute matches cost against
sending the BGP
Tony: what do you see as the constraint on convergeance?
Nischal: table sending time. time to reach convergeance is long
Tony: time for convergeance has interesting things, its more than
the bit size on the wire. time is dominated by processing not
transfer of data. this minimizes b/w. inconsistency detected
is only the presence of routes. even with exchanged hash,
but path attributes may need to be exchanged. eg session reset
then requires the full set of updates anyway. they will all
disagree
Lixia: digest is not calculated on every update. more periodic. do
not have to instantly re-calc. secondly, after session reset
try to avoid huge prefix swap, by just examining which entries
have changed, only exchange updates as incrementals
Tony: BGP already does incremental updates. don't understand where
this is going.
Joe: confused as to the goals. few routes different, session gets
reset and entire table is sent. this model has to do almost
the same amount of work apparently
Nischal: not entire entry, just prefix
Chandra: think issue here is that even one blackhole route is not good.
fixing false positives is good, but if has known error rate
Jeff: even if have perfect way to keep tables in sync, session reset
will require invalidation, regardless of overhead, processing
etc cost is significantly less than route selection on entries.
Vila: exchange network b/w for router memory. use graceful restart
doesn't matter how long takes, traffic flows. whats the point
Jeff: doesn't preserve forwarding table
Yakov: why use graceful restart. flaps. spend bit more effort trying
to reduce BGP flood, help other things anyway
Tony: cannot stop the backhoe. using this to schedule updates is good,
accelerate convergeance, schedule deltas ahead of full table
but still have to send full table. simpler mechanism for all
of this. put the work on sender side with its incremental updates
using re-sync procedure, schedules, floods first, then trickle
older updates later. can do that no problem.
This is a wonderful technique, but it is more applicable to ISIS,
Henk: calc/processing overhead. measured? against eg stable situation
adding one route inconsistency, measure time, effort compared
to classical?
Nischal: do normal BGP costs more: digest exchange costs max 760k, full
table costs 5+Mb.
Chandra: status? intention?
Nischal: grow, or other places, have to sit and decide.
Dave: not appropriate for operations group