[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bmwg] WGLC: draft-ietf-bmwg-mpls-forwarding-meth-00
At 10:13 AM 9/24/2008, Al Morton wrote:
BMWG:
A WG Last Call period for the Internet-Draft on
"MPLS Forwarding Benchmarking Methodology"
draft-ietf-bmwg-mpls-forwarding-meth-00.txt
will be open from 24 September through October 24, 2008.
I have three comments as WG chair:
First, this is a very clearly written draft, and I'd like to
thank the authors for their persistent and skillful efforts
to pare this draft down to the minimum.
I'd like to see the "standard security paragraphs" incorporated
in the text. This way, it's clear to anyone who picks-up the
RFC that the scope is limited to lab characterization, etc.
There are people who recently referenced RFC 2544 for live network
OAM testing in their standards documents. Not Good.
Clear Scope = Good.
The draft seems to use Frame and Packet interchangeably, and that's
bound to confuse some readers. Pick the right one.
My remaining comments are below, as a participant.
Al
Section 2, Scope.
There are a few good sentences in the abstract that should be
also appear in the text of the scope. This also solves the problem of
not mentioning RFC 2544 until page 5.
I suggest:
2. Document Scope
The purpose of this draft is to describe a methodology specific to
the benchmarking of MPLS forwarding devices. The scope of this
benchmarking will be limited to various types of packet-forwarding
and delay measurements in a laboratory setting.
It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242
[RFC1242] and other IETF Benchmarking
Methodology Working Group (BMWG) efforts.
MPLS [RFC3031] is a foundation enabling technology for other more
...
Section 4, Test Methodology.
The example calculates the number of ports needed using the throughput,
but how do we know the throughput before establishing the test setup?
Maybe there is an estimated throughput available, and it seems that there
are a couple of considerations to mention.
I suggest:
The exact throughput is a measured quantity obtained through testing.
Throughput may vary depending on the number of ports used,
and other factors. The number of ports used (p) MUST be reported.
Section 4.1.2, editorials:
...(includes when the label bindings change). The most commonly used
protocols are Label Distribution Protocol (LDP) [RFC5036], RSVP-TE ...
^^^^^
...This memo discourages the use of static label to establish the MPLS
^^^^
Section 4.1.3, Frame sizes
Although most active test people know what an IMIX is,
we don't have that term in bmwg lingo.
I suggest (in place of the last 2 paragraphs):
...In addition to the individual frame size trials, results MAY ALSO
be collected with multiple simultaneous frame sizes (sometimes
called an IMIX). There is no standard for mixtures of frame sizes,
and the results are subject to wide interpretation. See section 18
of RFC 2544.
When running trials using multiple simultaneous frame sizes, the DUT
configuration MUST remain the same.
Section 4.1.4, TTL and Hop Count
I suggest to add:
If TTL/Hop Count Decrement is a configurable option, the setting
MUST be reported.
Section 4.1.5, Trial Duration
I suggest to reword the last paragraph, for clarity:
The longer trial time used for dynamic routing protocols
is to verify that the DUT is able to maintain a stable
control plane when the data-forwarding plane is under stress.
Section 4.1.5.1. Traffic Verification
I suggest to reword the last sentence of the 1st paragraph:
...In addition, the
presence or absence of MPLS header on the packet MUST be verified,
as well as checksum, frame sequencing and correct MPLS TTL
decrement action.
Also, is the last paragraph in quotes needed? possibly an editing issue:
"In all cases the sent traffic MUST be accounted for, whether it was
received on the wrong port, correct port or not received at all. In
addition, the MPLS header...."
??
Section 4.1.7. Abbreviations Used
Looks like a typo:
OLD
RN := Remote Network (can also be thought of as a network that is
reachable via) Mp.
NEW?
RN := Remote Network (can also be thought of as a network that is
reachable via Mp).
^^^^
Section 5. Reporting Format
1st paragraph, suggest:
s/recommended/RECOMMENDED/
Table header, suggest:
s/Unit/Units/
Section 6. MPLS Forwarding Benchmarking tests
1st para, suggest:
s/than one MPLS headers/than one MPLS header/
s/those of described in RFC2544/those described in RFC2544/
2nd para, suggest:
s/follow the below 'Test Setup' and 'Test Procedure.'/follow the
'Test Setup' and 'Test Procedure' below./
3rd para says:
... In such case, the tool traffic should use BpRN1 and
BpAN as the IP destinations in a weighted round robin fashion. The
weighting ratio between BpRN1 and BpAN is a constant test
parameter. A suggested ratio is 1:100 with BpAN:BpRN1. The traffic
streams offered MUST conform to section 16 of RFC 2544.
but the weighting seems to conflict with the referenced section of 2544,
specifically the sentence: http://tools.ietf.org/html/rfc2544
...The specified tests are
run using the same data rate being offered to each of the input
ports.
>>> Need some text to reconcile this difference, and possibly discuss
>>> this point on the list.
Section 6, un-numbered section on Test Procedure
I suggest:
Test Procedure (Refer to Section 26 of RFC 2544)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Send traffic from port(s) Ap towards DUT at a constant load towards
^^^
IP prefixes (BpRN1 addresses) advertised by the test tool on the
^^^^^^^^^
receive ports, for a fixed time interval.
^^^^^^^^^^^^^
Section 6.1.1. Throughput for MPLS Label Imposition
in the Objective section, I suggest:
To obtain the DUT's Throughput (as per RFC 2544) during label imposition
(i.e. IP to MPLS) for a regular (IPv4 or IPv6) packet.
last sentence of Test Setup:
s/it's/its/
first line of Discussion:
s/contain non-reserved/contain a non-reserved/
2nd sentence of Discussion:
s/testool/test tool/
2nd sentence of Procedure:
s/must/MUST/
2nd sentence of Reporting format says:
Results for each test SHOULD be in the form of a table with a row
for each of the tested frame sizes. Additional columns SHOULD
include: offered load and measured throughput.
An RFC 2544 Throughput benchmark *is* the offered load, the only
measurement on the output is a count to determine if loss occurred.
So, these two columns are the same thing, maybe something else would
be a better example.
Similar comments apply to sections 6.1.2 and 6.1.3 and 6.1.4
Section 6.2. Latency Measurement
in Procedure, I suggest:
s/RFC 2544/section 26.2 of RFC 2544/
Section 6.2. Frame Loss Measurement (FLR)
in Procedure, I suggest:
s/RFC 2544/section 26.3 of RFC 2544/
Section 9 References:
IMO, both RFC 2544 and RFC 1242 are Normative in this memo,
so should appear in the Normative section.
_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www.ietf.org/mailman/listinfo/bmwg