This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg]Draft doc proposing Route Flap Damping Obsolesence
- Previous message (by thread): [routing-wg]Draft doc proposing Route Flap Damping Obsolesence
- Next message (by thread): [routing-wg]Draft doc proposing Route Flap Damping Obsolesence
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Geoff Huston
gih at apnic.net
Sat Apr 29 11:21:11 CEST 2006
I suspect that the generousity needs to be over time - i.e. route flap during convergence is normal and you may see a burst over some minutes (details can be dredged out of update logs). I suspect that we need more think time here, and perhaps some more investigation - what we don't want is to simply generate more NOC calls to manually undamp routes, so where and how route propagation supression should be applied deserves some considerable thought. Geoff At 03:58 AM 29/04/2006, Rob Evans wrote: >>i suggested that the rfd spec be modified, at least to be per-prefix as >>opposed to prefix+path, to allow the disaster prefixes to be easily >>detected and damped. > >I get the impression from RFC2439 (sec. 4.4.3) that the authors intended >it would be optional for the path to be included in the per-route state, >so perhaps some vendor pressure to implement the relevant knob? Or am I >missing some other aspect of the document? > >Then the pathological prefixes could be damped by using some "generous" >parameters that most prefixes would never reach in even the most severe >circumstances. > >Is that the idea? > >Rob >
- Previous message (by thread): [routing-wg]Draft doc proposing Route Flap Damping Obsolesence
- Next message (by thread): [routing-wg]Draft doc proposing Route Flap Damping Obsolesence
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]