Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 26 Apr 2011 07:51:17 -0400

Thanks for catching the improper use of the term "administrative domain".
When we said "administrative domain", we actually meant
ASs within the same "address allocation hierarchy".
It is in the sense of parent, child, grandchild, etc.
in address allocation/suballocation chain.
Of course, multiple ASs belonging to different entities are involved.
For example, in the Figure in Appendix A, a large ISP with AS-G 
suballocated address space to two smaller ISPs with AS-E and AS-F, 
and also to four customer ASs A,B,C, and D (grand children).
Therefore, AS-G is in a position to proxy aggregate the more specifics
from ASs A through F, and also create a ROA for the aggregate prefix 
with itself (AS-G) as the origin AS. Being able to create a ROA for the 
aggregate is important when adoption of RPKI and origin validation 
takes effect. Therefore, the suggestion is to aggregate only more specifics 
and only from ASs located in the same address allocation hierarchy.  

In light of your comment, we will make the following change:
Replace
"An AS should proxy aggregate only prefixes which
belong to its administrative domain." 
with new sentence
"An aggregating AS should proxy aggregate only more specific prefixes 
from ASs which have address suballocations within the same 
address allocation hierarchy (as that of the aggregating AS)."

We will also edit related text elsewhere to be consistent with the above.

Sriram

>Date: Sun, 24 Apr 2011 18:22:01 -0400
>From: Curtis Villamizar [email-masked]
>-- snip –
>The following sentence in the appendix is also inaccurate "An AS
>should proxy aggregate only prefixes which belong to its
>administrative domain. "  Consenting adults may aggregate prefixes for
>which they both have components of the aggregate, though you should
>word it differently in the next iteration.  The key is to have
>agreement from the other party, exchange more specifics, and both
>aggregate only the more specifics to any peer but each other.  This
>works for two or more administrative domains though the consenting
>adults analogy get a little wierd so we shouldn't go there.
>
>Proxy aggregation is by definition aggregating someone else's prefix,
>so the sentence "An AS should proxy aggregate only prefixes which
>belong to its administrative domain." contains a contradiction.  The
>point is aggregate only more specifics.  Proxy aggregation should be
>with consent of other parties and adequate consideration of
>consequences.  It may be necessary to proxy aggregate without consent
>if some provider routinely leaks out tons of more specifics and has
>proven to be clueless and/or unresponsive.
>-- Snip -->
>Curtis>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Apr 2011 21:41:51 -0400

In message <[email-masked]>
> We will also edit related text elsewhere to be consistent with the above.

Sriram,

This limitation sounds specific to SIDR and if so you should either
say so and describe the limitation or leave it out.

Ultimately all addresses come from somewhere.  Jon Postel maybe.  So
in a sense it is also meaningless.  The further up the tree you have
to go the harder it would be to coordinate, but all address
allocations have a common root.

Curtis