IET
Decrease font size
Increase font size
Topic Title: ethernet layer 2 vs mpls
Topic Summary:
Created On: 19 March 2014 07:22 PM
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
View similar topics View similar topics
View topic in raw text format. Print this topic.
 19 March 2014 07:22 PM
User is offline View Users Profile Print this message



mruser

Posts: 2
Joined: 19 March 2014

Hi - first post here. Didn't get any good answers on another forum. I am a telecom professional but have a Customer asking me for Layer 2 Ethernet service for their WAN. We do EoMPLS but I never considered this a Layer 2 service since it is handled by a Layer 3 protocol. Question is, would you still call EoMPLS "Layer 2 Ethernet"?

Thanks for any help!
 20 March 2014 12:24 AM
User is offline View Users Profile Print this message



jakegreenland

Posts: 66
Joined: 04 May 2009

Largely depends what side of the P/C equation you sit on. From a customers perspective a port based draft-martini or draft-kompella pseudowire is basically a layer2 link between two remote endpoints and should for all intents and purposes offer a similar degree of transparency as, for example, a QinQ presentation would but doesn't offer the low latency of a DWDM wave or the ability of a dark fibre to be multiplexed using WDM.

So from the C side of the equation all the CE device sees is a layer2 connection to the CE at the other end of the link [or multipoint in the case of VPLS].

However from the PE device you're actually presenting a port using MPLS, a label transport protocol like LDP or RSVP in conjunction with MP-BGP and a whole bunch of other L3 bits going on so from the P side of the equation it's very much a service running at Layer3-ish.

Essentially MPLS L2 VPNs are a way or providing point to point layer2 connectivity over an MPLS network which usually then relies on some layer3 information to establish reachability and routing. They also don't come with the other L2 complications that things like QinQ do so tend to scale better and be more resilient if done properly.

So providing your customer just wants L2 connectivity between 2 points and your service will be MTU transparent to them then functionally your MPLS service is no different to providing a piece of ethernet cable between the sites, just with a somewhat higher latency and hopefully more resilience.

HTH

-------------------------
Jake Greenland, CEng MIET.
CCIE #22595
 20 March 2014 04:15 PM
User is offline View Users Profile Print this message



mruser

Posts: 2
Joined: 19 March 2014

You answered it. It is indeed the latency penalty I'm concerned with. Also, I will assume that there is no significant payload penalty for the additional packaging, since that didn't jump up in your mind. I also appreciate that there are some engineering semantics involved but wanted to get an outside opinion.

I think I am going to like this site. Will need to spend some time seeing what I can help answer in order to play it forward.
 25 March 2014 03:46 PM
User is offline View Users Profile Print this message



jakegreenland

Posts: 66
Joined: 04 May 2009

Well there is a packaging overhead but it's not huge. Basically you've got 4 bytes for the tunnel label and then another 4 for the VC label and then the control word is optional in some cases but is another 4 bytes if present.

Ultimately, however, I'd prefer to rely on an MPLS LSP for my layer2 services than a qinq tunnel because the former can have multiple backup paths and things like fast reroute whereas the latter relies on spanning tree for meshed redundancy ...

-------------------------
Jake Greenland, CEng MIET.
CCIE #22595
Statistics

See Also:



FuseTalk Standard Edition v3.2 - © 1999-2014 FuseTalk Inc. All rights reserved.