[bmwg] Repost

Barry Constantine <Barry.Constantine@jdsu.com> Fri, 11 January 2013 16:27 UTC

From: Barry Constantine <Barry.Constantine@jdsu.com>
To: "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: Repost
Thread-Index: Ac3wGGB4CfslJRlXR+2pZAiyY9S4sg==
Date: Fri, 11 Jan 2013 16:27:00 +0000
Message-ID: <DE2AAE0A8826CF4ABC3A6CCB756356EB0BC9A8@AMEXMB01.ds.jdsu.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_DE2AAE0A8826CF4ABC3A6CCB756356EB0BC9A8AMEXMB01dsjdsunet_"
MIME-Version: 1.0
Subject: [bmwg] Repost
Precedence: list

Hi Folks, the original email was getting lengthy and rejected, here is the last part of the thread:

This is close, but I don't think all methods are harmful and we would specify those that are, and then include the language that application of any lab method deemed unharmful, could be pursued as standards work in other area.

Thank you,
Barry Constantine

JDSU Communications Test
Principal Member Technical Staff
301-325-7069

From: MORTON JR., ALFRED (AL) [mailto:acm@research.att.com]
Sent: Friday, January 11, 2013 7:51 AM
To: Barry Constantine; bmwg@ietf.org<mailto:bmwg@ietf.org>
Subject: RE: Traffic Management Submission

That's an interesting idea, a standard section of bmwg memos that


-   points to RFC 6815 http://tools.ietf.org/html/rfc6815

-   indicates ways that application of the described lab methods

could be harmful if used beyond their scope

-   emphasizes that these are non-exhaustive examples

-   suggests that application of these lab methods should

result in development of a new standard intended for production nets


What do others think?

Al
bmwg chair


From: Barry Constantine [mailto:Barry.Constantine@jdsu.com]
Sent: Friday, January 11, 2013 7:18 AM
To: MORTON JR., ALFRED (AL); bmwg@ietf.org<mailto:bmwg@ietf.org>
Subject: RE: Traffic Management Submission

OK Al, that makes sense.

I'll use this email to explore a topic that probably has been discussed in BMWG before.

First some background.  It's common for a network provider to conduct lab based benchmarking and pre-deployment testing during the design phase of a new network.  In many cases, the network engineer responsible for lab testing, writes the operational installation tests for the field technicians.

This explains how RFC 2544 made it's way into field testing.

Another example is the SIP metrics developed by this group.  Those metrics (even in draft form) were an excellent means to establish common measurements and are also used in operational management systems.

I realize the core charter of BMWG is to produce test processes and benchmarks in a lab environment, but as I said above, in practice the lab network engineers are also responsible for field test procedures.

So here is the rub; even though BMWG charter does not cover operational networks, should we consider language (perhaps a dedicated paragraph) that explicitly states which components would be harmful to production networks?  It may save the headache that RFC 6815 tried to correct and this would also provide guidance for those readers who may seek to adopt portions of the test to operational networks.

OK, hope this makes sense and am trying to be proactive.

Thank you,
Barry Constantine


Thank you,
Barry Constantine

JDSU Communications Test
Principal Member Technical Staff
301-325-7069

[bmwg] Repost Barry Constantine