(decision process phases 1 and 2).   An implementation MAY also (based on local configuration) alter the   value of the MULTI_EXIT_DISC attribute received over an external   link.  If it does so, it shall do so prior to determining the degree   of preference of the route and performing route selection (decision   process phases 1 and 2).5.1.5   LOCAL_PREF   LOCAL_PREF is a well-known mandatory attribute that SHALL be included   in all UPDATE messages that a given BGP speaker sends to the other   internal peers. A BGP speaker SHALL calculate the degree of   preference for each external route and include the degree of   preference when advertising a route to its internal peers. The higher   degree of preference MUST be preferred. A BGP speaker shall use the   degree of preference learned via LOCAL_PREF in its decision process   (see section 9.1.1).   A BGP speaker MUST NOT include this attribute in UPDATE messages that   it sends to external peers.  If it is contained in an UPDATE message   that is received from an external peer, then this attribute MUST be   ignored by the receiving speaker.5.1.6   ATOMIC_AGGREGATE   ATOMIC_AGGREGATE is a well-known discretionary attribute.  If a BGP   speaker, when presented with a set of overlapping routes from one of   its peers (see 9.1.4), selects the less specific route without   selecting the more specific one, then the local system MUST attach   the ATOMIC_AGGREGATE attribute to the route when propagating it to   other BGP speakers (if that attribute is not already present in the   received less specific route). A BGP speaker that receives a route   with the ATOMIC_AGGREGATE attribute MUST NOT remove the attribute   from the route when propagating it to other speakers. A BGP speaker   that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT   make any NLRI of that route more specific (as defined in 9.1.4) when   advertising this route to other BGP speakers.  A BGP speaker that   receives a route with the ATOMIC_AGGREGATE attribute needs to be   cognizant of the fact that the actual path to destinations, as   specified in the NLRI of the route, while having the loop-free   property, may traverse ASs that are not listed in the AS_PATH   attribute.Expiration Date July 2001                                      [Page 24]RFC DRAFT                                                   January 20015.1.7   AGGREGATOR   AGGREGATOR is an optional transitive attribute which may be included   in updates which are formed by aggregation (see Section 9.2.4.2).  A   BGP speaker which performs route aggregation may add the AGGREGATOR   attribute which shall contain its own AS number and IP address.6.  BGP Error Handling.   This section describes actions to be taken when errors are detected   while processing BGP messages.   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.  If no   Error Subcode is specified, then a zero must be used.   The phrase "the BGP connection is closed" means that the transport   protocol connection has been closed and that all resources for that   BGP connection have been deallocated.  Routing table entries   associated with the remote peer are marked as invalid.  The fact that   the routes have become invalid is passed to other BGP peers before   the routes are deleted from the system.   Unless specified explicitly, the Data field of the NOTIFICATION   message that is sent to indicate an error is empty.6.1 Message Header error handling.   All errors detected while processing the Message Header are indicated   by sending the NOTIFICATION message with Error Code Message Header   Error.  The Error Subcode elaborates on the specific nature of the   error.   The expected value of the Marker field of the message header is all   ones if the message type is OPEN.  The expected value of the Marker   field for all other types of BGP messages determined based on the   presence of the Authentication Information Optional Parameter in the   BGP OPEN message and the actual authentication mechanism (if the   Authentication Information in the BGP OPEN message is present). If   the Marker field of the message header is not the expected one, then   a synchronization error has occurred and the Error Subcode is set to   Connection Not Synchronized.Expiration Date July 2001                                      [Page 25]RFC DRAFT                                                   January 2001   If the Length field of the message header is less than 19 or greater   than 4096, or if the Length field of an OPEN message is less  than   the minimum length of the OPEN message, or if the Length field of an   UPDATE message is less than the minimum length of the UPDATE message,   or if the Length field of a KEEPALIVE message is not equal to 19, or   if the Length field of a NOTIFICATION message is less than the   minimum length of the NOTIFICATION message, then the Error Subcode is   set to Bad Message Length.  The Data field contains the erroneous   Length field.   If the Type field of the message header is not recognized, then the   Error Subcode is set to Bad Message Type.  The Data field contains   the erroneous Type field.6.2 OPEN message error handling.   All errors detected while processing the OPEN message are indicated   by sending the NOTIFICATION message with Error Code OPEN Message   Error.  The Error Subcode elaborates on the specific nature of the   error.   If the version number contained in the Version field of the received   OPEN message is not supported, then the Error Subcode is set to   Unsupported Version Number.  The Data field is a 1-octet unsigned   integer, which indicates the largest locally supported version number   less than the version the remote BGP peer bid (as indicated in the   received OPEN message).   If the Autonomous System field of the OPEN message is unacceptable,   then the Error Subcode is set to Bad Peer AS.  The determination of   acceptable Autonomous System numbers is outside the scope of this   protocol.   If the Hold Time field of the OPEN message is unacceptable, then the   Error Subcode MUST be set to Unacceptable Hold Time.  An   implementation MUST reject Hold Time values of one or two seconds.   An implementation MAY reject any proposed Hold Time.  An   implementation which accepts a Hold Time MUST use the negotiated   value for the Hold Time.   If the BGP Identifier field of the OPEN message is syntactically   incorrect, then the Error Subcode is set to Bad BGP Identifier.   Syntactic correctness means that the BGP Identifier field represents   a valid IP host address.   If one of the Optional Parameters in the OPEN message is notExpiration Date July 2001                                      [Page 26]RFC DRAFT                                                   January 2001   recognized, then the Error Subcode is set to Unsupported Optional   Parameters.   If the OPEN message carries Authentication Information (as an   Optional Parameter), then the corresponding authentication procedure   is invoked.  If the authentication procedure (based on Authentication   Code and Authentication Data) fails, then the Error Subcode is set to   Authentication Failure.6.3 UPDATE message error handling.   All errors detected while processing the UPDATE message are indicated   by sending the NOTIFICATION message with Error Code UPDATE Message   Error.  The error subcode elaborates on the specific nature of the   error.   Error checking of an UPDATE message begins by examining the path   attributes.  If the Unfeasible Routes Length or Total Attribute   Length is too large (i.e., if Unfeasible Routes Length + Total   Attribute Length + 23 exceeds the message Length), then the Error   Subcode is set to Malformed Attribute List.   If any recognized attribute has Attribute Flags that conflict with   the Attribute Type Code, then the Error Subcode is set to Attribute   Flags Error.  The Data field contains the erroneous attribute (type,   length and value).   If any recognized attribute has Attribute Length that conflicts with   the expected length (based on the attribute type code), then the   Error Subcode is set to Attribute Length Error.  The Data field   contains the erroneous attribute (type, length and value).   If any of the mandatory well-known attributes are not present, then   the Error Subcode is set to Missing Well-known Attribute.  The Data   field contains the Attribute Type Code of the missing well-known   attribute.   If any of the mandatory well-known attributes are not recognized,   then the Error Subcode is set to Unrecognized Well-known Attribute.   The Data field contains the unrecognized attribute (type, length and   value).   If the ORIGIN attribute has an undefined value, then the Error   Subcode is set to Invalid Origin Attribute.  The Data field containsExpiration Date July 2001                                      [Page 27]RFC DRAFT                                                   January 2001   the unrecognized attribute (type, length and value).   If the NEXT_HOP attribute field is syntactically incorrect, then the   Error Subcode is set to Invalid NEXT_HOP Attribute.  The Data field   contains the incorrect attribute (type, length and value).  Syntactic   correctness means that the NEXT_HOP attribute represents a valid IP   host address.  Semantic correctness applies only to the external BGP   links. It means that the interface associated with the IP address, as   specified in the NEXT_HOP attribute, shares a common subnet with the   receiving BGP speaker and is not the IP address of the receiving BGP   speaker.  If the NEXT_HOP attribute is semantically incorrect, the   error should be logged, and the the route should be ignored.  In this   case, no NOTIFICATION message should be sent.   The AS_PATH attribute is checked for syntactic correctness.  If the   path is syntactically incorrect, then the Error Subcode is set to   Malformed AS_PATH.   The information carried by the AS_PATH attribute is checked for AS   loops. AS loop detection is done by scanning the full AS path (as   specified in the AS_PATH attribute), and checking that the autonomous   system number of the local system does not appear in the AS path. If   the autonomous system number appears in the AS path the route may be   stored in the Adj-RIB-In, but unless the router is configured to   accept routes with its own autonomous system in the AS path, the   route shall not be passed to the BGP Decision Process.  Operations of   a router that is configured to accept routes with its own autonomous   system number in the AS path are outside the scope of this document.   If an optional attribute is recognized, then the value of this   attribute is checked.  If an error is detected, the attribute is   discarded, and the Error Subcode is set to Optional Attribute Error.   The Data field contains the attribute (type, length and value).   If any attribute appears more than once in the UPDATE message, then   the Error Subcode is set to Malformed Attribute List.   The NLRI field in the UPDATE message is checked for syntactic   validity.  If the field is syntactically incorrect, then the Error   Subcode is set to Invalid Network Field.   An UPDATE message that contains correct path attributes, but no NLRI,   shall be treated as a valid UPDATE message.Expiration Date July 2001                                      [Page 28]RFC DRAFT                                                   January 20016.4 NOTIFICATION message error handling.   If a peer sends a NOTIFICATION message, and there is an error in that   message, there is unfortunately no means of reporting this error via   a subsequent NOTIFICATION message.  Any such error, such as an   unrecognized Error Code or Error Subcode, should be noticed, logged   locally, and brought to the attention of the administration of the   peer.  The means to do this, however, lies outside the scope of this   document.6.5 Hold Timer Expired error handling.   If a system does not receive successive KEEPALIVE and/or UPDATE   and/or NOTIFICATION messages within the period specified in the Hold   Time field of the OPEN message, then the NOTIFICATION message with   Hold Timer Expired Error Code must be sent and the BGP connection   closed.6.6 Finite State Machine error handling.   Any error detected by the BGP Finite State Machine (e.g., receipt of   an unexpected event) is indicated by sending the NOTIFICATION message   with Error Code Finite State Machine Error.6.7 Cease.   In absence of any fatal errors (that are indicated in this section),   a BGP peer may choose at any given time to close its BGP connection   by sending the NOTIFICATION message with Error Code Cease.  However,   the Cease NOTIFICATION message must not be used when a fatal error   indicated by this section does exist.6.8 Connection collision detection.