Some readers have been writing in saying they are seeing parts of their network drop peering for “unknown reasons”. The reason is that Saudi Telecom was sending out routes with invalid attribute #128 (a private attribute).

NANOG posting showing private attribute discussion.
http://www.gossamer-threads.com/lists/nanog/users/144466
This was triggering a Juniper peering issue the PSN information below requires a juniper login.
http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2011-09-380&actionBtn=Search
Juniper is (was) following RFC 4274 http://www.ietf.org/rfc/rfc4271
“When any of the conditions described here are detected, a
   NOTIFICATION message, with the indicated Error Code, Error Subcode,
   and Data fields, is sent, and the BGP connection is closed (unless it
   is explicitly stated that no NOTIFICATION message is to be sent and
   the BGP connection is not to be closed).  If no Error Subcode is
   specified, then a zero MUST be used.”

Starting with Junos 10.2, Juniper added the ability to allow you to
completely ignore or drop the path attributes of your choice:

http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuration/bgp-drop-path-attributes-configuring.html
http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuration/bgp-ignore-path-attributes-configuring.html

There is some fairly new work being done in an IETF routing working group to allow for minor miscommunication between peers without dropping the session and all of your neighbors routes. It is still early but given the issues we have seen with things like this lately it is a good step forward as is Juniper's new abilities.