Output BGP Policy Accounting
In Figure 8-1, where an ISP deploys a destination-sensitive billing scheme, imagine a case in which a customer downloads some huge files from the Internet. Destination-sensitive billing, configured with Input BGP Policy Accounting, tracks only the initial small FTP requests. The bulk of the returned data, which is sent in the opposite direction, is tracked with only an additional configured source-sensitive billing scheme.
To use source-sensitive billing, the ISP must apply a traffic classification on the (sub)interface facing the customers on Router A, for the egress traffic. This traffic classification is based on the route that the traffic took before arriving at the customers, which is a source classification.
The question "Does the traffic come from ISP1, from ISP2, or via the satellite link from ISP3?" can now be answered. Therefore, the customers are charged according to the path of the information's source.
The similarities and differences between Input and Output BGP Policy Accounting can be deduced from the similarities and differences between destination- and source-sensitive billing:
In case of destination-sensitive billing (Input BGP Policy Accounting), the router looks at the traffic when it enters the interface. The router looks at the traffic when it leaves the interface for source-sensitive billing (Output BGP Policy Accounting).
In case of destination-sensitive billing (Input BGP Policy Accounting), the router executes a destination lookup classification to deduce where the traffic will be sent. For source-sensitive billing (Output BGP Policy Accounting), the router executes a source lookup classification to deduce where the traffic comes from (from which peering point the traffic enters the ISP network).
The same traffic classifications are used in both source- and destination-sensitive billing (both Input and Output BGP Policy Accounting), based on BGP community list, BGP AS number, and/or AS_PATH on a per-interface basis.
Note
A general concern related to any accounting mechanism that performs a source lookup also applies in the case of Output BGP Policy Accounting. A source lookup in the routing table results in the path that this router would take to reach the source. In case of asymmetric routing, where the forwarded traffic path is different from the return traffic path, the deduced routing information is incorrect. Therefore, caution should be taken with Output BGP Policy Accounting (and, as a consequence, with source-sensitive billing), because BGP asymmetry is a common occurrence in ISP environments.
Some ISPs have an interesting alternative that avoids the issues of asymmetric BGP routes. If an ISP has only a few customers (a maximum of 64, which is the maximum number of buckets in BGP Policy Accounting), and the customer routes are in (I)BGP on the external border routers (those with "upstream" connections), the ISP could map each customer into a bucket on those routers and use ingress BGP Policy Accounting on every interface to an upstream ISP.
