[GTER] Borda ideal para provedores

[Shine]

Felipe,

Eu vou divagar somente nas questões técnicas do acesso, o modelo de
negócios tem gente muito mais tarimbada do que eu... ;)
No fundo vou mais questionar do que dar exatamente uma solução. Minha
experiência com acesso já data de um bom tempo, acredito que estou
ultrapassado... ;)

Funcionaria assim:
> Em um ponto de interconexao, o provedor de serviços se conecta ao provedor
> de rede fisicamente e ganha uma ou mais VLAN´s dentro da rede do provedor
> de rede.
> O provedor de rede (ou ultima milha) assume a partir dai.
> Quando o cliente opta por este provedor de serviços, o provedor de rede
> provisiona a VLAN daquele provedor na porta do cliente. Provisiona as
> configurações padroes do serviço, como limites de velocidades, mac
> permitidos, etc.

Feito isso, o provedor de serviços passa a enxergar em sua rede seu novo
> cliente.
> Através do sistema de gestão compartilhado, o provedor de serviços tem
> acesso as mesmas informacoes do provedor da rede em tempo real. Ele
> consegue acessar o equipamento onde o cliente esta conectado, testar as
> portas, reprovisionar, suspender, alterar serviço etc.
>
Bem, aqui eu entendo que é relativamente fácil olhando somente a rede. Você
pode criar "roles" de administração, dando flexibilidade para o provedor de
serviços executar as alterações de políticas e com os logs fica fácil
identificar e gerar o ticket para proporcionalmente cobrar ou descontar um
upgrade ou um downgrade do serviço.
O que eu acredito poder assumir é que o provedor de serviços fornece a
saída. Assim, a parte de prover o endereçamento parece ter mais lógica em
ser o provedor de serviços.
Aqui uma definição mais clara do modelo de acesso precisa ser dada:
1) Você poderia simplesmente fornecer conectividade e o provedor de
serviços teria que se utilizar de algum meio para prover o acesso, seja via
DHCP, PPPoE, etc.
2) Ou você forneceria o modelo de acesso (DHCP, PPPoE por exemplo) e
repassaria os tickets de acesso para o provedor de serviços (ele precisa
ter rastreabilidade do acesso por exigências legais). O provedor de
serviços por sua vez passaria blocos IPs e os modelos de acesso que ele
operaria. Não é uma tarefa muito trivial gerenciar tickets de acesso no
plano operacional, o modelo precisa mesmo ser bem definido.
1 não parece ser muito interessante para o provedor de serviços pela falta
de serviços integrados e 2 é tecnicamente complexo, principalmente na parte
operacional.
É o que o Rubens cita do alto acoplamento de rede. Não é simplesmente
ligar, mas ter um sistema gerencial e operacional extremamente integrado
para lidar com a complexidade operacional de provisionamento. E lembrar que
os sistema precisa ser flexível o bastante para não criar um system-lock
(ou seja, você ficar refém da tecnologia e não ter a flexibilidade de mudar
seja para modernizar ou mesmo migrar para outros sistemas de
acesso/gerência).

Um chamado aberto no sistema é automaticamente propagado para todos os
> stakeholders deste ecossistema, desta forma o provedor nao liga para o NOC
> do provedor de rede, ele terá acesso direto a mesma informacao que o
> provedor de rede tem e verá o desdobramento de tickets e O.S.´s da mesma
> forma.
>
Bem, ter a visibilidade da rede é bom, mas dizendo que o problema fosse
algo na estrutura do provedor de rede, qual seria o processo? Como seria a
coordenação entre os NOCs? Um problema pode ser simples, mas também pode
exigir um processo mais elaborado de troubleshooting. Custos operacionais
para manter uma equipe de alto nível para qualquer tipo de chamado também
não me parece ser algo muito factível no modelo de negócios...


> Já que não é parecido com o PIX, vou dizer que é parecido com os provedores
> dial-up de antigamente.

É, podemos dizer que sim, mas tem diferenças significativas. No discado
ninguém precisava falar de selecionar velocidade.
Eu gerenciei um sistema de acesso em banda larga que era baseado
multi-provedores de serviço. Basicamente se fazia a diferenciação do
cliente usando um esquema de PPPoE e "conteineres" de acesso do provedor de
serviço que eram dinamicamente alocados no equipamento de acesso,
simplemente usando hashing. Por exemplo, o cliente logando
username at provedor1 se autenticava no sistema radius do provedor de
serviços, identificado pelo hash do login. E uma vez dado acesso ele
entrava no container do provedor de serviços.
Funcionava perfeitamente do ponto de vista técnico da rede, mas tinha
também suas desvantagens, principalmente quando pensávamos do ponto de
vista operacional.
1) Tinha que ter um cliente PPPoE no cliente. E muitas vezes o problema de
acesso estava nesse cliente, que não é muito prático de configurar para um
usuário leigo. Isso exigia um custo operacional de suporte significativo.
Acredite, existem muitos problemas diversos, por exemplo poderia alguém ter
um upgrade do MacOS Lion para o Maverick automático e aí o acesso parava (é
fictício, apenas para exempificar, OK? ;) )
2) Tinham problemas de furto e venda de logins de usuários com melhores
perfis de acesso.
3) Exigia um alto nível de integração de sistemas, já que o registro de
login continha os perfis de acesso, mas ao mesmo tempo o mapeamento do
acesso precisava ser repassado ao provedor de serviços.
4) Por ser um sistema de autenticação integrado e monolítico, eventuais
problemas com esse sistema, seja no lado do provedor de serviços ou da rede
geravam confusões frequentes com os clientes.
5) problemas em infraestrutura de interconexão dos provedores de serviço e
rede exigiam um staff altamente qualificado de ambos lados, o que não era
sempre possível no mesmo tempo.

Existem muitos prós e contras nos sistemas centralizados contra os sistemas
distribuídos e vice versa. Sistemas centralizados são menos resilientes,
mas apresenta a vantagem da simplicidade operacional. Não existe um modelo
ideal para tudo, mas um modelo que encaixa melhor na realidade do seu
negócio.
Eu diria que como sua proposta é ter um modelo de acesso de altíssima
velocidade, o modelo distribuído parece ser interessante por deixar o
controle do tráfego mais na borda. Mas precisa ter em mente como vai ser o
modelo de gerência, qual o nível de resiliência, qual o plano de
contingência de acesso e backup. Por regra, mais escalável e resiliente =
maior custo. E entender a conexão com o provedor de serviços, se pode ser
distribuído, se ele tem muitos POPs, qual a dimensão desses POPs. Nem
sempre a infra vai estar lá disponível e seria no mínimo recomendável fazer
o survey do que pode ser entregue para o cliente antes de ofertar...

Os clientes são dos provedores e o suporte de primeiro nivel é dado por
> eles.
>
E quem vende o acesso, o provedor da rede? Ou de serviços?

A informacao de faturamento é emitida pelo sistema. Um arquivo é exportado
> e pode ser importado pelo provedor de serviços para emitir suas NF´s. Uma
> integracao com gateways de pagamento permite que os provedores de serviço,
> caso desejem, enviem as cobrancas direto para o cliente final, restando
> apenas a emissão das NF´s pelo provedor.
>
Eu não sei se o cliente entende esse modelo de duas NFs. Me lembra aquelas
discussões de venda casada que tivemos no passado...