[GTER] Traffic Engineering

[Reinaldo Penno]

Carlos,

concordo contigo..Como disse o Claus? (quando ainda estava na Embratel) em
uma palestra sobre otimizacao de trafego, sempre se pode fazer traffic
engineering, algumas ferramentas sao bem antigas e totalmente disjuntas do
tema MPLS. So que um backbone/provider dedica 0.0001% do seu tempo a isso.
Nao tem ninguem dedicado para fazer. 

Para falar a verdade, traffic engineering nao mais pertence ao grupo de MPLS
to IETF ja faz tempo, agora tem um sub-grupo dedicado a isso e os dois
drafts principais falam justamente sobre o que vc esta abordando, ou seja,
que o mais importante do traffic engineering e o estudo do seu proprio
backbone, coleta trafego, estatisticas, etc e entao depois se escolhe a
ferramenta ideal. E nao o contrario, ou seja, pega uma ferramenta/protocolo
e tenta ver o que da para fazer. 

Mais especificamente:

http://www.ietf.org/html.charters/tewg-charter.html


Overview and Principles of Internet Traffic Engineering

http://www.ietf.org/internet-drafts/draft-ietf-tewg-principles-02.txt

Framework for Internet Traffic Engineering Measurement

http://www.ietf.org/internet-drafts/draft-ietf-tewg-measure-02.txt

abracos,

Reinaldo




>-----Original Message-----
>From: Carlos Ribeiro [mailto:carribeiro at yahoo.com]
>Sent: Monday, May 06, 2002 9:01 AM
>To: gter at eng.registro.br
>Cc: Loureiro, Rodrigo; Penno, Reinaldo [SC9:T327:EXCH]
>Subject: Re: [GTER] Traffic Engineering
>
>
>On Mon 06 May 2002 12:08, you wrote:
>> Carlos, da próxima vez responderei em offline.
>
>Rodrigo, 
>
>Acho que não há necessidade disso. Flames à parte, a discussão 
>enriquece a 
>todos no grupo.
>
>De certa forma, concordo com o que o Reinaldo disse (mesmo que 
>ele também 
>seja do time dos fornecedores :-) Gostaria de colocar tudo sob uma 
>perspectiva mais ampla; a idéia não é defender um ou outro 
>fornecedor ou 
>tecnologia, mas fazer uma avaliação bastante fria e realista.
>
>O tema 'Traffic Engineering', e a própria forma como estamos 
>discutindo aqui 
>no grupo, ilustra uma diferença muito grande de perspectiva entre os 
>fornecedores de tecnologia (Unisphere, Nortel, e todos os 
>outros...) e os 
>verdadeiros usuários dessa tecnologia, dos quais temos vários 
>representantes 
>presentes na lista. Em meio a tanto 'hype', muitas vezes fica 
>difícil para 
>nós (potenciais clientes) distinguir o que realmente importa 
>daquilo é puro 
>marketing. Somente a discussão aberta, isenta de conceitos 
>pré-formatados, 
>vai nos permitir atingir a profundidade adequada ao tema.
>
>Sobre a sua resposta original: todos os pontos que você levantou são 
>importantes, especialmente se deixarmos de pensar em técnicas 
>específicas - 
>que são as soluções - para pensar nos requisitos técnicos e 
>operacionais. 
>Para cada problema, há várias soluções possíveis, umas melhores do que 
>outras, mas cada uma com seus pontos fortes e fracos. No 
>entanto, ANTES de 
>chegarmos a uma arquitetura non-blocking, wire-speed, 'onisciente' e 
>'onipresente', é preciso que seja feito o trabalho básico de 
>PLANEJAMENTO DE 
>TRÁFEGO. É ele quem nos diz se precisamos de baixa latência, 
>ou se uma espera 
>a mais não vai fazer mal nenhum... 
>
>Assim, de volta ao tema... acho que é importante discutirmos o que é a 
>engenharia de tráfego, independente do equipamento ou da arquitetura 
>específica de cada operadora. Qualquer que seja a tecnologia, 
>o tráfego 
>estará lá, e precisamos aprender muito sobre ele ainda. Espero 
>que possamos 
>utilizar este grupo - que tem horas de vôo suficientes para pilotar um 
>monomotor até Júpiter - para elevar o nível da discussão 
>técnica aqui na 
>terrinha.
>
>Espero que essas palavras sejam bem recebidas, e que não 
>estejamos começando 
>uma nova 'flame war', que ao final só consegue dividir e 
>esvaziar o grupo.
>
>
>Carlos Ribeiro
>CTBC Telecom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eng.registro.br/pipermail/gter/attachments/20020506/f7a1a3d7/attachment.html>