Subject: [bmwg] comments on <draft-ietf-bmwg-fib-meth-01.txt>

From: Kevin Dubray <[email-masked]>
Date: Fri, 14 Mar 2003 20:33:28 -0500

Section 2: "This document covers only IPv4 packets..."

Since v4 only was a showstopper for the terminology draft,
I would expect equal problems with this I-D.

Let's identify sections that preclude application to IPv6 and
either address v6 directly or identify more widely applicable
language.

Section 5. Test Setup.

"The router should be configured realistically. That is..."

While the I-D states some useful components that must
be present for [most] routers' operation (e.g., physical
interface modules), it doesn't give clues as to what
constitutes "realistic."

More importantly, perhaps the draft should offer guidance to the
requirements in reporting said realistic configuration?

"In the absense of test gear, ... network prefixes could be manually
be entered into the router."

The balance of the I-D presumes the participation of external test
devices. Is it reasonable to assume the FIB will be populated
to exhaustion (in some tests) via provisioning?

If so, language should be considered for the draft requiring
reporting of the population method.

Similar language should be specified or relocated to section
6, Methodology of Route Advertisements.

Section 6.3, Learning time.

This section specifies two ways to assess learning times:
via internal reporting (via the router's management plane) and
external measurement (via traffic observation).

See the discussion on the list recently regarding the role of
white box methodology vis a vis black box methodology.

The section heading is a misnomer since, as stated in the
draft, the goal is to assess whether the FIB population cycle is
complete.

Section 8. Table composition.

This is an example of a section that need to be reworked so as not to
preclude IPv6 applicability.

General notes:

If nothing else, doesn't the reporting requirements need to be
strenghthen for the metrics?  Where do I derive the RFC 3222
notion of Forwarding Information Base Prefix Distribution
that was applied to the DUT?

Might want to check section 12.3's pseudo-code against:

http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt

to see if it'll fly.

I think this I-D might need some more time in the oven... :-)

-Kevin

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg