"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: Tony Li [mailto:[email protected]] >Sent: Thursday, January 03, 2013 4:15 PM >To: Smith, Donald >Cc: 'Jeff Wheeler'; '[email protected]'; '[email protected]' >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error-handling-06.txt > > >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. Agreed. > > >> 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. > > Understood on over runs or under runs (length errors). I am not sure that is true for ALL other issues. Such as the recent issue where the attribute had non-zero bits in the lower nibble. >>> 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. Agreed I now have bad data (incorrect or incomplete) from one peer but everything else is still working. I haven't flapped the session. Now I have to talk to that peer (assuming this is noticed via syslog or snmp or something). Or that peer calls us and says "why aren't you propagating this announcement" and we begin joint AS troubleshooting. That is probably the best solution:) > >If, on the other hand, you withdraw that prefix, then any alternate >connectivity for that prefix can come into play. That makes sense and in big ISPs there will nearly always be another path. > >In short, treat-as-withdraw is a fail safe approach. Ignoring updates >is not. But in a peering world you have potentially just withdrawn all of your routes to a peer from that peer. You will now prefer some other peer for all of that peers traffic (or another connection to that peer in another location). If you can ignore a single update error from a peer while you troubleshoot the issue with that peer it would allow a better path for the rest of that peers announcements. Again anything with a overrun or under run issue sort of implies the rest of the updates from that point forward are corrupted/untrustworthy. Can you detect overrun and under runs without FPs or FNs? Probably not in all cases. > >Tony _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
