route/origin

Daniel,

> 
> 
>   > epg at merit.edu writes:
>   > 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."
> 
> revised version:
> 
> Conceptually there can be multiple route objects for the
> same route with different origins. 
> This will represent that the same route is originated by different ASes.
> Such entries will represent multiple proxy aggregation by 
> *different* ASes which to our knowledge is not done in the Internet yet.
> We have not thoroughly investigated the consequences this added 
> complexity will have for consistency checking and the PRIDE tools.
> 
>   > The NSFNET service will be doing proxy aggregation for DISA and Westnet
>   > real soon now (the code is ready). 
> 
> We can do proxy to the nth level without multiple route objects.
> It is just when two *different* ASes announce the *same* route that
> we need multiple route objects. These we can accept into the registry
> no problem.  It is just a problem that we do not know how useful the
> output of the tools can be in the face of this.
> 
>   > 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.
> 
> The answer is yes and the proposal intended to say so. I hope it
> is clearer now.

Let me repeat what I think has been said - just to make sure I have it
straight.

1)The route object will NOT permit multiple values for the origin attribute.
2)The unique key will be route/origin, thereby permitting multiple entries
for the same route in the registries.
3)The Merit Routing Registry can replace the INETNUM object with the
ROUTE object. The ROUTE object is the "policy" relevant object. The
INETNUM object is the assignment/allocation relevant object.

As Jessica, has mentioned, our initial preference is to permit
multiple values for the origin attribute.  It seems cleaner
to us, and would require fewer modifications to current tools (we think).
We are VERY happy that we have some common aggreegment about 
route and origin - not flaming - just trying to have a constructive
conversation :-)

Will look forward to the next version of the proposal.
         --Elise



-------- Logged at  Thu Apr 28 18:00:45 MET DST 1994  ---------