From nobody Thu Apr 3 08:46:35 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA3C1A0251; Thu, 3 Apr 2014 08:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbRX1b0Rk0lq; Thu, 3 Apr 2014 08:46:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BE91A020A; Thu, 3 Apr 2014 08:46:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140403154624.31758.67922.idtracker@ietfa.amsl.com> Date: Thu, 03 Apr 2014 08:46:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/6wc18D3tVIY4TnLOf3a26_k3RPk Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-registry-active-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:46:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Active Performance Metric Sub-Registry Authors : Al Morton Marcelo Bagnulo Philip Eardley Filename : draft-ietf-ippm-registry-active-00.txt Pages : 25 Date : 2014-04-03 Abstract: This memo defines the Active Performance Metrics sub-registry of the Performance Metric Registry. This sub-registry will contain Active Performance Metrics, especially those defined in RFCs prepared in the IP Performance Metrics (IPPM) Working Group of the IETF, and possibly applicable to other IETF metrics. Three aspects make IPPM metric registration difficult: (1) Use of the Type-P notion to allow users to specify their own packet types. (2) Use of flexible input variables, called Parameters in IPPM definitions, some of which determine the quantity measured and others of which should not be specified until execution of the measurement. (3) Allowing flexibility in choice of statistics to summarize the results on a stream of measurement packets. This memo proposes a way to organize registry entries into columns that are well-defined, permitting consistent development of entries over time (a column may marked NA if it is not applicable for that metric). The design is intended to foster development of registry entries based on existing reference RFCs, whilst each column serves as a check-list item to avoid omissions during the registration process. Every entry in the registry, before IANA action, requires Expert review as defined by concurrent IETF work in progress "Registry for Performance Metrics" (draft-manyfolks-ippm-metric- registry). The document contains two examples: a registry entry for an active Performance Metric entry based on RFC3393 and RFC5481, and a registry entry for an end-point Performance Metric based on RFC 7003. The examples are for Informational purposes and do not create any entry in the IANA registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-registry-active/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-registry-active-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 3 09:13:06 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8110A1A022B; Thu, 3 Apr 2014 09:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuurwXi-eugW; Thu, 3 Apr 2014 09:12:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B781A0216; Thu, 3 Apr 2014 09:12:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140403161241.22104.18036.idtracker@ietfa.amsl.com> Date: Thu, 03 Apr 2014 09:12:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/WNazOcHsrFrt-Fkiq6ljI4ZJjsU Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-testplan-rfc2680-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 16:13:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Test Plan and Results for Advancing RFC 2680 on the Standards Track Authors : Len Ciavattone Ruediger Geib Al Morton Matthias Wieser Filename : draft-ietf-ippm-testplan-rfc2680-05.txt Pages : 29 Date : 2014-04-03 Abstract: This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2680 on One-way Loss Metrics. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2680/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-testplan-rfc2680-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 3 11:01:30 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7061A02AC; Thu, 3 Apr 2014 11:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuxsaK5jR33j; Thu, 3 Apr 2014 11:01:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BD41A02B4; Thu, 3 Apr 2014 11:01:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140403180110.8559.17839.idtracker@ietfa.amsl.com> Date: Thu, 03 Apr 2014 11:01:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/ynEspoD7b8u_sO88id9vwKIrLEs Cc: ippm mailing list , ippm chair , RFC Editor Subject: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 18:01:27 -0000 The IESG has approved the following document: - 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' (draft-ietf-ippm-testplan-rfc2680-05.txt) as Informational RFC This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2680/ Technical Summary The document defines a plan for testing implementations of RFC 2680 on one-way packet loss metrics, based upon the requirements set out in RFC 2680 itself, in order to evaluate ambiguity in RFC 2680 that may lead to interoperability problems.and recommends the revision of RFC 2680 based on ambiguities found herein, with subsequent advancement of RFC 2680bis to Internet Standard. Working Group Summary The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item. Document Quality This document describes a test plan, but also reports on the results of these tests with two independent implementation, Personnel The document shepherd is Brian Trammell. The responsible Area Director is Spencer Dawkins. From nobody Thu Apr 3 12:44:54 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65D41A00EC for ; Thu, 3 Apr 2014 12:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAHUL4wASNBl for ; Thu, 3 Apr 2014 12:44:44 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 91ED21A0107 for ; Thu, 3 Apr 2014 12:44:44 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id E74F75541DD; Thu, 3 Apr 2014 15:50:39 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 3B660F035A; Thu, 3 Apr 2014 15:44:40 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Thu, 3 Apr 2014 15:44:39 -0400 From: "MORTON, ALFRED C (AL)" To: "ippm@ietf.org" Date: Thu, 3 Apr 2014 15:44:38 -0400 Thread-Topic: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt) Thread-Index: Ac9PZsW4c/1ZLZK3SEegILHZsrL3cAADIadw Message-ID: <2845723087023D4CB5114223779FA9C801792B79F7@njfpsrvexg8.research.att.com> References: <20140403180110.8559.17839.idtracker@ietfa.amsl.com> In-Reply-To: <20140403180110.8559.17839.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Hf_v_lZQdlttLY0ujBT7_kLOjBQ Cc: ippm chair Subject: Re: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:44:50 -0000 IPPM, With approval of this draft, and the prior approval of=20 http://tools.ietf.org/html/rfc6808 (for RFC 2679) we have finished the justification to move our delay and loss RFCs up the standards track. Now that the heavy lifting is done, it would be great if IPPM=20 folks would volunteer to review the new versions or RFC 2679=20 and RFC 2680. They are revised according to the conclusions reached in the tests & results now fully approved. Please help to move these=20 drafts up the standards track (increasing the visibility of our work): draft-morton-ippm-2679-bis -03 2013-10-14 =20 http://tools.ietf.org/html/draft-morton-ippm-2679-bis-03.txt draft-morton-ippm-2680-bis -02 2014-02-13 =20 http://tools.ietf.org/html/draft-morton-ippm-2680-bis-02.txt If you've read the original RFCs this is a really easy request, and if you haven't read them, there's no time like the present. thanks for your help, Al > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of The IESG > Sent: Thursday, April 03, 2014 2:01 PM > To: IETF-Announce > Cc: ippm mailing list; ippm chair; RFC Editor > Subject: [ippm] Document Action: 'Test Plan and Results for Advancing RFC > 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm- > testplan-rfc2680-05.txt) >=20 > The IESG has approved the following document: > - 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' > (draft-ietf-ippm-testplan-rfc2680-05.txt) as Informational RFC >=20 > This document is the product of the IP Performance Metrics Working Group. >=20 > The IESG contact persons are Spencer Dawkins and Martin Stiemerling. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2680/ >=20 >=20 >=20 >=20 >=20 > Technical Summary >=20 > The document defines a plan for testing implementations > of RFC 2680 on one-way packet loss metrics, based upon > the requirements set out in RFC 2680 itself, in order to > evaluate ambiguity in RFC 2680 that may lead to interoperability > problems.and recommends the revision of RFC 2680 based > on ambiguities found herein, with subsequent > advancement of RFC 2680bis to Internet Standard. >=20 > Working Group Summary >=20 > The document has clear working group consensus for publication, > and has been reviewed by several WG participants since its > initial adoption as a working group item. >=20 > Document Quality >=20 > This document describes a test plan, but also reports on the > results of these tests with two independent implementation, >=20 > Personnel >=20 > The document shepherd is Brian Trammell. The responsible Area Director is > Spencer Dawkins. >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Mon Apr 7 08:27:15 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113221A07C4; Mon, 7 Apr 2014 08:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_YfSjN48IwJ; Mon, 7 Apr 2014 08:27:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7E1A07B9; Mon, 7 Apr 2014 08:27:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407152705.16521.8347.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 08:27:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/FQf4PmeBBgCgpmzoCB-TXMAI0B0 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-registry-passive-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:27:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Passive Performance Metrics Sub-Registry Authors : Aamer Akhter Benoit Claise Filename : draft-ietf-ippm-registry-passive-00.txt Pages : 22 Date : 2014-04-07 Abstract: This memo defines the Passive Performance Metrics sub-registry of the Performance Metric Registry. This sub-registry will contain Passive Performance Metrics, especially those defined in RFCs prepared in the IP Performance Metrics (IPPM) Working Group of the IETF, and possibly applicable to other IETF metrics. IPPM Passive metric registration is meant to allow wider adoption of common metrics in an inter-operable way. There are challenges with metric interoperability and adoption (to name a few) due to flexible input parameters, confusion between many similar metrics, and varying output formats. This memo proposes a way to organize registry entries into columns that are well-defined, permitting consistent development of entries over time (a column may be marked NA if it is not applicable for that metric). The design is intended to foster development of registry entries based on existing reference RFCs, whilst each column serves as a check-list item to avoid omissions during the registration process. Every entry in the registry, before IANA action, requires Expert review as defined by concurrent IETF work in progress "Registry for Performance Metrics" (draft-manyfolks-ippm-metric- registry). The document contains example entries for the Passive Performance Metrics sub-registry: a registry entry for a passive metric based on octetTotalCount as defined in RFC5102 and a protocol specific passive metric based on RTP packets lost as defined in RFC3550. The examples are for Informational purposes and do not create any entry in the IANA registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-registry-passive/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-registry-passive-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 7 08:36:02 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7D21A01B2 for ; Mon, 7 Apr 2014 08:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcMYkO0ZyWNk for ; Mon, 7 Apr 2014 08:35:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C93AC1A045A for ; Mon, 7 Apr 2014 08:35:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407153551.10646.50640.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 08:35:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/3E1HFChDGW1yit1Pzg68FzY9Z-Y Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:36:00 -0000 Changed milestone "Submit draft on registry for active performance metrics to IESG as Proposed Standard", added draft-ietf-ippm-registry-active to milestone. Changed milestone "Submit draft on registry for passive performance metrics to IESG as Proposed Standard", added draft-ietf-ippm-registry-passive to milestone. URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Wed Apr 16 12:40:01 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898561A02DE; Wed, 16 Apr 2014 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8zd8Z01geqr; Wed, 16 Apr 2014 12:39:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 491E61A021D; Wed, 16 Apr 2014 12:39:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416193956.1942.22841.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 12:39:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/7xCL-LJJ5N_p3ld2iPX8glc1KHo Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-2330-update-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:39:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Advanced Stream and Sampling Framework for IPPM Authors : Joachim Fabini Al Morton Filename : draft-ietf-ippm-2330-update-04.txt Pages : 16 Date : 2014-04-16 Abstract: To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them, otherwise unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-2330-update-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2330-update-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 22 00:25:03 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2193D1A00D3 for ; Tue, 22 Apr 2014 00:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.473 X-Spam-Level: X-Spam-Status: No, score=-104.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MZxHakFVZ3Y for ; Tue, 22 Apr 2014 00:24:39 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3615E1A0028 for ; Tue, 22 Apr 2014 00:24:38 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CA118FA99B9 for ; Tue, 22 Apr 2014 09:24:32 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.88.240] (unknown [163.117.88.240]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 31773119EE68 for ; Tue, 22 Apr 2014 09:24:32 +0200 (CEST) Message-ID: <5356195A.3050305@it.uc3m.es> Date: Tue, 22 Apr 2014 09:25:14 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20648.005 X-TM-AS-Result: No--2.609-7.0-31-1 X-imss-scan-details: No--2.609-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/HR17BK2M_Bh3ehEbs29y9UAjjXw Subject: [ippm] URIs as metric identifiers X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 07:24:46 -0000 Hi, In the LMAP WG, the framework document is using URIs as metric identifiers in the lmap protocols. In order to be compatible with that, the performance metric registries should have a URI column which would include a IANA allocated URI for each metric. Shall we do this? If we do this, shall we also keep the flat identifier and the metric name? Should there be any relation between the URI and the metric identifer and/or the metric name? Regards, marcelo From nobody Thu Apr 24 07:57:36 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB781A02A6; Thu, 24 Apr 2014 07:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2DxAHnJsPqZ; Thu, 24 Apr 2014 07:57:32 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 336B51A02A4; Thu, 24 Apr 2014 07:57:32 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 0FF561A06A1; Thu, 24 Apr 2014 16:56:54 +0200 (CEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 24 Apr 2014 16:56:53 +0200 Message-Id: To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/l4M6RY9kKSd0pFCcZq-iWpn-dnE Cc: lmap@ietf.org Subject: [ippm] WGLC on draft-ietf-ippm-lmap-path X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 14:57:34 -0000 --Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, This begins a Working Group Last Call on draft-ietf-ippm-lmap-path-02, = "A Reference Path and Measurement Points for LMAP". (I'm cross-posting = this to LMAP, so that the LMAP WG can have a chance to review as well, = given that this document is applicable to both WGs.) WGLC will run until Thursday 15 May 2014. Please review the document and = provide comments to ippm@ietf.org. Many thanks, best regards, Brian Trammell --Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTWSY1AAoJENt3nsOmbNJcHeUH/ihZCag2vpbfS1BS5ITPiqw5 LqjUY5Z7Uiiq3llVVddeMYji0M+H3z+bjJYlpzXgm7hFbsM8J2FKX26/7pdOyvvE T+tZXj8x2bmFWBKvT8xH0NX6OL7W8paAJGDDEZogYoO7Rln2rpLm3QMZoNV9fJRK f9SJY5dG9ukvwerygQ5asjqvkh9vQ8KDtLKXAadi69PlYK6BLpF8S98JdYoG3Qeb TawfcO/JLACxpkbMeIKT1syjvgGvnTcyQh8M6k6rxBBm5zThvX0JIfD1fWssTMWz ygelV3ZCWkwo1LGWxPLz7rA0Ynt9Itrh01cusRvYmGAqA6tPNSU1TM3BXpwVc8U= =0M2y -----END PGP SIGNATURE----- --Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE-- From nobody Thu Apr 24 10:10:37 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FAB1A0229; Thu, 24 Apr 2014 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.968 X-Spam-Level: * X-Spam-Status: No, score=1.968 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQgg9j0n2tTl; Thu, 24 Apr 2014 10:04:09 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD5A1A02BA; Thu, 24 Apr 2014 10:04:08 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s3OH40x8015726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2014 12:04:01 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 73AF71E0065; Thu, 24 Apr 2014 11:03:55 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 1E42B1E005E; Thu, 24 Apr 2014 11:03:55 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s3OH3sVE001205; Thu, 24 Apr 2014 12:03:54 -0500 (CDT) Received: from [10.188.201.94] (x1069818.dhcp.intranet [10.188.201.94]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s3OH3oEt001075; Thu, 24 Apr 2014 12:03:50 -0500 (CDT) Message-ID: <535943F6.80904@centurylink.com> Date: Thu, 24 Apr 2014 11:03:50 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: Brian Trammell References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------050302010308020803010000" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/K1tDq7wrFKtED0nepGTO6Ub6IfY X-Mailman-Approved-At: Thu, 24 Apr 2014 10:10:29 -0700 Cc: lmap@ietf.org, ippm@ietf.org Subject: Re: [ippm] [lmap] WGLC on draft-ietf-ippm-lmap-path X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:04:14 -0000 This is a multi-part message in MIME format. --------------050302010308020803010000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian, This is the first time I have read the draft, so I have several comments. Most of my comments are asking for clarifications to be added to the text. Here are my comments: Section 5 The numbering for measurement points (mpNNN ) allows for considerable local use of unallocated numbers. Is the numbering (mpNNN) arbitrary? Should there be rules so that it is known where the mp is based on the number? o Some use the terminology "on-net" and "off-net" when referring to Internet Service Provider (ISP) measurement coverage. With respect to the reference path, tests between mp100 and mp190 are "on-net". "on-net" and "off-net" are terms relative to the perspective of the network of interest. Mp100 and mp190 would only be "on-net" relative to the Access Service Provider. They would be "off-net" relative to a Transport Service Provider. There is probably a better way to address "on-net" and "off-net". o Widely deployed broadband access measurements have used pass- through devices[SK] (at the subscriber's location) directly connected to the service demarcation point: this would be located at mp100. What is [SK]? o The networking technology used at all measurement points must be indicated, especially the interface standard and configured speed. Please explain why the "must". A person doing an end-to-end measurement does not care what the technology is. However, if the measurement result is to be compared to another measurement result, it is essential that the technology is known in order to understand whether the results are comparable. If the "must" is to facilitate comparability, we should add that to the bullet. o If it can be shown that a link connecting to a measurement point has reliably deterministic or negligible performance , then the remote end of the connecting link is an equivalent point for some methods of measurement (To Be Specified Elsewhere). In any case, the presence of such a link must be reported. "negligible performance" does not make sense. You never want performance to be negligible. Clarification is needed here on what conditions result in an intermediate point being equivalent to the remote end. o Many access network architectures have a traffic aggregation point (e.g., CMTS or DSLAM ) between mp100 and mp150. We designate this point mp120, but it won't currently fit in the figure. Maybe more examples are needed. When I first looked at the mp figure, I assumed that mp150 would be a DSLAM or OLT. Are you saying the mp150 is an NPE (Network Provider Edge) switch? o In the case that a private address space is used in an access architecture, then mp100 may need to use the same address space as its remote measurement point counterpart , so that a test between these points produces a useful assessment of network performance. Tests between mp000 and mp100 could use private address space, and when the egress side of a CGN is at mp150, then the private address side of the CGN could be designated mp149 for tests with mp100. When you say "remote measurement point counterpart" that sounds like it should be between mp800 and mp900. Some clarification as to the example being discussed is needed. It appears that rather than a remote counterpoint, that you are talking about two devices in the same private network. o Measurement points at Transit GRA GWs are numbered mpX00 and mpX90, where X is the lowest positive integer not already used in the path. This is not consistent with the drawing. mpX00 could be mistaken for mp000 or mp100. Consider starting at mp200 and incrementing to mp290. ***My real comment is that I believe it would be much clearer to have a section detailing the numbering rules to ensure consistency. 6. Translation Between Ref. Path and Tech . X What is "Tech."? May be better to spell out. I don't recall seeing "Tech." defined. After further reading, this should probably be "Technology". Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit device Net #1 Net #2 Demarc. Access GW GRA GW mp000 mp100 mp150 mp190 mp200 |--UE--|------------CPE/NAT--------|-------|BRAS -|------| |----Access Network--| |_______Un-managed sub-path________|__Managed sub-path__| Where you have BRAS is where the DSLAM would be. The BRAS would typically be behind the GRA GW and sometimes behind the Transit GRA GW. Only if a distributed BRAS is used would it possibly be at mp150. Because of the variety to topologies that could be used, it may be useful to consider mps at domain boundaries. These could be Domain mps, and Intra-Domain mps. We may need some more thinking in regarding the identification of measurement points. Also, why does "Access Network" need to be shown? Section 7 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit device Net #1 Net #2 Demarc. Access GW GRA GW mp000 mp100 mp150 mp190 mp200 |--UE--|------------CPE/NAT--------|------|-CGN-|------| Wi-Fi wired |---Access Network--| |-Shared--|RT|------Dedicated------| RT |-----Shared------... |_______Un-managed sub-path________|_Managed sub-path__| I have been asking why we need to indicate "Access Network". From the figure for the example is Section 7, I'm thinking rather than say "Access Network" maybe it should be "DSL" or "GPON" to indicated the technology. "Wired" would be 1000BASE-T. That would make this row in the figure the Technology row in defining the path. Thanks for your efforts in putting together this draft. Regards, Charles Cook On 4/24/2014 8:56 AM, Brian Trammell wrote: > Greetings, all, > > This begins a Working Group Last Call on draft-ietf-ippm-lmap-path-02, "A Reference Path and Measurement Points for LMAP". (I'm cross-posting this to LMAP, so that the LMAP WG can have a chance to review as well, given that this document is applicable to both WGs.) > > WGLC will run until Thursday 15 May 2014. Please review the document and provide comments to ippm@ietf.org. > > Many thanks, best regards, > > Brian Trammell > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --------------050302010308020803010000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

This is the first time I have read the draft, so I have several comments.  Most of my comments are asking for clarifications to be added to the text.  Here are my comments:

Section 5
   The numbering for measurement points (mpNNN ) allows for considerable
   local use of unallocated numbers.

Is the numbering (mpNNN) arbitrary?  Should there be rules so that it is known where the mp is based on the number?

   o  Some use the terminology "on-net" and "off-net"  when referring to
      Internet Service Provider (ISP) measurement coverage.  With
      respect to the reference path, tests between mp100 and mp190 are
      "on-net".

“on-net” and “off-net” are terms relative to the perspective of the network of interest.  Mp100 and mp190 would only be “on-net” relative to the Access Service Provider.  They would be “off-net” relative to a Transport Service Provider.  There is probably a better way to address “on-net” and “off-net”.

   o  Widely deployed broadband access measurements have used pass-
      through devices[SK]  (at the subscriber's location) directly
      connected to the service demarcation point: this would be located
      at mp100.

What is [SK]?


   o  The networking technology used at all measurement points must  be
      indicated, especially the interface standard and configured speed.

Please explain why the "must".  A person doing an end-to-end measurement does not care what the technology is.  However, if the measurement result is to be compared to another measurement result, it is essential that the technology is known in order to understand whether the results are comparable.  If the "must" is to facilitate comparability, we should add that to the bullet.

   o  If it can be shown that a link connecting to a measurement point
      has reliably deterministic or negligible performance , then the
      remote end of the connecting link is an equivalent point for some
      methods of measurement (To Be Specified Elsewhere).  In any case,
      the presence of such a link must be reported.

"negligible performance" does not make sense.  You never want performance to be negligible.  Clarification is needed here on what conditions result in an intermediate point being equivalent to the remote end.

   o  Many access network architectures have a traffic aggregation point
      (e.g., CMTS or DSLAM ) between mp100 and mp150.  We designate this
      point mp120, but it won't currently fit in the figure.

Maybe more examples are needed.  When I first looked at the mp figure, I assumed that mp150 would be a DSLAM or OLT.  Are you saying the mp150 is an NPE (Network Provider Edge) switch?

   o  In the case that a private address space is used in an access
      architecture, then mp100 may need to use the same address space as
      its remote measurement point counterpart , so that a test between
      these points produces a useful assessment of network performance.
      Tests between mp000 and mp100 could use private address space, and
      when the egress side of a CGN is at mp150, then the private
      address side of the CGN could be designated mp149 for tests with
      mp100.

When you say “remote measurement point counterpart” that sounds like it should be between mp800 and mp900.  Some clarification as to the example being discussed is needed.  It appears that rather than a remote counterpoint, that you are talking about two devices in the same private network. 

   o  Measurement points at Transit GRA GWs are numbered mpX00  and
      mpX90, where X is the lowest positive integer not already used in
      the path.

This is not consistent with the drawing.  mpX00 could be mistaken for mp000 or mp100.  Consider starting at mp200 and incrementing to mp290.  ***My real comment is that I believe it would be much clearer to have a section detailing the numbering rules to ensure consistency.

6.  Translation Between Ref. Path and Tech .  X

What is “Tech.”?  May be better to spell out.  I don’t recall seeing “Tech.” defined.  After further reading, this should probably be "Technology".

   Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
   device     Net #1     Net #2    Demarc.    Access     GW     GRA GW
   mp000                            mp100      mp150    mp190    mp200
   |--UE--|------------CPE/NAT--------|-------|BRAS -|------|
                                      |----Access Network--|
   |_______Un-managed sub-path________|__Managed sub-path__|

Where you have BRAS is where the DSLAM would be.  The BRAS would typically be behind the GRA GW and sometimes behind the Transit GRA GW.  Only if a distributed BRAS is used would it possibly be at mp150.

 

Because of the variety to topologies that could be used, it may be useful to consider mps at domain boundaries.  These could be Domain mps, and Intra-Domain mps.  We may need some more thinking in regarding the identification of measurement points.

Also, why does “Access Network” need to be shown?  

Section 7
   Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
   device     Net #1     Net #2    Demarc.    Access     GW     GRA GW
   mp000                            mp100      mp150    mp190    mp200
   |--UE--|------------CPE/NAT--------|------|-CGN-|------|
              Wi-Fi      wired        |---Access Network--|

          |-Shared--|RT|------Dedicated------| RT  |-----Shared------...
   |_______Un-managed sub-path________|_Managed sub-path__|

I have been asking why we need to indicate "Access Network".  From the figure for the example is Section 7, I’m thinking rather than say “Access Network” maybe it should be “DSL” or “GPON” to indicated the technology.  “Wired” would be 1000BASE-T.  That would make this row in the figure the Technology row in defining the path.


Thanks for your efforts in putting together this draft.

Regards,
Charles Cook


On 4/24/2014 8:56 AM, Brian Trammell wrote:
Greetings, all,

This begins a Working Group Last Call on draft-ietf-ippm-lmap-path-02, "A Reference Path and Measurement Points for LMAP". (I'm cross-posting this to LMAP, so that the LMAP WG can have a chance to review as well, given that this document is applicable to both WGs.)

WGLC will run until Thursday 15 May 2014. Please review the document and provide comments to ippm@ietf.org.

Many thanks, best regards,

Brian Trammell



_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap


-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com
--------------050302010308020803010000-- From nobody Mon Apr 28 14:55:18 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F93B1A8839; Mon, 28 Apr 2014 14:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBqaKi2sTUEQ; Mon, 28 Apr 2014 14:55:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 196C31A6FAD; Mon, 28 Apr 2014 14:55:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140428215512.30831.82462.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 14:55:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/HFKWyqdbIpJDRyNEOA2cWP8fa7Y Cc: ippm@ietf.org Subject: [ippm] Last Call: (Advanced Stream and Sampling Framework for IPPM) to Informational RFC X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:55:15 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Advanced Stream and Sampling Framework for IPPM' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them, otherwise unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-2330-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-2330-update/ballot/ No IPR declarations have been submitted directly on this I-D.