[governance] For you as an Internet user, what is a "Critical Internet resource"?
McTim
dogwallah at gmail.com
Wed Oct 17 13:25:19 EDT 2007
Milton,
On 10/16/07, Milton L Mueller <mueller at syr.edu> wrote:
>
<snip>
>
> > A /24 is routed the same way a /8 is routed, with BGP4 (usually), so
> > no difference there.
>
> I don't have time to clear up this misconception. Let's just say that the decision about who gets a /8 and who gets a /24 has something to do with routing as well as address conservation.
>
Actually, The "decision" about who gets a /8 vs. a /24 has nothing to
do with either routing or conservation. Addresses are assigned
according to proven need, following policies laid down by the
community in question.
IIRC, only one of us has ever actually made IP allocations. It's been
a couple of years, but I seem to recall how it's done, so I don't
think the misconception is on my side.
> > AFAIK, RIRs don't impose routing aggregation constraints, although
>
> Interesting, a few years ago I was told that if we had any competition among RIRs we would instantly lose all route aggregation....
I'm sure you will try point to smt I said a few years ago, but it's
nonsensical to suggest that current route aggregation would be lost if
there was "RIR shopping". We certainly would lose some
aggregatability going forward if we had competition as you had
suggested, but that's not the same as "instantly lose all route
aggregation".
> > they DO keep aggregation in mind whenever possible when making
> > allocations.
>
> Hmm, so would you say that "The way RIRs allocate addresses has a lot to do with how routing takes place"? ;-)
No, I would say they don't waste (IPv4) space needlessly. See above,
a /24 is routed the same way as a /8.
>
> > > and the need to register addresses with
> > > RIRs all have some kind of impact.
> >
> > In the RIRs I am familiar with, if it's an allocation or a PI
> > (End-User) assignment, the RIR does the registration in the RIR
> > Database. LIRs do enter PA assignments in the appropriate RIR Db, and
> > these can be routed by an entity that is NOT the LIR, but this
> > requires an entry in a Routing Registry (not neccesarily the same as
> > an RIR). In other words, it's difficult to route a PA assignment
> > block that is NOT registered in an RIR Db, but this is the task of an
> > LIR, NOT an RIR.
>
> To shorten what you say above, "the need to register addresses with RIRs has some kind of impact on routing."
sort of, but not on routing policy per se.
> This is yet another one of those bizarre McTim exchanges in which you essentially confirm what I asserted but nevertheless insist that you are disagreeing with me. Hope you enjoyed it.
I confirmed the tiniest sliver of reality in your assertion. It's
only satisfying if the clue bat works, in this case, it seems to be
failing. I'll have to use a bigger one ;-)
>
> > Why? With the birth of the two newest RIRs folk building filters just
> > have two more databases for their scripts to query. I don't see any
> > "major effects". Maybe you can ask the folk at Syracuse if they have
>
> Tell me: what reason is there to create a RIR?
Pride,regional policy making, ease of travel/lower cost to meetings, etc.
>Does it contribute to route aggregation or not? A simple yes or no on
that last question would suffice.
I'll give you a firm no on that, and a definite yes at the same time.
The act of creating a new RIR doesn't contribute, as RIRs don't route
the space they allocate. As I've said before, one of their main goals
IS aggregation, so yes, they do contribute. However, if you had
hundreds of them (one per country for example) this would contribute
to DE-aggregation to an extent.
>
> > had to change their routing policies since LACNIC and AfriNIC came
> > into existence?
>
> I am sure they did not. But that was not my point. Do you think Latin American and African ISPs changed their routing policies?
Well, in some cases, they changed IP blocks, and routing policies
change when you get change peers and/or IP blocks, so some did.
I think we have been talking past each other, here is an illustration
of why. I am in Nairobi today, and here is the block of IPs I am
writing this mail from:
inetnum: 196.207.16.0 - 196.207.31.255
org: ORG-CSL1-AFRINIC
netname: ORG-CSL1-AFRINIC-20050530
descr: Communication Solutions Ltd.
descr: PROVIDER Local Registry
country: KE
admin-c: NPS2007-AFRINIC
tech-c: RM1760-AFRINIC
status: ALLOCATED PA
mnt-by: AFRINIC-HM-MNT
mnt-lower: COMMSOL-MNT
source: AFRINIC
Here is the route object registered for that block:
% Information related to '196.207.16.0/20AS15808'
route: 196.207.16.0/20
descr: Commsol Infrastructure
origin: AS15808
mnt-routes: RIPE-NCC-RPSL-MNT
mnt-by: COMMSOL-MNT
source: RIPE
And here, in the ASN, in Routing Policy specification Language, is the
routing policy for the ISP used to send this mail:
Information related to 'AS15808'
aut-num: AS15808
as-name: UNSPECIFIED
descr: Communication Solutions Ltd is an ISP serving
descr: corporate customers in Kenya
import: from AS5486
action pref=100;
accept ANY
import: from AS12455
action pref=100;
accept ANY
export: to AS12455
announce AS15808
admin-c: TECH6-RIPE
tech-c: TECH6-RIPE
tech-c: RM1760-RIPE
mnt-by: COMMSOL-MNT
source: RIPE
"import" means they accept routes (send packets) from the other ASNs
listed, export means they send their routes (acccept packets). THIS
is their routing "policy". I suspect you are talking about other kinds
of "policies".
Again, this is the RPSL "map" of the BGP "territory" that is
implemented in the routers of the ASs.
>
> > I guess it's concievable, `i just can't see the IGF making these
> > decisions.
>
> IGF doesn't make any decisions. IGF talks about things. Are you still looking for the UN-takes-over-the-Internet bogeyman under your bed?
No, but I am wary of folk who want to talk about things already being
discussed in other (authoritative) fora, when they show little or no
inclination to join those other fora.
--
Cheers,
McTim
$ whois -h whois.afrinic.net mctim
____________________________________________________________
You received this message as a subscriber on the list:
governance at lists.cpsr.org
To be removed from the list, send any message to:
governance-unsubscribe at lists.cpsr.org
For all list information and functions, see:
http://lists.cpsr.org/lists/info/governance
More information about the Governance
mailing list