Jeff, Tony,
>From: Tony Li >Sent: Wednesday, May 09, 2012 10:33 PM > >On May 9, 2012, at 3:29 PM, Jeffrey Haas wrote: > >>> Thank you. This seems to indicate that after a g-shut event, the neighbor >would continue to advertise the prefixes to its peers (albeit tagged with the >community). Wouldn't this cause non-updated routers to blackhole traffic? >What happens when only half of you IBGP peers are updated? >>> >>> If the peering doesn't come back for an extended period, couldn't this cause >traffic to transit and then be blackholed, assuming there are no alternate >paths? >>> >>> This is violating BGP's fundamental principle: "Advertise what you're using, >use what you advertise." It seems like black holes are inevitable. >> >> Please see the other clarification I posted. Graceful shutdown is applied >> to the routes from the peer that is sending bad updates that are accepted >> and valid. Routes that contain errors are processed with the stated "treat >> as withdraw" behavior. >> >> In other words, the goal is to remove the bad neighbor's valid routes from >> the forwarding path as much as possible since that neighbor is presumed to >> possibly crazy. > > >Jeff, > >Understood. I have no issues with withdrawn routes. The issue is with g-shut >routes that continue to sink traffic. In iBGP, as per my previous clarification, I don't see an issue within the AS de-preferencing the routes received from the "bad" eBGP peer: - if there is a backup path, it will be used. Fine. - otherwise, it may be better to still use the routes learnt from a valid UPDATE. In eBGP, however, IMO Tony has a point for upstream ASes (next ASes from the BGP propagation point of view). There is no guaranty that they will understand the g-shut community. Hence they will not de-preference the route and may still use the suspicious routes even if they have an alternate path. Then it's a question of how much we trust those routes. If we believe they are reasonable, we could still advertise them to upstream AS (this is only for the case where is no a valid backup path as those path have a low local_pref). Otherwise, we could add the NO_EXPORT community to avoid propagating that path to others ASes. Regards, Bruno >Tony > >_______________________________________________ >GROW mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/grow _________________________________________________________________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
