tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4276

 
 
 

BGP-4 Implementation Report

Part 4 of 4, p. 67 to 97
Prev RFC Part

 


prevText      Top      Up      ToC       Page 67 
3.36.  UPDATE Message Handling / Section 9 [RFC4271]

   3.36.183.  UPDATE Message Handling

       Functionality/Description: Does your implementation handle
       UPDATE messages in a manner compatible to the description in
       this section?

       RFC2119: N/A

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 68 
   3.36.184.  WITHDRAWN ROUTES

       Functionality/Description: Any previously advertised routes
       whose destinations are contained in this field SHALL be removed
       from the Adj-RIB-In

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.36.185.  WITHDRAWN ROUTES

       Functionality/Description: The BGP speaker SHALL run its
       Decision Process since the previously advertised route is no
       longer available for use

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.36.186.  Implicit Withdraw

       Functionality/Description: If an UPDATE message contains a
       feasible route, and the NLRI of the new route is identical to
       the one of a route currently stored in the Adj-RIB-In, then the
       new route SHALL replace the older route

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 69 
   3.36.187.  Other Feasible Routes

       Functionality/Description: If an UPDATE message contains a
       feasible route, and the NLRI of the new route is not identical
       to the one of any route currently stored in the Adj-RIB-In, then
       the new route SHALL be placed in the Adj-RIB-In

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.36.188.  Adj-RIB-In Update

       Functionality/Description: Once a BGP speaker updates the
       Adj-RIB-In, it SHALL run its Decision Process

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.37.  Decision Process / Section 9.1 [RFC4271]

   3.37.189.  Decision Process

       Functionality/Description: Is your implementation compatible
       with the description in this section?

       RFC2119: N/A

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 70 
   3.37.190.  Degree of Preference

       Functionality/Description: SHALL NOT use as its inputs any of
       the following: the existence of other routes, the non-existence
       of other routes, or the path attributes of other routes

       RFC2119: SHALL NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.38.  Phase 1: Calculation of Degree of Preference / Section 9.1.1
       [RFC4271]

   3.38.191.  Ineligible Degree of Preference

       Functionality/Description: The route MAY NOT serve as an input
       to the next phase of route selection

       RFC2119: MAY NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.38.192.  Eligible Degree of Preference

       Functionality/Description: Used as the LOCAL_PREF value in any
       IBGP re-advertisement

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 71 
3.39.  Phase 2: Route Selection / Section 9.1.2 [RFC4271]

   3.39.193.  Unresolvable NEXT_HOP

       Functionality/Description: If the NEXT_HOP attribute of a BGP
       route depicts an address that is not resolvable, or it would
       become unresolvable if the route was installed in the routing
       table the BGP route MUST be excluded

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.39.194.  Routes Installed in LOC-RIB

       Functionality/Description: The route in the Adj-RIBs-In
       identified as the best (see section 9.1.2) is installed in the
       Loc-RIB, replacing any route to the same destination that is
       currently being held in the Loc-RIB

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.39.195.  Immediate Next-Hop Address

       Functionality/Description: MUST be determined from the NEXT_HOP
       attribute of the selected route (see Section 5.1.3)

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 72 
   3.39.196.  Phase 2: Route Selection

       Functionality/Description: Performed again if either the
       immediate next hop or the IGP cost to the NEXT_HOP changes

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.39.197.  Immediate Next-Hop Address


   Functionality/Description: Used for packet forwarding

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.39.198.  Unresolvable Routes

       Functionality/Description: Removed from the Loc-RIB and the
       routing table

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 73 
   3.39.199.  Unresolvable Routes

       Functionality/Description: Kept in the corresponding Adj-RIBs-In

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.40.  Route Resolvability Condition / Section 9.1.2.1 [RFC4271]

   3.40.200.  Unresolvable Routes

       Functionality/Description: Excluded from the Phase 2 decision

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.40.201.  Multiple Matching Routes

       Functionality/Description: Only the longest matching route
       SHOULD be considered

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 74 
   3.40.202.  Mutual Recursion

       Functionality/Description: If a route fails the resolvability
       check because of mutual recursion, an error message SHOULD be
       logged

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    We have checks that disallow mutual
                                    recursion, so this won't happen.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.41.  Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271]

   3.41.203.  Tie-Breaking Criteria

       Functionality/Description: Applied in the order specified

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.41.204.  Algorithm Used

       Functionality/Description: BGP implementations MAY use any
       algorithm which produces the same results as those described
       here

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 75 
   3.41.205.  MULTI_EXIT_DISC Removal

       Functionality/Description: If done before re-advertising a route
       into IBGP, then comparison based on the received EBGP
       MULTI_EXIT_DISC attribute MAY still be performed

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.41.206.  MULTI_EXIT_DISC Removal

       Functionality/Description: The optional comparison on
       MULTI_EXIT_DISC if performed at all MUST be performed only among
       EBGP learned routes

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.41.207.  MULTI_EXIT_DISC Comparison

       Functionality/Description: Performed for IBGP learned routes

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 76 
3.42.  Phase 3: Route Dissemination / Section 9.1.3 [RFC4271]

   3.42.208.  Policy for processing routes from the Loc-RIB into
              Adj-RIBs-Out

       Functionality/Description: Exclude a route in the Loc-RIB from
       being installed in a particular Adj-RIB-Out

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.42.209.  Adj-Rib-Out Route Installation

       Functionality/Description: Not unless the destination and
       NEXT_HOP described by this route may be forwarded appropriately
       by the Routing Table

       RFC2119: SHALL NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.42.210.  Withdraw Routes

       Functionality/Description: If a route in Loc-RIB is excluded
       from a particular Adj-RIB-Out the previously advertised route in
       that Adj-RIB-Out MUST be withdrawn from service by means of an
       UPDATE message (see 9.2)

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 77 
3.43.  Overlapping Routes / Section 9.1.4 [RFC4271]

   3.43.211.  Overlapping Routes

       Functionality/Description: Consider both routes based on the
       configured acceptance policy

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.43.212.  Accepted Overlapping Routes

       Functionality/Description: The Decision Process MUST either
       install both routes or...

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.43.213.  Accepted Overlapping Routes

       Functionality/Description: Aggregate the two routes and install
       the aggregated route, provided that both routes have the same
       value of the NEXT_HOP attribute

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We install both in Local RIB.
       Laurel  Y/N/O/Comments: N    no automatic aggregation
       NextHop Y/N/O/Comments: N    no automatic aggregation

