[GTER] Borda ideal para provedores

Thu May 8 01:41:31 -03 2014

O Bruno anda meio pessimista com o negocio. :-) Todas as operadoras usam
last mile de terceiros. Isso é normal. E a idéia é muito mais profunda, é
uma rede de acesso compartilhada com todo os sistemas de suporte para tanto.

O acoplamento complexo é resolvido justamente pelo sistema de gestão e
controle, feito exclusivamente para isso. Podemos agendar testes para quem
quiser conhecer.

Shine, a operação é mais simples do que colocou. O circuito é provisionado
com velocidade já ajustada.
Se o provedor do Shine estiver na VLAN 100 por exemplo, a porta do cliente
é provisionada com a VLAN100 e velocidade já ajustada para por exemplo 30mb
down e 10 mb up.
O Provedor passa a enxergar o cliente, dentro da velocidade acordada, e no
cadastro do cliente é associada a porta de conexão. Se ele estiver
conectado na porta fa0/2 do switch 10.10.10.10, o cadastro dele tem a
informação:

Cliente A no ponto de acesso 10.10.10.10-0-2.

Fiz uma apresentacao rapida de algumas telas do sistema para ilustrar o que
estamos falando: http://bit.ly/screenshots_rede

Por isso a duvida inicial: como montar uma borda para operar em um ambiente
onde a rede de transporte é operado por um terceiro? O provedor vai
precisar administrar suas conexões com a internet e também o controle mais
detalhado dos seus clientes. Vai precisar controlar os IP´s cedidos aos
clientes (DHCP) e manter log das conexões.

*Se houver problemas na rede de acesso.

Se os equipamentos sairem do ar por rompimento de fibras, por exemplo, o
sistema alarma e um icone é colocado ao lado do nome do switch. Quando o
cliente ligar para o provedor para reclamar que esta sem serviço, este
consultará o sistema e o cadastro do cliente e ali constará o equipamento
onde o cliente esta conectado com a informacao de alarme ao lado.
O provedor poderá informar imediatamente que há problemas na rede e
detalhes como previsão de retorno, que constarão no ticket.

*Cobrança dos serviços

A cobrança é feita através de uma unica NF. O provedor de serviços (ISP)
cobra o cliente diretamente. O provedor de rede cobra o ISP.
O cliente nao cai em venda casada, ao contrario, ele tem total liberdade
para contratar o serviço de internet do ISP "y" e telefone do ISP "x".

Abs,

2014-05-07 0:47 GMT-03:00 Shine <eshine at gmail.com>:

> 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...
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>