Re: draft minutes of routing wg session RIPE24 (22-04-96)

[Curtis Villamizar <]

Thanks for the minutes.  Some comments.

In message <9605091017.AA28975@localhost>, 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