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.
- [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp … l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Randy Bush
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Adrian Farrel
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- [mpls] misdelivered mpls packets - Was: Re: draft… Loa Andersson
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Gregory Mirsky
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Huub van Helvoort
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Andrew G. Malis
- Re: [mpls] misdelivered mpls packets - Was: Re: d… David Allan I
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Curtis Villamizar
- Re: [mpls] misdelivered mpls packets - Was: Re: d… l.wood
- [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: … Curtis Villamizar
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … l.wood
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… l.wood
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Wesley Eddy
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … Dino Farinacci
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … gorry
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Mark Tinka
- [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE:… Curtis Villamizar
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Randy Bush
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Alexander Vainshtein
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] mpls-in-udp entropy Eric Rosen
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… gorry
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Saku Ytti
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Saku Ytti
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein