The loop occurs because of an error in the update message: The AS path was missing. The receiving router "handled" the error and propagated it.
I just gave you an example of how slippery the error handling slope can be. Please don't lose perspective. Error handling should be simple. I don't want to trust anything from a buggy router. However, it has been shown that dropping everything from a router because of a small bug is too severe. Therefore, I'm prepared to accept the additional rule: If an error can be isolated to a set of prefixes, withdraw only the prefixes, and send an operational message. Nothing more. On Wednesday, May 09, 2012 3:12 AM, bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> wrote: > Jakob, > > Thanks for your example. > > For sure, if a router (partially) erase the AS PATH, we can have > loops. So far, I don't see how this is related to BGP error handling, > not to mention to Jeff proposition. > > In more details, is B configured to enforce first AS? > - if so, it should detect the error and react. As per > draft-ietf-idr-error-handling I guess it should treat as withdraw. I > don't see the issue. Or are you considering a case of two different > bugs in two consecutive routers (A & B)? > - if not, well, the loop is the current BGP behavior. Not specific > to BGP error handling as no router see an error. > > > Or eventually, we have a different reading of Jeff proposal. I > understood that the proposition is to use as last resort the routes > received _before_ the BGP error (i.e. valid routes received through a > valid BGP UPDATE but which would be implicitly withdrawn with the BGP > notification). Not route from the invalid BGP UPDATE. > > Regards, > Bruno > >> From: Jakob Heitz [mailto:jakob.he...@ericsson.com] Sent: Wednesday, >> May 09, 2012 10:10 AM >> >> A has a route learnt from C. >> A configures a long AS path prepend, but because of a bug activated >> by >> a too long AS path, it sends no AS path. B receives it, >> but does not withdraw the route. It announces the route to C. >> C had a better route before, but due to policy did not >> announce it to B. C starts sending traffic to B. >> B send to A. A sends to C. loop. >> >> Here is the way: >> If you can isolate an error to a set of routes withdraw them. >> If not, drop the session and withdraw all routes from it. >> RFD takes care of flapping sessions. >> >> On Wednesday, May 09, 2012 12:37 AM, bruno.decra...@orange.com >> <mailto:bruno.decra...@orange.com> wrote: >> >>> From: grow Jakob Heitz Sent: Wednesday, May 09, 2012 3:08 AM >>>> On Monday, May 07, 2012 10:58 AM, Jeffrey Haas <> wrote: >>>> >>>>> On Fri, Apr 13, 2012 at 07:27:36PM +0100, Rob Shakir wrote: >>>>>> I'd like to ask the WG their collective opinion on a couple of >>>>>> matters in this draft, which come from some discussions at IETF83 >>>>>> (in particular with John Scudder and Adam Simpson) about how the >>>>>> requirements are currently written regarding repeated errors. >>>>> >>>>> In reviewing this thread, there's another possible tool we could >>>>> leverage. The consensus seems to be trending toward "if the >>>>> session is bad enough, take it down. Potentially hold it down if >>>>> it continues to be bad." >>>>> >>>>> An alternative before you get to such a stage is to perform BGP >>>>> graceful shutdown procedures on the session's routes. This >>>>> permits the routes to be routes of last resort until the issue is >>>>> dealt with. >>>> >>>> That raises the possibility that the routes are actually used. >>>> That may cause loops. >>> >>> Would you mind sharing an example of such loops following an eBGP >>> session failure? That would help me. (Hopefully some others). >>> >>> Thanks, >>> Bruno >>> >>> >>> >> _______________________________________________________________________________ >> __________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>> avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages electroniques etant susceptibles d'alteration, France >>> Telecom - Orange decline toute responsabilite si ce message a ete >>> altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; >>> they should not be distributed, used or copied without >>> authorisation. If you have received this email in error, please >>> notify the sender and delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. Thank you. >> >> >> >> -- >> Jakob Heitz. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
