"Pampers use multiple layers of protection to prevent leakage. Rommel used defense in depth to defend European fortresses." (A.White) [email protected]
>-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Tony Li >Sent: Thursday, January 03, 2013 3:31 PM >To: Jeff Wheeler >Cc: [email protected]; [email protected] >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error-handling-06.txt > > >On Jan 3, 2013, at 2:15 PM, Jeff Wheeler <[email protected]> wrote: > >>>> However bad or difficult to clean up, what if that's not as bad as >the >>>> alternative ? >>> >>> Clearly, the treat-as-withdraw alternative is better. You're not >leaving bogus state in the rest of the network. >> >> Does this mean you support treat-as-withdraw, even though you dislike >> its high complexity? My read of your postings today is that you >> dislike the whole error-handling idea. > > >Jeff, > >I support the general concept of improved error handling and softer >failures when possible. > >As I've said before, errors can be reasonably classified into two >groups: syntactic and semantic. > >A syntactic error would be any inconsistency of length fields, >incompatibility between a type and a length, or any other error that >would introduce any doubt about the parsing of the message. Once this >type of error has occurred, then the remainder of the data stream is >wholly in doubt. 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. Other than getting it noticed I doubt a reset will ever make a misbehaving router stop misbehaving. > >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? >This would seem reasonable. > >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:) This is what happened recently. ALU announced attributes with 1 bit set that others didn't understand. If the routers that didn't understand that bit could have ignored just that element everything would have been fine. > >Tony > >_______________________________________________ >GROW mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
