Re: : Ethernet transport versus MPLS transport
Thomas D. Nadeau <tnadeau <at> lucidvision.com>
2007-11-02 18:40:26 GMT
> Agree entirely.
> Evolution is a key element for carriers. Just because we have IP,
> MPLS and Ethernet, the carriers will walk away from SONET overnight.
> Unless there is a strong incentive, it's not clear to me that the
> carriers should disturb the paying customers by moving to Ethernet.
> Similarly, Ethernet circuits have been in deployment for a number of
> years. For many carriers, Ethernet circuits are entirely L2 based. Q-
> in-Q is no longer capable of sustaining the growth. At the same
> time, changing the operation methodology with IP/MPLS could be
> costly, disruptive and, sometimes, confusing (or illegal) among
> carriers. So Mac-in-Mac (PBB) may not be a bad option. In theory,
> PBB may be simple to migrate into the existing L2 operation models.
> However, it is not clear to me that the adaptation of PBB is a
> statement about the acceptance of Layer-2 networking. If the
> backbone is IP/MPLS, and end-users are using IP, why should we have
> an all-L2 network in the middle? The ultimate goal for carriers may
> be of having a unified MPLS/GMPLS/IP control-plane that governing
> all sub-IP technologies (PBB, DWDM, SONET, WiMax etc.).
> IMHO, we should not confuse about a near-term migration solution
> with the long-term goal.
A few points. First, "ethernet in the middle" is something that some
carrier/SP environments like due to having a low cost of equipment,
is in some ways, simpler to operate than other L3 technologies. This
mean that there are no advantages to using L3 technologies in a core
Another important point to tease out of your comments earlier is
that from a carrier perspective, there are a number of uses of ethernet
technologies: backbone, access and aggregation, NNI and UNI. All
of these are in use today and have valid business models.
It should also be clear that layer-3 VPN services are still in high
demand and will not be going away anytime soon despite all of the recent
hype over deploying ethernet everywhere.
My final point is to not fall into the confines of believing
that one-solution-fits-all. Some providers are focusing on L2
or L3 services, but many (most I would say) are happy to sell their
a combination of both services. Along these lines, some of the more
technology proposals are likely to not fit in anywhere because when it
to it, they are simply not OpEx/CapEx price competitive to the
Long over are the days of over-deployment and deployment for the
novelty of some
technology. In order to go with something new, there has to be a
BUSINESS CASE to do so.
> 2 cents,
> - Ping
> Serbest, Yetik wrote:
>> I personally see a use for PBB to resolve MAC explosion in the
>> network. We have been providing Ethernet services for quite some time
>> now. Have we hit the wall? No, not yet. Will we? Possibly.
>> I also personally do not believe we need PBT. I agree with Kevin on
>> regard. The simple reason for me is this: it has been proposed to use
>> IS-IS for PBT. This sure looks like reinventing the wheel to me.
>> I am always for evolution. MPLS is a part of the evolution as Ping
>> mentions below (so is PBB I might add). I really don't believe in
>> designing a new best networking technology from scratch (look what
>> happened to ATM). One should evolve based on real incremental
>> yetik -----Original Message-----
>> From: Ping Pan [mailto:pingpan <at> pingpan.org] Sent: Friday, November
>> 02, 2007 12:06 PM
>> To: Kevin DeMartino
>> Cc: Vinay Bannai; mpls-ops <at> mplsrc.com
>> Subject: Re: [MPLS-OPS]: Ethernet transport versus MPLS transport
>> I think there may be some confusion here.
>> First, MPLS is an IP technology. Its entire control-plane uses
>> pretty much all the routing protocols for the best-effort
>> Second, at data-plane, MPLS introduces "tunnels" or connections in
>> the network. Note that MPLS runs in the carrier networks, where
>> deterministic traffic behavior is critical to the operators. It's
>> one thing to run all-IP in the enterprise and residential networks,
>> but it would be disastrous if the operators cannot control the
>> traffic within the backbone. MPLS LSP's and PW's are designed to
>> help the operators.
>> Third, MPLS can transport data traffic over long-haul networks
>> without introducing congestion and delay to user flows, while TCP
>> (over IP-only network) is bad for long-haul delay-sensitive data
>> transport due to its window sizing and ack's etc. So I have no
>> problem with running only TCP/IP within access networks, but just
>> cannot see how TCP would help the transport of video streams
>> between continents.
>> Finally, IMHO, MPLS is not about Layer 2 or Layer 3. Rather it's
>> about providing the best possible vehicle for the operators to
>> control and manage their networks. OSI laying concept is not a
>> religion. If it's for
>> the best interest of business, merging, splitting and overlaying
>> one or two or three layers should be fine, and have been done
>> BTW, just curious, if we run MPLS to manage all-Ethernet networks,
>> do we
>> still need Ethernet switches running mac learning, spanning tree,
>> loop-detection... Ooops, did we just get rid of one layer, formerly
>> known as MAC?
>> Take care!
>> - Ping
>> Kevin DeMartino wrote:
>>> You are right, MPLS/GMPLS is also a step backwards. It moves away
>>> IP-based transport and goes back to transport based on the OSI
>>> Model and back to a control plane based on common channel
>>> signaling, similar to the SS7 control plane.
>>> IP has proven to be a very effective method for interconnecting
>>> subnets, actually layer 2/3 subnets. Note that the subnet
>>> protocols include both packet framing and packet forwarding
>>> functions, which are
>>> associated with layer 2 and layer 3 of the OSI Reference Model,
>>> Since IP is a connectionless protocol, it has its limitations. TCP
>>> the layer 2/3 subnets compensate to some extent for the
>>> limitations of
>>> IP. The TCP/IP approach has been an expedient approach for
>>> overlaying data networks on top of the legacy telephone networks.
>>> However, MPLS
>>> conjunction with the Generalized MPLS control plane is a much
>>> better approach.
>>> With MPLS/GMPLS, the layer 2/3 subnets (and some of the TCP
>>> are no longer necessary. Thus, the seams along the subnets
>>> boundaries can be eliminated.
>>> I believe that MPLS in conjunction with the GMPLS control plane
>>> all the functionality needed for efficient transport. (However, it
>>> be desirable to enhance the functionality of the control/signaling
>>> protocols associated with the control plane.) I believe it is a
>>> bad idea to re-introduce layer 2/3 protocols and subnets, and the
>>> go along with them.
>>> Regards, Kevin
>>> ----- Original Message -----
>>> *From:* Vinay Bannai <mailto:bannai <at> pacbell.net>
>>> *To:* 'Kevin DeMartino' <mailto:kevindemar <at> verizon.net> ;
>>> N' <mailto:shravan.nagraj <at> gmail.com>
>>> *Cc:* mpls-ops <at> mplsrc.com <mailto:mpls-ops <at> mplsrc.com>
>>> *Sent:* Friday, November 02, 2007 12:48 AM
>>> *Subject:* RE: [MPLS-OPS]: Ethernet transport versus MPLS
>>> >> snip <<
>>> MPLS is one way to get around the limitations of the TCP/IP
>>> approach. Although MPLS can be used to interconnect layer 2
>>> model) subnets, the ultimate goal should be to replace these
>>> with MPLS network segments, which can be seamlessly
>>> Carrier Ethernet (specifically PBT) is a step backwards.
>>> > >
>>> Your assertion above in a previous email requires some
>>> We can take a position that MPLS is not required to connect
>>> layer 2 technologies. L3 is there to provide seamless
>>> between various layer 2 technologies. I remember clearly the
>>> days of MPLS (mid 90's). By then IP at layer 3 was successfully
>>> interconnecting the various layer 2s. A case can be made that IP
>>> layer 3 can do all the things that MPLS can do and much more.
>>> My point is not to beat up on MPLS. MPLS can have a role in
>>> network scenarios. But I am little puzzled by your statement
>>> Ethernet is a step backwards. By that token, isn't MPLS a step
>>> backward from IP?
>>> Vinay Bannai
>> The MPLS-OPS Mailing List
>> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
>> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml