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

[McTim]

On 2/16/06, Parminder <parminder at itforchange.net> wrote:

> <snip>

Yes, this is important. I would like to know who all do not agree that
> public policy issues for critical resources should not be discussed in the
>
> IGF.


I think you can count me in on that one.

Just to know people's views that all.... because that is a bit
> surprising for me that there are people here who believe so.


Why? If you participated in the current bottom up, open to all, consensus
driven IG mechanisms, I think you would not be surprised at all. They are a
model of what CS wants from such processes (open, transparent,
e-participation enabled, etc).


> I am very eager
> to hear their logic for it.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20060216/ee585261/attachment.htm>
-------------- next part --------------
_______________________________________________
governance mailing list
governance at lists.cpsr.org
https://ssl.cpsr.org/mailman/listinfo/governance