[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64
From:       David Farmer <farmer () umn ! edu>
Date:       2014-03-24 15:55:55
Message-ID: 5330558B.6080107 () umn ! edu
[Download RAW message or body]

On 3/21/14, 13:16 , Fred Baker (fred) wrote:
> > > ONLY the unicast *routing-prefix* is VLSM, and that does NOT
> > > include the fixed-length 64-bit IID.
> > 
> > If that had been the case, I would have expected this fact to be
> > spelled out in BIG BOLD LETTERS in the IPv6 specifications.
> > 
> > But I haven't seen this. On the contrary, I've seen plenty of claims
> > that we have 128-bit addresses and longest prefix match applies to
> > the whole address. This is also the observed behavior for the vendors
> > I'm most familiar with.
> 
> I can’t comment for all vendors. However, I can tell you that this is how Cisco \
> views it. It’s a 128 bit CIDR prefix that has a convention (defined in each version \
> of the architecture, originally 48 and now 64 bits) for the IID on a set of \
> interface types. 
> A general comment. I frequently hear that “some equipment can’t handle a prefix \
> longer than 64 bits”. It would be good to know what equipment is under discussion \
> and exactly what the impact is. I suspect that there is at least as much FUD in \
> that as fact. 
> I *can* tell you that a 64 or 128 bit number occupies more space than a 32 bit \
> number, which impacts TCAM densities in equipment that uses TCAMs (“what, you can’t \
> handle as many IPv6 prefixes as IPv4 prefixes?”). Depending on the TCAM \
> organization, it may mean that when a prefix longer than <something> is used, we \
> have to do multiple TCAM reads or access a separate TCAM for the “subsequent” part. \
>  By “organization”, I mean “did we make the memory 32, 64, or 128 bits wide?” A \
> datum width of 32 bits makes sense for IPv4-only; dual stack means at least a \
> double read for local and de-aggregated IPv6 prefixes. 64 bit widths are an \
> interesting trade-off; if I have an IPv6 /32 route to a neighboring ISP, I am \
> “wasting” 32 bits that are for its use. For routes in my own prefix, or \
> de-aggregated routes, I’m going to use some subset of the next 32 bits. In most \
> cases, I don’t need to go into bits 64..127, but it’s there if I need it for the \
> price of a second read. If I go for a 128 bit wide TCAM, I will “waste” 64-80 bits \
> of most entries, which costs in both capital expense (I’ll put all the memory into \
> the thing that you want to pay for) and operational expense (power, heat, and heat \
> management). 
> A TCAM read is on the order of 20 ns, at least with Cisco EARL 8, so that means \
> that either the second read has to be pipelined or the speed of the card is reduced \
> from 50 Mpps to 25 Mpps. In other words, using 1500 byte packets, the maximum speed \
> of a card is 300 GBPS instead of 600 GBPS, or using 128 byte packets it is reduced \
> from 51 GBPS to 25 GBPS. 
> A 64 bit width with an occasional extra read looks like a pretty good trade-off, \
> from where I’m sitting. If I want to build a 10X100G Ethernet card similar to my \
> present 10X10G cards, I can probably afford multiple TCAMs. 

I read that as saying routers with fast-path hardware are frequently 
optimized for prefixes of /64 or shorter, and significant use of longer 
prefixes may result in performance degradation.  How many longer 
prefixes are actually significant and the details of the performance 
degradation depend on the particulars of the optimization technique 
used.


-- 
================================================
David Farmer               Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]