Vinay Bannai | 2 Nov 2007 05:48

RE: : Ethernet transport versus MPLS transport

 >> snip <<

MPLS is one way to get around the limitations of the TCP/IP approach. Although MPLS can be used to interconnect layer 2 (TCP/IP model) subnets, the ultimate goal should be to replace these subnets with MPLS network segments, which can be seamlessly interconnected. Carrier Ethernet (specifically PBT) is a step backwards.

 

>>

 

 

Kevin,

 

Your assertion above in a previous email requires some justification.

We can take a position that MPLS is not required to connect various layer 2 technologies. L3 is there to provide seamless connectivity between various layer 2 technologies. I remember clearly the early 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 at 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 certain network scenarios. But I am little puzzled by your statement carrier Ethernet is a step backwards. By that token, isn’t MPLS a step backward from IP?

 

Regards,

Vinay Bannai

 

Kevin DeMartino | 2 Nov 2007 15:51
Picon

Re: : Ethernet transport versus MPLS transport

Vinay,
 
You are right, MPLS/GMPLS is also a step backwards. It moves away from IP-based transport and goes back to transport based on the OSI Reference 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 layer 2 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, respectively.
 
Since IP is a connectionless protocol, it has its limitations. TCP and 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 in 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 functions) 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 provides all the functionality needed for efficient transport. (However, it would 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 seams that go along with them.
 
Regards, Kevin
----- Original Message -----
Sent: Friday, November 02, 2007 12:48 AM
Subject: RE: [MPLS-OPS]: Ethernet transport versus MPLS transport

 >> snip <<

MPLS is one way to get around the limitations of the TCP/IP approach. Although MPLS can be used to interconnect layer 2 (TCP/IP model) subnets, the ultimate goal should be to replace these subnets with MPLS network segments, which can be seamlessly interconnected. Carrier Ethernet (specifically PBT) is a step backwards.

 

>>

 

 

Kevin,

 

Your assertion above in a previous email requires some justification.

We can take a position that MPLS is not required to connect various layer 2 technologies. L3 is there to provide seamless connectivity between various layer 2 technologies. I remember clearly the early 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 at 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 certain network scenarios. But I am little puzzled by your statement carrier Ethernet is a step backwards. By that token, isn’t MPLS a step backward from IP?

 

Regards,

Vinay Bannai

 

Ping Pan | 2 Nov 2007 18:05

Re: : Ethernet transport versus MPLS transport

Hi,

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 connectionless networks.

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 before. ;-)

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:
> Vinay,
>  
> You are right, MPLS/GMPLS is also a step backwards. It moves away from 
> IP-based transport and goes back to transport based on the OSI Reference 
> 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 layer 2 
> 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, 
> respectively.
>  
> Since IP is a connectionless protocol, it has its limitations. TCP and 
> 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 in 
> 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 functions) 
> 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 provides 
> all the functionality needed for efficient transport. (However, it would 
> 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 seams that 
> go along with them.
>  
> Regards, Kevin
> 
>     ----- Original Message -----
>     *From:* Vinay Bannai <mailto:bannai <at> pacbell.net>
>     *To:* 'Kevin DeMartino' <mailto:kevindemar <at> verizon.net> ; 'Shravan
>     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 transport
> 
>      >> snip <<
> 
>     MPLS is one way to get around the limitations of the TCP/IP
>     approach. Although MPLS can be used to interconnect layer 2 (TCP/IP
>     model) subnets, the ultimate goal should be to replace these subnets
>     with MPLS network segments, which can be seamlessly interconnected.
>     Carrier Ethernet (specifically PBT) is a step backwards.
> 
>      
> 
>     > > 
> 
>      
> 
>     Kevin,
> 
>      
> 
>     Your assertion above in a previous email requires some justification.
> 
>     We can take a position that MPLS is not required to connect various
>     layer 2 technologies. L3 is there to provide seamless connectivity
>     between various layer 2 technologies. I remember clearly the early
>     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 at
>     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 certain
>     network scenarios. But I am little puzzled by your statement carrier
>     Ethernet is a step backwards. By that token, isn’t MPLS a step
>     backward from IP?
> 
>      
> 
>     Regards,
> 
>     Vinay Bannai
> 
>      
> 

Serbest, Yetik | 2 Nov 2007 18:52
Picon

RE: : Ethernet transport versus MPLS transport


I personally see a use for PBB to resolve MAC explosion in the carrier's
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 that
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
necessities.

Thanks,
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

Hi,

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 connectionless
networks.

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 before. ;-)

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:
> Vinay,
>  
> You are right, MPLS/GMPLS is also a step backwards. It moves away from

> IP-based transport and goes back to transport based on the OSI
Reference 
> 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 layer
2 
> 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, 
> respectively.
>  
> Since IP is a connectionless protocol, it has its limitations. TCP and

