Hi Donald, >> A session reset seems like the only (conservative) way >> of handling this, as it's unclear that further data would be accurate. > I disagree. Does a session reset fix the issue? It hasn't the last few times > I have seen this. > It exasperated it by causing peers to drop and having to rebuild ribs/fibs > etc... continuously.
Which is why I suggested that re-opening the connection is perhaps not optimal. > Other than getting it noticed I doubt a reset will ever make a misbehaving > router stop misbehaving. The point is that once you've lost context in the data stream, subsequent messages cannot be accepted with a reasonable certainty of correct parsing. >> I'm very open to a discussion of alternatives to session flap for these >> cases. Should we require manual intervention before session restart? > Manual intervention will be required in most cases but if we "require" manual > intervention haven't we left the programming side (state machine) and gone > into the operational control side of things? Correct. The programming side has failed. As you note, trying again is not likely to help. Adding Artificial Intelligence to BGP to recover is unlikely to be effective or an efficient means of making progress. >> Semantic errors would be consistency violations within the contents of >> the message. In these cases, treat-as-withdraw seems reasonable. > I would also like the ignore option here. You know your neighbor is saying > something you don't understand, possibly due to a lack of in your vocabulary > but you understand other elements so you nod and continue listening to the > rest:) The entire problem with the ignore option is that it leaves bogus information in the network. Suppose that the update contains an AS path change for a prefix. If you ignore the update, then you ignore that path change, AND, you fail to propagate that change to your upstream neighbors. Now, BGP's loop prevention mechanism is out the window and, in the worst case, you've created an inter-domain forwarding loop. If, on the other hand, you withdraw that prefix, then any alternate connectivity for that prefix can come into play. In short, treat-as-withdraw is a fail safe approach. Ignoring updates is not. Tony _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
