[GTER] Borda ideal para provedores

[Shine]

Felipe,

Vamos ver novamente inline...

Em 9 de maio de 2014 00:05, Felipe Trevisan <fetrevisan at gmail.com> escreveu:

> > 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.
>
Esta dificuldade que vc menciona não é maior do que a enfrentado por
> muitos provedores atualmente. Como se provisiona um novo cliente? O mesmo
> processo pode ser replicado. Grande parte é automatizado.
>
Observe que o operador de redes não é um engenheiro de redes sênior.
Olhando a sua tela, o provimento me parece complexo para um operador
junior, ele teria que ser treinado para provisionar.
Existe ainda o ponto que o operador do ISP tem total visibilidade da rede,
mas o sistema precisa ter auditoria, por ao menos duas razões:
1) não pode se confiar na integridade moral do operador.
2) erros de provisionamento ocorrem e velocidades equivocadas podem ser
provisionadas.
Dessa forma, acredito que a automatização seja o melhor caminho. Mas os
sistemas dos ISPs não são homogêneos e a integração meio que sai
customizada. Isso tem um custo considerável para o ISP dependendo da
complexidade do sistema.
Conclusão: não é impossível, mas no final isso vai limitar a parceria com o
ISP.

No momento que o provedor inicia seu relacionamento com o provedor de rede,
> ele define os produtos que vai oferecer, as velocidades e demais
> caracteristicas técnicas de cada um dos serviços. Define tambem valores
> para cobrar do cliente final, os textos que aparecem no site, o link para
> seu contrato de prestação de serviços, etc. Estes ultimos podem ser
> alterados pelo ISP livremente a qualquer tempo.
> Quando o cliente escolhe um determinado serviço daquele provedor, o sitema
> faz as associações automaticamente. No final do periodo o sistema emite um
> relatorio da quantidade de clientes em cada serviço e os valores que devem
> ser cobrados.
> Não tenho certeza se esclareci sua dúvida.
>
Não é isso... isso eu já sei. Como disse, o problema é auditoria e
controle, ter um relatório não integrado com o sistema do ISP não é o
melhor dos mundos. Dependendo do ISP isso pode ser muito difícil.
Minha opinião: precisa ter um modelo de gestão integrado com padrões claros
de integração.


> > 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?
>
1) A configuração de cada serviço é pré-configurada também através de
> service profiles (eu atualizei aquele ppt e isneri a imagem da configuracao
> de um service profile). Nele vc limita a quantidade de ip´s permitidos.
>
Esse é um mecanismo que gostaria de entender... supondo que o cliente pode
ter desde equipamentos de rede diversos. Ele pode ter um router, mas também
pode se conectar diretamente à porta... ou não?

Confesso que estamos no limiar do que consigo responder tecnicamente e
> talvez precise pedir ajuda.
> As informações do option 82 podem ser repassados ao ISP.
>
Para isso seu equipamento de rede precisa fazer o DHCP Relay e passar para
o servidor do ISP. OK, a gerência é aberta e isso em si é tecnicamente
possível. Mas se o operador errar não funciona. Não dá para confiar que o
ISP só tenha operadores de alto nível ou alto potencial...

2) Na VLAN dedicada ao provedor só vai haver o DHCP dele. As restrições são
> normalmente bloqueadas na porta do switch onde o cliente está conectado.
>
Você teria que ter perfis de filtro para cada ISP e limitar o escopo desse
filtro, senão o ISP faz a festa e exaure com o recurso do equipamento. Ou
seja, o sistema tem que ser muito bem amarrado para isso e ter perfis de
cada equipamento.

3) Não é o provedor que aloca o IP fixo do cliente? Ele teria de controlar
> de alguma forma.
>
Não, o que quis dizer é o cliente mudar a configuração dele de DHCP para um
IP fixo para ele usufluir de um IP fixo. Imagine que o ISP tem um monte de
assinantes, imagine o porre dele descobrir quem é o usuário que está
fazendo isso. Vai ter que descobrir o mac por sniffer e matar esse mac por
filtro. Isso é trivial para um engenheiro de rede com experiência, mas para
um operador novato...
Isso se o usuário for dos mais ingênuos... com a facilidade de scan e com
velocidade fica ainda mais simples burlar alterando macs e IPs... e aí a
auditoria de acesso vai pro espaço.
Tem solução? Claro que tem. O ISP pode usar um sistema que alimenta o pool
dado pelo DHCP e dinamicamente atualizar um filtro que permite que somente
os IPs alocados passem. Agora imagine esse filtro em uma conexão de
10G-40G. O ISP tem que ter então um equipamento que suporte essa banda, e
se integre com o sistema DHCP. Ou seja, tem custo para implantar, operar e
manter.

> 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.
> > Q-in-Q? O PTT pode entregar cada provedor em uma porta do PIX. Este é
> conectado ao switch de interconexão normalmente. Tanto faz se o ISP esta no
> rack do lado ou através do PTT.
>
Para suportar Q-in-Q, o PIX teria que suportar e ser configurado para isso.
Como não conheço a linha de negociação do PTT, vou deixar a pergunta em
aberto para outros participantes...