> 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
in 
> 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 functions)

> 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
provides 
> all the functionality needed for efficient transport. (However, it
would 
> 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 seams
that 
> go along with them.
>  
> Regards, Kevin
> 
>     ----- Original Message -----
>     *From:* Vinay Bannai <mailto:bannai <at> pacbell.net>
>     *To:* 'Kevin DeMartino' <mailto:kevindemar <at> verizon.net> ; 'Shravan
>     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
transport
> 
>      >> snip <<
> 
>     MPLS is one way to get around the limitations of the TCP/IP
>     approach. Although MPLS can be used to interconnect layer 2
(TCP/IP
>     model) subnets, the ultimate goal should be to replace these
subnets
>     with MPLS network segments, which can be seamlessly
interconnected.
>     Carrier Ethernet (specifically PBT) is a step backwards.
> 
>      
> 
>     > > 
> 
>      
> 
>     Kevin,
> 
>      
> 
>     Your assertion above in a previous email requires some
justification.
> 
>     We can take a position that MPLS is not required to connect
various
>     layer 2 technologies. L3 is there to provide seamless connectivity
>     between various layer 2 technologies. I remember clearly the early
>     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
at
>     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
certain
>     network scenarios. But I am little puzzled by your statement
carrier
>     Ethernet is a step backwards. By that token, isn't MPLS a step
>     backward from IP?
> 
>      
> 
>     Regards,
> 
>     Vinay Bannai
> 
>      
> 

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

Ping Pan | 2 Nov 2007 19:17

Re: : Ethernet transport versus MPLS transport

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. :-)

2 cents,

- Ping

