From nobody Tue Jul 1 22:27: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 1A8311B287F for ; Tue, 1 Jul 2014 22:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 wzZ1B9ubR9Ep for ; Tue, 1 Jul 2014 22:27:15 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id AD37D1A0AF2 for ; Tue, 1 Jul 2014 22:27:14 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee553b39830764-4a764; Wed, 02 Jul 2014 13:27:12 +0800 (CST) X-RM-TRANSID: 2ee553b39830764-4a764 Received: from cmccPC (unknown[10.2.43.183]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee353b3982c85c-e68b6; Wed, 02 Jul 2014 13:27:12 +0800 (CST) X-RM-TRANSID: 2ee353b3982c85c-e68b6 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Wed, 2 Jul 2014 13:27:13 +0800 Message-ID: <01e001cf95b6$47f615d0$d7e24170$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+VteYnO+Y18CxMSiu51duBz8nHMgAAAnrA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/JetEwNwbTjNPoNz_-BzhkdPQWM8 Subject: [ippm] FW: New Version Notification for draft-deng-ippm-passive-wireless-usecase-00.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: Wed, 02 Jul 2014 05:27:17 -0000 Hi all, The following use-case draft for passive IP measurements in wireless = networks is submitted. Your review and comments are very welcome. Lingli > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, July 02, 2014 1:24 PM > To: Greg Mirsky; Lianshu Zheng; Greg Mirsky; Deng Lingli; Lingli Deng; > Lianshu Zheng > Subject: New Version Notification for > draft-deng-ippm-passive-wireless-usecase-00.txt >=20 >=20 > A new version of I-D, draft-deng-ippm-passive-wireless-usecase-00.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. >=20 > Name: draft-deng-ippm-passive-wireless-usecase > Revision: 00 > Title: Use-cases for Passive Measurement in Wireless Networks > Document date: 2014-07-02 > Group: Individual Submission > Pages: 9 > URL: > = http://www.ietf.org/internet-drafts/draft-deng-ippm-passive-wireless-usec= as > e-00.txt > Status: > = https://datatracker.ietf.org/doc/draft-deng-ippm-passive-wireless-usecase= / > Htmlized: > http://tools.ietf.org/html/draft-deng-ippm-passive-wireless-usecase-00 >=20 >=20 > Abstract: > This document presents use-cases for passive IP performance > measurements in wireless networks. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Wed Jul 2 02:30:53 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 4EBE01B27E0 for ; Wed, 2 Jul 2014 02:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yu-NPhL-CGeB for ; Wed, 2 Jul 2014 02:30:50 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 021811B27DF for ; Wed, 2 Jul 2014 02:30:49 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 336361A0968 for ; Wed, 2 Jul 2014 11:30:17 +0200 (CEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_BE1F2640-D3FA-4C94-A10C-A0021ED560B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <017EE38A-2B06-429F-AAC9-27F45932AD5C@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Wed, 2 Jul 2014 11:30:16 +0200 References: <20140529194155.17884.67924.idtracker@ietfa.amsl.com> <47EC9EAE-25A9-4E0F-B5F9-10593A4DDD0C@trammell.ch> To: ippm@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/thTR89ARA0Yk52HHFMEu06gDcmQ Subject: Re: [ippm] Calls for adoption as WG items 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: Wed, 02 Jul 2014 09:30:52 -0000 --Apple-Mail=_BE1F2640-D3FA-4C94-A10C-A0021ED560B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Greetings, IPPM, A gentle reminder: We would like very much to have discussion on = adoption completed before the Toronto meeting, so we can spend face to = face time on the documents themselves. And we cannot adopt drafts as = Working Group items for which there is not a strong demonstration of = support and commitment to read, review, and improve the drafts. So, please see last week's call for adoption notice, consider whether = you support adoption of the named drafts, and whether you can commit to = review them. The deadline for this call for adoption is, as before, end of day = Thursday 10 July 2014. Many thanks and best regards, Brian Trammell, as co-chair. On 24 Jun 2014, at 16:17, Brian Trammell wrote: > Greetings, IPPM, >=20 > This is a call for adoption for four new milestones under the current = IPPM charter. >=20 > (1) Submit a draft updating RFC2679 based on testing and = implementation=20 > experience (RFC 6808) to the IESG as Proposed Standard > (under consideration for this milestone is = draft-morton-ippm-2679-bis-04) >=20 > (2) Submit a draft updating RFC2680 based on testing and = implementation=20 > experience (draft-ietf-ippm-testplan-rfc2680-05) to the IESG as=20 > Proposed Standard > (under consideration for this milestone is = draft-morton-ippm-2679-bis-04) >=20 > (3) Submit a draft adding DSCP and ECN monitoring to TWAMP to the=20 > IESG as Proposed Standard > (under consideration for this milestone is = draft-hedin-ippm-type-p-monitor-03) >=20 > (4) Submit a draft adding a UDP Checksum Trailer to OWAMP and TWAMP to = the IESG=20 > as Informational > (under consideration for this milestone is = draft-mizrahi-ippm-checksum-trailer-00) >=20 > For each draft, please indicate the following to the list at = ippm@ietf.org >=20 > (a) whether you support the addition of the milestone and the adoption = of the draft as a WG item to fulfill that milestone > (b) whether you have read the draft > (c) whether you pledge to review the draft during the WG process. >=20 > This call for adoption will last until Thursday 10 July 2014. >=20 > Many thanks, best regards, >=20 > Brian >=20 > On 02 Jun 2014, at 18:07, Brian Trammell wrote: >=20 >> Greetings, IPPM, >>=20 >> Thanks and congratulations to the authors on the approval of our = first draft from the "new" (March 2013) charter! >>=20 >> As we're moving forward in our charter, it's time to consider = adopting new drafts. >>=20 >> I've seen implicit requests for a call for adoption for the following = two drafts, which were not adopted in Orlando because we wanted to see = if 2330-update would change their scope significantly: >>=20 >> draft-morton-ippm-2679-bis-04 >> draft-morton-ippm-2680-bis-02 >>=20 >> We have at least one explicit request for a call for adoption: >>=20 >> draft-hedin-ippm-type-p-monitor-03 >>=20 >> If there are other documents which you would like to have considered = for adoption as IPPM WG items in the next round under the present = charter, please notify the chairs at ippm-chairs@tools.ietf.org by = Friday, June 6th; we'll run the call for adoption after that. >>=20 >> Thanks, cheers, >>=20 >> Brian (as chair) >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: The IESG >>> Subject: Document Action: 'Advanced Stream and Sampling Framework = for IPPM' to Informational RFC (draft-ietf-ippm-2330-update-05.txt) >>> Date: 29 May 2014 21:41:55 GMT+2 >>> Resent-To: bill@wjcerveny.com, ietf@trammell.ch, >>> To: IETF-Announce >>> Cc: RFC Editor , ippm mailing list = , ippm chair >>>=20 >>> The IESG has approved the following document: >>> - 'Advanced Stream and Sampling Framework for IPPM' >>> (draft-ietf-ippm-2330-update-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-2330-update/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Technical Summary >>>=20 >>> To obtain repeatable results in modern networks, test descriptions=20= >>> need an expanded stream parameter framework that also augments=20 >>> aspects specified as Type-P for test packets. This memo updates >>> the IP Performance Metrics (IPPM) Framework, RFC 2330, with=20 >>> advanced considerations for measurement methodology and testing. =20 >>> The existing framework mostly assumes deterministic connectivity,=20 >>> and that a single test stream will represent the characteristics of = the=20 >>> path when it is aggregated with other flows. Networks have evolved=20= >>> and test stream descriptions must evolve with them, otherwise=20 >>> unexpected network features may dominate the measured performance. =20= >>> This memo describes new stream parameters for both network=20 >>> characterization and support of application design using IPPM = metrics. >>>=20 >>> Working Group Summary >>>=20 >>> This draft was first introduced to the working group in October = 2012.=20 >>> Support for the draft was indicated at meetings with no dissent. >>>=20 >>> Document Quality >>>=20 >>> As an update to the IPPM Framework, this document adds=20 >>> new and updated considerations for stream parameters. >>>=20 >>> The document shepherd reviewed the document as a =93-02=94=20 >>> draft and reviewed the changes which constitute =93-03=94 and =93-04=94= . >>>=20 >>> As documented, other topics in the IPPM Framework which=20 >>> might be updated or augmented are deferred to future work. This=20 >>> includes the topics of passive and various forms of of hybrid=20 >>> active/passive measurements. >>>=20 >>> Personnel >>>=20 >>> The document shepherd was Bill Cerveny. The responsible=20 >>> area director is Spencer Dawkins. >>=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_BE1F2640-D3FA-4C94-A10C-A0021ED560B0 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 iQEcBAEBCgAGBQJTs9EoAAoJENt3nsOmbNJckTsIAJZbRzlolGofBAPZkxNdCuWt R/58WWY8VwmsbTruY1yXk1Z05oB0PvZValdSisPpkz71fVntDq3JaHZB+0qZdA3x 52DxIUSDRn0sz4aGpa0sBbFWSORvvnOALq2AXoanh0SLfm+AYai2tl+u0LOUVTgV VnludKOzSZfaeM69jUyyQBehWBAWjdO8hSNfeGv3FgSZXnvABo3shTzZbiSbd7jY RhMpGSvlBC7hWbTVmjINNmCW/7UFNxiUf9vqKSi4/igznwfeFnIedaEYZU9EpgaX XiY4EMXsM8wckjSswjREYcHfiJ2STjRJmjpH/DoxXLztbqCT/ynTqQlloP8vXcQ= =sL4m -----END PGP SIGNATURE----- --Apple-Mail=_BE1F2640-D3FA-4C94-A10C-A0021ED560B0-- From nobody Wed Jul 2 04:02:52 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 560E31B2901 for ; Wed, 2 Jul 2014 04:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 XYBZmP598PRM for ; Wed, 2 Jul 2014 04:02:47 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F1C1B28FE for ; Wed, 2 Jul 2014 04:02:46 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 02 Jul 2014 13:02:22 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 2 Jul 2014 13:02:21 +0200 From: To: Date: Wed, 2 Jul 2014 13:02:20 +0200 Thread-Topic: [ippm] Calls for adoption as WG items Thread-Index: Ac+V2kqMzxN944jpTsSJcVMgKQx5EAACnudA Message-ID: References: <20140529194155.17884.67924.idtracker@ietfa.amsl.com> <47EC9EAE-25A9-4E0F-B5F9-10593A4DDD0C@trammell.ch> <017EE38A-2B06-429F-AAC9-27F45932AD5C@trammell.ch> In-Reply-To: <017EE38A-2B06-429F-AAC9-27F45932AD5C@trammell.ch> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/T_WEqP2wJ_f5w4b3hyEtThZInsQ Cc: ippm@ietf.org Subject: Re: [ippm] Calls for adoption as WG items 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: Wed, 02 Jul 2014 11:02:49 -0000 Hi Brian, I support adopting these new milestones. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: ippm [mailto:ippm-bounces@ietf.org] Im Auftrag von Brian Trammell Gesendet: Mittwoch, 2. Juli 2014 11:30 An: ippm@ietf.org Betreff: Re: [ippm] Calls for adoption as WG items Greetings, IPPM, A gentle reminder: We would like very much to have discussion on adoption c= ompleted before the Toronto meeting, so we can spend face to face time on t= he documents themselves. And we cannot adopt drafts as Working Group items = for which there is not a strong demonstration of support and commitment to = read, review, and improve the drafts. So, please see last week's call for adoption notice, consider whether you s= upport adoption of the named drafts, and whether you can commit to review t= hem. The deadline for this call for adoption is, as before, end of day Thursday = 10 July 2014. Many thanks and best regards, Brian Trammell, as co-chair. On 24 Jun 2014, at 16:17, Brian Trammell wrote: > Greetings, IPPM, >=20 > This is a call for adoption for four new milestones under the current IPP= M charter. >=20 > (1) Submit a draft updating RFC2679 based on testing and implementation=20 > experience (RFC 6808) to the IESG as Proposed Standard (under=20 > consideration for this milestone is draft-morton-ippm-2679-bis-04) >=20 > (2) Submit a draft updating RFC2680 based on testing and implementation=20 > experience (draft-ietf-ippm-testplan-rfc2680-05) to the IESG as=20 > Proposed Standard > (under consideration for this milestone is=20 > draft-morton-ippm-2679-bis-04) >=20 > (3) Submit a draft adding DSCP and ECN monitoring to TWAMP to the=20 > IESG as Proposed Standard > (under consideration for this milestone is=20 > draft-hedin-ippm-type-p-monitor-03) >=20 > (4) Submit a draft adding a UDP Checksum Trailer to OWAMP and TWAMP to th= e IESG=20 > as Informational > (under consideration for this milestone is=20 > draft-mizrahi-ippm-checksum-trailer-00) >=20 > For each draft, please indicate the following to the list at=20 > ippm@ietf.org >=20 > (a) whether you support the addition of the milestone and the adoption=20 > of the draft as a WG item to fulfill that milestone > (b) whether you have read the draft > (c) whether you pledge to review the draft during the WG process. >=20 > This call for adoption will last until Thursday 10 July 2014. >=20 > Many thanks, best regards, >=20 > Brian >=20 > On 02 Jun 2014, at 18:07, Brian Trammell wrote: >=20 >> Greetings, IPPM, >>=20 >> Thanks and congratulations to the authors on the approval of our first d= raft from the "new" (March 2013) charter! >>=20 >> As we're moving forward in our charter, it's time to consider adopting n= ew drafts. >>=20 >> I've seen implicit requests for a call for adoption for the following tw= o drafts, which were not adopted in Orlando because we wanted to see if 233= 0-update would change their scope significantly: >>=20 >> draft-morton-ippm-2679-bis-04 >> draft-morton-ippm-2680-bis-02 >>=20 >> We have at least one explicit request for a call for adoption: >>=20 >> draft-hedin-ippm-type-p-monitor-03 >>=20 >> If there are other documents which you would like to have considered for= adoption as IPPM WG items in the next round under the present charter, ple= ase notify the chairs at ippm-chairs@tools.ietf.org by Friday, June 6th; we= 'll run the call for adoption after that. >>=20 >> Thanks, cheers, >>=20 >> Brian (as chair) >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: The IESG >>> Subject: Document Action: 'Advanced Stream and Sampling Framework=20 >>> for IPPM' to Informational RFC (draft-ietf-ippm-2330-update-05.txt) >>> Date: 29 May 2014 21:41:55 GMT+2 >>> Resent-To: bill@wjcerveny.com, ietf@trammell.ch, >>> To: IETF-Announce >>> Cc: RFC Editor , ippm mailing list=20 >>> , ippm chair >>>=20 >>> The IESG has approved the following document: >>> - 'Advanced Stream and Sampling Framework for IPPM' >>> (draft-ietf-ippm-2330-update-05.txt) as Informational RFC >>>=20 >>> This document is the product of the IP Performance Metrics Working Grou= p. >>>=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-2330-update/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Technical Summary >>>=20 >>> To obtain repeatable results in modern networks, test descriptions=20 >>> need an expanded stream parameter framework that also augments=20 >>> aspects specified as Type-P for test packets. This memo updates the=20 >>> IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced=20 >>> considerations for measurement methodology and testing. >>> The existing framework mostly assumes deterministic connectivity,=20 >>> and that a single test stream will represent the characteristics of=20 >>> the path when it is aggregated with other flows. Networks have=20 >>> evolved and test stream descriptions must evolve with them,=20 >>> otherwise unexpected network features may dominate the measured perform= ance. >>> This memo describes new stream parameters for both network=20 >>> characterization and support of application design using IPPM metrics. >>>=20 >>> Working Group Summary >>>=20 >>> This draft was first introduced to the working group in October 2012.=20 >>> Support for the draft was indicated at meetings with no dissent. >>>=20 >>> Document Quality >>>=20 >>> As an update to the IPPM Framework, this document adds new and=20 >>> updated considerations for stream parameters. >>>=20 >>> The document shepherd reviewed the document as a "-02"=20 >>> draft and reviewed the changes which constitute "-03" and "-04". >>>=20 >>> As documented, other topics in the IPPM Framework which might be=20 >>> updated or augmented are deferred to future work. This includes the=20 >>> topics of passive and various forms of of hybrid active/passive=20 >>> measurements. >>>=20 >>> Personnel >>>=20 >>> The document shepherd was Bill Cerveny. The responsible area=20 >>> director is Spencer Dawkins. >>=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Jul 3 02:25:34 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 DE7471B2817; Thu, 3 Jul 2014 02:25:32 -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 uCNlEjmFzsNR; Thu, 3 Jul 2014 02:25:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E30E01B281E; Thu, 3 Jul 2014 02:25:31 -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.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703092531.19766.6821.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 02:25:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/luJxwJIe8QM5sYi4kFURjZJJY40 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-metric-registry-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 Jul 2014 09:25:33 -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 : Registry for Performance Metrics Authors : Marcelo Bagnulo Benoit Claise Philip Eardley Al Morton Filename : draft-ietf-ippm-metric-registry-00.txt Pages : 19 Date : 2014-07-03 Abstract: This document specifies the common aspects of the IANA Registry for Performance Metrics, both active and passive categories. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-metric-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-metric-registry-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 Jul 3 07:21:45 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 EF7F61B2A9A for ; Thu, 3 Jul 2014 07:21:42 -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 m1uvUGp-_2ZA for ; Thu, 3 Jul 2014 07:21:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 613C31B2A7E for ; Thu, 3 Jul 2014 07:21:38 -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.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703142138.11134.18059.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 07:21:38 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/U524sdAFflE2IQWs5voA6DsxG-U 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: Thu, 03 Jul 2014 14:21:43 -0000 Changed milestone "Submit draft on core registry for performance metrics to IESG as Proposed Standard", added draft-ietf-ippm-metric-registry to milestone. URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Thu Jul 3 20:24:08 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 F0FC61B2930; Thu, 3 Jul 2014 20:24:05 -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 oxARvWC5eZkc; Thu, 3 Jul 2014 20:24:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E24871B278E; Thu, 3 Jul 2014 20:24:03 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704032403.11895.42573.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 20:24:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Ux14wcrpBFpzfIO1ybCYNdszUYs Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-model-based-metrics-03.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: Fri, 04 Jul 2014 03:24:06 -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 : Model Based Bulk Performance Metrics Authors : Matt Mathis Al Morton Filename : draft-ietf-ippm-model-based-metrics-03.txt Pages : 43 Date : 2014-07-03 Abstract: We introduce a new class of model based metrics designed to determine if an end-to-end Internet path can meet predefined transport performance targets by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to key infrastructure, such as interconnects, to accurately detect if it will prevent the full end-to-end paths that traverse it from meeting the specified target performance. Each IP diagnostic test consists of a precomputed traffic pattern and a statistical criteria for evaluating packet delivery. The traffic patterns are precomputed to mimic TCP or other transport protocol over a long path but are independent of the actual details of the subpath under test. Likewise the success criteria depends on the target performance for the long path and not the details of the subpath. This makes the measurements open loop, which introduces several important new properties and eliminates most of the difficulties encountered by traditional bulk transport metrics. This document does not define diagnostic tests, but provides a framework for designing suites of diagnostics tests that are tailored the confirming the target performance. Interim DRAFT Formatted: Thu Jul 3 20:19:04 PDT 2014 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-model-based-metrics/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-model-based-metrics-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-model-based-metrics-03 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 Fri Jul 4 07:17:56 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 940971B29BC; Fri, 4 Jul 2014 07:17:52 -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 tPhNR9Kyd7P2; Fri, 4 Jul 2014 07:17:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEC21B2850; Fri, 4 Jul 2014 07:17:50 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704141750.1061.75381.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 07:17:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/SSIF21GPu8i8hcoGwnlQ92LZ6_M Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-registry-passive-01.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: Fri, 04 Jul 2014 14:17:52 -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-01.txt Pages : 23 Date : 2014-07-04 Abstract: This document specifies the Passive Performance Metrics sub-registry of the Performance Metric Registry. This sub-registry contains 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. This document specifies 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-ietf-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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-registry-passive-01 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 Fri Jul 4 12:10:20 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 565E01B2B6A; Fri, 4 Jul 2014 12:10:16 -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 gywGt3cIR4qf; Fri, 4 Jul 2014 12:10:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9D41B297D; Fri, 4 Jul 2014 12:10:14 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704191014.10540.88626.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 12:10:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/5FHgavWemF-3fRxbERPPUW8ZMDA Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-registry-active-01.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: Fri, 04 Jul 2014 19:10:16 -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-01.txt Pages : 27 Date : 2014-07-04 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-ietf-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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-registry-active-01 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 Fri Jul 4 13:43:29 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 965851B2F8F; Fri, 4 Jul 2014 13:43:27 -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 CSsNH3R0dQwZ; Fri, 4 Jul 2014 13:43:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9C61B2F8B; Fri, 4 Jul 2014 13:43:26 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704204326.17376.699.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 13:43:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/7M8VoXiY67t4GSfHAKmbJ2_DmCU Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-morton-ippm-2679-bis-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: Fri, 04 Jul 2014 20:43:27 -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 : A One-Way Delay Metric for IPPM Authors : Guy Almes Sunil Kalidindi Matt Zekauskas Al Morton Filename : draft-morton-ippm-2679-bis-05.txt Pages : 23 Date : 2014-07-04 Abstract: This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-morton-ippm-2679-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-morton-ippm-2679-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-morton-ippm-2679-bis-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 Fri Jul 4 13:47: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 76D961B2F9A; Fri, 4 Jul 2014 13:46:59 -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 QPRTsnqNj6By; Fri, 4 Jul 2014 13:46:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD301A0384; Fri, 4 Jul 2014 13:46:58 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704204658.15292.77589.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 13:46:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/zjhjhWS9XvICyeptisb8HSUByrA Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-morton-ippm-2680-bis-03.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: Fri, 04 Jul 2014 20:46:59 -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 : A One-Way Loss Metric for IPPM Authors : Guy Almes Sunil Kalidindi Matt Zekauskas Al Morton Filename : draft-morton-ippm-2680-bis-03.txt Pages : 19 Date : 2014-07-04 Abstract: This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-morton-ippm-2680-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-morton-ippm-2680-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-morton-ippm-2680-bis-03 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 Fri Jul 4 13:48:50 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 907BC1B2FA1 for ; Fri, 4 Jul 2014 13:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_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 mQDTixXEaUpM for ; Fri, 4 Jul 2014 13:48:45 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id C91EE1B2F9F for ; Fri, 4 Jul 2014 13:48:44 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 056F5120E74; Fri, 4 Jul 2014 16:52:47 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id 4CEDCE042B; Fri, 4 Jul 2014 16:47:42 -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; Fri, 4 Jul 2014 16:48:44 -0400 From: "MORTON, ALFRED C (AL)" To: Barry Constantine , "ippm@ietf.org" Date: Fri, 4 Jul 2014 16:48:42 -0400 Thread-Topic: [ippm] RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680 Thread-Index: Ac94Ldpbl13tFwfNRqu7VHkTCuyiHQfk6bHA Message-ID: <2845723087023D4CB5114223779FA9C80189AAD4F6@njfpsrvexg8.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C80189AAD4F6njfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/WIJfQEQRlubpCSf45dPQrkXFBqg Subject: Re: [ippm] RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680 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: Fri, 04 Jul 2014 20:48:48 -0000 --_000_2845723087023D4CB5114223779FA9C80189AAD4F6njfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barry, thanks again for your comments on the -bis drafts, some replies below, ACM: regards, Al From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Sunday, May 25, 2014 12:18 PM To: ippm@ietf.org Subject: [ippm] RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rf= c2680 Hello IPPM, I have reviewed RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rf= c2680. Being in the test and measurement industry, I think standardizing these del= ay and loss RFCs would be very valuable to the industry. Loss and delay ar= e two of the key parameters that are part of a service SLA; there are varyi= ng techniques used to measure loss and delay and this leads to differing me= asurement results (inter-operability of test equipment is a whole other sto= ry...). I do have some comments I would like to add for each RFC and am listing the= se below: RFC 2679bis: Section 1: Packet transfer on Faster-Than-Light (FTL) networks could result in negativ= e delays and packet reordering, and both are covered as possibilities in th= e current text. ** This is interesting, can this be expanded upon with a sentence or two to= explain this phenomena? RFC 6291 is dated April 1st... Section 2.1: Performance of an application may depend mostly on the performance in one d= irection. For example, a file transfer using TCP may depend more on the pe= rformance in the direction that data flows, rather than the direction in wh= ich acknowledgements travel. ** There were some recent comments on this, mine may overlap. I understand= how one way performance of TCP is affected by loss in the direction of the= data (i.e. upload). It was not intuitive why one way delay is important f= or TCP, since TCP stacks use RTT for it's congestion avoidance algorithms, = etc. ACM: clearly delay of both directions contributes to RTT, as the queues gro= w in the forward direction they may tend to dominate, a la buffer bloat. I= clarified this briefly. Section 3.5: Real delay values will be positive. Therefore, it does not make sense to r= eport a negative value as a real delay.... ** Be good to tie this into the description of Faster-Than-Light (FTL) netw= orks for clarity Section 3.6: At the Src host, select Src and Dst IP addresses, and form a test packet of= Type-P with these addresses. Any 'padding' portion of the packet needed o= nly to make the test packet a given size should be filled with randomized b= its to avoid a situation in which the measured delay is lower than it would= otherwise be due to compression techniques along the path. ** I think this ties into the broader subject of WAN altering devices such = as WAN Accelerators, Firewalls, IDS, etc which will certainly affect the de= lay. It seems useful to add a paragraph (and diagram?) to discuss the vari= ous points in a network where delay may be measured and the potential impac= t of various devices. It would be useful to suggest delay measurements wit= h WAN acceleration ON and OFF, etc. ACM: One of the IESG comments on the RFC2330 update resulted in adding this= text, when mentioning compression (approx. same added here): We note that use of transport layer encryption will counteract the deployme= nt of network-based analysis and may reduce the adoption of payload optimizations= , however. Section 3.7.2: Errors or uncertainties related to Wire-time vs Host-time ** Good to mention here they NIC card and some of the offloading that occur= s, the time stamps occur "before the wire" and there can be TCP segment off= load, etc.. Capturing on the wire benefits, which might be mentioned here.= .. ACM: mentioned this, both Nalini and Joachim have raised this point too. Section 3.8.4: Path ** Should traceroute be mentioned to obtain a static snapshot? Even if it = is static per se, in most managed networks the path will not change. ACM: in this day and age, tracert packets and measurement packets can easil= y follow different paths RFC 2680bis: Section 2.7: In addition, the instruments should be checked to ensure the that the possi= bility a packet arrives at the network interface, but is lost due to conges= tion on the interface or to other resource exhaustion (e.g., buffers) on th= e instrument is low. ** Does it make sense to suggest that the instruments should be calibrated = running a head-head RFC 2544 test? ACM: I think this is an on-going check for congestion, packets will certain= ly be lost if the buffers fill. Although you proposed a lab calibration, which is fine, http://tools.ietf.o= rg/html/rfc6815 is worth noting. Section 2.8.1: UDP or TCP protocol ** This comments applies to both 2680bis and the 2680 draft test plan. TCP= is mentioned as a possible means to conduct loss and delay testing, but th= e RFC 2679/80 and test plan do not expand on guidelines when using TCP. An= example would be retransmissions, how do the loss statistics get measured = when there are retransmits? ACM: According to the metric definitions, each packet gets an unambiguous = wire-time, T. So, the packet at time T is either lost or not. If a TCP segment is retran= smitted, it gets a later wire-time, T, and is treated individually. How do the delay metrics get measured when there are retransmits, etc.? I'= m not even sure that using TCP traffic for these measurements is feasible b= ut understand that in some networks that have Layer 4 aware devices, that T= CP may be the only way (this is related to my earlier comment regarding WAN= accelerators, Firewalls, etc.) ACM: my guess is that answers for TCP appear in the BTC framework http://tools.ietf.org/html/rfc3148 Section 4.1: The reference to healthy Internet paths operating at below 1% loss, is that= dated (seems high)? ACM: it's mostly to provide background for a comment about statistics, whic= h is still valid. **** Again fully support these RFCs to become standards and hope these comments = are useful. Thank you, Barry Constantine --_000_2845723087023D4CB5114223779FA9C80189AAD4F6njfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Barry,

<= p class=3DMsoNormal> 

thanks again for your comments on the = -bis drafts,

some replies below, ACM:<= /span>

 

regards,<= /p>

Al

 

From: ippm [mailto:ippm-bounces@ietf.org] = On Behalf Of Barry Constantine
Sent: Sunday, May 25, 2014 12:= 18 PM
To: ippm@ietf.org
Subject: [ippm] RFC 2679bis and= RFC 2680bis and draft-ietf-ippm-testplan-rfc2680

 

H= ello IPPM,

 

I have reviewed RFC 2679bis and RFC 2680bis and draft-ie= tf-ippm-testplan-rfc2680.

 =

Being in the test and measurement industr= y, I think standardizing these delay and loss RFCs would be very valuable t= o the industry.  Loss and delay are two of the key parameters that are= part of a service SLA; there are varying techniques used to measure loss a= nd delay and this leads to differing measurement results (inter-operability= of test equipment is a whole other story...).

 

I do have some comm= ents I would like to add for each RFC and am listing these below:

 

R= FC 2679bis:

 

Section 1:  
Packet transfer on Faster-Than-Ligh=
t (FTL) networks could result in negative delays and packet reordering, and=
 both are covered as possibilities in the current text.
 
** This is interesting, can this be expanded =
upon with a sentence or two to explain this phenomena?
 
RFC 6291 is dated April 1st...
 
Section 2.1:
Perform=
ance of an application may depend mostly on the performance in one directio=
n.  For example, a file transfer using TCP may depend more on the perf=
ormance in the direction that data flows, rather than the direction in whic=
h acknowledgements travel.
 
** There were some recent comments on this, mine may overlap.  I unde=
rstand how one way performance of TCP is affected by loss in the direction =
of the data (i.e. upload).  It was not intuitive why one way delay is =
important for TCP, since TCP stacks use RTT for it’s congestion avoid=
ance algorithms, etc.
 
ACM:=
 clearly delay of both directions contributes to RTT, as the queues grow in=
 the forward direction they may tend to dominate, a la buffer bloat.  =
I clarified this briefly. 
 
Section 3.5:
Real delay values will be positive. =
; Therefore, it does not make sense to report a negative value as a real de=
lay….
 
** Be good to tie t=
his into the description of Faster-Than-Light (FTL) networks for clarity
 
 
=
Section 3.6:
At the Src host, select Src and Dst IP ad=
dresses, and form a test packet of Type-P with these addresses.  Any '=
padding' portion of the packet needed only to make the test packet a given =
size should be filled with randomized bits to avoid a situation in which th=
e measured delay is lower than it would otherwise be due to compression tec=
hniques along the path.
 
**=
 I think this ties into the broader subject of WAN altering devices such as=
 WAN Accelerators, Firewalls, IDS, etc which will certainly affect the dela=
y.  It seems useful to add a paragraph (and diagram?) to discuss the v=
arious points in a network where delay may be measured and the potential im=
pact of various devices.  It would be useful to suggest delay measurem=
ents with WAN acceleration ON and OFF, etc.
 =
;
ACM: One of the IESG comments on the RFC2330 update resul=
ted in adding this text,
when mentioning compression (=
approx. same added here):
 
=
We note that use of transport layer encryption will counteract the deployme=
nt of 
network-based analysis and may reduce the adopt=
ion of payload optimizations, however.
 
 
Section 3.7.2:
 
Errors or uncertainties related to Wire-time =
vs Host-time
 
** Good to me=
ntion here they NIC card and some of the offloading that occurs, the time s=
tamps occur “before the wire” and there can be TCP segment offl=
oad, etc..  Capturing on the wire benefits, which might be mentioned h=
ere…
 
ACM: mentioned =
this, both Nalini and Joachim have raised this point too.
<= pre> 
Section 3.8.4: Path
 
** Should traceroute be mentioned to obtain a sta=
tic snapshot?  Even if it is static per se, in most managed networks t=
he path will not change.
 
A=
CM: in this day and age, tracert packets and measurement packets can easily=
 follow different paths
 

RFC 2680bis:

 
Section 2.7:
In addition, the instruments should be =
checked to ensure the that the possibility a packet arrives at the network =
interface, but is lost due to congestion on the interface or to other resou=
rce exhaustion (e.g., buffers) on the instrument is low.
 
** Does it make sense to suggest that the in=
struments should be calibrated running a head-head RFC 2544 test?
 
ACM: I think this is an on-going ch=
eck for congestion, packets will certainly be lost if the buffers fill.
Although you proposed a lab calibration, which is fine, <=
a href=3D"http://tools.ietf.org/html/rfc6815">http://tools.ietf.org/html/rf=
c6815 is worth noting. 
 
Section 2.8.1: UDP or TCP protocol
 =

** This comments applies to both 2680bis and the 2680 draft test=
 plan.  TCP is mentioned as a possible means to conduct loss and delay=
 testing, but the RFC 2679/80 and test plan do not expand on guidelines whe=
n using TCP.  An example would be retransmissions, how do the loss sta=
tistics get measured when there are retransmits? 
 
ACM:  According to the metric definition=
s, each packet gets an unambiguous wire-time, T.
So, t=
he packet at time T is either lost or not.  If a TCP segment is retran=
smitted, it
gets a later wire-time, T, and is treated =
individually.
 
How do the d=
elay metrics get measured when there are retransmits, etc.?  I’m=
 not even sure that using TCP traffic for these measurements is feasible bu=
t understand that in some networks that have Layer 4 aware devices, that TC=
P may be the only way (this is related to my earlier comment regarding WAN =
accelerators, Firewalls, etc.)
 
= 
ACM: my guess is that answers for TCP appear in the BTC framework 
http://tools.ietf.org/html/rfc3148
<=
o:p> 
Section 4.1:
 
The reference to healthy Internet paths operating at below 1%=
 loss, is that dated (seems high)?
 
ACM: it's mostly to provide background for a comment about statist=
ics, which is still valid.
 
****

Again fully support these RFC= s to become standards and hope these comments are useful.

 

 

Thank you,

Ba= rry Constantine

= --_000_2845723087023D4CB5114223779FA9C80189AAD4F6njfpsrvexg8re_-- From nobody Sun Jul 6 08:46:39 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 68C0D1A03C1 for ; Sun, 6 Jul 2014 08:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zSzvJ8qisFsl for ; Sun, 6 Jul 2014 08:46:35 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5AD1A039F for ; Sun, 6 Jul 2014 08:46:34 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::2] (unknown [IPv6:2001:470:26:9c2::2]) by trammell.ch (Postfix) with ESMTPSA id DAB381A0623 for ; Sun, 6 Jul 2014 17:46:02 +0200 (CEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_603C11C7-F547-48BB-8D19-B96F59C5239F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sun, 6 Jul 2014 17:46:01 +0200 Message-Id: <9457D5C0-5B9D-4274-A1A2-AC24306C5469@trammell.ch> To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/7to1t8sa3I6gN9VZ13SfECx1T8g Subject: [ippm] DRAFT Agenda for IPPM Meeting in Toronto X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "ippm-chairs@tools.ietf.org Chairs" List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 15:46:37 -0000 --Apple-Mail=_603C11C7-F547-48BB-8D19-B96F59C5239F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, The IPPM draft agenda has been posted to=20 http://www.ietf.org/proceedings/90/agenda/agenda-90-ippm and is copied below: ## IPPM WG Meeting Agenda, IETF 90 Toronto ## Tuesday 22 July 2014 / 16:40 - 18:40 EDT (UTC-4) / Salon B | Start | Dur | Topic | Speaker(s) = | = |-------|-----|--------------------------------------------|--------------= ----| | 16:40 | 10m | Intro / Status / Agenda Bash | = Cerveny/Trammell | | 16:50 | 5m | LC draft-ietf-ippm-ipsec-03 | K. = Pentakousis | | 16:55 | 15m | WG draft-ietf-ippm-registry-00 | M. Bagnulo = | | 17:10 | 15m | WG draft-ietf-ippm-registry-active-00 | M. Bagnulo = | | 17:25 | 10m | WG draft-ietf-ippm-registry-passive-00 | A. Akhter = | | 17:35 | 15m | WG draft-ietf-ippm-model-based-metrics-02 | M. Mathis = | | 17:50 | 10m | CfA draft-morton-ippm-(2679,2680)-bis | A. Morton = | | 18:00 | 10m | CfA draft-hedin-ippm-type-p-monitor-03 | G. Mirsky = | | 18:10 | 15m | Ind draft-zheng-ippm-framework-passive-00 | V. Zheng = | | 18:20 | 10m | Ind draft-chen-ippm-coloring-based-ipfpm-* | L. Deng = | | 18:30 | 5m | CfA draft-mizrahi-ippm-checksum-trailer-00 | Chairs = | - *LC*: draft in Working Group Last Call - *WG*: current Working Group draft - *CfA*: draft for which a Call for Adoption was issued 24 June - *Ind*: individual draft without current Call for Adoption Authors: please review the agenda, and send any corrections (missing = agenda items, corrections to speakers, etc.) to = ippm-chairs@tools.ietf.org ASAP. Thanks, cheers, Brian --Apple-Mail=_603C11C7-F547-48BB-8D19-B96F59C5239F 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 iQEcBAEBCgAGBQJTuW85AAoJENt3nsOmbNJcteIH/ixJUia/2Cr110Bgi8rIu151 lkb4BZfviM63Jpu0+kHR6RhSujO8up+FwpmqBP7pBYmDTiFm4ZfgUPzKNV3dwqsd UJolU4ckGP8SH5cClwHXbYDLDADpXoKuf+rU5HC572BA8lJdPP8vPEJy7ktuzXqN XbzYCs9hOUxwNyM/oZEls2pSk+xkQCNAEAjVCOYpnD8sxM7VRLCBjOVV3IApfB5V nGQm0+SNYVp1bBGTjU1XyZCyxu+O25xtEl7noD/RlhrrKsW0F8AKsur6lmxafyC3 ikXcJO554dr0nX6L+aVSdbJGcgvHISIKS3bTVWAc/9uE7hkNlsywsnprV9WYG3I= =YK/y -----END PGP SIGNATURE----- --Apple-Mail=_603C11C7-F547-48BB-8D19-B96F59C5239F-- From nobody Sun Jul 6 18:38:57 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 935631A0097 for ; Sun, 6 Jul 2014 18:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 0dPolMdBnWkb for ; Sun, 6 Jul 2014 18:38:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4671A0089 for ; Sun, 6 Jul 2014 18:38:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR61753; Mon, 07 Jul 2014 01:38:51 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 02:38:50 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.121]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 09:38:48 +0800 From: Vero Zheng To: "ippm-chairs@tools.ietf.org Chairs" , "ippm@ietf.org" Thread-Topic: [ippm] DRAFT Agenda for IPPM Meeting in Toronto Thread-Index: AQHPmTGFghCVf/4iV0i5XgD+yG2ENpuT1K/A Date: Mon, 7 Jul 2014 01:38:48 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C871ADE@SZXEMA504-MBS.china.huawei.com> References: <9457D5C0-5B9D-4274-A1A2-AC24306C5469@trammell.ch> In-Reply-To: <9457D5C0-5B9D-4274-A1A2-AC24306C5469@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/bSHq0Mz2AgbyfI_v7voIQwEKbCE Cc: Nalini Elkins Subject: Re: [ippm] DRAFT Agenda for IPPM Meeting in Toronto 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: Mon, 07 Jul 2014 01:38:55 -0000 QnJpYW4sDQoNCkEgZmV3IGNvcnJlY3Rpb24gb2YgdGhlIGFnZW5kYSBhcyBiZWxvdzoNCjEuIGRy YWZ0LXpoZW5nLWlwcG0tZnJhbWV3b3JrLXBhc3NpdmUtMDANClRoZSBzcGVha2VyIHdpbGwgYmUg TmFsaW5pIEVsa2lucw0KDQoyLCBkcmFmdC1jaGVuLWlwcG0tY29sb3JpbmctYmFzZWQtaXBmcG0t ZnJhbWV3b3JrDQpUaGUgc3BlYWtlciB3aWxsIGJlIE1hY2ggQ2hlbg0KDQozLCBMaW5nbGkgRGVu ZyBhbHNvIHJlcXVlc3RlZCBhIDEwIG1pbnMgc2xvdCBmb3IgZHJhZnQtZGVuZy1pcHBtLXBhc3Np dmUtd2lyZWxlc3MtdXNlY2FzZQ0KQnV0IEkgZG9uoa90IHNlZSBpdCBvbiBhZ2VuZGEuDQoNCkNo ZWVycywgVmVybw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlwcG0g W21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBUcmFtbWVs bA0KPiBTZW50OiBTdW5kYXksIEp1bHkgMDYsIDIwMTQgMTE6NDYgUE0NCj4gVG86IGlwcG1AaWV0 Zi5vcmcNCj4gU3ViamVjdDogW2lwcG1dIERSQUZUIEFnZW5kYSBmb3IgSVBQTSBNZWV0aW5nIGlu IFRvcm9udG8NCj4gDQo+IEdyZWV0aW5ncywgYWxsLA0KPiANCj4gVGhlIElQUE0gZHJhZnQgYWdl bmRhIGhhcyBiZWVuIHBvc3RlZCB0bw0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85MC9hZ2VuZGEvYWdlbmRhLTkwLWlwcG0NCj4gDQo+IGFuZCBpcyBjb3BpZWQgYmVsb3c6 DQo+IA0KPiAjIyBJUFBNIFdHIE1lZXRpbmcgQWdlbmRhLCBJRVRGIDkwIFRvcm9udG8gIyMNCj4g DQo+IFR1ZXNkYXkgMjIgSnVseSAyMDE0IC8gMTY6NDAgLSAxODo0MCBFRFQgKFVUQy00KSAvIFNh bG9uIEINCj4gDQo+IHwgU3RhcnQgfCBEdXIgfCBUb3BpYyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCBTcGVha2VyKHMpDQo+IHwNCj4gfC0tLS0tLS18LS0tLS18LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18LS0tLS0tLS0tLS0tLS0tLS0t fA0KPiB8IDE2OjQwIHwgMTBtIHwgSW50cm8gLyBTdGF0dXMgLyBBZ2VuZGEgQmFzaCAgICAgICAg ICAgICAgIHwNCj4gQ2VydmVueS9UcmFtbWVsbCB8DQo+IHwgMTY6NTAgfCA1bSAgfCBMQyAgZHJh ZnQtaWV0Zi1pcHBtLWlwc2VjLTAzICAgICAgICAgICAgICAgfCBLLg0KPiBQZW50YWtvdXNpcyAg IHwNCj4gfCAxNjo1NSB8IDE1bSB8IFdHICBkcmFmdC1pZXRmLWlwcG0tcmVnaXN0cnktMDAgICAg ICAgICAgICB8IE0uIEJhZ251bG8NCj4gfA0KPiB8IDE3OjEwIHwgMTVtIHwgV0cgIGRyYWZ0LWll dGYtaXBwbS1yZWdpc3RyeS1hY3RpdmUtMDAgICAgIHwgTS4gQmFnbnVsbw0KPiB8DQo+IHwgMTc6 MjUgfCAxMG0gfCBXRyAgZHJhZnQtaWV0Zi1pcHBtLXJlZ2lzdHJ5LXBhc3NpdmUtMDAgICAgfCBB LiBBa2h0ZXINCj4gfA0KPiB8IDE3OjM1IHwgMTVtIHwgV0cgIGRyYWZ0LWlldGYtaXBwbS1tb2Rl bC1iYXNlZC1tZXRyaWNzLTAyIHwgTS4gTWF0aGlzDQo+IHwNCj4gfCAxNzo1MCB8IDEwbSB8IENm QSBkcmFmdC1tb3J0b24taXBwbS0oMjY3OSwyNjgwKS1iaXMgICAgICB8IEEuIE1vcnRvbg0KPiB8 DQo+IHwgMTg6MDAgfCAxMG0gfCBDZkEgZHJhZnQtaGVkaW4taXBwbS10eXBlLXAtbW9uaXRvci0w MyAgICAgfCBHLiBNaXJza3kNCj4gfA0KPiB8IDE4OjEwIHwgMTVtIHwgSW5kIGRyYWZ0LXpoZW5n LWlwcG0tZnJhbWV3b3JrLXBhc3NpdmUtMDAgIHwgVi4gWmhlbmcNCj4gfA0KPiB8IDE4OjIwIHwg MTBtIHwgSW5kIGRyYWZ0LWNoZW4taXBwbS1jb2xvcmluZy1iYXNlZC1pcGZwbS0qIHwgTC4gRGVu Zw0KPiB8DQo+IHwgMTg6MzAgfCA1bSAgfCBDZkEgZHJhZnQtbWl6cmFoaS1pcHBtLWNoZWNrc3Vt LXRyYWlsZXItMDAgfCBDaGFpcnMNCj4gfA0KPiANCj4gLSAqTEMqOiAgZHJhZnQgaW4gV29ya2lu ZyBHcm91cCBMYXN0IENhbGwNCj4gLSAqV0cqOiAgY3VycmVudCBXb3JraW5nIEdyb3VwIGRyYWZ0 DQo+IC0gKkNmQSo6IGRyYWZ0IGZvciB3aGljaCBhIENhbGwgZm9yIEFkb3B0aW9uIHdhcyBpc3N1 ZWQgMjQgSnVuZQ0KPiAtICpJbmQqOiBpbmRpdmlkdWFsIGRyYWZ0IHdpdGhvdXQgY3VycmVudCBD YWxsIGZvciBBZG9wdGlvbg0KPiANCj4gQXV0aG9yczogcGxlYXNlIHJldmlldyB0aGUgYWdlbmRh LCBhbmQgc2VuZCBhbnkgY29ycmVjdGlvbnMgKG1pc3NpbmcgYWdlbmRhDQo+IGl0ZW1zLCBjb3Jy ZWN0aW9ucyB0byBzcGVha2VycywgZXRjLikgdG8gaXBwbS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcg QVNBUC4NCj4gDQo+IFRoYW5rcywgY2hlZXJzLA0KPiANCj4gQnJpYW4NCg== From nobody Sun Jul 6 23:00: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 0193B1A0B02 for ; Sun, 6 Jul 2014 23:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z8L-VyGK75u7 for ; Sun, 6 Jul 2014 23:00:10 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 648191A0AFA for ; Sun, 6 Jul 2014 23:00:08 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::2] (unknown [IPv6:2001:470:26:9c2::2]) by trammell.ch (Postfix) with ESMTPSA id D10EE1A0290; Mon, 7 Jul 2014 08:00:06 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_888B9278-644D-43A4-B901-51DFA93B81E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C5C871ADE@SZXEMA504-MBS.china.huawei.com> Date: Mon, 7 Jul 2014 08:00:06 +0200 Message-Id: <15ECACF9-BB62-497F-9B64-266EC7412062@trammell.ch> References: <9457D5C0-5B9D-4274-A1A2-AC24306C5469@trammell.ch> <2EEA459CD95CCB4988BFAFC0F2287B5C5C871ADE@SZXEMA504-MBS.china.huawei.com> To: Vero Zheng X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/2qPrK792DSxG5RAD6ROU1w1iKCM Cc: Nalini Elkins , "ippm-chairs@tools.ietf.org Chairs" , "ippm@ietf.org" Subject: Re: [ippm] DRAFT Agenda for IPPM Meeting in Toronto 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: Mon, 07 Jul 2014 06:00:15 -0000 --Apple-Mail=_888B9278-644D-43A4-B901-51DFA93B81E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 hi Vero, Lingli, all, Thanks for the corrections, apologies for having missed = passive-wireless-usecase. I've added this as an individual after the = passive framework draft. Be advised that we are now five minutes over time. Presenters, if any of = you can take _less_ time than presently allocated in the agenda, please = let the chairs now. Thanks, best regards, Brian On 07 Jul 2014, at 03:38, Vero Zheng wrote: > Brian, >=20 > A few correction of the agenda as below: > 1. draft-zheng-ippm-framework-passive-00 > The speaker will be Nalini Elkins >=20 > 2, draft-chen-ippm-coloring-based-ipfpm-framework > The speaker will be Mach Chen >=20 > 3, Lingli Deng also requested a 10 mins slot for = draft-deng-ippm-passive-wireless-usecase > But I don=A1=AFt see it on agenda. >=20 > Cheers, Vero >=20 >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell >> Sent: Sunday, July 06, 2014 11:46 PM >> To: ippm@ietf.org >> Subject: [ippm] DRAFT Agenda for IPPM Meeting in Toronto >>=20 >> Greetings, all, >>=20 >> The IPPM draft agenda has been posted to >>=20 >> http://www.ietf.org/proceedings/90/agenda/agenda-90-ippm >>=20 >> and is copied below: >>=20 >> ## IPPM WG Meeting Agenda, IETF 90 Toronto ## >>=20 >> Tuesday 22 July 2014 / 16:40 - 18:40 EDT (UTC-4) / Salon B >>=20 >> | Start | Dur | Topic | = Speaker(s) >> | >> = |-------|-----|--------------------------------------------|--------------= ----| >> | 16:40 | 10m | Intro / Status / Agenda Bash | >> Cerveny/Trammell | >> | 16:50 | 5m | LC draft-ietf-ippm-ipsec-03 | K. >> Pentakousis | >> | 16:55 | 15m | WG draft-ietf-ippm-registry-00 | M. = Bagnulo >> | >> | 17:10 | 15m | WG draft-ietf-ippm-registry-active-00 | M. = Bagnulo >> | >> | 17:25 | 10m | WG draft-ietf-ippm-registry-passive-00 | A. = Akhter >> | >> | 17:35 | 15m | WG draft-ietf-ippm-model-based-metrics-02 | M. = Mathis >> | >> | 17:50 | 10m | CfA draft-morton-ippm-(2679,2680)-bis | A. = Morton >> | >> | 18:00 | 10m | CfA draft-hedin-ippm-type-p-monitor-03 | G. = Mirsky >> | >> | 18:10 | 15m | Ind draft-zheng-ippm-framework-passive-00 | V. Zheng >> | >> | 18:20 | 10m | Ind draft-chen-ippm-coloring-based-ipfpm-* | L. Deng >> | >> | 18:30 | 5m | CfA draft-mizrahi-ippm-checksum-trailer-00 | Chairs >> | >>=20 >> - *LC*: draft in Working Group Last Call >> - *WG*: current Working Group draft >> - *CfA*: draft for which a Call for Adoption was issued 24 June >> - *Ind*: individual draft without current Call for Adoption >>=20 >> Authors: please review the agenda, and send any corrections (missing = agenda >> items, corrections to speakers, etc.) to ippm-chairs@tools.ietf.org = ASAP. >>=20 >> Thanks, cheers, >>=20 >> Brian --Apple-Mail=_888B9278-644D-43A4-B901-51DFA93B81E8 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 iQEcBAEBCgAGBQJTujdmAAoJENt3nsOmbNJccDsIAM56noByv1RTl62EtiO8Wgwx hVhm915d0aR3VHry7PvBT7tSaMFtJM5tioaFOdkFWwbOyWfvTukYdmL0mFwOjR+8 mA34ZxKaZdra2/hsSzfngQ4Vb8CJY6c9ofdjSnFGBno0ejcD4bS/Jh4oGJ76ls6D SV+hQp2koarpI+BO8pBkJ8uocl3vL3bWPcgXHoimdtHeomq140J0Rg9Sy0whKiNE Qx+3O3lv/ixZM/M5Qm7uY7pDDBVr+89HsKFa22Afw3BfUiTLYPW5FmrXImwVFvX/ AzQ5NmyipDUctjeme3gn5IVr4tMZGHDGxA8gKb15yZTMw3UNX6JycwamGP9w980= =Gpy0 -----END PGP SIGNATURE----- --Apple-Mail=_888B9278-644D-43A4-B901-51DFA93B81E8-- From nobody Mon Jul 7 23:42:26 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 2355C1B2A69 for ; Mon, 7 Jul 2014 23:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 dImapOmLnN6t for ; Mon, 7 Jul 2014 23:42:21 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id BEA031B2A66 for ; Mon, 7 Jul 2014 23:42:20 -0700 (PDT) Received: from [128.131.67.239] (jason.nt.tuwien.ac.at [128.131.67.239]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id s686gIG4013239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 08:42:18 +0200 Message-ID: <53BB92C5.1080400@tuwien.ac.at> Date: Tue, 08 Jul 2014 08:42:13 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Trammell , ippm@ietf.org References: <20140529194155.17884.67924.idtracker@ietfa.amsl.com> <47EC9EAE-25A9-4E0F-B5F9-10593A4DDD0C@trammell.ch> <017EE38A-2B06-429F-AAC9-27F45932AD5C@trammell.ch> In-Reply-To: <017EE38A-2B06-429F-AAC9-27F45932AD5C@trammell.ch> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/efJoe2PTc5DGk8F3r2m9ZX-CKNc Subject: Re: [ippm] Calls for adoption as WG items 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, 08 Jul 2014 06:42:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian, IPPM, Having finally read (1) and (2) I support adoption of these drafts/milestones. I will submit a summary of my review to the list for discussion within the next week(s) and I plan to contribute to the review process of these two documents in the future. best regards Joachim On 02.07.2014 11:30, Brian Trammell wrote: > Greetings, IPPM, > > A gentle reminder: We would like very much to have discussion on > adoption completed before the Toronto meeting, so we can spend face > to face time on the documents themselves. And we cannot adopt > drafts as Working Group items for which there is not a strong > demonstration of support and commitment to read, review, and > improve the drafts. > > So, please see last week's call for adoption notice, consider > whether you support adoption of the named drafts, and whether you > can commit to review them. > > The deadline for this call for adoption is, as before, end of day > Thursday 10 July 2014. > > Many thanks and best regards, > > Brian Trammell, as co-chair. > > On 24 Jun 2014, at 16:17, Brian Trammell wrote: > >> Greetings, IPPM, >> >> This is a call for adoption for four new milestones under the >> current IPPM charter. >> >> (1) Submit a draft updating RFC2679 based on testing and >> implementation experience (RFC 6808) to the IESG as Proposed >> Standard (under consideration for this milestone is >> draft-morton-ippm-2679-bis-04) >> >> (2) Submit a draft updating RFC2680 based on testing and >> implementation experience (draft-ietf-ippm-testplan-rfc2680-05) >> to the IESG as Proposed Standard (under consideration for this >> milestone is draft-morton-ippm-2679-bis-04) >> >> (3) Submit a draft adding DSCP and ECN monitoring to TWAMP to the >> IESG as Proposed Standard (under consideration for this >> milestone is draft-hedin-ippm-type-p-monitor-03) >> >> (4) Submit a draft adding a UDP Checksum Trailer to OWAMP and >> TWAMP to the IESG as Informational (under consideration for this >> milestone is draft-mizrahi-ippm-checksum-trailer-00) >> >> For each draft, please indicate the following to the list at >> ippm@ietf.org >> >> (a) whether you support the addition of the milestone and the >> adoption of the draft as a WG item to fulfill that milestone (b) >> whether you have read the draft (c) whether you pledge to review >> the draft during the WG process. >> >> This call for adoption will last until Thursday 10 July 2014. >> >> Many thanks, best regards, >> >> Brian >> >> On 02 Jun 2014, at 18:07, Brian Trammell >> wrote: >> >>> Greetings, IPPM, >>> >>> Thanks and congratulations to the authors on the approval of >>> our first draft from the "new" (March 2013) charter! >>> >>> As we're moving forward in our charter, it's time to consider >>> adopting new drafts. >>> >>> I've seen implicit requests for a call for adoption for the >>> following two drafts, which were not adopted in Orlando because >>> we wanted to see if 2330-update would change their scope >>> significantly: >>> >>> draft-morton-ippm-2679-bis-04 draft-morton-ippm-2680-bis-02 >>> >>> We have at least one explicit request for a call for adoption: >>> >>> draft-hedin-ippm-type-p-monitor-03 >>> >>> If there are other documents which you would like to have >>> considered for adoption as IPPM WG items in the next round >>> under the present charter, please notify the chairs at >>> ippm-chairs@tools.ietf.org by Friday, June 6th; we'll run the >>> call for adoption after that. >>> >>> Thanks, cheers, >>> >>> Brian (as chair) >>> >>> >>> Begin forwarded message: >>> >>>> From: The IESG Subject: Document >>>> Action: 'Advanced Stream and Sampling Framework for IPPM' to >>>> Informational RFC (draft-ietf-ippm-2330-update-05.txt) Date: >>>> 29 May 2014 21:41:55 GMT+2 Resent-To: bill@wjcerveny.com, >>>> ietf@trammell.ch, To: IETF-Announce >>>> Cc: RFC Editor , ippm mailing list >>>> , ippm chair >>>> >>>> The IESG has approved the following document: - 'Advanced >>>> Stream and Sampling Framework for IPPM' >>>> (draft-ietf-ippm-2330-update-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-2330-update/ >>>> >>>> >>>> >>>> >>>> >>>> Technical Summary >>>> >>>> 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. >>>> >>>> Working Group Summary >>>> >>>> This draft was first introduced to the working group in >>>> October 2012. Support for the draft was indicated at meetings >>>> with no dissent. >>>> >>>> Document Quality >>>> >>>> As an update to the IPPM Framework, this document adds new >>>> and updated considerations for stream parameters. >>>> >>>> The document shepherd reviewed the document as a “-02” draft >>>> and reviewed the changes which constitute “-03” and “-04”. >>>> >>>> As documented, other topics in the IPPM Framework which might >>>> be updated or augmented are deferred to future work. This >>>> includes the topics of passive and various forms of of hybrid >>>> active/passive measurements. >>>> >>>> Personnel >>>> >>>> The document shepherd was Bill Cerveny. The responsible area >>>> director is Spencer Dawkins. >>> >>> _______________________________________________ ippm mailing >>> list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm >> >> _______________________________________________ ippm mailing >> list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm > > > > _______________________________________________ ippm mailing list > ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTu5LFAAoJEKCP3BPvRqfSawMH/2S+os0oHNt6MrCWIY9Tbpas 9nu/chFiah4vKNVbak4n8ac3TmZZtGw0QIyL0dev1ZssUwUjArlZrzET7IoqnLr1 lbVFoPA0tyuR+AH0XaBCDB/CepbYwOq/L7IpUKAY0hVVZtuaXQcZL5/JI1LsxK0o 2RrQOiClLGl/ihaPyuLibEl8C3GrJIV29IN/bp3S2jk4YyymI8nebJJSn7vS4xAf IlB31d2F201PfiM25RKKyZEIZNbUtpQ1nbrImZCdhz5zRSCENad8z57Vki3vZ14P jvSWgz0HIKA3jRyhn/mv7fFjRL9H6FuK6y2gKACCKzYo5QvX4odSgqF6pkVzuw4= =xw7U -----END PGP SIGNATURE----- From nobody Mon Jul 14 10:18: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 C1E951A0AE3 for ; Mon, 14 Jul 2014 10:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 X47DUNz2fjrc for ; Mon, 14 Jul 2014 10:18:31 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id E8D871A0AE9 for ; Mon, 14 Jul 2014 10:18:30 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id D3FEF1FF5F; Mon, 14 Jul 2014 19:18:29 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 0020D1FF52; Mon, 14 Jul 2014 19:18:28 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 925FD37825F; Mon, 14 Jul 2014 19:18:28 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 14 Jul 2014 19:18:28 +0200 From: Kostas Pentikousis To: Steve Baillargeon , Brian Trammell , "ippm@ietf.org" Date: Mon, 14 Jul 2014 19:18:26 +0200 Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuA= Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE 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/blt9CLulJFuLltBwTw90IfTcOPA Cc: "draft-ietf-ippm-ipsec@tools.ietf.org" Subject: Re: [ippm] WGLC on draft-ietf-ippm-ipsec-03 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: Mon, 14 Jul 2014 17:18:34 -0000 Hi Steve, all, | I support with the following comments: Many thanks for the support, much appreciated.=20 | - The tile of the draft is misleading. It should say something like | O/TWAMP Shared Secret Key Feature I think we discussed the title some time ago. Personally I would take a bit= of an issue with changing the title so late in the process, but I have to = agree that as the draft evolved since Orlando, the title didn't do so accor= dingly. We're open to suggestions, although I am not excited about the word= "Feature" in an IETF RFC title :) Would something like "IKEv2-based Shared= Secret Key for O/TWAMP", for example, be ok with you? | - The use case in section 1 is not clear. It should indicate this mode | is intended for protecting and exchanging OWAMP/TWAMP test protocol | between two IKEv2 systems when OWAMP/TWAMP control/test traffic is not | protected by IPSec The document does focus on how to derive O/TWAMP Shared Secret Key from IKE= v2 SA. As per earlier discussions in Berlin and Vancouver, I think we alrea= dy agreed that this is orthogonal to whether the O/TWAMP control/test traff= ic is transferred inside the IPsec tunnel or not. The admin or operator pol= icy could play a role, for example. Of course, one should avoid a so-to-spe= ak "double security protection". | - I personally think the most common case is to protect OWAMP/TWAMP | control/test traffic with IPsec. It is important to highlight the | benefits associated with this new mode versus the common | unauthenticated O/TWAMP mode protected via AH or ESP. I think we mostly agree on this. Would you be so kind to propose some text = to add? I guess a few of sentences would suffice at this stage =20 | - in section 4.1 first sentence, the requirement level is ambiguous. I | think it should say...the shared secret MUST be derived ...(as opposed | to can). Same comment for the second paragraph, the word if should be | replaced by when. Sounds good; we will update the draft before the meeting. Thanks for this p= oint. | - end of section 4.1, the expected behavior when the IKEv2 SA is | rekeyed is not clear. Same is true when the IKEv2 SA is deleted for | whatever reasons. What should the O/TWAMP part of the IKE system do | when the IKE SA is rekeyed or deleted? Should it close its test | sessions and setup new test sessions using the key associated with the | newly established IKEv2 SA? Waiting for the lifetime to expire does not | make sense. And if you do, what happens next? I'm not sure about this, although we would be happy to integrate proposed t= ext from your end. The shared secret key generated from the SA could contin= ue to be used until the lifetime expiration. Do you see a need to rekey the= shared secret key immediately after the IKEv2 SA is rekeyed? | - section 4.2. Three (3) new TWAMP modes are not needed. One TWAMP mode | called Shared Secret Key should be sufficient. This mode can then be | used on conjunction with the authenticated, encrypted and mixed modes. | Please do not use the X mode over IKEv2. The text "over" is always | misleading. I need to go back to my notes wrt the discussion we had earlier. If I recal= l correctly, extending the Modes values is advantageous if one considers ba= ckwards compatibility with existing O/TWAMP clients. The Set-Up-Response Me= ssage contains a mode value which indicates unauthenticated, authenticated = or encrypted. In this case, the O/TWAMP server cannot obtain the informatio= n whether to derive shared secret key from an IKEv2 SA or not, if the modes= value is not extended. The Set-Up-Response Message must signal this in con= junction with the mode. Since there is no unused field in the Set-Up-Respo= nse Message, isn't it better to extend Modes? Best regards, Kostas and Emma From nobody Thu Jul 17 08:13:40 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 C246A1A0199 for ; Thu, 17 Jul 2014 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 y2vqEVL7F9aH for ; Thu, 17 Jul 2014 08:13:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F361B27B2 for ; Thu, 17 Jul 2014 08:13:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 09C4721AC9 for ; Thu, 17 Jul 2014 11:13:28 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Thu, 17 Jul 2014 11:13:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=xHdX8fnM7ko3PRTayqNy0o4a/Jg=; b=ZS8m+Q+iOuKGILCD+0Nl3jwO9vun KniC5K1kxG2Jb6rVbbAJaeNafCS5QspZ/CZbBa4gKXHN5oyDikogkE8/8zQsif1o /uloya4v5EBXeUVi6Yhda925RcZvbfcwHfDhG7pd+cxyur7FJZoyb5INvlOWQYa8 7sFCVqc05NFsbaI= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id E16C6F0034A; Thu, 17 Jul 2014 11:13:27 -0400 (EDT) Message-Id: <1405610007.551.142696221.69DA5142@webmail.messagingengine.com> X-Sasl-Enc: 92PcdaiBQG5WpMPGi6nFUxW7DYCeRU0DIThh7XTSd5Fa 1405610007 From: William Cerveny To: ippm@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-741a34df Date: Thu, 17 Jul 2014 11:13:27 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/D0LwUBoW5D2edlmHyQKg5Rngl-U Subject: [ippm] IPPM @ IETF90 Administrative Notes 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, 17 Jul 2014 15:13:39 -0000 Dear IPPM Participants, I'd greatly appreciate if presenters for the upcoming IPPM meeting in Toronto can send their presentations to me ( bill@wjcerveny.com or ippm@wjcerveny.com) as early as possible, so that I can post them to the meeting materials. We need note takers and jabber scribes. Please let us know if you can be a note taker or jabber scribe. By the way, links for meeting jabber, audio, presentations, etc, can be found at: https://tools.ietf.org/agenda/90/ Participants are encouraged to post their comments on any IPPM WG related draft to the IPPM mailing list. Having "talking-points" from the list will improve the quality of discussion at the meeting. To recap, the IPPM meeting at the Toronto IETF will be Tuesday, July 23, 2014 at 1640 (4:40pm) local time in Toronto (EDT). We are meeting in Salon B. The meeting will be on meetecho: See http://ietf90.conf.meetecho.com/ Regards, Bill Cerveny Brian Trammell IPPM WG Co-chairs From nobody Mon Jul 21 10:30:23 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 BCEFC1A033C for ; Mon, 21 Jul 2014 10:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 l-rgCp61nYQI for ; Mon, 21 Jul 2014 10:30:21 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FD11A0336 for ; Mon, 21 Jul 2014 10:30:20 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-ab-53ccf8e0891d Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A0.EC.25146.0E8FCC35; Mon, 21 Jul 2014 13:26:24 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Mon, 21 Jul 2014 13:30:19 -0400 From: Steve Baillargeon To: Kostas Pentikousis Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4A== Date: Mon, 21 Jul 2014 17:30:18 +0000 Message-ID: References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPoO6DH2eCDXb/l7BYeHc+k8XGlnds Fj0P3jFb7Dmwn9WBxePL/yYmjyVLfjJ5fLn8mc3jyf6ZLAEsUVw2Kak5mWWpRfp2CVwZV5+w FXRrVax5/JSxgfGVYhcjJ4eEgInEpPUbGSFsMYkL99azdTFycQgJHGWUWLhoOzOEs5xR4uq3 10wgVWwCFhLr5y5jBrFFBPQk9qw9xwpSxCwwk1Hi3p4WdpCEMNDYj3Pvs0AUmUrsPTCZHcJ2 kli/8yBYnEVAVaLz8zNWEJtXwFfi/JeVUKvbmCQOv2sEK+IU8JHY9PEqWBGjgKzE7rPXwa5g FhCXuPVkPhPE3QISS/acZ4awRSVePv7HCmErSXz8PZ8dol5HYsHuT2wQtrbEsoWvmSEWC0qc nPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAiPqmASb4w7GBZ8sDzEKcDAq 8fAueHImWIg1say4MvcQozQHi5I4r2b1vGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjJy9 C1ftefL2e7LXxdim5tcH7p4Kfat/zm7dOe/GFYKn370KjG58+XjrlI+qwVkZfEclbFl6nwQY 7/+1UK/uqcvJQ0+3RxT/Xxl2NTPm0owPiy6e19UVuiR/Ru210iRZvus+xsJVT+ZIX6tasGtv cem+e9fcP6V5f1juMbVP6NL1yG/TExsXbOFRYinOSDTUYi4qTgQAGM3GnokCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/RNCJIdLD-is3bz6C4LuEEHazTF8 Cc: "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] WGLC on draft-ietf-ippm-ipsec-03 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: Mon, 21 Jul 2014 17:30:22 -0000 Hi Kostas I am happy if the tittle changes to "IKEv2-based Shared Secret Key for O/TW= AMP". I suggest the following text: In many cases, protecting unauthenticated O/TWAMP traffic using IPsec secur= ity services is sufficient and provides the easiest solution to secure sens= itive traffic including O/TWAMP control and/or test traffic and hide the O/= TWAMP endpoint services from the external network with IPsec tunnel mode fo= r instance. This new mode is intended for the following cases: 1) when O/TWAMP traffic is bypassing IPsec protection and is running over a= n external network exactly between two IKEv2 systems (maybe we should elabo= rate on why this might be needed) 2) when double protection is needed (should we drop this case and recommend= to avoid it?) IMO this mode should use the same "rekeying behavior" as defined in IKEv2 i= .e. if a new IKE SA is established to carry the IKE traffic before the keys= expires and the old SA is then deleted, then I suggest a new TWAMP test se= ssion is established and the old test session is closed before the keys exp= ires.=20 I still think one mode is sufficient. Regards Steve B -----Original Message----- From: Kostas Pentikousis [mailto:k.pentikousis@eict.de]=20 Sent: July-14-14 1:18 PM To: Steve Baillargeon; Brian Trammell; ippm@ietf.org Cc: draft-ietf-ippm-ipsec@tools.ietf.org Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Hi Steve, all, | I support with the following comments: Many thanks for the support, much appreciated.=20 | - The tile of the draft is misleading. It should say something like=20 | O/TWAMP Shared Secret Key Feature I think we discussed the title some time ago. Personally I would take a bit= of an issue with changing the title so late in the process, but I have to = agree that as the draft evolved since Orlando, the title didn't do so accor= dingly. We're open to suggestions, although I am not excited about the word= "Feature" in an IETF RFC title :) Would something like "IKEv2-based Shared= Secret Key for O/TWAMP", for example, be ok with you? | - The use case in section 1 is not clear. It should indicate this mode=20 | is intended for protecting and exchanging OWAMP/TWAMP test protocol=20 | between two IKEv2 systems when OWAMP/TWAMP control/test traffic is not=20 | protected by IPSec The document does focus on how to derive O/TWAMP Shared Secret Key from IKE= v2 SA. As per earlier discussions in Berlin and Vancouver, I think we alrea= dy agreed that this is orthogonal to whether the O/TWAMP control/test traff= ic is transferred inside the IPsec tunnel or not. The admin or operator pol= icy could play a role, for example. Of course, one should avoid a so-to-spe= ak "double security protection". | - I personally think the most common case is to protect OWAMP/TWAMP=20 | control/test traffic with IPsec. It is important to highlight the=20 | benefits associated with this new mode versus the common=20 | unauthenticated O/TWAMP mode protected via AH or ESP. I think we mostly agree on this. Would you be so kind to propose some text = to add? I guess a few of sentences would suffice at this stage =20 | - in section 4.1 first sentence, the requirement level is ambiguous. I=20 | think it should say...the shared secret MUST be derived ...(as opposed=20 | to can). Same comment for the second paragraph, the word if should be=20 | replaced by when. Sounds good; we will update the draft before the meeting. Thanks for this p= oint. | - end of section 4.1, the expected behavior when the IKEv2 SA is=20 | rekeyed is not clear. Same is true when the IKEv2 SA is deleted for=20 | whatever reasons. What should the O/TWAMP part of the IKE system do=20 | when the IKE SA is rekeyed or deleted? Should it close its test=20 | sessions and setup new test sessions using the key associated with the=20 | newly established IKEv2 SA? Waiting for the lifetime to expire does=20 | not make sense. And if you do, what happens next? I'm not sure about this, although we would be happy to integrate proposed t= ext from your end. The shared secret key generated from the SA could contin= ue to be used until the lifetime expiration. Do you see a need to rekey the= shared secret key immediately after the IKEv2 SA is rekeyed? | - section 4.2. Three (3) new TWAMP modes are not needed. One TWAMP=20 | mode called Shared Secret Key should be sufficient. This mode can then=20 | be used on conjunction with the authenticated, encrypted and mixed modes. | Please do not use the X mode over IKEv2. The text "over" is always=20 | misleading. I need to go back to my notes wrt the discussion we had earlier. If I recal= l correctly, extending the Modes values is advantageous if one considers ba= ckwards compatibility with existing O/TWAMP clients. The Set-Up-Response Me= ssage contains a mode value which indicates unauthenticated, authenticated = or encrypted. In this case, the O/TWAMP server cannot obtain the informatio= n whether to derive shared secret key from an IKEv2 SA or not, if the modes= value is not extended. The Set-Up-Response Message must signal this in con= junction with the mode. Since there is no unused field in the Set-Up-Respo= nse Message, isn't it better to extend Modes? Best regards, Kostas and Emma From nobody Tue Jul 22 07:15:07 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 E25A81B28B1; Tue, 22 Jul 2014 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 kbIgHyihXA6o; Tue, 22 Jul 2014 07:14:58 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 23DB11B28B0; Tue, 22 Jul 2014 07:14:58 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id EF9821FF54; Tue, 22 Jul 2014 16:14:56 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id E9DE11FF46; Tue, 22 Jul 2014 16:14:55 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 9CF74378277; Tue, 22 Jul 2014 16:14:55 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Tue, 22 Jul 2014 16:14:55 +0200 From: Kostas Pentikousis To: Steve Baillargeon Date: Tue, 22 Jul 2014 16:14:53 +0200 Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAw Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE 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/Tyit8v8rAbkfxczgvt5XjBCObz0 Cc: "ipsec@ietf.org" , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] WGLC on draft-ietf-ippm-ipsec-03 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 Jul 2014 14:15:03 -0000 Hi Steve, Many thanks once again for the feedback and text suggestion! (adding ipsec folks in CC) | I am happy if the tittle changes to "IKEv2-based Shared Secret Key for | O/TWAMP". Already changed in my local copy, and I will update the slides for this aft= ernoon accordingly. | I suggest the following text: | In many cases, protecting unauthenticated O/TWAMP traffic using IPsec | security services is sufficient and provides the easiest solution to | secure sensitive traffic including O/TWAMP control and/or test traffic | and hide the O/TWAMP endpoint services from the external network with | IPsec tunnel mode for instance. This new mode is intended for the | following cases: | 1) when O/TWAMP traffic is bypassing IPsec protection and is running | over an external network exactly between two IKEv2 systems (maybe we | should elaborate on why this might be needed) | 2) when double protection is needed (should we drop this case and | recommend to avoid it?) How about the following, instead: We note that protecting unauthenticated O/TWAMP traffic using IPsec securit= y services is sufficient in many cases. That said, protecting unauthenticat= ed O/TWAMP control and/or test traffic via AH or ESP cannot provide various= security modes and cannot authenticate part of a O/TWAMP packet as mention= ed in . In real-world deployments this may hinder= timestamp accuracy. This document describes how to derive the shared secre= t key from the IKEv2 SA and employ the security service at the O/TWAMP laye= r. This method SHOULD be used when O/TWAMP traffic is bypassing IPsec prote= ction and is running over an external network exactly between two IKEv2 sys= tems. If this is ok, I can update the draft on the datatracker before lunch, and = then we discuss the two points below during the meeting in the afternoon. | IMO this mode should use the same "rekeying behavior" as defined in | IKEv2 i.e. if a new IKE SA is established to carry the IKE traffic | before the keys expires and the old SA is then deleted, then I suggest | a new TWAMP test session is established and the old test session is | closed before the keys expires. We had a short chat with Emma and it seems that although the (O/TWAMP) shar= ed secret key is derived from IKEv2 SA it is in fact a _separate key at the= O/TWAMP layer_. That would mean that it's not necessary to update the shar= ed secret key before it expires, even though a new IKEv2 SA is established.= Doing so will disrupt the ongoing test session. So we do not see much bene= fit from a measurements pov. | I still think one mode is sufficient. I guess we still think that backwards compatibility is a good thing :) Best regards, Kostas |=20 | Regards | Steve B |=20 | -----Original Message----- | From: Kostas Pentikousis [mailto:k.pentikousis@eict.de] | Sent: July-14-14 1:18 PM | To: Steve Baillargeon; Brian Trammell; ippm@ietf.org | Cc: draft-ietf-ippm-ipsec@tools.ietf.org | Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 |=20 | Hi Steve, all, |=20 | | I support with the following comments: |=20 | Many thanks for the support, much appreciated. |=20 |=20 | | - The tile of the draft is misleading. It should say something like | | O/TWAMP Shared Secret Key Feature |=20 | I think we discussed the title some time ago. Personally I would take a | bit of an issue with changing the title so late in the process, but I | have to agree that as the draft evolved since Orlando, the title didn't | do so accordingly. We're open to suggestions, although I am not excited | about the word "Feature" in an IETF RFC title :) Would something like | "IKEv2-based Shared Secret Key for O/TWAMP", for example, be ok with | you? |=20 |=20 | | - The use case in section 1 is not clear. It should indicate this | mode | | is intended for protecting and exchanging OWAMP/TWAMP test protocol | | between two IKEv2 systems when OWAMP/TWAMP control/test traffic is | not | | protected by IPSec |=20 | The document does focus on how to derive O/TWAMP Shared Secret Key from | IKEv2 SA. As per earlier discussions in Berlin and Vancouver, I think | we already agreed that this is orthogonal to whether the O/TWAMP | control/test traffic is transferred inside the IPsec tunnel or not. The | admin or operator policy could play a role, for example. Of course, one | should avoid a so-to-speak "double security protection". |=20 |=20 | | - I personally think the most common case is to protect OWAMP/TWAMP | | control/test traffic with IPsec. It is important to highlight the | | benefits associated with this new mode versus the common | | unauthenticated O/TWAMP mode protected via AH or ESP. |=20 | I think we mostly agree on this. Would you be so kind to propose some | text to add? I guess a few of sentences would suffice at this stage |=20 |=20 | | - in section 4.1 first sentence, the requirement level is ambiguous. | I | | think it should say...the shared secret MUST be derived ...(as | opposed | | to can). Same comment for the second paragraph, the word if should be | | replaced by when. |=20 | Sounds good; we will update the draft before the meeting. Thanks for | this point. |=20 |=20 | | - end of section 4.1, the expected behavior when the IKEv2 SA is | | rekeyed is not clear. Same is true when the IKEv2 SA is deleted for | | whatever reasons. What should the O/TWAMP part of the IKE system do | | when the IKE SA is rekeyed or deleted? Should it close its test | | sessions and setup new test sessions using the key associated with | the | | newly established IKEv2 SA? Waiting for the lifetime to expire does | | not make sense. And if you do, what happens next? |=20 |=20 | I'm not sure about this, although we would be happy to integrate | proposed text from your end. The shared secret key generated from the | SA could continue to be used until the lifetime expiration. Do you see | a need to rekey the shared secret key immediately after the IKEv2 SA is | rekeyed? |=20 | | - section 4.2. Three (3) new TWAMP modes are not needed. One TWAMP | | mode called Shared Secret Key should be sufficient. This mode can | then | | be used on conjunction with the authenticated, encrypted and mixed | modes. | | Please do not use the X mode over IKEv2. The text "over" is always | | misleading. |=20 |=20 | I need to go back to my notes wrt the discussion we had earlier. If I | recall correctly, extending the Modes values is advantageous if one | considers backwards compatibility with existing O/TWAMP clients. The | Set-Up-Response Message contains a mode value which indicates | unauthenticated, authenticated or encrypted. In this case, the O/TWAMP | server cannot obtain the information whether to derive shared secret | key from an IKEv2 SA or not, if the modes value is not extended. The | Set-Up-Response Message must signal this in conjunction with the mode. | Since there is no unused field in the Set-Up-Response Message, isn't | it better to extend Modes? |=20 |=20 | Best regards, |=20 | Kostas and Emma From nobody Tue Jul 22 07:42:17 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 376D01A0060; Tue, 22 Jul 2014 07:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FYaiXLdSwouU; Tue, 22 Jul 2014 07:42:14 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637F41AC0D2; Tue, 22 Jul 2014 07:42:12 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-cc-53ce255682cc Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.11.05330.6552EC35; Tue, 22 Jul 2014 10:48:22 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 10:42:08 -0400 From: Steve Baillargeon To: Kostas Pentikousis Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAwgAAOCRA= Date: Tue, 22 Jul 2014 14:42:08 +0000 Message-ID: References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt26Y6rlggxdz1C0W3p3PZLGx5R2b Rc+Dd8wW+7e8YLPYc2A/qwOrx5f/TUweS5b8ZPL4cvkzm8eT/TNZAliiuGxSUnMyy1KL9O0S uDKO/6kp2OtZ0fL+FEsD4z+rLkZODgkBE4mNbzazQ9hiEhfurWfrYuTiEBI4yihx4OxZKGc5 o8S3N9OYQarYBCwk1s9dBmaLCOhJ7Fl7jhWkiFlgD6PE1519YKOEgcZ+nHufBaLIVGLvgcns ELafxNtX78CaWQRUJVbd+AsW5xXwlXh4tocdYlsPs8SHjZvBmjkFfCT2PH7KCGIzCshK7D57 nQnEZhYQl7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwphK0lMWnqOFaJeR2LB7k9sELa2xLKFr5kh FgtKnJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2MQJj65gEm+4Oxj0vLQ8x CnAwKvHwLnhyJliINbGsuDL3EKM0B4uSOO+s2nnBQgLpiSWp2ampBalF8UWlOanFhxiZODil GhgnbK+Se8y+ycJDdLrHLfl9jiZnXyp4rTGw+NV1xvSTX0ZkquLHWCbOJzyG+r32amop3tdW 3X8tsq4j/3NA7PO67TcPKM+9v1v+157dRauUS+35bqyaM3/Fsa9bdYSMFCzzdsY2t/vVW9kk TuP8/ir8RX6/YrTS3YvcC9asW7RUJUxeKGLLyV4lluKMREMt5qLiRADDTLl+jgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/E4zCIlG10XbcKE_Ug4mSmwum7EQ Cc: "ipsec@ietf.org" , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] WGLC on draft-ietf-ippm-ipsec-03 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 Jul 2014 14:42:16 -0000 Hi Kostas Some quick comments. The changes looks good but I think we need a couple of simple network diagr= ams to clarify the case when this mode is not needed and the case when it n= eeded. Here are two examples. 1) Case when new mode is not used/needed: Inner TWAMP Controller -- Internal Network ---IKE System 1 ---External Netw= ork ---IKE System 2 ---Internal Network ---Inner TWAMP Responder In this case #1, IPsec is protecting the TWAMP traffic (running in TWAMP un= authenticated mode for instance) and any other inner traffic over the exter= nal network but the TWAMP traffic is transmitted in cleartext and is not (f= ully) authenticated by the TWAMP endpoints=20 Note 1: the controller and responder can also perform basic "ACL-like check= ing" based on the IP addresses and port numbers in TWAMP unauthenticated mo= de. Not sure what you mean by "In real-world deployments this may hinder timest= amp accuracy". I don't see any problem with this case if the internal netwo= rks are considered "trustable" and both TWAMP endpoints are managed by the = same "entity". Note 2: The Inner TWAMP responder and/or controller can be standalone or em= bedded within the IKE system. 2) Case when new mode is used/needed: IKE System 1 acting an Outer TWAMP Controller---External Network ---IKE Sys= tem 2 acting as Outer TWAMP Responder In this case #1, IPsec is not protecting the TWAMP traffic. The TWAMP traff= ic is directly running over the external network in authenticated mode (etc= ...) in conjunction with the new mode. Note 3: The outer TWAMP responder and/or controller are embedded within eac= h IKE system. Is this what you have in mind for the use case? Is there more to it? Regards Steve B -----Original Message----- From: Kostas Pentikousis [mailto:k.pentikousis@eict.de]=20 Sent: July-22-14 10:15 AM To: Steve Baillargeon Cc: draft-ietf-ippm-ipsec@tools.ietf.org; Brian Trammell; ippm@ietf.org; ip= sec@ietf.org Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Hi Steve, Many thanks once again for the feedback and text suggestion! (adding ipsec folks in CC) | I am happy if the tittle changes to "IKEv2-based Shared Secret Key for=20 | O/TWAMP". Already changed in my local copy, and I will update the slides for this aft= ernoon accordingly. | I suggest the following text: | In many cases, protecting unauthenticated O/TWAMP traffic using IPsec=20 | security services is sufficient and provides the easiest solution to=20 | secure sensitive traffic including O/TWAMP control and/or test traffic=20 | and hide the O/TWAMP endpoint services from the external network with=20 | IPsec tunnel mode for instance. This new mode is intended for the=20 | following cases: | 1) when O/TWAMP traffic is bypassing IPsec protection and is running=20 | over an external network exactly between two IKEv2 systems (maybe we=20 | should elaborate on why this might be needed) | 2) when double protection is needed (should we drop this case and=20 | recommend to avoid it?) How about the following, instead: We note that protecting unauthenticated O/TWAMP traffic using IPsec securit= y services is sufficient in many cases. That said, protecting unauthenticat= ed O/TWAMP control and/or test traffic via AH or ESP cannot provide various= security modes and cannot authenticate part of a O/TWAMP packet as mention= ed in . In real-world deployments this may hinder= timestamp accuracy. This document describes how to derive the shared secre= t key from the IKEv2 SA and employ the security service at the O/TWAMP laye= r. This method SHOULD be used when O/TWAMP traffic is bypassing IPsec prote= ction and is running over an external network exactly between two IKEv2 sys= tems. If this is ok, I can update the draft on the datatracker before lunch, and = then we discuss the two points below during the meeting in the afternoon. | IMO this mode should use the same "rekeying behavior" as defined in | IKEv2 i.e. if a new IKE SA is established to carry the IKE traffic=20 | before the keys expires and the old SA is then deleted, then I suggest=20 | a new TWAMP test session is established and the old test session is=20 | closed before the keys expires. We had a short chat with Emma and it seems that although the (O/TWAMP) shar= ed secret key is derived from IKEv2 SA it is in fact a _separate key at the= O/TWAMP layer_. That would mean that it's not necessary to update the shar= ed secret key before it expires, even though a new IKEv2 SA is established.= Doing so will disrupt the ongoing test session. So we do not see much bene= fit from a measurements pov. | I still think one mode is sufficient. I guess we still think that backwards compatibility is a good thing :) Best regards, Kostas |=20 | Regards | Steve B |=20 | -----Original Message----- | From: Kostas Pentikousis [mailto:k.pentikousis@eict.de] | Sent: July-14-14 1:18 PM | To: Steve Baillargeon; Brian Trammell; ippm@ietf.org | Cc: draft-ietf-ippm-ipsec@tools.ietf.org | Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 |=20 | Hi Steve, all, |=20 | | I support with the following comments: |=20 | Many thanks for the support, much appreciated. |=20 |=20 | | - The tile of the draft is misleading. It should say something like=20 | | O/TWAMP Shared Secret Key Feature |=20 | I think we discussed the title some time ago. Personally I would take=20 | a bit of an issue with changing the title so late in the process, but=20 | I have to agree that as the draft evolved since Orlando, the title=20 | didn't do so accordingly. We're open to suggestions, although I am not=20 | excited about the word "Feature" in an IETF RFC title :) Would=20 | something like "IKEv2-based Shared Secret Key for O/TWAMP", for=20 | example, be ok with you? |=20 |=20 | | - The use case in section 1 is not clear. It should indicate this | mode | | is intended for protecting and exchanging OWAMP/TWAMP test protocol=20 | | between two IKEv2 systems when OWAMP/TWAMP control/test traffic is | not | | protected by IPSec |=20 | The document does focus on how to derive O/TWAMP Shared Secret Key=20 | from | IKEv2 SA. As per earlier discussions in Berlin and Vancouver, I think=20 | we already agreed that this is orthogonal to whether the O/TWAMP=20 | control/test traffic is transferred inside the IPsec tunnel or not.=20 | The admin or operator policy could play a role, for example. Of=20 | course, one should avoid a so-to-speak "double security protection". |=20 |=20 | | - I personally think the most common case is to protect OWAMP/TWAMP=20 | | control/test traffic with IPsec. It is important to highlight the=20 | | benefits associated with this new mode versus the common=20 | | unauthenticated O/TWAMP mode protected via AH or ESP. |=20 | I think we mostly agree on this. Would you be so kind to propose some=20 | text to add? I guess a few of sentences would suffice at this stage |=20 |=20 | | - in section 4.1 first sentence, the requirement level is ambiguous. | I | | think it should say...the shared secret MUST be derived ...(as | opposed | | to can). Same comment for the second paragraph, the word if should=20 | | be replaced by when. |=20 | Sounds good; we will update the draft before the meeting. Thanks for=20 | this point. |=20 |=20 | | - end of section 4.1, the expected behavior when the IKEv2 SA is=20 | | rekeyed is not clear. Same is true when the IKEv2 SA is deleted for=20 | | whatever reasons. What should the O/TWAMP part of the IKE system do=20 | | when the IKE SA is rekeyed or deleted? Should it close its test=20 | | sessions and setup new test sessions using the key associated with | the | | newly established IKEv2 SA? Waiting for the lifetime to expire does=20 | | not make sense. And if you do, what happens next? |=20 |=20 | I'm not sure about this, although we would be happy to integrate=20 | proposed text from your end. The shared secret key generated from the=20 | SA could continue to be used until the lifetime expiration. Do you see=20 | a need to rekey the shared secret key immediately after the IKEv2 SA=20 | is rekeyed? |=20 | | - section 4.2. Three (3) new TWAMP modes are not needed. One TWAMP=20 | | mode called Shared Secret Key should be sufficient. This mode can | then | | be used on conjunction with the authenticated, encrypted and mixed | modes. | | Please do not use the X mode over IKEv2. The text "over" is always=20 | | misleading. |=20 |=20 | I need to go back to my notes wrt the discussion we had earlier. If I=20 | recall correctly, extending the Modes values is advantageous if one=20 | considers backwards compatibility with existing O/TWAMP clients. The=20 | Set-Up-Response Message contains a mode value which indicates=20 | unauthenticated, authenticated or encrypted. In this case, the O/TWAMP=20 | server cannot obtain the information whether to derive shared secret=20 | key from an IKEv2 SA or not, if the modes value is not extended. The=20 | Set-Up-Response Message must signal this in conjunction with the mode. | Since there is no unused field in the Set-Up-Response Message, isn't=20 | it better to extend Modes? |=20 |=20 | Best regards, |=20 | Kostas and Emma From nobody Tue Jul 22 07:54:11 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 E395D1B27F2; Tue, 22 Jul 2014 07:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 J1Nr5JvxV1XF; Tue, 22 Jul 2014 07:54:08 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7C1B27D8; Tue, 22 Jul 2014 07:54:07 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id EDC8F1FF52; Tue, 22 Jul 2014 16:54:06 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id A32811FF46; Tue, 22 Jul 2014 16:54:06 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 3E521378277; Tue, 22 Jul 2014 16:54:06 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Tue, 22 Jul 2014 16:54:05 +0200 From: Kostas Pentikousis To: Steve Baillargeon Date: Tue, 22 Jul 2014 16:54:05 +0200 Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAwgAAOCRCAAAfbQA== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FD7@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE 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/zNrmZKlDo-MXQr2pVABWd6dth9c Cc: "ipsec@ietf.org" , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] WGLC on draft-ietf-ippm-ipsec-03 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 Jul 2014 14:54:09 -0000 Hi Steve, | The changes looks good but I think we need a couple of simple network | diagrams to clarify the case when this mode is not needed and the case | when it needed. Simple network examples may be a good idea to orient the uninitiated reader= . But adding network diagrams to scope the applicability is not an equally = good idea.=20 | internal networks are considered "trustable" and both TWAMP endpoints I'm not sure whether anyone really thinks that an "internal" network in the= age of virtualization can be "trustable" :) Best regards, Kostas From nobody Tue Jul 22 07:56:50 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 33ABF1ABD17; Tue, 22 Jul 2014 07:56:47 -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 VUYtvQ6LJLeK; Tue, 22 Jul 2014 07:56:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DEF1A004D; Tue, 22 Jul 2014 07:56:44 -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.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722145644.10776.58367.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 07:56:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/ulb6OTJU8R9apK0YzmzY30gZr0k Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-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: Tue, 22 Jul 2014 14:56:47 -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 : IKEv2-based Shared Secret Key for O/TWAMP Authors : Kostas Pentikousis Yang Cui Emma Zhang Filename : draft-ietf-ippm-ipsec-04.txt Pages : 12 Date : 2014-07-22 Abstract: The O/TWAMP security mechanism requires that both the client and server endpoints possess a shared secret. Since the currently- standardized O/TWAMP security mechanism only supports a pre-shared key mode, large scale deployment of O/TWAMP is hindered significantly. At the same time, recent trends point to wider IKEv2 deployment which, in turn, calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and two-way network performance in a standardized manner. This document discusses the use of keys derived from an IKEv2 SA as the shared key in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ TWAMP can support certificate-based key exchange, which would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-ipsec-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ipsec-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 Jul 22 08:11:59 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 EC1B21B292A; Tue, 22 Jul 2014 08:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4e8TBEdb8Y3L; Tue, 22 Jul 2014 08:11:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A99B1A0073; Tue, 22 Jul 2014 08:11:41 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-1d-53ce29d5d9f7 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 78.52.25146.5D92EC35; Tue, 22 Jul 2014 11:07:33 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 11:11:40 -0400 From: Steve Baillargeon To: Kostas Pentikousis Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAwgAAOCRCAAAfbQIAAAfRQ Date: Tue, 22 Jul 2014 15:11:39 +0000 Message-ID: References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FD7@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FD7@SBS2008.eict.local> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPoO5VzXPBBl/uilksvDufyWJjyzs2 i54H75gt9m95wWax58B+VgdWjy//m5g8liz5yeTx5fJnNo8n+2eyBLBEcdmkpOZklqUW6dsl cGUc2nmRvWApZ8Wx7lVsDYzH2LsYOTkkBEwkft48zwJhi0lcuLeerYuRi0NI4CijxM3rd5kh nOWMEh//N7GBVLEJWEisn7uMGcQWEdCT2LP2HCtIEbPAHkaJrzv7wMYKA439OPc+C0SRqcTe A5PZIewoiV9328DiLAKqEhcuPmUEsXkFfCXuX+tngtg2iUXiwrfprCAJTgEfiabr78GaGQVk JXafvc4EYjMLiEvcejKfCeJuAYkle84zQ9iiEi8f/2OFsJUk5ry+xgxRryOxYPcnNghbW2LZ wtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiB0XVMgs1xB+OC T5aHGAU4GJV4eBc8ORMsxJpYVlyZe4hRmoNFSZxXs3pesJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbG0uo2YU0DZhvzTuYzIlVfk6MWLeKbl/PN7efEx/q5IT6XIua/XBfr9CvmdLKOzSb7 2ElCfLXpB3+XrZ90Xbi3gaH68K3jf/e4b0qwS3RmvZD9NVhV6FuaptCvwrCLxe8vd808d4XB nflVRdiX83u2XI56OK3QXrN0y9QELsXFRpMryr1E+dKUWIozEg21mIuKEwG1Fo9mjwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/WmjJfhFWhzuiVdiXLVgB7ZcB2QE Cc: "ipsec@ietf.org" , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] WGLC on draft-ietf-ippm-ipsec-03 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 Jul 2014 15:11:56 -0000 Hi Kostas I must disagree here.=20 Stating that unauthenticated mode is no longer applicable is incorrect. I believe that adding network diagrams to scope the applicability is a good= idea as long as the associated text is concise. I am still confused about the new mode applicability :) -Steve -----Original Message----- From: Kostas Pentikousis [mailto:k.pentikousis@eict.de]=20 Sent: July-22-14 10:54 AM To: Steve Baillargeon Cc: draft-ietf-ippm-ipsec@tools.ietf.org; Brian Trammell; ippm@ietf.org; ip= sec@ietf.org Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Hi Steve, | The changes looks good but I think we need a couple of simple network=20 | diagrams to clarify the case when this mode is not needed and the case=20 | when it needed. Simple network examples may be a good idea to orient the uninitiated reader= . But adding network diagrams to scope the applicability is not an equally = good idea.=20 | internal networks are considered "trustable" and both TWAMP endpoints I'm not sure whether anyone really thinks that an "internal" network in the= age of virtualization can be "trustable" :) Best regards, Kostas From nobody Tue Jul 22 11:47: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 D73531B2BBB for ; Tue, 22 Jul 2014 11:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 7uulsLlt6_XV for ; Tue, 22 Jul 2014 11:46:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2191A02E9 for ; Tue, 22 Jul 2014 11:46:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8940222AB0 for ; Tue, 22 Jul 2014 14:46:43 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Tue, 22 Jul 2014 14:46:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=Wg79aJMOjgnBLT7VZtFn4mQmIyE=; b=G+efFY2+yi2JjgmboDSNDg7DnM5P wt+5qoDg5A+F7Zk5QUy0DIRfoa+DSauZjPlvarjntJyyJDs3AYTZcQTjIQ+wiHrr NubXL6GOZLLC4BMpjYWwaMkBYM+BQ20uFir4BYT6BeJ+Y/3fea7ePtOBEkF7zYY7 fGFYqk76ZKsZJBQ= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 699B9F005D8; Tue, 22 Jul 2014 14:46:43 -0400 (EDT) Message-Id: <1406054803.20043.144501713.5AB9F558@webmail.messagingengine.com> X-Sasl-Enc: Xyc1mAf0X4h4ds+Ogq1MMI/DSinVtx4NYUiO5pIUZgzj 1406054803 From: William Cerveny To: ippm@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-c420910d Date: Tue, 22 Jul 2014 14:46:43 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/uNu4RsM3qFz48sDeSH0H1BLXFpE Subject: [ippm] Jabber and minutes scribes still needed for IPPM @ IETF90 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 Jul 2014 18:46:55 -0000 Dear IPPM@IETF90 Meeting Participants, We are still searching for jabber and minutes scribes for the upcoming IPPM meeting this afternoon ... if you can help with one of these functions (with priority for minutes scribe), please let me know now and/or before the meeting begins. Thanks, Bill Cerveny From nobody Wed Jul 23 13:18:13 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 6B2501B27FD for ; Wed, 23 Jul 2014 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4bWmZBKH2gkx for ; Wed, 23 Jul 2014 13:18:04 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 851161A0537 for ; Wed, 23 Jul 2014 13:18:04 -0700 (PDT) Received: from eduroam-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:25dc:512c:e0e6:4235]) by trammell.ch (Postfix) with ESMTPSA id 320AA1A0989 for ; Wed, 23 Jul 2014 22:17:32 +0200 (CEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5248F368-6558-40B3-A8CC-909797D3E7CB@trammell.ch> Date: Wed, 23 Jul 2014 16:17:29 -0400 To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Lb2l1ArTEZpwQKVG1YkUysD_jJ8 Subject: [ippm] Draft IETF 90 IPPM WG meeting minutes posted to datatracker 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: Wed, 23 Jul 2014 20:18:06 -0000 Greetings, all, Draft minutes for yesterday's meeting are available at: http://www.ietf.org/proceedings/90/minutes/minutes-90-ippm Many thanks to Sarah Banks for taking minutes during the meeting. If you have any comments or additions, please let us know at = ippm-chairs@tools.ietf.org.=20 Many thanks, best regards, Brian= From nobody Wed Jul 23 16:13:22 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 9CC6A1A011E; Wed, 23 Jul 2014 16:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] 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 Xj6-TmMm21qW; Wed, 23 Jul 2014 16:08:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470F01A00B5; Wed, 23 Jul 2014 16:08:48 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s6NN7Qaf024892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jul 2014 02:07:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6NN7OB1008483; Thu, 24 Jul 2014 02:07:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21456.16428.701207.732932@fireball.kivinen.iki.fi> Date: Thu, 24 Jul 2014 02:07:24 +0300 From: Tero Kivinen To: Kostas Pentikousis In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 14 min Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/UHqIeMTyVZ03EaahIz8x3M04iAQ X-Mailman-Approved-At: Wed, 23 Jul 2014 16:13:21 -0700 Cc: "ipsec@ietf.org" , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] [IPsec] WGLC on draft-ietf-ippm-ipsec-03 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: Wed, 23 Jul 2014 23:08:50 -0000 Kostas Pentikousis writes: > (adding ipsec folks in CC) I quickly read this document and I think it needs much broaders review from the IPsec people. This document is using internal IKEv2 keying material outside IKEv2 SA context, meaning it can cause problems with the actual security of the IKEv2 SA. It uses Shared secret key = PRF( SKEYSEED, "IPPM" ) to generate the shared key to be used in the ippm. The SKEYSEED is internal IKEv2 keying material, and should not be exposed outside IKEv2. All IKEv2 keying material to protect the IKEv2 SA is also derived from that value. The generation looks quite safe, so it most likely do not directly cause IKEv2 SA to be broken, but also as SKEYSEED is internal to the IKEv2, it might not be available at all outside the IKEv2 library. For example my IKEv2 code will never store the SKEYSEED, it is temporary calculated and then used to calculate the derived SK_* keys, and then immediately zeroed out. It would be much better to use the SK_d or KEYMAT which is derived from the SK_d for that purposes, as that is what SK_d was meant to be used, (i.e to derive keys for other uses than IKEv2 SA protection or authentication). Also the section 4.1 talks about the lifetime of the shared secret key, but I have no idea what expire time it is refering to. If it refers to the Shared secret key generated above, then where is its expire time defined? IKEv2 does not negotiate lifetimes, and IKEv2 SA rekey is the closest thing we have about lifetime in the IKEv2, but the text explictly says that "shared secret key generated" can continue to be used... Anyways I thing this document needs more reviews especially from the IPsec community, as it is using IKEv2 as KMP for something else than IPsec (which is not a wrong thing to do, but you need to know what you are doing). -- kivinen@iki.fi From nobody Thu Jul 24 05:07: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 346B01A024C; Thu, 24 Jul 2014 05:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 UEle0djG5OHE; Thu, 24 Jul 2014 05:06:59 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB91A0250; Thu, 24 Jul 2014 05:06:58 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 80D2D1FF58; Thu, 24 Jul 2014 14:06:57 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 380801FF54; Thu, 24 Jul 2014 14:06:57 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id BC71437825F; Thu, 24 Jul 2014 14:06:56 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 24 Jul 2014 14:06:56 +0200 From: Kostas Pentikousis To: Tero Kivinen Date: Thu, 24 Jul 2014 14:06:54 +0200 Thread-Topic: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: Ac+mzo7WbZngNQMUSV+XLiReTVehhQAZ/zXg Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C61A112@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> <21456.16428.701207.732932@fireball.kivinen.iki.fi> In-Reply-To: <21456.16428.701207.732932@fireball.kivinen.iki.fi> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE 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/S8lm2FnD_WXKRkJhj4E_8ASH9is Cc: "ipsec@ietf.org" , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] [IPsec] WGLC on draft-ietf-ippm-ipsec-03 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 Jul 2014 12:07:01 -0000 Hi Tero, all, Many thanks for chimming in, much appreciated! =20 | Anyways I thing this document needs more reviews especially from the | IPsec community, as it is using IKEv2 as KMP for something else than | IPsec (which is not a wrong thing to do, but you need to know what you | are doing). Indeed, and as you may recall I have asked ipsec in the the past for commen= ts/review wrt this draft. I'm very happy to see the comments and I think al= l at ippm will be even happier to see more of it. Best regards, Kostas From nobody Thu Jul 24 05:31:27 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 C52181A023E; Thu, 24 Jul 2014 05:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2o_PvxisAHFu; Thu, 24 Jul 2014 05:31:21 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CF9C21A0280; Thu, 24 Jul 2014 05:31:20 -0700 (PDT) Received: from dhcp-9d17.meeting.ietf.org (dhcp-9d17.meeting.ietf.org [31.133.157.23]) by trammell.ch (Postfix) with ESMTPSA id 724911A0327; Thu, 24 Jul 2014 14:30:47 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C61A112@SBS2008.eict.local> Date: Thu, 24 Jul 2014 08:30:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36E1DF4F-B178-4346-AC35-78C176B5FB14@trammell.ch> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> <21456.16428.701207.732932@fireball.kivinen.iki.fi> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C61A112@SBS2008.eict.local> To: Kostas Pentikousis , "ipsec@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/G-RijVQjgdlUrylcXCIYIqvuYrY Cc: "draft-ietf-ippm-ipsec@tools.ietf.org" , Tero Kivinen , "ippm@ietf.org" Subject: Re: [ippm] [IPsec] WGLC on draft-ietf-ippm-ipsec-03 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 Jul 2014 12:31:26 -0000 hi Kostas, Tero, all, Many thanks for the review! For the benefit of the ipsec working group, there are still a few = discussions from the ippm side but we expect these to be resolved soon, = after which we'd like to request publication. One or two more reviews = from ipsec in the meantime would be extremely useful. Thanks again, best regards, Brian (as co-chair, ippm) On 24 Jul 2014, at 8:06, Kostas Pentikousis = wrote: > Hi Tero, all, >=20 > Many thanks for chimming in, much appreciated! >=20 > =20 >=20 > | Anyways I thing this document needs more reviews especially from the > | IPsec community, as it is using IKEv2 as KMP for something else than > | IPsec (which is not a wrong thing to do, but you need to know what = you > | are doing). >=20 > Indeed, and as you may recall I have asked ipsec in the the past for = comments/review wrt this draft. I'm very happy to see the comments and I = think all at ippm will be even happier to see more of it. >=20 > Best regards, >=20 > Kostas >=20 >=20 From nobody Fri Jul 25 11:30:49 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 EAACB1A0452; Fri, 25 Jul 2014 11:30:45 -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, HTML_MESSAGE=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 BTswxuM2eQCO; Fri, 25 Jul 2014 11:30:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC9D1A041C; Fri, 25 Jul 2014 11:30:43 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-d9-53d24cd178d7 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F4.CA.25146.1DC42D35; Fri, 25 Jul 2014 14:25:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 14:30:41 -0400 From: David Sinicrope To: "lmap@ietf.org" Thread-Topic: Liaison from Broadband Forum to the IETF with attached Straw Ballot Text for WT-304 Thread-Index: AQHPqDaKbeGWkbMzVkaI/6KBiyEp4A== Date: Fri, 25 Jul 2014 18:30:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_CFF81A90141427davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyuXSPn+4ln0vBBtc3c1k8mbaByaJl9z82 i54H75gtms9rW2xdf5zZ4tOSvewObB6tz/ayeqzvnsDi0fZlMpPHkiU/mTxanp1kC2CN4rJJ Sc3JLEst0rdL4MqYt3IhY8Ff7oopC1exNDAe5upi5OSQEDCROPrhNDuELSZx4d56ti5GLg4h gaOMEgu/vmUDSQgJLGeU+DHfFMRmA2pYt3EPC4gtIqAsceb1ImaQBmaBXiaJ9VveMHUxcnAI C8RJvPrKCVGTLPH651V2CFtP4u7svawgNouAqsSNpfPB5vMKWElMfbocLM4IdMT3U2uYQGxm AXGJW0/mM0EcJyCxZM95ZghbVOLl439g9aJAM9e374aqUZKY8/oaM0RvvMS8VxB7eQUEJU7O fMIygVFkFpKxs5CUzUJSBhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMELa1RGPXYRQ1Cxg5VjFy lBanluWmGxluYgRG5jEJNscdjAs+WR5iFOBgVOLhXaB1KViINbGsuDL3EKM0B4uSOK9m9bxg IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyzXGpW/bXlXhDyY1fLoq1MF1fOratap/H+2Gvp PF2GrPV6qz9GfJ4rbl1Wt7UksPkg33dnr5sRloEsck+PaBzRXlfg/X+phuPxr4bnVhjUZF/+ lBAaqdq3p3bO4U9nbYueLhdWYtl3zTqmkPfZnH03uF+467OEi+3+e9tyjWZ83ORPNzKjll1R YinOSDTUYi4qTgQAKQgk4K0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/B6bs-bhn9MK5uit8HK1Z6BZ4mzo Cc: David Allan I , "ippm@ietf.org" , Sven Ooghe , Robin Mersh , Dave Thorne , "christophe.alter@orange.com" Subject: [ippm] Liaison from Broadband Forum to the IETF with attached Straw Ballot Text for WT-304 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: Fri, 25 Jul 2014 18:30:46 -0000 --_000_CFF81A90141427davidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable https://datatracker.ietf.org/liaison/1341/ As discussed in Thursday=92s LMAP session, please find the link above to th= e anticipated Broadband Forum WT-304 draft text and the accompanying liaiso= n. If you have any questions, please feel free to contact me. Thanks, David Sinicrope IETF Liaison Manager to Broadband Forum --_000_CFF81A90141427davidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <63B23BF90EE37B4A9D59CBBD40E5F916@ericsson.com> Content-Transfer-Encoding: quoted-printable

As discussed in Thursday=92s LMAP session, please find the link above = to the anticipated Broadband Forum WT-304 draft text and the accompanying l= iaison.
If you have any questions, please feel free to contact me.
Thanks,
David Sinicrope
IETF Liaison Manager to Broadband Forum
--_000_CFF81A90141427davidsinicropeericssoncom_-- From nobody Tue Jul 29 17:22:53 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 390B91A03A9 for ; Tue, 29 Jul 2014 17:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 FGNVB9QJtw7R for ; Tue, 29 Jul 2014 17:22:49 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF651A035B for ; Tue, 29 Jul 2014 17:22:48 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so718977vcb.21 for ; Tue, 29 Jul 2014 17:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PLlXhP5bfCKlt/x/GZUsPAKQ+YXtG761lSUFLm5AoPo=; b=qQsqjTXka1pp0h7G+hQ9jLj7CBUzvD5IDG/oTCQBU/gN0ApmVv+nuQ3w9j6AKRbm7L uxgcEaaHG+y7EI3dMCVkruxZvsU+9ws+2+Vs8WucOpNX2TG+0GVxhhs6sDK7kjZsnwqe mANHilQ8vUE+BcSqFe6QOp1zXloRPpHYwagCPdYT0eK39dn+m938dEUVw7aCV448lNB9 ijoShHPP1QyOVPtT1ufhdMaNoUiVUnbF8sWXmEH/GFQ2GOQBQ7nf+kCx2comO7yHlXgI DdHACTLBKStVgiBRhoB3xM/MXamVxnkLym/QvbxUVk6Tulgzr+be/iTB7hQ3Hb1fUsvs KUdw== MIME-Version: 1.0 X-Received: by 10.52.244.81 with SMTP id xe17mr4509822vdc.24.1406679767938; Tue, 29 Jul 2014 17:22:47 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Tue, 29 Jul 2014 17:22:47 -0700 (PDT) In-Reply-To: <5248F368-6558-40B3-A8CC-909797D3E7CB@trammell.ch> References: <5248F368-6558-40B3-A8CC-909797D3E7CB@trammell.ch> Date: Tue, 29 Jul 2014 17:22:47 -0700 Message-ID: From: Greg Mirsky To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11c2c34ae17b8604ff5e27e4 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/V76k3ixVbdQxw8Nd2oiEWE-U4II Cc: "ippm@ietf.org" Subject: Re: [ippm] Draft IETF 90 IPPM WG meeting minutes posted to datatracker 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: Wed, 30 Jul 2014 00:22:51 -0000 --001a11c2c34ae17b8604ff5e27e4 Content-Type: text/plain; charset=UTF-8 Hi Brian, could you please update the minutes in part of discussion of rate-problem document. I believe the comments tagged 'Mike' were mine as well as proposal, after Al's Shakespearean quote, to modify the requirement to "protocol MUST support generating asymmetrical packet size. Protocol SHOULD support generating packets with asymmetrical size." "general agreement in the room" in my opinion very accurately captures the reaction to the proposal. Regards, Greg On Wed, Jul 23, 2014 at 1:17 PM, Brian Trammell wrote: > Greetings, all, > > Draft minutes for yesterday's meeting are available at: > > http://www.ietf.org/proceedings/90/minutes/minutes-90-ippm > > Many thanks to Sarah Banks for taking minutes during the meeting. > > If you have any comments or additions, please let us know at > ippm-chairs@tools.ietf.org. > > Many thanks, best regards, > > Brian > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --001a11c2c34ae17b8604ff5e27e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,
could you please update = the minutes in part of discussion of rate-problem document. I believe the c= omments tagged 'Mike' were mine as well as proposal, after Al's= Shakespearean quote, to modify the requirement to "protocol MUST supp= ort generating asymmetrical packet size. Protocol SHOULD support generating= packets with asymmetrical size." "general agreement in the room&= quot; in my opinion very accurately captures the reaction to the proposal.<= br>
Regards,
Greg

On Wed, Jul 23, 2014 at 1:17 PM, Brian Trammel= l <ietf@trammell.ch> wrote:
Greetings, all,

Draft minutes for yesterday's meeting are available at:

http://www.ietf.org/proceedings/90/minutes/minutes-90-ippm

Many thanks to Sarah Banks for taking minutes during the meeting.

If you have any comments or additions, please let us know at ippm-chairs@tools.ietf.org.

Many thanks, best regards,

Brian
_______________________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm

--001a11c2c34ae17b8604ff5e27e4--