Julião, !3runo (legalzinho esse negócio de leetspeak :-) ) e demais colegas,

Vou tentar me limitar às questões técnicas, e deixas ar discussões sobre política e legislação para a troca de posts com o Rogério :-) .

Primeiro a questão "quem veio primeiro o ovo ou a galinha?" do BGP-4 versus AS. Vou transcrever a introdução da RFC 1930 - Guidelines  for creation, selection and registration of an Autonomous System (AS) - que pode ser consultada em http://tools.ietf.org/html/rfc1930:

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such.  ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior Gateway Protocol, now at historical status; see [EGP]), BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier.

Nesta mesma RFC, na seção 3 (definitions), está escrito que:

The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes. Since this classic definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASes to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it.

To rephrase succinctly: An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.

Routing policy here is defined as how routing decisions are made in the Internet today. It is the exchange of routing information between ASes that is subject to routing policies.

Portanto para mim é claro que:

a) O conceito de AS foi criado para definir unidades administrativas que controlam segmentos lógicos (isto é, uma parte do espaço de endereçamento IPv4 ou IPv6) da Internet e a forma de roteamento no seu interior. Sem isto seria impossível que a Internet atingisse a escala mundial que ela tem hoje;

b) Cada AS deve apresentar aos demais AS (isto é, para o restante da Internet) uma política de roteamento única e claramente definida (isto é, como o tráfego destinado a endereços IP no seu interior deve ser encaminhado até a sua "fronteira"). Já o roteamento dentro da "fronteira" de cada AS é de sua exclusiva opção e responsabilidade;

c) A forma como estas políticas de roteamento entre AS são comunicadas entre eles é através das mensagens de um protocolo de exterior routing, compartilhado em comum acordo por toda a comunidade dos AS. Este protocolo já foi o EGP (RFC 904), hoje é o BGP-4 (RFC 4271), e um dia (talvez, when the hell freezes over :-) ) venha a ser o IDRP (ISO/IEC 10747).

Mas as interconexões AS-AS mostram apenas a organização lógica da Internet. Por baixo disto (e muito mais obscura) está a estrutura física de encaminhamento do tráfego.
É um fato (e não só no Brasil) que a posse física dos meios de conexão interfere muito na maneira como as coisas ocorrem na prática.
Vamos ver, como exemplo, a RNP (ASN 1916).
 Ela é dona dos seus roteadores, mas os links que os conectam certamente não são de sua propriedade.
Então, no mapa que mostra a topologia da RNP (e também o seu "estado de saúde") em http://www.rnp.br/ceo/trafego/panorama.php, podemos ver que no nó principal de tráfego SP existem conexões para a Embratel (ASN 4230) e para a Global Crossing (ASN 3549).
Supondo que os roteadores destes dois AS também estejam localizados em SP, existe uma forte possibilidade que os dois links passem pela infra-estrutura da rede MPLS da Telefónica, e tenham caído juntos durante o meltdown.

O caminho alternativo de tráfego mais óbvio seria a conexão SP-RJ, mas se alguma parte física deste link também depender da rede MPLS da Telefónica, adiós.
Próxima alternativa seria rotear o tráfego via DF e MG (desde que o link SP-DF também não tenha caído junto com os outros), mas existe a possibilidade de congestionamento se a falha ocorrer em HMM.
Conclusão: se os administradores da RNP não planejarem com cuidado de quem eles contratam os seus links, a esperada resiliência do projeto lógico da rede vai pras cucuias.

Se este problema existe no nível urbano das maiores cidades do país, imagine o resto.
Quando se trata se provimento de enlaces interestaduais a quantidade de escolhas se reduz a meia dúzia de operadores, e nem todos os trechos que alguém gostaria de conectar possuem mais de um operador com caminhos físicos completamente distintos.
Saídas internacionais? Se vc precisa de banda de verdade (digamos, assim, algumas centenas de Mbps) a única alternativa prática são os cabos submarinos de fibras óticas.
No mapa disponível em http://www1.alcatel-lucent.com/submarine/refs/World_Map_2007_LR.pdf eu contei sete cabos de conexão internacional e um cabo de uso puramente doméstico.
A administração destes cabos geralmente é feita por consórcios, e aposto alguns destes consórcios operam mais de um cabo.

A conseqüência final é que os pontos de interconexão das redes tendem a ser colocados apenas nos locais onde o agregado de tráfego justifique o custo.
E é por isto que os grandes provedores de interconexão, que operam os AS de "passagem" para os pequenos provedores de interconexão (que fazem o varejo do negócio de acesso à Internet), cobram "pedágio".
Enquanto o tráfego da Internet for composto principalmente por aplicações best effort (ex.: http e smtp) estas "voltas do mar" que o tráfego tem de fazer para passar de um AS para outro não chegam a comprometer a performance (alguns milissegundos a mais ou a menos? No big deal).
Mas, quando houver um volume considerável de tráfego real-time, isto será um problema.
Será um problema grande o suficiente a ponto de forçar uma mudança neste estado de coisas? Depende de vários fatores, mas isto é assunto para outro post.

Ah! Só para terminar... Alguém aí sabe quais seriam os impedimentos técnicos de lançar um trecho de cabo submarino de Fortaleza a Belém, e um trecho "subfluvial" de Belém a Manaus? Isto daria um desafogo e tanto para a região norte, onde praticamente só se chega por satélite.

[ ]'s

J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (15) - Mapeando os "nossos" backbones (04) - Nova mensagem de José Smolka