Connected: An Internet Encyclopedia
RFC 1771 - 9. UPDATE Message Handling

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1771
Prev: 8. BGP Finite State machine.
Next: 9.1 Decision Process

### 9. UPDATE Message Handling

An UPDATE message may be received only in the Established state. When an UPDATE message is received, each field is checked for validity as specified in Section 6.3.

If an optional non-transitive attribute is unrecognized, it is quietly ignored. If an optional transitive attribute is unrecognized, the Partial bit (the third high-order bit) in the attribute flags octet is set to 1, and the attribute is retained for propagation to other BGP speakers.

If an optional attribute is recognized, and has a valid value, then, depending on the type of the optional attribute, it is processed locally, retained, and updated, if necessary, for possible propagation to other BGP speakers.

If the UPDATE message contains a non-empty WITHDRAWN ROUTES field, the previously advertised routes whose destinations (expressed as IP prefixes) contained in this field shall be removed from the Adj-RIB- In. This BGP speaker shall run its Decision Process since the previously advertised route is not longer available for use.

If the UPDATE message contains a feasible route, it shall be placed in the appropriate Adj-RIB-In, and the following additional actions shall be taken:

1. If its Network Layer Reachability Information (NLRI) is identical to the one of a route currently stored in the Adj-RIB-In, then the new route shall replace the older route in the Adj-RIB-In, thus implicitly withdrawing the older route from service. The BGP speaker shall run its Decision Process since the older route is no longer available for use.

2. If the new route is an overlapping route that is included (see 9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP speaker shall run its Decision Process since the more specific route has implicitly made a portion of the less specific route unavailable for use.

3. If the new route has identical path attributes to an earlier route contained in the Adj-RIB-In, and is more specific (see 9.1.4) than the earlier route, no further actions are necessary.

4. If the new route has NLRI that is not present in any of the routes currently stored in the Adj-RIB-In, then the new route shall be placed in the Adj-RIB-In. The BGP speaker shall run its Decision Process.

5. If the new route is an overlapping route that is less specific (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the BGP speaker shall run its Decision Process on the set of destinations described only by the less specific route.

9.1 Decision Process

9.1.1 Phase 1: Calculation of Degree of Preference
9.1.2 Phase 2: Route Selection

9.1.2.1 Breaking Ties (Phase 2)

9.1.3 Phase 3: Route Dissemination
9.1.4 Overlapping Routes

9.2 Update-Send Process

9.2.1 Internal Updates

9.2.1.1 Breaking Ties (Internal Updates)

9.2.2 External Updates
9.2.3 Controlling Routing Traffic Overhead

9.2.3.1 Frequency of Route Advertisement
9.2.3.2 Frequency of Route Origination
9.2.3.3 Jitter

9.2.4 Efficient Organization of Routing Information

9.2.4.1 Information Reduction
9.2.4.2 Aggregating Routing Information

9.3 Route Selection Criteria
9.4 Originating BGP routes

Next: 9.1 Decision Process

Connected: An Internet Encyclopedia
RFC 1771 - 9. UPDATE Message Handling