Serbest, Yetik wrote:
> I personally see a use for PBB to resolve MAC explosion in the carrier's
> 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 that
> 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
> necessities.
> 
> Thanks,
> 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
> 
> Hi,
> 
> 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 connectionless
> networks.
> 
> 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 before. ;-)
> 
> 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:
>> Vinay,
>>  
>> You are right, MPLS/GMPLS is also a step backwards. It moves away from
> 
>> IP-based transport and goes back to transport based on the OSI
> Reference 
>> 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 layer
> 2 
>> 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, 
>> respectively.
>>  
>> Since IP is a connectionless protocol, it has its limitations. TCP and
> 
>> 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
> in 
>> 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 functions)
> 
>> 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
> provides 
>> all the functionality needed for efficient transport. (However, it
> would 
>> 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 seams
> that 
>> go along with them.
>>  
>> Regards, Kevin
>>
>>     ----- Original Message -----
>>     *From:* Vinay Bannai <mailto:bannai <at> pacbell.net>
>>     *To:* 'Kevin DeMartino' <mailto:kevindemar <at> verizon.net> ; 'Shravan
>>     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
> transport
>>      >> snip <<
>>
>>     MPLS is one way to get around the limitations of the TCP/IP
>>     approach. Although MPLS can be used to interconnect layer 2
> (TCP/IP
>>     model) subnets, the ultimate goal should be to replace these
> subnets
>>     with MPLS network segments, which can be seamlessly
> interconnected.
>>     Carrier Ethernet (specifically PBT) is a step backwards.
>>
>>      
>>
>>     > > 
>>
>>      
>>
>>     Kevin,
>>
>>      
>>
>>     Your assertion above in a previous email requires some
> justification.
>>     We can take a position that MPLS is not required to connect
> various
>>     layer 2 technologies. L3 is there to provide seamless connectivity
>>     between various layer 2 technologies. I remember clearly the early
>>     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
> at
>>     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
> certain
>>     network scenarios. But I am little puzzled by your statement
> carrier
>>     Ethernet is a step backwards. By that token, isn't MPLS a step
>>     backward from IP?
>>
>>      
>>
>>     Regards,
>>
>>     Vinay Bannai
>>
>>      
>>
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 

Thomas D. Nadeau | 2 Nov 2007 19:40

Re: : Ethernet transport versus MPLS transport


> 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,  
and it
is in some ways, simpler to operate than other L3 technologies. This  
doesn't
mean that there are no advantages to using L3 technologies in a core  
network,
however.

	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  
customers
a combination of both services.  Along these lines, some of the more  
recent
technology proposals are likely to not fit in anywhere because when it  
comes down
to it, they are simply not OpEx/CapEx price competitive to the  
existing ones.
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  
compelling
BUSINESS CASE to do so.

	--Tom

>
>
> 2 cents,
>
> - Ping
>
>
> Serbest, Yetik wrote:
>> I personally see a use for PBB to resolve MAC explosion in the  
>> carrier's
>> 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  
>> that
>> 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
>> necessities.
>> Thanks,
>> 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
>> Hi,
>> 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  
>> connectionless
>> networks.
>> 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  
>> before. ;-)
>> 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:
>>> Vinay,
>>> You are right, MPLS/GMPLS is also a step backwards. It moves away  
>>> from
>>> IP-based transport and goes back to transport based on the OSI
>> Reference
>>> 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  
>>> layer
>> 2
>>> 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,  
>>> respectively.
>>> Since IP is a connectionless protocol, it has its limitations. TCP  
>>> and
>>> 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
>> in
>>> 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  
>>> functions)
>>> 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
>> provides
>>> all the functionality needed for efficient transport. (However, it
>> would
>>> 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  
>>> seams
>> that
>>> go along with them.
>>> Regards, Kevin
>>>
>>>    ----- Original Message -----
>>>    *From:* Vinay Bannai <mailto:bannai <at> pacbell.net>
>>>    *To:* 'Kevin DeMartino' <mailto:kevindemar <at> verizon.net> ;  
>>> 'Shravan
>>>    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
>> transport
>>>     >> snip <<
>>>
>>>    MPLS is one way to get around the limitations of the TCP/IP
>>>    approach. Although MPLS can be used to interconnect layer 2
>> (TCP/IP
>>>    model) subnets, the ultimate goal should be to replace these
>> subnets
>>>    with MPLS network segments, which can be seamlessly
>> interconnected.
>>>    Carrier Ethernet (specifically PBT) is a step backwards.
>>>
>>>
>>>    > >
>>>
>>>    Kevin,
>>>
>>>
>>>    Your assertion above in a previous email requires some
>> justification.
>>>    We can take a position that MPLS is not required to connect
>> various
>>>    layer 2 technologies. L3 is there to provide seamless  
>>> connectivity
>>>    between various layer 2 technologies. I remember clearly the  
>>> early
>>>    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
>> at
>>>    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
>> certain
>>>    network scenarios. But I am little puzzled by your statement
>> carrier
>>>    Ethernet is a step backwards. By that token, isn't MPLS a step
>>>    backward from IP?
>>>
>>>
>>>    Regards,
>>>
>>>    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
>

Ping Pan | 2 Nov 2007 23:06

Re: : Ethernet transport versus MPLS transport

My dear Mr. Nadeau,

Thomas D. Nadeau wrote:
> 
> 
>     A few points. First, "ethernet in the middle" is something that some
> carrier/SP environments like due to having a low cost of equipment, and it
> is in some ways, simpler to operate than other L3 technologies. 
> 

Does the cost of equipment have much to do with L2 and IP?

If we open up a box normally get deployed in metro networks, the box 
needs to satisfy the following:

1. Carrier-grade: the box needs to have some level of equipment 
protection capability, 1:1 or 1:N. This has nothing to do with router, 
switch, SONET, IP and Ethernet. This can be complex and expensive.

2. Protection and redundancy capability: As far as I can tell, the 
effort in developing and operating MPLS fast-reroute and Ethernet Link 
Aggregation at data path are practically identical.

3. Switching packets real fast: how much do we believe the extra cost in 
swapping MPLS labels comparing with switching on VLANS tags? With 
reasonable modern components, they are in the same cost range.

4. QoS: yes, many of the boxes in the area have extensive QoS features 
to operate in legacy services. Now Ethernet metro relies on 
over-provisioning, so there is not much need for QoS. But as Ethernet 
circuits carrying voice, video and data, QoS requirements will only go 
up on access links.

So, if the carriers want to build their Ethernet metro networks with 
switches from Fry's, I am sure it would be very cheap. But if they want 
to offer and sustain any reasonable service, I would think that they 
have to deploy boxes with carrier-grade, protection/redundancy, 
line-rate switching and some QoS. This has little to do with running 
Ethernet or MPLS at control-plane.

BTW, the boxes with Ethernet should be much cheaper than the ones with 
POS ports. This is simply due to the commercialization of Ethernet MAC 
technology. Once again, this has nothing to do with router vs. switch.

IMHO, MPLS running over Ethernet should give the similar cost benefit as 
Technology-XYZ over Ethernet. If you don't believe me, you should work 
for an equipment vendor. :-)

Take care!

- Ping

Kevin DeMartino | 3 Nov 2007 15:53
Picon

Re: : Ethernet transport versus MPLS transport

Ping,

For the most part, I agree with your response.

1. For carrier networks, a protection and restoration capability is 
required. Providing protection for LSPs can be a lot more efficient than the 
SONET ring protection that is currently used by carriers.

2. Restoration of LSPs can be fast if backup LSPs are predetermined. 
Resources need not be assigned to the backup LSPs until a failure occurs.

3. Swapping MPLS labels can be performed using relatively small lookup 
tables (several MB). Thus, label swapping can be straightforward, and it 
shouldn't have a major impact on complexity or cost.