Top      Up      ToC       Page 78 
   3.43.214.  Aggregation

       Functionality/Description: Either include all ASs used to form
       the aggregate in an AS_SET or add the ATOMIC_AGGREGATE
       attribute to the route

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.43.215.  De-Aggregation

       Functionality/Description: Routes SHOULD NOT be de-aggregated

       RFC2119: SHOULD NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.43.216.  Route with the ATOMIC_AGGREGATE Attribute

       Functionality/Description: Not de-aggregated

       RFC2119: MUST NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 79 
3.44.  Update-Send Process / Section 9.2 [RFC4271]

   3.44.217.  UPDATE Message Received from an Internal Peer

       Functionality/Description: Not re-distribute the routing
       information to other internal peers, unless the speaker acts as
       a BGP Route Reflector [RFC2796]

       RFC2119: SHALL NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.44.218.  No Replacement Route

       Functionality/Description: All newly installed routes and all
       newly unfeasible routes for which there is no replacement route
       SHALL be advertised to its peers by means of an UPDATE message

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.44.219.  Previously Advertised Routes

       Functionality/Description: A BGP speaker SHOULD NOT advertise a
       given feasible BGP route if it would produce an UPDATE message
       containing the same BGP route as was previously advertised

       RFC2119: SHOULD NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 80 
   3.44.220.  Unfeasible Routes

       Functionality/Description: Removed from the Loc-RIB

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.44.221.  Changes to Reachable Destinations

       Functionality/Description: Changes to the reachable destinations
       within its own autonomous system SHALL also be advertised in an
       UPDATE message

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.44.222.  A single route doesn't fit into the UPDATE message

       Functionality/Description: Don't advertise

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.44.223.  A single route doesn't fit into the UPDATE message

       Functionality/Description: Log an error local

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 81 
3.45.  Frequency of Route Advertisement / Section 9.2.1.1 [RFC4271]

   3.45.224.  MinRouteAdvertisementIntervalTimer

       Functionality/Description: Minimum separation between two UPDATE
       messages sent by a BGP speaker to a peer that advertise feasible
       routes and/or withdrawal of unfeasible routes to some common set
       of destinations

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.45.225.  Fast Convergence

       Functionality/Description: MinRouteAdvertisementIntervalTimer
       used for internal peers SHOULD be shorter than the
       MinRouteAdvertisementIntervalTimer used for external peers, or

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: O    Configurable on per peer basis.
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: N    they are same for ebgp and ibgp
       NextHop Y/N/O/Comments: Y    Configuration option allows to set
                                    the time per peer.


   3.45.226.  Fast Convergence

       Functionality/Description: The procedure describes in this
       section SHOULD NOT apply for routes sent to internal peers

       RFC2119: SHOULD NOT

       Alcatel Y/N/O/Comments: O    Operator has to ensure that through
                                    configuration.
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y    Default setting is off for BGP
                                    peers.

