Connected: An Internet Encyclopedia
RFC 1773 - Metrics

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1773
Prev: Migration to BGP version 4
Next: Internal BGP in large autonomous systems

### Metrics

BGP version 4 re-defined the old INTER-AS metric as a MULTI-EXIT- DISCRIMINATOR. This value may be used in the tie breaking process when selecting a preferred path to a given address space. The MED is meant to only be used when comparing paths received from different external peers in the same AS to indicate the preference of the originating AS.

The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was insure that peers could not "shed" or "absorb" traffic for networks that they advertise.

The LOCAL-PREFERENCE attribute was added so a local operator could easily configure a policy that overrode the standard best path determination mechanism without configuring local preference on each router. One shortcoming in the BGP4 specification was a suggestion for a default value of LOCAL-PREF to be assumed if none was provided. Defaults of 0 or the maximum value each have range limitations, so a common default would aid in the interoperation of multi-vendor routers in the same AS (since LOCAL-PREF is a local administration knob, there is no interoperability drawback across AS boundaries).

Another area where more exploration is required is a method whereby an originating AS may influence the best path selection process. For example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup.

                        /---- transit B ----\
            end-customer                     transit A----
                        \---- transit C ----/

In a topology where the two transit service providers connect to a third provider, the real decision is performed by the third provider and there is no mechanism for indicating a preference should the third provider wish to respect that preference.

A general purpose suggestion that has been brought up is the possibility of carrying an optional vector corresponding to the AS- PATH where each transit AS may indicate a preference value for a given route. Cooperating ASs may then chose traffic based upon comparison of "interesting" portions of this vector according to routing policy.

While protecting a given ASs routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols.

Next: Internal BGP in large autonomous systems

Connected: An Internet Encyclopedia
RFC 1773 - Metrics