4. QoS is a big problem for connectionless transport, which includes 
IP-based transport and Ethernet without tags. MPLS provides the best 
solution to the QoS problem. Of course, you can duplicate the MPLS 
capabilities using Ethernet tags.

There is nothing that makes layer 3 transport inherently more expensive than 
layer 2 (TCP/IP model) transport. Transport based on MPLS labels or Ethernet 
tags is basically the same. Of course, cost is affected by volume. So a 
particular approach may turn out to be less expensive than a competing 
approach if it catches on quicker.

Regards, Kevin

----- Original Message ----- 
From: "Ping Pan" <pingpan <at> pingpan.org>
To: "Thomas D. Nadeau" <tnadeau <at> lucidvision.com>
Cc: "Serbest, Yetik" <Yetik_Serbest <at> labs.att.com>; "Kevin DeMartino" 
<kevindemar <at> verizon.net>; "Vinay Bannai" <bannai <at> pacbell.net>; 
<mpls-ops <at> mplsrc.com>
Sent: Friday, November 02, 2007 6:06 PM
Subject: Re: [MPLS-OPS]: Ethernet transport versus MPLS transport

> My dear Mr. Nadeau,
>
> Thomas D. Nadeau wrote:
>>
>>
>>     A few points. First, "ethernet in the middle" is something that some
>> carrier/SP environments like due to having a low cost of equipment, and 
>> it
>> is in some ways, simpler to operate than other L3 technologies.
>
> Does the cost of equipment have much to do with L2 and IP?
>
> If we open up a box normally get deployed in metro networks, the box needs 
> to satisfy the following:
>
> 1. Carrier-grade: the box needs to have some level of equipment protection 
> capability, 1:1 or 1:N. This has nothing to do with router, switch, SONET, 
> IP and Ethernet. This can be complex and expensive.
>
> 2. Protection and redundancy capability: As far as I can tell, the effort 
> in developing and operating MPLS fast-reroute and Ethernet Link 
> Aggregation at data path are practically identical.
>
> 3. Switching packets real fast: how much do we believe the extra cost in 
> swapping MPLS labels comparing with switching on VLANS tags? With 
> reasonable modern components, they are in the same cost range.
>
> 4. QoS: yes, many of the boxes in the area have extensive QoS features to 
> operate in legacy services. Now Ethernet metro relies on 
> over-provisioning, so there is not much need for QoS. But as Ethernet 
> circuits carrying voice, video and data, QoS requirements will only go up 
> on access links.
>
> So, if the carriers want to build their Ethernet metro networks with 
> switches from Fry's, I am sure it would be very cheap. But if they want to 
> offer and sustain any reasonable service, I would think that they have to 
> deploy boxes with carrier-grade, protection/redundancy, line-rate 
> switching and some QoS. This has little to do with running Ethernet or 
> MPLS at control-plane.
>
> BTW, the boxes with Ethernet should be much cheaper than the ones with POS 
> ports. This is simply due to the commercialization of Ethernet MAC 
> technology. Once again, this has nothing to do with router vs. switch.
>
> IMHO, MPLS running over Ethernet should give the similar cost benefit as 
> Technology-XYZ over Ethernet. If you don't believe me, you should work for 
> an equipment vendor. :-)
>
> Take care!
>
> - Ping
> 

Padmavathi Chilukoori | 15 Nov 2007 13:47
Picon

: MPLS-OPS: WRR between LSP's

Hi,

          We would like to apply WRR (Weighted Round Robin)
 across LSP's on Cisco.
 Any idea about it? (Bandwidth for LSP's will be provided using    rsvp-te).

Thanks in advance,
Padmavathi.

Padmavathi Chilukoori | 19 Nov 2007 13:37
Picon

: WRR between LSP's

Hello,

We have a scenario as below; 

                                (LSR)                
( LER) [ A ]---------[ B ]======[ C ] (LER)
                            |
                            |
                          [ D ]
                               ( LER )

Following are the 2 signalled LSP's,

LSP1: A---B---C : with X bandwidth.
LSP2: D---B---C : with Y bandwidth.

These two LSP's are sharing the same link. ( Between LSR [B] and LER [c] ), Now,

1:  We want to gaurantee LSP1 with X bandwidth, and LSP2 with Y bandwidth.
    At LSR [B] how this bandwidths are gauranteed?  Is there any scheduler applied at [B] for this,
    if so how? what exactly " reservation " of BW means?

2:  If LSP1 is not utilizing its X bandwidth, then we want LSP2 to get that bw utilized.

How to implement this?
How branded routers like Cisco & Juniper (or any other's) deals with this concept?

Can the document  " DS-TE Requirements for Support of multiple-COS on an E-LSP"
( <draft-ganti-tewg-diffserv-multicos-elspreq-00.txt > ), guide us in this issue?


Thanks in advance,
Padma.


Gmane