Luca Martini, Level 3

COMMENTS

Newest First | Oldest First | Threaded View

Page 1 / 10 > >>

Mark Seery 12/5/2012 | 3:35:03 AM

re: Luca Martini, Level 3 I had reason to revisit this question recently as part of some broader issues I am looking in to, and I remembered this "spirited" debate, so thought I would share my conclusions, which are explained in a paper called "connection oriented forwarding" which can be found at:

http://www.interflect.com/docu...

In summary I concluded that LDP-based MPLS was more like a "connectionless" protocol than it was like a "connection oriented" protocol, and that RSVP-TE based MPLS had the ability to express behavior that was equivalent to that of other "connection oriented" protocols.

Whether our understanding of the terms "connectionless" and "connection oriented" are more by way of convention and implementation experience than by way of immutable / unviolable laws remains an interesting discussion.....

Reply | Post Message | MESSAGES LIST | START A BOARD

Say_Yes_2_MPLS 12/5/2012 | 12:02:53 AM

re: Luca Martini, Level 3 I have a few questions for Luca or anyone else who has views surrounding the subjects discussed in this interview:

[LM: Layer 2 VPNs offer a very simple interface that is easy to manage for both sides.]

Q1 - DoesnGÇÖt that depend on what the L2 user interface is? In the case of ATM and Frame Relay access an NTU/NTE device serves as a clear customer demarcation point. The SP can put a loop on the circuit and perform diagnostic checks to prove that the circuit is working up to the NTU/NTE, beyond the NTU/NTE is the customerGÇÖs responsibility. Where is the customer demarcation point if the access circuit is Ethernet? If the service is L2 only and the customer CPE is a standard switch, how does the service provider prove that the circuit is working up to the CPE? There is no manageable customer demarcation point in the Ethernet standards (yet). In the case of IP VPNs the SP can at least ping the customer CPE, Ethernet does not support MAC address pings (yet). So this raises the question - How does Level 3 detect L2 Ethernet access faults? My guess is they wait for the customer to ring up and tell them that thereGÇÖs a problem, not exactly proactiveGÇª Or maybe they use some kind of proprietary Ethernet OAM? Or maybe they donGÇÖt offer true L2 services and only offer an IP router interconnect service, in which case they use IP connectivity checks? Can anyone shed any light on this?

[LR: Some service providers like Qwest and Sprint, say they donGÇÖt want to use MPLS VPNs. They say theyGÇÖd rather use IPSec. What do you think?]

Q2 - It would be interesting to hear LucaGÇÖs views on the range of MPLS VPN alternatives, not just IPsec. I donGÇÖt think anyone (including Sprint) thinks that IPsec is a scalable SP VPN offering, but what about other VPN enabling protocols such as L2TPv3 and GRE?

[LM: Have you ever priced out a Shasta or CoSine solution? LR: So youGÇÖre saying you can do it more cheaply using MPLS?]

Q3 - IGÇÖm not sure about the Shasta but I know that CoSine offers L2 and L3 MPLS VPNs as well as IPsec. IGÇÖd be interested in hearing how the cost of implementing a solution with CoSine boxes at the edge compared to say Laurel boxes at the edge. Bearing in mind that with CoSine boxes at the edge the SP can offer the same MPLS services as it can with the Laurel box, but can also offer IPsec VPNs, NAT, and dial-up/remote authentication services. IGÇÖm not saying that CoSine is a great solution, just that if you want to mention a specific vendors product and compare costs then you should consider more than just one service.

[LM: The place where Layer 3 VPNs really shine is in connecting a large number of small sites. It can be difficult to scale Layer 2 VPNs in that situation, but for most applications a Layer 2 VPN will scale just fine. And it has a better support model.]

Q4 - IGÇÖd be interested in hearing what this L2 VPN GÇ£support modelGÇ¥ is and how it is better than the L3 VPN support model.

I also have a few comments:

[LM: Why not just do Layer 3 MPLS VPNs? VPLS does not scale.]

Comment 1 - HmmmGÇª werenGÇÖt you just saying how complicated L3 VPNs were because you have to support customer routing? Perhaps thatGÇÖs why SPs may not want to use L3 MPLS VPNs? For what reasons does VPLS not scale? I suggest that for customers with a few sites (lets say 10) then VPLS should scale OK and you only need 1 Ethernet port at each customer site. If you use p2p links then you need 9 Ethernet ports per customer site. Even though from a provisioning point of view p2p vs. p2mp requires a similar amount of work from the SP perspective, 1 port vs. 9 ports is very different. If instead of burning up 9 ports the SP uses just one port with some clever VLAN ID mapping/translation, this CAPEX saving of ports incurs the extra OPEX cost of managing the VLAN ID mapping/translation.

