Subject: Comments on FIB Terminology document

From: Gabe Heininger <[email-masked]>
Date: Tue, 12 Dec 2000 20:56:38 -0800

Guy,
   Here are more comments on your draft for FIB based router
benchmarking. Some I mentioned at the meeting, some were more minor and
not brought up then. All are included here.

Regards,

Gabe Heininger
Senior Engineer
Ixia

Section 2:
"   When routes are advertised into the router, the routes should be
   advertised in such a way so that route aggregation (5.14) does not
   occur."

Something should be added here to clarify that you mean "sequential
route ranges should not be on the same port" or something to that
effect. This is explained in section 5.14. You could also state that
route aggregation should be disabled in the router when possible.

Section 3:
"[2] contains discussions of a number of terms relevant to
   the benchmarking of switching devices and should also be consulted."

Is "switching devices" an appropriate term here? RFC 2544 describes
"network interconnect devices" in general. Perhaps this could be changed
to "network interconnect devices."

Section 5.1
This comment was made in the meeting.
"   Discussion:
          Network prefixes are represented as a 32 bit IP address with
          a mask indicating the number of bits representing the network
          prefix.  I.e. 141.184.128 /17 indicates that the network
          prefix is 17 bits long."

141.184.128 is not a 32 bit IP address, it is a prefix. 141.184.128.0 is
(to me) a 32 bit IP address.  Do we include the .0s on /24s and smaller
prefixes? Consider 10 /8 vs. 10.0.0.0 /8. Obviously for prefix lengths
greater than /24 we would need to specify the last octet. This conflict
needs to be resolved.
I also think that "32 bit IP address" should be further specified as "32
bit dotted ip address" or something to that effect.

Section 5.2
"   Measurement units:
          length in bits"

In sections 5.5 and 5.7 you use the unit "Positive Integer," would this
not be the same? We seem to have some inconsistencies in this document.
The unit is bits, the data type is a positive integer. Is that not more
descriptive? Does it make sense to specify the unit and the data type?

Section 5.3
"The forwarding information base is an abstract concept used..."

Abstract? It certainly exists and can be viewed in several
implementations! I also agree with Jerry that LPM is out of place here,
though it is a relevant concept that should be defined/described.

Section 5.4
"   Definition:
          A single entry within a forwarding information base,
          consisting of a network prefix and a router port identifier."

To be consistent with the definition in 5.3, you should add "and next
hop information."

Section 5.6
   My concern about fractional routes has been addressed.

Section 5.7
"   Definition:
          The maximum number of forwarding information base entries
          that can be supported within the forwarding information base."

"Supported" needs to be further qualified here. I have seen devices
claim to have x routes in their forwarding table (via a command line
interface or SNMP), however the device is not able to consistently
forward packets to every prefix in the FIB. Can we include the phrase,
"that the device is able to forward all offered packets on," in here
somewhere? And something sounds strange with the reciprocal definition,
"The maximum number of table entries that can be supported within the
table." Could this be better worded as, "... within the DUT"
I disagree with Jerry on the measurement units, the data type is
positive integer and the unit is routes.

Section 5.8
You need to make a provision for protocols that export routes into other
protocols. Is this included in the time or not? For example, in BGP or
OSPF, all routes could be advertised to the DUT but the DUT could take
some amount of time to process/filter/propagate that information to
Peers/Neighbors. Does the timer stop when the last route is advertised
to the DUT or when the last route is exported to the last peer/neighbor?

The measurement unit would be a seconds, data type positive integer.
Jerry suggests we use the term "prefixes per second," the section title
implies a raw count in seconds. Otherwise this should be FIB Learning
RATE.

Section 5.9/5.10
Every time I read this I think about RFC 1242: "Treat the device as a
unit without regard to it's internal structure." I don't think it is
appropriate to come up with a test for every architecture out there.
However, I have seen from my own work the effect of these two factors on
testing.  The methodology document could make note of this. "Packets
must be sent to all networks to insure the test measures overall router
performance, mitigating the effects of optimizations such as port-level
or card-level caching."

Section 5.14
Would it be appropriate to mention "many FIB entries may be exported as
a single entry?" Aggregation affects the way the route is stored in the
DUT and advertised/exported. Do you think it is worthwhile to mention
it? (I suppose this would depend on your ideas regarding my comments on
section 5.8)