Thanks for the minutes. Some comments. In message <9605091017.AA28975@jade.noc.dfn.de>, Joachim Schmitz writes:
- Action 22-9 on RIPE NCC/ANS: To find a final date when to give up advisory tags. status: DONE (more or less)
As far as ANS is concerned, advisory tags in the route object have been ignored since about November or so of last year. Why is this still an agenda/action item?
- for the registration of new ASs, submission of a routing policy has become compulsory. This data is actually used (by ANS, BT, and possibly others) to generate filters
Prior attempts to automate this (generating policy for new AS) failed due to missing aut-nums and the lack of routing policy in aut-nums. We're just as guilty with ANS AS13xx. I've noted that this has improved in the RIPE database and may revisit this soon. At this point we still rely on notification from adjacent providers which means that Dante, EUNET, connected AS get updated quickly (they notify us) and many others don't. We also have the ability to base policy on as-macro. Unfortunately too many as-macros simply list all AS a provider is in any way associated with and are not useful for infering policy. Dante is an exception here (as is BBN and a few others in the US).
- the effort to reduce redundancies and remove old data is continuing. This is most notable on the route objects. Their overall number in the RIPE database declines.
We do have code to clean up any prefix based policy exceptions that existed simply to work around route objects registered with bogus origin AS and having policy differing from the origin AS that they in reality no longer had anything to do with. Our aut-num is getting smaller due to this cleanup. Thank you to those who are making this information more accurate.
5a.Exponential route flap dampening
[ ... ]
it would then be difficult to change them if need arises. A further clarifi- cation among DK and PL stated that dampening is applied to outbound updates only.
Route flap dampenning should be applied only to EBGP and probably EBGP inbound only, except for a small fixed delay. If you delay EBGP inbound, you should supress all consideration of the route, including at the immediate hop so the AS path propogated further is consistent. Delaying propogation of IBGP unevenly can result in route loops. Delaying outbound EBGP announcement more than a brief fixed delay will result in inconsistent announcement downstream due to some border routers dampenning at different rates if the next best route is announced in place of a flapping preferred route. Route withdrawl should be prpogated faster than route announcement. If someone tells you they can't get somewhere, delaying propogation of the announcement makes you a blck hole. If you delay propogation of the "up" announcement, alternate paths will be used, plus the delay will make sure the forwarding path you are advertising has converged. Curtis