[GTER] Borda ideal para provedores

[Shine]

Oi Felipe,

Obrigado pela paciência em discutir o assunto.
A minha participação aqui é puramente técnica, sem nenhum interesse ou
vínculo comercial. Eu não trabalho nesta área, o intuito é mesmo trazer
mais detalhes para me atualizar tecnologicamente.

Ainda tenho mais dúvidas, se você puder esclarecer para nós da comunidade
agradeço...

Em 8 de maio de 2014 18:43, Felipe Trevisan <fetrevisan at gmail.com> escreveu:

> Existe um intermediario neutro entre os provedores e a rede fisica. Podemos
> chamá-lo de "operador do unbundling". Esta entidade é responsável por rodar
> o software que adminsitra tudo. As redes físicas podem ser de sua
> propriedade ou de terceiros, contratadas por ele.
> O sistema usado compartilha as informações dos usuários com os provedores.
> Um provedor só pode ver seu cliente. Quando acessar um endereço que não é
> seu cliente, vai ver que existe um cliente com serviço, mas nao vai saber
> quem é o provedor daquele cliente nem qual serviço ele esta contratando.
> A mudança é feita automaticamente. Nao tem +Opex por conta disso.
> Justamente o contrario, reduz opex pela automação. Tecnicamente a mudança
> que ocorre é apenas o reprovisionamento da VLAN adequada na porta do
> cliente.
> Se o cliente tem o serviço do ISP x e este ISP usa a VLAN x dentro da rede,
> o sistema envia um comando diretamente ao switch para mudar a porta do
> cliente, por exemplo a fa0/10 da VLAN x para VLAN y. Simples e rápido. Tudo
> é registrado e pode ser auditado.
>
Desculpe eu não fui claro... estava falando de ter um opex para o provedor
de serviços.
Ele vai ter que ter um procedimento operacional para cuidar da gestão da
rede, de registrar o cliente, de correlacionar o cliente dele com o serviço
prestado pelo provedor de rede.
Sei que não é relacionado diretamente com a sua estrutura, mas imagino que
seja um desafio operacional para o provedor de serviço.


> Normalmente quem opera o DHCP é o provedor. O cliente passa pela rede do
> provedor de rede de forma transparente até os roteadores do ISP. Esta
> estrutura do ISP que gerou a duvida inicial desse thread.
> Existe uma opção no sistema para o provedor cadastrar seu bloco de IP para
> cada tipo de serviço e o sistema do do "operador do unbundling" administra
> e mantem os logs. Não é comumente usado mas daria para ser feito.
>
Na verdade se o DHCP passa transparente, o provedor de serviço tem que ter
um servidor DHCP na VLAN correspondente. Esse design tem alguns desafios
que precisam ser pensados, só para citar alguns:
1) como restringir o acesso de vários clientes na mesma vlan? Claro que em
termos de velocidade ele já se provisiona, mas vamos pensar que a conexão
na vlan pode ter um bridging no cliente e ele pode ver vários dispositivos.
Como o provedor de serviços vai diferencial por qual circuito passa cada
cliente, como ele vai fazer o dimensionamento de pool? Existem alternativas
como relay e option 82, mas é em cima de rede roteada e aí tem implicação
de estrutura de camada 3.
2) como evitar um rogue DHCP na rede?
3) como evitar que um usuário use IP fixo e gere problemas de duplicação na
rede?

   - Eu tenho mais dúvidas ainda. Como acoplar a rede dos provedores?
>       - O provedor tem um ou mais pontos de interconexao com os
>       equipamentos do provedor de rede. Pode ser feito através do PTT
> inclusive.
>
Bom, assumindo que ele recebe uma rede camada 2 do cliente diretamente,
acho que não dá para usar PTT não... com a palavra os mestres da lista.


>       - Porque haveria redundancia entre os provedores? O provedor deve
>       manter seus equipamentos funcionando. Pode optar por se
> interconectar em
>       mais de um ponto, mas a interconexao entre estes dois pontos do ISP
> é de
>       responsabilidade dele.
>
Você confiaria em uma única conexão entre o provedor de serviço e o
provedor de rede? Manter equipamento funcionando é obrigação, claro, mas
acho que o cliente não vai esperar reparar um equipamento de core ou uma
fibra que interliga o provedor de serviço e o provedor de rede...