Top      Up      ToC       Page 82 
   3.45.227.  MinRouteAdvertisementIntervalTimer

       Functionality/Description: The last route selected SHALL be
       advertised at the end of MinRouteAdvertisementIntervalTimer

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.46.  Aggregating Routing Information / Section 9.2.2.2 [RFC4271]

   3.46.228.  MULTI_EXIT_DISC

       Functionality/Description: Routes that have different
       MULTI_EXIT_DISC attribute SHALL NOT be aggregated

       RFC2119: SHALL NOT

       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y


   3.46.229.  AS_SET as the First Element

       Functionality/Description: If the aggregated route has an AS_SET
       as the first element in its AS_PATH attribute, then the router
       that originates the route SHOULD NOT advertise the
       MULTI_EXIT_DISC attribute with this route

       RFC2119: SHOULD NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 83 
   3.46.230.  NEXT_HOP

       Functionality/Description: When aggregating routes that have
       different NEXT_HOP attribute, the NEXT_HOP attribute of the
       aggregated route SHALL identify an interface on the BGP speaker
       that performs the aggregation

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.231.  ORIGIN INCOMPLETE

       Functionality/Description: Used if at least one route among
       routes that are aggregated has ORIGIN with the value INCOMPLETE

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.232.  ORIGIN EGP

       Functionality/Description: Used if at least one route among
       routes that are aggregated has ORIGIN with the value EGP

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 84 
   3.46.233.  Routes to be aggregated have different AS_PATH attributes

       Functionality/Description: The aggregated AS_PATH attribute
       SHALL satisfy all of the following conditions: ...

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.234.  Routes to be aggregated have different AS_PATH attributes

       Functionality/Description: All tuples of type AS_SEQUENCE in the
       aggregated AS_PATH SHALL appear in all of the AS_PATH in the
       initial set of routes to be aggregated

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.235.  Routes to be aggregated have different AS_PATH attributes

       Functionality/Description: All tuples of type AS_SET in the
       aggregated AS_PATH SHALL appear in at least one of the AS_PATH
       in the initial set

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 85 
   3.46.236.  Routes to be aggregated have different AS_PATH attributes

       Functionality/Description: For any tuple X of type AS_SEQUENCE
       in the aggregated AS_PATH which precedes tuple Y in the
       aggregated AS_PATH, X precedes Y in each AS_PATH in the initial
       set which contains Y, regardless of the type of Y

       RFC2119: N/A

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.237.  Routes to be aggregated have different AS_PATH attributes

       Functionality/Description: No tuple of type AS_SET with the same
       value SHALL appear more than once in the aggregated AS_PATH

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.238.  Routes to be aggregated have different AS_PATH attributes

       Functionality/Description: Multiple tuples of type AS_SEQUENCE
       with the same value may appear in the aggregated AS_PATH only
       when adjacent to another tuple of the same type and value

       RFC2119: N/A

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 86 
   3.46.239.  AS_PATH Aggregation Algorithm

       Functionality/Description: Able to perform the (minimum)
       algorithm described in 9.2.2.2.

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We don't do merging.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.240.  ATOMIC_AGGREGATE

       Functionality/Description: The aggregated route SHALL have this
       attribute if at least one of the routes to be aggregated has it

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.46.241.  AGGREGATOR

       Functionality/Description: Attribute from routes to be
       aggregated MUST NOT be included in aggregated route

       RFC2119: MUST NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 87 
   3.46.242.  AGGREGATOR

       Functionality/Description: Attach a new one when aggregating
       (see Section 5.1.7)

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.47.  Route Selection Criteria / Section 9.3 [RFC4271]

   3.47.243.  Unstable Routes

       Functionality/Description: Avoid using them

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.47.244.  Route Changes

       Functionality/Description: SHOULD NOT make rapid spontaneous
       changes to the choice of route

       RFC2119: SHOULD NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 88 
