Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
Curtis Villamizar <curtis@ipv6.occnc.com> Tue, 14 January 2014 15:51 UTC
Return-Path: <curtis@ipv6.occnc.com>
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 5D1BE1AE09C; Tue, 14 Jan 2014 07:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 NTFsiqOmpGvp; Tue, 14 Jan 2014 07:51:14 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 395E81AE0DF; Tue, 14 Jan 2014 07:51:14 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EFojHp098066; Tue, 14 Jan 2014 10:50:46 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401141550.s0EFojHp098066@maildrop2.v6ds.occnc.com>
To: mark.tinka@seacom.mu
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Sun, 12 Jan 2014 21:04:40 +0200." <201401122104.44370.mark.tinka@seacom.mu>
Date: Tue, 14 Jan 2014 10:50:45 -0500
Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, ietf@ietf.org, lisp@ietf.org, david.black@emc.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu
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: curtis@ipv6.occnc.com
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: Tue, 14 Jan 2014 15:51:17 -0000
In message <201401122104.44370.mark.tinka@seacom.mu> Mark Tinka writes: > On Sunday, January 12, 2014 08:37:16 PM Curtis Villamizar=20 > 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=20 > use those line cards, and I make it my business to know what=20 > 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. What you said was "Current-generation ASIC's have no problem forwarding MPLS frames at wire rate". Since you didn't mention IP packets I assumed you were making the 20 year old argument that MPLS forwarding was faster than IP. > > ... > > 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=20 > vendor equipment is about half the rate of IPv4 or MPLS. But=20 > then again, because MPLS control planes are IPv4-driven=20 > today, I'm hoping I didn't have to be explicit about not=20 > including IPv6 in that group, on this list. None of the equipment I have worked on (a while back) or the chips we evaluated recently had such a problem for IPv6 using only the top 64 bits for forwarding. An argument was made in the early 2000s (by me and others) that if we allocated global routes only from the top 64 bits all equipment at that time could forward at essentially the same rate as for IPv4. The reaction from the IPv6 community was to completely throw away the bottom half of the address and make it the host part. There are chips for which looking at a 32 bit prefix or a 64 bit prefix is done within the same pipeline and therefore takes the same amount of time. Other chips which parallelize packet handling budget enough microengines to get the job done (only a part of which is the MPLS ILM or IP destination lookup). > > 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=20 > (Label Switch Processor) and much of the PFE from J's PTX=20 > are forwarding engines that have been made cheaper by=20 > reducing the IP FIB on the assumption that all traffic will=20 > be carried in MPLS. This is, obviously, an assumption I do=20 > not support because: Those line cards (and designs I was recently involved in) assume what has historically been called a BGP-free core. Only the IGP routes are carried in the core. BGP is mapped onto the IGP routes. MPLS carries traffic across the core. The core has no BGP routes and therefore needs a lot fewer entries and the ILM can be put into SRAM rather than use a TCAM and only a small set of IP routes needs to be supported. That is done to eliminate a need for large external DRAM or TCAM which itself and the SERDES needed to go off chip produces heat and requires power, board space, and cooling and therefore reduces density. Putting more simple filters in the core also helps increase density. It is more a power to operate and floor space per Gb/s issue. For the most part IP/MPLS transport equipment seems to be going this way, though some people are stuck on MPLS-TP and trying to build a L2 overlay. If you go back to before 2000 at least one provider built a BGP-free core over Frame Relay, but FR itself soon died and the overlay didn't scale well. Some providers wanted to do this over MPLS but the RSVP-TE restoration times were too long and the fallback to IP routing was still needed to make up for that. > - 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=20 > native IPv6, you could potentially run out of FIB slots to=20 > host IPv6 routes. Unless you run a BGP-free core, whether IPv4 or IPv6. Then you have plenty of FIB space. > That is why I say MPLS has allowed vendors to put out=20 > cheaper line cards compared to the costs of those which have=20 > large IPv4/IPv6 scale. Because MPLS forwarding is so=20 > mainstream, there is no additional cost associated with=20 > forwarding rates similar to IPv4. So much of the cost of=20 > line cards is in QoS queues and routing FIB slots (and MPLS- > biased line cards are stripped of that, hence making them=20 > cheaper). You put forwarding at full rate and cheaper line cards in the same paragraph with no mention of smaller FIB size due to eliminating the BGP routes. > > 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=20 > world IP traffic is not all 40 bytes. > > If operators have doubts about what forwarding engines can=20 > do below 128 bytes, that is what PoC labs are for before you=20 > buy. And even then, several operators accept the=20 > restrictions up to a certain point, because the lab and real=20 > life vary significantly. > > Mark. OK ... so this is all interesting but I've lost the connection between this discussion and draft-ietf-mpls-in-udp. Hence the OT in the subject. Would you please remind me what that connection was. Curtis
- [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