draft-ietf-idr-bgp4-14.txt

BCAST Implementation for NS2

         NEXT_HOP attribute.

         - If the external peer to which the route is being advertised
         shares a common subnet with one of the announcing router's own
         interfaces, the router may use the IP address associated with
         such an interface in the NEXT_HOP attribute. This is known as a
         "first party" NEXT_HOP attribute.

         - By default (if none of the above conditions apply), the BGP
         speaker should use in the NEXT_HOP attribute the IP address of
         the interface that the speaker uses to establish the BGP
         session to peer X.

      3) When sending a message to an external peer X, and the peer is



Expiration Date April 2002                                     [Page 23]





RFC DRAFT                                                   October 2001


      multiple IP hops away from the speaker (aka "multihop EBGP"):

         - The speaker may be configured to propagate the NEXT_HOP
         attribute.  In this case when advertising a route that the
         speaker learned from one of its peers, the NEXT_HOP attribute
         of the advertised route is exactly the same as the NEXT_HOP
         attribute of the learned route (the speaker just doesn't modify
         the NEXT_HOP attribute).

         - By default, the BGP speaker should use in the NEXT_HOP
         attribute the IP address of the interface that the speaker uses
         to establish the BGP session to peer X.

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



Expiration Date April 2002                                     [Page 24]





RFC DRAFT                                                   October 2001


   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
   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. There are
   two cases where the ATOMIC_AGGREGATE attribute is used:

      - a speaker receives both more and less specific routes, these
      routes have the same NEXT_HOP, the AS_PATH attribute of the more
      specific route is different from the AS_PATH attribute of the less
      specific route, and the speaker installs in its Loc-RIB only the
      less specific route. In this case the speaker should advertise
      this route with the ATOMIC_AGGREGATE attribute to all neighbors
      (subject to the outbound route filtering).



Expiration Date April 2002                                     [Page 25]





RFC DRAFT                                                   October 2001


      - a speaker receives both more and less specific routes the
      AS_PATH attribute of the more specific route is different from the
      AS_PATH attribute of the less specific route, the speaker installs
      in its Loc-RIB both routes, but the speaker advertises to a
      particular neighbor only the less specific route. In this case the
      advertisement MUST carry the ATOMIC_AGGREGATE attribute.

   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 not be the path specified in the AS_PATH
   attribute of the route.


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.


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



Expiration Date April 2002                                     [Page 26]





RFC DRAFT                                                   October 2001


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




Expiration Date April 2002                                     [Page 27]





RFC DRAFT                                                   October 2001


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



Expiration Date April 2002                                     [Page 28]





RFC DRAFT                                                   October 2001


   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 cod