David Freeman-
We do have a native MPLS backbone and one of our provider does procide
MPLS CsC about 24 of our remote sites.
For about 12 of our other sites, the service providers only offer native
IP services.
Any reasons why you have a distaste for MPLSoGRE?
The Cisco TAC has actually told me they have more expertise and
experience with MPLSoGRE and has suggested the move away from L2TPv3.
Thanks for your feedback.
Regards,
Ge Moua
University of Minnesota
david.freedman at uk
Sep 25, 2009, 9:56 AM
Post #7 of 10 (18 views)
Permalink
Re: EoMPLS v L2TPv3 Remove Highlighting [In reply to]
-----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.
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: moua0...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
