On 2/16/06, Parminder
<div><span class="gmail_quote"><<a href="mailto:parminder@itforchange.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">parminder@itforchange.net</a>> wrote:</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><snip></blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes, this is important. I would like to know who all do not agree that <br>public policy issues for critical resources should not be discussed in the
<br>IGF. </blockquote>
<div><br>I think you can count me in on that one.<br></div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Just to know people's views that all.... because that is a bit<br>surprising for me that there are people here who believe so. 
</blockquote>
<div><br>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).
<br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I am very eager<br>to hear their logic for it.</blockquote>
<div><br>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.</div>
<div><br>B) I don't think the IGF can do IG better than the current bodies.</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>For example, here is an excerpt form a mail I just read posted to a public policy list concerning Internet resources:</div>
<div> </div>
<div> </div>
<div><excerpt></div>
<div> </div>
<div>I think an approach to lat/long <span name="st">PI</span> addressing such as your<br>draft-hain-<span name="st">ipv6</span>-<span name="st">pi</span>-addr-09.txt
 may be a solid foundation for choosing the <span name="st">PI</span><br>block to assign to each individual organization.  However, I think your<br>draft-hain-<span name="st">ipv6</span>
-<span name="st">pi</span>-addr-use-09.txt proposals, and previous discussion of<br>similar ideas on PPML, have over-engineered the use cases and the<br>implications for routing and exchange points.  In particular, I read your
<br>drafts as requiring that all ISPs in a region would have to agree on the<br>level of aggregation for the region and that all ISPs in that region<br>interconnect at an exchange point, and also encouraging ISPs to filter
<br>more-specifics heard from their peers based on how many routes each origin<br>AS announces and/or a certain prefix length.  I think that all these<br>requirements/suggestions are unnecessarily restrictive stipulations that
<br>encourage unnecessary opposition to the proposal.<br><br>Here's what I see as a more realistic application of Geo <span name="st">PI</span>:<br><br> - Implement some sort of geography-based <span name="st">
PI</span> addressing scheme, either one<br>like draft-hain-<span name="st">ipv6</span>-<span name="st">pi</span>-addr-09.txt, a population-based scheme like Michael<br>Dillon has advocated, or something more like our current system, where RIRs
<br>allocate <span name="st">PI</span> blocks to individual companies, but choose the particular<br>netblock to allocate based on one of the schemes above.  (I'm not sure which<br>of those approaches is superior, but we can debate the merits of each
<br>separately.)<br> - Initially, multihomed organizations allocated <span name="st">PI</span> space would probably<br>route them the exact same way they do IPv4 <span name="st">PI</span>
 space today, announcing it in<br>BGP to their transit providers, who would advertise it to everyone on the<br>planet with a full BGP feed (the DFZ).<br> - At some future point, some global tier 1 NSPs* may decide that the
<br>routing table growth is causing problems for their routers.  At that point,<br>they can begin aggregating <span name="st">PI</span> space within their own network, such that<br><span></span>within a region (which could be a BGP confederation sub-AS, for example) all
<br>more-specifics for that region are carried, but only the <span name="st">PI</span> aggregate is<br>carried outside the region.  In order for an tier 1 NSP to do this<br>effectively, they would have to ensure that all of their peers have at least
<br>two peering points within the region (private peering or exchanged-based, it<br>doesn't matter), so that their peers can reach them and their customers' <span name="st">PI</span><br>more-specifics for that region.
<br> - For transit customers outside the aggregated region, the tier 1 NSP would<br>be able to just advertise the <span name="st">PI</span> aggregate.  For peers who only peer outside<br>the region, the NSP could do one of several things: they could simply
<br>advertise the peer their <span name="st">PI</span> aggregate, which opens the possibility of<br>providing transit connectivity to the peer; they could carry all<br>more-specifics from the aggregated region to the peering router(s), which
<br>would probably require a multihop BGP session or a tunnel; or they could<br>simply not advertise routes from the aggregated region to their peer outside<br>that region, requiring the peer to set up a peering point within the
<br>aggregated region or buy transit connectivity for traffic to that region.<br> - When two or more NSPs set up such aggregation, a customer multi-homed to<br>both NSPs would be able to announce their <span name="st">
PI</span>  deaggregate to their transit<br>providers just as they do now.  Anyone trying to reach the customer from<br>within the region (or from an NSP that doesn't aggregate) would be able to<br>choose between the two resulting BGP paths.  Anyone trying to reach the
<br>customer from outside the region would see the customer's IP space as part<br>of a regional aggregate, and would route their traffic towards the region.<br>Once the traffic arrived at the region, it would reach a router which would
<br>be able to choose between the two deaggregated paths, based on the BGP<br>metrics (localpref, AS path, MEDs, etc.) set by the origin AS.<br><span></span> - If the two NSPs the customer multi-homes to decide to aggregate
<br>differently, it might affect the traffic balance inbound to the multi-homed<br>customer, but the customer will still have the leeway to adjust their<br>announcements to compensate.  For example, if NSP A aggregates a smaller
<br>region to a /32, and NSP B aggregates a larger region to a /28, then traffic<br>from outside the larger region would prefer NSP A, while traffic from the<br>in-between region would prefer NSP B, as the route would still be a
<br>deaggregate over NSP B in that region.  Once traffic reached the smaller<br>region, the origin AS's BGP metrics would take over.<br><br>My point here is not that NSPs have to do things this way, but rather that a<br>
geography-based 
<span name="st">PI</span> allocation scheme allows them to continue operating with<br>the current model as long as they want to, and also gives them the<br>flexibility to begin gradually aggregating <span name="st">
PI</span> space within their network as<br>they see fit (for example by starting with large regions like continents, an<br>later aggregating on a more regional basis as needed).  We can implement<br>such a geography-based 
<span name="st">PI</span> allocation scheme *without* requiring everyone (or<br>anyone) in a region to set up new interconnections, and without requiring<br>anyone to coordinate the precise size of aggregated regions (and thereby the
<br>length of aggregate prefixes).  IMO that makes it *much* more likely that<br>such a system could reach consensus and actually get implemented.<br> </div>
<div></excerpt></div>
<div> </div>
<div> </div>
<div>Now, I think this discussion is fascinating, and crucial to the stability of future internetworking.  How many people in Tunisia would;</div>
<div> </div>
<div>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?)<br></div>
<div> </div>
<div>B) know what the post was saying and could fit that into the schema of global coordination of such resources?</div>
<div> </div>

<div>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.
<br><br>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.
<br><br>   <br></div></div>-- <br>Cheers,<br><br>McTim<br>$ whois -h <a href="http://whois.afrinic.net/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">whois.afrinic.net</a>  mctim<br>