> > 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...
> Não, nao confiaria em uma unica conexao. O provedor deve ter duas
> interconexoes. O provedor de rede disponibiliza as duas portas, seja no
> mesmo local ou em locais alternativos. Isso sim se parece com o PTT. O
> provedor pode chegar em dois PEX e pedir duas portas, uma em cada um. O
> modo de chegar em cada PIX é de responsabilidade do provedor.
>
Veja, pelo modelo proposto, o acesso vai direto do usuário até o ISP. Se o
ISP está em camada 2 (VLAN), quais são os modelos técnicos de balanceamento
e controle? LACP é inadequado no meu entender, mas dizendo que seja assim,
como vai a camada 3? VRRP/GBLP/HSRP? Ou seja, o dilema fica com o ISP, que
tem que bolar mais um mecanismo para resolver...


> > Acho que entendi o modelo, mas ele traz uma série de desafios técnicos ao
> > provedor de serviços.
>
Não entendo porque. O que muda em relação ao que ele faz? Como deveria ser
> entregue a conexao do provedor de rede para minimizar o trabalho do ISP?
>
Essa é questão que ninguém ainda consegue responder e a tecnologia
disruptiva que precisaria ser pensada. Por isso que o modelo atual é o
provedor ter domínio de toda a cadeia, incluindo o acesso físico e é por
isso que o mercado é dominado pelas grandes teles que conseguem ser muito
mais competitivas...

> 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.
> De novo, o provedor já não tem este tipo de pessoal em seus quadros?
>
Ele tem, mas esse pessoal é extremamente sobrecarregado. Teria que
contratar alguém para integrar o sistema.

> Isso se ambos entendem as informações... o que eu não contaria como
> certo.
>
Bom, eu nao estava considerando isso como um problema. Talvez esta seja um
> dos pré-requisitos para o ISP poder particpar da rede.
>
Como te disse, tem gente muito mais qualificada do que eu nesta lista para
dar um parecer sobre isso... mas até um tempo atrás isso não era a regra,
era a exceção no ISP...

> 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.
> A condição para o sistema funcionar é justamente estar aberta ao provedor.
> Não tem como ser diferente. Por isso o sistema foi criado em torno disso.
> Deve ser esta a duvida com relação ao alto acoplamento que o Rubens
> mencionou. Estou certo?
>
Falando em termos mais coloquiais, alto acoplamento significa que os
elementos participantes tenham uma forte integração entre si. Não é
simplesmente ser aberta.
Se os sistemas não se integram, não há eficiência operacional e os custos
não se justificam em um ambiente competitivo.

> 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...
>
O CRM e a auditoria fazem parte do sistema do provedor de rede, sem isso
> nada funcionaria.
> No sistema estao concentrados os dados do cliente, endereços, serviços,
> provedores e todo o historico de contratacoes, cancelamentos, upgrades e
> trocas. Informacoes de ativações, bloqueios pro falta de pagamento,
> liberacao apos pagamento ter sido efetuado, mudanças de endereços, enfim,
> tudo concentrado na plataforma.
>
OK, mas qual o modelo de aplicação e integração na operação? Como
automatizar o provisionamento, o cancelamento, a alteração e a auditoria?
Você tem um modelo?
Existem muitos modelos de CRM, sem ter um modelo definido de integração
fica difícil mensurar a complexidade para adequar o sistema automatizado.

> 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?
>
Cada cliente esta conectado a uma porta. O procedimento é simples:
> ISP acessa o sistema
> Busca o cliente
> No Overview do cliente ele verá a porta e o switch onde o cliente esta
> conectado.
> Clicou no icone, o sistema faz uma consulta em tempo real ao switch e busca
> as informacoes. Vc fica sabendo na hora se a porta esta admin up, e com o
> cabo conectado, qual vlan, modo trunk ou access, trafego acumulado. Se ele
> estiver com DHCP ativado, ja ve o ip alocado ao cliente o mac address
> resolvido do que estiver conectado na ponta.
> Dependendo do switch, vc consegue fazer aquele teste para saber o estado
> dos cabos utp ou das fibras.
> O sistema mantem um grafico MRTG de cada porta ativa. Nesta mesma tela, o
> ISP poderia clicar e enxergar os graficos de consumo da porta, por dia,
> semana, mes e ano.
>
Eu não acho que o NOC do ISP tem esse tempo todo para ficar olhando
manualmente, se usa mais coisas como Nagios, Zabbix... o ISP também tem que
integrar e monitorar os agentes para esse serviço?

Existem algumas CPE homologadas. Se o cliente estiver conectado através de
> uma CPE, o ISP enxerga o CPE e todas as suas portas. Vai saber por exemplo
> qual VLAN esta associada em cada porta do switch, qual esta com cabo
> conectado, quais linhas de telefone estao associados a portas SIP,
> controlar o SSID e ativar, desativar SSID´s remotamente.
>
É mais um ativo para o ISP controlar e auditar...