[governance] intervention draft - why are the more progressiveelements of IGF functions ommitted

William Drake drake at hei.unige.ch
Fri Feb 17 06:38:58 EST 2006


Hi McTim,

Two quick thoughts while I sit here listening to ISOC say that the forum should
focus only on easy noncontroversial issues and capacity building.

Discussion of possible public policy principles is not, in fact, ongoing in
other forums.  All that's been happening is that the US and EU are having
private bilaterals, and the US is telling everyone they can join and support
GAC, which neither the Europeans nor the developing countries appears to view
as an answer.  Brazil was quite explicit on this yesterday.  If it doesn't
happen in the IGF, where do you think everyone excluded from the US-EU dialogue
will take it?  My money's on the ITU.  Do you prefer that to an open
multistakeholder discussion in a nonbiding forum?

I'm not clear what your point is with respect to the technical discussion you
forwarded.  Yes, people who do not come from technical backgrounds and
participate in technical forums might not be inclined to read through or able
to fully grok the dialogues there.  So what?  Does that mean that governments
have no right to take an interest in public policy aspects, or that CS should
not try to have a dialogue with them in order to encourage good policies and
discourage bad ones?  Should we just tell them to sit down, be quiet, and eat
their Wheaties?  That line obviously hasn't gone done well to date, I can't see
how you'd imagine it will going forward.

Puzzled,

Bill





-----Original Message-----
From: governance-bounces at lists.cpsr.org
[mailto:governance-bounces at lists.cpsr.org]On Behalf Of McTim


A) It would be a waste of time, money and effort, as these discussions are
ongoing in other fora.  Duplication is what we want to avoid IMO.

B) I don't think the IGF can do IG better than the current bodies.

C) I am sure that IGF participants will not be interested in the nitty gritty
"technical" issues that IG resource folk talk about.  At least on this list
whenever anything remotely technical comes up, there are only a few who don't
bury thier heads in the sand.

For example, here is an excerpt form a mail I just read posted to a public
policy list concerning Internet resources:


<excerpt>

I think an approach to lat/long PI addressing such as your
draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing the PI
block to assign to each individual organization.  However, I think your
draft-hain-ipv6 -pi-addr-use-09.txt proposals, and previous discussion of
similar ideas on PPML, have over-engineered the use cases and the
implications for routing and exchange points.  In particular, I read your
drafts as requiring that all ISPs in a region would have to agree on the
level of aggregation for the region and that all ISPs in that region
interconnect at an exchange point, and also encouraging ISPs to filter
more-specifics heard from their peers based on how many routes each origin
AS announces and/or a certain prefix length.  I think that all these
requirements/suggestions are unnecessarily restrictive stipulations that
encourage unnecessary opposition to the proposal.

Here's what I see as a more realistic application of Geo PI:

 - Implement some sort of geography-based PI addressing scheme, either one
like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like Michael
Dillon has advocated, or something more like our current system, where RIRs
allocate PI blocks to individual companies, but choose the particular
netblock to allocate based on one of the schemes above.  (I'm not sure which
of those approaches is superior, but we can debate the merits of each
separately.)
 - Initially, multihomed organizations allocated PI space would probably
route them the exact same way they do IPv4 PI space today, announcing it in
BGP to their transit providers, who would advertise it to everyone on the
planet with a full BGP feed (the DFZ).
 - At some future point, some global tier 1 NSPs* may decide that the
routing table growth is causing problems for their routers.  At that point,
they can begin aggregating PI space within their own network, such that
within a region (which could be a BGP confederation sub-AS, for example) all
more-specifics for that region are carried, but only the PI aggregate is
carried outside the region.  In order for an tier 1 NSP to do this
effectively, they would have to ensure that all of their peers have at least
two peering points within the region (private peering or exchanged-based, it
doesn't matter), so that their peers can reach them and their customers' PI
more-specifics for that region.
 - For transit customers outside the aggregated region, the tier 1 NSP would
be able to just advertise the PI aggregate.  For peers who only peer outside
the region, the NSP could do one of several things: they could simply
advertise the peer their PI aggregate, which opens the possibility of
providing transit connectivity to the peer; they could carry all
more-specifics from the aggregated region to the peering router(s), which
would probably require a multihop BGP session or a tunnel; or they could
simply not advertise routes from the aggregated region to their peer outside
that region, requiring the peer to set up a peering point within the
aggregated region or buy transit connectivity for traffic to that region.
 - When two or more NSPs set up such aggregation, a customer multi-homed to
both NSPs would be able to announce their PI deaggregate to their transit
providers just as they do now.  Anyone trying to reach the customer from
within the region (or from an NSP that doesn't aggregate) would be able to
choose between the two resulting BGP paths.  Anyone trying to reach the
customer from outside the region would see the customer's IP space as part
of a regional aggregate, and would route their traffic towards the region.
Once the traffic arrived at the region, it would reach a router which would
be able to choose between the two deaggregated paths, based on the BGP
metrics (localpref, AS path, MEDs, etc.) set by the origin AS.
 - If the two NSPs the customer multi-homes to decide to aggregate
differently, it might affect the traffic balance inbound to the multi-homed
customer, but the customer will still have the leeway to adjust their
announcements to compensate.  For example, if NSP A aggregates a smaller
region to a /32, and NSP B aggregates a larger region to a /28, then traffic
from outside the larger region would prefer NSP A, while traffic from the
in-between region would prefer NSP B, as the route would still be a
deaggregate over NSP B in that region.  Once traffic reached the smaller
region, the origin AS's BGP metrics would take over.

My point here is not that NSPs have to do things this way, but rather that a
geography-based PI allocation scheme allows them to continue operating with
the current model as long as they want to, and also gives them the
flexibility to begin gradually aggregating PI space within their network as
they see fit (for example by starting with large regions like continents, an
later aggregating on a more regional basis as needed).  We can implement
such a geography-based PI allocation scheme *without* requiring everyone (or
anyone) in a region to set up new interconnections, and without requiring
anyone to coordinate the precise size of aggregated regions (and thereby the
length of aggregate prefixes).  IMO that makes it *much* more likely that
such a system could reach consensus and actually get implemented.

</excerpt>


Now, I think this discussion is fascinating, and crucial to the stability of
future internetworking.  How many people in Tunisia would;

A) be interested enough to read the entire post let alone dozens of similar ones
daily on dozens of lists? (or be motivated enough to do the research to learn?)


B) know what the post was saying and could fit that into the schema of global
coordination of such resources?

With respect to B, I think the Canadians Prepcom3 proposal about capacity
building was spot on.  The existing fora work well.  Unfortunately, from a
bottom up perspective it is a very narrow bottom, so IGF capacity building is
key IMO in expanding that bottom.

It is clear that the current bodies are keen to work with the IGF.  However, if
the IGF recommends smt contrary to the best interests of the communities that
make up the current bodies, count on those recommendations to be largely
ignored.



--
Cheers,

McTim
$ whois -h whois.afrinic.net mctim


_______________________________________________
governance mailing list
governance at lists.cpsr.org
https://ssl.cpsr.org/mailman/listinfo/governance



More information about the Governance mailing list