[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