as-in/as-out

Thank heavens we are all in agreement about this. It's also
good that we misinterpreted single.  Thanks for the clarification.
        --Elise
> 
> 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  Tue May 24 18:41:32 MET DST 1994  ---------