* Christopher Morrow:
(you are asking your vendors to run full bit sweeps of each protocol in a regimented manner checking for all possible edge cases and properly handling them, right?)
The real issue is that both spec and current practice say you need to drop the session as soon as you encounter any unexpected data. That's just wrong---you can't really be sure that it's a temporary glitch caused by your peer. If it's not, you are unnecessarily taking yourself off the net. Of course, there is little you can do when the outer framing at the internal BGP layer is wrong (resyncing is way too risky). A tear-down might be in order if you receive an unrecognized message type, too. But a BGP update message which is malformed internally should just be ignored. From a theoretical point of view, it's no worse than the operator configuring a prefix-list that filters out all the NLRI entries.