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/routing-wg@ripe.net/
[routing-wg] IETF last call on making flap damping usable
- Previous message (by thread): [routing-wg] IETF last call on making flap damping usable
- Next message (by thread): [routing-wg] Weekly Routing Table Report
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Saku Ytti
saku at ytti.fi
Thu Sep 5 11:12:15 CEST 2013
On (2013-09-05 08:05 +0900), Randy Bush wrote: > > For info, an Internet Draft by Randy and colleagues on flap damping is > > currently in last call at the IETF: > > > > <http://www.ietf.org/mail-archive/web/idr/current/msg12365.html> > > > > The draft is here: > > > > <http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-03> > > and essentially says what ripe-580 says Obviously lot of real academic work went into this, much appreciated and many thanks to Randy and other authors for it. Operational sentiments indicate that there is very little desire for people to actually run it or to consider RIPE-580 as BCP. Operators are not very worried about control-plane CPU use due to flapping BGP prefixes, we're more worried about customer having path via competitor to somewhere and not via us. What I believe would be more successful amongst operators would be not to suppress but to penalize (e.g. local-pref?) flapping routes. I'd love to see some work put into it. It would have network stabilizing effect when stable paths exists and for path where stable path do not exist you'd still offer connectivity when it is possible. -- ++ytti
- Previous message (by thread): [routing-wg] IETF last call on making flap damping usable
- Next message (by thread): [routing-wg] Weekly Routing Table Report
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]