[LM: If you build a network that has no links defined, it will be difficult to assign a cost to the different links. If you use a point-to-point link, you can assign a different cost to each end point.]

Comment 2 - I do not think that p2p vs. p2mp is the real issue here. If you have complete control over how links are provisioned, whether they are p2p or p2mp you can assign different costs to each path. This may be more difficult if using a dynamic protocol such as LDP, but not if for example you used a centralised provisioning system. I suggest that it is the way in which the drafts have been written that is the problem, not that this is an inherent p2mp problem.

[LM: Actually, I have come out with a solution for assigning different prices to links used with RFC 2547. Service providers can map the cost of the underlying network into the overall cost metric, so you can solve this problem if you want.]

Comment 3 - Well if you have solved the problem for 2547 then IGÇÖm sure you can solve it for VPLS, especially if you apply the same solution to the K.Kompella draft, which works in almost exactly the same way as 2547.

Thanks.

Reply | Post Message | MESSAGES LIST | START A BOARD

Say_Yes_2_MPLS 12/5/2012 | 12:02:51 AM

re: Luca Martini, Level 3 Regarding the statement chosen by LR as the quote to put on the main link to the interview:

[Luca: Personally, I think that MPLS is a merging of the best features of connection protocols like ATM and connectionless protocols like IP. MPLS offers the best features of both.]

Personally I think this is just a marketing statement with no technical foundations. How can MPLS offer the best features of a connectionless protocol AND a connection-orientated protocols? In other words, how can a protocol be connectionless and connection-orientated at the same time? Surely MPLS must be one or the other, and must therefore inherit the features of the network mode it belongs to.

There are 3 networking modes: connectionless, connection-orientated packet-switching, and connection-orientated circuit-switching. MPLS belongs to the connection-orientated packet-switching mode (as does ATM, FR) and therefore inherits the features of the connection-orientated packet-switching mode.

The only GÇÿconnectionlessGÇÖ part of MPLS is the way in which tunnels can be set up using a protocol such as LDP, which assigns labels based on the underlying IGP. However, LSPs can be provisioned manually without using any IP protocols at all, after all the original specification was for GÇ£Multi-protocolGÇ¥ not just IP. Even in the case of an MPLS network running LDP, if we consider that MPLS is at layer 2.5 (as some people do) and IP is at layer 3, then isnGÇÖt this analogous to IP at layer 3 running over ATM at Layer 2? If so then the statement about MPLS being a merging of the best features of connectionless and connection-orientated to can also be used for an IP network running over ATM or indeed any network where different layers belong to different networking modes.

Reply | Post Message | MESSAGES LIST | START A BOARD

gbennett 12/5/2012 | 12:02:50 AM

re: Luca Martini, Level 3 Comrade Say_Yes_2_MPLS,

IMHO, I think Luca's statement does sum up the general philosophy of MPLS, and I'll try and marshal some evidence to back that up...

I think you are absolutely correct in your definitions of C/O and C/L technologies. But the idea with MPLS was to make IP connection-oriented. C/O technologies have some advantages over C/L. You can do TE with a C/O technology, and (although I don't believe that MPLS offers real QoS today) you can theoretically do QoS in a C/O environment, whereas you can't in C/L.

In fact there is a C/L mode for MPLS. If an unlabelled packet arrives at an LSR (such as an OSPF routing packet or an RSVP-TE signalling packet), these packets are treated the same way as they would be in a router (as it happens they generally terminate within the receiving LSR). But you can also pass unlabelled data traffic through an LSR - it just defaults to C/L router operation.

So an MPLS LSR is, ipso facto, also an IP router.

This contrasts with an ATM switch, which may well have an IP stack too (eg. to allow SNMP management). But this kind of ATM switch will not take an active part in the IP/MPLS Control Plane. This is why the IP Over ATM Traffic Engineering architecture tended to "break" protocols like OSPF because of the large number of adjacencies that could be required.

An ATM switch that has been "upgraded" with an MPLS Control Plane does take an active part in the MPLS routing and signalling protocols, and solves the IGP Adjacency problem.

Cheers,
Geoff

Reply | Post Message | MESSAGES LIST | START A BOARD

Say_Yes_2_MPLS 12/5/2012 | 12:02:26 AM

re: Luca Martini, Level 3 Hi Geoff

I agree that an IP/MPLS router can forward IP packets and MPLS packets. However, I do not agree with your idea that there is a cnls mode for MPLS. In the case of unlabelled MPLS packets, who is to say they will be IP? In the case of L2 VPNs for example they could be Ethernet or Frame Relay, in which case a P router wonGÇÖt have a clue what to do with them. Even if the frames are IP, what if they are customer frames belonging to an RFC2547 VPN? A P router does not have any knowledge of customer VPN routes.

If an MPLS node receives an unlabelled packet which *should* be labelled then an error has occurred and the packet should be dropped. Just as an error would have occurred if a Frame Relay switch was to receive a frame without a DLCI for example.

IMHO, if a router is forwarding IP packets its running in cnls mode, if its forwarding MPLS packets its running in co pkt-sw mode.

Regards,

SY2M

Reply | Post Message | MESSAGES LIST | START A BOARD

gbennett 12/5/2012 | 12:02:25 AM

re: Luca Martini, Level 3 Hi SY2M,

I stand corrected, I should have specified "unlabelled IP packets" :-)

