[c-nsp] EoMPLS v L2TPv3

[David Freedman]

Well, if you are TAC supported, go for it, I don't like it because it is layering another control network over IP which adds more to the list of things to troubleshoot. You also have to watch your MTU.

Dave.


------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net



-----Original Message-----
From: Ge Moua [mailto:moua0100 at umn.edu]
Sent: Sat 9/26/2009 16:28
To: moua0100 at umn.edu
Cc: David Freedman; Michael Robson; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] EoMPLS v L2TPv3
 
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: 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/
>>   
>