The Hole in my proposal

[[e-mail]]

Ref:  Your note of Fri, 3 Feb 1995 23:27:09 +0500

Joel,

>Thus, de-aggregation is needed as part of the exit selection, not just the
>address resolution phase.

You're certainly correct. If there is a need to perform aggregation within
the boundaries of the ATM cloud, then there is a need to provide
deaggregation. Support for deaggregation in BGP can be accommodated if the
following conditions are met:

(a) there should be a mechanism by which a BGP router can determine
    whether the route it receives from its peer(s) contains aggregated
    information, and if yes, then the address of the (other) router that
    performed the aggregation;

(b) there should be a mechanism by which a BGP router can extract components
    of the aggregate route from another BGP router that performed the
    aggregation.

(a) is already solved in BGP-4 (and in IDRP for IPv6) -- there is an AGGREGATOR
attribute that provides all the information required by (a).

To accommodate (b) requires minor extensions to BGP-4 -- a router, when
it peers with another router, should be able to specify to its peer the
set of destinations the router is "interested in". This set can be defined
in terms of Routing Information Filters (aka RIFs). RIFs can be passed
either at BGP-4 peer establishment time (as a set of optional parameters
in the OPEN message), or after the peering is established (via UPDATE
messages). There is a document that Curtis, Kannan Varadhan and myself
are planning to submit as an Internet Draft this week that describes RIFs,
and how they are supported in BGP-4 and IDRP.

Yakov.

P.S. By the way, RIFs are useful not only in the case of ATM -- SDR WG
has other plans of using it, so the mechanism is likely to be available
in BGP-4 and IDRP in any case. We may as well use it.