This should not overwhelm a router. However, a more serious consequence is a lot of flapping routes. Serious enough to consider. We could dust off some dampening code for it.
Note the previous discussion was about repeated "treat as withdraw" errors. I support the use of an operational message for these errors, but nothing for repetitions of them. Repeated operational messages may get annoying, but they are not going to disrupt service. -- Jakob Heitz. On Apr 16, 2012, at 2:05 AM, "Rob Shakir" <r...@rob.sh> wrote: > > On 16 Apr 2012, at 04:22, Jakob Heitz wrote: > >> IMO >> 1. Error handling must be simple, lest we have to handle errors >> of the error handling, ad infinitum... >> >> 2. Error handling should be restricted to error isolation >> and reporting. It should refrain from attempting error recovery. >> >> If an error can be isolated to a set of NLRI, withdraw them. >> If an error can only be isolated to a session, reset it. >> >> Tracking and analysing multiple errors to decide on a reset >> violates point 1. > > Hi Jakob, > > I agree with this, but would like to clarify something here. > > I think that there is a requirement to ensure that we do not overwhelm the > resources of a particular PE by constant session restarts. If one were to > implement NOTIFICATION-based G-R, when do you stop trying to G-R and instead > assume that there is something that is not going to go away on the other side? > > If the answer is "never", then I guess the requirement outlined in the > section I'm discussing is moot. However, from my POV, there's definitely a > need to say that at some point my box should stop trying to expend effort > fixing things (hence the original wording with 'hold up', and now the > discussion of 'shutdown and back off'). > > Cheers > r. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
