[c-nsp] EoMPLS v L2TPv3
David Freedman
david.freedman at uk.clara.net
Fri Sep 25 12:56:54 EDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think the choice is simple.
If you have a "native" MPLS backbone, use EoMPLS.
If you don't, then don't, use L2TPv3, please don't do MPLSoGRE,
it is more trouble than it is worth.
That said, can you not build out a native MPLS network? does your
provider not give you the ability to do this?
Dave.
Ge Moua wrote:
> David Freedman-
> Do you have a preference of one over the other? I've been thinking
> about the option of replacing our L2TPv3 deployment with EoMPLS (ie,
> Cisco's ATOM model).
>
> We are using Cisco 7203 with NSE engine for L2TPv3 acceleration; but I'm
> not a big fan of this platform; we have 3bxl-sup720/cat6k at the core
> that can do MPLS in hardware; I was just thinking of using GRE to
> encapsulate the MPLS packet over to the spoke sites (thereby bypassing
> the need to do MPLS end-to-end); this would allow EoMPLS over service
> providers' native IP infrastructure.
>
> Feedback?
>
>
>
> Regards,
> Ge Moua | Email: moua0100 at umn.edu
>
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
>
>
>
> David Freedman wrote:
>> Wow, this is actually a tricky question, so I'll jot down some points
>> for you to think about from the top of my head (and anybody, please feel
>> free to correct these if they are wrong, they may be out of date)
>>
>> EoMPLS:
>>
>> - Requires end-to-end MPLS LSP
>> - Does not support path fragmentation (need wider MTU end-to-end)
>> - Hardware support good
>> - OAM available
>> - Closer ties with MPLS-TE
>> - some vendors have attachment circuit interworking
>> - some hardware vendors may not be happy about attachment circuit MTU
>> mismatch
>>
>>
>> L2TPv3:
>>
>> - Only requires IP (but has some rudimentary security (Cookie))
>> - "Path" Can be encrypted by IPSEC (this is actually a moot point, even
>> in a world where stuff like draft-raggarwa-mpls-ipsec wasn't
>> implemented, you can still encrypt the payloads of both technologies)
>> - Not well supported in hardware, lots of restrictions
>> - interworking support in hardware poor
>> - lack of proper OAM
>>
>>
>>
>> Dave.
>>
>>
>> Michael Robson wrote:
>>
>>> What is the added benefit of running an EoMPLS pseudowire across an MPLS
>>> cloud over an L2TPv3 tunnel over the same cloud?
>>>
>>>
>>> Michael
>>>
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkq89lUACgkQtFWeqpgEZrJgJQCgyiBbfxBZocdqUj438BmceLZh
fI8Anjz17oKLUcgsVlU4Xezwwhm8CAn6
=R75n
-----END PGP SIGNATURE-----
More information about the cisco-nsp
mailing list