Re: [c-nsp] EoMPLS v L2TPv3
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:moua0...@umn.edu] Sent: Sat 9/26/2009 16:28 To: moua0...@umn.edu Cc: David Freedman; Michael Robson; cisco-nsp@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: 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/
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: 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/
Re: [c-nsp] EoMPLS v L2TPv3
On Fri Sep 25, 2009 at 10:44:14AM +0100, 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? In my experience, a difference in which feature is supported on the hardware you've got. My gut feel is that EoMPLS has more hardware support than L2TPv3. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director|* Domain Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: i...@bogons.net * ___ 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/
Re: [c-nsp] EoMPLS v L2TPv3
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/
Re: [c-nsp] EoMPLS v L2TPv3
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/
Re: [c-nsp] EoMPLS v L2TPv3
Hi, On Fri, Sep 25, 2009 at 11:49:47AM -0500, Ge Moua wrote: 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? PFC3b cannot do MPLS-over-GRE (... at least not without the help of a SIP or ES line card) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpp7NwqZiiU2.pgp Description: PGP signature ___ 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/
Re: [c-nsp] EoMPLS v L2TPv3
-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: 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/ -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- ___ 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/
Re: [c-nsp] EoMPLS v L2TPv3
Gert- what about the 3cxl; we have some of those on hand too. Regards, Ge Moua | Email: moua0...@umn.edu Network Design Engineer University of Minnesota | Networking Telecommunications Services Gert Doering wrote: Hi, On Fri, Sep 25, 2009 at 11:49:47AM -0500, Ge Moua wrote: 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? PFC3b cannot do MPLS-over-GRE (... at least not without the help of a SIP or ES line card) gert ___ 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/
Re: [c-nsp] EoMPLS v L2TPv3
On Fri, 2009-09-25 at 12:36 -0500, Ge Moua wrote: Gert Doering wrote: PFC3b cannot do MPLS-over-GRE what about the 3cxl; we have some of those on hand too. Same thing, no MPLSoGRE. In almost all practical regards the PFC3C and PFC3B are the same. -- Peter ___ 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/
Re: [c-nsp] EoMPLS v L2TPv3
Hi, On Fri, Sep 25, 2009 at 12:36:37PM -0500, Ge Moua wrote: Gert- what about the 3cxl; we have some of those on hand too. Same. Difference between 3b and 3c is mainly MAC address table space, and xl vs. non-xl is table size for routing table entries (TCAM space), but it's the same EARL. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpMRn9q4bEZi.pgp Description: PGP signature ___ 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/