>       - Essa duvida faz parte da duvida inicial de como montar a borda
>       ideal. Este é um problema para o ISP resolver que eu estou querendo
> saber
>       como fazer tambem. O provedor de rede vai dar o tubo, a mágica é
> com o ISP.
>
Acho que entendi o modelo, mas ele traz uma série de desafios técnicos ao
provedor de serviços.

      - Voce pode me envair as duvidas, ou entao marcamos um call.
>
Sem call... a dúvida não é para mim, mas para a comunidade. ;)


> *Se houver problemas na rede de acesso.
>       - Atualmente, se seu provedor te deixar na mao, vc liga no noc dele e
>       abre um chamado, depois acompanha o ticket.
>       - Aqui vc vai acompanhar o ticket sem precisar abrir o chamado, pois
>       voce terá acesso direto na mesma base de informação que o
> responsavel por
>       arrumar a rede (supondo que seja um problema de rede).
>
Mas operacionalmente o provedor de serviços precisaria de um staff técnico
de alta qualificação para poder acompanhar o problema... no final isso gera
mais custo para o provedor de serviço.

      - Nao tem filtro. A informacao trocada entre o provedor de serviços,
>       o operador do unbundling e o prorietario de rede é vista por todos.
> Todos
>       ficam ao par do que ocorre. Um novo tipo de relacionamento.
>
Isso se ambos entendem as informações... o que eu não contaria como certo.



>       - O ticket vai conter as informacoes. Elas sao enviadas pelas equipes
>       responsaveis. O coordenador das equipes de campo pode alimentar o
> sistema.
>       - Tem razão. A experiencia mostra que a maior parte dos problemas são
>       resolvidos pelo atendimento nivel 1 dado pelo proprio ISP quando
> o cliente
>       liga. O ISP nem abre o ticket no sistema compartilhado pois
> resolve dentro
>       de casa.
>       - Caso efetue todos os testes e não consiga resolver dentro de sua
>       estrutra, o ISP abre um ticket na plataforma e imediatamente é visto
> por
>       outros envolvidos.
>
A idéia de deixar a plataforma aberta ao provedor de serviços é
interessante, mas isso demanda ter staff técnico adequado. E isso tem custo.


>    - O modelo seria por tempo de serviço ou por quantidade de dados?
>       - Este é um controle do ISP. O uso da rede é por usuario/por
>       serviço/por velocidade.
>       - Exemplo: um tubo de 100 Mb poderia custar 100 reais, o de 200Mb 200
>       reais. IPTV adiciona mais 20, VOIP adiciona mais 5.
>
OK, simples. Mas dizendo que ele altere a velocidade por demanda do
usuário, isso precisa ter um sistema CRM bem sincronizado, fora um sistema
de auditoria... não me parece simples para o provedor de serviço, mas acho
que os colegas da lista estão mais atualizados do que eu... quem sabe
alguém escreve um artigo me dizendo o que evoluiu nesses anos...


>       - Como o sistema faria a auditoria de uso?
>       - O sistema é todo auditável. O provedor de rede somente monitora o
>       trafego das portas e se elas estao de pé. Garante que não haja
> gargalos
>       entre os nós, fazendo os upgrades neessários quando a capacidade
> demandar.
>    - Como seria a qualificação da qualidade de serviço, como seria a tomada
>    de métrica do serviço?
>       - Pode haver uma configuracao geral dizendoq ue VLANs de voz tem
>       prioridade sobre as de dados dedicados, que tem prioridade sobre as
> de
>       dados compartilhados. Este tipo de filtro só é ativado se houver
> gargalo. A
>       idéia é que não haja gargalos.
>    - Coisas como jitter, latência, taxa efetiva de transferência de dados
>       - Mesmo caso da resposta acima.

Então suponho que o provedor de serviço tenha acesso a uma ferramenta do
sistema que emula uma consulta SNMP nas portas e somente nas portas que ele
locou com o provedor de rede? E como isso é feito? O sistema emula um
serviço SNMP no espaço de gerência onde somente as portas locadas para o
provedor estão conectadas em tempo real?