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. _________________________________________________________________________________________________________________________ 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. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