3.48.  Originating BGP Routes / Section 9.4 [RFC4271]

   3.48.245.  Non-BGP Acquired Routes

       Functionality/Description: Distributed to other BGP speakers
       within the local AS as part of the update process
       (see Section 9.2)

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.48.246.  Non-BGP Acquired Routes

       Functionality/Description: Distribution controlled via
       configuration

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.49.  BGP Timers / Section 10 [RFC4271]

   3.49.247.  Optional Timers

       Functionality/Description: Two optional timers MAY be supported:
       DelayOpenTimer, IdleHoldTimer by BGP

       RFC2119: MAY

       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    We support DelayOpenTimer but not
                                    IdleHoldTimer
       Laurel  Y/N/O/Comments: Y    support IdleHoldTimer but not the
                                    DelayOpenTimer
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 89 
   3.49.248.  Hold Time

       Functionality/Description: Configurable on a per peer basis

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.49.249.  Timers

       Functionality/Description: Allow the other timers to be
       configurable

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   3.49.250.  Jitter

       Functionality/Description: Applied to the timers associated with
       MinASOriginationInterval, KeepAlive,
       MinRouteAdvertisementInterval, and ConnectRetry

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    We only apply to ConnectRetry.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 90 
   3.49.251.  Jitter

       Functionality/Description: Apply the same jitter to each of
       these quantities regardless of the destinations to which the
       updates are being sent; that is, jitter need not be configured
       on a "per peer" basis

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y    We apply same only for connectretry.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

   3.49.252.  Default Amount of jitter

       Functionality/Description: Determined by multiplying the base
       value of the appropriate timer by a random factor which is
       uniformly distributed in the range from 0.75 to 1.0

       RFC2119: SHALL

       Alcatel Y/N/O/Comments: Y    Range is 0.9 to 1.1
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

   3.49.253.  Default Amount of jitter

       Functionality/Description: New random value picked each time the
       timer is set

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 91 
   3.49.254.  Jitter Random Value Range

       Functionality/Description: Configurable

       RFC2119: MAY

       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: N


3.50.  TCP Options that May Be Used with BGP / Appendix E [RFC4271]

   3.50.255.  TCP PUSH Function Supported

       Functionality/Description: Each BGP message SHOULD be
       transmitted with PUSH flag set

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    Depends on the TCP stack support.
                                    GateD 10, NGC can run over
                                    multiple stacks.


   3.50.256.  Differentiated Services Code Point (DSCP) Field Support

       Functionality/Description: TCP connections opened with bits 0-2
       of the DSCP field set to 110 (binary)

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    Depends on the TCP stack support.
                                    GateD 10, NGC can run over
                                    multiple stacks.

Top      Up      ToC       Page 92 
3.51.  Reducing Route Flapping / Appendix F.2 [RFC4271]

   3.51.257.  Avoid Excessive Route Flapping

       Functionality/Description: A BGP speaker which needs to withdraw
       a destination and send an update about a more specific or less
       specific route SHOULD combine them into the same UPDATE message

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: N


3.52.  Complex AS_PATH aggregation / Appendix F.6 [RFC4271]

   3.52.258.  Multiple Instances in AS_PATH

       Functionality/Description: The last instance (rightmost
       occurrence) of that AS number is kept

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: N    We use algorithm in 9.2.2.2
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: N


3.53.  Security Considerations [RFC4271]

   3.53.259.  Authentication Mechanism

       Functionality/Description: A BGP implementation MUST support
       the authentication mechanism specified in RFC 2385 [RFC2385].

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Top      Up      ToC       Page 93 
4.  Additional BGP Implementations Information

   Three implementations responded to a call (5/20/04-6/2/04) for
   information on those implementations that had a BGP implementation,
   but did not complete the full survey.  The responses for the call for
   additional information are below.

