draft-ietf-idr-bgp4-13.txt

BCAST Implementation for NS2

         speaker should use in the NEXT_HOP attribute the IP address
         that is used to establish the BGP session.

   Normally the NEXT_HOP attribute is chosen such that the shortest
   available path will be taken. A BGP speaker must be able to support
   disabling advertisement of third party NEXT_HOP attributes to handle
   imperfectly bridged media.

   A BGP speaker must never advertise an address of a peer to that peer
   as a NEXT_HOP, for a route that the speaker is originating. A BGP



Expiration Date March 2002                                     [Page 23]





RFC DRAFT                                                 September 2001


   speaker must never install a route with itself as the next hop.

   The NEXT_HOP attribute is used by the BGP speaker to determine the
   actual outbound interface and immediate next-hop address that should
   be used to forward transit packets to the associated destinations.
   The immediate next-hop address is determined by performing a
   recursive route lookup operation for the IP address in the NEXT_HOP
   attribute using the contents of the Routing Table (see Section
   9.1.2.2). The resolving route will always specify the outbound
   interface. If the resolving route specifies the next-hop address,
   this address should be used as the immediate address for packet
   forwarding. If the address in the NEXT_HOP attribute is directly
   resolved through a route to an attached subnet (such a route will not
   specify the next-hop address), the outbound interface should be taken
   from the resolving route and the address in the NEXT_HOP attribute
   should be used as the immediate next-hop address.


5.1.4 MULTI_EXIT_DISC


   The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
   neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four
   octet unsigned number which is called a metric. All other factors
   being equal, the exit point with lower metric should be preferred. If
   received over external links, the MULTI_EXIT_DISC attribute MAY be
   propagated over internal links to other BGP speakers within the same
   AS. The MULTI_EXIT_DISC attribute received from a neighboring AS MUST
   NOT be propagated to other neighboring ASs.

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (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



Expiration Date March 2002                                     [Page 24]





RFC DRAFT                                                 September 2001


   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 based on the locally configured
   policy, 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, except for the case of BGP Confederations
   [13]. 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, except for the case of BGP Confederations [13].


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.


5.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. The
   IP address should be the same as the BGP Identifier of the speaker.






Expiration Date March 2002                                     [Page 25]





RFC DRAFT                                                 September 2001


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, the associated Adj-RIB-In has
   been cleared, and that all resources for that BGP connection have
   been deallocated. Entries in the Loc-RIB 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.

   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



Expiration Date March 2002                                     [Page 26]





RFC DRAFT                                                 September 2001


   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 not
   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



Expiration Date March 2002                                     [Page 27]





RFC DRAFT                                                 September 2001


   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 Withdrawn Routes Length or Total Attribute Length
   is too large (i.e., if Withdrawn 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 contains
   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



Expiration Date March 2002                                     [Page 28]





RFC DRAFT                                                 September 2001


   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 (unless the speaker has been configured to run
   the external BGP session over multiple IP hops), 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 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