fyi - my notes on the ptomaine issue

[Curtis Villamizar]

This is just an FYI.  If anyone is interested, these are excerpts from
the notes I jotted down after the ptomaine meeting (some of the notes
well after the meeting in the airport waiting for a delayed flight).

As Yakov already pointed out, this feature of the new attribute
described below is similar to a feature in IDRP (but just about
everthing imagionable is in IDRP which is why IDRP never happenned).

A key semantic difference is in the proposed semantics below, if an
overlap occurred, any provider would aggregate in the absense of this
attribute under the assumption that the more specific was a mistaken
rather than an intentional and bounded leak through the aggregate.

You guys can take it from here (Ben, Joe, anyone else).

Curtis



A number of presentations were made by Geof Huston, Abha Ahuja, Craig
Labovitz.  These were mostly reruns of measurements and projections of
growth in the number of prefix, AS, or paths.

The problem is that more specific components of aggregates have to be
announced among a small number of AS but need not be announced very
far.  Once announced outside the origin AS, the aggregates are never
formed due to the difficulty of coordinating aggregation across
multiple providers.

Prior attempts to fix this were based on the routing registry (IRR).
A suggestion was made (by me) to resurrect the prior work (also by me)
but to use BGP communities instead of the IRR as the means to
communicate the needs to proxy aggregate outside the origin AS.  John
Scudder later in a private conversation suggested that we use a new
BGP attribute since we would otherwise need multiple communities per
aggregate (one per AS that must carry the more specifics) plus we need
to make modifications to the router code in deciding to form
aggregates in what would now be considered special cases.

The transition would proceed as follows:

  1.  First we must agree on the protocol method.  There are two
      candidates.

      a.  Routers would have to form an aggregate for any prefix which
          has a specific community set that contains their own AS in
          the lower half but only if the peer AS was not listed in a
          similar aggregate.  This part could be done without change
          to the router but long term may be less desirable.  It also
          initially requires some per peer configuration.

      b.  If a new BGP attribute was present, and the routers AS was
          not listed, then the router would not accept any more
          specific prefixes.  If the router's AS was listed and an
          EBGP peer's AS is not listed, then proxy aggregation is
          performed outbound.  The advantage of this method is it
          requires software upgrade but no configuration except simple
          configuration at the origin AS.

  2.  Demonstrate the capability to aggregate using one of the above
      methods.

      a.  Providers within the aggregation boundary must be prepared
          to handle one the above cases.  For case (a) (communities)
          these providers must have their routers configured to
          recognize the appropriate set of communities.  For case (b)
          (new attribute) the routers must be upgraded and at most a
          feature enabled.

      b.  The origin AS must put the community or new attribute on the
          aggregate.

  3.  Encourage widespread deployment.  The goal of widespread
      deployment is to provide explicit limits to the regions in which
      multihomed prefixes are announced thereby decreasing the size
      and growth rate of the global routing table.

  4.  Begin proxy aggregating in any case where shorter prefixes
      overlap longer prefixes and where attributes are not present
      limiting the region where the more specific leak.  This step
      make the default to aggregate rather than to leak globally.  It
      might be that this step is never actually taken but could serve
      as the "big stick" to provide the "encouragement" in step 3.

These notes describing the proposed solutions were written a while
after the meeting and after discussions with John, Abha, Geoff, Ben
Black, and others.  If its wrong it was my error and I expect to be
corrected on the ptomaine mailing list.