4.1.  Avici

   If you have an implementation of BGP and you did not send in an
   implementation report (answering the 259 questions), could you send
   me the answer the following questions:

   1) BGP product
      Contributor (your name):Curtis Villamizar [curtis@fictitious.org]
      Company: Avici
      name of product: IPriori (TM)
      minor version:   No interoperability problems with any version.

             Current deployed versions are 5.x and 6.0.x.
             Version 6.1 and beyond are tested against the
             latest BGP specification [RFC4271].

   2) What other implementations you interoperate with.

         Cisco: IOS 12.0(22)
         Juniper: JUNOS (version not given)

   3) Do you inter-operate with:

      1) Alcatel BGP (release) - not tested
      2) cisco BGP IOS 12.0(27)s - not tested
            tested with IOS 12.0(22); BGP is the same
      3) laurel BGP (specify release) - not tested
      4) NextHop GateD - not tested

   4) Did the length of the survey for BGP cause you to not
      submit the BGP implementation report?

      yes

Top      Up      ToC       Page 94 
4.2.  Data Connection Ltd.

   If you have an implementation of BGP and you did not send in an
   implementation report (answering the 259 questions), could you send
   me the answer the following questions:

   1) BGP product
      Contributor (your name): Mike Dell
      Company: Data Connection Ltd.
      name of product:  DC-BGP
      version and minor of software: v1.1
      release date: April 2003

   2) What other implementations you interoperate with.

         Cisco (12.0(26)S)
         Alcatal (7770 0BX)
         Agilent (Router Tester)
         Ixia (1600T)
         Netplane (Powercode)
         Nortel (Shasta 5000 BSN)
         Redback (SmartEdge 800)
         Riverstone (RS8000)
         Spirent (AX4000)
         IP Infusion (ZebOs)
         Nokia (IP400)
         Juniper (M5)

   3) Do you inter-operate with

      1) Alcatel BGP (release)      YES
      2) cisco BGP IOS 12.0(27)s
            Unknown, but we do inter-operate with v12.0(26)s
      3) laurel BGP (specify release)  Unknown
      4) NextHop GateD           YES

   4) Did the length of the survey for BGP
      cause you to not submit the BGP
      implementation report?

         YES

4.3.  Nokia

   If you have an implementation of BGP and you did not send in an
   implementation report (answering the 259 questions), could you send
   me the answer the following questions:

Top      Up      ToC       Page 95 
    1) BGP product

    Contributor (your name):Rahul Bahadur
                           (rahul.bahadur@nokia.com)
    Company:                      Nokia
    Name of product:              IP Security Platforms
    Version and minor of software IPSO 3.8 Build031
    Release date                  May 24, 2004

    2) What other implementations you interoperate with.

          Cisco: IOS 12.3(1)
          Extreme: Extremeware Version 6.1.7 (Build 9)
          Foundry: SW Version 07.5.05iT53
          Juniper: JUNOS 5.3R1.2
          Nortel: BayRS 15.4.0.1
          GNU Zebra: zebra-0.92a

   3) Do you inter-operate with

      1) Alcatel BGP (release) - not tested
      2) cisco BGP IOS 12.0(27)s - yes
      3) laurel BGP (specify release) - not tested
      4) NextHop GateD - not tested

   4) Did the length of the survey for BGP
      cause you to not submit the BGP implementation report?

          Yes - lack of resources to help with task.

5.  Security Considerations

   This document does not address any security issues.

6.  Normative References

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
              4)", RFC 1771, March 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

Top      Up      ToC       Page 96 
   [RFC2796]  Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection
              - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.

   [RFC2918]  Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
              September 2000.

   [RFC3065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
              System Confederations for BGP", RFC 3065, February 2001.

7.  Acknowledgements

   Alcatel responses provided by:
   Contact Name: Devendra Raut
   Contact EMail: Devendra.raut@Alcatel.com

   Cisco Systems responses provided by:
   Contact Name: Himanshu Shah, Ruchi Kapoor
   Contact EMail: hhshah@cisco.com, ruchi@cisco.com

   Laurel responses provided by:
   Contact Name: Manish Vora
   Contact EMail: vora@laurelnetworks.com

   NextHop responses provided by:
   Contact Name: Susan Hares
   Contact EMail: skh@nexthop.com
   Additional Help:  Matt Richardson, Shane Wright.

Authors' Addresses

   Susan Hares
   NextHop Technologies
   825 Victors Way, Suite 100
   Ann Arbor, MI 48108

   Phone: 734.222.1610
   EMail: skh@nexthop.com


   Alvaro Retana
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709

   Phone: 919 392 2061
   EMail: aretana@cisco.com

Top      Up      ToC       Page 97 
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).