[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> Sun, 12 January 2014 18:37 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 2DBCD1AE00C; Sun, 12 Jan 2014 10:37:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Level:
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=0.6, 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 pJnoHHCrCFIc; Sun, 12 Jan 2014 10:37:36 -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 BB9AB1ADFE6; Sun, 12 Jan 2014 10:37:35 -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 s0CIbGKE054334; Sun, 12 Jan 2014 13:37:16 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401121837.s0CIbGKE054334@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 14:26:23 +0200." <201401121426.23719.mark.tinka@seacom.mu>
Date: Sun, 12 Jan 2014 13:37:16 -0500
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: [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: Sun, 12 Jan 2014 18:37:37 -0000

In message <201401121426.23719.mark.tinka@seacom.mu>
Mark Tinka writes:
 
> On Sunday, January 12, 2014 04:59:41 AM l.wood@surrey.ac.uk
> wrote:
>  
> > The MPLS assumption is that it's protected and checked by
> > a strong link CRC like Ethernet, and checked/regenerated
> > by stack processing between hops; here, in a path
> > context, with zero UDP checksums MPLS has no checking at
> > all.
>  
> Right, which is probably why routers today can count badly
> checksum'ed Ethernet frames, but don't have the equivalent
> for MPLS.
>  
> > I'm sorry, when was MPLS cheap?
>  
> Current-generation ASIC's have no problem forwarding MPLS
> frames at wire rate. One could go so far as to say that MPLS
> has allowed vendors to make cheaper line cards also because
> IP FIB's and traffic queues can be scaled down dramatically
> (not that I'd every buy such line cards, but...).
>  
> Mark.


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

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.  ... 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.  Back when forwarding was done in software
(circa 1995) your statement would have been true if MPLS preceeded
forwarding ASICs which it did not.

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.

Curtis