Subject: Re: rps-auth

From: [email-masked]
Date: Tue, 8 Sep 1998 08:27:56 -0700 (PDT)

> Please note that where information is recorded and how it is
> distributed is the topic of the draft rps-dist.  For the moment I'd
> like to restrict this thread at least to the topic that Harald Tveit
> Alvestrand brought up.  In the rps-auth, a key assumption is stated
> below:
> 
>     3  Implicit Policy Assumptions
> 
>       The authorization model encodes certain policies for allocation of
>       address numbers, AS numbers, and for the announcement of routes.
>       Implicit to the authorization model are a very limited number of
>       policy assumptions.
> 
>      2.  AS numbers are allocated either singly or in small blocks by
>          registries.  Registries are allocated blocks of AS numbers, thereby
>          making the allocation hierarchical.
> 
> I don't think there is any disagreement about #1 and #2.  This are
> just statements of fact.

	Actually, I think that I disagree with #2 above. Segmentation
	is not the same as hierarchy.

> The third statement further implies the following:
> 
> 	  3.a	    The holder of an AS number may not advertise any
> 		    prefix they see fit to advertise, irrespective of
> 		    IP address assignments.

	Only within the context of the big "I" Internet. 

> 	  3.b	    The holder of an IP address assignment cannot
> 		    advertise that prefix with any AS number
> 		    irrespective of AS number assignments.

	Same comment as above with the further restriction placed
	by BGP communities et.al. for hiding ASNs in a path.

> 	  3.d	    If the holder of an IP address assignment and the
> 		    holder of an AS number assignment are different
> 		    parties, then either:
> 
> 		      1   one must delegate a limited amount of
> 			  authority to the other allowing the other to
> 			  register advertisement of that prefix and
> 			  that origin AS,
> 
> 		      2   or both must agree the act of registering
> 			  advertisement of that prefix and that origin
> 			  AS.

	Proxy aggregation by some ISPs violates this condition.

> Curtis

--bill

---

From: Bill Manning <[email-masked]>
Date: Tue, 8 Sep 1998 12:03:45 -0700 (PDT)

> In message <[email-masked]>, [email-masked] writes:
> > > 
> IANA allocates to RIPE (or another regional registry).  RIPE allocates
> to a consumer of AS numbers.  That's a two level hierarchy.

	True, I was confusing delegation hierarchy with routing.
	Somehow I don;t think that there is proposed a routing
	thing which will aggregate ASNs e.g.

	# aggregate all ASNs within the range 200-1000    

--bill

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Sep 1998 14:46:58 -0400

> 	Only within the context of the big "I" Internet. 

Sorry.  I thought the "I" in "IRR" was capitalized.  What you do
behind the firwall or NAT box should not be placed in the IRR.

> 	Proxy aggregation by some ISPs violates this condition.

Not neccesarily.  What we've referred to as "hostile proxy
aggregation" does violate this.

If the block was allocated by a registry to multiple parties, the
registry can agree with the provider(s) that wish to allocate.  If the
registry is acting on behalf of the interests of the those using it,
then they might want to try to consult those who had been delegated
the more specific (out of band) or at least a subset by way of prior
notification.  If it was deemed to be in everyone's best interest, the
registry and the ISP(s) wishing to aggregate can agree to add the
aggregate route object and agree on the aggregation boundary (which
could encompass many AS in the case of a large, well planned
aggregation).

We've also discussed the topic of an aggregate that only exists within
a subset of the Internet.  An example was China wishing to use less
expensive routers with less memory and aggregating to default at
borders to AS within China.  (I don't remember where this example came
from or if it was hypothetic).  In such a case, you'd list the AS in
which the aggregate existed bu not the more specific and require only
that those AS agreed to the information reduction.  This feature has
not yet made ir into RPSL (unless I'm mistaken).  

Currently the aggregation boundary contains the list of AS in which
the more specifics are exchanged, outside of which only the aggregate
is announced.  The above example is a reversal of this, where the
aggregation boundary contains the list of AS where the more specifics
don't exist.  The latter feature allows a set of AS to generate and
share default or generate and share aggregates with stubs.

There are some complexities, such as adding an interior AS to very
large aggregates (the question arises as to who needs to sign the
addition of the AS).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Sep 1998 16:59:49 -0400

In message <[email-masked]>, Bill Manning writes:
> > > >          registries.  Registries are allocated blocks of AS numbers, th
> ereb
> > > y

So the text is OK.  Thanks.

Curtis