Luca Martini, Level 3

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 3 / 10 > >>

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

re: Luca Martini, Level 3 Tony,

Regarding the following statement:

GÇ£It's entirely reasonable to ask that the L2 CPE switch is IP manageable and that the service provider at least be able to ping it for continuity checks.GÇ¥

This assumes the SP has IP management connectivity to the customer CPE. How is this provided? The SP must either have a connection into the customers VPN, or use a separate management VLAN. Both of these have their own problems, e.g. filtering of customer traffic and management of VLAN space.

Presuming that the customer also needs to manage their own CPE device and it is therefore connected to the customer management LAN, the SP may need to filter out customer management traffic from other devices in the customers network. The SPs management connection to the customers CPE also leads to security risks (for the customer and the SP). An SP managed L3 solution is open to the same risks, however, these security risks are not associated with other L2 access technologies like Frame Relay and ATM, as these circuits are managed at L2 (where the SP wants to provide L2 connectivity only). The whole problem stems from the fact that Ethernet does not have any inherent management or OAM functionality, and must therefore GÇÿborrowGÇÖ these from L3 (IP).

The above statement also assumes that the SP is providing a managed service for that particular customer. What if the SP is a wholesale provider and just wants to provide an Ethernet GÇÿwireGÇÖ for the customer to plug their CPE into? I think the answer here is that Ethernet cannot be used in this way. Just like a Frame Relay circuit has an NTE/NTU, I think an Ethernet circuit needs a line termination device that is GÇÿownedGÇÖ by the SP. The customer can then plug their CPE into the SP termination device (which could be a cheap L2 switch). This gets round the problems associated with the customer management connection as only the SP has a management connection to the termination device.

Some customers may be OK about giving an SP management connectivity to a device in their network, but there will also be many that wonGÇÖt. Especially those who simply want a replacement for their existing ATM/FR circuits.

SY2M.

Reply | Post Message | MESSAGES LIST | START A BOARD

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

re: Luca Martini, Level 3 Hi Raj,

>> But i still believe as Tony have said - MPLS will never match ATM QOS <<

I'll give u a longer answer when I get home tonight, but my short response is that access networks are very different than what Tony and I were predominantly discussing. In addition, an ATM network may not have the characteristics of a SONET network, but.....right tool, for the right job.

It is true to say that you can not get a better QoS than reserving resources on a flow basis, the question is can you get an equivalent. I'll discuss the role of both per-flow queues and packet sizes in access networks when I respond tonight.

Mark

Reply | Post Message | MESSAGES LIST | START A BOARD

raj_sarkar 12/5/2012 | 12:02:01 AM

re: Luca Martini, Level 3 Mark & Tony,

I agree with both of you but i was just curios about the scalability of MPLS to the latest work being done in IP QOS in the DSL Forum. I was just curios of how this model of 6 queues will go with MPLS ( especially if MPLS is in the core). From the discussion it looks like it would be a good idea to shape the aggregate of flows terminating on an MPLS LSP to reduce the possible bursty behavior if any before the packets enter the core. But i still believe as Tony have said - MPLS will never match ATM QOS. Currently, most of the service providers' use best effort flows and their is hardly any box deployed using 6 queue methodology in the DSL network. Since, L3 is already running MPLS network, i will be curious to know how it is performing from the terms of traffic engineering (if any) ? Mr. Marconi may be able to shed some light on that...

- Raj

Reply | Post Message | MESSAGES LIST | START A BOARD

boozoo 12/5/2012 | 12:02:00 AM

re: Luca Martini, Level 3 Raj,

Good observation about "shaping" into the core. I think the correct techincal term is called "policing".
However, I think the statistical multiplexing - that becomes more and more prevalent when you approach the core - will take care of it, as Mark suggested earlier.

I would like to summarize what I'm hearing so far (please correct me if I'm wrong):
When you deploy QoS in an MPLS network, you want to employ both:
- exp bits to acheive traffic separation throughout the network
- service(customer) separation AT THE EDGE(using per-customer policers and shapers and thus per-customer queuing).

