[GTER] GTER/14 - Artigo sobre MPLS # IPsec VPNs

[Reinaldo Penno]

comentarios no texto.

>-----Original Message-----
>From: adailton at icomnet.com.br [mailto:adailton at icomnet.com.br]
>Sent: Tuesday, April 09, 2002 9:21 PM
>To: gter at eng.registro.br
>Cc: roosevelt at juniper.net
>Subject: Re: [GTER] GTER/14 - Artigo sobre MPLS # IPsec VPNs
>
>
>Cópia Joao Carlos Mendes Luis <jonny at embratel.net.br>:
>> Oi,
>
>Oi Jonny,
>
>Considerando apenas as questões técnicas, independente da religiosas...
>
>> Eduardo Ascenco Reis wrote:
>> > ontem após a apresentação do Roosevelt Ferreira - Juniper 
>Networks -
>> > "Carrier-based MPLS VPNs" foi questionado pelo Jonny o uso 
>de MPLS #
>> IPsec
>> > para implementação de VPNs. Para complementar a discussão, sugiro a
>> > referência de um artigo interessante da revista Packet da Cisco:
>
>O IPSec definitvamente não substitui o MPLS porque, apesar da 
>VPN, não visa 
>Controle de Tráfego, Transporte e QoS; assim como MPLS não 
>substitui IPSec 
>porque não visa o aspecto segurança (não autentica cabeçalho e 
>nem criptografa 
>payload). Ou seja, mesmo considerando o aspecto "tunelamento", 
>ambos têm 
>propósitos completamente diferentes.

Existem outros protocolos de tunelamento sendo discutidos no caso de MPLS
VPNs, uma deles eh L2TPv3, que no caso ja existe um padrao para transporte
de IPSec, tem campo de demultiplexacao e eh "multiprotocolo". 

>
>>     Só para esclarecer:  Minha pergunta não foi referente ao uso
>> conjunto de MPLS e IPSEC.  Resumidamente, eu queria saber o que o 
>> MPLS fazia que outras formas de tunel não fazem, e que ele não 
>> substituia IPSEC em relação a segurança "contra" o provedor de 
>> backbone, e o Roosevelt disse que poderia ser
>> usado IPSEC sobre MPLS.  Até agora as desculpas são:
>> 
>> 1) Desempenho - Não faz mais diferença, todo mundo está 
>usando hardware
>> IP switching e a diferença de desempenho praticamente não existe.
>
>Comparado com as redes convencionais, o desempenho é 
>melhorado. Devido às 
>facilidades do MPLS, as redes de nova geração estão sendo 
>implantadas com as 
>tecnologias (IP+MPLS) sobre C/D-WDM. Esse é um fato.

A pergunta da Jonny estava relacionada a comutacao de pacotes, esse era um
dos argumentos originais do MPLS. Nao existe nenhum aumento de performance
em relacao a isso. Eu acho que ninguem mais acredita nisso, apesar que no
inicio muitos acreditavam e muitos equipamentos foram vendidos sob esse
pretexto.

>
>> 2) Controle de QoS - Realmente, pode-se fazer um controle de 
>QoS fim a
>> fim mais facilmente com o MPLS, mas ainda não vi ninguem 
>usar MPLS por causa
>> disso.
>
>Tem operadora no Brasil que já utiliza MPLS. 

Para Traffic Engineering? 

>
>Só o fato de se poder criar VCs (uma LP virtual) da mesma 
>forma que criamos um 
>PVC no Frame Relay ou ATM é inédito em IP. Sim, é possivel obter um 
>comportamento de uma LP virtual usando DiffServ/DSCP (PHB) com 
>serviço premium, 
>mas não escala. Por isso DiffServ também é utilizado em 
>conjunto com MPLS. 

MPLS eh um protocolo de tunelamento como outro qualquer eh os ultimos IETF's
mostraram isso. Vc so "consegue criar VCs (uma LP virtual)..." simplesmente
porque existem ferramentas de provisionamento para facilitar sua vida. Vc
poderia fazer a mesma coisa com IP-in-IP, GRE, L2TP e outros se existissem
as feramentas necessarias. A unica coisa relamente necessaria sao as
extensoes de OSPF (TE).

>
>Além de se poder utilizar AToM (Any Transport over MPLS), como 
>apresentado pelo 
>Roosevelt.

desculpa mas isso eh papo para marketing...


>
>> 3) Engenharia de Trafego - Alguem ai usa MPLS sem LDP ou BGP?   ;-)
>
>Mas LDP faz parte da arquitetura MPLS!

mas com LDP vc nao consegue CR-LSPs. 

>
>>    Mas, por favor, não vamos recomeçar essa discussão.  O assunto é
>> quase religioso... 
>>                                         Jonny
>
>Abraço,
>Adailton Silva
>--
>GTER list    http://eng.registro.br/mailman/listinfo/gter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eng.registro.br/pipermail/gter/attachments/20020410/23fec339/attachment.html>