But even Layer 2 VPN tunnels are signalled with unlabelled LDP packets (which will have an IP address on them corresponding to the egress PE router if I'm not mistaken).

If something goes wrong once the tunnel is set up, and somehow an unlabelled Ethernet frame is inserted into the tunnel, the first LSR that receives the unlabelled frame will just discard it. As you say, there's no "connectionless" mode for an L2 VPN.

Cheers,
Geoff

Reply | Post Message | MESSAGES LIST | START A BOARD

Mark Seery 12/5/2012 | 12:02:24 AM

re: Luca Martini, Level 3 Some people apply the following test to the user plane to determine if it is connectionless:

-can you pick up any packet, and place it on any link and have it find its way to the correct destination?

MPLS fails this test. So if you believe the test.....

In addition, true connectionless networks don't have to worry about packets being routed to the wrong place due to label swap configuration errors, and hence do not have a need for ongoing end-point verification to ensure packets are getting switched correctly. Also a connectionless user plane contains both DA and SA so you can determine who the SA is and return packets (in CO you have a return connection). Ethernet has DA & SA semantics, IP has DA & SA, MPLS has DA only.

In looking at these issues we see a clear difference between the role of the control plane and the user plane. Any OSPF-like control plane can be used to create a forwarding database for any user plane, but the real test is the behvior and semantics of the user plane.

it would appear that the preponderance of evidence suggests MPLS is CO. That the actual use of a control plane in real live implementations (as opposed to the theoretical use of one - e.g. ATM networks that do not run PNNI) provides benefits for the operator is a separate issue and should not be confused.

Mark

Reply | Post Message | MESSAGES LIST | START A BOARD

gbennett 12/5/2012 | 12:02:24 AM

re: Luca Martini, Level 3 SY2M said...

IMHO, if a router is forwarding IP packets its running in cnls mode, if its forwarding MPLS packets its running in co pkt-sw mode.

I agree. This is exactly analogous to ATM. When ATM switches pass a connection request, they route the message to the appropriate destination (with the objective of setting up a connection). Once the connection is set up, the ATM cells are switched over it.

The ATM connection request uses a full Layer 3 addressing scheme (NSAPs, or ATM Private Addresses). The Virtual Circuit uses a locally signficant, Layer 2 label (the VPI/VCI field).

So we can say that ATM switches route connection requests, but they switch cells.

Similarly, if you're using a signalling protocol to create MPLS LSPs, then the routing of the LSP (either hop by hop, or explicitly routed) is done using IP addresses. Once the LSP is set up, labelled packets are Layer 2 switched on the basis of the locally significant label.

Thus LSRs route unlabelled IP packets, but they switch correctly labelled packets.

Cheers,
Geoff

Reply | Post Message | MESSAGES LIST | START A BOARD

Mark Seery 12/5/2012 | 12:02:23 AM

re: Luca Martini, Level 3 Having actually woken up, I realize I left out an important point - label merging, I wanted to avoid it, so as to avoid an OAM discussion, but alas....

So when using destination-based hop-by-hop mode of MPLS (e.g. LDP) the forwarding is based on FEC, not on connection. Meaning multiple ingress labels can be swapped to the same egress label. What this means is that in theory the system does not have the kind of state associated with connection-oriented networks, and theoretically less. It also means that QoS can not work the same way as in connection-oriented networks, unless there is another P2P layer above this on which QoS decisions is made (also needed for OAM).

So in summary:

Fault modes (e.g. incorrect label swap) : CO
User plane semantics : CO
Switch state : CLNS
QoS : CLNS

So you can pick and choose parts of MPLS to argue that it is either CO or CLNS.

If I was an engineer working at a system vendor dealing with details of implementation every day, I would tend to look at LDP-MPLS and view it as CLNS.

If I was a network operator, I would tend to look at MPLS and conclude it was CO with some quirks.

MPLS is either a new mode of networking or two broken modes of networking. What ever it is in theory, it is deployed in networks today.

Mark

Reply | Post Message | MESSAGES LIST | START A BOARD

je 12/5/2012 | 12:02:22 AM

re: Luca Martini, Level 3 Just wanted to drop in and say thanks for a good discussion, IGÇÖve learned something here.

je

Reply | Post Message | MESSAGES LIST | START A BOARD

Page 1 / 10 > >>