[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bmwg] WGLC: draft-ietf-bmwg-mpls-forwarding-meth-00
Hi Al,
Your comments immensely improve this document. All the comments have
been incorporated in -01 version without any doubt. Thank you so much.
> 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.
Done.
> The draft seems to use Frame and Packet interchangeably, and that's
> bound to confuse some readers. Pick the right one.
Fixed. The term frame is used consistently.
While the RFC2544 does use both terms, we agree that we need to be
consistent.
> 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
> ...
Fixed.
> 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.
Fixed. Inserted the suggested para.
> 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
> ^^^^
Fixed.
> 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.
Fixed.
> 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.
Fixed.
I am assuming that this was pertaining to DUT.
>
> 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.
>
Fixed.
> 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.
Fixed.
> 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...."
> ??
Fixed.
> 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).
> ^^^^
Indeed. Fixed.
> Section 5. Reporting Format
> 1st paragraph, suggest:
> s/recommended/RECOMMENDED/
> Table header, suggest:
> s/Unit/Units/
Fixed.
> 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/
Fixed.
> 2nd para, suggest:
> s/follow the below 'Test Setup' and 'Test Procedure.'/follow the
> 'Test Setup' and 'Test Procedure' below./
fixed.
> 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.
Fixed. The text has been edited such that it only refers to RFC2544, and
there is no conflict.
> 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.
> ^^^^^^^^^^^^^
>
Fixed.
> 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
All fixed.
> Section 6.2. Latency Measurement
> in Procedure, I suggest:
> s/RFC 2544/section 26.2 of RFC 2544/
Fixed.
> Section 6.2. Frame Loss Measurement (FLR)
> in Procedure, I suggest:
> s/RFC 2544/section 26.3 of RFC 2544/
Fixed.
> Section 9 References:
> IMO, both RFC 2544 and RFC 1242 are Normative in this memo,
> so should appear in the Normative section.
Fixed.
Cheers,
Rajiv
> -----Original Message-----
> From: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On Behalf
Of
> Al Morton
> Sent: Thursday, October 16, 2008 12:00 PM
> To: bmwg at ietf.org
> Subject: 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
_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www.ietf.org/mailman/listinfo/bmwg