The Difference Between GateD and IDRP "Preference"

Introduction

Both GateD and IDRP use the word preference to describe different concepts. This can be confusing, and it is the purpose of this document to briefly describe what that term means in both contexts, and how one can distinguish between these usages in a GateD configuration file.

Metrics

In order to understand the concept of preference, it is important to first understand the concept of metrics; here is an explanation of metrics in routing protocols for those who are unfamiliar with this term.

GateD Preference

GateD is a platform which controls the running of various routing protocols; it sets up different sorts of protocol sessions, with syntax for the specification of various session parameters for the different protocols, and also controls the acceptance and redistribution of routing information via its policy language. In order to allow for the comparison of routes obtained from these various protocols, GateD uses its own measure, but, in order to avoid confusion with the term "metric," the GateD measure of a route's desirability is called "preference".

GateD's preference is a normalized metric which allows for precisely the comparison sought--the comparison of routing information obtained from different protocols with wildly different concepts of what constitutes a metric. This preference, GateD's own internal metric, has GateD-defined values:

• Currently, preferences are signed, 32-bit integers (see pref_t in defs.h), but perusal of the rt_table.h file makes it seem that only 1-byte values are used (0 to 254 are used in the latter file; -1 is used throughout the GateD code as the "invalid preference" value, i.e., the preference of a route which cannot be used because it is rejected by import policy.

• The lower the preference, the more desirable the route (thus, 0 represents the best possible preference value, i.e., most-desirable routes.

In order to be useful, the preference must be tagged on all routes accepted by GateD; during import filtering, accepted routes should be tagged with a preference. The value used is either a default value defined in a GateD header file in the distribution (currently, rt_table.h), or a value defined somewhere within the various scopes of preference in the file. Typically, the preference can be set at any of these levels, from the smallest scope to the broadest:

• prefix-level preference;
• import statement-level preference;
• peer-level preference;
• protocol-level preference from the GateD configuration file;
• default protocol-level preference from a header file in the GateD distribution; the values as of the time of this writing can be viewed here.

Note that the preference keyword only appears in the import statement; this makes sense, since it is a concept internal only to GateD. When routes are exported, this occurs via the various routing protocols, so that the given protocol's "metric" is valid upon export; this is why the metric keyword is typically found only in the export statement.

If all routes are tagged with a GateD preference--remember, this is up to the proper coding of the protocol, as of the current writing--any route from any protocol can be compared with any other route from any other protocol via comparing their respective GateD preferences. In practice, the process of route selection compares two or more identical routes from various protocols or various peers using a single routing protocol, in order to select which of the various ways of reaching the given destination is considered to be the best (this is known as "best-route selection" or "route selection"). Since the exchange of routing information is merely a prelude to route selection, which results in an actual route being installed in the router's kernel routing table, which in turn allows for the actual routing of packets to occur, it is clear that the GateD preference is a fundamental part of the utility of GateD in controlling and exchanging routing information.

IDRP Preference

Just to be difficult, IDRP doesn't refer to its internal metric as a "metric"--instead, IDRP uses "preference" for the concept which other routing protocols refer to as a "metric"! This is confusing, since IDRP routes will/can have a PREFERENCE path attribute before being imported, and the situation is not aided by the fact that IDRP's preference is inverted from GateD's in that it has the opposite sense of increasingly good routes (a high IDRP preference is good, while a high GateD preference is bad).

IDRP and GateD Preferences in the GateD Configuration Files

In order to be able to use both IDRP and GateD preferences without confusion, the GateD configuration file syntax uses only

• gated-preference or gated-pref and
• idrp-preference or idrp-pref

in the IDRP-specific portions of the configuration syntax. Each means what its name implies; it is hoped that this will aid users to avoid confusion between these two similar uses of the term "preference."