Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)

Mark Tinka <mark.tinka@seacom.mu> Sun, 12 January 2014 19:05 UTC

Return-Path: <mark.tinka@seacom.mu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C2B1AE013; Sun, 12 Jan 2014 11:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.589
X-Spam-Level:
X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQSton2cP-ZI; Sun, 12 Jan 2014 11:05:10 -0800 (PST)
Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id C693A1AE012; Sun, 12 Jan 2014 11:05:09 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from <mark.tinka@seacom.mu>) id 1W2QKz-0000ia-1E; Sun, 12 Jan 2014 21:04:45 +0200
From: Mark Tinka <mark.tinka@seacom.mu>
Organization: SEACOM
To: curtis@ipv6.occnc.com
Date: Sun, 12 Jan 2014 21:04:40 +0200
User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; )
References: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com>
In-Reply-To: <201401121837.s0CIbGKE054334@maildrop2.v6ds.occnc.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1564113.ZqtHiklPLi"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201401122104.44370.mark.tinka@seacom.mu>
Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, jnc@mit.edu, tsvwg@ietf.org
Subject: Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mark.tinka@seacom.mu
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 19:05:13 -0000

On Sunday, January 12, 2014 08:37:16 PM Curtis Villamizar 
wrote:

> Perhaps if you actully worked for a company that made
> line cards you would not make the above statement.

I work for an operator that pays real money to deploy and 
use those line cards, and I make it my business to know what 
I'm paying for.

> Many of the big router vendors use the same TCAM hardware
> for MPLS lookups as they do for IP lookups.  Doing the
> lookup is not the rate limiting factor even in hardware
> that has an ILM SRAM table and some form of radix based
> lookup.  All of the hardwre I've seen in the last 15
> years or so forwards MPLS and IP at the same rate.

Which was exactly my point - unless you somehow missed that.

> ...
> Except IPv6 before they decided to waste the lower half
> of the address space with 40 quintilion host in a
> bridged subnet and you really did have to look at the
> whole 128 bits.

It is no secret that forwarding of IPv6 packets on some 
vendor equipment is about half the rate of IPv4 or MPLS. But 
then again, because MPLS control planes are IPv4-driven 
today, I'm hoping I didn't have to be explicit about not 
including IPv6 in that group, on this list.

> Back when forwarding was done in
> software (circa 1995) your statement would have been
> true if MPLS preceeded forwarding ASICs which it did
> not.

You might not know that line cards from C like the LSP 
(Label Switch Processor) and much of the PFE from J's PTX 
are forwarding engines that have been made cheaper by 
reducing the IP FIB on the assumption that all traffic will 
be carried in MPLS. This is, obviously, an assumption I do 
not support because:

	- I run IPv6 natively, and at the moment, there are
	  no production-grade IPv6 control planes for MPLS.

	- It assumes providers will run 6PE (in which case,
	  IPv6 traffic enjoys MPLS and IPv6 wire rate
	  forwarding speeds).

I do not buy such line cards because for anyone running 
native IPv6, you could potentially run out of FIB slots to 
host IPv6 routes.

That is why I say MPLS has allowed vendors to put out 
cheaper line cards compared to the costs of those which have 
large IPv4/IPv6 scale. Because MPLS forwarding is so 
mainstream, there is no additional cost associated with 
forwarding rates similar to IPv4. So much of the cost of 
line cards is in QoS queues and routing FIB slots (and MPLS-
biased line cards are stripped of that, hence making them 
cheaper).

> Also the statement "Current-generation ASIC's have no
> problem forwarding MPLS frames at wire rate" is not true
> for most (or all) hardware with 40 byte payloads (even
> with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s
> interfaces.  It is true for "average packet size"
> traffic and on most hardware only true if bursts of 40
> byte packets are very limited in duration.

C'mon, Curtis. Everybody knows this already. Moreover, real 
world IP traffic is not all 40 bytes.

If operators have doubts about what forwarding engines can 
do below 128 bytes, that is what PoC labs are for before you 
buy. And even then, several operators accept the 
restrictions up to a certain point, because the lab and real 
life vary significantly.

Mark.