as-in/as-out

Elise, I missed this sentence as well, and after rereading, I am not
quite sure what the second sentence means. Proxy aggregation is
obviously supported by components in different ASs. That is basic
proxy aggregation. Now, the difficult bit comes when you do proxy
proxy aggregation, ie you proxy aggregate for your customer with it's
own AS, who has address space from your block, but I am your bigger
transit provider and you have your own AS and your address space from
my even bigger block (is this complicated or what ;-). Conceptually
this can all be described with the object below. Problem with proxy^n
aggregation is the consistency checking and policy derivation becomes
quite difficult. I am not quite sure how many people are going to do
more than one level proxy aggregation.

Now, in stead of sending two mails, I may as well answer Jessica's
question, and you are right that this is not clear from the doc, but
we recognized that an aggregate can be aggregated at multiple places
(and legally so, although it may create a policy maintainer's
nightmare, and has all sorts of policy implications, but all that is
nothing new) and therefore origin CAN contain more than one value. The
"single" definition is a RIPE database like definition, which means it
can only be one line, but on that line there can be multiple origins.

Daniel and Tony, please correct me if I am totally wrong, but this is
how I remember the discussion.

-Marten

 * Have just quickly browsed thru the document. Thanks for sending it.
 * 
 * On the paragraph that says:
 * "Conceptually there can be multiple route objects with different
 * origins.  Representing multiple proxy aggregation which to our knowledge
 * is not done in the Internet yet."
 * 
 * The NSFNET service will be doing proxy aggregation for DISA and Westnet
 * real soon now (the code is ready). And it seems likely that some
 * multi-homed entity in the future will ask both(or more) peer ASs to
 * aggregate nets on their behalf.  Could the unique key be route and origin,
 * instead of just route? How would you propose to deal with
 * this case? It seems shortsighted of us if we cannot accommodate proxy
 * aggregation.
 *         --Elise 



-------- Logged at  Wed Apr 27 21:50:35 MET DST 1994  ---------