Tony said in a previous post that ATM offers too much from a QoS point of vie and I suspect that he was refering to the not-needed customer separation in the core of the network.

Boozoo

Reply | Post Message | MESSAGES LIST | START A BOARD

raj_sarkar 12/5/2012 | 12:02:00 AM

re: Luca Martini, Level 3 <good "policing".="" "shaping"="" about="" called="" core.="" correct="" i="" into="" is="" observation="" techincal="" term="" the="" think="">

What i meant was shaping on the egress before it enters the core MPLS network? If you police it on the ingress then actually you will be dropping traffic if the traffic is bursty. Rather, shape it - so that you accomodate the packets merging into a MPLS LSP from different flows and prevent the actual aggregate bandwidth from exceeding the MPLS LSP guaranteed bw. In this way you accomodate the short comings of a packet based network and prevent the core from taxing bursty traffic coming in from an edge (tho there is a less possibility as pointed out by Mark).
</good>

Reply | Post Message | MESSAGES LIST | START A BOARD

indianajones 12/5/2012 | 12:01:55 AM

re: Luca Martini, Level 3 Tony,

I am afraid you are incorrect in some of your assumptions.

While it is not necessary to mimic ATM's per-VC queueing, it is necessary to support "hard" guarantees for applications requiring bounded latency and jitter.

Simply using Diff-Serv and prioritizing traffic will not cut it. Cisco and Juniper have been parroting this for a while now but the truth of the matter is that they have pretty unpredictable latency and jitter.

The useful notion in ATM is that CBR, rt-VBR connections support tight latency and jitter in the presence of UBR traffic and no amount of UBR traffic would adversely impact those QoS metrics. MPLS will be useful for supporting real-time services only if it supports a similar notion.

Reply | Post Message | MESSAGES LIST | START A BOARD

gigeguy 12/5/2012 | 12:01:54 AM

re: Luca Martini, Level 3 While it's not a part of the MPLS RFCs, there are existence proofs in shipping equipment today that MPLS can achieve the same QoS guarantees as ATM when you combine RSVP-TE BW reservations, constraint-based routing, and diff-serv through the core with per-flow or per-customer queuing, shaping (both ingress and egress), and policing at the edge.

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 12:01:50 AM

re: Luca Martini, Level 3

SY2M,

All that's required here is that the SP have one IP address within the customer's VPN. This is not unreasonable, considering it's a managed service.

Also, it's not reasonable to assume that the CPE is not managed by the SP. There are likely to be cases where both are appropriate/desired.

If a customer doesn't trust the SP to be connected to their network, then the customer is fooling themselves when they hand an unencrypted packet to the provider in the first place.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

douggreen 12/5/2012 | 12:01:49 AM

re: Luca Martini, Level 3 Toni,

A bit of history regarding demark and Ethernet services.

Years ago I worked for a company that provided equipment to MFS, TCG, BD Tel, and other for their native LAN service (10 meg). It was MFS' fastest growing service, with more than 3000 ports deployed, before Worldcom bought them and killed it ("we only sell pipes, not services...") Similar story with TCG and AT&T.

Management at the demark was a major issue with all. Most ended up sticking a 2500 router at the end of the native ethernet, even when it was sold as a transparent LAN service. The sole purpose of the router was to have something that would give them statistics and something to "ping".

A really cheap CPE device that provides basic stats and connectivity information is a must and would be a great product for a startup to develop. The only problem is that there's little margin in it for the equipment provider. In the mean time, most SPs will find the cheapest router or LAN switch that can serve the purpose.

One more point: customers fool themselves regarding security all the time. It's the only way to sleep at nights ;)

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 12:01:47 AM

re: Luca Martini, Level 3
Doug,

No arguments. If the SP wants to provide the switch, that fine by me. However, it is again not something special. As you note, it's a commodity off the shelf product. Functionally it's the same thing whether the SP pays for it and charges the customer or whether the customer pays directly for it and lets the SP ping it.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 3 / 10 > >>