Subject: Re: [RADIR] section 5.5 of prob statement

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Jul 2007 13:42:31 -0400

"Azinger, Marla" <[email-masked]> writes:

> Here is the small write up I did on 5.5:

> 5.5 RIR Policy:

> RIR policy indirectly attributes to more updates by the subnet size
> they directly allocate to users through PI policy.  If PI did not
> exist then these users would not have their own subnets directly
> injected into the global internet, they instead would be inlcuded
> within a providers supernet.  What will also lead to more updates is
> if RIR members work together and agree to let filters allow more
> specifics than a /32 through that come out of the PA addresses
> range.

This is a tough section. I can't help be read it is saying "the RIRs
are part of the problem allowing PI". But in some sense, the RIRs are
being made scapegoats.

How about:

RIR address policy has direct impact on the routing load because
address policy determines who is eligible for a PI assignment (which
impacts how many are given out in practice) and the size of the
assignment (which impacts how much address space can be aggregated
within a single assignment). If PI assignments for end sites did not
exist then those end sites would not need to advertise their own
prefix directly into the global routing system; instead their address
block would be covered by their provider's aggregate. That said, RIRs
have adopted PI policies in response to community demand, for reasons
described elsewhere (e.g., to support multihoming and to avoid the
need to renumber).

> What will also lead to more updates is if RIR members work together
> and agree to let filters allow more specifics than a /32 through that
> come out of the PA addresses range.

This is the operators agreeing to do something, not the RIRs.

Thomas

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 17 Jul 2007 14:00:24 -0400

> prefix directly into the global routing system; instead their address

I'd say s/would not need to/would not/.  As written, it makes it  
sound as though the need to do so is a problem from the end site's  
PoV, whereas of course it's not.

--John