I-D Action:draft-ietf-bmwg-mpls-forwarding-meth-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Benchmarking Methodology Working Group of the IETF.

	Title           : MPLS Forwarding Benchmarking Methodology for IP Flows
	Author(s)       : A. Akhter, et al.
	Filename        : draft-ietf-bmwg-mpls-forwarding-meth-06.txt
	Pages           : 31
	Date            : 2009-09-08

This document describes a methodology specific to the benchmarking
of Multi-Protocol Label Switching (MPLS) forwarding devices, limited
to the most common MPLS packet forwarding scenarios and delay
measurements for each, considering IP flows. It builds upon the
tenets set forth in RFC2544, RFC1242 and other IETF Benchmarking
Methodology Working Group (BMWG) efforts.  This document seeks to
extend these efforts to the MPLS paradigm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-mpls-forwarding-meth-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________

FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available

BMWG,

Please allocate some cycles to this request.

Since our work crosses into many IETF areas, it's
particularly important for us to think about folks
we know and respect who might be willing and able
to serve as ADs.

And to be completely frank with you all, I'm not eligible.

thinking caps on,
Al
bmwg chair

>Subject: FW: Nomcom 2009-10: Important Reminder: Call for Nominations,
>         Local Office hours, Nominee Questionnaires available
>Date: Wed, 9 Sep 2009 09:46:38 -0500
>From: "Mary Barnes" <mary.barnes <at> nortel.com>
>To: "Working Group Chairs" <wgchairs <at> ietf.org>
>X-BeenThere: wgchairs <at> ietf.org
>Sender: wgchairs-bounces <at> ietf.org
>
>Hi all,
>
>Thanks to the ADs and chairs that forwarded the previous reminder to
>their mailing lists. I would appreciate it if other chairs and ADs could
>do so, since we are really in need of more nominations.
>
>Thanks,

Planning for an Interim Meeting

BMWG,

As discussed at the last session in Stockholm, both
our AD-Advisor Ron and I have schedule conflicts with
IETF-76 week, and are unable to travel to the meeting.
We mentioned that BMWG could have an Interim meeting to
progress work, likely a 2 hour conference call supported by
a document conference system, such as webex.

The weeks between IETF meetings are rapidly slipping by, and I
want to investigate the possibility of a meeting during
the 3rd week of October, on 19 Monday, 20 Tuesday or 23 Friday.
The time would need to be friendly to both Europe and US
(we don't have any active participants from other zones, AFAIK)
so that means it would start at about 11AM US Eastern time,
+/1 an hour or so.

The main question at this point is to ALL DOCUMENT EDITORS:

- Will there be an update of your draft ready for discussion
   by the 2nd week of October, to give people a chance to read
   it prior to the meeting?  If not, by when will an update be
   available?

I know of one such draft right now, a new work proposal from
David Newman and Timmons Player:
http://www.ietf.org/id/draft-player-dcb-benchmarking-00.txt

If we have sufficient drafts to discuss, then we'll meet.
If not, we'll look at the calendar again with the dates

Re: Planning for an Interim Meeting

Hi Al,

I intend to submit new version of the Flow Monitoring
draft during first week of Oct - just waiting if I get
some last comments ...

Jan

The climate of Edinburgh is such that the weak
succumb young .... and the strong envy them.

                                 Dr. Johnson  

> -----Original Message-----
> From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On Behalf
Of Al
> Morton
> Sent: 21 September 2009 15:28
> To: bmwg <at> ietf.org
> Subject: [bmwg] Planning for an Interim Meeting
> 
> BMWG,
> 
> As discussed at the last session in Stockholm, both
> our AD-Advisor Ron and I have schedule conflicts with
> IETF-76 week, and are unable to travel to the meeting.
> We mentioned that BMWG could have an Interim meeting to
> progress work, likely a 2 hour conference call supported by
> a document conference system, such as webex.
> 

Re: Planning for an Interim Meeting

Thanks Jan.

If we can get commitments from some of the chartered items,
then we'll try to schedule an Interim meeting in the 3rd week
of Oct ...

Al

At 06:49 AM 9/24/2009, Jan Novak (janovak) wrote:
>I intend to submit new version of the Flow Monitoring
>draft during first week of Oct - just waiting if I get
>some last comments ...
>
>Jan

Re: Planning for an Interim Meeting

>> As discussed at the last session in Stockholm, both
>> our AD-Advisor Ron and I have schedule conflicts with
>> IETF-76 week, and are unable to travel to the meeting.
>> We mentioned that BMWG could have an Interim meeting to
>> progress work, likely a 2 hour conference call supported by
>> a document conference system, such as webex.
>>

Al,

My plans have changed and I will attend IETF 76. However, please don't
let that influence your plans to hold an interim meeting.

                                        Ron

Document Action: 'MPLS Forwarding Benchmarking Methodology for IP Flows' to Informational RFC

The IESG has approved the following document:

- 'MPLS Forwarding Benchmarking Methodology for IP Flows '
   <draft-ietf-bmwg-mpls-forwarding-meth-06.txt> as an Informational RFC

This document is the product of the Benchmarking Methodology Working Group. 

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-mpls-forwarding-meth-06.txt

Technical Summary
Over the past several years, there has been an increase in the use
of MPLS as a forwarding architecture in new and existing network
designs. However, there is no standard method defined to compare
and contrast
the foundational MPLS packet forwarding capabilities of network
devices. This document specifies a methodology using common criteria
(such as throughput, latency, frame loss rate, system recovery,
reset etc.) to evaluate MPLS forwarding of any implementation.

The purpose of this document is to describe a methodology specific
to the benchmarking of MPLS forwarding devices. The methods
described are limited in scope to the most common MPLS packet
forwarding scenarios and corresponding performance measurements in a
laboratory setting. This document focuses on the MPLS label
stack having only
one entry, as it is the fundamental of MPLS forwarding.

Re: Document Action: 'MPLS Forwarding Benchmarking Methodology for IP Flows' to Informational RFC

At 12:46 PM 9/25/2009, The IESG wrote:
>The IESG has approved the following document:
>
>- 'MPLS Forwarding Benchmarking Methodology for IP Flows '
>    <draft-ietf-bmwg-mpls-forwarding-meth-06.txt> as an Informational RFC

Congrats to the authors, Aamer, Rajiv, and Carlos.

A reminder to BMWG that an author team is forming to
address the issues raised for RFC 2544 RESET testing during the
final review. Please contact me if willing to work this topic.

Al
bmwg chair

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Hi Kris, Did not realize until now that we had not responded to your
comments on the term draft.

Cheers,
Jay

> -----Original Message-----
> From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On Behalf 
> Of Kris Michielsen (kmichiel)
> Sent: Monday, August 03, 2009 9:56 AM
> To: 'Al Morton'; bmwg <at> ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and
> meth-05
> 
> Hi,
> 
> Please find some comments/questions below.
> 
> 
> comments on term-06:
> 
> * The definitions don't seem to be consistent. A "Path" is defined in 
> the draft as a sequence of nodes/links from R1 (ingress of IP
> packets) and Rn (egress of IP packets). Other definitions in the draft

> point out that a "Backup Path" is not necessarily end-to-end, but can 
> start and end at any node along the "Primary Path". If the Backup Path

> is not end-to-end, one can also not claim that the Backup Path becomes